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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux