I’m kind of exploring this too, and I do not have a complete answer. Some information might help you though.
Take a look at kernel source:
Search for “spi”. These “spi” entries occur related to “function”, while the containing struct has a name which relates to the physical chip. Before going further, look at the schmatic, search for “j3a1”, e.g.:
On the schematic page listing J3A1, find “TS_SPI_CS_L” shown to connect to J3A1 pin 6. This is where one of the SPI interfaces connect to. Search for “TS_SPI_CS_L” in the schematic to find the physical pin on the tegra124 chip itself. You’ll find this connects to U3C1 ball grid array (I believe the tegra124 is the only ball grid array on the board). The function is listed as ULPI_STP.
Now go back to tegra124-jetson_tk1-pinmux-pm375-0000-c00-00.dtsi. Search (case insensitive) for ulpi_stp. You find this:
nvidia,pins = "ulpi_stp_py3";
nvidia,function = "spi1";
nvidia,pull = <TEGRA_PIN_PULL_NONE>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,enable-input = <TEGRA_PIN_DISABLE>;
Note the “_py3” addition to the name “ulpi_stp”. This would be the marker of a specific controller or specific pin. In GPIO it is a bit more clear because because the TRM chapter on GPIO uses a naming convention which directly corresponds to a header file. A file which specifically uses this designation of ulpi_stp_py3 which is specific to the tegra124 chip:
The line in that file is:
#define TEGRA_PIN_ULPI_STP_PY3 _GPIO(195)
Now one has to go back and find out what _GPIO(195) corresponds to. This in turn refers to naming defined in:
#define TEGRA_GPIO_PY3 195
The PY3 can be found in TRM under GPIO (chapter 8, mult-purpose I/O). There are multiple GPIO controllers, each controller has a repeating theme, and individual controller determines part of the PY3 designation, while specific GPIO pins of the controller determine the rest (certain bits of GPIO controller may set up the pin as SPI, referring to specific controller as something such as SPI2). Looking at the gpio-tegra.h defines, notice this pattern:
Unfortunately, 0x7000d600 is not a GPIO controller, so the specific parts of TRM and GPIO I’m familiar with won’t give the information you need. The method of finding that information should be the same as finding GPIO pin information. However, the use of paths in /sys containing a controller physical address leads to clues, e.g.:
find /sys -name '*7000d600*
It’s much easier to find out such information when you have the actual hardware attached, as this leads to /sys updating.