Govindraj <govindraj.ti@xxxxxxxxx> writes: > On Wed, Jun 22, 2011 at 10:12 PM, Tero Kristo <t-kristo@xxxxxx> wrote: >> PRCM interrupt handler will now parse registered pads to see whether there >> is an active wakeup event. If this is the case, the corresponding interrupt >> will be triggered. This can be used for example with UART driver to register >> PAD wakeup event for the UART RX pin, and when this happens, UART interrupt >> will be triggered. >> >> Signed-off-by: Tero Kristo <t-kristo@xxxxxx> [...] >> @@ -153,6 +184,25 @@ int omap_prcm_event_to_irq(const char *name) >> } >> >> /* >> + * Register interrupt handler for a given pad. When the PRCM interrupt >> + * handler detects wakeupevent on the corresponding pad, the IRQ will >> + * be triggered. >> + */ >> +int omap_prcm_register_pad_irq(u32 pad, unsigned int irq) > > I tested this v3 series seems to work fine. > > Minor comments. > > Can we make the prcm_register interface params with mux_name > or > even omap_hmwod and with hwmod api's check > wake-up event through a mux api as here [1] > rather than passing pad offset. Hmm, good point. In fact, each omap_hwmod already knows about the pads and the IRQ for each IP block, so another API to create that mapping isn't really needed. Instead, what we need is simply a way register an omap_hwmod with the PRCM layer to indicate that it should trigger the IRQ whenever a wakup is detected. Then, when a wakeup event is detected, it could call a new omap_hwmod_mux_* function which would use the IRQ in the hwmod and call generic_handle_irq(). I think adding to Govindraj's patch below[1] with a new API to handle the irq: omap_hwmod_mux_handle_irq() or something similar would be the right way to handle this. > since I planning to test uart-runtime changes with irq_chaining, > pad offsets are no more available with uart-runtime > and uses hmwod_mux api's. > > -- > Thanks, > Govindraj.R > > [1] https://patchwork.kernel.org/patch/773932/ 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
