All of 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: 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Andre Przywara <andre.przywara@arm.com>
Cc: devicetree@vger.kernel.org,
	"Conor Dooley" <conor.dooley@microchip.com>,
	"John Watts" <contact@jookia.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	linux-riscv@lists.infradead.org,
	"Samuel Holland" <samuel@sholland.org>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Chen-Yu Tsai" <wens@csie.org>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	linux-sunxi@lists.linux.dev, linux-pwm@vger.kernel.org,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Aleksandr Shubin" <privatesub2@gmail.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Marc Kleine-Budde" <mkl@pengutronix.de>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Maksim Kiselev" <bigunclemax@gmail.com>,
	linux-arm-kernel@lists.infradead.org,
	"Cheo Fusi" <fusibrandon13@gmail.com>,
	linux-kernel@vger.kernel.org,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Philipp Zabel" <p.zabel@pengutronix.de>
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: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
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: 48+ 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 ` Aleksandr Shubin
2024-01-31 12:59 ` 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 12:59   ` Aleksandr Shubin
2024-01-31 12:59   ` Aleksandr Shubin
2024-01-31 14:52   ` Andre Przywara
2024-01-31 14:52     ` Andre Przywara
2024-01-31 14:52     ` Andre Przywara
2024-01-31 21:22     ` Conor Dooley
2024-01-31 21:22       ` Conor Dooley
2024-01-31 21:22       ` Conor Dooley
2024-02-01 17:48       ` Andre Przywara
2024-02-01 17:48         ` Andre Przywara
2024-02-01 17:48         ` Andre Przywara
2024-02-01 18:59         ` Conor Dooley [this message]
2024-02-01 18:59           ` Conor Dooley
2024-02-01 18:59           ` Conor Dooley
2024-01-31 16:34   ` Maxim Kiselev
2024-01-31 16:34     ` Maxim Kiselev
2024-01-31 16:34     ` Maxim Kiselev
2024-05-09 20:32   ` Chris Morgan
2024-05-09 20:32     ` Chris Morgan
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 12:59   ` Aleksandr Shubin
2024-01-31 12:59   ` Aleksandr Shubin
2024-01-31 13:41   ` Philipp Zabel
2024-01-31 13:41     ` Philipp Zabel
2024-01-31 13:41     ` Philipp Zabel
2024-02-01  8:49   ` Uwe Kleine-König
2024-02-01  8:49     ` Uwe Kleine-König
2024-02-01  8:49     ` Uwe Kleine-König
2024-02-02 17:32     ` Brandon Cheo Fusi
2024-02-02 17:32       ` Brandon Cheo Fusi
2024-02-02 17:32       ` Brandon Cheo Fusi
2024-02-03 15:04   ` kernel test robot
2024-02-03 15:04     ` kernel test robot
2024-02-03 15:04     ` kernel test robot
2024-05-01  5:42   ` John Watts
2024-05-01  5:42     ` John Watts
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 12:59   ` Aleksandr Shubin
2024-01-31 12:59   ` Aleksandr Shubin
2024-01-31 14:50   ` Andre Przywara
2024-01-31 14:50     ` Andre Przywara
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.