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 <[email protected]>
To: linux-sunxi <[email protected]>
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.
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).
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.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.