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 try
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
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 can recover
[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
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 checkout) to
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 communication for
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 for a
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 j...@perches.com
---
drivers/net/ps3_gelic_wireless.c | 35 +++---
drivers/net/wireless/ipw2x00/ipw2200.c | 83
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
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 to
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
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
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
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
