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.

Reply via email to