PWM disabled - Register 0x6000d504 always at 0x1

Robotics & Edge Computing Jetson Systems Jetson Nano
1

Hi,

I have been trying to make the PWM work on pin 32 for a while now.
What’s strange is that I remember it working directly after booting with Jetson.GPIO PWM a couple of months ago.

Anyway, now the only lead I have is that after booting, register 0x6000d504 is at 0x1.
If I set it to 0x0, I can use my PWM.

Do you know how I should set this in the DTS, please?
I suppose it’s in gpio@6000d000, but I’ve tried and not succeeded:

pin32-pwm {
        gpio-hog;
        gpios = <168 0>;
        input;
        line-name = "pin32-pwm";
};

Thank you in advance,

Tom

3

Hi tom.hall1,

Are you using the devkit or custom board for Jetson Nano?
What’s the Jetpack version in use?

gpio-hog is probably not the right approach here. For pin 32 on Jetson Nano, please check PV.00 / GPIO07 / LCD_BL_PWM_PV0, and verify whether TEGRA_GPIO(V, 0) is still enabled in the DT or bootloader pin settings. If the pin is still hogged as GPIO, PWM will conflict with it.

For this case, I would suggest checking whether TEGRA_GPIO(V, 0) is still enabled first. In a similar Nano production-SOM case, removing/disabling that GPIO path resolved PWM on pin 32 and pin 33.

You can compare the live DT and GPIO state with:

sudo dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree
sudo cat /sys/kernel/debug/tegra_gpio

If PV.00 / TEGRA_GPIO(V, 0) is still configured as GPIO, please remove/disable it and then re-test PWM.

4

Hi @KevinFFF

Yes I am using the devkit.

So, are you saying that 0x1 means there’s a gpio hog and 0x0 means no gpio-hog on pin 168?
I have checked tegra_gpio, it shows line V like this:

V: 5:1 01 01 01 00 00 00 000000

And after I put 0x0 to the 0x6000d504 register, I get this:

V: 5:1 00 00 00 00 00 00 000000

m
This seems normal since CNF tells whether it’s gpio or not.
But in my active DTS, I don’t see anything that can hog it.

Do you confirm it must be in the gpio@6000d000 node?
I just tried disabling all gpio@6000d000 children nodes altogether, but I still get that 01 in the tegra_gpio CNF and the 0x6000d504 is still at 0x1.

Any other ideas?

Thanks in advance,
Tom

5

0x1 does not necessarily mean gpio-hog; it only shows pin 32 (PV.00 / GPIO07) is still in GPIO mode.

Since disabling gpio@6000d000 children does not change it, this likely comes from an earlier boot stage rather than a Linux GPIO hog.

Please dump the live DT from /proc/device-tree and check whether TEGRA_GPIO(V,0) is present.
If not, please check the bootloader pin configuration for PV.00.

sudo dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree
sudo cat /sys/kernel/debug/tegra_gpio
6

Hi @KevinFFF,

Indeed I don’t think there’s any clear gpio-hog on it.
The only instances of 0xa8 I see (and not 100% sure it’s referring to the pin number), are in nodes “pinmux@700008d4/prod-settings/prod” (the prod property, and on top I have nvidia,prod-boot-init), “pwm-fan” (as vdd-fan-supply), and mods-simple-bus/mods-clocks (in the clocks and resets properties).

Unfortunately I disabled all of them, and still have the identical result…

7

Thanks, this further suggests it is not a Linux gpio-hog issue. If disabling gpio@6000d000 children and those other candidate nodes still gives the exact same result, then pin 32 (PV.00 / GPIO07) is likely being configured before Linux, i.e. in the bootloader pinmux/init stage.

Please dump the live DT from /proc/device-tree and check whether TEGRA_GPIO(V,0) appears there. If not, I would suggest checking/updating the bootloader pin configuration for PV.00.

sudo dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree
sudo cat /sys/kernel/debug/tegra_gpio
8

Hi @KevinFFF

First, here’s the DTS I have already (I converted it into txt just to upload it here):

kernel.txt (318.9 KB)

Then, here’s the active device-tree from /proc/device-tree:

kernel_nano_proc.txt (323.7 KB)

I can’t find anything that could block pwm0 here, please let me know what you think.

Also (quick aparte), I have a Jetson Nano 4GB that seemingly has no dtb assigned in extlinux.conf, is there somewhere I can find the initial applied device-tree? Is it something that’s applied from the flash to the device tree? Or a default device-tree (and where)? Please.

Is it safe tegra210-p3448-0002-p3449-0000-b00.dtb as the kernel dtb on a Jetson Nano 4GB that would normally have a kernel210-p3448-0002-p3449-0000-b00-user-custom.dtb in extlinux.conf?

9

From the DTS snippet, hdr40-pin32 already sets lcd_bl_pwm_pv0 to pwm0, so the Linux pinmux entry itself looks correct.
I also do not see an obvious consumer such as panel-bl-pwm-gpio or /backlight in the active DT you checked.
So at this point, it does not look like a Linux DT gpio-hog issue. It is more likely that PV.00 is being forced to GPIO in an earlier boot stage (bootloader/BCT pinmux-gpio init) or reconfigured later at runtime.

If the DTB in not specified in the extlinux.conf, it will be loaded from kernel-dtb partition.
You can simply check the flash log to know the exact DTB file in use.

Please use kernel210-p3448-0002-p3449-0000-b00-user-custom.dtb if you have used jetson-io tool to configure the pin.

10

Hi,

From what I see, a lot of the /proc/device-tree depends on the device itself rather than a base DTB that is applied.

Do you have any additional ways to find where a potential reconfiguration of pin 168 might be happening?

(By the way I made a typo. It’s kernel_tegra210-p3448-0002-p3449-0000-b00-user-custom.dtb, not kernel210-p3448-0002-p3449-0000-b00-user-custom.dtb).

Thank you

11

Please specify this DTB for FDT entry in extlinux.conf.

You can extract the device tree in runtime and check the hex value for that pin.

$ sudo dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree
12

Hi KevinFFF,

I tried that. But still I get the same result. lcd_bl_pwm_pv0 is still pwm0 and not hogged anywhere.

I will try to compile one of the template DTB files in the boot folder to see if there’s a difference (as I remember PWM working a few months ago).
I’ll let you know.

Thank you,
Tom