All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Jerome Brunet <jbrunet@baylibre.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>
Cc: "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
Date: Tue, 1 Aug 2017 13:27:18 -0500	[thread overview]
Message-ID: <835101ba-e5d5-fd5e-e0c2-06001d02f850@ti.com> (raw)
In-Reply-To: <1501574614.2759.9.camel@baylibre.com>



On 08/01/2017 03:03 AM, Jerome Brunet wrote:
> On Tue, 2017-08-01 at 09:52 +0200, Linus Walleij wrote:
>> On Fri, Jul 21, 2017 at 6:49 PM, Grygorii Strashko
>> <grygorii.strashko@ti.com> wrote:
>>
>>> Now IRQ mappings are always created for all (allowed) GPIOs in gpiochip in
>>> gpiochip_irqchip_add_key() which goes against the idea of SPARSE_IRQ and,
>>> as result, leads to:
>>>   - increasing of memory consumption for IRQ descriptors most of which will
>>> never ever be used (espessially on platform with a high number of GPIOs).
>>> (sizeof(struct irq_desc) == 256 on my tested platforms)
>>>   - imposibility to use GPIO irqchip APIs by gpio drivers when HW implements
>>> GPIO IRQ functionality as IRQ crossbar/router which has only limited
>>> number of IRQ outputs (example from [1], all GPIOs can be mapped on only 8
>>> IRQs).
> 
> Sorry, I forgot to reply to this thread until now.
> This patch is generalization of create mapping in the gpio_to_irq, right ?
> 
> So the issue of mapping left lying around until the gpio driver is unloaded is
> still there ?

Yep. But this should unblock you work and allow to use static boot time IRQ
mappings (if you'll be able to implement irq_domain hierarchy properly). 

> 
> Having gpio_irq_prepare/gpio_irq_unprepare would solve that, I suppose
> (Again, sorry I could not send an RFC for this yet ...)

Sry, but still do not see how it will work :( But hope you might find the way :) 
Few notes to take into account:

There is no way now to know when you can release mappings and when it's safe to do :(,
except when gpio driver is unloaded.

1) drivers using GPIO IRQ directly (no gpio_to_irq() calls). IRQ can be shared.
IRQ mappings will happen in platform_get_irq()/of_irq_get().
Drivers may call request_irq/free_irq() many times using the same Linux IRQ number.
Such drivers, in many cases, do not expect to call any kind of GPIO APIs.

2) drivers using GPIO as IRQ (gpio_to_irq() calls).
IRQ mappings will happen in gpio_to_irq(). Theoretically driver can call
some API to dispose mappings as it knows when its safe to do, but...
The same IRQ still can be used by another driver as shared IRQ.

Note. IRQ mappings have no refcount.

Regarding, your use case - MMC issue can be WA using irq_valid_mask.
(don't blame me it's just WA).

-- 
regards,
-grygorii

  reply	other threads:[~2017-08-01 18:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-21 16:49 [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically Grygorii Strashko
2017-07-21 16:49 ` Grygorii Strashko
2017-08-01  7:52 ` Linus Walleij
2017-08-01  8:03   ` Jerome Brunet
2017-08-01 18:27     ` Grygorii Strashko [this message]
2017-09-15  8:26       ` Jerome Brunet
2017-09-21 11:41         ` Linus Walleij
2017-10-05 10:59           ` Marc Zyngier
2017-08-01  9:53   ` Bartosz Golaszewski
2017-09-28  8:33 ` Mika Westerberg
2017-09-28 14:02   ` Grygorii Strashko
2017-09-28 14:02     ` Grygorii Strashko
2017-09-28 14:26     ` Mika Westerberg
2017-10-08  0:27   ` Linus Walleij
2017-10-09 18:10     ` Grygorii Strashko
2017-10-09 19:57       ` Linus Walleij
2017-10-09 22:17         ` Grygorii Strashko

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=835101ba-e5d5-fd5e-e0c2-06001d02f850@ti.com \
    --to=grygorii.strashko@ti.com \
    --cc=brgl@bgdev.pl \
    --cc=jbrunet@baylibre.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.