Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1700711 > unrolled thread

Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically Linus Walleij <linus.walleij@linaro.org> - 2017-08-01 10:00 +0200
    Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs  dynamically Jerome Brunet <jbrunet@baylibre.com> - 2017-08-01 10:10 +0200
      Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs  dynamically Grygorii Strashko <grygorii.strashko@ti.com> - 2017-08-01 20:30 +0200
    Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically Bartosz Golaszewski <brgl@bgdev.pl> - 2017-08-01 12:00 +0200

#1700711 — Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically

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).
>
> Hence, remove static IRQ mapping code from gpiochip_irqchip_add_key() and
> instead replace irq_find_mapping() with irq_create_mapping() in
> gpiochip_to_irq(). Also add additional gpiochip_irqchip_irq_valid() calls
> in gpiochip_to_irq() and gpiochip_irq_map().
>
> After this change gpio2irq mapping will happen the following way when GPIO
> irqchip APIs are used by gpio driver:
>  - IRQ mappings will be created statically if driver passes first_irq>0
> vlaue in gpiochip_irqchip_add_key().
>  - IRQ mappings will be created dynamically from gpio_to_irq() or
> of_irq_get().
>
> Tested on am335x-evm and dra72-evm-revc.
> - dra72-evm-revc: number of created irq mappings decreased from 402 -> 135
>   Mem savings 267*256 = 68352 (66kB)
> - am335x-evm: number of created irq mappings decreased from 188 -> 63
>   Mem savings 125*256 = 32000 (31kB)
>
> [1] https://lkml.org/lkml/2017/6/15/428
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> ---
> Changes in v2:
> - restored struct gpio_chip->irq_base to fix buld of gpio-mockup.c

Applied this rather than v1.

But maybe we should get rid of ->irq_base from gpio-mockup.c
and delete it, as the base is irqchip-internal.

Bartosz what do you say? Do we need this in the mockup?

Yours,
Linus Walleij

[toc] | [next] | [standalone]

#1700717 — Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically

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 ?

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

> > 
> > Hence, remove static IRQ mapping code from gpiochip_irqchip_add_key() and
> > instead replace irq_find_mapping() with irq_create_mapping() in
> > gpiochip_to_irq(). Also add additional gpiochip_irqchip_irq_valid() calls
> > in gpiochip_to_irq() and gpiochip_irq_map().
> > 
> > After this change gpio2irq mapping will happen the following way when GPIO
> > irqchip APIs are used by gpio driver:
> >  - IRQ mappings will be created statically if driver passes first_irq>0
> > vlaue in gpiochip_irqchip_add_key().
> >  - IRQ mappings will be created dynamically from gpio_to_irq() or
> > of_irq_get().
> > 
> > Tested on am335x-evm and dra72-evm-revc.
> > - dra72-evm-revc: number of created irq mappings decreased from 402 -> 135
> >   Mem savings 267*256 = 68352 (66kB)
> > - am335x-evm: number of created irq mappings decreased from 188 -> 63
> >   Mem savings 125*256 = 32000 (31kB)
> > 
> > [1] https://lkml.org/lkml/2017/6/15/428
> > Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> > ---
> > Changes in v2:
> > - restored struct gpio_chip->irq_base to fix buld of gpio-mockup.c
> 
> Applied this rather than v1.
> 
> But maybe we should get rid of ->irq_base from gpio-mockup.c
> and delete it, as the base is irqchip-internal.
> 
> Bartosz what do you say? Do we need this in the mockup?
> 
> Yours,
> Linus Walleij

[toc] | [prev] | [next] | [standalone]

#1701331 — Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically

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

[toc] | [prev] | [next] | [standalone]

#1700797

2017-08-01 9:52 GMT+02:00 Linus Walleij <linus.walleij@linaro.org>:
>
> Applied this rather than v1.
>
> But maybe we should get rid of ->irq_base from gpio-mockup.c
> and delete it, as the base is irqchip-internal.
>
> Bartosz what do you say? Do we need this in the mockup?
>
> Yours,
> Linus Walleij

Hi Linus,

a while ago I submitted a series[1] adding a simple framework for
simulating interrupts with the intention of removing most of the
irq_work code from gpio-mockup and iio-dummy-evgen. The third patch in
that series[2] does that for the mockup driver. I'll send a v2 shortly
and I hope to get it merged for v4.14.

Best regards,
Bartosz Golaszewski

[1] https://lkml.org/lkml/2017/7/19/698
[2] https://lkml.org/lkml/2017/7/19/696

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web