As per spi pl022 binding, spear and lpc18 platform require fix in dma
properties to resolve dtbs_check warning.
Patch 1(spear): just reorder entries to resolve warning.
Patch 2(lpc): require reorder of dma pairs, and also within pairs.
In general, dmas follow below convention:
<rx,tx> = <x+1,x>
Keeping this mind, I updated entries for dma pairs.
This patchset is based on
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git, arm/dt
Kuldeep Singh (2):
ARM: dts: spear13xx: Update SPI dma properties
ARM: dts: lpc18xx: Update SPI dma properties
arch/arm/boot/dts/lpc18xx.dtsi | 19 +++++++------------
arch/arm/boot/dts/spear13xx.dtsi | 5 ++---
2 files changed, 9 insertions(+), 15 deletions(-)
--
2.25.1
Reorder dmas and dma-names property for spi controller node to make it
compliant with bindings.
Signed-off-by: Kuldeep Singh <[email protected]>
---
arch/arm/boot/dts/spear13xx.dtsi | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
index c87b881b2c8b..45f0b2a33e02 100644
--- a/arch/arm/boot/dts/spear13xx.dtsi
+++ b/arch/arm/boot/dts/spear13xx.dtsi
@@ -284,9 +284,8 @@ spi0: spi@e0100000 {
#size-cells = <0>;
interrupts = <0 31 0x4>;
status = "disabled";
- dmas = <&dwdma0 4 0 0>,
- <&dwdma0 5 0 0>;
- dma-names = "tx", "rx";
+ dmas = <&dwdma0 5 0 0>, <&dwdma0 4 0 0>;
+ dma-names = "rx", "tx";
};
rtc@e0580000 {
--
2.25.1
On 14-03-22, 12:24, Kuldeep Singh wrote:
> Dma-names order matters here.
> As per pl022 binding, dma-names order specify rx,tx and all DTs which
> have tx,rx as order start raising dtbs_chek warning. Thus, need to
> reverse this order. Please note, no functional change in this patch
> apart from just fixing warning.
>
> Warning:
> 'rx' was expected
> 'tx' was expected
Hmm. I see your point now.
dma-names:
description:
There must be at least one channel named "tx" for transmit and named "rx"
for receive.
minItems: 2
maxItems: 32
additionalItems: true
items:
- const: rx
- const: tx
I was expecting above to allow adding the items in any order, but
looks like the order is fixed with this.
--
viresh
On 12-03-22, 23:36, Kuldeep Singh wrote:
> Reorder dmas and dma-names property for spi controller node to make it
> compliant with bindings.
>
> Signed-off-by: Kuldeep Singh <[email protected]>
What about a fixes tag ?
> ---
> arch/arm/boot/dts/spear13xx.dtsi | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
> index c87b881b2c8b..45f0b2a33e02 100644
> --- a/arch/arm/boot/dts/spear13xx.dtsi
> +++ b/arch/arm/boot/dts/spear13xx.dtsi
> @@ -284,9 +284,8 @@ spi0: spi@e0100000 {
> #size-cells = <0>;
> interrupts = <0 31 0x4>;
> status = "disabled";
> - dmas = <&dwdma0 4 0 0>,
> - <&dwdma0 5 0 0>;
> - dma-names = "tx", "rx";
> + dmas = <&dwdma0 5 0 0>, <&dwdma0 4 0 0>;
> + dma-names = "rx", "tx";
Why does the order matter here since we have dma-names anyway, which
was correct earlier ?
> };
>
> rtc@e0580000 {
> --
> 2.25.1
--
viresh
On Mon, Mar 14, 2022 at 09:21:18AM +0530, Viresh Kumar wrote:
> On 12-03-22, 23:36, Kuldeep Singh wrote:
> > Reorder dmas and dma-names property for spi controller node to make it
> > compliant with bindings.
> >
> > Signed-off-by: Kuldeep Singh <[email protected]>
>
> What about a fixes tag ?
Sure, will add one.
> > ---
> > arch/arm/boot/dts/spear13xx.dtsi | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
> > index c87b881b2c8b..45f0b2a33e02 100644
> > --- a/arch/arm/boot/dts/spear13xx.dtsi
> > +++ b/arch/arm/boot/dts/spear13xx.dtsi
> > @@ -284,9 +284,8 @@ spi0: spi@e0100000 {
> > #size-cells = <0>;
> > interrupts = <0 31 0x4>;
> > status = "disabled";
> > - dmas = <&dwdma0 4 0 0>,
> > - <&dwdma0 5 0 0>;
> > - dma-names = "tx", "rx";
> > + dmas = <&dwdma0 5 0 0>, <&dwdma0 4 0 0>;
> > + dma-names = "rx", "tx";
>
> Why does the order matter here since we have dma-names anyway, which
> was correct earlier ?
Dma-names order matters here.
As per pl022 binding, dma-names order specify rx,tx and all DTs which
have tx,rx as order start raising dtbs_chek warning. Thus, need to
reverse this order. Please note, no functional change in this patch
apart from just fixing warning.
Warning:
'rx' was expected
'tx' was expected
Regards
Kuldeep
On Mon, Mar 14, 2022 at 8:31 AM Viresh Kumar <[email protected]> wrote:
>
> On 14-03-22, 12:24, Kuldeep Singh wrote:
> > Dma-names order matters here.
> > As per pl022 binding, dma-names order specify rx,tx and all DTs which
> > have tx,rx as order start raising dtbs_chek warning. Thus, need to
> > reverse this order. Please note, no functional change in this patch
> > apart from just fixing warning.
> >
> > Warning:
> > 'rx' was expected
> > 'tx' was expected
>
> Hmm. I see your point now.
>
> dma-names:
> description:
> There must be at least one channel named "tx" for transmit and named "rx"
> for receive.
> minItems: 2
> maxItems: 32
> additionalItems: true
> items:
> - const: rx
> - const: tx
>
>
> I was expecting above to allow adding the items in any order, but
> looks like the order is fixed with this.
I don't think that it was meant to have a fixed order: unlike the other
bindings that define xxx-names properties, dmas require giving
names to allow the DT to specify more than one possible DMA
specifier for a given name. This means that nothing may ever just
rely on an index but has to use the name for lookup.
OTOH, while fixing the order in the binding does not add any
value, it's also harmless as this should never be able to break
anything that worked for any combination of old/new dtb and
kernel, and it's probably easier to express in the binding.
Arnd
On 14-03-22, 11:27, Arnd Bergmann wrote:
> I don't think that it was meant to have a fixed order: unlike the other
> bindings that define xxx-names properties, dmas require giving
> names to allow the DT to specify more than one possible DMA
> specifier for a given name. This means that nothing may ever just
> rely on an index but has to use the name for lookup.
Is there a way to update the yaml or tooling in that case so it doesn't expect a
fixed order ?
> OTOH, while fixing the order in the binding does not add any
> value, it's also harmless as this should never be able to break
> anything that worked for any combination of old/new dtb and
> kernel, and it's probably easier to express in the binding.
I agree, but such a patch shouldn't be required at all, which caught my
attention. It is fine to merge it and won't break anything, but it shouldn't be
required as well.
--
viresh