T234 pinmux/pinctrl driver status in jetpack-6.1

Hello,

I have some problems (probably misconfigured gpio or pwm pad) driving a custom add-on board since I use jetpack-6. It worked well with jetpack-5.1.2. The specific GPIO is PI.00 and the pwm is pwm3.

Parsing Jetson AGX Orin Platform Adaptation and Bring-Up — NVIDIA Jetson Linux Developer Guide 1 documentation I have found the following note :

Currently, to update pinmux, users cannot use the pinctrl APIs.
This is because the upstreamed GPIO driver does not yet support
calling the pinctrl APIs to make changes in the pinmux registers.

Is that still true ? Is it impossible to change pinmux/pinctrl after the initial flashing ?

If I am not mistaken, the last update to that driver in jetpack-6.1 is

commit 5362f5c76bb98c5a0125c96be07348716ebf79b3
Author: Prathamesh Shete <pshete@nvidia.com>
Date:   Mon Jun 5 17:42:29 2023 +0200

    pinctrl: tegra: Add Tegra234 pinmux driver

    BugLink: https://bugs.launchpad.net/bugs/2028400

    This change adds support for the two pin controllers found on Tegra234.

    (cherry-picked from commit 6d8257ca39884a90bbb61e3441f7d578abc53bac)
    Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20230605154230.2910847-3-thierry.reding@gmail.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
    Reviewed-by: Jonathan Hunter <jonathanh@nvidia.com>
    Signed-off-by: Abhilash G <abhilashg@nvidia.com>
    Acked-by: Jacob Martin <jacob.martin@canonical.com>
    Acked-by: Ian May <ian.may@canonical.com>
    Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

hello phdm,

yes, you must re-flash the target to apply pinmux changes.

besides,
since Jetpack-6 (i.e. release-36) does not have /sys/class/gpio to control gpio anymore.
please use libgpiod tools instead. The new GPIO Interface on the Raspberry PI: libgpiod | Lloyd Rochester's Geek Blog

Hello JerryChang,

I have reflashed ny main board by integrating the pinmux needed for my add-on board into the main board dts, and that solves the problem.

However I would like to know :

  • The Orin TRM states about the control registers for the GPIO’s :
All Non-AON, i.e. GPIO_<ii>, Control Registers share the same
base address under the name GPIO_CTL, where <ii> = A, B, C, D, E,
 F, G, H, I, J, K, L, M, N, P, Q, R, X, Y, Z, AC, AD, AE, AF, and AG.

All AON, i.e. GPIO_<iii>, Control Registers share the same base
 address under the name AON_GPIO_0, where <iii> = AA, BB, CC,
 DD, EE, and GG.

For the base address of Non-AON GPIO Control Registers
 (GPIO_CTL) and AON GPIO Control Registers (AON_GPIO_0),
 please refer to the System Address Map in this TRM.

I think I have found the base address for Non-AON GPIO Control Registers :

GPIO_CTL 0x02200000 0x022fffff SYSTEM

but I have not found the address for AON GPIO Control registers. Where is it ?

  • Is the DT-based configuration of the GPIO’s on Tegra234 fixed in current upstream version on kernel. org ?

hello phdm,

let’s taking GPIO3_PAA.0 as an example, CAN0_DOUT is the ball name from pinmux spreadsheet.
you should searching for CAN0_DOUT in the TRM, you’ll see PAD control register, PADCTL_AO_HV_CAN0_DOUT_0.
so, please refer to [8.4.15 Always On High Voltage PAD Control Registers] for the PAD control description.
re-cap as below.

The Always ON High Voltage PAD Control Registers are collectively called PADCTL_A15 in the System Address Map.

according to above, please looking for PADCTL_A15.
for instance,

Block Name Address Start Address End Address Locality
PADCTL_A15 0x0c303000 0x0c303fff SYSTEM

Thank you, JerryChang

And about my other question ?

hello phdm,

please see-also Pinmux and GPIO Configuration.
may I know what’s the failure you’ve seen?

I had flashed my custom board as a devkit (excepted for ./kernel/dtb/tegra234-p3768-0000+p3767-0000-dynamic.dtbo which forces csi and vi bus-widths incompatible with our hardware) and then added my kernel and dtb in the /boot/extlinux/extlinux.conf file. Everything (image sensors, usb, ethernet and more i2c and spi peripherals) worked fine except for one peripheral controlled only by pwm3 and gpio PI.00. Integrating the pinmux and gpio files produced by the spreadsheet configured for our board into our DT did not succeed to make our peripheral work. I had used the same working way (flashing as a devkit, then using extlinux.conf to choose our kernel and DT) with jetpack-5.1.2 and that worked perfectly. Maybe the default configuration of PI.00 and pwm3 has changed between 5.1.2 and 6.1, or the pinmux/gpio drivers have regressed ?

There is no update from you for a period, assuming this is not an issue anymore.
Hence, we are closing this topic. If need further support, please open a new one.
Thanks

hello phdm,

may I know what’s the failure? did you meant incorrect initial state, or… you cannot toggle the pin?