Re: lockdep and threaded IRQs (was: ...)

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

 



On Saturday 28 February 2009, Thomas Gleixner wrote:
> > > > 
> > > > Where you'll observe twl_init_irq() at line 688 setting
> > > > up the thread and the Primary IRQ Handler (PIH) dispatch.
> > > > That's pretty much bog-standard chained IRQ setup code,
> > > > except that it chains through a thread.
> > > 
> > > So this would be the perfect candidate to test the generic threaded
> > > code I posted a few days ago ?
> > 
> > Could be.  URL?
> 
> http://lkml.org/lkml/2009/2/26/146

Quick report:

 - patch 2/4 didn't apply, mainline uses GFP_ATOMIC in that
   memory allocation not GFP_KERNEL; obvious fix.

 - patch 4/4 also didn't apply, 5/15 hunks failed ... looks
   like IRQ affinity stuff.  free_irq() changes need rework,
   the others look to have obvious fixes.

Got a version that applies to mainline GIT?


At a quick glance it looks like these patches don't cover
set_irq_chained_handler(), which would be trouble since
__setup_irq() doesn't get called in those cases.

They should however handle simpler cases, like I2C devices
that only expose one IRQ instead of needing to demux several
dozen IRQs going to different drivers and subsystems.

And, not touching lockdep, the original ugliness will still
be needed (re-enabling IRQs in threaded handlers).

- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux