Message-ID: <CAHCN7xKePMS2F6sR6iRHrfdLET1Z2=zrXB=79K9HFdW+0VYAJg@mail.gmail.com>
Date:   Wed, 7 Apr 2021 18:03:41 -0500
From:   Adam Ford <aford173@...il.com>
To:     Lucas Stach <l.stach@...gutronix.de>
Cc:     Adrien Grassein <adrien.grassein@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Sascha Hauer <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Anson Huang <Anson.Huang@....com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Peng Fan <peng.fan@....com>,
        Aisheng Dong <aisheng.dong@....com>, qiangqing.zhang@....com,
        Alice Guo <alice.guo@....com>,
        Guido Günther <agx@...xcpu.org>,
        Andrey Smirnov <andrew.smirnov@...il.com>,
        devicetree <devicetree@...r.kernel.org>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 0/7] imx-gpcv2 improvements

On Wed, Apr 7, 2021 at 5:13 PM Lucas Stach <l.stach@...gutronix.de> wrote:
>
> Hi Adrien,
>
> I feel like I already mentioned to you some time ago that there is
> already a much more complete patch series to add this functionality on
> the list [1].
>
> If you want this functionality to go upstream, please help test and
> extend this patch series.
>
> Regards,
> Lucas
>
> [1] https://lore.kernel.org/linux-arm-kernel/20201105174434.1817539-1-l.stach@pengutronix.de/

I took Lucas' code and attempted to build upon it to add Nano support.
At some point, someone from NXP thought it would get really hard to
read if we started filling that file with every supported SoC.
To help with that, I created a patch to split the gpcv2 code into a
gcpv2 core functions  with the individual SoC's having separate files
to help keep things a little cleaner, and easier to read:
gpcv2-imx7, gpcv2-imx8mq, gpcv2-imx8mm, and gpcv2-imx8mn, etc.
I was holding off on doing anything with it, because the dt-bindings
appeared to be stalled, and the attempt by Lucas to get the basic
functionality was stalled.

As of right now, it seems like without any changes, I can not get my
Mini or Nano to wake from sleep unless I use a U-Boot and ATF based on
NXP's custom branches.  When using the custom branches, I made some
additional patches to the gpcv2 to add a flag which would prevent
disabling USB OTG on Mini and Nano which appeared to help waking from
sleep, and it matched some of what NXP's custom ATF was doing.

I know there has been some concern about using syscon address the
resets and enables, but I took some work Marek did, and added to it by
adding some flags to the structure which could take the syscon and
write different values to the blk-ctl register depending on whether or
not it was a Mini or Nano (and probably Plus).   Using some of these,
I was able to get the dispmix to come out of reset and enable the
LCDIF on both Mini and Nano, but for some reason, any attempts to
enable the mipi domain were causing failures in other domains, so I
strilpped them out again.  I've withheld posting any of these for the
same reasons I withheld my other patches.

As soon as Lucas' patch [1] above or something similar gets accepted,
can rebase and submit a few of the patches I have.

adam
>
> Am Mittwoch, dem 07.04.2021 um 23:21 +0200 schrieb Adrien Grassein:
> > Hi,
> >
> > This patch set aims is to add the support of the i.MX8 MM power domains
> > on the mainline kernel.
> >
> > To achieve this, I do several patches
> >   - Check errors when reading or writing registers (concerns i.MX8M base
> >     implementation);
> >   - Fix power up/down sequence. Handshake was not checked and it was
> >     not called at the appropriate time (concerns i.MX8M base
> > implementaions);
> >   - Allow domains without power sequence control like the HSIOMIX of the
> >     i.MX8MM.
> >   - Add some i.MX8MM domains (HSIO and OTGS);
> >   - Introduce quirks. For example, i.MX8MM OTG domains should not be
> >     powered off (seen n the source code of th i.MX ATF). Quirks are
> > easily upgrable for other cases.
> >   - Finally I defined power domains into the imx8mm.dtb file.
> >
> > I know that this kind of patch is rejected by NXP ut the other way
> > (callin ATF directly) was also rejected.
> >
> > I also know that NXP is concerned abou adding hundred lines of codes for
> > each new SOC but it' the way it works on Linux. And the "added code"
> > mainly consist of adding structures, defines and generic methods for
> > regmap.
> >
> > If it's a real problem, maybe we can introduc a new "gpcv3" driver for
> > i.MX8MM, i.MX8MN and i.MX8MP.
> >
> > Thanks,
> >
> > Adrien Grassein (7):
> >   soc: imx: gpcv2: check for errors when r/w registers
> >   soc: imx: gpcv2: Fix power up/down sequence
> >   soc: imx: gpcv2: allow domains without power sequence control
> >   dt-bindings: power: fsl,imx-gpcv2: add definitions for i.MX8MM
> >   soc: imx: gpcv2: add HSIOMIX and USB domains for i.MX8MM
> >   soc: imx: gpcv2: add quirks to domains
> >   arm64: dts: imx8mm: add power-domains
> >
> >  .../bindings/power/fsl,imx-gpcv2.yaml         |   7 +-
> >  arch/arm64/boot/dts/freescale/imx8mm.dtsi     |  35 ++
> >  drivers/soc/imx/gpcv2.c                       | 336 ++++++++++++++----
> >  include/dt-bindings/power/imx8mm-power.h      |  21 ++
> >  4 files changed, 333 insertions(+), 66 deletions(-)
> >  create mode 100644 include/dt-bindings/power/imx8mm-power.h
> >
>
>

Powered by blists - more mailing lists