| Message ID | 20191213160542.15757-1-aford173@gmail.com |
|---|---|
| Headers | show |
| Series | soc: imx: Enable additional functionality of i.MX8M Mini | expand |
On Fri, Dec 13, 2019 at 10:05 AM Adam Ford <aford173@gmail.com> wrote: > > The GPCv2 controller on the i.MX8M Mini is compatible with the driver > used for the i.MX8MQ except for the register locations and names. > The GPCv2 controller is used to enable additional periperals currently > unavailable on the i.MX8M Mini. In order to make them function, > the GPCv2 needs to be adapted so the drivers can associate their > power domain to the GPCv2 to enable them. > > This series makes one include file slightly more generic, > adds the iMX8M Mini entries, updates the bindings, adds them > to the device tree, then associates the new power domain to > both the OTG and PCIe controllers. > > Some peripherals may need additional power domain drivers in the future > due to limitations of the GPC driver, but the drivers for VPU and others are > not available yet. Before I do a V3 to address Rob's comments, I am thinking I'll drop the items on the GPC that Jacky suggested would not work, and we don't have drivers for those other peripherals (GPU, VPU, etc.) anyway. My main goal here was to try and get the USB OTG ports working, so I'd like to enabled enough of the items on the GPC that are similar to the i.MX8MQ and leave the more challenging items until we have either a better driver available and/or actual peripheral support coming. I haven't seen LCDIF or DSI drivers pushed upstream yet, so I doubt we'll see GPU or VPU yet until those are done. Does anyone from the NXP team have any other comments/concerns? adam > > Adam Ford (7): > soc: imx: gpcv2: Rename imx8mq-power.h to imx8m-power.h > soc: imx: gpcv2: Update imx8m-power.h to include iMX8M Mini > soc: imx: gpcv2: add support for i.MX8M Mini SoC > dt-bindings: imx-gpcv2: Update bindings to support i.MX8M Mini > arm64: dts: imx8mm: add GPC power domains > ARM64: dts: imx8mm: Fix clocks and power domain for USB OTG > arm64: dts: imx8mm: Add PCIe support > > .../bindings/power/fsl,imx-gpcv2.txt | 6 +- > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 127 ++++++++- > arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +- > drivers/soc/imx/gpcv2.c | 246 +++++++++++++++++- > .../power/{imx8mq-power.h => imx8m-power.h} | 14 + > 5 files changed, 387 insertions(+), 8 deletions(-) > rename include/dt-bindings/power/{imx8mq-power.h => imx8m-power.h} (57%) > > -- > 2.20.1 >
> -----Original Message----- > From: Adam Ford <aford173@gmail.com> > Sent: Saturday, December 21, 2019 11:07 PM > To: arm-soc <linux-arm-kernel@lists.infradead.org> > Cc: Peng Fan <peng.fan@nxp.com>; Jacky Bai <ping.bai@nxp.com>; Rob > Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; > Shawn Guo <shawnguo@kernel.org>; Sascha Hauer > <s.hauer@pengutronix.de>; Pengutronix Kernel Team > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; > dl-linux-imx <linux-imx@nxp.com>; devicetree <devicetree@vger.kernel.org>; > Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Leonard Crestez > <leonard.crestez@nxp.com> > Subject: Re: [PATCH V2 0/7] soc: imx: Enable additional functionality of > i.MX8M Mini > > On Fri, Dec 13, 2019 at 10:05 AM Adam Ford <aford173@gmail.com> wrote: > > > > The GPCv2 controller on the i.MX8M Mini is compatible with the driver > > used for the i.MX8MQ except for the register locations and names. > > The GPCv2 controller is used to enable additional periperals currently > > unavailable on the i.MX8M Mini. In order to make them function, the > > GPCv2 needs to be adapted so the drivers can associate their power > > domain to the GPCv2 to enable them. > > > > This series makes one include file slightly more generic, adds the > > iMX8M Mini entries, updates the bindings, adds them to the device > > tree, then associates the new power domain to both the OTG and PCIe > > controllers. > > > > Some peripherals may need additional power domain drivers in the > > future due to limitations of the GPC driver, but the drivers for VPU > > and others are not available yet. > > Before I do a V3 to address Rob's comments, I am thinking I'll drop the items > on the GPC that Jacky suggested would not work, and we don't have drivers > for those other peripherals (GPU, VPU, etc.) anyway. My main goal here was > to try and get the USB OTG ports working, so I'd like to enabled enough of the > items on the GPC that are similar to the i.MX8MQ and leave the more > challenging items until we have either a better driver available and/or actual > peripheral support coming. I haven't seen LCDIF or DSI drivers pushed > upstream yet, so I doubt we'll see GPU or VPU yet until those are done. > > Does anyone from the NXP team have any other comments/concerns? > If you look into NXP's release code, you will find that it is not easy to handle the power domain more generically in GPCv2 driver for imx8mm. That's the reason why we use SIP service to handle all the power domain in TF-A. we tried to upstream the SIP version power domain that can be reused for all i.MX8M, but rejected by ARM guys. they think we need to use SCMI to implement it. as there is no SCMI over SMC available, upstream is on the way, so the power domain for i.MX8MM/MN is pending. Actually, I am confused why we can't use SIP service, even if the SCMI over SMC is ready in the future, It seems the SMCC function ID still need to choose from SIP service function id bank. Another concern for adding power domain support in GPCv2 is that, each time a new SOC is added, we need to add hundred lines of code in GPCv2 driver. it is not a best way to keep driver reuse. The GPCv2 driver is originally used for i.MX7D, then reused by i.MX8MQ, as i.MX8MQ has very simple power domain design as i.MX7D. But for i.MX8MM, it is not the case. There is another concern, we don't want to export GPC module to rich OS side, it is not a must. BR Jacky Bai > adam > > > > Adam Ford (7): > > soc: imx: gpcv2: Rename imx8mq-power.h to imx8m-power.h > > soc: imx: gpcv2: Update imx8m-power.h to include iMX8M Mini > > soc: imx: gpcv2: add support for i.MX8M Mini SoC > > dt-bindings: imx-gpcv2: Update bindings to support i.MX8M Mini > > arm64: dts: imx8mm: add GPC power domains > > ARM64: dts: imx8mm: Fix clocks and power domain for USB OTG > > arm64: dts: imx8mm: Add PCIe support > > > > .../bindings/power/fsl,imx-gpcv2.txt | 6 +- > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 127 ++++++++- > > arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +- > > drivers/soc/imx/gpcv2.c | 246 > +++++++++++++++++- > > .../power/{imx8mq-power.h => imx8m-power.h} | 14 + > > 5 files changed, 387 insertions(+), 8 deletions(-) rename > > include/dt-bindings/power/{imx8mq-power.h => imx8m-power.h} (57%) > > > > -- > > 2.20.1 > >
On Sun, Dec 22, 2019 at 2:33 AM Jacky Bai <ping.bai@nxp.com> wrote: > > > -----Original Message----- > > From: Adam Ford <aford173@gmail.com> > > Sent: Saturday, December 21, 2019 11:07 PM > > To: arm-soc <linux-arm-kernel@lists.infradead.org> > > Cc: Peng Fan <peng.fan@nxp.com>; Jacky Bai <ping.bai@nxp.com>; Rob > > Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; > > Shawn Guo <shawnguo@kernel.org>; Sascha Hauer > > <s.hauer@pengutronix.de>; Pengutronix Kernel Team > > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; > > dl-linux-imx <linux-imx@nxp.com>; devicetree <devicetree@vger.kernel.org>; > > Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Leonard Crestez > > <leonard.crestez@nxp.com> > > Subject: Re: [PATCH V2 0/7] soc: imx: Enable additional functionality of > > i.MX8M Mini > > > > On Fri, Dec 13, 2019 at 10:05 AM Adam Ford <aford173@gmail.com> wrote: > > > > > > The GPCv2 controller on the i.MX8M Mini is compatible with the driver > > > used for the i.MX8MQ except for the register locations and names. > > > The GPCv2 controller is used to enable additional periperals currently > > > unavailable on the i.MX8M Mini. In order to make them function, the > > > GPCv2 needs to be adapted so the drivers can associate their power > > > domain to the GPCv2 to enable them. > > > > > > This series makes one include file slightly more generic, adds the > > > iMX8M Mini entries, updates the bindings, adds them to the device > > > tree, then associates the new power domain to both the OTG and PCIe > > > controllers. > > > > > > Some peripherals may need additional power domain drivers in the > > > future due to limitations of the GPC driver, but the drivers for VPU > > > and others are not available yet. > > > > Before I do a V3 to address Rob's comments, I am thinking I'll drop the items > > on the GPC that Jacky suggested would not work, and we don't have drivers > > for those other peripherals (GPU, VPU, etc.) anyway. My main goal here was > > to try and get the USB OTG ports working, so I'd like to enabled enough of the > > items on the GPC that are similar to the i.MX8MQ and leave the more > > challenging items until we have either a better driver available and/or actual > > peripheral support coming. I haven't seen LCDIF or DSI drivers pushed > > upstream yet, so I doubt we'll see GPU or VPU yet until those are done. > > > > Does anyone from the NXP team have any other comments/concerns? > > > > If you look into NXP's release code, you will find that it is not easy to handle the > power domain more generically in GPCv2 driver for imx8mm. That's the reason why we use > SIP service to handle all the power domain in TF-A. we tried to upstream the SIP version > power domain that can be reused for all i.MX8M, but rejected by ARM guys. they think > we need to use SCMI to implement it. as there is no SCMI over SMC available, upstream is > on the way, so the power domain for i.MX8MM/MN is pending. > Thank you for the background. I appreciate it. > Actually, I am confused why we can't use SIP service, even if the SCMI over SMC is ready in > the future, It seems the SMCC function ID still need to choose from SIP service function id bank. > > Another concern for adding power domain support in GPCv2 is that, each time a new > SOC is added, we need to add hundred lines of code in GPCv2 driver. it is not a best way > to keep driver reuse. The GPCv2 driver is originally used for i.MX7D, then reused by i.MX8MQ, > as i.MX8MQ has very simple power domain design as i.MX7D. But for i.MX8MM, it is not the > case. There are some entries on the 8MM which can be used the same way as the 8MM. I have been able to get USB OTG working using the 8MQ's GPC table. Until sometime better is available, would you entertain a limited use of the 8MQ's GPC where the device tree nodes only contain a limited number of entries (like USB OTG) where we can re-use the similar functions 8MQ without expanding the driver functions? I know its not ideal, but it would be a temporary solution unless you think the upstream power domain support is coming quickly. I looked through the mailing list history and it looked like there were some attempts about 6 months ago, then it appeared to stop. Once the newer driver is available upstream, we could then remove GPC references from the 8MM device tree and point it to the new driver. It would increase some limited functionality for the short term. I know Leonard has been working on the DDRC modifications and power reduction. I have been trying to use them, but unsuccessful so far. > > There is another concern, we don't want to export GPC module to rich OS side, it is not a must. What about doing it in the U-Boot stage if Linux isn't an option and ATF isn't accepting them? adam > > BR > Jacky Bai > > > adam > > > > > > > Adam Ford (7): > > > soc: imx: gpcv2: Rename imx8mq-power.h to imx8m-power.h > > > soc: imx: gpcv2: Update imx8m-power.h to include iMX8M Mini > > > soc: imx: gpcv2: add support for i.MX8M Mini SoC > > > dt-bindings: imx-gpcv2: Update bindings to support i.MX8M Mini > > > arm64: dts: imx8mm: add GPC power domains > > > ARM64: dts: imx8mm: Fix clocks and power domain for USB OTG > > > arm64: dts: imx8mm: Add PCIe support > > > > > > .../bindings/power/fsl,imx-gpcv2.txt | 6 +- > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 127 ++++++++- > > > arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +- > > > drivers/soc/imx/gpcv2.c | 246 > > +++++++++++++++++- > > > .../power/{imx8mq-power.h => imx8m-power.h} | 14 + > > > 5 files changed, 387 insertions(+), 8 deletions(-) rename > > > include/dt-bindings/power/{imx8mq-power.h => imx8m-power.h} (57%) > > > > > > -- > > > 2.20.1 > > >
> -----Original Message----- > From: Adam Ford <aford173@gmail.com> > Sent: Sunday, December 22, 2019 10:58 PM > To: Jacky Bai <ping.bai@nxp.com> > Cc: arm-soc <linux-arm-kernel@lists.infradead.org>; Peng Fan > <peng.fan@nxp.com>; Rob Herring <robh+dt@kernel.org>; Mark Rutland > <mark.rutland@arm.com>; Shawn Guo <shawnguo@kernel.org>; Sascha > Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; > dl-linux-imx <linux-imx@nxp.com>; devicetree <devicetree@vger.kernel.org>; > Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Leonard Crestez > <leonard.crestez@nxp.com> > Subject: Re: [PATCH V2 0/7] soc: imx: Enable additional functionality of > i.MX8M Mini > > On Sun, Dec 22, 2019 at 2:33 AM Jacky Bai <ping.bai@nxp.com> wrote: > > > > > -----Original Message----- > > > From: Adam Ford <aford173@gmail.com> > > > Sent: Saturday, December 21, 2019 11:07 PM > > > To: arm-soc <linux-arm-kernel@lists.infradead.org> > > > Cc: Peng Fan <peng.fan@nxp.com>; Jacky Bai <ping.bai@nxp.com>; Rob > > > Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; > > > Shawn Guo <shawnguo@kernel.org>; Sascha Hauer > > > <s.hauer@pengutronix.de>; Pengutronix Kernel Team > > > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; > > > dl-linux-imx <linux-imx@nxp.com>; devicetree > > > <devicetree@vger.kernel.org>; Linux Kernel Mailing List > > > <linux-kernel@vger.kernel.org>; Leonard Crestez > > > <leonard.crestez@nxp.com> > > > Subject: Re: [PATCH V2 0/7] soc: imx: Enable additional > > > functionality of i.MX8M Mini > > > > > > On Fri, Dec 13, 2019 at 10:05 AM Adam Ford <aford173@gmail.com> > wrote: > > > > > > > > The GPCv2 controller on the i.MX8M Mini is compatible with the > > > > driver used for the i.MX8MQ except for the register locations and > names. > > > > The GPCv2 controller is used to enable additional periperals > > > > currently unavailable on the i.MX8M Mini. In order to make them > > > > function, the > > > > GPCv2 needs to be adapted so the drivers can associate their power > > > > domain to the GPCv2 to enable them. > > > > > > > > This series makes one include file slightly more generic, adds the > > > > iMX8M Mini entries, updates the bindings, adds them to the device > > > > tree, then associates the new power domain to both the OTG and > > > > PCIe controllers. > > > > > > > > Some peripherals may need additional power domain drivers in the > > > > future due to limitations of the GPC driver, but the drivers for > > > > VPU and others are not available yet. > > > > > > Before I do a V3 to address Rob's comments, I am thinking I'll drop > > > the items on the GPC that Jacky suggested would not work, and we > > > don't have drivers for those other peripherals (GPU, VPU, etc.) > > > anyway. My main goal here was to try and get the USB OTG ports > > > working, so I'd like to enabled enough of the items on the GPC that > > > are similar to the i.MX8MQ and leave the more challenging items > > > until we have either a better driver available and/or actual > > > peripheral support coming. I haven't seen LCDIF or DSI drivers pushed > upstream yet, so I doubt we'll see GPU or VPU yet until those are done. > > > > > > Does anyone from the NXP team have any other comments/concerns? > > > > > > > If you look into NXP's release code, you will find that it is not easy > > to handle the power domain more generically in GPCv2 driver for > > imx8mm. That's the reason why we use SIP service to handle all the > > power domain in TF-A. we tried to upstream the SIP version power > > domain that can be reused for all i.MX8M, but rejected by ARM guys. > > they think we need to use SCMI to implement it. as there is no SCMI over > SMC available, upstream is on the way, so the power domain for > i.MX8MM/MN is pending. > > > > Thank you for the background. I appreciate it. > > > Actually, I am confused why we can't use SIP service, even if the SCMI > > over SMC is ready in the future, It seems the SMCC function ID still need to > choose from SIP service function id bank. > > > > Another concern for adding power domain support in GPCv2 is that, each > > time a new SOC is added, we need to add hundred lines of code in GPCv2 > > driver. it is not a best way to keep driver reuse. The GPCv2 driver is > > originally used for i.MX7D, then reused by i.MX8MQ, as i.MX8MQ has > > very simple power domain design as i.MX7D. But for i.MX8MM, it is not the > case. > > There are some entries on the 8MM which can be used the same way as the > 8MM. I have been able to get USB OTG working using the 8MQ's GPC table. > > Until sometime better is available, would you entertain a limited use of the > 8MQ's GPC where the device tree nodes only contain a limited number of > entries (like USB OTG) where we can re-use the similar functions 8MQ > without expanding the driver functions? I know its not ideal, but it would be > a temporary solution unless you think the upstream power domain support is > coming quickly. I looked through the mailing list history and it looked like > there were some attempts about > 6 months ago, then it appeared to stop. > > Once the newer driver is available upstream, we could then remove GPC > references from the 8MM device tree and point it to the new driver. > > It would increase some limited functionality for the short term. I know > Leonard has been working on the DDRC modifications and power reduction. > I have been trying to use them, but unsuccessful so far. > > > > There is another concern, we don't want to export GPC module to rich OS > side, it is not a must. > > What about doing it in the U-Boot stage if Linux isn't an option and ATF isn't > accepting them? I have enabled the USB/PCIE power domain by default early before, if using the community ATF, I think USB can work well. BR Jacky Bai > > adam > > > > BR > > Jacky Bai > > > > > adam > > > > > > > > > > Adam Ford (7): > > > > soc: imx: gpcv2: Rename imx8mq-power.h to imx8m-power.h > > > > soc: imx: gpcv2: Update imx8m-power.h to include iMX8M Mini > > > > soc: imx: gpcv2: add support for i.MX8M Mini SoC > > > > dt-bindings: imx-gpcv2: Update bindings to support i.MX8M Mini > > > > arm64: dts: imx8mm: add GPC power domains > > > > ARM64: dts: imx8mm: Fix clocks and power domain for USB OTG > > > > arm64: dts: imx8mm: Add PCIe support > > > > > > > > .../bindings/power/fsl,imx-gpcv2.txt | 6 +- > > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 127 ++++++++- > > > > arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +- > > > > drivers/soc/imx/gpcv2.c | 246 > > > +++++++++++++++++- > > > > .../power/{imx8mq-power.h => imx8m-power.h} | 14 + > > > > 5 files changed, 387 insertions(+), 8 deletions(-) rename > > > > include/dt-bindings/power/{imx8mq-power.h => imx8m-power.h} (57%) > > > > > > > > -- > > > > 2.20.1 > > > >
On Mon, Dec 30, 2019 at 7:06 PM Jacky Bai <ping.bai@nxp.com> wrote: > > > -----Original Message----- > > From: Adam Ford <aford173@gmail.com> > > Sent: Sunday, December 22, 2019 10:58 PM > > To: Jacky Bai <ping.bai@nxp.com> > > Cc: arm-soc <linux-arm-kernel@lists.infradead.org>; Peng Fan > > <peng.fan@nxp.com>; Rob Herring <robh+dt@kernel.org>; Mark Rutland > > <mark.rutland@arm.com>; Shawn Guo <shawnguo@kernel.org>; Sascha > > Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team > > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; > > dl-linux-imx <linux-imx@nxp.com>; devicetree <devicetree@vger.kernel.org>; > > Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Leonard Crestez > > <leonard.crestez@nxp.com> > > Subject: Re: [PATCH V2 0/7] soc: imx: Enable additional functionality of > > i.MX8M Mini > > > > On Sun, Dec 22, 2019 at 2:33 AM Jacky Bai <ping.bai@nxp.com> wrote: > > > > > > > -----Original Message----- > > > > From: Adam Ford <aford173@gmail.com> > > > > Sent: Saturday, December 21, 2019 11:07 PM > > > > To: arm-soc <linux-arm-kernel@lists.infradead.org> > > > > Cc: Peng Fan <peng.fan@nxp.com>; Jacky Bai <ping.bai@nxp.com>; Rob > > > > Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; > > > > Shawn Guo <shawnguo@kernel.org>; Sascha Hauer > > > > <s.hauer@pengutronix.de>; Pengutronix Kernel Team > > > > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; > > > > dl-linux-imx <linux-imx@nxp.com>; devicetree > > > > <devicetree@vger.kernel.org>; Linux Kernel Mailing List > > > > <linux-kernel@vger.kernel.org>; Leonard Crestez > > > > <leonard.crestez@nxp.com> > > > > Subject: Re: [PATCH V2 0/7] soc: imx: Enable additional > > > > functionality of i.MX8M Mini > > > > > > > > On Fri, Dec 13, 2019 at 10:05 AM Adam Ford <aford173@gmail.com> > > wrote: > > > > > > > > > > The GPCv2 controller on the i.MX8M Mini is compatible with the > > > > > driver used for the i.MX8MQ except for the register locations and > > names. > > > > > The GPCv2 controller is used to enable additional periperals > > > > > currently unavailable on the i.MX8M Mini. In order to make them > > > > > function, the > > > > > GPCv2 needs to be adapted so the drivers can associate their power > > > > > domain to the GPCv2 to enable them. > > > > > > > > > > This series makes one include file slightly more generic, adds the > > > > > iMX8M Mini entries, updates the bindings, adds them to the device > > > > > tree, then associates the new power domain to both the OTG and > > > > > PCIe controllers. > > > > > > > > > > Some peripherals may need additional power domain drivers in the > > > > > future due to limitations of the GPC driver, but the drivers for > > > > > VPU and others are not available yet. > > > > > > > > Before I do a V3 to address Rob's comments, I am thinking I'll drop > > > > the items on the GPC that Jacky suggested would not work, and we > > > > don't have drivers for those other peripherals (GPU, VPU, etc.) > > > > anyway. My main goal here was to try and get the USB OTG ports > > > > working, so I'd like to enabled enough of the items on the GPC that > > > > are similar to the i.MX8MQ and leave the more challenging items > > > > until we have either a better driver available and/or actual > > > > peripheral support coming. I haven't seen LCDIF or DSI drivers pushed > > upstream yet, so I doubt we'll see GPU or VPU yet until those are done. > > > > > > > > Does anyone from the NXP team have any other comments/concerns? > > > > > > > > > > If you look into NXP's release code, you will find that it is not easy > > > to handle the power domain more generically in GPCv2 driver for > > > imx8mm. That's the reason why we use SIP service to handle all the > > > power domain in TF-A. we tried to upstream the SIP version power > > > domain that can be reused for all i.MX8M, but rejected by ARM guys. > > > they think we need to use SCMI to implement it. as there is no SCMI over > > SMC available, upstream is on the way, so the power domain for > > i.MX8MM/MN is pending. > > > > > > > Thank you for the background. I appreciate it. > > > > > Actually, I am confused why we can't use SIP service, even if the SCMI > > > over SMC is ready in the future, It seems the SMCC function ID still need to > > choose from SIP service function id bank. > > > > > > Another concern for adding power domain support in GPCv2 is that, each > > > time a new SOC is added, we need to add hundred lines of code in GPCv2 > > > driver. it is not a best way to keep driver reuse. The GPCv2 driver is > > > originally used for i.MX7D, then reused by i.MX8MQ, as i.MX8MQ has > > > very simple power domain design as i.MX7D. But for i.MX8MM, it is not the > > case. > > > > There are some entries on the 8MM which can be used the same way as the > > 8MM. I have been able to get USB OTG working using the 8MQ's GPC table. > > > > Until sometime better is available, would you entertain a limited use of the > > 8MQ's GPC where the device tree nodes only contain a limited number of > > entries (like USB OTG) where we can re-use the similar functions 8MQ > > without expanding the driver functions? I know its not ideal, but it would be > > a temporary solution unless you think the upstream power domain support is > > coming quickly. I looked through the mailing list history and it looked like > > there were some attempts about > > 6 months ago, then it appeared to stop. > > > > Once the newer driver is available upstream, we could then remove GPC > > references from the 8MM device tree and point it to the new driver. > > > > It would increase some limited functionality for the short term. I know > > Leonard has been working on the DDRC modifications and power reduction. > > I have been trying to use them, but unsuccessful so far. > > > > > > There is another concern, we don't want to export GPC module to rich OS > > side, it is not a must. > > > > What about doing it in the U-Boot stage if Linux isn't an option and ATF isn't > > accepting them? > > > I have enabled the USB/PCIE power domain by default early before, if using the community ATF, > I think USB can work well. Can you point me to which repo you're using? When I use a stock U-Boot from their repo with the ATF referenced from there, the board hangs when USB is initialized. Ideally, I'd like to get USB working on the mainline Linux with mainline U-Boot. adam > > BR > Jacky Bai > > > > > adam > > > > > > BR > > > Jacky Bai > > > > > > > adam > > > > > > > > > > > > > Adam Ford (7): > > > > > soc: imx: gpcv2: Rename imx8mq-power.h to imx8m-power.h > > > > > soc: imx: gpcv2: Update imx8m-power.h to include iMX8M Mini > > > > > soc: imx: gpcv2: add support for i.MX8M Mini SoC > > > > > dt-bindings: imx-gpcv2: Update bindings to support i.MX8M Mini > > > > > arm64: dts: imx8mm: add GPC power domains > > > > > ARM64: dts: imx8mm: Fix clocks and power domain for USB OTG > > > > > arm64: dts: imx8mm: Add PCIe support > > > > > > > > > > .../bindings/power/fsl,imx-gpcv2.txt | 6 +- > > > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 127 ++++++++- > > > > > arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +- > > > > > drivers/soc/imx/gpcv2.c | 246 > > > > +++++++++++++++++- > > > > > .../power/{imx8mq-power.h => imx8m-power.h} | 14 + > > > > > 5 files changed, 387 insertions(+), 8 deletions(-) rename > > > > > include/dt-bindings/power/{imx8mq-power.h => imx8m-power.h} (57%) > > > > > > > > > > -- > > > > > 2.20.1 > > > > >
Hi Jacky, On So, 2019-12-22 at 08:33 +0000, Jacky Bai wrote: > > -----Original Message----- > > From: Adam Ford <aford173@gmail.com> > > Sent: Saturday, December 21, 2019 11:07 PM > > To: arm-soc <linux-arm-kernel@lists.infradead.org> > > Cc: Peng Fan <peng.fan@nxp.com>; Jacky Bai <ping.bai@nxp.com>; Rob > > Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; > > Shawn Guo <shawnguo@kernel.org>; Sascha Hauer > > <s.hauer@pengutronix.de>; Pengutronix Kernel Team > > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; > > dl-linux-imx <linux-imx@nxp.com>; devicetree <devicetree@vger.kernel.org>; > > Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Leonard Crestez > > <leonard.crestez@nxp.com> > > Subject: Re: [PATCH V2 0/7] soc: imx: Enable additional functionality of > > i.MX8M Mini > > > > On Fri, Dec 13, 2019 at 10:05 AM Adam Ford <aford173@gmail.com> wrote: > > > The GPCv2 controller on the i.MX8M Mini is compatible with the driver > > > used for the i.MX8MQ except for the register locations and names. > > > The GPCv2 controller is used to enable additional periperals currently > > > unavailable on the i.MX8M Mini. In order to make them function, the > > > GPCv2 needs to be adapted so the drivers can associate their power > > > domain to the GPCv2 to enable them. > > > > > > This series makes one include file slightly more generic, adds the > > > iMX8M Mini entries, updates the bindings, adds them to the device > > > tree, then associates the new power domain to both the OTG and PCIe > > > controllers. > > > > > > Some peripherals may need additional power domain drivers in the > > > future due to limitations of the GPC driver, but the drivers for VPU > > > and others are not available yet. > > > > Before I do a V3 to address Rob's comments, I am thinking I'll drop the items > > on the GPC that Jacky suggested would not work, and we don't have drivers > > for those other peripherals (GPU, VPU, etc.) anyway. My main goal here was > > to try and get the USB OTG ports working, so I'd like to enabled enough of the > > items on the GPC that are similar to the i.MX8MQ and leave the more > > challenging items until we have either a better driver available and/or actual > > peripheral support coming. I haven't seen LCDIF or DSI drivers pushed > > upstream yet, so I doubt we'll see GPU or VPU yet until those are done. > > > > Does anyone from the NXP team have any other comments/concerns? > > > > If you look into NXP's release code, you will find that it is not easy to handle the > power domain more generically in GPCv2 driver for imx8mm. That's the reason why we use > SIP service to handle all the power domain in TF-A. we tried to upstream the SIP version > power domain that can be reused for all i.MX8M, but rejected by ARM guys. they think > we need to use SCMI to implement it. as there is no SCMI over SMC available, upstream is > on the way, so the power domain for i.MX8MM/MN is pending. Adding power domain support for i.MX8MM/MN to the GPCv2 driver does not prevent a SCMI solution to be used when available. I don't see why we should block this. > Actually, I am confused why we can't use SIP service, even if the SCMI over SMC is ready in > the future, It seems the SMCC function ID still need to choose from SIP service function id bank. > > Another concern for adding power domain support in GPCv2 is that, each time a new > SOC is added, we need to add hundred lines of code in GPCv2 driver. it is not a best way > to keep driver reuse. This is how all hardware specific stuff is handled in the driver. I see your use-case of having a single TF-A based driver for applications where you have more than on OS running on the system. For the very common case of only a single rich OS running on the system the code reuse doesn't really matter and in fact it's easier to fix any bugs by just updating the Linux kernel. > The GPCv2 driver is originally used for i.MX7D, then reused by i.MX8MQ, > as i.MX8MQ has very simple power domain design as i.MX7D. But for i.MX8MM, it is not the > case. I would be very interested in the details here. What is the big difference in the i.MX8MM that would make it hard to support it in the GPCv2 driver in the same way as we did with i.MX8MQ? > > There is another concern, we don't want to export GPC module to rich OS side, it is not a must. You are still free to remove the GPC DT node, as soon as the SCMI replacement is ready. But if you decide to handle the GPC stuff in TF-A, are you also going to handle the external supplies to the GPC domains in the TF-A? What about synchronous reset clocks that need to be running while the domain is powered up? Are you going to add a SCMI based replacement for the clock controller, which is currently also handled in the rich OS? Regards, Lucas > > BR > Jacky Bai > > > adam > > > Adam Ford (7): > > > soc: imx: gpcv2: Rename imx8mq-power.h to imx8m-power.h > > > soc: imx: gpcv2: Update imx8m-power.h to include iMX8M Mini > > > soc: imx: gpcv2: add support for i.MX8M Mini SoC > > > dt-bindings: imx-gpcv2: Update bindings to support i.MX8M Mini > > > arm64: dts: imx8mm: add GPC power domains > > > ARM64: dts: imx8mm: Fix clocks and power domain for USB OTG > > > arm64: dts: imx8mm: Add PCIe support > > > > > > .../bindings/power/fsl,imx-gpcv2.txt | 6 +- > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 127 ++++++++- > > > arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +- > > > drivers/soc/imx/gpcv2.c | 246 > > +++++++++++++++++- > > > .../power/{imx8mq-power.h => imx8m-power.h} | 14 + > > > 5 files changed, 387 insertions(+), 8 deletions(-) rename > > > include/dt-bindings/power/{imx8mq-power.h => imx8m-power.h} (57%) > > > > > > -- > > > 2.20.1 > > >
The GPCv2 controller on the i.MX8M Mini is compatible with the driver used for the i.MX8MQ except for the register locations and names. The GPCv2 controller is used to enable additional periperals currently unavailable on the i.MX8M Mini. In order to make them function, the GPCv2 needs to be adapted so the drivers can associate their power domain to the GPCv2 to enable them. This series makes one include file slightly more generic, adds the iMX8M Mini entries, updates the bindings, adds them to the device tree, then associates the new power domain to both the OTG and PCIe controllers. Some peripherals may need additional power domain drivers in the future due to limitations of the GPC driver, but the drivers for VPU and others are not available yet. Adam Ford (7): soc: imx: gpcv2: Rename imx8mq-power.h to imx8m-power.h soc: imx: gpcv2: Update imx8m-power.h to include iMX8M Mini soc: imx: gpcv2: add support for i.MX8M Mini SoC dt-bindings: imx-gpcv2: Update bindings to support i.MX8M Mini arm64: dts: imx8mm: add GPC power domains ARM64: dts: imx8mm: Fix clocks and power domain for USB OTG arm64: dts: imx8mm: Add PCIe support .../bindings/power/fsl,imx-gpcv2.txt | 6 +- arch/arm64/boot/dts/freescale/imx8mm.dtsi | 127 ++++++++- arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +- drivers/soc/imx/gpcv2.c | 246 +++++++++++++++++- .../power/{imx8mq-power.h => imx8m-power.h} | 14 + 5 files changed, 387 insertions(+), 8 deletions(-) rename include/dt-bindings/power/{imx8mq-power.h => imx8m-power.h} (57%)