[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