On Tue, Mar 30, 2010 at 10:05:01PM -0500, Bill Gatliff wrote:
[...]
> In other words, the GPIO pin I'm using for the key is one of the bits on
> my pca953x GPIO expander chip.
>
> The above would all be great, except that I haven't come up with a way
> to make sure that my encoder_button doesn't t
This patch adds NAPI support to the MPC52xx FEC network driver. The main
reason for using NAPI is to solve the problem of system hangs under
heavy packet storms causing interrupt flooding. While NAPI support is
straight-forward, recovering from RX FIFO errors is more delicate.
Actually, under packe
Hi Roman,
Wolfgang Grandegger wrote:
> Roman Fietze wrote:
>> Hello,
>>
>> I think this is a never ending story. This error still happens under
>> higher load every few seconds, until I get a "PHY: f0003000:00 - Link
>> is Down", on my box easiliy reproducable after maybe 15 to 30 seconds.
>> I ca
[please CC me as I am not subscribed]
Hi,
when building a kernel for powerpc32 (PowerBook6,8 / 7447A) I can select
CONFIG_KEXEC. However, after booting I can't convince kexec (from
kexec-tools, latest git checkout) to load the kernel:
# /opt/kexec-tools/sbin/kexec -l /boot/2.6/zImage --append="
Hi,
On Wed, Mar 31, 2010 at 05:18:18AM -0700, Christian Kujau wrote:
> [please CC me as I am not subscribed]
>
> Hi,
>
> when building a kernel for powerpc32 (PowerBook6,8 / 7447A) I can select
> CONFIG_KEXEC. However, after booting I can't convince kexec (from
> kexec-tools, latest git checkou
On Tue, Mar 30, 2010 at 11:46:29PM -0500, Kumar Gala wrote:
>
> On Nov 5, 2008, at 3:22 PM, Ira Snyder wrote:
>
> > This adds support to Linux for a virtual ethernet interface which uses the
> > PCI bus as its transport mechanism. It creates a simple, familiar, and fast
> > method of communicatio
Peter Pan wrote:
Recently, I'm porting Linux 2.6.32.6 to our customized MPC8247 based
board. Everything is fine out except my ethernets. I uses
cpm2-scc-enet and cpm2-fcc-enet drivers.
My ethernet works fine in U-Boot with the same setting, and our
previous Linux 2.6.22 is also working, so there
>
> I'm tracking a problem that's leading me through DSI and DTLB miss
> exceptions on an MPC8347 (e300c1 core), and I've come across an oddity
> that I'm hoping someone can explain.
>
> When a DTLB Miss exception can't find a PTE for the virtual address being
> written/read, it dummies up the SPRs
Hi,
On 03/17/2010 11:21 PM, Joe Perches wrote:
> Use #define STD_IW_HANDLER from wireless.h instead
>
> Signed-off-by: Joe Perches
> ---
> drivers/net/ps3_gelic_wireless.c | 35 +++---
> drivers/net/wireless/ipw2x00/ipw2200.c | 83
>
> 2 files
On Wed, 31 Mar 2010 at 17:23, Anton Vorontsov wrote:
> Kernel has all needed for kexec, but kexec-tools are broken for
> powerpc32.
>
> http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg22498.html
Oh :-\
> I've just asked around, and it seems that Maxim (Cc'ed) will start
> working on
Yes, the PHY address is correct, I've checked the schematics, and
2.6.22 is also using this PHY address.
The different between 2.6.22 and 2.6.32.6 is that:
In 2.6.22, we use arch/ppc/8260_io/fcc_enet.c as the driver. IMMR
address 0xf000 is directly used.
In 2.6.32.6, cpm2-fcc-enet driver is use
I got a question when reading source code. Hope somebody can give me the
answer.
On multi-core system, spin_lock_irqsave() can stop all CPU cores
receiving interrupts?
If the answer is no, what we can do to disable external interrupt for
all CPU cores?
Thanks,
Gavin
___
On Thu, 2010-04-01 at 09:59 +0800, gshan wrote:
> On multi-core system, spin_lock_irqsave() can stop all CPU cores
> receiving interrupts?
No.
> If the answer is no, what we can do to disable external interrupt for
> all CPU cores?
You don't :-)
Really, you generally don't. Why would you want
On Thu, 2010-04-01 at 10:41 +0800, gshan wrote:
> One of my private driver need it. I don't know how to do it.
Then your driver is most certainly doing something wrong :-) No driver
needs that. Ever.
What is it trying to do more precisely ? I might be able to explain what
the right approach is i
Benjamin Herrenschmidt wrote:
On Thu, 2010-04-01 at 09:59 +0800, gshan wrote:
On multi-core system, spin_lock_irqsave() can stop all CPU cores
receiving interrupts?
No.
Thanks a lot for your answer.
If the answer is no, what we can do to disable extern
Then your driver is most certainly doing something wrong :-) No driver
needs that. Ever.
What is it trying to do more precisely ? I might be able to explain what
the right approach is if you can tell me what the driver is trying to
disable all system IRQs for ? Keep in mind that local_irq_save
On Thu, 2010-04-01 at 11:18 +0800, gshan wrote:
> I agree with you. Actually, I can disable the individual interrupt via
> disable_irq_sync() to make sure
> system cooherence.
This is also a very heavy hammer and not recommended at all. In most
case, you don't need that either. Also don't forget
17 matches
Mail list logo
