Re: [PATCH RFC 6/6] ARM: dts: am335x-boneblack: Use new binding for HDMI

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

On 02/03/15 18:06, Russell King - ARM Linux wrote:

>> This is missing the output of tda998x. It should have two ports, input
>> and output, output going to hdmi-connector.
> 
> We don't have that kind of level of modelling in DRM right now - as far
> as DRM is concerned, the tda998x is both the encoder _and_ the connector
> since it supplies both functionalities.

That's fine, but these are DT bindings which should reflect the
hardware, not the SW stack.

> We did discuss this ages ago, but afaik no concensus was reached how to
> model physical connectors in DT, so it never moved forward in DRM (and

I don't know about consensus, but omapdss is using connectors in DT, and
they were discussed in lists, and everyone seemed to be ok with that
model (Documentation/devicetree/bindings/video/hdmi-connector.txt). If I
recall right, the only real question was how the links should be modeled
(two way, one way, something else), but that's not specific to connectors.

So while it's open how they should be implemented in the DRM, I don't
see why we couldn't/shouldn't specify them in the .dts.

That said, if and when DRM supports connectors defined in .dts, we can
just assume that if tda998x does not have an output defined in the .dts,
it's connected to a HDMI connector. So we should do just fine even if we
end up not defining the connectors at this time.

> besides, everyone seems to be off doing their own thing when it comes
> to writing DT descriptions for video hardware.)

Yep... I've been trying to push the video ports/endpoints system which
afaik covers about all the use cases that have been raised. But the
counter argument usually is that "it's too complex".

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]