[PATCH v8 1/3] dt-bindings: pwm: Add binding for Allwinner D1/T113-S3/R329 PWM controller
Conor Dooley
conor at kernel.org
Wed Jan 31 13:22:06 PST 2024
On Wed, Jan 31, 2024 at 02:52:44PM +0000, Andre Przywara wrote:
> On Wed, 31 Jan 2024 15:59:14 +0300
> Aleksandr Shubin <privatesub2 at gmail.com> wrote:
>
> Hi,
>
> > Allwinner's D1, T113-S3 and R329 SoCs have a new pwm
> > controller witch is different from the previous pwm-sun4i.
> >
> > The D1 and T113 are identical in terms of peripherals,
> > they differ only in the architecture of the CPU core, and
> > even share the majority of their DT. Because of that,
> > using the same compatible makes sense.
> > The R329 is a different SoC though, and should have
> > a different compatible string added, especially as there
> > is a difference in the number of channels.
> >
> > D1 and T113s SoCs have one PWM controller with 8 channels.
> > R329 SoC has two PWM controllers in both power domains, one of
> > them has 9 channels (CPUX one) and the other has 6 (CPUS one).
> >
> > Add a device tree binding for them.
> >
> > Signed-off-by: Aleksandr Shubin <privatesub2 at gmail.com>
> > Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
> > ---
> > .../bindings/pwm/allwinner,sun20i-pwm.yaml | 88 +++++++++++++++++++
> > 1 file changed, 88 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pwm/allwinner,sun20i-pwm.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/allwinner,sun20i-pwm.yaml b/Documentation/devicetree/bindings/pwm/allwinner,sun20i-pwm.yaml
> > new file mode 100644
> > index 000000000000..716f75776006
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pwm/allwinner,sun20i-pwm.yaml
> > @@ -0,0 +1,88 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pwm/allwinner,sun20i-pwm.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Allwinner D1, T113-S3 and R329 PWM
> > +
> > +maintainers:
> > + - Aleksandr Shubin <privatesub2 at gmail.com>
> > + - Brandon Cheo Fusi <fusibrandon13 at gmail.com>
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - const: allwinner,sun20i-d1-pwm
> > + - items:
> > + - const: allwinner,sun20i-r329-pwm
> > + - const: allwinner,sun20i-d1-pwm
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + "#pwm-cells":
> > + const: 3
> > +
> > + clocks:
> > + items:
> > + - description: Bus clock
> > + - description: 24 MHz oscillator
> > + - description: APB0 clock
> > +
> > + clock-names:
> > + items:
> > + - const: bus
> > + - const: hosc
> > + - const: apb0
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + allwinner,pwm-channels:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description: The number of PWM channels configured for this instance
> > + enum: [6, 9]
> > +
> > +allOf:
> > + - $ref: pwm.yaml#
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: allwinner,sun20i-r329-pwm
> > +
> > + then:
> > + required:
> > + - allwinner,pwm-channels
> > +
> > + else:
> > + properties:
> > + allwinner,pwm-channels: false
>
> Do we really need to be that strict?
> If something compatible to D1 pops up in the future, just with a different
> number of channels, we would need a new compatible string.
Well, you would want to have a soc specific compatible anyway then,
right?
> If we would leave this else branch out, we could just specify some
> number differing from the default, and be good.
If it were compatible with the d1, then the "then:" branch would apply,
provided you used the fallback correctly. Although if the number of
channels were different, we'd likely end up with modifications here to
limit it to the correct values for each soc.
Cheers,
Conor.
> The number of channels really looks like a parameter to the IP, it's
> modelled like this in the manual (PCR: 0x0100 + 0x0000 + N * 0x0020).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240131/40b4ef0e/attachment.sig>
More information about the linux-arm-kernel
mailing list