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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
