On Wed, 12 Sep 2012, Stephen Warren wrote:

On 09/12/2012 01:28 PM, Guennadi Liakhovetski wrote:

quoted

Hi Stephen

On Wed, 12 Sep 2012, Stephen Warren wrote:

quoted

On 09/11/2012 09:51 AM, Guennadi Liakhovetski wrote:

quoted

This patch adds a document, describing common V4L2 device tree bindings.

Co-authored-by: Sylwester Nawrocki [off-list ref]
Signed-off-by: Guennadi Liakhovetski <redacted>

Overall, I think this looks pretty reasonable, so:

...

quoted

quoted

quoted

+			clock-frequency = <50000000>;	/* max clock frequency */
+			clock-output-names = "mclk";
+		};
+
+		port {

...

quoted

+			ceu0_0: link@0 {
+				reg = <0>;
+				remote = <&csi2_2>;
+				immutable;

Did we decide "immutable" was actually needed? Presumably the driver for
the HW in question knows the HW isn't configurable, and would simply not
attempt to apply any configuration even if the .dts author erroneously
provided some?

Well, I've been thinking about this today. I think, bridge drivers will 

Sorry, I'm not sure what a "bridge" driver is; is it any v4l2 device?

Right, sorry for not explaining. We call a bridge a device, that's sitting 
on a bus like USB, PCI or - as in the SoC case - on an internal one and 
interfacing to, say, a video sensor or a TV decoder or encoder. In the SoC 
case most primitive bridges just take data from video sensors attached 
over, say, an 8-bit parallel bus and DMA it into RAM buffers. Some bridges 
can also perform some data processing.

quoted

call centrally provided helper functions to enumerate links inside ports. 

Presumably a given driver would only parse the ports/links of its own DT
node, and hence would be able to provide a parameter to any helper
function that indicated the same information that "immutable" would?

Well, let's drop "immutable" for now, since we don't have a good idea 
whether we need it or not. If we do need it, we'll add it later, removing 
a part of a standart is more difficult.

quoted

While doing that they will want to differentiate between links to external 
devices with explicit configuration, and links to internal devices, whose 
configuration drivers might be able to figure out themselves. How should a 
driver find out what device this link is pointing to? Should it follow the 
"remote" phandle and then check the "compatible" property? The word 
"immutable" is a hint, that this is a link to an internal device, but it 
might either be unneeded or be transformed into something more 
informative.

I would imagine that a given driver would only ever parse its own DT
node; the far end of any link is purely the domain of the other driver.
I thought that each link node would contain whatever hsync-active,
data-lanes, ... properties that were needed to configure the local device?

I think, information needed to configure a bridge device to connect to a 
camera sensor, like sync polarities etc., might not be sufficient to 
configure it to interface to an SoC internal unit, like a MIPI CSI-2 
interface. I can see 2 possibilities to recognise, that this link is going 
to an internal device: (1) follow the remote phandle, (2) use a 
vendor-specific property to specify the remote device type. I guess, you'd 
prefer the latter?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/