[PATCH v2 1/4] dt-bindings: connector: Add fsl,aud-io-slot binding

Chancel Liu (OSS) chancel.liu at oss.nxp.com
Tue Jun 30 01:06:37 PDT 2026


> > From: Chancel Liu <chancel.liu at nxp.com>
> >
> > The NXP AUD-IO slot represents a physically present I/O connector on
> > the base board. It acts as a nexus that exposes a constrained set of
> > I/O resources, such as GPIOs, clocks and interrupts, through fixed
> > electrical wiring. All actual hardware providers reside on the base
> > board. The connector node only defines index-based mappings to those
> > providers.
> >
> > This connector type is present on i.MX95 19x19 EVK and i.MX952 EVK,
> > where it is used to attach the IMX-AUD-IO audio expansion card[1]. The
> > same add-on board can be reused across different base boards that
> > carry this connector.
> >
> > [1]https://www.nxp.com/part/IMX-AUD-IO
> >
> > Signed-off-by: Chancel Liu <chancel.liu at nxp.com>
> > ---
> >  .../bindings/connector/fsl,aud-io-slot.yaml   | 113 ++++++++++++++++++
> >  1 file changed, 113 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/connector/fsl,aud-io-slot.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/connector/fsl,aud-io-slot.yaml
> > b/Documentation/devicetree/bindings/connector/fsl,aud-io-slot.yaml
> > new file mode 100644
> > index 000000000000..5085574d221b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/connector/fsl,aud-io-slot.yaml
> > @@ -0,0 +1,113 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/connector/fsl,aud-io-slot.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: NXP AUD-IO Slot
> > +
> > +maintainers:
> > +  - Frank Li <Frank.li at nxp.com>
> > +  - Chancel Liu <chancel.liu at nxp.com>
> > +
> > +description:
> > +  The NXP AUD-IO slot represents a physically present I/O connector
> > +on
> > +  the base board. It acts as a nexus that exposes a constrained set
> > +of
> > +  I/O resources, such as GPIOs, clocks and interrupts, through fixed
> > +  electrical wiring. All actual hardware providers reside on the base
> > +  board. The connector node only defines index-based mappings to
> > +those
> > +  providers. This connector type is present on i.MX95 19x19 EVK and
> > +  i.MX952 EVK, where it is used to attach the IMX-AUD-IO expansion
> card.
> > +
> > +properties:
> > +  compatible:
> > +    oneOf:
> > +      - items:
> > +          - enum:
> > +              - fsl,imx952-evk-aud-io
> > +          - const: fsl,imx95-19x19-evk-aud-io
> > +      - const: fsl,imx95-19x19-evk-aud-io
> > +
> > +  gpio-controller: true
> > +
> > +  '#gpio-cells':
> > +    const: 2
> > +
> > +  gpio-map:
> > +    minItems: 1
> > +    maxItems: 32
> 
> You don't know how many GPIOs are on the connector?
>

Understood. I used a loose upper bound here, which is wrong. I will
constrain gpio-map to the exact number of GPIOs on the connector.
 
> > +
> > +  gpio-map-mask:
> > +    items:
> > +      - const: 0xffff
> > +      - const: 0x0
> > +
> > +  gpio-map-pass-thru:
> > +    items:
> > +      - const: 0x0
> > +      - const: 0x1
> > +
> > +  '#clock-cells':
> > +    const: 1
> > +
> > +  clock-map:
> > +    minItems: 1
> > +    maxItems: 16
> 
> You don't know how many clocks are on the connector?
>

Same here.

> > +
> > +  clock-map-mask:
> > +    items:
> > +      - const: 0xff
> 
> > +
> > +  clock-map-pass-thru: true
> 
> The purpose of this property (for GPIO) was to pass thru flag cells which
> are standardized. That's not the case for clocks.
>

Agreed. I will drop clock-map-pass-thru.

> Anyways, these properties need to be defined in dtschema first.
> 
> Rob

Yes. As noted in the cover letter, this series depends on Miquel
Raynal's clock nexus binding/core support:
https://lore.kernel.org/all/20260327-schneider-v7-0-rc1-crypto-v1-10-5e6ff7853994@bootlin.com/

This series is intended to be applied only after the clock nexus binding
and core support are available.

Regards, 
Chancel Liu



More information about the linux-arm-kernel mailing list