[PATCH 1/3] dt-bindings: iio: adc: Add GPADC for Allwinner A523

Michal Piekos michal.piekos at mmpsystems.pl
Mon May 11 20:56:54 PDT 2026


On Mon, May 11, 2026 at 06:02:16PM +0200, Andre Przywara wrote:
> Hi Michal,
> 
> thanks for adding this!
> 
> On 5/10/26 14:57, Michal Piekos wrote:
> > Add support for the GPADC for the Allwinner A523. It differs from the
> > D1/T113s/R329/T507 by having two clocks.
> > 
> > Signed-off-by: Michal Piekos <michal.piekos at mmpsystems.pl>
> > ---
> >   .../iio/adc/allwinner,sun20i-d1-gpadc.yaml         | 37 +++++++++++++++++++++-
> >   1 file changed, 36 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/iio/adc/allwinner,sun20i-d1-gpadc.yaml b/Documentation/devicetree/bindings/iio/adc/allwinner,sun20i-d1-gpadc.yaml
> > index da605a051b94..89da96cd705f 100644
> > --- a/Documentation/devicetree/bindings/iio/adc/allwinner,sun20i-d1-gpadc.yaml
> > +++ b/Documentation/devicetree/bindings/iio/adc/allwinner,sun20i-d1-gpadc.yaml
> > @@ -17,6 +17,7 @@ properties:
> >         - items:
> >             - enum:
> >                 - allwinner,sun50i-h616-gpadc
> > +              - allwinner,sun55i-a523-gpadc
> >             - const: allwinner,sun20i-d1-gpadc
> 
> As Jernej already mentioned, the A523 GPADC is not fully compatible, since
> it adds another clock. The question to ask is: Can a driver only knowing
> about the fallback device handle this new device? For which the answer here
> is: No, it misses a clock.
> So add just a single entry for the A523 (plus adding it to the driver).
> 
> So looking at this I wonder if we should add some property to describe the
> number of supported channels, since they are slightly different between the
> SoCs:
> - The D1 manual mentions 2 channels.
> - The T113s manual (same die as the D1?) describes 1 channel only.
> - The T507 manual (same die as the H616) reports 4 channels.
> - The A733 has 6 channels.
> - The A133 has 1 channel, but it's channel 1, not 0.
> 
> So all of this is somewhat covered as channels are described as child nodes,
> and have a reg property. Ideally non-existing channels just wouldn't be
> listed, but I don't know if we want to rely on that.
> 
> So I am wondering if we should introduce a limit, or rather a mask (to cover
> the A133 oddity)?
> Either a DT property (channel-mask, as a single sell representing the bit
> mask), or derived in the driver from the compatible string.
> The former would avoid introducing different compatible strings just because
> of that, though I think this type of property is somewhat discouraged?
> 
> Any thoughts?

Thanks. I have missed that sparse channels are also possible. I think in
current implementation it will cause issue with lookup through
<&gpadc 1> as sun20i_gpadc_alloc_channels would effectively create
channels[0].channel = 1 in such scenario. I will try to verify if my
logic is correct and provide separate fix if needed.

Regarding DT property masking channels there is already precedence:
atmel,adc-channels-used is a bitmask of muxed and enabled channels.
Not sure if preferable though...

Michal
> 
> >     "#io-channel-cells":
> > @@ -29,7 +30,12 @@ properties:
> >       const: 0
> >     clocks:
> > -    maxItems: 1
> > +    minItems: 1
> > +    maxItems: 2
> > +
> > +  clock-names:
> > +    minItems: 1
> > +    maxItems: 2
> >     interrupts:
> >       maxItems: 1
> > @@ -40,6 +46,35 @@ properties:
> >     resets:
> >       maxItems: 1
> > +allOf:
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          items:
> > +            - const: allwinner,sun55i-a523-gpadc
> > +            - const: allwinner,sun20i-d1-gpadc
> > +    then:
> > +      properties:
> > +        clocks:
> > +          minItems: 2
> > +          maxItems: 2
> > +          items:
> > +            - description: Bus clock
> > +            - description: Module clock
> 
> I am not a YAML expert, but I think you can drop the min and max properties,
> if you just enumerate the cases. Same for the names.
> 
> Cheers,
> Andre

I will correct that in v2.
Michal.
> 
> > +        clock-names:
> > +          minItems: 2
> > +          maxItems: 2
> > +          items:
> > +            - const: bus
> > +            - const: mod
> > +      required:
> > +        - clock-names
> > +    else:
> > +      properties:
> > +        clocks:
> > +          maxItems: 1
> > +        clock-names: false
> > +
> >   patternProperties:
> >     "^channel@[0-9a-f]+$":
> >       $ref: adc.yaml
> > 
> 



More information about the linux-arm-kernel mailing list