mbox series

[0/3] pinctrl: scmi: support i.MX95 OEM extensions with fsl,pins property

Message ID 20240521-pinctrl-scmi-imx95-v1-0-9a1175d735fd@nxp.com
Headers show
Series pinctrl: scmi: support i.MX95 OEM extensions with fsl,pins property | expand

Message

Peng Fan (OSS) May 21, 2024, 6:25 a.m. UTC
All:
 There was a v6 that use generic properties, but at a late stage, NXP
 internals decides to switch to fsl,pins property to align with other
 i.MXs. Since new properties, drivers rewrite, I start this patchset
 from v1 with a new patch title. A RFC patch for binding was posted,
 since Rob said he is fine, so post this patchset out.

 Whether v6 or this patchset, patch 2 is a must and was not changed from
 v6.

 The pinctrl stuff has been pending for quite sometime, I would be
 apprecaited if any quick comments.

v6:
 https://lore.kernel.org/all/20240513-pinctrl-scmi-oem-v3-v6-0-904975c99cc4@nxp.com/
RFC:
 https://lore.kernel.org/all/20240520194942.GA1374705-robh@kernel.org/

Thanks,
Peng.

ARM SCMI v3.2 Table 24 Pin Configuration Type and Enumerations:
'192 -255 OEM specific units'.

i.MX95 System Manager FW supports SCMI PINCTRL protocol, but it has zero
functions, groups. So pinctrl-scmi.c could not be reused for i.MX95.
Because nxp,pin-func, nxp,pin-conf properties are rejected by dt
maintainers, so use 'fsl,pins' which requires a new driver
pinctrl-imx-scmi.c

The node will be as below:
pinctrl_usdhc1: usdhc1grp {
	fsl,pins = <
		IMX95_PAD_SD1_CLK__USDHC1_CLK				0x158e
		IMX95_PAD_SD1_CMD__USDHC1_CMD				0x138e
		IMX95_PAD_SD1_DATA0__USDHC1_DATA0			0x138e
		IMX95_PAD_SD1_DATA1__USDHC1_DATA1			0x138e
		IMX95_PAD_SD1_DATA2__USDHC1_DATA2			0x138e
		IMX95_PAD_SD1_DATA3__USDHC1_DATA3			0x138e
		IMX95_PAD_SD1_DATA4__USDHC1_DATA4			0x138e
		IMX95_PAD_SD1_DATA5__USDHC1_DATA5			0x138e
		IMX95_PAD_SD1_DATA6__USDHC1_DATA6			0x138e
		IMX95_PAD_SD1_DATA7__USDHC1_DATA7			0x138e
		IMX95_PAD_SD1_STROBE__USDHC1_STROBE			0x158e
	>;
};

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Peng Fan (3):
      dt-bindings: firmware: arm,scmi: Add properties for i.MX95 Pinctrl OEM extensions
      pinctrl: scmi: add blocklist
      pinctrl: imx: support SCMI pinctrl protocol for i.MX95

 .../devicetree/bindings/firmware/arm,scmi.yaml     |   4 +-
 .../bindings/firmware/nxp,imx95-scmi-pinctrl.yaml  |  53 +++
 drivers/pinctrl/freescale/Kconfig                  |   9 +
 drivers/pinctrl/freescale/Makefile                 |   1 +
 drivers/pinctrl/freescale/pinctrl-imx-scmi.c       | 357 +++++++++++++++++++++
 drivers/pinctrl/pinctrl-scmi.c                     |   9 +
 6 files changed, 432 insertions(+), 1 deletion(-)
---
base-commit: 632483ea8004edfadd035de36e1ab2c7c4f53158
change-id: 20240521-pinctrl-scmi-imx95-867bea9595cf

Best regards,

Comments

Peng Fan May 27, 2024, 8:36 a.m. UTC | #1
Hi Linus, Sudeep, Cristian,

> Subject: [PATCH 0/3] pinctrl: scmi: support i.MX95 OEM extensions with
> fsl,pins property

