Re: [RFC PATCH v1 1/4] media: dt-bindings: max9286: add device tree binding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Geert,
   I'm replying here, even if a new version of the bindings for this
chip has been posted[1], as they have the same ports layout.

[1] https://www.spinics.net/lists/linux-renesas-soc/msg29307.html

On Wed, Jun 06, 2018 at 08:34:41AM +0200, Geert Uytterhoeven wrote:
> Hi Kieran,
>
> On Wed, Jun 6, 2018 at 1:34 AM, Kieran Bingham
> <kieran.bingham+renesas@xxxxxxxxxxxxxxxx> wrote:
> > Provide device tree binding documentation for the MAX9286 Quad GMSL
> > deserialiser.
> >
> > Signed-off-by: Kieran Bingham <kieran.bingham+renesas@xxxxxxxxxxxxxxxx>
>
> Thanks for your patch!
>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/i2c/max9286.txt
> > @@ -0,0 +1,75 @@
> > +* Maxim Integrated MAX9286 GMSL Quad 1.5Gbps GMSL Deserializer
> > +
> > +Required Properties:
> > + - compatible: Shall be "maxim,max9286"
> > +
> > +The following required properties are defined externally in
> > +Documentation/devicetree/bindings/i2c/i2c-mux.txt:
> > + - Standard I2C mux properties.
> > + - I2C child bus nodes.
> > +
> > +A maximum of 4 I2C child nodes can be specified on the MAX9286, to
> > +correspond with a maximum of 4 input devices.
> > +
> > +The device node must contain one 'port' child node per device input and output
> > +port, in accordance with the video interface bindings defined in
> > +Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
> > +are numbered as follows.
> > +
> > +      Port        Type
> > +    ----------------------
> > +       0          sink
> > +       1          sink
> > +       2          sink
> > +       3          sink
> > +       4          source
>
> I assume the source and at least one sink are thus mandatory?
>
> Would it make sense to use port 0 for the source?
> This would simplify extending the binding to devices with more input
> ports later.

I see your point, but as someone that has no idea how future chips could look
like, I wonder why having multiple outputs it's more un-likely to
happen than having more inputs added.

Do you have any suggestion on how we can handle both cases?

Thanks
   j

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux