Re: [PATCH] arm64: dts: imx8mm: Add GPU node

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 23, 2020 at 3:25 AM Lucas Stach <l.stach@xxxxxxxxxxxxxx> 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@xxxxxxx> 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
>



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux