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). >From all the bindings I've seen though, the style in the table above would be unusual though; most compatible values simply specify the first (or first SW-supported) SoC version that incorporated that IP version. Still, I imagine that's simply historical precedent rather than some hard-and-fast rule. So, I'd say go ahead with the table above, but you may want to ping some DT maintainers or old-hands to make sure there isn't something I forgot about. > The reason I like this better is that it's clear which value to use > when gating features in the driver. Using the scheme above, it might > be tempting to gate a feature/fix on exynos5xxx-hdmi when it really > works with both 4212 && 5xxx. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
