[PATCH 2/4] drm/msm: drop qcom,chipid

[Eric Anholt]

Rob Clark <robdclark at gmail.com> writes:

> On Mon, Jan 30, 2017 at 1:09 PM, Eric Anholt <eric at anholt.net> wrote:
>> Rob Clark <robdclark at gmail.com> writes:
>>
>>> The original way we determined the gpu version was based on downstream
>>> bindings from android kernel.  A cleaner way is to get the version from
>>> the compatible string.
>>>
>>> Note that no upstream dtb uses these bindings.  But the code still
>>> supports falling back to the legacy bindings (with a warning), so that
>>> we are still compatible with the gpu dt node from android device
>>> kernels.
>>
>> The gpulist[] seems pretty short, like you could just have 7 compatible
>> strings in dt_match[] and point them directly at corresponding the
>> gpulist[] entry.  Or are there lots of patch levels, with the same
>> struct adreno_info values?
>
> The list currently is rather incomplete (which may or may not matter,
> I guess it comes down to how many different phones/tablets out there
> people try to get an upstream kernel working on).  And it has those
> ANY_ID wildcard entries.
>
> A full list of all the gpu's including all their patchlevels would be
> quite long.
>
> We might end up wanting to split the quirks out differently, since
> those tend to apply to specific patchlevel's.. I had to change the
> existing entry for a530 from a530.* to a530.2 for this reason.  But
> that won't effect the bindings so that is an implementation detail we
> can worry about later.

I think that using the of_match_device() mechanism from the specific
strings listed as the compatible would make more sense than this string
parsing.  You have to write a gpulist[] entry anyway for the module to
load.  So that means adding about 7 values today to the compatible
string dt_match, and the code to use of_match_device() to get your
struct adreno_info.  Then the current version number lookup loop would
be just for the old DT compatibility and there's no string parsing.

However, it's your driver.  The code seems correct, and using specific
compatible strings is an obviously good step.

Reviewed-by: Eric Anholt <eric at anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170130/75d3e2e4/attachment.sig>