imx8qxp: can mux_mode be set just via linux dts, or must it be set via u-boot or scfw first?

[petero5]

Hi

iMX8Ximx8qxp
Can mux_mode be set just via linux dts, or must it be set via u-boot or scfw first?
Is it enough to set bits 29-27 (mux-mode) in the linux device tree pinctrl?
Or do we have to have already set this via the SCFW?

Example, looking at IMX8DQXPRM
pad/mux control for R35 SPI0_CS1
mux_mode
100b - LSIO_GPIO1_IO07

The .dts output for that by Config Tools for i.MX is
- {pin_num: R35, peripheral: LSIO__GPIO1, signal: 'gpio_io, 07', pin_signal: SPI0_CS1, direction: OUTPUT}
SC_P_SPI0_CS1_LSIO_GPIO1_IO07 0x00000040

That bit field has the default mux_mode 000b rather 100b, which should make it 0x20000040?

But some other pins do include the mux_mode in the bit field, like
- {pin_num: B24, peripheral: LSIO__GPIO4, signal: 'gpio_io, 19', pin_signal: USDHC1_RESET_B, PULL: PULL_1, PDRV: PDRV_1}
SC_P_USDHC1_RESET_B_LSIO_GPIO4_IO19 0x20000021

Why do some non-default muxed pins have the mux_mode in the hex and others don't?
And is it enough to add it to the linux device tree, or do we have to do it in the SCFW too?
Or do we have to write 1 to update_mux_mode in the SCFW?

Which documentation explains this clearly please?

Thank you
-- Peter

[brian14]

Hi @petero5, 

The device tree must be configured in the Linux Device Tree file (.dts and .dtsi).
Here you will need to change the mux_mode bits in the proper register.

About the relation of dts files with the Reference Manual, sometimes there is no relation with the default values in the Reference Manual. But it is important to correctly follow the diagram and fields detailed in the same document.

I will attach a link to the Code Aurora which is a repository for Device Tree files based on NXP EVKs.

Link: freescale\dts\boot\arm64\arch - linux-imx - i.MX Linux kernel (codeaurora.org)

For example, this is a part of device tree for iMX8QXP.

In pinctrl_i2c0_mipi_lvds0: mipi_lvds0_i2c0_grp > "IMX8QXP_MIPI_DSI1_I2C0_SCL_MIPI_DSI1_I2C0_SCL" with a value of 0xc6000020. You will need to find this register in the IOMUX memory map and then apply the changes in this file.

Finally, unfortunately, there are no documents or training for this topic.

Let me know if you have any further questions or if there's anything else I can help you with.

Best regards, Brian.

[petero5]

Hi Brian

Thank you for the reply.
I'm still unsure about a couple of things:
For example in IMX8DQXPRM.pdf
i.MX 8DualX/8DualXPlus/8QuadXPlus Applications Processor Reference Manual, Rev. 0, 05/2020

9.2.5.1.104.2 Function
pad/mux control for SPI0_CS1
31 update_mux_mode update lock for mux control
write 1 to allow programming to mux control [29:19]
30 update_pad_ctl update lock for pad control
write 1 to allow programming to pad control [14-1:0]
29-27 mux_mode
100b - LSIO_GPIO1_IO07

With bits 31=0b, 30=0b and 29-27=100b that would be 0x20...
With bits 31=1b, 30=1b and 29-27=100b that would be 0xE0...

But the .dts that the Config Tools for i.MX generates is
- {pin_num: R35, peripheral: LSIO__GPIO1, signal: 'gpio_io, 07', pin_signal: SPI0_CS1, direction: OUTPUT, update_mux_mode: update_mux_mode_0}
SC_P_SPI0_CS1_LSIO_GPIO1_IO07 0x00000040

i.e. I've told the tool that for R35 I want
peripheral: LSIO__GPIO1, signal: 'gpio_io, 07'
but it gives me 0x00000040 rather than 0x20000040?

Do I need to do something else in the tool to make the tool give me 0x20... rather than 0x00... or do I always need to hand edit this?

Also, what does this mean:
31 update_mux_mode update lock for mux control
write 1 to allow programming to mux control

When do I need to use that?
Do I need to set that bit too in order for 29-27 mux_mode to actually work?
Or does that apply to a different situation?
I searched the doc for update_mux_mode but can't find anything that explains what "allow programming to mux control" actually means?

Thank you very much
-- Peter

[brian14 · Accepted solution]

Hi @petero5, 

Is correct that is not the right value, you can use the "Registers" section as follow to use the correct value:

Config Tools Reference Manual contains a note as follow:

"Tool generated board-oriented device tree (DTS) DTSI file is only a snippet and not a full device tree file content. There are just basic device tree elements, initial skeleton, and processor-specific "pinfunc.h" includes together with functional groups of fsl, pins = content definitions which provide the initial IOMUXC module configuration according to the tool UI defined pin routing and functional configurations. Content itself must be manually merged together with existing Linux BSP device tree file(s) in order to apply the tool generated pins configuration. This tool also does not generate nor export processor-specific "pinfunc.h" file that is containing definition of all supported DTS pin functional configuration macros. This file is not purposely integrated within the tool output because it is a part of separate Linux BSP support package deliverables. "

I hope this information will be helpful.

Have a great day.

Best regards, Brian.

[petero5]

Hi Brian

Thank you.
So if I understand correctly, the docs say that the .dts from the tool "provide the initial IOMUXC module configuration according to the tool UI defined pin routing and functional configurations".
However, the Config Tool does not actually set update_mux_mode, update_pad_ctl, mux_mode in the .dts.
Therefore we need to do this manually when using a non-default pin mux.
And IMX8DQXPRM.pdf the Registers tab can be used as a reference to set these correctly.

Thank you
-- Peter

[petero5]

scfw board.c
pad_force_mux(SC_P_SPI0_CS1, 4U, SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF);

fixes the issue.
However still vague on best practices, how SCFW and u-boot and linux device trees should work together.
Any docs/worked examples for pads that are using alternative mux_mode please?

Thank you