[Freedreno] [RFC] drm/msm/adreno: clean up gpu bindings

[Jordan Crouse]

On Thu, Jan 26, 2017 at 05:03:54PM -0500, Rob Clark wrote:
> On Thu, Jan 26, 2017 at 4:09 PM, Rob Herring <robh at kernel.org> wrote:
> > On Thu, Jan 26, 2017 at 1:51 PM, Rob Clark <robdclark at gmail.com> wrote:
> >> On Thu, Jan 26, 2017 at 2:11 PM, Rob Herring <robh at kernel.org> wrote:
> >>> On Tue, Jan 24, 2017 at 11:11 AM, Rob Clark <robdclark at gmail.com> wrote:
> >>>> So, cleaning up the GPU bindings is something that has been on my TODO
> >>>> list for a while, but always $bigger_fires.  Existing bindings are a bit
> >>>> ugly, but served a purpose when too many of the other drivers the GPU
> >>>> depends on where still working their way upstream.  But now enough of
> >>>> that is in place for a few devices, that we should start trying to get
> >>>> the GPU nodes into the upstream dts files.
> >>>>
> >>>> This drops the "qcom,chipid" property and parses the GPU revision out of
> >>>> the compat string.  It does mean you need to list both "qcom,adreno" and
> >>>> the more specific string, for example "qcom,adreno-530.2".  I'm not sure
> >>>> if that is "weird" or anyone has better ideas (hence this RFC).
> >>>
> >>> Is version and SoC close to a 1-1 mapping? If one version is in lots
> >>> of different SoCs, then you should have an SoC specific compatible.
> >>
> >> I'm not sure how common it is, but I'm pretty sure in the past I've
> >> seen same gpu (but maybe not same patchlevel).
> >>
> >> Also, there tend to be multiple revisions of the SoC which may or may
> >> not bump the gpu patchlevel.  I think it is quite likely to be
> >> insanity to try and figure out gpu revision from SoC..
> >
> > I'm not saying you should. My point is gpu revision alone may not be
> > enough. Things can get integrated or configured differently. You could
> > use an SoC based compatible, read the revision registers for the
> > revision, and override wrong revision registers based on SoC
> > compatible (assuming that is rare).
> 
> Hmm, I'll probably defer to Jordan on this, since he has seen more
> combinations over the years. 
>
> I think any integration differences would just amount to which
> clks/gdsc/etc are wired up.  At least what I've seen in downstream
> kgsl driver, all the things that are conditional are purely keyed to
> the revision+patchlevel.

I think for all practical purposes there is a 1-1 mapping between a GPU version
and a SoC at least over the last few years. The last time I can remember was an
unfortunate series of revisions in the 3XX family which I think ended up being
the catalyst for the hardware team getting their act together in this regard.

> As far as revision registers, IIRC back in the a3xx days they were not
> to be trusted.  I'm not entirely sure when they became trustworthy.
> Last I checked, android kgsl driver was not using them.

We got burned to a crisp over these back in the day and I have never forgotten
it so thats why the downstream driver is exclusively DT based (which I admit is
probably too far in the other direction).

These days I think they are mostly agreeable again (sometimes they don't get
updated for metal spins but I think they even got that figured out too).

I'm open to using revision registers again as long as we don't blindly trust
them and give ourselves a way to override the version.

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project