Linux Media Controller development
 help / color / mirror / Atom feed
From: jacopo mondi <jacopo@jmondi.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Kieran Bingham" <kieran.bingham+renesas@ideasonboard.com>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
	"Niklas Söderlund" <niklas.soderlund@ragnatech.se>
Subject: Re: [RFC PATCH v1 1/4] media: dt-bindings: max9286: add device tree binding
Date: Tue, 17 Jul 2018 14:59:30 +0200	[thread overview]
Message-ID: <20180717125930.GP8180@w540> (raw)
In-Reply-To: <CAMuHMdVLe3P0GBP9z=S2+a1SDsBe3zmUnS32J-yd4tYsP99qaQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4184 bytes --]

Hi Geert,

On Tue, Jul 17, 2018 at 02:23:16PM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Tue, Jul 17, 2018 at 2:13 PM jacopo mondi <jacopo@jmondi.org> wrote:
> >    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@ideasonboard.com> wrote:
> > > > Provide device tree binding documentation for the MAX9286 Quad GMSL
> > > > deserialiser.
> > > >
> > > > Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> > >
> > > 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.
>
> I also don't know.
> I was just thinking "What if another chip has less or more sinks?".
>
> > Do you have any suggestion on how we can handle both cases?
>
> Instead of having a single "ports" subnode, you could split it in two subnodes,
> "sinks" and "sources"? I don't know if that's feasible.
>
Maybe I didn't get you here, and sorry to repeat something obvious for
you but, that would be against basic assumptions both in fwnode/of framework
and in media framework too. See the graph.txt documentation and
video_interfaces.txt, the layout with a single 'ports' node with
multiple 'port' sub-nodes is not avoidable, afaik.

What is not -theoretically- forbidden is to have port subnodes with
multiple endpoints, which is also used as an example in multiple
places in the documentation files I mentioned above. Unfortunately, as
we experienced with the ADV748x and the R-Car CSI-2 receiver
upstreaming effort, the v4l2-async framework relies on matching on the
remote endpoint's parent device node, and Kieran and Niklas had to use
a custom endpoint matching logic for the R-Car CSI-2 and adv748x
combo, something I'm sure nobody wants to repeat here.

We said that multiple times that we would like to tackle this
limitation (if that's limitation) in the v4l2_async framework, maybe
if GMSL-like devices with multiple input/output ports comes out, we
might have enough motivation to do that ;) ?

Thanks
   j


> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2018-07-17 13:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-05 23:34 [RFC PATCH v1 0/4] GMSL Drivers Kieran Bingham
2018-06-05 23:34 ` [RFC PATCH v1 1/4] media: dt-bindings: max9286: add device tree binding Kieran Bingham
2018-06-06  6:34   ` Geert Uytterhoeven
2018-06-06  8:45     ` Kieran Bingham
2018-07-17 12:13     ` jacopo mondi
2018-07-17 12:23       ` Geert Uytterhoeven
2018-07-17 12:59         ` jacopo mondi [this message]
2018-07-17 13:04           ` Geert Uytterhoeven
2018-06-06  9:14   ` Sergei Shtylyov
2018-06-06  9:18     ` Kieran Bingham
2018-06-05 23:34 ` [RFC PATCH v1 2/4] media: i2c: Add MAX9286 driver Kieran Bingham
2018-06-05 23:34 ` [RFC PATCH v1 3/4] media: dt-bindings: rdacm20: add device tree binding Kieran Bingham
2018-06-06  9:08   ` Sergei Shtylyov
2018-06-06 10:34     ` Kieran Bingham
2018-06-05 23:34 ` [RFC PATCH v1 4/4] media: i2c: Add RDACM20 driver Kieran Bingham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180717125930.GP8180@w540 \
    --to=jacopo@jmondi.org \
    --cc=geert@linux-m68k.org \
    --cc=kieran.bingham+renesas@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=niklas.soderlund@ragnatech.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox