Re: [PATCH 3/6] dt-bindings: connector: Add Toradex camera connector
From: Rob Herring
Date: Fri Sep 18 2026 - 15:23:28 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.
>
> > > +
> > > + "#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?
> >
0x3 is enough for 4 pins...
>
> 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?
This is what you are matching against. You don't want 0x12345671 to
match the 0x1 entry. So yes, all 1s is correct.
>
> > > + - 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.
Correct. You don't want 'gpio-controller' here. That and 'gpio-map' are
mutually exclusive just like interrupts. There is an exception for
interrupts for when a PCI host controller is the interrupt controller
for PCI interrupts.
Rob