PROCESSOR-SDK-J7200: main_pmx3 configuration

Hi Nikhil,

It's interesting that the gpio is in main_pmx3. Let me test some things and I will get back to you on whether it should actually be in a different pinmux or if we need to update the device tree.

Best,
Jared

Hi Jared,

Any update on this case.

Regards,

Nikhil

Hi Jared,

Thanks for the reply,

I observed that multiple IO pins having issue with pinmuxing.
Can you please ensure that which are the IO having wrong register mappings interms of pimuxing (main, wkup domains)

Regards,

Nikhil K

Hi Nikhil,

Sorry, the pinmux I gave was incorrect. I have fixed the code.

The patch above is for the main domain, do you have a list of the IO pins that are having issues? That would help me narrow down anything else.

Best,
Jared

Hi Jared,

Seems like wkup_pmx also having similar issue.

Regards,

Nikhil

Hi Jared,

Thanks for the reference,

1. Here we are configuring wkup_gpio0_31 as an gpio, but we are not able to toggle the gpio (in the sense we are not able to make this gpio high).

Kindly find the iomux configuration below

        wkup_gpio_pins_default: wkup_gpio_default_pins {
                pinctrl-single,pins = <
                        J721E_WKUP_IOPAD(0x4, PIN_OUTPUT, 7) /* (D5) MCU_OSPI0_CSn3.WKUP_GPIO0_31 */
                >;
        };

2. Also we observed gpio sysfs read values are not proper.

In the attachment you can see eth_reset_gpio shows configured as low but actually the gpio is configured high and when we probed voltage level of the gpio it shows high.

Kindly help is resolving above mentioned two issues.

Regards,

Nikhil

Hi Nikhil,

I was able to set the gpio both low and high with the following device tree (just had to change the default state).

#include <dt-bindings/gpio/gpio.h>
#include "k3-pinctrl.h"

/dts-v1/;
/plugin/;

&wkup_pmx1 {
	test_gpio_pins: test-gpio-pins {
		pinctrl-single,pins = <
			J721E_WKUP_IOPAD(0x004, PIN_OUTPUT, 7)
		>;
	};
};

&{/} {
	test_gpio_leds: test-gpio-leds {
		compatible = "gpio-leds";

		pinctrl-names = "default";
		pinctrl-0 = <&test_gpio_pins>;

		led-0 {
			gpios = <&wkup_gpio0 31 GPIO_ACTIVE_HIGH>;
			label = "wkup0_31 gpio";
			default-state = "on";
		};
	};
};

I checked the status of the pin with:

$ devmem2 0x42110014

Is your device tree written correctly? Do you have the pinctrl in the relevant node?

Best,
Jared

Hi Jared,

2. Also we observed gpio sysfs read values are not proper.

In the attachment you can see eth_reset_gpio shows configured as low but actually the gpio is configured high and when we probed voltage level of the gpio it shows high.

any update on this ?

Regards,

Nikhil

Hi Nikhil,

Is it not high because it is set to active low? Can you toggle the pin or set the pin to active high and see if that fixed things?

Best,
Jared

Hi jared,

Here i configured ethernet reset using gpio hog and kept as active high

&wkup_gpio0 {
        pinctrl-names = "default";
        pinctrl-0 = <&wkup_eth_rst_pins_default>;
        eth_reset_gpio {
                gpio-hog;
                gpios = <25 GPIO_ACTIVE_HIGH>;
                output-high;
                linename = "eth_rst";
        };
};

Regards,

Nikhil K

Hi Jared,

We have disabled  ospi node and we are not facinng any pinctrl issue. When we probed in voltmeter gpio status is showing high and in devmem2 0x42110014 also it showing gpio bit set, only thing not working is reading in sysfs.

Regards,

Nikhil

Hi Jared,

Yes, everything else works properly, but sysfs also should work properly for reading the status of gpio using below command

cat /sys/kernel/debug/gpio

This command will not try to access gpio, this just prints the status of that, so if that gpio already  in use there is no conflict will come

Regards,

Nikhil

Hi Nikhil,

I also see the issue in DebugFS. Something interesting to note:

Set with a gpio-hog (shows up as an input and low):

gpiochip4: GPIOs 371-455, parent: platform/42110000.gpio, 42110000.gpio:
 gpio-371 (                    |enable              ) out lo 
 gpio-373 (                    |standby             ) out hi 
 gpio-396 (                    |wkup0-25-hog        ) in  lo 
 gpio-402 (                    |wkup0-31-hog        ) in  lo 
 gpio-429 (                    |standby             ) out lo ACTIVE LOW

Set with gpio-leds driver (shows up as an output and low):

gpiochip4: GPIOs 371-455, parent: platform/42110000.gpio, 42110000.gpio:
 gpio-371 (                    |enable              ) out lo 
 gpio-373 (                    |standby             ) out hi 
 gpio-396 (                    |wkup0_25-gpio       ) out lo 
 gpio-402 (                    |wkup0_31-gpio       ) out lo 
 gpio-429 (                    |standby             ) out lo ACTIVE LOW

I'll run the bug up internally.

Best,
Jared

Just another note, there is a discrepancy between the TRM and the datasheet. I've added two patches depending on which ends up being correct.

Datasheet, no padconfig 63:

From fa7394e401f87bc2d986113e0260f4f91ee0ed3c Mon Sep 17 00:00:00 2001
From: Jared McArthur <j-mcarthur@ti.com>
Date: Mon, 9 Sep 2024 14:07:10 -0500
Subject: [PATCH] arm64: dts: ti: k3-j7200: Fix register map for main domain
 pmx

