RE: [RFC] scmi: pinctrl: support i.MX9

[Peng Fan <peng.fan@xxxxxxx>]

Hi Linus,

Thanks for quick reply.

> Subject: Re: [RFC] scmi: pinctrl: support i.MX9
> 
> 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, 

Right.

it is merely making things more complex and also slower
> bymaking the registers only accessible from this SCMI link.

This is for safety reason, the pinctrl hardware must be handled
by a system manager entity. So mmio direct access not allowed
from Cortex-A side.

The SCMI firmware is very straightforward, there is no group or
function.

It just accepts the format as this:
MUX_TYPE, MUX VALUE, CONF_TYPE, CONF_VAL, DAISY_TYPE,
DAISY ID, DAISY_CFG, DAISY_VALUE.

Similar as linux MMIO format.

Our i.MX95 platform will support two settings, one with SCMI
firmware, one without SCMI. These two settings will share
the same pinctrl header file.

And to simplify the scmi firmware design(anyway I am not owner
of the firmware), to make pinctrl header shared w/o scmi,
we take the current in-upstream freescale imx binding format.

Thanks,
Peng.
 
> 
> But I could have misunderstood it, so please correct me!
> 
> Yours,
> Linus Walleij