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@xxxxxxxxxx> wrote: > > On Thu, Jan 26, 2017 at 1:51 PM, Rob Clark <robdclark@xxxxxxxxx> wrote: > >> On Thu, Jan 26, 2017 at 2:11 PM, Rob Herring <robh@xxxxxxxxxx> wrote: > >>> On Tue, Jan 24, 2017 at 11:11 AM, Rob Clark <robdclark@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
