public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@ti.com>
To: Tero Kristo <t-kristo@ti.com>
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv3 2/6] PRCM: Add support for PAD wakeup interrupts
Date: Fri, 24 Jun 2011 14:21:00 -0700	[thread overview]
Message-ID: <87fwmzylhf.fsf@ti.com> (raw)
In-Reply-To: <1308760934-9757-3-git-send-email-t-kristo@ti.com> (Tero Kristo's message of "Wed, 22 Jun 2011 19:42:10 +0300")

Tero Kristo <t-kristo@ti.com> writes:

> 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>
> ---
>  arch/arm/mach-omap2/prcm.c             |   50 ++++++++++++++++++++++++++++++++
>  arch/arm/plat-omap/include/plat/prcm.h |    1 +
>  2 files changed, 51 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
> index 362c59c..cc92064 100644
> --- a/arch/arm/mach-omap2/prcm.c
> +++ b/arch/arm/mach-omap2/prcm.c
> @@ -53,6 +53,15 @@ static struct omap_prcm_irq *omap_prcm_irqs;
>  /* Number of entries in omap_prcm_irqs */
>  static int omap_prcm_irqs_nr;
>  
> +/* PAD handlers list */
> +struct pad_def {
> +	u32 pad;
> +	unsigned int irq;
> +	struct list_head node;
> +};
> +
> +static LIST_HEAD(pad_handler_list);
> +
>  /* Pointers to either OMAP3 or OMAP4 specific functions */
>  static void (*omap_prcm_mask_event)(unsigned event);
>  static void (*omap_prcm_unmask_event)(unsigned event);
> @@ -84,6 +93,25 @@ static struct irq_chip prcm_irq_chip = {
>  	.irq_unmask	= prcm_irq_unmask,
>  };
>  
> +
> +/*
> + * Handler for PAD irqs, called from PRCM interrupt handler
> + */
> +static void omap_prcm_handle_pad_irqs(void)
> +{
> +	struct pad_def *def;
> +	u16 val = 0;

minor: insert blank line between variables and code

> +	list_for_each_entry(def, &pad_handler_list, node) {
> +		/* Read padconf value based on cpu type */
> +		if (cpu_is_omap34xx())
> +			val = omap_ctrl_readw(def->pad);

We need to avoid cpu_is_* checks in driver code.

What we'll need is another control-module API for reading a padconf, and
the SoC-specific implementation can be managed by the control module code.

> +		/* if pad wakeupevent is active, fire registered IRQ */
> +		if (val & OMAP3_PADCONF_WAKEUPEVENT0)

Does this need to be masked with the wakeup enable?  IOW, is it possible
to find an pad with a masked wakeup event?  Might be worth double
checking the TRM on that one, but masking with the enable would not hurt
here.

> +			generic_handle_irq(def->irq);

Nice, I wish I thought of that!  I was trying to figure out how to SW
trigger a hard IRQ, but this is much better and doesn't rely on any
hardware feature.   Sometimes the simplest solution is the best. :)

> +	}
> +}
> +
>  /*
>   * PRCM Interrupt Handler
>   *
> @@ -106,6 +134,9 @@ static void prcm_irq_handler(unsigned int irq, struct irq_desc *desc)
>  	unsigned long pending[OMAP_PRCM_MAX_NR_PENDING_REG];
>  	struct irq_chip *chip = irq_desc_get_chip(desc);
>  
> +	/* Handle PAD events first, we don't want to ack them before parse */
> +	omap_prcm_handle_pad_irqs();
> +

Handling here is fine, but it's not terribly clear on first read where
the events are eventually cleared.  

I see now that they are cleared upon entry into the idle path, but I
think it would help readability if they were cleared after this handler
runs.

>  	/*
>  	 * Loop until all pending irqs are handled, since
>  	 * generic_handle_irq(), called by prcm_irq_handle_virtirqs()
> @@ -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.

This comment needs a minor change: technically, it's not the IRQ that is
triggered but the ISR for that IRQ will be called.

The same change should be made in the changelog.

> + */
> +int omap_prcm_register_pad_irq(u32 pad, unsigned int irq)
> +{
> +	struct pad_def *def;
> +
> +	def = kmalloc(sizeof(struct pad_def), GFP_ATOMIC);
> +	if (!def)
> +		return -ENOMEM;
> +
> +	def->pad = pad;
> +	def->irq = irq;
> +	list_add(&def->node, &pad_handler_list);
> +	return 0;
> +}

This wants an unregister counterpart.

> +/*
>   * Prepare the array of PRCM events corresponding to the current SoC,
>   * and set-up the chained interrupt handler mechanism.
>   */
> diff --git a/arch/arm/plat-omap/include/plat/prcm.h b/arch/arm/plat-omap/include/plat/prcm.h
> index 5785555..789eb17 100644
> --- a/arch/arm/plat-omap/include/plat/prcm.h
> +++ b/arch/arm/plat-omap/include/plat/prcm.h
> @@ -72,6 +72,7 @@ void omap4_prcm_pending_events(unsigned long *pending);
>  int omap_prcm_event_to_irq(const char *name);
>  int omap_prcm_irq_init(void);
>  void omap_prcm_irq_cleanup(void);
> +int omap_prcm_register_pad_irq(u32 pad, unsigned int irq);
>  u32 omap_prcm_get_reset_sources(void);
>  int omap2_cm_wait_idlest(void __iomem *reg, u32 mask, u8 idlest,
>  			 const char *name);

Kevin

  parent reply	other threads:[~2011-06-24 21:21 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
2011-06-24 21:21   ` Kevin Hilman [this message]
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=87fwmzylhf.fsf@ti.com \
    --to=khilman@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox