Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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