From: Conor Dooley <conor@kernel.org>
To: Andre Przywara <andre.przywara@arm.com>
Cc: "Aleksandr Shubin" <privatesub2@gmail.com>,
linux-kernel@vger.kernel.org,
"Conor Dooley" <conor.dooley@microchip.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Chen-Yu Tsai" <wens@csie.org>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Samuel Holland" <samuel@sholland.org>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"Marc Kleine-Budde" <mkl@pengutronix.de>,
"Maksim Kiselev" <bigunclemax@gmail.com>,
"Cristian Ciocaltea" <cristian.ciocaltea@collabora.com>,
"John Watts" <contact@jookia.org>,
"Cheo Fusi" <fusibrandon13@gmail.com>,
linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-sunxi@lists.linux.dev, linux-riscv@lists.infradead.org
Subject: Re: [PATCH v8 1/3] dt-bindings: pwm: Add binding for Allwinner D1/T113-S3/R329 PWM controller
Date: Thu, 1 Feb 2024 18:59:30 +0000 [thread overview]
Message-ID: <20240201-numbing-reconcile-64d05bb88e9c@spud> (raw)
In-Reply-To: <20240201174851.62e74089@donnerap.manchester.arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 5315 bytes --]
On Thu, Feb 01, 2024 at 05:48:51PM +0000, Andre Przywara wrote:
> On Wed, 31 Jan 2024 21:22:06 +0000
> Conor Dooley <conor@kernel.org> wrote:
>
> Hi,
>
> > 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@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@gmail.com>
> > > > Reviewed-by: Conor Dooley <conor.dooley@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@gmail.com>
> > > > + - Brandon Cheo Fusi <fusibrandon13@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?
>
> So the idea would be to add any new (specific) compatible string to that
> list then, when we add them?
> I guess this would work, but strictly speaking any current driver would
> then only need to check this property for the R329 type? The Linux
> driver proposed in the next patch *always* honours the
> allwinner,pwm-channels property, which is IMHO the right way to implement
> this. And that's why I think the binding should reflect that, and not
> explicitly *forbid* the property for every one other than R329 (atm).
>
> With the current Linux driver, a potential new SoC using:
> "allwinner,sun20i-d2-pwm", "allwinner,sun20i-d1-pwm";
> allwinner,pwm-channels = <6>;
> would work without driver changes. A driver strictly written to this
> binding here might not, though, as it would be free to ignore the
> pwm-channels property.
>
> Does that make sense? So to encourage future compatibility, can we drop
> the "else" branch?
Oh true, I see what you mean now with the example you gave. I wouldn't
respin for this alone, since the else branch could be dropped when
another user showed up given the driver doesn't restrict things.
I'm okay with your suggestion though.
Cheer,
Conor.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-02-01 18:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-31 12:59 [PATCH v8 0/3] Add support for Allwinner PWM on D1/T113s/R329 SoCs Aleksandr Shubin
2024-01-31 12:59 ` [PATCH v8 1/3] dt-bindings: pwm: Add binding for Allwinner D1/T113-S3/R329 PWM controller Aleksandr Shubin
2024-01-31 14:52 ` Andre Przywara
2024-01-31 21:22 ` Conor Dooley
2024-02-01 17:48 ` Andre Przywara
2024-02-01 18:59 ` Conor Dooley [this message]
2024-01-31 16:34 ` Maxim Kiselev
2024-05-09 20:32 ` Chris Morgan
2024-01-31 12:59 ` [PATCH v8 2/3] pwm: Add Allwinner's D1/T113-S3/R329 SoCs PWM support Aleksandr Shubin
2024-01-31 13:41 ` Philipp Zabel
2024-02-01 8:49 ` Uwe Kleine-König
2024-02-02 17:32 ` Brandon Cheo Fusi
2024-02-03 15:04 ` kernel test robot
2024-05-01 5:42 ` John Watts
2024-01-31 12:59 ` [PATCH v8 3/3] riscv: dts: allwinner: d1: Add pwm node Aleksandr Shubin
2024-01-31 14:50 ` Andre Przywara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240201-numbing-reconcile-64d05bb88e9c@spud \
--to=conor@kernel.org \
--cc=andre.przywara@arm.com \
--cc=aou@eecs.berkeley.edu \
--cc=bigunclemax@gmail.com \
--cc=conor+dt@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=contact@jookia.org \
--cc=cristian.ciocaltea@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=fusibrandon13@gmail.com \
--cc=jernej.skrabec@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=mkl@pengutronix.de \
--cc=p.zabel@pengutronix.de \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=privatesub2@gmail.com \
--cc=robh+dt@kernel.org \
--cc=samuel@sholland.org \
--cc=u.kleine-koenig@pengutronix.de \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox