Cubieboard GPIO interrupts

[hp197]

Hi,

As some of you on IRC might have noticed the past couple of days, im trying to get interrupts working on the GPIO pins of the cubietruck.
In my quest for a irq, i found something what I think is a bug in the pinctrl driver.

http://lxr.free-electrons.com/source/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c#L984
According the code pin PI[10-19] have IRQ connected to mux 0x5.

While if I taker a look onto the datasheet of the a20, I see them on mux 6 (http://dl.linux-sunxi.org/A20/A20%20Datasheet%20V1.41%2020131230.pdf page 23).

First I thought this was because the muxes start counting from 0x0, so 0x5 is the 6th number.
But this wont explain why all the other functions are on the correct mux number (like uart and spi) and looking at pins PH[0-21] you can see they are on 0x6 (in code).

I have a patch ready, but want to get verified that this is a bug (as I refuse to believe that I found a gpio bug in almost 3 years old code and it implies nobody used gpio irq's on mainline with the a20).


~~~

Now, while the pin assignment is sorted, I still have no IRQ's in my kernel.

To start with, this is the output of a logic analyzer onto the pin: http://puu.sh/ndaBJ/804665ce1d.png.
Signal is 1sec spaced and 25ms wide (@3v).

If I export PI14 by running:
echo 270 > /sys/class/gpio/export

I get no value change in: /sys/class/gpio/gpio270/value (while the default direction is in).
Only after I do: 'echo "in" > /sys/class/gpio/gpio270/direction'  I get changing values.
So it looks the port defaults to out direction although kernel says its in, but I do have confirmed that the gpio pin state is working and does change (so I do have signal).

Now, for the irq part....
I changed my dts to include a pps device (pulse per second) - see diff on the bottom of this email.
If the kernel boots, I get a message from the pps-gpio driver that it has found the device and is attached to a kernel irq:

root@cubietruck:~# dmesg | grep pps
[    0.377532] pps_core: LinuxPPS API ver. 1 registered
[    0.377564] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 ...
[    4.773132] pps_core: source pps.-1 got cdev (252:0)
[    4.773161] pps pps0: new PPS source pps.-1
[    4.773289] pps pps0: Registered IRQ 79 as PPS source

/sys/kernel/debug/pinctrl/pinctrl-handles
device: pps current state: default
  state: default
    type: MUX_GROUP controller 1c20800.pinctrl group: PI14 (167) function: irq (27)
    type: CONFIGS_GROUP controller 1c20800.pinctrl group PI14 (167)config 000a0009
config 00007fff

/sys/kernel/debug/pinctrl/1c20800.pinctrl/pinmux-pins
pin 270 (PI14): pps 1c20800.pinctrl:270 function irq group PI14


So to my humble opinion, it looks like it is connected and should work as expected.
Though if I do an output of /proc/interrupts:
           CPU0       CPU1   
 79:          0          0  sunxi_pio_edge  26 Edge      pps.-1

and it looks like it is never interrupted (from the device driver point of view).


Does somebody have a idea where my IRQ's went to and how to find them back?
Thanks in advance,

-
Henry


diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index 8da939a..58ead68 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -94,6 +94,14 @@
                pinctrl-0 = <&mmc3_pwrseq_pin_cubietruck>;
                reset-gpios = <&pio 7 9 GPIO_ACTIVE_LOW>; /* PH9 WIFI_EN */
        };
+
+       pps {
+               pinctrl-names = "default";
+               pinctrl-0 = <&pps_pins_cubietruck>;
+               gpios = <&pio 8 14 GPIO_OPEN_DRAIN>; /* PI14 EINT26 */
+               compatible = "pps-gpio";
+               status = "okay";
+       };
 };
 
 &ahci {
@@ -219,6 +227,13 @@
                allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
        };
 
