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

From: Sudeep Holla <sudeep.holla@arm.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
	oleksii_moisieiev@epam.com, Sudeep Holla <sudeep.holla@arm.com>,
	aisheng.dong@nxp.com, festevam@gmail.com, ping.bai@nxp.com,
	s.hauer@pengutronix.de, shawnguo@kernel.org,
	kernel@pengutronix.de, linux-imx@nxp.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
	Peng Fan <peng.fan@nxp.com>
Subject: Re: [RFC] scmi: pinctrl: support i.MX9
Date: Thu, 24 Aug 2023 11:51:37 +0100	[thread overview]
Message-ID: <20230824105137.xqkwi4xvmjoidexh@bogus> (raw)
In-Reply-To: <CACRpkdYU7MRXRV3Uw1w300sdxv=9XT=P1vFFarHfpSM6BT20Hg@mail.gmail.com>

Hi Linus,

Thanks a lot for the quick response.

On Thu, Aug 24, 2023 at 10:43:20AM +0200, Linus Walleij wrote:
> On Thu, Aug 24, 2023 at 9:01 AM Peng Fan (OSS) <peng.fan@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.
>

Good to know.

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

Correct.

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

Agreed.

I don't have much knowledge on generic pinmux conf and suggested Peng
to post the RFC to start the discussion instead of getting blocked by me
during some internal/private discussions as the main intention for him
was upstreaming the changes. I am against the idea of mixing platform
specific changes the way it is done here but since I didn't have much
knowledge on pinmux conf to suggest/provide any useful feedback I suggested
to trigger this discussion.

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

+1

-- 
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel