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

[Linus Walleij <linus.walleij@linaro.org>]

On Thu, Aug 24, 2023 at 2:47 PM Peng Fan <peng.fan@nxp.com> wrote:
> Me:

>> 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.

Yeah I understood as much. But I don't think that the firmware is
really filtering any of the access, it will just poke into any pinctrl
register as instructed anyway so what's the point. Just looks like
a layer of indirection. But I'm not your system manager, so it's not
my decision.

> 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.

The SCMI people will have to state their position on this.
Like what they consider conformance and what extensions are
allowed. This is more a standardization question than an
implementation question so it's not really my turf.

I was under the impression that the ambition with SCMI firmware
was to abstract away and hide aspects of the hardware behind
a consistent API. This approach drives a truck through that
idea.

Yours,
Linus Walleij