RE: [PATCH 0/2] ARM: dts: rskrza1: Add I2C and remaining LEDs

[Chris Brandt <Chris.Brandt@renesas.com>]

Hi Geert,

Look what fun you are having with an RZ/A1 board!
You might have even more fun with a RZ/A2 board ;)

> However, that also doesn't work, as the PL390 GIC supports rising edge
> and high-level interrupts only.  Falling edge and low-level interrupts
> on the IRQ pins seem to be an RZ/A1-specific GIC extension,

Yes. I get this question a couple times a year.

And no one wants rising or level high, so the GPIO interrupts would not 
work for them anyway.

So, as you found:

> I've just discovered commit 207c10b54ca81129 ("irq-gic: add support for
> pins IRQ0-IRQ7") in rza_linux-4.14, but when using that, the system
> locks up when pressing a switch :-(

It might be because the interrupt routine needs to go in and clear the 
interrupt by writing to the 'IRQ Interrupt Request Register' (IRQRR).
From the HW manual:

"IRQRR is a 16-bit register that indicates interrupt requests from 
external input pins IRQ7 to IRQ0. If edge detection is set for the IRQ7 to 
IRQ0 interrupts, writing 0 to the IRQ7F to IRQ0F bits after reading IRQ7F 
to IRQ0F = 1 cancels the retained interrupts."


The touchscreen driver for the LCD uses IRQ_TYPE_LEVEL_LOW. 
In the interrupt routine ft5x06_ts_isr, disable_irq_nosync(irq) is called immediately.
Then after the touch point is read out, enable_irq(ts->client->irq) is called in ft5x06_ts_poscheck.
https://github.com/renesas-rz/rza_linux-4.19/blob/master/drivers/input/touchscreen/ft5x06_ts.c#L232


> What am I doing wrong?
> Do you have a better solution?
> The IRQx support looks most promising, but needs some work (separate
> compatible value, small driver with a custom .irq_set_type, deferring
> the rest to the normal GIC driver).

I not sure about a 'better' solution...just the one I tell people 
(although I need to make some App Note someday).

Basically, I tell people they need to describe the IRQ in the Device 
Tree somewhere (so it can get allocated an interrupt ID).
Then, they can call request_irq() from inside a custom driver if they 
want to.
Or, they just make a very simple shim-driver in their board-xxx.c file 
that registers the interrupt and has a simple interrupt routine. Many 
times all people want to do is simply wire up an interrupt that the 
application can wait on. Or, use an IRQ pin to start an ADC conversion. Pretty 
simple stuff.

Of course they can also use a UIO driver to do these kinds of things as 
well.
As you know, the UIO subsystem will automatically turn of the interrupt 
each time, but users still need to write to the IRQRR register before 
turning the interrupt back on if using edge interrupts.

I always thought what I really need to do is instead just make a 
separate driver like you suggested above because technical, the "IRQ" block is 
not really part of the GIC, it is a separate block that feeds interrupts
into the GIC just like all the other peripherals, so it should be 
represented as a separate piece of hardware (ie, its own driver and 
capability string).


For what it's worth, the RZ/A2 has the exact same IRQs, so if I ever got
around for doing it for RZ/A1, it could also be used for RZ/A2.

Chris