help needed with kernal GPIO Interrupts via device tree overlay

[William Lear]

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
-------------------------
What I have so far:
My .dts file compiles, is loaded, configures the pins. the driver maps its ISR to the IRQ obtained from devm_request_threaded_irq(),
and I have verified with a scope that the hardware is generating Interrupt requests on the correct pin.

The applicable fragments from my overlay are:

    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
                pinctrl-single,pins = <
                    0x90 0x37      /* INT   gpio2_2,     MODE7, INPUT, PULLUP */
                    0x44 0x17      /* RESET gpio1_17,    MODE7, OUTPUT, PULLUP */
               >;
         };
    };

    fragment@1{
        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 = <&gpio2>;
                interrupts = <2 1>;
               
                reset-gpios = <&gpio1 17 1>;
               
                touchscreen-size-x = <480>;
                touchscreen-size-y = <272>;
            };
         };
    };

The pins are properly configured as confirmed by /sys/kernel/debug/pinctrl/44e10800.pinmux/*
Debug prints in the driver confirms its probe function runs cleanly, and the ISR is never called.
/proc/interrupts confirms that an IRQ is assigned as GPIO to the driver (with either compatible driver).

[Robert Nelson]

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,

--
Robert Nelson
http://www.rcn-ee.com/

[Robert Nelson]

On Tue, Oct 14, 2014 at 4:46 PM, William Lear <wrl...@gmail.com> wrote:

interrupt-parent = <&gpio3>; /* really gpio2 in v3.8.x */

[William Lear]

>

>                 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

[Robert Nelson]

It's strictly in the gpio/pinctrl driver.. Off hand i don't remember
which commit/kernel version it was fixed in.

[William Lear]

Excellent.  I'll make the changes and report back one way or the other.
Thanks again,
Bill

[William Lear]

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 : [<c026e182>]    lr : [<c026e65f>]    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

[William Lear]

On Wednesday, October 15, 2014 7:50:38 AM UTC-4, William Lear wrote:

Robert,

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

[Robert Nelson]

Read up on:

https://github.com/cdsteinkuehler/beaglebone-universal-io

This is what we are using in v3.14 to emulate "cape overlays"...

[William Lear]

On Friday, October 17, 2014 9:17:42 PM UTC-4, RobertCNelson wrote:

...

Read up on:

https://github.com/cdsteinkuehler/beaglebone-universal-io

This is what we are using in v3.14 to emulate "cape overlays"...

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

This looks promising. I did not see how to specify pin slew rates using this method.

Bill

[Charles Steinkuehler]

On 10/18/2014 7:16 AM, William Lear wrote:
>
> This looks promising. I did not see how to specify pin slew rates using
> this method.

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.

--
Charles Steinkuehler
cha...@steinkuehler.net