[PATCH] media: add V4L2 DT binding documentation

[Guennadi Liakhovetski]

On Wed, 12 Sep 2012, Stephen Warren wrote:

> On 09/12/2012 01:28 PM, Guennadi Liakhovetski wrote:
> > Hi Stephen
> > 
> > On Wed, 12 Sep 2012, Stephen Warren wrote:
> > 
> >> On 09/11/2012 09:51 AM, Guennadi Liakhovetski wrote:
> >>> This patch adds a document, describing common V4L2 device tree bindings.
> >>>
> >>> Co-authored-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> >>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
> >>
> >> Overall, I think this looks pretty reasonable, so:
> ...
> >>
> >>> +			clock-frequency = <50000000>;	/* max clock frequency */
> >>> +			clock-output-names = "mclk";
> >>> +		};
> >>> +
> >>> +		port {
> >> ...
> >>> +			ceu0_0: link at 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.

> > 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.

> > 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/