From: Kevin Hilman <khilman@ti.com>
To: Govindraj <govindraj.ti@gmail.com>
Cc: Tero Kristo <t-kristo@ti.com>, linux-omap@vger.kernel.org
Subject: Re: [PATCHv3 2/6] PRCM: Add support for PAD wakeup interrupts
Date: Fri, 24 Jun 2011 14:34:32 -0700 [thread overview]
Message-ID: <87sjqyykuv.fsf@ti.com> (raw)
In-Reply-To: <BANLkTingCPNkpcyfNwy2=M75n6cmVUR6Yg@mail.gmail.com> (Govindraj's message of "Thu, 23 Jun 2011 15:53:29 +0530")
Govindraj <govindraj.ti@gmail.com> writes:
> On Wed, Jun 22, 2011 at 10:12 PM, Tero Kristo <t-kristo@ti.com> 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@ti.com>
[...]
>> @@ -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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-06-24 21:34 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-22 16:42 [PATCHv3 0/6] PRCM chain handler Tero Kristo
2011-06-22 16:42 ` [PATCHv3 1/6] omap: prcm: switch to a chained IRQ handler mechanism Tero Kristo
2011-06-22 23:53 ` Kevin Hilman
2011-06-23 7:24 ` Tero Kristo
2011-06-23 8:19 ` Tony Lindgren
2011-06-23 9:08 ` Tero Kristo
2011-06-23 9:51 ` Tony Lindgren
2011-06-24 16:00 ` Kevin Hilman
2011-06-24 21:02 ` Kevin Hilman
2011-06-22 16:42 ` [PATCHv3 2/6] PRCM: Add support for PAD wakeup interrupts Tero Kristo
2011-06-23 10:23 ` Govindraj
2011-06-24 21:34 ` Kevin Hilman [this message]
2011-06-24 21:21 ` Kevin Hilman
2011-06-22 16:42 ` [PATCHv3 3/6] OMAP: PRCM: Added an api to get id for a PRCM event Tero Kristo
2011-06-24 21:58 ` Kevin Hilman
2011-06-22 16:42 ` [PATCHv3 4/6] OMAP3: PM: Use PRCM chain handler Tero Kristo
2011-06-24 21:57 ` Kevin Hilman
2011-06-22 16:42 ` [PATCHv3 5/6] OMAP3: Serial: Made serial to work properly with " Tero Kristo
2011-06-22 17:09 ` Tero Kristo
2011-06-23 10:30 ` Govindraj
2011-06-23 8:21 ` Tony Lindgren
2011-06-23 9:11 ` Tero Kristo
2011-06-23 10:00 ` Tony Lindgren
2011-06-23 10:35 ` Govindraj
2011-06-23 11:12 ` Tony Lindgren
2011-06-24 15:15 ` Kevin Hilman
2011-06-24 22:00 ` Kevin Hilman
2011-06-22 16:42 ` [PATCHv3 6/6] OMAP3: Serial tty: Added resume_idle calls to critical points Tero Kristo
2011-06-27 15:02 ` [PATCHv3 0/6] PRCM chain handler Tero Kristo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sjqyykuv.fsf@ti.com \
--to=khilman@ti.com \
--cc=govindraj.ti@gmail.com \
--cc=linux-omap@vger.kernel.org \
--cc=t-kristo@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.