I am writing a device tree overlay file for a custom cape containing a touchscreen , and am having problems mapping a GPIO line as an interrupt to be handled by a device driver.
I cannot get interrupt pulses on my GPIO line to invoke the ISR in the device driver.
I have reached the limits of my BBB debug capabilities - I’m looking for any suggestions about how to find
the disconnect between the pin and the ISR.
Thanks,
Bill
This is on 3.14 (note the &gpioX index was one off in v3.8.x)
https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-bone-bbb-exp-c.dtsi#L50
Regards,
interrupt-parent = <&gpio3>; /* really gpio2 in v3.8.x */
Regards,
reg = <0x38>;
interrupt-parent = <&gpio2>;interrupt-parent = <&gpio3>; /* really gpio2 in v3.8.x */
Regards,
–
Robert Nelson
http://www.rcn-ee.com/
That would explain a lot. I am running the 3.8 kernel/Debian. I backported an updated version of the driver from the 3.15 kernel. I was not aware of the indexing issue. Do you think I will need to change anything in the driver source to accommodate this, or is it strictly a device tree issue?
Thanks much!
Bill
It's strictly in the gpio/pinctrl driver.. Off hand i don't remember
which commit/kernel version it was fixed in.
Regards,
Excellent. I’ll make the changes and report back one way or the other.
Thanks again,
Bill
reg = <0x38>;
interrupt-parent = <&gpio2>;interrupt-parent = <&gpio3>; /* really gpio2 in v3.8.x */
Regards,
–
Robert Nelson
http://www.rcn-ee.com/That would explain a lot. I am running the 3.8 kernel/Debian. I backported
an updated version of the driver from the 3.15 kernel. I was not aware of
the indexing issue. Do you think I will need to change anything in the
driver source to accommodate this, or is it strictly a device tree issue?It’s strictly in the gpio/pinctrl driver… Off hand i don’t remember
which commit/kernel version it was fixed in.Regards,
–
Robert Nelson
http://www.rcn-ee.com/Excellent. I’ll make the changes and report back one way or the other.
Thanks again,
Bill
Well, just changing
interrupt-parent = <&gpio2>;
to
interrupt-parent = <&gpio3>;
resulted in an unhandled fault in _set_gpio_irq_type() (being called by gpio_irq_type()) :
[ 9.904568] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa1ac140
[ 9.912579] Internal error: : 1028 [#1] SMP THUMB2
[ 9.917579] Modules linked in: ft5x0x_ts mt7601Usta(O) edt_ft5x06
[ 9.923970] CPU: 0 Tainted: G O (3.8.13-bone50 #1)
[ 9.930258] PC is at _set_gpio_triggering+0x1e/0x1c0
[ 9.935440] LR is at gpio_irq_type+0x93/0xc0
[ 9.939892] pc : [] lr : [] psr: 800001b3
[ 9.939892] sp : de609c30 ip : 00000000 fp : de30d820
[ 9.951863] r10: df0c77b0 r9 : 00000042 r8 : df0c8c10
[ 9.957319] r7 : 60000193 r6 : 00000044 r5 : fa1ac000 r4 : 00000001
[ 9.964124] r3 : df0c8c10 r2 : 00000001 r1 : 00000004 r0 : fa1ac140
[ 9.970939] Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA Thumb Segment user
[ 9.978646] Control: 50c5387d Table: 9e544019 DAC: 00000015
[ 9.984642] Process capemgr.sh (pid: 575, stack limit = 0xde608240)
[ 9.991172] Stack: (0xde609c30 to 0xde60a000)
[ 9.995720] 9c20: 00000001 df0c7780 df0c8c6c 60000193
[ 10.004258] 9c40: df0c7804 df0c7780 c026e5cd 00000000 000000c2 c08771ec 00000001 c0073a01
[ 10.012785] 9c60: df0c7804 df0c7780 df2f4540 df0c77d0 00840000 000000c2 40000113 c0073cd7
[ 10.021335] 9c80: c0863d14 c0042069 df2e7428 de30d800 df2f4540 df0c7780 00000021 bf8c704d
[ 10.029874] 9ca0: 000000c2 00000000 de516340 c0073db9 de30d800 00000000 de516340 bf8c7bd4
[ 10.038412] 9cc0: de30d820 bf8c7c04 bf8c80b4 bf8c710f bf8c7c04 de516340 de713648 c00fdc8f
[ 10.046948] 9ce0: de713648 00000000 de609d08 de713b48 de713988 c00fe507 df0bacb8 bf8c7bbc
[ 10.055484] 9d00: bf8c7bbc de30d804 bf8c7bd4 de30d820 de30d800 bf8c7061 de5e7928 c035e899
[ 10.064022] 9d20: c09189ec de30d820 bf8c7efc 00000000 c09189c8 00200200 00000000 c02c62bb
I’m not very familiar with the operation of the capemgr, but this appears to happen while it is loading my overlay, so I don’t believe the driver is involved yet?
Since gpio_irq_type() was involved, I also ran another test in which I changed all the gpio interrupt-cells from <1> to <2> per notes in the .dtsi - no difference in behavior.
The two fragments involved now look like:
fragment@0 {
target = <&am33xx_pinmux>;
overlay {
pharm_ctp_pins: pinmux_pharm_ctp_pins {
pinctrl-single,pins = <
0x90 0x37 /* INT gpio2_2, MODE7, INPUT, PULLUP /
0x44 0x17 / RESET gpio1_17, MODE7, OUTPUT, PULLUP */
;
};
};
};
and
fragment@3 {
target = <&i2c2>;
overlay {
#address-cells = <1>;
#size-cells = <0>;
status = “okay”;
/* Capacitive Touch Panel */
edt_ft5x06@38 {
status = “okay”;
compatible = “edt,edt-ft5x06”;
/compatible = “ft5x0x_ts”;/
pinctrl-names = “default”;
pinctrl-0 = <&pharm_ctp_pins>;
reg = <0x38>;
interrupt-parent = <&gpio3>; /* Testing - actually gpio2 */
interrupts = <2 1>;
reset-gpios = <&gpio1 17 1>;
touchscreen-size-x = <480>;
touchscreen-size-y = <272>;
};
};
};
Any suggestions for next steps?
Bill
In the am335x-bone-bbb-exp-c.dtsi file you referenced, what does the following section do:
&ocp {
/* i2c /
…
/ edt-ft5306 irq pin */
P9_23_pinmux {
status = “disabled”;
};
…
};
I have not seen this before. Is this required in order to use a gpio as an interrupt?
Bill
Read up on:
https://github.com/cdsteinkuehler/beaglebone-universal-io
This is what we are using in v3.14 to emulate "cape overlays"...
Regards,
This looks promising. I did not see how to specify pin slew rates using this method.
Bill
You'll have to edit the pinmux values if you want to change the slew
rate. I have entries to enable input, output, and pull-up/pull-down,
but there's a limit to how many combinations make sense to have in the
default device tree.
Playing with slew rate is one of the things that pushes you towards
making your own device-tree with whatever custom settings you need for
your hardware. If you want to use the universal overlay, you would need
edit the pinmux values:
<example pinmux settings you need to change for P8, pin 7):
https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universal-00A0.dts#L173-L183
I have entries to enable input, output, and pull-up/pull-down, but
there's a limit to how many combinations make sense to have in the
default device tree before requiring you to craft your own.