Accessing GPIOs of Camera interface


according to,

I can access the 2 CSI camera interface pins as a GPIOs, however I don’t know how, what is the sysfs filename for those GPIOs.

Like GPIO_PU0 , its sysfs filename is gpio160, so how I can list the available GPIOs of the csi camera pins.

Could this pins used as I/O of just output, and what is ST & CZ I/O types?

Also Could I use GPIO_PH2, GPIO_PK2, and many others as GPIOs, what are there sysfs filename?


Not all GPIO show up under sysfs…if a GPIO is configured for some other functionality (many have alternate specific functions) they aren’t really GPIO in the eyes of sysfs. For knowing what possible special purpose conflict is possible you have to dig into the pinmux.

Within the kernel source this file shows you the defines for mapping with the Tegra K1 TRM document…numbers in that document match the numbers of the define and the naming within the TRM:


There are three important locations within sysfs related to GPIO:

/sys/kernel/debug/gpio  # An information file
/sys/class/gpio/        # Contains active GPIO related files
/sys/class/gpio/export  # A control file

Looking at the kernel’s current idea of GPIO is via:

cat /sys/kernel/debug/gpio

Just as an example the default on R19.2 startup is that GPIO PU1 (the kernel source #define is 161) is not active so far as Linux drivers are concerned. This happens to already be pinmux’d as GPIO because it was not set up elsewhere as non-GPIO…which means it can be activated when desired and placed into the cat output of /sys/kernel/debug/gpio at any time by a simple echo of it’s #define number:

echo 161 > /sys/class/gpio/export

If you go back to cat the kernel/debug/gpio you will see 161 now shows up and it is categorized as sysfs (when pinmux’d with a different driver consuming the I/O the category will show differently in this cat output, e.g., 59 shows as panel rst). At the same time that 161 is echoed into the export file a symbolic link named “gpio161” shows up in /sys/class/gpio/. Within that subdirectory characteristics of GPIO_PU1 are controllable via echo, e.g., setting the GPIO here for output and setting its value to on:

echo out > /sys/class/gpio/gpio161/direction
echo 1 > /sys/class/gpio/gpio161/value

…once this is done a volt meter on connector J3A2 pin 43 will show +1.8V. Echo of “0” to the value file will send the volt meter back to 0V.

If you were to look at the TRM a possible conflict for pinmux would be use of the pin for “TXD” output of “UART A”…this never happened and so there is no conflict with immediately using GPIO_PU1 without removing some prior setup.

As for CSI GPIO it is possible that so long as no driver has actually been loaded to use those GPIO those same GPIO should be ready for use as non-specific GPIO. In the cat of my kernel/debug/gpio I did not see “160” listed…after echo of 160 to export it shows up as category sysfs and seems generally available…the catch is that some drivers may interfere when loaded.

You may also find some kernel source files of interest here (the SoC is a tegra124, the physical board of a Jetson is a pm375):


Note that files there are related to the flattened device tree blob and device enumeration at start of boot.

Thanks for your detailed reply, now it’s working as I/O, kindly what is ST & CZ I/O types?

Both are multi-purpose pinmux’ble I/O pads with function being selectable.

CZ is “controlled output impedance”. The faster CPUs become the more the circuit board traces need to be treated as a precision radio transmission line…CZ has some ability to be tailored to different trace designs at the highest possible speeds (it is more flexible for RF design issues). Impedance requirement adjustments are done through programming.

ST is a standard multi-purpose pad and does not have any ability to programatically alter impedance and RF characteristics…circuit board RF design traits are fixed.