Message ID | 20240521-pinctrl-scmi-imx95-v1-0-9a1175d735fd@nxp.com (mailing list archive) |
---|---|
Headers | show |
Series | pinctrl: scmi: support i.MX95 OEM extensions with fsl,pins property | expand |
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>
On Mon, May 27, 2024 at 10:36 AM Peng Fan <peng.fan@nxp.com> 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. > > Are you ok with this patchset? Patch 1 is fine as it's ACKed by the DT maintainers. Patch 2 patches the SCMI pinctrl driver and patch 3 uses module_scmi_driver(), so I cannot merge any of these patches without ACK from the SCMI maintainers. The code in patch 3 looks OK but I will comment on it, no big deal though. Yours, Linus Walleij
Hi Linus, Thanks for your quick response. > Subject: Re: [PATCH 0/3] pinctrl: scmi: support i.MX95 OEM extensions with > fsl,pins property > > On Mon, May 27, 2024 at 10:36 AM Peng Fan <peng.fan@nxp.com> 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. > > > > Are you ok with this patchset? > > Patch 1 is fine as it's ACKed by the DT maintainers. > > Patch 2 patches the SCMI pinctrl driver and patch 3 uses > module_scmi_driver(), so I cannot merge any of these patches without ACK > from the SCMI maintainers. Sudeep, Cristian, May I get your ACK for the patches? > > The code in patch 3 looks OK but I will comment on it, no big deal though. Thanks, I just replied there. Thanks, Peng. > > Yours, > Linus Walleij
> 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
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
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. BTW: would you please also give an ACK for patch 3, because patch 3 uses module_scmi_driver? Thanks, Peng. > > -- > Regards, > Sudeep
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
Hi Linus, > Subject: [PATCH 0/3] pinctrl: scmi: support i.MX95 OEM extensions with > fsl,pins property > Is this patchset good for you to pick up? SCMI and i.MX maintainers has gave A-b and R-b a few days ago. Thanks, Peng.
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
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
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