Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

From: Thierry Reding <thierry.reding@gmail.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: devicetree@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	seanpaul@google.com, daniel.vetter@ffwll.ch, joshi@samsung.com,
	dri-devel@lists.freedesktop.org,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	ajaynumb@gmail.com, prashanth.g@samsung.com,
	Ajay Kumar <ajaykumar.rs@samsung.com>
Subject: Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
Date: Tue, 23 Sep 2014 16:50:52 +0200	[thread overview]
Message-ID: <20140923145051.GH5982@ulmo> (raw)
In-Reply-To: <8067599.NmrXQIO5A1@avalon>

[-- Attachment #1.1: Type: text/plain, Size: 2463 bytes --]

On Tue, Sep 23, 2014 at 02:12:52PM +0300, Laurent Pinchart wrote:
> On Tuesday 23 September 2014 11:53:15 Thierry Reding wrote:
> > On Tue, Sep 23, 2014 at 12:30:20PM +0300, Tomi Valkeinen wrote:
> > > On 23/09/14 09:21, Thierry Reding wrote:
> > > >> Well, I can write almost any kind of bindings, and then evidently my
> > > >> device would work. For me, on my board.
> > > > 
> > > > Well, that's the whole problem with DT. For many devices we only have a
> > > > single setup to test against. And even when we have several they often
> > > > are derived from each other. But the alternative would be to defer
> > > > (possibly indefinitely) merging support for a device until a second,
> > > > wildly different setup shows up. That's completely unreasonable and we
> > > > need to start somewhere.
> > > 
> > > Yes, but in this case we know of existing boards that have complex
> > > setups. It's not theoretical.
> > 
> > Complex setups involving /this particular/ bridge and binding are
> > theoretical at this point, however.
> > 
> > > > phandles should simply point to the next element in the pipeline and the
> > > > OS abstractions should be good enough to handle the details about how to
> > > > chain the elements.
> > > 
> > > I, on the other hand, would rather see the links the other way around.
> > > Panel having a link to the video source, etc.
> > 
> > Why? It seems much more natural to describe this using the natural flow
> > of data. The device furthest away from the CPU should be the target of
> > the phandle. That way the DT can be used to trace the flow of data down
> > the pipeline.
> > 
> > > The video graphs have two-way links, which of course is the safest
> > > options, but also more verbose and redundant.
> > 
> > Right. If we take that line of thinking to the extreme we end up listing
> > individual registers in DT so that we can safely assume that we can
> > control all possible aspects of the device.
> 
> And the other extreme would be to have a single DT node for the logical video 
> device with all information pertaining to it stored in C code. Extremes are 
> never good, we need to find a reasonable middle-ground here. I believe OF 
> graph fulfills that requirement, it might be slightly more verbose than a 
> single phandle, but it's also much more versatile. 

Oh well, yet another one of these things where we'll never reach an
agreement I guess.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel