Example devicetrees and reserved bit

Technical Support
, , ,
1

Hi,

I was wondering about the following. In some of your device-trees for Linux kernel, such as imx8mp-verdin.dtsi, pinctrl settings are used that have bit 30 set. For example. the hdmihoggrp:


	pinctrl_hdmi_hog: hdmihoggrp {
		fsl,pins = <
			MX8MP_IOMUXC_HDMI_CEC__HDMIMIX_HDMI_CEC		0x40000019	/* SODIMM 63 */
			MX8MP_IOMUXC_HDMI_DDC_SCL__HDMIMIX_HDMI_SCL	0x400001c3	/* SODIMM 59 */
			MX8MP_IOMUXC_HDMI_DDC_SDA__HDMIMIX_HDMI_SDA	0x400001c3	/* SODIMM 57 */
			MX8MP_IOMUXC_HDMI_HPD__HDMIMIX_HDMI_HPD		0x40000019	/* SODIMM 61 */
>;
	};

If I check that imx8mp datasheet, I see that the CTL pad descriptions lists bit 31-5 are reserved. For CEC pin for example:

image
image1492×1381 157 KB

Is it known what this bit does, and why it is set in the device tree?

Kind regards,

Mathijs

2

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Hello!

For i.MX-based modules, bit 31 in the pin configuration cell is crucial as it prevents the IOMUXC from altering the pad control register. This bit acts as a special control separate from the pad settings. You can find more details about this in the Toradex documentation for i.MX7 and i.MX6ULL modules.

Additionally, bit 30 is used to set the SION (Software Input On) bit, which is also documented in the same resources.

Here’s an example of how this pattern is used in a device tree configuration:

&iomuxc {
    pinctrl_can_int: canintgrp {
        fsl,pins = <
            MX6UL_PAD_ENET1_TX_DATA1__GPIO2_IO04    0x13010 /* SODIMM 73 */
        >;
    };
};

The hexadecimal value in the last cell includes these control bits along with other pin settings. For more detailed information on pin configuration specific to your SoC, it’s advisable to consult the datasheet and reference manual for your specific module, as the exact meaning of reserved bits may vary between different i.MX variants.

I hope this helps clarify the pin configuration process for your i.MX module.

Best regards,
Toradex AI Assistant.

3

Hi @mathijs !

@ToradexAI mixed iMX6 and iMX7-based modules. It doesn’t help here :sweat_smile:

You have a very good question. And AFAIK we might not have the answer.

I think that we just “inherited” it from NXP (even though we created imx8mp-verdin.dtsi ourselves, we don’t necessarily redo everything from scratch).

As you can see below, NXP’s EVK for i.MX8M Plus does the same thing…

Looking at git blame of the file below, it is not clear why those reserved bits are set.

Anyway, I will ask internally at Toradex if anyone has ever looked into why it is like this (although my hopes are not high :sweat_smile:)

Best regards,

4

Hi @henrique.tx,

Thank you for your reply. With the reply from the Toradex AI, I looked a bit further in how the kernel reads this value from the pinctl. Although its reply wasn’t fully correct, it did lead me to this part in pinctrl-imx.c:

    if (info->generic_pinconf) {
        /* generic pin config decoded */
        pin_mmio->config = imx_pinconf_parse_generic_config(np, ipctl);
    } else {
        /* legacy pin config read from devicetree */
        config = be32_to_cpu(*list++);
 
        /* SION bit is in mux register */
        if (config & IMX_PAD_SION)
            pin_mmio->mux_mode |= IOMUXC_CONFIG_SION;
        pin_mmio->config = config & ~IMX_PAD_SION;
    }

With IMX_PAD_SION being set to 31. So it seems, that this bit is indeed (mis)used to set the SION in the muxmode. And that it is cleared when writing to the pin config, and thus not applied to that register.

Kind regards,

Mathijs

5

Hi @mathijs !

Nice investigation :slight_smile:

With that, I understand your question is solved, right?

Please feel free to mark your message as the Solution :wink:

Best regards,