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

From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
	detheridge@ti.com, tony@atomide.com, Jyri Sarha <jsarha@ti.com>,
	bcousson@baylibre.com, linux-omap@vger.kernel.org
Subject: Re: [PATCH RFC 6/6] ARM: dts: am335x-boneblack: Use new binding for HDMI
Date: Mon, 2 Mar 2015 17:42:27 +0000	[thread overview]
Message-ID: <20150302174227.GC29584@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <54F49917.6070608@ti.com>

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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel