[RFC] media DT bindings

Laurent Pinchart laurent.pinchart at ideasonboard.com
Wed Aug 1 15:59:59 EST 2012


Hi Stephen,

On Tuesday 31 July 2012 17:29:24 Stephen Warren wrote:
> On 07/31/2012 03:22 PM, Laurent Pinchart wrote:
> > On Tuesday 31 July 2012 14:39:07 Guennadi Liakhovetski wrote:
> ...
> 
> >> Ok, then, how about
> >> 
> >> 		#address-cells = <1>;
> >> 		#size-cells = <0>;
> >> 		...
> >> 		ov772x-1 = {
> >> 		
> >> 			reg = <1>;			/* local pad # */
> >> 			client = <&ov772x at 0x21-0 0>;	/* remote phandle and pad */
> > 
> > The client property looks good, but isn't such a usage of the reg property
> > an abuse ? Maybe the local pad # should be a device-specific property.
> > Many hosts won't need it, and on others it would actually need to
> > reference a subdev, not just a pad.
> 
> That's a very odd syntax the the phandle; I assume that "&ov772x at 0x21-0"
> is supposed to reference some other DT node. However, other nodes are
> either referenced by:
> 
> "&foo" where foo is a label, and the label name is unlikely to include
> the text "@0x21"; the @ symbol probably isn't even legal in label names.
> 
> "&{/path/to/node}" which might include the "@0x21" syntax since it might
> be part of the node's name, but your example didn't include {}.
> 
> I'm not sure what "-0" is meant to be in that string - a math
> expression, or ...? If it's intended to represent some separate field
> relative to the node the phandle references, it needs to be just another
> cell.

I'm actually not sure what -0 represents, and I don't think we need the 
@0x21-0 at all. I believe &ov772x at 0x21-0 is supposed to just be a label. We 
don't need an extra cell.

> So overall, perhaps:
> 
> / {
>    ...
>    pad: something { ... };
>    ...
>    ov772x at 1 = { /* @1 not -1 would be canonical syntax */
>      reg = <1>;
>      client = <&pad 0 0>;
>    ...
> 
> I'm sorry I haven't followed the thread; I'm wondering why a client is a
> pad, which to me means a pin/pad/ball on an IC package, so I'm still not
> entirely sure if even this makes sense.

Client references an image source (which is usually an I2C client, but can be 
a different type of device) and a pad. Pad refers here to a media entity pad 
(see http://linuxtv.org/downloads/v4l-dvb-apis/media-controller-model.html), 
not a physical pin on an IC package.

-- 
Regards,

Laurent Pinchart



More information about the devicetree-discuss mailing list