linux-kernel - Re: [PATCH] arm64: dts: imx8mm: Add GPU node

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 23 Oct 2020 06:07:02 -0500
From:   Adam Ford <aford173@...il.com>
To:     Lucas Stach <l.stach@...gutronix.de>
Cc:     Marek Vasut <marex@...x.de>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>,
        Adam Ford-BE <aford@...conembedded.com>,
        Rob Herring <robh+dt@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64: dts: imx8mm: Add GPU node

On Fri, Oct 23, 2020 at 3:25 AM Lucas Stach <l.stach@...gutronix.de> wrote:
>
> On Do, 2020-10-22 at 13:31 -0500, Adam Ford wrote:
> > On Thu, Oct 22, 2020 at 1:17 PM Marek Vasut <marex@...x.de> wrote:
> > > On 10/22/20 7:16 PM, Adam Ford wrote:
> > > > According to the documentation from NXP, the i.MX8M Nano has a
> > > > Vivante GC7000 Ultra Lite as its GPU core.
> > > >
> > > > With this patch, the Etnaviv driver presents the GPU as:
> > > >    etnaviv-gpu 38000000.gpu: model: GC7000, revision: 6203
> > > >
> > > > It uses the GPCV2 controller to enable the power domain for the
> > > > GPU.
> > >
> > > Subject should say 8mn , not 8mm .
> >
> > ugh.. My mistake.  I'll submit a V2 once other have had a chance to
> > give some feedback.
> >
> > Maybe NXP can comment on the dialog below.
> >
> > > Are the assigned-clock-rates correct ?
> >
> > I used the assigned clock rates from the vendor kernel, with the
> > exception of running at 400MHz instead of 600MHz.  According to the
> > datasheet, the GPU clock needs to be 400MHZ to run at 0.85V. The
> > 600MHz operating point for the GPU requires a 0.95V operating point.
> > Since the default operating point for the Nano shows 0.85V, I left
> > the
> > GPU clock lower to match the normal operating speed.  This varies a
> > bit from the vendor kernel, but their kernel is also showing a 0.95V
> > operating point, so I think that's why they are specifying a 600MHz
> > operating point.
> >
> > On the Beacon embedded board, we're driving the LPDDR to 800MHz which
> > requires the ARM to run at .95V.   I was able to override the
> > assigned-clock rates for my board to run at 600MHz, and change the
> > ARM
> > operating point to .95V to meet the spec.
> >
> > My intent was to use the defaults and let the board files override
> > them.   If you want, I can try to look through the board files to see
> > what operating point their using and propose updates to those
> > respective device trees to address the clocks on those boards.
>
> I think this is fine as-is with this explanation. At least we have a
> precedent in the i.MX8MQ DT where the assigned clocks are for the base
> (non overdrive) operating point and boards can choose to override it if
> they want to use the overdrive OPP. At least until we add proper
> frequency scaling in etnaviv, which should obsolete those fixed clock
> rates.

I have to do a V2 from the feedback of Krzysztof.  I will expand the
commit message to include the description of the 400MHz vs 600MHz
clocking and the need for adjusting the operating points.

adam
>
> Regards,
> Lucas
>