Issue configuring device tree for AM335xEVMSK and touchscreen

I forgot to mention: I know that the line of code in the driver that's causing the error message is:

of_get_named_gpio(np, "wakeup-gpios", 0);

which is a common device tree call that's not really related to the driver. So that line in the .dts file seems to be at fault.

I should also mention this is my first time mucking about with device trees...

Hi Steve,

I will forward this to the SW experts.

Hi ,

As is known for the am335x wakeup is possible only for GPIO0 bank. Your initializations " wakeup-gpios = <1 0>; /* 1 = gpio2_1; 0 = unused cell */" is wrong.

BR
Ivan

Ivan Matrakov said:

As is known for the am335x wakeup is possible only for GPIO0 bank. Your initializations " wakeup-gpios = <1 0>; /* 1 = gpio2_1; 0 = unused cell */" is wrong.

But, according to the schematic for the TMDSSK3358 evaluation module, on page 9, upper-left hand corner, connector J2 pin 6 (LCD_CAP_TOUCH_WAKE) has the LCD wake pin connected to the AM3358 GPIO2_1. I believe this pin is used to wake the touch controller from the AM3358, not the other way around.

It would be much more helpful to suggest a solution than to simply say "it's wrong". I understand there's probably something wrong here...

There is a note at the bottom of this TI page describing the eval kit that contains a link to New Haven, which is broken. Is there any documentation on how to accomplish this? I could probably adapt that to my LCD controller, I'm sure.

Hi ,

For the wakeup sources you can see from the TRM: 8.1.4.5 Wakeup Sources/Events
For the other part of code I recommended to see in the same directory am33xx.dtsi file (it's included). For me the "interrupt-parent = <&gpio2>;" mean that you have to define the parent sources. Do you have these declarations. The line "interrupts = <0 2>;" mean that you want to use interrupt 0 and 2 not gpio2_0.
Please see these and comments.

BR
Ivan

I think I've discovered an issue between the documentation on the OMAP4 GPIO bindings and the GPIO bindings present in am33xx.dtsi.

According to Documentation/devicetree/bindings/gpio/gpio-omap.txt in the Linux source:

- #interrupt-cells : Should be 2.
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
1 = low-to-high edge triggered.
2 = high-to-low edge triggered.
4 = active high level-sensitive.
8 = active low level-sensitive.

So, in my binding, I used "interrupts <0 2>". The first cell is 0, which I assumed was the GPIO number in the bank that was specified as the interrupt controller (gpio2), therefore "pin 0 of bank gpio2". The second cell I selected as 2 because I want a falling edge trigger.

However, this is the entry for GPIO2 in am33xx.dtsi:

gpio2: gpio@481ac000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio3";
clocks = <&l4ls_gclk>, <&gpio2_dbclk>;
clock-names = "fck", "dbclk";
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x481ac000 0x1000>;
interrupts = <32>;
};

This directly conflicts with the documentation - #interrupt-cells is 1, not 2! I just noticed this...

Now I don't know what I know. I believe that if there is documentation alluded to on that page regarding a New Haven display, that it would directly help me in this issue. Unfortunately, I can't find it.

Biser,

Is there any news from the SW experts?

Thank you.

I just noticed the following after booting from a stock SD card (generated with the SDK's script). This is a grep of dmesg for "parse gpios":

[ 0.264356] of_get_named_gpio_flags: can't parse gpios property of node '/fixedregulator@0[0]'
[ 0.264781] of_get_named_gpio_flags: can't parse gpios property of node '/fixedregulator@1[0]'
[ 0.503189] of_get_named_gpio_flags: can't parse gpios property of node '/ocp/serial@44e09000[0]'
[ 1.298857] of_get_named_gpio_flags: can't parse gpios property of node '/ocp/mmc@48060000[0]'
[ 1.590378] of_get_named_gpio_flags: can't parse gpios property of node '/ocp/mmc@48060000[0]'
[ 3.220419] of_get_named_gpio_flags: can't parse gpios property of node '/ocp/usb@47400000/usb-phy@47401300[0]'
[ 3.239947] of_get_named_gpio_flags: can't parse gpios property of node '/ocp/usb@47400000/usb-phy@47401b00[0]'
[ 3.280777] of_get_named_gpio_flags: can't parse gpios property of node '/ocp/i2c@44e0b000/tlv320aic3106@1b[0]'

I would expect the stock image to boot "cleanly".

Steve Ziuchkovski said:

I would expect the stock image to boot "cleanly".

I would as well, so I took a look. This output is generated because GPIO debug is enabled in our defconfig and the of_get_named_gpio_flags() call that is used by the drivers to parse the DT uses a pr_debug() when it doesn't find anything. The drivers correctly ignore this, but the pr_debug() has already been called, generating much of the output you referenced. This is not causing any real issues.

On to your original problem, we have a board similar to the SK which has a DT file in upstream that you might want to reference here.

Also, I did some work to get the New Haven cap touch display going. I never quite got it there to where I wanted, but the changes I've made might help to get you going. Here's the DT entry I used under I2C0:

polytouch: edt-tf5x06@38 {
                                status = "okay";
                                compatible = "edt,edt-ft5306", "edt,edt-ft5x06";
                                reg = <0x38>;
                                pinctrl-names = "default";
                                pinctrl-0 = <&edt_ft5x06_ts_pins>;
                                interrupt-parent = <&gpio2>;
                                interrupts = <0 0>;
                                wake-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
                                touchscreen-size-x = <480>;
                                touchscreen-size-y = <272>;
                        };

One thing I notice as a difference is that I don't see a pinctrl entry in yours. I needed to set the interrupt and wake pins to GPIO with this in the am33xx_pinmux structure:

edt_ft5x06_ts_pins: edt_ft5x06_ts_pins {
                        pinctrl-single,pins = <
                                0x88 (PIN_INPUT | MUX_MODE7) /* gpmc_csn2.gpio2_0 */
                                0x8C (PIN_OUTPUT | MUX_MODE7) /* gpmc_clk.gpio2_1 */
                        >;

};

Hopefully between these two pointers, you'll find something that helps you get yours working.