[RFC] scmi: pinctrl: support i.MX9

Linus Walleij linus.walleij at linaro.org
Thu Aug 24 01:43:20 PDT 2023


On Thu, Aug 24, 2023 at 9:01 AM Peng Fan (OSS) <peng.fan at oss.nxp.com> wrote:

> This patch is just to introduce i.MX support to see whether people have
> comments for the design.

Very interesting!

> The binding format:
> <mux_reg conf_reg input_reg mux_mode input_val>
> dts:
>         pinctrl_uart1: uart1grp {
>                 fsl,pins = <
>                         MX93_PAD_UART1_RXD__LPUART1_RX                  0x31e
>                         MX93_PAD_UART1_TXD__LPUART1_TX                  0x31e
>                 >;
>         };
>
> i.MX pinctrl not use generic pinconf, this has been agreeed by
> maintainers before.

Yes, it has historical reasons.

> So after moving to SCMI, we will still
> keep the same binding format, and i.MX SCMI firmware also use same
> format when configure registers. So we need to use i.MX specific
> dt_node_to_map function.

I thought the idea with SCMI was to abstract and hide the characteristics of
the underlying hardware. I.e. the firmware is to present groups and
functions and generic config options and then the driver will use these.

This patch, it seems, creates a hybrid between the old freescale driver
and the SCMI firmware communication link where the SCMI is just a
transport mechanism to something inside SCMI that poke the same
registers that userspace could poke, if it could only access these
registers.

I.e using SCMI on this platform isn't creating any abstraction of the
pin control hardware, it is merely making things more complex and
also slower bymaking the registers only accessible from this SCMI link.

But I could have misunderstood it, so please correct me!

Yours,
Linus Walleij



More information about the linux-arm-kernel mailing list