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

[Frank Li <Frank.li@oss.nxp.com>]

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@toradex.com>
> > >
> > > 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@toradex.com>
> > > ---
> > >  .../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@toradex.com>
> > > +  - Toradex Linux BSP Team <linux-bsp@toradex.com>
> > > +
> > > +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@oss.nxp.com/
>
> 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