Status of Meson GPIO IRQ support

Status of Meson GPIO IRQ support

[Heiner Kallweit]

Jerome,

when working on Meson I2C driver I was testing with a device where I wanted
to use a GPIO as interrupt source.
This isn't supported yet and when checking I found that end of last year
you submitted related patches. After some intense discussions I found no
further update.
Was this topic put on-hold due to bigger technical issues?

Rgds, Heiner

Status of Meson GPIO IRQ support

[Jerome Brunet]

On Tue, 2017-03-14 at 21:41 +0100, Heiner Kallweit wrote:
> Jerome,
> 
> when working on Meson I2C driver I was testing with a device where I wanted
> to use a GPIO as interrupt source.
> This isn't supported yet and when checking I found that end of last year
> you submitted related patches. After some intense discussions I found no
> further update.
> Was this topic put on-hold due to bigger technical issues?
> 

Well, the proposed code does work but, as you have probaly seen for yourself,
the maintainers of irqchip and gpio raised valid concerns, mainly about the way
the mapping is created in the gpio driver. Ideally, the mapping should be
created at probe time but, with a hierarchic interrupt domain, that means
allocating the parent irq. We only have 8 of those for 100+ gpios.?

I'm still not sure how to address the problem to be honest: Is there a way to
create mapping in hierarchy domain and allocate the parent only when the irq is
actually requested ? Or should we simply not use a hierarchy domain for this
controller (which seems to make sense) ?

I still hope to be able to do something on this topic but probably not tomorrow
:( Of course, If you have some spare time and want to contribute on this topic,
you are welcome to do so.

> Rgds, Heiner

Cheers

Jerome

Status of Meson GPIO IRQ support

[Heiner Kallweit]

Am 15.03.2017 um 08:50 schrieb Jerome Brunet:
> On Tue, 2017-03-14 at 21:41 +0100, Heiner Kallweit wrote:
>> Jerome,
>>
>> when working on Meson I2C driver I was testing with a device where I wanted
>> to use a GPIO as interrupt source.
>> This isn't supported yet and when checking I found that end of last year
>> you submitted related patches. After some intense discussions I found no
>> further update.
>> Was this topic put on-hold due to bigger technical issues?
>>
> 
> Well, the proposed code does work but, as you have probaly seen for yourself,
> the maintainers of irqchip and gpio raised valid concerns, mainly about the way
> the mapping is created in the gpio driver. Ideally, the mapping should be
> created at probe time but, with a hierarchic interrupt domain, that means
> allocating the parent irq. We only have 8 of those for 100+ gpios. 
> 
> I'm still not sure how to address the problem to be honest: Is there a way to
> create mapping in hierarchy domain and allocate the parent only when the irq is
> actually requested ? Or should we simply not use a hierarchy domain for this
> controller (which seems to make sense) ?
> 
Meanwhile I became somewhat familiar with the irq subsystem and do some tests
with a GPIO IRQ driver based on GPIOLIB_IRQCHIP (in generic chained mode).

This basically works, however I have a problem with edge detection.
Level changes are not reliably detected. If I connect an input pin (configured
for edge irq generation) to a output pin and change the value of the output pin
no edge is detected. However if I use a cable to connect the input pin to
VCC/GND manually then most of the time edges are detected (not always).
Did you ever come across a similar problem during your tests?

Regards, Heiner

> I still hope to be able to do something on this topic but probably not tomorrow
> :( Of course, If you have some spare time and want to contribute on this topic,
> you are welcome to do so.
> 
>> Rgds, Heiner
> 
> Cheers
> 
> Jerome
> 

Status of Meson GPIO IRQ support

[Jerome Brunet]

On Tue, 2017-04-25 at 23:28 +0200, Heiner Kallweit wrote:
> Am 15.03.2017 um 08:50 schrieb Jerome Brunet:
> > On Tue, 2017-03-14 at 21:41 +0100, Heiner Kallweit wrote:
> > > Jerome,
> > > 
> > > when working on Meson I2C driver I was testing with a device where I
> > > wanted
> > > to use a GPIO as interrupt source.
> > > This isn't supported yet and when checking I found that end of last year
> > > you submitted related patches. After some intense discussions I found no
> > > further update.
> > > Was this topic put on-hold due to bigger technical issues?
> > > 
> > 
> > Well, the proposed code does work but, as you have probaly seen for
> > yourself,
> > the maintainers of irqchip and gpio raised valid concerns, mainly about the
> > way
> > the mapping is created in the gpio driver. Ideally, the mapping should be
> > created at probe time but, with a hierarchic interrupt domain, that means
> > allocating the parent irq. We only have 8 of those for 100+ gpios.?
> > 
> > I'm still not sure how to address the problem to be honest: Is there a way
> > to
> > create mapping in hierarchy domain and allocate the parent only when the irq
> > is
> > actually requested ? Or should we simply not use a hierarchy domain for this
> > controller (which seems to make sense) ?
> > 
> 
> Meanwhile I became somewhat familiar with the irq subsystem and do some tests
> with a GPIO IRQ driver based on GPIOLIB_IRQCHIP (in generic chained mode).

While I'm sure a chained mode implementation would work, I think it would be
incorrect.

As far as I understood, chained mode is designed for controllers which actually
get an interrupt and need to figure out which attached device triggered it.

Imagine you have one IRQ per gpio bank and a register in the gpio controller
telling you which gpio line triggered it (It's a pretty usual design)
         _______________
         |           0 | 
PCTL <---|             |
         | GPIO ctl *1*|<--- Dev B
         |_____________|
 
The GPIO controller is actually involved in the processing of the IRQ. It
receives a signal from the device, set the register value, a trigger the IRQ on
the parent controller (PCTL, in our case: the GIC). I think this is chained
mode.

Our case it is more like this:
????? ???_______________
???? ????|???????????0 |
PCTL <---|------|??????|
         |      |----1-|<--- Dev B
         |_____________|

It simply is a static routing of a signal. The controller is not involved in the
IRQ processing. The signal generated by the device is directly given to the
PCTL.

What's important here is that the GPIO-IRQ controller does not generate the IRQ.
It is not capable of generating an IRQ on the PCTL on its own.

> 
> This basically works, however I have a problem with edge detection.
> Level changes are not reliably detected. If I connect an input pin (configured
> for edge irq generation) to a output pin and change the value of the output
> pin
> no edge is detected. However if I use a cable to connect the input pin to
> VCC/GND manually then most of the time edges are detected (not always).
> Did you ever come across a similar problem during your tests?

Nope, I did not see such a thing. I have mostly tested using a button connected
to gpio (which should be similar to the VCC/GND cable setup you decribed). I've
always got all the IRQs I expected to receive.

If you can, you should try to hook a scope, or at least a voltmeter, check if
you've got valid binary signals.

> 
> Regards, Heiner
> 
> > I still hope to be able to do something on this topic but probably not
> > tomorrow
> > :( Of course, If you have some spare time and want to contribute on this
> > topic,
> > you are welcome to do so.
> > 
> > > Rgds, Heiner
> > 
> > Cheers
> > 
> > Jerome
> > 
> 
>