+       pps_pins_cubietruck: pps_pins@0 {
+               allwinner,pins = "PI14";
+               allwinner,function = "irq";
+               allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+               allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+       };
+
        mmc3_pwrseq_pin_cubietruck: mmc3_pwrseq_pin@0 {
                allwinner,pins = "PH9";
                allwinner,function = "gpio_out";

[hp197]

Op vrijdag 19 februari 2016 14:08:59 UTC+1 schreef hp197:

http://lxr.free-electrons.com/source/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c#L984
According the code pin PI[10-19] have IRQ connected to mux 0x5.

While if I taker a look onto the datasheet of the a20, I see them on mux 6 (http://dl.linux-sunxi.org/A20/A20%20Datasheet%20V1.41%2020131230.pdf page 23).

First I thought this was because the muxes start counting from 0x0, so 0x5 is the 6th number.
But this wont explain why all the other functions are on the correct mux number (like uart and spi) and looking at pins PH[0-21] you can see they are on 0x6 (in code).

I have a patch ready, but want to get verified that this is a bug (as I refuse to believe that I found a gpio bug in almost 3 years old code and it implies nobody used gpio irq's on mainline with the a20).

Just a small heads up with last night findings.

After testing, I believe most manuals and datasheets are wrong.
For the IRQ (EINT*) part this page seemed to be spot on: http://linux-sunxi.org/A20/PIO
All the other documents who say there is IRQ on PI* and PC* are wrong (tested on pins: PC19-20 and PI14-15).

I know pinctrl library says otherwise and will configure irq on other pins (like on PI*) but this is simply incorrect and although you can configure them as irq pin, it will never get interrupted.
I'll do some more examination and update wiki / code accordingly, this might be a revisioned version of the chip who is different from the original.
 

 This was all based on PI* pins being irq-able. So in the end it explains why it didnt work.

 A Thank you to Andre (apritzel) for making me aware that all the manuals and datasheets might be wrong.

[John S]

I see a comment that I don't really understand but maybe it helps.

It is here https://github.com/jwrdegoede/linux-sunxi/pull/3

Maybe contact its author?

John

---

From: hp197 <draak...@gmail.com>
To: linux-sunxi <linux...@googlegroups.com>
Sent: Saturday, 20 February 2016, 9:51
Subject: [linux-sunxi] Re: Cubieboard GPIO interrupts

Op vrijdag 19 februari 2016 14:08:59 UTC+1 schreef hp197:

http://lxr.free-electrons.com/ source/drivers/pinctrl/sunxi/ pinctrl-sun7i-a20.c#L984
According the code pin PI[10-19] have IRQ connected to mux 0x5.

While if I taker a look onto the datasheet of the a20, I see them on mux 6 (http://dl.linux-sunxi.org/ A20/A20%20Datasheet%20V1.41% 2020131230.pdf page 23).

First I thought this was because the muxes start counting from 0x0, so 0x5 is the 6th number.
But this wont explain why all the other functions are on the correct mux number (like uart and spi) and looking at pins PH[0-21] you can see they are on 0x6 (in code).

I have a patch ready, but want to get verified that this is a bug (as I refuse to believe that I found a gpio bug in almost 3 years old code and it implies nobody used gpio irq's on mainline with the a20).

Just a small heads up with last night findings.

After testing, I believe most manuals and datasheets are wrong.
For the IRQ (EINT*) part this page seemed to be spot on: http://linux-sunxi.org/A20/PIO
All the other documents who say there is IRQ on PI* and PC* are wrong (tested on pins: PC19-20 and PI14-15).

I know pinctrl library says otherwise and will configure irq on other pins (like on PI*) but this is simply incorrect and although you can configure them as irq pin, it will never get interrupted.
I'll do some more examination and update wiki / code accordingly, this might be a revisioned version of the chip who is different from the original.
 

Now, while the pin assignment is sorted, I still have no IRQ's in my kernel.

To start with, this is the output of a logic analyzer onto the pin: http://puu.sh/ndaBJ/ 804665ce1d.png.
Signal is 1sec spaced and 25ms wide (@3v).

If I export PI14 by running:
echo 270 > /sys/class/gpio/export

I get no value change in: /sys/class/gpio/gpio270/value (while the default direction is in).

Only after I do: 'echo "in" > /sys/class/gpio/gpio270/ direction'  I get changing values.

[hp197]

Op zaterdag 20 februari 2016 18:35:18 UTC+1 schreef John S:

I see a comment that I don't really understand but maybe it helps.

It is here https://github.com/jwrdegoede/linux-sunxi/pull/3

Looking at the diff: https://github.com/fredericgermain/linux-sunxi/commit/b18f7d273a1cf5f3bc164742f1153aa77deb7d92
I would say he meant exactly the same as me with the IRQ's for PI* pins being on mux 6 instead of mux 5 (because the manual said so).

Though what I didn't know was that the manuals where wrong.
 
To know this for sure, I need somebody with a bPI and some spare free time, to test IRQ's on the easy accessible PI14-15 and PC19-20 pins.
But if it would work on the bPI, it might mean the A20 had a hardware revision. Something which I don't think is the case and my best guess is that nobody really used gpio irq's before on the A20 mainline (maybe some did try, see it didnt work and thought, well, this is still WIP so i'll move back to stock 3.4 kernel).