Changing pinmux setting after booting.

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX1
1

Hello again,

For one of the applications I have, I have to use the SPI0 pins as SPI at certain stages of the application or use it as GPIO during certain other stages. It depends on how the user input.

Based on what I’ve read till now, it seems the only way to change the pimux settings is by adding/removing the following bit of code to the device tree.

gpio_default: default{
   gpio-hog;
   function;
   gpios = <TEGRA_GPIO(C, 0) 0 TEGRA_GPIO(C, 1) 0 TEGRA_GPIO(C, 2) 0 TEGRA_GPIO(C, 3) TEGRA_GPIO(C,4) 0>;

Since the edit has to be at to device tree,

  1. It needs a reboot after changing the device tree,
  2. It needs an external x86 host machine from which ./flash.sh can be run.

This is extremely annoying. Is there any way to change the pinmux from userspace. LIke through sysfs or something?

2

Just speculating, but if drivers used for given hardware are unloaded prior to making changes, then maybe. Not all of the drivers can be run as modules, but that’s where I’d start…see if all drivers involved can be loaded and unloaded as modules.

3

Does pinmux settings happen in the driver? So, in this case, SPI spidev or spi-tegra114 drivers?

I would think it would happen in the pinctrl driver when it’s loaded. I see some relevant code in pinctrl-tegra.c and pinctrl-utils.c

One approach would be to write a custom module which could do the swap based on some ioctl call. Painful but possible. Just hoping for cleaner and safer alternatives.

4

PINMUX isn’t used in the drivers, but drivers can lock the resource in the same way that files can be locked. My thought is that any attempt to change PINMUX in a running system will require the drivers to be detached…and the best way to guarantee that is to unload the driver. It doesn’t mean you’ll succeed, but this is probably a necessary minimum starting point. Reinsert of the module would then name any command line argument changes related to those resources (if the resources are named as arguments). Having a driver loaded at the time of change might have an effect similar to writing to a pointer which is no longer valid.