All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
@ 2017-07-21 16:49 ` Grygorii Strashko
  0 siblings, 0 replies; 17+ messages in thread
From: Grygorii Strashko @ 2017-07-21 16:49 UTC (permalink / raw)
  To: Linus Walleij, linux-gpio; +Cc: linux-kernel, Jerome Brunet, Grygorii Strashko

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
Link on v1:
- https://patchwork.kernel.org/patch/9831565/

 drivers/gpio/gpiolib.c | 29 ++++++-----------------------
 1 file changed, 6 insertions(+), 23 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 9568708..ee6ba07 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1605,6 +1605,9 @@ static int gpiochip_irq_map(struct irq_domain *d, unsigned int irq,
 {
 	struct gpio_chip *chip = d->host_data;
 
+	if (!gpiochip_irqchip_irq_valid(chip, hwirq))
+		return -ENXIO;
+
 	irq_set_chip_data(irq, chip);
 	/*
 	 * This lock class tells lockdep that GPIO irqs are in a different
@@ -1671,7 +1674,9 @@ static void gpiochip_irq_relres(struct irq_data *d)
 
 static int gpiochip_to_irq(struct gpio_chip *chip, unsigned offset)
 {
-	return irq_find_mapping(chip->irqdomain, offset);
+	if (!gpiochip_irqchip_irq_valid(chip, offset))
+		return -ENXIO;
+	return irq_create_mapping(chip->irqdomain, offset);
 }
 
 /**
@@ -1747,9 +1752,6 @@ int gpiochip_irqchip_add_key(struct gpio_chip *gpiochip,
 			     struct lock_class_key *lock_key)
 {
 	struct device_node *of_node;
-	bool irq_base_set = false;
-	unsigned int offset;
-	unsigned irq_base = 0;
 
 	if (!gpiochip || !irqchip)
 		return -EINVAL;
@@ -1806,25 +1808,6 @@ int gpiochip_irqchip_add_key(struct gpio_chip *gpiochip,
 		irqchip->irq_release_resources = gpiochip_irq_relres;
 	}
 
-	/*
-	 * Prepare the mapping since the irqchip shall be orthogonal to
-	 * any gpiochip calls. If the first_irq was zero, this is
-	 * necessary to allocate descriptors for all IRQs.
-	 */
-	for (offset = 0; offset < gpiochip->ngpio; offset++) {
-		if (!gpiochip_irqchip_irq_valid(gpiochip, offset))
-			continue;
-		irq_base = irq_create_mapping(gpiochip->irqdomain, offset);
-		if (!irq_base_set) {
-			/*
-			 * Store the base into the gpiochip to be used when
-			 * unmapping the irqs.
-			 */
-			gpiochip->irq_base = irq_base;
-			irq_base_set = true;
-		}
-	}
-
 	acpi_gpiochip_request_interrupts(gpiochip);
 
 	return 0;
-- 
2.10.1

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
@ 2017-07-21 16:49 ` Grygorii Strashko
  0 siblings, 0 replies; 17+ messages in thread
