Re: [PATCH 3/6] dt-bindings: connector: Add Toradex camera connector

From: Frank Li

Date: Thu Sep 10 2026 - 13:37:18 EST

On Thu, Sep 10, 2026 at 06:39:30PM +0200, Ernest Van Hoecke wrote:
> Hi Frank,
>
> Thanks for reviewing this so quickly.
>
> On Thu, Sep 10, 2026 at 11:26:22AM -0500, Frank Li wrote:
> > On Thu, Sep 10, 2026 at 05:37:59PM +0200, Ernest Van Hoecke wrote:
> > > From: Ernest Van Hoecke <ernest.vanhoecke@xxxxxxxxxxx>
> > >
> > > Toradex boards route the sideband signals of their 24-pin camera
> > > connectors to different GPIO controllers. Camera overlays which name
> > > those controllers directly must therefore be duplicated for each host
> > > board.
> > >
> > > Describe reset, power-down, detection and power-control as
> > > connector-local GPIO functions. This lets an accessory overlay remain
> > > independent of the host wiring. MIPI CSI-2, I2C, clocks and supplies
> > > remain described separately because the GPIO nexus does not abstract
> > > them.
> > >
> > > Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@xxxxxxxxxxx>
> > > ---
> > > .../connector/toradex,camera-connector.yaml | 86 ++++++++++++++++++++++
> > > 1 file changed, 86 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/connector/toradex,camera-connector.yaml b/Documentation/devicetree/bindings/connector/toradex,camera-connector.yaml
> > > new file mode 100644
> > > index 000000000000..06e6836e1aa6
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/connector/toradex,camera-connector.yaml
> > > @@ -0,0 +1,86 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/connector/toradex,camera-connector.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/base.yaml#
> > > +
> > > +title: Toradex camera connector GPIO nexus
> > > +
> > > +maintainers:
> > > + - Ernest Van Hoecke <ernest.vanhoecke@xxxxxxxxxxx>
> > > + - Toradex Linux BSP Team <linux-bsp@xxxxxxxxxxx>
> > > +
> > > +description: |
> > > + Toradex boards provide 24-pin camera connectors carrying MIPI CSI-2, I2C,
> > > + clock, power, and sideband GPIO signals. This binding describes the sideband
> > > + signals as a GPIO nexus. The other connector resources remain described by
> > > + the surrounding board device tree.
> > > +
> > > + The nexus exposes connector-local GPIO function numbers to camera overlays
> > > + and maps the functions wired by a carrier board to their GPIO controllers.
> > > + GPIO specifiers contain a function number followed by standard GPIO flags.
> > > + A board may omit functions which it does not wire.
> > > +
> > > + The function numbers are:
> > > + - 0: Camera reset, connector pin 11
> > > + - 1: Camera power-down, connector pin 22
> > > + - 2: Camera identification, connector pin 23
> > > + - 3: Camera power control, connector pin 24
> > > +
> > > +properties:
> > > + compatible:
> > > + const: toradex,camera-connector
> >
> > Name is too generally, suggest use board name, we got similar comments at
> >
> > https://lore.kernel.org/imx/20260629074734.3643227-2-chancel.liu@xxxxxxxxxxx/
>
> I saw that and it made me reconsider this name.
>
> However, I believe that in our case it is specific enough. It is really
> the same on all our carrier boards, and Toradex specific. It's also only
> for cameras, which is more defined than just "io". Curious to see if
> others agree or if we should come up with a name for this.

If some days later, you update hardware connector to 30pin from 24pins.

>
> > > +
> > > + "#gpio-cells":
> > > + const: 2
> > > +
> > > + gpio-map:
> > > + minItems: 1
> > > + maxItems: 4
> > > +
> > > + gpio-map-mask:
> > > + items:
> > > + - const: 0xffffffff
> >
> > are you sure need full 32bit, only 4 pin, maybe 0xf should enough?
> >
>
> Indeed we could reduce the size of the mask, but I don't really see the
> value in it. Isn't it good that a user can pass through the full GPIO?

it works, I remember it control input index's width.

<0 0 &gpio1 0 GPIO_ACTIVE_HIGH>
^

You can wait for dt team's comments for this.

>
> > > + - const: 0
> > > +
> > > + gpio-map-pass-thru:
> > > + items:
> > > + - const: 0
> > > + - const: 0xffffffff
> > > +
> >
> > missed
> > gpio-controller: true
> >
>
> This is one thing I didn't fully understand about the GPIO nexus
> concept, why would we need this gpio-controller flag? Isn't the gpio
> controller behind the nexus? The nexus just maps onto it. The actual
> controller would be on the SoC or an expander.

Yes, I remember "#gpio-cells" depend on "gpio-controller", does
pass dt_binding_check?

>
> > > +required:
> > > + - compatible
> > > + - "#gpio-cells"
> > > + - gpio-map
> > > + - gpio-map-mask
> > > + - gpio-map-pass-thru
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > + #include <dt-bindings/gpio/gpio.h>
> > > +
> > > + camera-connector {
> > > + compatible = "toradex,camera-connector";
> > > + #gpio-cells = <2>;
> > > + /*
> > > + * 0: Camera reset, connector pin 11
> > > + * 1: Camera power-down, connector pin 22
> > > + * 2: Camera identification, connector pin 23
> > > + * 3: Camera power control, connector pin 24
> > > + */
> > > + gpio-map = <0 0 &gpio1 0 GPIO_ACTIVE_HIGH>,
> > > + <1 0 &gpio1 1 GPIO_ACTIVE_HIGH>,
> > > + <2 0 &gpio1 2 GPIO_ACTIVE_HIGH>,
> > > + <3 0 &gpio1 3 GPIO_ACTIVE_HIGH>;
> > > + gpio-map-mask = <0xffffffff 0x0>;
> > > + gpio-map-pass-thru = <0x0 0xffffffff>;
> > > + };
> > > +
> > > + gpio1: gpio-controller {
> > > + #gpio-cells = <2>;
> > > + gpio-controller;
> > > + };
> >
> > Need't gpio-controller.
> >
> > Frank
> >
>
> This ties in to my same confusion above, could you explain why or point
> me to a relevant example/docs?

My means needn't whole gpio-controller{} block, like &its, needn't add
node of interrupt controllers.

Example should not contain unrelated device
nodes, e.g. consumer nodes in a provider binding, other nodes referenced by
phandles or node labels which are not directly referenced in the example
itself. Phandles in the example do not have to be resolvable.

Frank

>
> Thanks and kind regards,
> Ernest