Re: [PATCH v2] drm/exynos: Get HDMI version from device tree

[Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]

On 01/31/2013 10:36 AM, Stephen Warren wrote:
> On 01/31/2013 08:04 AM, Sean Paul wrote:
> ...
>> I think if we take a step back, we're really not discussing HDMI
>> version 1.3 vs. 1.4, we're really talking about the HDMI IP block
>> version.
> 
> Absolutely.
> 
>> The blocks just happen to implement different versions of the
>> HDMI spec.
> 
> Yes.
> 
>> The initial naming in the driver is unfortunate.
>>
>> That said, I think the above solution is fine, but it's a little
>> misleading.  I'd much rather encode the version of the IP block
>> instead of the SoC that contains it. Something like:
>>
>> compatible = "samsung,exynos-hdmiXXX"
>>
>> In this case, XXX is just some integer in the bindings that maps to an
>> SoC. For example,
>>
>> +----------------------+-------------+
>> | HDMI IP version      | Exynos SoC  |
>> +----------------------+-------------+
>> | samsung,exynos-hdmi1 | 4210        |
>> | samsung,exynos-hdmi2 | 4212, 5250  |
>> +----------------------+-------------+
> 
> That seems reasonable to me. (But, does the documentation for these IP
> blocks specify the version in the format "1" and "2"? It'd be best if
> the compatible value encoded the same version scheme as the IP block
> documentation).

The thing I forgot here is:

Even if the IP block is identical between two different SoCs, it's quite
possible it was tweaked just a tiny bit between the two SoCs, or
something about the environment into which the IP block was placed
differs. Either of those conditions could mean that the same IP block
instantiated into two different SoCs could end up requiring different
workarounds/bugfixes/... that the driver needs to know about. As such,
encoding the exact SoC into the compatible value, and then deriving the
IP block version from the SoC-specific compatible value, makes the most
sense.

This is really just what Olof was saying rephrased. I'm just following
up to change my mind on my assertion that the table above appears
reasonable.

And of course as Olof cares, the compatible value can contain multiple
values; the most specific first, and then progressively more generic
values, and if the driver doesn't care (yet?) about the differences
between some specific values, it can always /just/ match on the more
generic values until some specific WAR/bugfix is needed.