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: 3123 bytes --]

On 02/03/15 19:42, Russell King - ARM Linux wrote:
> On Mon, Mar 02, 2015 at 07:08:39PM +0200, Tomi Valkeinen wrote:
>> 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.
> 
> I still don't buy your argument.  The principle is right, but I think
> you're taking it too far.

<snip>

> When we say "DT should follow the hardware" we're not talking about
> making DT be an alternative to the hardware's schematic.

I agree, and that's not what I'm suggesting. We should only model HW in
the DT when it makes sense, when it gives us something.

A HDMI connector can have (at least) two functionalities that the driver
for it may need to handle: HPD and +5V. On some SoCs/boards those are
handled by the HDMI encoder, but I have boards where they are not. So we
need to have the data somewhere, and a HDMI connector node at the end of
the video path is a logical choice.

The HDMI connector node is also a good place for a symbolic name which
can be shown to the user.

In this particular board, the HDMI encoder handles the HPD and the +5V
is always enabled, so there's no strict need to have the HDMI connector
node.

However, I still feel it's better to have the HDMI connector in .dts:

1) It's not said that a HDMI encoder always has a HDMI connector as the
next component. The next component could be a integrated panel, needing
a specific driver and there's no HDMI connector at all. Or there could
be something else, as is the case on some OMAP boards which have an ESD
protection chip (that requires controlling, i.e. a driver) between the
encoder and the connector.

2) I like that the beginning and the end of the video pipeline are
clearly defined. A video pipeline starts at a display controller, and
ends at a panel or a connector. This makes it easier to understand the
.dts as you know what to expect.

In the SW side these mean that every encoder (or whatever is doing this
stuff) should be able to handle any component after the encoder, be it a
connector, panel or something else.

If we allow leaving out the connector node, the code also needs to
handle the case when there's nothing after the encoder, which probably
means fabricating some connector data (at least if and when DRM can
handle arbitrary video pipelines).

But as I said earlier, we can do just fine without the HDMI connector
node on boards where the connector "just works". We can handle that in
the drivers with some extra code.

So if people think it's a big chore to add the connectors and don't see
the benefit in them (and they don't want the symbolic labels that could
be added there), I'm fine with having them optional.

 Tomi



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