[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: acquiring an interrupt for swim3 floppy driver



On Wed, 13 Apr 2005, Brad Boyer wrote:

On Tue, Apr 12, 2005 at 07:37:16PM -0500, vinai wrote:

I was wondering what was the best/cleanest (and SMP-safe) way to grab
an interrupt ?  swim3 currently uses local_irq_enable, but from past
discussions on the list, it did not sound like it was SMP safe.  All
of the other local_irq_ code seems to be easily enough bracketed off
by equivalent spin lock functions, but I haven't found one that works
for just the irq_enable ...

I just looked at the copy of swim3.c that I have (from 2.6.8.1), and I
can't figure out why it's even using local_irq_enable(). It doesn't
seem like a safe thing to do anyway. I'd suggest trying to figure out
why it was doing that before, since it's possible you can just drop it.

I looked at floppy.c, and tried to backtrack where that driver got an
interrupt, and it went back to asm/floppy.h, which seemed to want hard
coded values for floppy IRQ and DMA, which I did not think we had to
do on PPC ?  So that was the dead end that brought me back here ...

Are you converting it over to being a proper macio driver while you're
there? If so, you can just ask the macio layer for the various correct
addresses and IRQ values with the functions on the macio_dev object.
Otherwise, you would get them out of the device_node just like it does
in the old version.

The mainline floppy code is pretty stupid and PC specific. It expects
to have most of the information compiled into the kernel, which doesn't
really work for mac hardware.

No - my attempts right now were to get the driver to compile (by getting
rid of the old sti/cli/save_flags/restore_flags).  I was able to do this
by getting rid of these functions and replacing them with the local_irq_
equivalents, and the driver compiled, and even worked ;-)

However, in trying to make the driver SMP-safe, I haven't had any luck.
Replacing the local_irq functions by their spin_lock equivalents have
not resulted in a working kernel for me.  I thought this was due to the
local_irq_enable.  x86 floppy.c did not use such a routine, but the way
that driver acquired an interrupt value led me back to defined values
for FLOPPY_IRQ and FLOPPY_DMA - which did not look right for PowerPC...

Thanks for the pointers - I'll look into device_node and see what's in
there ;-)

cheers
vinai



Reply to: