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. Look at ePAPR for a moment, and consider a serial port. A serial UART can be physically connected to a 9-pin or a 25-pin connector, which may be male or female. These details are not included in the DT description. Even when the serial port control signals are provided by GPIOs rather than the UART, we don't model the connector - we wrap the GPIOs directly into the UART driver. Arguably, that's not following the hardware, it's following the software representation - it's following the software representation of what a serial port _should_ look like to a non-specific OS. Consider an ethernet port. You'll find the same thing applies - the physical connector itself is not specified. Yet, somehow, we're wanting to specify the physical connector for _all_ video devices? I don't see why that should be mandatory when it's not mandatory for other subsystems. If we want to take this to the extreme, we should be specifying the power connectors in DT and how they're wired up along with their controls. We don't though, we specify the control devices and the function of those (eg, via a charger chip.) To take this to the extreme, what about a device powered via PoE? Should the PoE connector be modelled in DT? When we say "DT should follow the hardware" we're not talking about making DT be an alternative to the hardware's schematic. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
