so for all pins that is defined in pinmux sheet its gpio name is GPIO3_P part of the name,i can pick GPIO name from here,right?
so for GPIO9_MOTION_INT ,GPIO is AA.02
for AA pin AON GPIO controller: #define TEGRA_AON_GPIO_PORT_AA 5
so actual GPIO number in tegra device i can calculate is = 256 + 5*8 +2 =398
The same way i can calculate all pins GPIO number for tegra device,is it correct?
one thing i want to ask,if i have to change any pin configuration in pin mux spread sheet,so should i do changes in spread sheet and generate .cfg file or we can directly do changes in pinmux .cfg file???
As per my custom board design i want to change pinmux file…tegra186-mb1-bct-pinmux-quill-p3489-1000-a00.cfg
Thanks for the explanation it is really very helpful.
one thing i want to ask for this pin mux sheet of TX2 ,this sheet is for TX2 EVK.
I have my own customized board in which i have used TX24GB module,so i need to update this pin mux sheet as per my custom board right?
And after that i need to create .cfg file with customized pin mux sheet.
Yes, the pinmux spreadsheet is for the default Jetson TX2 Development Kit.
It all depends how far you have deviated from the Jetson TX2 Development Kit design. If you have made minor changes, you may be able to make those in the DT and delay their initialization/configuration till the kernel boots. If you have made significant changes and need them early in the boot process, you would want to utilize the latest NVIDIA pinmux spreadsheet as your starting point and make your changes in the pinmux spreadsheet. Following all of your changes you use the built-in spreadsheet macro/button to generate the DTSI files. There should be plenty of information in the NVIDIA documentation and other forum posts to walk you step-by-step through the process of regenerating the pinmux .cfg file and programming it to your board.
There is a GPIO1_CAM_PWR#/F7 that is mapped to GPIO N.02. That is very close to your name.
Remember your interfacing with a SoM. Not every signal/pin on the SoM makes its way back to the Tegra X2 SoC. If a particular SoM pin is the output from the PMIC or a power supply (i.e., charging status, reset, etc.) they aren’t going to have SoC pins nor will they be controllable as GPIOs. Both CHARGER_PRSNT# and RESET_OUT# seem to me to be signals that would be exclusively driven by hardware components such as a PMIC. I would not be surprised if they don’t go all the way back to the SoC and they do not have a controllable GPIO associated with them.