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@kernel.org wrote:
On Thu, Jan 26, 2017 at 1:51 PM, Rob Clark robdclark@gmail.com wrote:
On Thu, Jan 26, 2017 at 2:11 PM, Rob Herring robh@kernel.org wrote:
On Tue, Jan 24, 2017 at 11:11 AM, Rob Clark robdclark@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