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. <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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