From: Grygorii Strashko @ 2017-07-21 16:49 UTC (permalink / raw)
  To: Linus Walleij, linux-gpio; +Cc: linux-kernel, Jerome Brunet, Grygorii Strashko

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
Link on v1:
- https://patchwork.kernel.org/patch/9831565/

 drivers/gpio/gpiolib.c | 29 ++++++-----------------------
 1 file changed, 6 insertions(+), 23 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 9568708..ee6ba07 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1605,6 +1605,9 @@ static int gpiochip_irq_map(struct irq_domain *d, unsigned int irq,
 {
 	struct gpio_chip *chip = d->host_data;
 
+	if (!gpiochip_irqchip_irq_valid(chip, hwirq))
+		return -ENXIO;
+
 	irq_set_chip_data(irq, chip);
 	/*
 	 * This lock class tells lockdep that GPIO irqs are in a different
@@ -1671,7 +1674,9 @@ static void gpiochip_irq_relres(struct irq_data *d)
 
 static int gpiochip_to_irq(struct gpio_chip *chip, unsigned offset)
 {
-	return irq_find_mapping(chip->irqdomain, offset);
+	if (!gpiochip_irqchip_irq_valid(chip, offset))
+		return -ENXIO;
+	return irq_create_mapping(chip->irqdomain, offset);
 }
 
 /**
@@ -1747,9 +1752,6 @@ int gpiochip_irqchip_add_key(struct gpio_chip *gpiochip,
 			     struct lock_class_key *lock_key)
 {
 	struct device_node *of_node;
-	bool irq_base_set = false;
-	unsigned int offset;
-	unsigned irq_base = 0;
 
 	if (!gpiochip || !irqchip)
 		return -EINVAL;
@@ -1806,25 +1808,6 @@ int gpiochip_irqchip_add_key(struct gpio_chip *gpiochip,
 		irqchip->irq_release_resources = gpiochip_irq_relres;
 	}
 
-	/*
-	 * Prepare the mapping since the irqchip shall be orthogonal to
-	 * any gpiochip calls. If the first_irq was zero, this is
-	 * necessary to allocate descriptors for all IRQs.
-	 */
-	for (offset = 0; offset < gpiochip->ngpio; offset++) {
-		if (!gpiochip_irqchip_irq_valid(gpiochip, offset))
-			continue;
-		irq_base = irq_create_mapping(gpiochip->irqdomain, offset);
-		if (!irq_base_set) {
-			/*
-			 * Store the base into the gpiochip to be used when
-			 * unmapping the irqs.
-			 */
-			gpiochip->irq_base = irq_base;
-			irq_base_set = true;
-		}
-	}
-
 	acpi_gpiochip_request_interrupts(gpiochip);
 
 	return 0;
-- 
2.10.1

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
  2017-07-21 16:49 ` Grygorii Strashko
  (?)
@ 2017-08-01  7:52 ` Linus Walleij
  2017-08-01  8:03   ` Jerome Brunet
  2017-08-01  9:53   ` Bartosz Golaszewski
  -1 siblings, 2 replies; 17+ messages in thread
From: Linus Walleij @ 2017-08-01  7:52 UTC (permalink / raw)
  To: Grygorii Strashko, Bartosz Golaszewski
  Cc: linux-gpio, linux-kernel, Jerome Brunet

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
  2017-08-01  7:52 ` Linus Walleij
@ 2017-08-01  8:03   ` Jerome Brunet
  2017-08-01 18:27     ` Grygorii Strashko
  2017-08-01  9:53   ` Bartosz Golaszewski
  1 sibling, 1 reply; 17+ messages in thread
From: Jerome Brunet @ 2017-08-01  8:03 UTC (permalink / raw)
  To: Linus Walleij, Grygorii Strashko, Bartosz Golaszewski
  Cc: linux-gpio, linux-kernel

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
  2017-08-01  7:52 ` Linus Walleij
  2017-08-01  8:03   ` Jerome Brunet
@ 2017-08-01  9:53   ` Bartosz Golaszewski
  1 sibling, 0 replies; 17+ messages in thread
From: Bartosz Golaszewski @ 2017-08-01  9:53 UTC (permalink / raw)
  To: Linus Walleij; +Cc: Grygorii Strashko, linux-gpio, linux-kernel, Jerome Brunet

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
  2017-08-01  8:03   ` Jerome Brunet
@ 2017-08-01 18:27     ` Grygorii Strashko
  2017-09-15  8:26       ` Jerome Brunet
  0 siblings, 1 reply; 17+ messages in thread
From: Grygorii Strashko @ 2017-08-01 18:27 UTC (permalink / raw)
  To: Jerome Brunet, Linus Walleij, Bartosz Golaszewski
  Cc: linux-gpio, linux-kernel



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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
  2017-08-01 18:27     ` Grygorii Strashko
@ 2017-09-15  8:26       ` Jerome Brunet
  2017-09-21 11:41         ` Linus Walleij
  0 siblings, 1 reply; 17+ messages in thread
From: Jerome Brunet @ 2017-09-15  8:26 UTC (permalink / raw)
  To: Grygorii Strashko, Linus Walleij, Bartosz Golaszewski
  Cc: linux-gpio, linux-kernel

On Tue, 2017-08-01 at 13:27 -0500, Grygorii Strashko wrote:
> 
> 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.

You're right. It took me a while to realise there is a (serious) flaw in my plan
 :( Thanks for pointing it out Grygorii.

I initially planned to do some refcounting in the gpio layer but that would make
no sense, as you pointed out, the irq could be shared. This refcounting would
only make sense at the irq level.

On a more general note, I wonder when is it safe for a driver to dispose of the
mapping of a possibly shared irq ? There is no way to know if the mapping is
still used somewhere else, or am I missing something again ?

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
  2017-09-15  8:26       ` Jerome Brunet
@ 2017-09-21 11:41         ` Linus Walleij
  2017-10-05 10:59           ` Marc Zyngier
  0 siblings, 1 reply; 17+ messages in thread
From: Linus Walleij @ 2017-09-21 11:41 UTC (permalink / raw)
  To: Jerome Brunet, Marc Zyngier, Rob Herring
  Cc: Grygorii Strashko, Bartosz Golaszewski, linux-gpio, linux-kernel

On Fri, Sep 15, 2017 at 10:26 AM, Jerome Brunet <jbrunet@baylibre.com> wrote:

> I initially planned to do some refcounting in the gpio layer but that would make
> no sense, as you pointed out, the irq could be shared. This refcounting would
> only make sense at the irq level.
>
> On a more general note, I wonder when is it safe for a driver to dispose of the
> mapping of a possibly shared irq ? There is no way to know if the mapping is
> still used somewhere else, or am I missing something again ?

I have no idea, but maybe Marc Z or Rob H knows this?

They usually have a bit of deeper IRQ-centric knowledge.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
  2017-07-21 16:49 ` Grygorii Strashko
  (?)
  (?)
@ 2017-09-28  8:33 ` Mika Westerberg
  2017-09-28 14:02     ` Grygorii Strashko
  2017-10-08  0:27   ` Linus Walleij
  -1 siblings, 2 replies; 17+ messages in thread
From: Mika Westerberg @ 2017-09-28  8:33 UTC (permalink / raw)
  To: Grygorii Strashko
  Cc: Linus Walleij, linux-gpio, linux-kernel, Jerome Brunet, chrisjohgorman

On Fri, Jul 21, 2017 at 11:49:00AM -0500, Grygorii Strashko 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>

Hi Grygorii,

It looks like dc749a09ea5e41 ("gpiolib: allow gpio irqchip to map irqs
dynamically") broke the quirk we added for some Intel Cherryview
systems [1]. Basically after this keyboard of those systems stopped
working again.

Any idea what might be wrong?

I've CC'd Chris Gorman who reported the issue.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=194945

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
  2017-09-28  8:33 ` Mika Westerberg
@ 2017-09-28 14:02     ` Grygorii Strashko
  2017-10-08  0:27   ` Linus Walleij
  1 sibling, 0 replies; 17+ messages in thread
From: Grygorii Strashko @ 2017-09-28 14:02 UTC (permalink / raw)
  To: Mika Westerberg
  Cc: Linus Walleij, linux-gpio, linux-kernel, Jerome Brunet, chrisjohgorman



On 09/28/2017 03:33 AM, Mika Westerberg wrote:
> On Fri, Jul 21, 2017 at 11:49:00AM -0500, Grygorii Strashko 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>
> 
> Hi Grygorii,
> 
> It looks like dc749a09ea5e41 ("gpiolib: allow gpio irqchip to map irqs
> dynamically") broke the quirk we added for some Intel Cherryview
> systems [1]. Basically after this keyboard of those systems stopped
> working again.
> 
> Any idea what might be wrong?

Yes. kernel do not map all GPIO IRQs by default now.
I've red related discussion and, as per my understanding (correct me if i'm wrong),
on this platform all GPIO IRQs have to be mapped on fixed range of Linux IRQs.
In this case, It's reasonable to specify first_irq parameter in gpiochip_irqchip_add()
which should force IRQ mapping creation.

> 
> I've CC'd Chris Gorman who reported the issue.
> 
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=194945
> 



-- 
regards,
-grygorii

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
@ 2017-09-28 14:02     ` Grygorii Strashko
  0 siblings, 0 replies; 17+ messages in thread
From: Grygorii Strashko @ 2017-09-28 14:02 UTC (permalink / raw)
  To: Mika Westerberg
  Cc: Linus Walleij, linux-gpio, linux-kernel, Jerome Brunet, chrisjohgorman



On 09/28/2017 03:33 AM, Mika Westerberg wrote:
> On Fri, Jul 21, 2017 at 11:49:00AM -0500, Grygorii Strashko 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>
> 
> Hi Grygorii,
> 
> It looks like dc749a09ea5e41 ("gpiolib: allow gpio irqchip to map irqs
> dynamically") broke the quirk we added for some Intel Cherryview
> systems [1]. Basically after this keyboard of those systems stopped
> working again.
> 
> Any idea what might be wrong?

Yes. kernel do not map all GPIO IRQs by default now.
I've red related discussion and, as per my understanding (correct me if i'm wrong),
on this platform all GPIO IRQs have to be mapped on fixed range of Linux IRQs.
In this case, It's reasonable to specify first_irq parameter in gpiochip_irqchip_add()
which should force IRQ mapping creation.

> 
> I've CC'd Chris Gorman who reported the issue.
> 
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=194945
> 



-- 
regards,
-grygorii

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
  2017-09-28 14:02     ` Grygorii Strashko
  (?)
@ 2017-09-28 14:26     ` Mika Westerberg
  -1 siblings, 0 replies; 17+ messages in thread
From: Mika Westerberg @ 2017-09-28 14:26 UTC (permalink / raw)
  To: Grygorii Strashko
  Cc: Linus Walleij, linux-gpio, linux-kernel, Jerome Brunet, chrisjohgorman

On Thu, Sep 28, 2017 at 09:02:12AM -0500, Grygorii Strashko wrote:
> 
> 
> On 09/28/2017 03:33 AM, Mika Westerberg wrote:
> > On Fri, Jul 21, 2017 at 11:49:00AM -0500, Grygorii Strashko 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>
> > 
> > Hi Grygorii,
> > 
> > It looks like dc749a09ea5e41 ("gpiolib: allow gpio irqchip to map irqs
> > dynamically") broke the quirk we added for some Intel Cherryview
> > systems [1]. Basically after this keyboard of those systems stopped
> > working again.
> > 
> > Any idea what might be wrong?
> 
> Yes. kernel do not map all GPIO IRQs by default now.
> I've red related discussion and, as per my understanding (correct me if i'm wrong),
> on this platform all GPIO IRQs have to be mapped on fixed range of Linux IRQs.
> In this case, It's reasonable to specify first_irq parameter in gpiochip_irqchip_add()
> which should force IRQ mapping creation.

So can you propose what value I should pass then? It was working just
fine until this change.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
  2017-09-21 11:41         ` Linus Walleij
@ 2017-10-05 10:59           ` Marc Zyngier
  0 siblings, 0 replies; 17+ messages in thread
From: Marc Zyngier @ 2017-10-05 10:59 UTC (permalink / raw)
  To: Linus Walleij, Jerome Brunet, Rob Herring
  Cc: Grygorii Strashko, Bartosz Golaszewski, linux-gpio, linux-kernel

On 21/09/17 12:41, Linus Walleij wrote:
> On Fri, Sep 15, 2017 at 10:26 AM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> 
>> I initially planned to do some refcounting in the gpio layer but that would make
>> no sense, as you pointed out, the irq could be shared. This refcounting would
>> only make sense at the irq level.
>>
>> On a more general note, I wonder when is it safe for a driver to dispose of the
>> mapping of a possibly shared irq ? There is no way to know if the mapping is
>> still used somewhere else, or am I missing something again ?
> 
> I have no idea, but maybe Marc Z or Rob H knows this?
> 
> They usually have a bit of deeper IRQ-centric knowledge.
Unfortunately, there is no such thing. I contemplated tracking this at
some point, and got sidetracked. In general, the irq domain and irq core
are horribly disconnected, leading to that exact line of questioning.

	M.
-- 
Jazz is not dead. It just smells funny...

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
  2017-09-28  8:33 ` Mika Westerberg
  2017-09-28 14:02     ` Grygorii Strashko
@ 2017-10-08  0:27   ` Linus Walleij
  2017-10-09 18:10     ` Grygorii Strashko
  1 sibling, 1 reply; 17+ messages in thread
From: Linus Walleij @ 2017-10-08  0:27 UTC (permalink / raw)
  To: Mika Westerberg
  Cc: Grygorii Strashko, linux-gpio, linux-kernel, Jerome Brunet, Chris Gorman

On Thu, Sep 28, 2017 at 10:33 AM, Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
> On Fri, Jul 21, 2017 at 11:49:00AM -0500, Grygorii Strashko 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>
>
> Hi Grygorii,
>
> It looks like dc749a09ea5e41 ("gpiolib: allow gpio irqchip to map irqs
> dynamically") broke the quirk we added for some Intel Cherryview
> systems [1]. Basically after this keyboard of those systems stopped
> working again.

It seems like we need to revert this change.

I have also noted the following:

-       /*
-        * Prepare the mapping since the irqchip shall be orthogonal to
-        * any gpiochip calls. If the first_irq was zero, this is
-        * necessary to allocate descriptors for all IRQs.
-        */
-       for (offset = 0; offset < gpiochip->ngpio; offset++) {
-               if (!gpiochip_irqchip_irq_valid(gpiochip, offset))
-                       continue;
-               irq_base = irq_create_mapping(gpiochip->irqdomain, offset);
-               if (!irq_base_set) {
-                       /*
-                        * Store the base into the gpiochip to be used when
-                        * unmapping the irqs.
-                        */
-                       gpiochip->irq_base = irq_base;
-                       irq_base_set = true;
-               }

Note assignment of gpiochip->irq_base.

A whole slew of drivers use this.

We cannot merge a change like this without also fixing all the users
of .irq_base, as it will cause regressions on them.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
  2017-10-08  0:27   ` Linus Walleij
@ 2017-10-09 18:10     ` Grygorii Strashko
  2017-10-09 19:57       ` Linus Walleij
  0 siblings, 1 reply; 17+ messages in thread
From: Grygorii Strashko @ 2017-10-09 18:10 UTC (permalink / raw)
  To: Linus Walleij, Mika Westerberg
  Cc: linux-gpio, linux-kernel, Jerome Brunet, Chris Gorman



On 10/07/2017 07:27 PM, Linus Walleij wrote:
> On Thu, Sep 28, 2017 at 10:33 AM, Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
>> On Fri, Jul 21, 2017 at 11:49:00AM -0500, Grygorii Strashko 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>
>>
>> Hi Grygorii,
>>
>> It looks like dc749a09ea5e41 ("gpiolib: allow gpio irqchip to map irqs
>> dynamically") broke the quirk we added for some Intel Cherryview
>> systems [1]. Basically after this keyboard of those systems stopped
>> working again.
> 
> It seems like we need to revert this change.
> 
> I have also noted the following:
> 
> -       /*
> -        * Prepare the mapping since the irqchip shall be orthogonal to
> -        * any gpiochip calls. If the first_irq was zero, this is
> -        * necessary to allocate descriptors for all IRQs.
> -        */
> -       for (offset = 0; offset < gpiochip->ngpio; offset++) {
> -               if (!gpiochip_irqchip_irq_valid(gpiochip, offset))
> -                       continue;
> -               irq_base = irq_create_mapping(gpiochip->irqdomain, offset);
> -               if (!irq_base_set) {
> -                       /*
> -                        * Store the base into the gpiochip to be used when
> -                        * unmapping the irqs.
> -                        */
> -                       gpiochip->irq_base = irq_base;
> -                       irq_base_set = true;
> -               }
> 
> Note assignment of gpiochip->irq_base.
> 
> A whole slew of drivers use this.
> 
> We cannot merge a change like this without also fixing all the users
> of .irq_base, as it will cause regressions on them.

At the moment it was merged there were no user of irq_base except gpio-mockup.c.
And actually there are shouldn't as calling irq_create_mapping() in cycle
will not guarantee sequential Linux IRQ numbers allocation.



-- 
regards,
-grygorii

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
  2017-10-09 18:10     ` Grygorii Strashko
@ 2017-10-09 19:57       ` Linus Walleij
  2017-10-09 22:17         ` Grygorii Strashko
  0 siblings, 1 reply; 17+ messages in thread
From: Linus Walleij @ 2017-10-09 19:57 UTC (permalink / raw)
  To: Grygorii Strashko
  Cc: Mika Westerberg, linux-gpio, linux-kernel, Jerome Brunet, Chris Gorman

On Mon, Oct 9, 2017 at 8:10 PM, Grygorii Strashko
<grygorii.strashko@ti.com> wrote:

> At the moment it was merged there were no user of irq_base except gpio-mockup.c.

OK I feel calmer.

> And actually there are shouldn't as calling irq_create_mapping() in cycle
> will not guarantee sequential Linux IRQ numbers allocation.

Yeah. I always felt that was bad practice.

But we should really kill off that irq_base member from gpio_chip. It looks
dangerous to have arond.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically
  2017-10-09 19:57       ` Linus Walleij
@ 2017-10-09 22:17         ` Grygorii Strashko
  0 siblings, 0 replies; 17+ messages in thread
From: Grygorii Strashko @ 2017-10-09 22:17 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Mika Westerberg, linux-gpio, linux-kernel, Jerome Brunet, Chris Gorman



On 10/09/2017 02:57 PM, Linus Walleij wrote:
> On Mon, Oct 9, 2017 at 8:10 PM, Grygorii Strashko
> <grygorii.strashko@ti.com> wrote:
> 
>> At the moment it was merged there were no user of irq_base except gpio-mockup.c.
> 
> OK I feel calmer.
> 
>> And actually there are shouldn't as calling irq_create_mapping() in cycle
>> will not guarantee sequential Linux IRQ numbers allocation.
> 
> Yeah. I always felt that was bad practice.
> 
> But we should really kill off that irq_base member from gpio_chip. It looks
> dangerous to have arond.

patch posted.

-- 
regards,
-grygorii

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2017-10-09 22:17 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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.