[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHCN7xLupOP2ukGwXp00duJtDYiyHKj7av71zxeCne3yXwPkmg@mail.gmail.com>
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
>
Powered by blists - more mailing lists