Commit 0d0a0b441346 ("arm64: dts: ti: k3-j7200: fix main pinmux
range") split the main_pmx0 into two nodes: main_pmx0 and main_pmx1
due to a non-addressable region, but incorrectly represented the
ranges. As a result, the memory map for the pinctrl is incorrect. Fix
this by introducing the correct ranges.

The ranges are taken from the DRA821 datasheet [1] (Table 6-106. Pin
Multiplexing).

Padconfig starting addresses and ranges:
-  0 to 62: 0x11c000, 0x0fc
- 64 to 66: 0x11c100, 0x00c
-       68: 0x11c110, 0x004
- 71 to 73: 0x11c11c, 0x00c
- 89 to 90: 0x11c164, 0x008

[1] https://www.ti.com/lit/gpn/dra821u

Fixes: 0d0a0b441346 ("arm64: dts: ti: k3-j7200: fix main pinmux range")
Signed-off-by: Jared McArthur <j-mcarthur@ti.com>
---
 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 33 ++++++++++++++++++++---
 1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
index 16ff103cf69e4..df1011aa055d9 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
@@ -395,16 +395,43 @@ cpts@3d000 {
 	main_pmx0: pinctrl@11c000 {
 		compatible = "ti,j7200-padconf", "pinctrl-single";
 		/* Proxy 0 addressing */
-		reg = <0x00 0x11c000 0x00 0x10c>;
+		reg = <0x00 0x11c000 0x00 0x0fc>;
 		#pinctrl-cells = <1>;
 		pinctrl-single,register-width = <32>;
 		pinctrl-single,function-mask = <0xffffffff>;
 	};
 
-	main_pmx1: pinctrl@11c11c {
+	main_pmx1: pinctrl@11c100 {
 		compatible = "ti,j7200-padconf", "pinctrl-single";
 		/* Proxy 0 addressing */
-		reg = <0x00 0x11c11c 0x00 0xc>;
+		reg = <0x00 0x11c100 0x00 0x00c>;
+		#pinctrl-cells = <1>;
+		pinctrl-single,register-width = <32>;
+		pinctrl-single,function-mask = <0xffffffff>;
+	};
+
+	main_pmx2: pinctrl@11c110 {
+		compatible = "ti,j7200-padconf", "pinctrl-single";
+		/* Proxy 0 addressing */
+		reg = <0x00 0x11c110 0x00 0x004>;
+		#pinctrl-cells = <1>;
+		pinctrl-single,register-width = <32>;
+		pinctrl-single,function-mask = <0xffffffff>;
+	};
+
+	main_pmx3: pinctrl@11c11c {
+		compatible = "ti,j7200-padconf", "pinctrl-single";
+		/* Proxy 0 addressing */
+		reg = <0x00 0x11c11c 0x00 0x00c>;
+		#pinctrl-cells = <1>;
+		pinctrl-single,register-width = <32>;
+		pinctrl-single,function-mask = <0xffffffff>;
+	};
+
+	main_pmx4: pinctrl@11c164 {
+		compatible = "ti,j7200-padconf", "pinctrl-single";
+		/* Proxy 0 addressing */
+		reg = <0x00 0x11c164 0x00 0x008>;
 		#pinctrl-cells = <1>;
 		pinctrl-single,register-width = <32>;
 		pinctrl-single,function-mask = <0xffffffff>;
-- 
2.34.1

TRM, with padconfig 63:

From 4271cd55425b0579798b33e9e097b76bad3b3479 Mon Sep 17 00:00:00 2001
From: Jared McArthur <j-mcarthur@ti.com>
Date: Tue, 30 Jul 2024 11:19:44 -0500
Subject: [PATCH] arm64: dts: ti: k3-j7200: Fix register map for main domain
 pmx

Commit 0d0a0b441346 ("arm64: dts: ti: k3-j7200: fix main pinmux
range") split the main_pmx0 into two nodes: main_pmx0 and main_pmx1
due to a non-addressable region, but incorrectly represented the
ranges. As a result, the memory map for the pinctrl is incorrect. Fix
this by introducing the correct ranges.

The ranges are taken from the J7200 TRM [1] (Table 5-695. CTRL_MMR0
Registers).

Padconfig starting addresses and ranges:
-  0 to 66: 0x11c000, 0x10c
-       68: 0x11c110, 0x004
- 71 to 73: 0x11c11c, 0x00c
- 89 to 90: 0x11c164, 0x008

[1] https://www.ti.com/lit/pdf/spruiu1

Fixes: 0d0a0b441346 ("arm64: dts: ti: k3-j7200: fix main pinmux range")
Signed-off-by: Jared McArthur <j-mcarthur@ti.com>
---
 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
index 16ff103cf69e4..0d2ae3877a693 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
@@ -401,10 +401,28 @@ main_pmx0: pinctrl@11c000 {
 		pinctrl-single,function-mask = <0xffffffff>;
 	};
 
-	main_pmx1: pinctrl@11c11c {
+	main_pmx1: pinctrl@11c110 {
 		compatible = "ti,j7200-padconf", "pinctrl-single";
 		/* Proxy 0 addressing */
-		reg = <0x00 0x11c11c 0x00 0xc>;
+		reg = <0x00 0x11c110 0x00 0x004>;
+		#pinctrl-cells = <1>;
+		pinctrl-single,register-width = <32>;
+		pinctrl-single,function-mask = <0xffffffff>;
+	};
+
+	main_pmx2: pinctrl@11c11c {
+		compatible = "ti,j7200-padconf", "pinctrl-single";
+		/* Proxy 0 addressing */
+		reg = <0x00 0x11c11c 0x00 0x00c>;
+		#pinctrl-cells = <1>;
+		pinctrl-single,register-width = <32>;
+		pinctrl-single,function-mask = <0xffffffff>;
+	};
+
+	main_pmx3: pinctrl@11c164 {
+		compatible = "ti,j7200-padconf", "pinctrl-single";
+		/* Proxy 0 addressing */
+		reg = <0x00 0x11c164 0x00 0x008>;
 		#pinctrl-cells = <1>;
 		pinctrl-single,register-width = <32>;
 		pinctrl-single,function-mask = <0xffffffff>;
-- 
2.34.1

Best,
Jared

Hi Jared,

This issue already we have resolved with our previous discussion, anyway thanks for reconfirming

Jared McArthur said:

I also see the issue in DebugFS. Something interesting to note:

Is there any update on this issue..?

Regards,

Nikhil K

Hi Nikhil,

One of our developers is currently looking at the issue. I don't have an update for you though.

Best,
Jared