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