public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@linaro.org>
Cc: jgchunter@gmail.com, Santosh Shilimkar <santosh.shilimkar@ti.com>,
	Kevin Hilman <khilman@linaro.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	eballetbo@gmail.com, thomas.petazzoni@free-electrons.com,
	linux-omap@vger.kernel.org,
	Florian Vaussard <florian.vaussard@epfl.ch>,
	Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Subject: Re: [PATCH v2 1/2] gpio/omap: don't create an IRQ mapping for every GPIO on DT
Date: Mon, 24 Jun 2013 13:53:47 +0100	[thread overview]
Message-ID: <20130624125347.43AE73E0A89@localhost> (raw)
In-Reply-To: <1371855054-27958-2-git-send-email-javier.martinez@collabora.co.uk>

On Sat, 22 Jun 2013 00:50:53 +0200, Javier Martinez Canillas <javier.martinez@collabora.co.uk> wrote:
> When a GPIO is defined as an interrupt line using Device
> Tree, a call to irq_create_of_mapping() is made that calls
> irq_create_mapping(). So, is not necessary to do the mapping
> on the OMAP GPIO platform_driver and in fact is wrong to
> assume that all GPIO lines will be used as an IRQ.
> 
> Add a custom IRQ domain .map function handler that will be
> called by the IRQ core to map only the GPIO lines used as
> IRQ. This also allows to execute needed setup code such as
> configuring a GPIO as input and enabling the GPIO bank.
> 
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
> 
> Changes since v1:
>   - Split the addition of the .map function handler and the
>     automatic gpio request in two different patches.
>   - Add GPIO IRQ setup logic to the irq domain mapping function.
>   - Only call irq_create_mapping for every GPIO on legacy boot.
>   - Only setup a GPIO IRQ on the .map function for DeviceTree boot.
> 
>  drivers/gpio/gpio-omap.c |   52 ++++++++++++++++++++++++++++++++++++---------
>  1 files changed, 41 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index d3f7d2d..31cbe65 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1068,16 +1068,18 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
>  
>  	gpiochip_add(&bank->chip);
>  
> -	for (j = 0; j < bank->width; j++) {
> -		int irq = irq_create_mapping(bank->domain, j);
> -		irq_set_lockdep_class(irq, &gpio_lock_class);
> -		irq_set_chip_data(irq, bank);
> -		if (bank->is_mpuio) {
> -			omap_mpuio_alloc_gc(bank, irq, bank->width);
> -		} else {
> -			irq_set_chip_and_handler(irq, &gpio_irq_chip,
> -						 handle_simple_irq);
> -			set_irq_flags(irq, IRQF_VALID);
> +	if (!of_have_populated_dt()) {
> +		for (j = 0; j < bank->width; j++) {
> +			int irq = irq_create_mapping(bank->domain, j);
> +			irq_set_lockdep_class(irq, &gpio_lock_class);
> +			irq_set_chip_data(irq, bank);
> +			if (bank->is_mpuio) {
> +				omap_mpuio_alloc_gc(bank, irq, bank->width);
> +			} else {
> +				irq_set_chip_and_handler(irq, &gpio_irq_chip,
> +							 handle_simple_irq);
> +				set_irq_flags(irq, IRQF_VALID);
> +			}
>  		}
>  	}
>  	irq_set_chained_handler(bank->irq, gpio_irq_handler);
> @@ -1086,6 +1088,34 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
>  
>  static const struct of_device_id omap_gpio_match[];
>  
> +static int omap_gpio_irq_map(struct irq_domain *d, unsigned int virq,
> +			     irq_hw_number_t hwirq)
> +{
> +	struct gpio_bank *bank = d->host_data;
> +
> +	if (!bank)
> +		return -EINVAL;
> +
> +	if (of_have_populated_dt()) {
> +		irq_set_lockdep_class(virq, &gpio_lock_class);
> +		irq_set_chip_data(virq, bank);
> +		if (bank->is_mpuio) {
> +			omap_mpuio_alloc_gc(bank, virq, bank->width);
> +		} else {
> +			irq_set_chip_and_handler(virq, &gpio_irq_chip,
> +						 handle_simple_irq);
> +			set_irq_flags(virq, IRQF_VALID);
> +		}
> +	}

Actually, this looks wrong. You'll notice that the same block of code is
now duplicated in the map function and outside the map. The problem is
that the original code is manually walking through all the irqs and
doing the mapping work, but all of that stuff is what the .map() hook is
for!

Instead, the entire of the above block should be executed
unconditionally inside the map hook. In the DT case, it will get called
automatically only on referenced irqs. In the non-DT case, the for loop
in omap_gpio_chip_init() will only need to call irq_create_mapping() for
each irq, which in turn will call ->map().

g.

> +
> +	return 0;
> +}
> +
> +static struct irq_domain_ops omap_gpio_irq_ops = {
> +	.xlate  = irq_domain_xlate_onetwocell,
> +	.map    = omap_gpio_irq_map,
> +};
> +
>  static int omap_gpio_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
> @@ -1137,7 +1167,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
>  
>  
>  	bank->domain = irq_domain_add_linear(node, bank->width,
> -					     &irq_domain_simple_ops, NULL);
> +					     &omap_gpio_irq_ops, bank);
>  	if (!bank->domain)
>  		return -ENODEV;
>  
> -- 
> 1.7.7.6
> 

-- 
email sent from notmuch.vim plugin

  reply	other threads:[~2013-06-24 12:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <[PATCH v2 0/2]: auto request GPIO as input if used as IRQ via DT>
2013-06-21 22:50 ` (unknown), Javier Martinez Canillas
2013-06-21 22:50   ` [PATCH v2 1/2] gpio/omap: don't create an IRQ mapping for every GPIO on DT Javier Martinez Canillas
2013-06-24 12:53     ` Grant Likely [this message]
2013-06-21 22:50   ` [PATCH v2 2/2] gpio/omap: auto request GPIO as input if used as IRQ via DT Javier Martinez Canillas
2013-06-24 12:55     ` Grant Likely
2013-06-24 13:58       ` Javier Martinez Canillas

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=20130624125347.43AE73E0A89@localhost \
    --to=grant.likely@linaro.org \
    --cc=eballetbo@gmail.com \
    --cc=florian.vaussard@epfl.ch \
    --cc=javier.martinez@collabora.co.uk \
    --cc=jgchunter@gmail.com \
    --cc=khilman@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=plagnioj@jcrosoft.com \
    --cc=santosh.shilimkar@ti.com \
    --cc=thomas.petazzoni@free-electrons.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