Date:   Tue, 31 Dec 2019 01:06:41 +0000
From:   Jacky Bai <ping.bai@....com>
To:     Adam Ford <aford173@...il.com>
CC:     arm-soc <linux-arm-kernel@...ts.infradead.org>,
        Peng Fan <peng.fan@....com>, Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        dl-linux-imx <linux-imx@....com>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Leonard Crestez <leonard.crestez@....com>
Subject: RE: [PATCH V2 0/7] soc: imx: Enable additional functionality of
 i.MX8M Mini

> -----Original Message-----
> From: Adam Ford <aford173@...il.com>
> Sent: Sunday, December 22, 2019 10:58 PM
> To: Jacky Bai <ping.bai@....com>
> Cc: arm-soc <linux-arm-kernel@...ts.infradead.org>; Peng Fan
> <peng.fan@....com>; Rob Herring <robh+dt@...nel.org>; Mark Rutland
> <mark.rutland@....com>; Shawn Guo <shawnguo@...nel.org>; Sascha
> Hauer <s.hauer@...gutronix.de>; Pengutronix Kernel Team
> <kernel@...gutronix.de>; Fabio Estevam <festevam@...il.com>;
> dl-linux-imx <linux-imx@....com>; devicetree <devicetree@...r.kernel.org>;
> Linux Kernel Mailing List <linux-kernel@...r.kernel.org>; Leonard Crestez
> <leonard.crestez@....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@....com> wrote:
> >
> > > -----Original Message-----
> > > From: Adam Ford <aford173@...il.com>
> > > Sent: Saturday, December 21, 2019 11:07 PM
> > > To: arm-soc <linux-arm-kernel@...ts.infradead.org>
> > > Cc: Peng Fan <peng.fan@....com>; Jacky Bai <ping.bai@....com>; Rob
> > > Herring <robh+dt@...nel.org>; Mark Rutland <mark.rutland@....com>;
> > > Shawn Guo <shawnguo@...nel.org>; Sascha Hauer
> > > <s.hauer@...gutronix.de>; Pengutronix Kernel Team
> > > <kernel@...gutronix.de>; Fabio Estevam <festevam@...il.com>;
> > > dl-linux-imx <linux-imx@....com>; devicetree
> > > <devicetree@...r.kernel.org>; Linux Kernel Mailing List
> > > <linux-kernel@...r.kernel.org>; Leonard Crestez
> > > <leonard.crestez@....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@...il.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
> > > >

Powered by blists - more mailing lists