TDA4VM: Where to apply PinMux settings

Thomas,

Thomas Dorsch said:

1. I need to apply at least the PinMux-Config for the SPL R5, to be able to access the data storage for loading SYSFW, A72 ATF/OPTEE and depending hardware. (For example OSPI/UFS)

2. I need to apply at least the PinMux-Config for the U-Boot, to be able to access the kernel, dtb and rootfs. For example ethernet for booting over ethernet.

3. In the case that the firmware for MAIN_R5_0_0 requires SPI Port, the required PinMux configuration should be applied by linux kernel, and should not changed by firmware itself via
boardCfg = (BOARD_INIT_PINMUX_CONFIG)   
boardReturn = Board_init(boardCfg);
because changing PinMux configuration after linux booted is not supported.

That is right. We configure the pins of the modules that are exercised/used by the R5 SPL, A72 SPL, A72 u-boot, Linux kernel in the corresponding
places.

That said doing all the pinmux in the Linux side will have some challenges:

1) The firmwares for R5f get loaded at R5 SPL stage really early. That means you need to be aware of which stage your firmware is loaded so that correspondingly the SPL or u-boot or Linux have to configure pinmux upfront for you. This is still doable but the bigger problem is as below.

2) The SPL/u-boot configures pinmuxes as and when needed.

For example: We need to change the voltage of a PMIC that is connected to i2c0. Only when the pmic driver is probed the corresponding
i2c pinmux is configured.

Ex; wkup_i2c0_pins_default in "arch/arm/dts/k3-j721e-r5-common-proc-board.dts".

Is setup when the tps659413 is probed:

&wkup_i2c0 {
        u-boot,dm-spl;
        tps659413a: tps659413a@48 {
                reg = <0x48>;
                compatible = "ti,tps659413";
                u-boot,dm-spl;
                pinctrl-names = "default";
                pinctrl-0 = <&wkup_i2c0_pins_default>;
                clock-frequency = <400000>;

The pinmux are configured only when you have their phandles are populated in the nodes that use them.
Like pinctrl-0 = <&wkup_i2c0_pins_default>; is used by tps659413a.

So when you cannot initialize some pinmux for modules that are not probed by SPL/U-boot you better use the firmware
to set your pinmux.

My suggestion is to configure pinmux where the modules are needed. Otherwise it will be a hack & you will end up debugging
u-boot/SPL/Linux when firmware are not functional.

Hope you got my perspective.

Best Regards,
Keerthy

Thomas Dorsch said:

So first of all the R5 SPL, A72 SPL, A72 u-boot and Linux kernel will change the default PinMux configuration of the SoC.
After linux has boot and MAIN_R5_0-0 firmware has been loaded and started, the PinMux configuration is changed again for usage of i2c0.

This is not right. R5 SPL loads MAIN_R5_0-0 firmware & firmware does pinmux settings needed for the functionality it intends to do.
You should make sure that the same pin configuration is not overwritten by other entities.

Thomas Dorsch said:

Isn't this, technically spoken, a change of PinMux configuration after linux has booted?
I've read somehwere in e2e forum, that this is offical not supported.

This is true for TDA2. The pinmux configuration is all done one time at u-boot due to IODelay.

For the TDA4 that can be done in any place SPL/U-boot/Kernel or even firmware. Hope this answers all your questions."
Please resolve if i have answered all your questions.

Best Regards,
Keerthy

Hi Keerthy,

"This is not right. R5 SPL loads MAIN_R5_0-0 firmware & firmware does pinmux settings needed for the functionality it intends to do.
You should make sure that the same pin configuration is not overwritten by other entities."

Sorry, I think we have a misunderstanding here: In my hypothetical scenario, linux would load and start a custom firmware on MAIN_R5_0_0 via remoteproc. (Pretty late, after linux has booted)
This custom firmware needs to access i2c0.

Where should I put the PinMux configuration for i2c0 for that case?

This was the post which made me thinking not changing PinMux configuration after linux has boot:

"1) No runtime changing of pinmux."

Sorry for asking all these questions.

Very best regards,
Thomas