On Thu, Aug 24, 2023 at 9:01 AM Peng Fan (OSS) <peng.fan@xxxxxxxxxxx> 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