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] [thread-next>] [day] [month] [year] [list]
Message-ID: <15c51fd40f3c79b9afd208e2890263bb936e8434.camel@pengutronix.de>
Date:   Fri, 23 Oct 2020 10:25:30 +0200
From:   Lucas Stach <l.stach@...gutronix.de>
To:     Adam Ford <aford173@...il.com>, Marek Vasut <marex@...x.de>
Cc:     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 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.

Regards,
Lucas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