Tero Kristo <t-kristo@xxxxxx> writes: > Introduce a chained interrupt handler mechanism for the PRCM > interrupt, so that individual PRCM event can cleanly be handled by > handlers in separate drivers. We do this by introducing PRCM event > names, which are then matched to the particular PRCM interrupt bit > depending on the specific OMAP SoC being used. > > arch/arm/mach-omap2/prcm.c implements the chained interrupt mechanism > itself, with individual PRCM events for OMAP3 and OMAP4 being > described in arch/arm/mach-omap2/prcm3xxx.c and > arch/arm/mach-omap2/prcm4xxx.c respectively. At initialization time, > the set of PRCM events is filtered against the SoC on which we are > running, keeping only the ones that are actually useful. All the logic > is written to be generic with regard to OMAP3/OMAP4, even though OMAP3 > has single PRCM event registers and OMAP4 has two PRCM event > registers. > > The wakeup and I/O PRCM events are now handled as two separate > interrupts, and their handler is registered with IRQF_NO_SUSPEND, > otherwise the IRQ gets disabled during suspend, which prevents resume. > > Patch tested on OMAP4 blaze board, no testing done on OMAP3. > > Signed-off-by: Tero Kristo <t-kristo@xxxxxx> > Cc: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx> > Cc: Avinash.H.M <avinashhm@xxxxxx> > Cc: Kevin Hilman <khilman@xxxxxx> > Cc: Cousson, Benoit <b-cousson@xxxxxx> Another minor comment/request: Can you see if you can keep the chip_is checking out of the generic code and only in the SoC specific code. Using the register approach I mentioned earlier, it should be easy to do the filtering in SoC specific code before registering so the generic driver doesn't have to care. IOW, all SoC-specific stuff is done in SoC-specific init and all that is registered with the generic code is name/offset pairs. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
