On Monday 18 January 2010 21:33:09 Andy Walls wrote:
> On Mon, 2010-01-18 at 19:35 +0100, Hans Verkuil wrote:
> 
> > There is no particular order to these items. Most of these are hard or time
> > consuming to do. Otherwise I'd have done them by now :-)
> > 
> > - Both cx18 and ivtv use IRQF_DISABLED when registering the irq. This flag 
> > is
> >   bogus (and produces this annoying message in the log: 'IRQF_DISABLED is 
> > not
> >   guaranteed on shared IRQs'). Note that many drivers do this. This is 
> > something
> >   I discovered only recently.
> 
> I naively asked near the end of this discussion on the LKML what is the
> preferred solution to fix the "problem":
> 
> http://lkml.org/lkml/2009/11/30/486
> 
> No one answered.  The whole thread was about the problem with
> IRQF_DISABLED not being honored and the need to run with interrupts
> disabled.
> 
> As I understand it, the IRQF_SHARED with IRQF_DISABLED problem is really
> a problem in the kernel's management of interrupt handlers and has been
> labled as "do not fix".  Hence we have a useless message being printed
> out, warning users of a condition that has been in existence long before
> the message existed, for which there is no agrred upon solution in
> sight.  The user can't fix it short of moving hardware around.  I'm
> pretty sure a driver can't fix it without either:
> 
> a. refusing to work at all (no good for users)
> 
>  or
> 
> b. running it's IRQ handler with interrupts enabled (no good for
> multimedia capture devices, you'll just drop frames for no good reason)
> 
> So there the warning message sits.
> 
> 
> Did I get it wrong?

The problem with IRQF_DISABLED is that it disables all interrupts. We don't
need that. And while you are in an interrupt handler you can be sure you
won't be interrupted again with the same interrupt (so no nesting). So what's
the point of IRQF_DISABLED in the first place? From what I've read there
should be no reason to set this flag anymore except in some rare cases to do
with timers (Linux Device Drivers, 3rd edition, page 268, Fast and Slow 
Handlers).

Regards,

        Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Reply via email to