RE: [PATCH v6 1/4] dt-bindings: media: ti,ds90ub953: Add support for remote GPIO data source

[G.N. Zhou (OSS)]

Hi Linus,

> -----Original Message-----
> From: Linus Walleij <linusw@xxxxxxxxxx>
> Sent: Tuesday, April 28, 2026 4:50 AM
> To: G.N. Zhou (OSS) <guoniu.zhou@xxxxxxxxxxx>
> Cc: Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx>; Mauro Carvalho
> Chehab <mchehab@xxxxxxxxxx>; Rob Herring <robh@xxxxxxxxxx>; Krzysztof
> Kozlowski <krzk+dt@xxxxxxxxxx>; Conor Dooley <conor+dt@xxxxxxxxxx>; Frank
> Li <frank.li@xxxxxxx>; Vladimir Zapolskiy <vz@xxxxxxxxx>; Bartosz
> Golaszewski <brgl@xxxxxxxxxx>; linux-media@xxxxxxxxxxxxxxx;
> devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; imx@xxxxxxxxxxxxxxx;
> linux-gpio@xxxxxxxxxxxxxxx; G.N. Zhou <guoniu.zhou@xxxxxxx>
> Subject: Re: [PATCH v6 1/4] dt-bindings: media: ti,ds90ub953: Add support for
> remote GPIO data source
> 
> On Mon, Apr 27, 2026 at 11:13 AM G.N. Zhou (OSS)
> <guoniu.zhou@xxxxxxxxxxx> wrote:
> > [Me]
> 
> > > I understand that the driver needs to deal with this in a
> > > per-gpio-line basis though, have you considered:
> > >
> > > 1. Just hard-coding this into the driver based on the .compatible
> > >   string, if the remote GPIOs are always the same for this TI thing?
> > >
> > > 2. If it is just for one particular system, you *could* actually have
> > >   a table/mask inside the driver for this:
> > >   if (of_machine_is_compatible("my-funky-system")) which will
> > >   kick in only on that very machine,
> > >
> > > 3. If you really want to store the information in the media i2c
> > >   device node, add some custom property like this:
> > >   ti,remote-sources = <0x0000001f>;
> > >   where a bit is set to 1 for each GPIO which is remote.
> > >
> > > Putting flags on the GPIO lines themselves seems too complex and
> > > system- specific.
> >
> > Thank you for the detailed feedback.
> >
> > After considering your suggestions, I think option 3 (custom device
> > property) is the most appropriate approach for this case.
> 
> Why is that the most appropriate?
> 
> I think (1) is most appropriate, if the hardware with this compatible always
> looks like this. You need to answer the question if this is a per-system flag for
> the GPIO lines or something that is *always* applicable for a device with
> compatible ti,ds90ub9NN-q1?
> 
> If it for example always applies to ti,ds90ub971-q1, then make that compatible
> decide how to handle indvidual line, just write code for it. That is case (1).
> 
> If this setting depends on how the serializer is integrated and the remote
> setting may apply to some systems with this device and not others, you have
> options (2) and (3).
> 
> > However, I initially implemented this using a custom device property
> > (ti,gpio-data) in v1 [1], and Vladimir rejected that approach.
> 
> Vladimir is saying that the driver code should handle this without any extra DT
> properties. That can be done with approach
> (1) and (2). But I don't know about that.
> 
> I think the basic problem with the patch is that no-one (myself included) apart
> from you understand what a remote serializer is, why it is remote and what
> that means, how the mechanism between the components making up this
> essentially works etc. I.e. a much longer and more detailed commit message
> and binding explaining very cleary what this is and how it works and why the
> special property is needed on some lines, and how it is a property of some
> specific way of integrating this GPIO controller.
> 
> If a custom property should be used ti,gpio-data is too generic, come up with a
> property name that actually says what it is all about and which anyone would
> understand. "gpio-data" is a bit "the thing that does the thing" and overly
> generic term.

Thank you for this feedback. Let me explain the hardware architecture and the
reason I chose option (3).

Hardware Architecture:
SoC --- I2C --- DS90UB960 (Deserializer) ---+--- FPD-Link --- DS90UB953 (Ser) --- OX03C10 Camera
                                                                           +--- FPD-Link --- DS90UB953 (Ser) --- OX03C10 Camera
                                                                           +--- FPD-Link --- DS90UB953 (Ser) --- OX03C10 Camera
                                                                           +--- FPD-Link --- DS90UB953 (Ser) --- OX03C10 Camera

Each DS90UB953 serializer has 4 GPIO pins. One of these GPIOs connects to the
OX03C10 camera's FSIN (frame sync input) pin for multi-camera synchronization.

The Problem - Remote vs Local GPIO Data Source:
-----------------------------------------------
The DS90UB953's GPIO pins can operate in two modes:
1. LOCAL mode: GPIO data comes from the I2C-controlled GPIO register
   - Standard GPIO expander behavior
   - Data written via I2C controls the pin state

2. REMOTE mode: GPIO data comes from the DS90UB960 deserializer
   - The DS90UB960 generates a frame sync signal internally
   - This signal is transmitted to the DS90UB953 via the FPD-Link back channel
   - The DS90UB953 routes this remote signal to the specified GPIO pin
   - The GPIO pin state is NOT controlled by I2C register writes

For camera synchronization, we need REMOTE mode: the FSIN GPIO must receive
the frame sync signal from the deserializer, not from local I2C writes.

Regarding option1, the remote GPIO configuration can vary between different board
designs using the same TI device, so hard-coding based on .compatible wouldn't be
flexible enough. 

Regarding option 2, if I understand correctly, driver would require adding a new
compatible string or mask entry for every different board configuration, which
doesn't scale well.

> 
> Yours,
> Linus Walleij