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

From: Thierry Reding <thierry.reding@gmail.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.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,
	Laurent Pinchart <laurent.pinchart@ideasonboard.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 11:53:15 +0200	[thread overview]
Message-ID: <20140923095314.GS30514@ulmo> (raw)
In-Reply-To: <54213DAC.5010806@ti.com>

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

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.

Like I said, this seems to be the latest response to DT ABI stability
requirement. Add as much data to a DT node as possible so that it has
higher chances of being complete. The result is often overly complex DT
content that doesn't add any real value.

> When this was discussed earlier, it was unclear which way the links
> should be. It's true that only links to one direction are strictly
> needed, but the question raised was that if in the drivers we end up
> always going the links the other way, the performance penalty may be
> somewhat big. (If I recall right).

I doubt that graphs will become so complex that walking it would become
a performance bottleneck. In fact if we're constantly walking the graph
we're already doing something wrong. It should only be necessary when
the pipeline configuration changes, which should hopefully not be very
often (i.e. not several times per second).

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