Sorry if this is an early ping to you. Just wanna this not blocking i.MX95
upstream support.

Are you ok with this patchset? 

Thanks,
Peng.

> 
> All:
>  There was a v6 that use generic properties, but at a late stage, NXP  internals
> decides to switch to fsl,pins property to align with other  i.MXs. Since new
> properties, drivers rewrite, I start this patchset  from v1 with a new patch title.
> A RFC patch for binding was posted,  since Rob said he is fine, so post this
> patchset out.
> 
>  Whether v6 or this patchset, patch 2 is a must and was not changed from  v6.
> 
>  The pinctrl stuff has been pending for quite sometime, I would be
> apprecaited if any quick comments.
> 
> v6:
>  https://lore.kernel.org/all/20240513-pinctrl-scmi-oem-v3-v6-0-
> 904975c99cc4@nxp.com/
> RFC:
>  https://lore.kernel.org/all/20240520194942.GA1374705-robh@kernel.org/
> 
> Thanks,
> Peng.
> 
> ARM SCMI v3.2 Table 24 Pin Configuration Type and Enumerations:
> '192 -255 OEM specific units'.
> 
> i.MX95 System Manager FW supports SCMI PINCTRL protocol, but it has zero
> functions, groups. So pinctrl-scmi.c could not be reused for i.MX95.
> Because nxp,pin-func, nxp,pin-conf properties are rejected by dt maintainers,
> so use 'fsl,pins' which requires a new driver pinctrl-imx-scmi.c
> 
> The node will be as below:
> pinctrl_usdhc1: usdhc1grp {
> 	fsl,pins = <
> 		IMX95_PAD_SD1_CLK__USDHC1_CLK
> 	0x158e
> 		IMX95_PAD_SD1_CMD__USDHC1_CMD
> 	0x138e
> 		IMX95_PAD_SD1_DATA0__USDHC1_DATA0
> 	0x138e
> 		IMX95_PAD_SD1_DATA1__USDHC1_DATA1
> 	0x138e
> 		IMX95_PAD_SD1_DATA2__USDHC1_DATA2
> 	0x138e
> 		IMX95_PAD_SD1_DATA3__USDHC1_DATA3
> 	0x138e
> 		IMX95_PAD_SD1_DATA4__USDHC1_DATA4
> 	0x138e
> 		IMX95_PAD_SD1_DATA5__USDHC1_DATA5
> 	0x138e
> 		IMX95_PAD_SD1_DATA6__USDHC1_DATA6
> 	0x138e
> 		IMX95_PAD_SD1_DATA7__USDHC1_DATA7
> 	0x138e
> 		IMX95_PAD_SD1_STROBE__USDHC1_STROBE
> 	0x158e
> 	>;
> };
> 
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Peng Fan (3):
>       dt-bindings: firmware: arm,scmi: Add properties for i.MX95 Pinctrl OEM
> extensions
>       pinctrl: scmi: add blocklist
>       pinctrl: imx: support SCMI pinctrl protocol for i.MX95
> 
>  .../devicetree/bindings/firmware/arm,scmi.yaml     |   4 +-
>  .../bindings/firmware/nxp,imx95-scmi-pinctrl.yaml  |  53 +++
>  drivers/pinctrl/freescale/Kconfig                  |   9 +
>  drivers/pinctrl/freescale/Makefile                 |   1 +
>  drivers/pinctrl/freescale/pinctrl-imx-scmi.c       | 357
> +++++++++++++++++++++
>  drivers/pinctrl/pinctrl-scmi.c                     |   9 +
>  6 files changed, 432 insertions(+), 1 deletion(-)
> ---
> base-commit: 632483ea8004edfadd035de36e1ab2c7c4f53158
> change-id: 20240521-pinctrl-scmi-imx95-867bea9595cf
> 
> Best regards,
> --
> Peng Fan <peng.fan@nxp.com>
Aisheng Dong May 31, 2024, 8:45 a.m. UTC | #2
> From: Peng Fan (OSS) <peng.fan@oss.nxp.com>
> Sent: 2024年5月21日 14:26
> 
> All:
>  There was a v6 that use generic properties, but at a late stage, NXP  internals
> decides to switch to fsl,pins property to align with other  i.MXs. Since new
> properties, drivers rewrite, I start this patchset  from v1 with a new patch title.
> A RFC patch for binding was posted,  since Rob said he is fine, so post this
> patchset out.
> 
>  Whether v6 or this patchset, patch 2 is a must and was not changed from
> v6.
> 
>  The pinctrl stuff has been pending for quite sometime, I would be
> apprecaited if any quick comments.
> 
> v6:
> 
> https://lore.kernel.org/all/20240513-pinctrl-scmi-oem-v3-v6-0-904975c99cc4
> @nxp.com/
> RFC:
>  https://lore.kernel.org/all/20240520194942.GA1374705-robh@kernel.org/
> 
> Thanks,
> Peng.
> 
> ARM SCMI v3.2 Table 24 Pin Configuration Type and Enumerations:
> '192 -255 OEM specific units'.
> 
> i.MX95 System Manager FW supports SCMI PINCTRL protocol, but it has zero
> functions, groups. So pinctrl-scmi.c could not be reused for i.MX95.
> Because nxp,pin-func, nxp,pin-conf properties are rejected by dt maintainers,
> so use 'fsl,pins' which requires a new driver pinctrl-imx-scmi.c
> 
> The node will be as below:
> pinctrl_usdhc1: usdhc1grp {
> 	fsl,pins = <
> 		IMX95_PAD_SD1_CLK__USDHC1_CLK				0x158e
> 		IMX95_PAD_SD1_CMD__USDHC1_CMD				0x138e
> 		IMX95_PAD_SD1_DATA0__USDHC1_DATA0			0x138e
> 		IMX95_PAD_SD1_DATA1__USDHC1_DATA1			0x138e
> 		IMX95_PAD_SD1_DATA2__USDHC1_DATA2			0x138e
> 		IMX95_PAD_SD1_DATA3__USDHC1_DATA3			0x138e
> 		IMX95_PAD_SD1_DATA4__USDHC1_DATA4			0x138e
> 		IMX95_PAD_SD1_DATA5__USDHC1_DATA5			0x138e
> 		IMX95_PAD_SD1_DATA6__USDHC1_DATA6			0x138e
> 		IMX95_PAD_SD1_DATA7__USDHC1_DATA7			0x138e
> 		IMX95_PAD_SD1_STROBE__USDHC1_STROBE			0x158e
> 	>;
> };
> 
> Signed-off-by: Peng Fan <peng.fan@nxp.com>

For the series:
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>

Regards
Aisheng
Sudeep Holla June 3, 2024, 1:54 p.m. UTC | #3
On Mon, May 27, 2024 at 08:36:27AM +0000, Peng Fan wrote:
> Hi Linus, Sudeep, Cristian,
> 
> > Subject: [PATCH 0/3] pinctrl: scmi: support i.MX95 OEM extensions with
> > fsl,pins property
> 
> Sorry if this is an early ping to you. Just wanna this not blocking i.MX95
> upstream support.
>

I would say yes as this was posted bang in the middle of the merge window.
So it is possible for people to miss this if they are busy otherwise.

I wouldn't have responded in general or if someone is new to the Linux
kernel development. But you are no new to kernel development.

In general I also have a suggestion for you. Avoid churning the dependent
patch series if the base set of patches are not yet reviewed or agreed upon.
I was super confused with the amount of different concurrent but dependent
patch series you had for this whole i.MX SCMI pinmux support. I had ignored
and not responded in the past but thought it would be good to respond in
this thread.

--
Regards,
Sudeep
Sudeep Holla June 4, 2024, 12:11 p.m. UTC | #4
On Tue, Jun 04, 2024 at 12:49:13AM +0000, Peng Fan wrote:
> Hi Sudeep,
>
> > Subject: Re: [PATCH 0/3] pinctrl: scmi: support i.MX95 OEM extensions with
> > fsl,pins property
> >
> > On Mon, May 27, 2024 at 08:36:27AM +0000, Peng Fan wrote:
> > > Hi Linus, Sudeep, Cristian,
> > >
> > > > Subject: [PATCH 0/3] pinctrl: scmi: support i.MX95 OEM extensions
> > > > with fsl,pins property
> > >
> > > Sorry if this is an early ping to you. Just wanna this not blocking
> > > i.MX95 upstream support.
> > >
> >
> > I would say yes as this was posted bang in the middle of the merge window.
> > So it is possible for people to miss this if they are busy otherwise.
> >
> > I wouldn't have responded in general or if someone is new to the Linux kernel
> > development. But you are no new to kernel development.
> >
> > In general I also have a suggestion for you. Avoid churning the dependent
> > patch series if the base set of patches are not yet reviewed or agreed upon.
> > I was super confused with the amount of different concurrent but dependent
> > patch series you had for this whole i.MX SCMI pinmux support. I had ignored
> > and not responded in the past but thought it would be good to respond in
> > this thread.
>
> Thanks for your suggestion.  I tried to do different implementations that
> could make all of us agree, so it was indeed many versions with different
> implementations. Sorry. I will improve.
>

Thanks and sorry again if it is harsh but it was indeed confusing.

> BTW: would you please also give an ACK for patch 3, because patch 3 uses
> module_scmi_driver?

Done.

--
Regards,
Sudeep
Linus Walleij June 8, 2024, 9:35 a.m. UTC | #5
On Tue, May 21, 2024 at 8:17 AM Peng Fan (OSS) <peng.fan@oss.nxp.com> wrote:

>  There was a v6 that use generic properties, but at a late stage, NXP
>  internals decides to switch to fsl,pins property to align with other
>  i.MXs. Since new properties, drivers rewrite, I start this patchset
>  from v1 with a new patch title. A RFC patch for binding was posted,
>  since Rob said he is fine, so post this patchset out.
>
>  Whether v6 or this patchset, patch 2 is a must and was not changed from
>  v6.
>
>  The pinctrl stuff has been pending for quite sometime, I would be
>  apprecaited if any quick comments.
>
> v6:
>  https://lore.kernel.org/all/20240513-pinctrl-scmi-oem-v3-v6-0-904975c99cc4@nxp.com/
> RFC:
>  https://lore.kernel.org/all/20240520194942.GA1374705-robh@kernel.org/

Patches applied.

Yours,
Linus Walleij
Peng Fan June 13, 2024, 6:30 a.m. UTC | #6
Hi Linus,

> Subject: Re: [PATCH 0/3] pinctrl: scmi: support i.MX95 OEM extensions with
> fsl,pins property
> 
> On Tue, May 21, 2024 at 8:17 AM Peng Fan (OSS) <peng.fan@oss.nxp.com>
> wrote:
> 
> >  There was a v6 that use generic properties, but at a late stage, NXP
> > internals decides to switch to fsl,pins property to align with other
> > i.MXs. Since new properties, drivers rewrite, I start this patchset
> > from v1 with a new patch title. A RFC patch for binding was posted,
> > since Rob said he is fine, so post this patchset out.
> 
> Patches applied.

Just checked your repo in git.kernel.org, not see the patches.
No big deal, just wonder if they got forgotten.

Thanks,
Peng.

> 
> Yours,
> Linus Walleij
Linus Walleij June 18, 2024, 10:12 a.m. UTC | #7
On Thu, Jun 13, 2024 at 8:30 AM Peng Fan <peng.fan@nxp.com> wrote:

> Just checked your repo in git.kernel.org, not see the patches.
> No big deal, just wonder if they got forgotten.

I had to figure out some bureaucracy around the git branches, it should
be there now.

Yours,
Linus Walleij