On Maw, 2004-06-15 at 10:08, Nicolas DET wrote:
> For this specific case, the interrupt handler should manage it:
>
> >if ( (!(status & ~USBSTS_HCH)) /* shared interrupt, not mine */
> > || (!uhci->IntEnableReg_SW) )
> >{
> > retval = IRQ_NONE;
> > goto end;
> >}
>
> uhci->IntEnableReg_SW is the "software" view of the "Interrupt Enable"
> register of our UHCI chipset.
It makes me nervous. The first thing I see is the question about
ordering between posted writes to the IntEnable reg in PCI space and the
software register. The second thing is returning IRQ_NONE causing the
"screaming interrupt" warning.
I'm not saying you are wrong, its the kind of code that I really really
would never write unless it had huge payback.
> So if the interrupt arrives between stop_interrupt and spin_lock, the
> handler will no be taken because IntEnableReg_SW would be 0 (set by
> stop_interrupt) and the spin_lock would not be executed.
You do hang in the IRQ handler in this case until the drop of the IRQ
reaches the far end of the link because it is level triggered.
Alan
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
