* [PATCH v4 0/3] Determine the number of DMA channels by 'dma-channels' property @ 2022-01-17 1:35 ` Zong Li 0 siblings, 0 replies; 30+ messages in thread From: Zong Li @ 2022-01-17 1:35 UTC (permalink / raw) To: robh+dt, paul.walmsley, palmer, aou, krzysztof.kozlowski, conor.dooley, geert, bin.meng, green.wan, vkoul, dmaengine, devicetree, linux-kernel, linux-riscv Cc: Zong Li The PDMA driver currently assumes there are four channels by default, it might cause the error if there is actually less than four channels. Change that by getting number of channel dynamically from device tree. For backwards-compatible, it uses the default value (i.e. 4) when there is no 'dma-channels' information in dts. This patch set contains the dts and dt-bindings change. Changed in v4: - Remove cflags of debug use reported-by: kernel test robot <lkp@intel.com> Changed in v3: - Fix allocating wrong size - Return error if 'dma-channels' is larger than maximum Changed in v2: - Rebase on tag v5.16 - Use 4 as default value of dma-channels Zong Li (3): riscv: dts: Add dma-channels property in dma node dt-bindings: Add dma-channels for pdma device node dmaengine: sf-pdma: Get number of channel by device tree .../bindings/dma/sifive,fu540-c000-pdma.yaml | 7 +++++++ .../boot/dts/microchip/microchip-mpfs.dtsi | 1 + arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 1 + drivers/dma/sf-pdma/sf-pdma.c | 20 ++++++++++++------- drivers/dma/sf-pdma/sf-pdma.h | 8 ++------ 5 files changed, 24 insertions(+), 13 deletions(-) -- 2.31.1 ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v4 0/3] Determine the number of DMA channels by 'dma-channels' property @ 2022-01-17 1:35 ` Zong Li 0 siblings, 0 replies; 30+ messages in thread From: Zong Li @ 2022-01-17 1:35 UTC (permalink / raw) To: robh+dt, paul.walmsley, palmer, aou, krzysztof.kozlowski, conor.dooley, geert, bin.meng, green.wan, vkoul, dmaengine, devicetree, linux-kernel, linux-riscv Cc: Zong Li The PDMA driver currently assumes there are four channels by default, it might cause the error if there is actually less than four channels. Change that by getting number of channel dynamically from device tree. For backwards-compatible, it uses the default value (i.e. 4) when there is no 'dma-channels' information in dts. This patch set contains the dts and dt-bindings change. Changed in v4: - Remove cflags of debug use reported-by: kernel test robot <lkp@intel.com> Changed in v3: - Fix allocating wrong size - Return error if 'dma-channels' is larger than maximum Changed in v2: - Rebase on tag v5.16 - Use 4 as default value of dma-channels Zong Li (3): riscv: dts: Add dma-channels property in dma node dt-bindings: Add dma-channels for pdma device node dmaengine: sf-pdma: Get number of channel by device tree .../bindings/dma/sifive,fu540-c000-pdma.yaml | 7 +++++++ .../boot/dts/microchip/microchip-mpfs.dtsi | 1 + arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 1 + drivers/dma/sf-pdma/sf-pdma.c | 20 ++++++++++++------- drivers/dma/sf-pdma/sf-pdma.h | 8 ++------ 5 files changed, 24 insertions(+), 13 deletions(-) -- 2.31.1 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v4 1/3] riscv: dts: Add dma-channels property in dma node 2022-01-17 1:35 ` Zong Li @ 2022-01-17 1:35 ` Zong Li -1 siblings, 0 replies; 30+ messages in thread From: Zong Li @ 2022-01-17 1:35 UTC (permalink / raw) To: robh+dt, paul.walmsley, palmer, aou, krzysztof.kozlowski, conor.dooley, geert, bin.meng, green.wan, vkoul, dmaengine, devicetree, linux-kernel, linux-riscv Cc: Zong Li Add dma-channels property, then we can determine how many channels there by device tree. Signed-off-by: Zong Li <zong.li@sifive.com> --- arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi | 1 + arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi index c9f6d205d2ba..3c48f2d7a4a4 100644 --- a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi @@ -188,6 +188,7 @@ dma@3000000 { reg = <0x0 0x3000000 0x0 0x8000>; interrupt-parent = <&plic>; interrupts = <23 24 25 26 27 28 29 30>; + dma-channels = <4>; #dma-cells = <1>; }; diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi index 0655b5c4201d..2bdfe7f06e4b 100644 --- a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi +++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi @@ -171,6 +171,7 @@ dma: dma@3000000 { reg = <0x0 0x3000000 0x0 0x8000>; interrupt-parent = <&plic0>; interrupts = <23 24 25 26 27 28 29 30>; + dma-channels = <4>; #dma-cells = <1>; }; uart1: serial@10011000 { -- 2.31.1 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v4 1/3] riscv: dts: Add dma-channels property in dma node @ 2022-01-17 1:35 ` Zong Li 0 siblings, 0 replies; 30+ messages in thread From: Zong Li @ 2022-01-17 1:35 UTC (permalink / raw) To: robh+dt, paul.walmsley, palmer, aou, krzysztof.kozlowski, conor.dooley, geert, bin.meng, green.wan, vkoul, dmaengine, devicetree, linux-kernel, linux-riscv Cc: Zong Li Add dma-channels property, then we can determine how many channels there by device tree. Signed-off-by: Zong Li <zong.li@sifive.com> --- arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi | 1 + arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi index c9f6d205d2ba..3c48f2d7a4a4 100644 --- a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi @@ -188,6 +188,7 @@ dma@3000000 { reg = <0x0 0x3000000 0x0 0x8000>; interrupt-parent = <&plic>; interrupts = <23 24 25 26 27 28 29 30>; + dma-channels = <4>; #dma-cells = <1>; }; diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi index 0655b5c4201d..2bdfe7f06e4b 100644 --- a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi +++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi @@ -171,6 +171,7 @@ dma: dma@3000000 { reg = <0x0 0x3000000 0x0 0x8000>; interrupt-parent = <&plic0>; interrupts = <23 24 25 26 27 28 29 30>; + dma-channels = <4>; #dma-cells = <1>; }; uart1: serial@10011000 { -- 2.31.1 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH v4 1/3] riscv: dts: Add dma-channels property in dma node 2022-01-17 1:35 ` Zong Li @ 2022-01-18 15:04 ` Conor.Dooley -1 siblings, 0 replies; 30+ messages in thread From: Conor.Dooley @ 2022-01-18 15:04 UTC (permalink / raw) To: zong.li, robh+dt, paul.walmsley, palmer, aou, krzysztof.kozlowski, geert, bin.meng, green.wan, vkoul, dmaengine, devicetree, linux-kernel, linux-riscv On 17/01/2022 01:35, Zong Li wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Add dma-channels property, then we can determine how many channels there > by device tree. > > Signed-off-by: Zong Li <zong.li@sifive.com> > --- > arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi | 1 + > arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > index c9f6d205d2ba..3c48f2d7a4a4 100644 > --- a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > @@ -188,6 +188,7 @@ dma@3000000 { > reg = <0x0 0x3000000 0x0 0x8000>; > interrupt-parent = <&plic>; > interrupts = <23 24 25 26 27 28 29 30>; > + dma-channels = <4>; > #dma-cells = <1>; > }; For mpfs: Acked-by: Conor Dooley <conor.dooley@microchip.com> > > diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > index 0655b5c4201d..2bdfe7f06e4b 100644 > --- a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > +++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > @@ -171,6 +171,7 @@ dma: dma@3000000 { > reg = <0x0 0x3000000 0x0 0x8000>; > interrupt-parent = <&plic0>; > interrupts = <23 24 25 26 27 28 29 30>; > + dma-channels = <4>; > #dma-cells = <1>; > }; > uart1: serial@10011000 { > -- > 2.31.1 > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 1/3] riscv: dts: Add dma-channels property in dma node @ 2022-01-18 15:04 ` Conor.Dooley 0 siblings, 0 replies; 30+ messages in thread From: Conor.Dooley @ 2022-01-18 15:04 UTC (permalink / raw) To: zong.li, robh+dt, paul.walmsley, palmer, aou, krzysztof.kozlowski, geert, bin.meng, green.wan, vkoul, dmaengine, devicetree, linux-kernel, linux-riscv On 17/01/2022 01:35, Zong Li wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Add dma-channels property, then we can determine how many channels there > by device tree. > > Signed-off-by: Zong Li <zong.li@sifive.com> > --- > arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi | 1 + > arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > index c9f6d205d2ba..3c48f2d7a4a4 100644 > --- a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > @@ -188,6 +188,7 @@ dma@3000000 { > reg = <0x0 0x3000000 0x0 0x8000>; > interrupt-parent = <&plic>; > interrupts = <23 24 25 26 27 28 29 30>; > + dma-channels = <4>; > #dma-cells = <1>; > }; For mpfs: Acked-by: Conor Dooley <conor.dooley@microchip.com> > > diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > index 0655b5c4201d..2bdfe7f06e4b 100644 > --- a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > +++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > @@ -171,6 +171,7 @@ dma: dma@3000000 { > reg = <0x0 0x3000000 0x0 0x8000>; > interrupt-parent = <&plic0>; > interrupts = <23 24 25 26 27 28 29 30>; > + dma-channels = <4>; > #dma-cells = <1>; > }; > uart1: serial@10011000 { > -- > 2.31.1 > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 1/3] riscv: dts: Add dma-channels property in dma node 2022-01-17 1:35 ` Zong Li @ 2022-01-20 18:51 ` Palmer Dabbelt -1 siblings, 0 replies; 30+ messages in thread From: Palmer Dabbelt @ 2022-01-20 18:51 UTC (permalink / raw) To: zong.li Cc: robh+dt, Paul Walmsley, aou, krzysztof.kozlowski, conor.dooley, geert, bin.meng, green.wan, vkoul, dmaengine, devicetree, linux-kernel, linux-riscv, zong.li On Sun, 16 Jan 2022 17:35:26 PST (-0800), zong.li@sifive.com wrote: > Add dma-channels property, then we can determine how many channels there > by device tree. > > Signed-off-by: Zong Li <zong.li@sifive.com> > --- > arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi | 1 + > arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > index c9f6d205d2ba..3c48f2d7a4a4 100644 > --- a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > @@ -188,6 +188,7 @@ dma@3000000 { > reg = <0x0 0x3000000 0x0 0x8000>; > interrupt-parent = <&plic>; > interrupts = <23 24 25 26 27 28 29 30>; > + dma-channels = <4>; > #dma-cells = <1>; > }; > > diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > index 0655b5c4201d..2bdfe7f06e4b 100644 > --- a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > +++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > @@ -171,6 +171,7 @@ dma: dma@3000000 { > reg = <0x0 0x3000000 0x0 0x8000>; > interrupt-parent = <&plic0>; > interrupts = <23 24 25 26 27 28 29 30>; > + dma-channels = <4>; > #dma-cells = <1>; > }; > uart1: serial@10011000 { I've got some comments in on the bindings, but I'm assuming it's easier to keep these all together. Happy to take this through the RISC-V tree, but I'm guessing it'll be easier to take these via dmaengine as there's a lot more diff there so Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Thanks! ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 1/3] riscv: dts: Add dma-channels property in dma node @ 2022-01-20 18:51 ` Palmer Dabbelt 0 siblings, 0 replies; 30+ messages in thread From: Palmer Dabbelt @ 2022-01-20 18:51 UTC (permalink / raw) To: zong.li Cc: robh+dt, Paul Walmsley, aou, krzysztof.kozlowski, conor.dooley, geert, bin.meng, green.wan, vkoul, dmaengine, devicetree, linux-kernel, linux-riscv, zong.li On Sun, 16 Jan 2022 17:35:26 PST (-0800), zong.li@sifive.com wrote: > Add dma-channels property, then we can determine how many channels there > by device tree. > > Signed-off-by: Zong Li <zong.li@sifive.com> > --- > arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi | 1 + > arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > index c9f6d205d2ba..3c48f2d7a4a4 100644 > --- a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > @@ -188,6 +188,7 @@ dma@3000000 { > reg = <0x0 0x3000000 0x0 0x8000>; > interrupt-parent = <&plic>; > interrupts = <23 24 25 26 27 28 29 30>; > + dma-channels = <4>; > #dma-cells = <1>; > }; > > diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > index 0655b5c4201d..2bdfe7f06e4b 100644 > --- a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > +++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > @@ -171,6 +171,7 @@ dma: dma@3000000 { > reg = <0x0 0x3000000 0x0 0x8000>; > interrupt-parent = <&plic0>; > interrupts = <23 24 25 26 27 28 29 30>; > + dma-channels = <4>; > #dma-cells = <1>; > }; > uart1: serial@10011000 { I've got some comments in on the bindings, but I'm assuming it's easier to keep these all together. Happy to take this through the RISC-V tree, but I'm guessing it'll be easier to take these via dmaengine as there's a lot more diff there so Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Thanks! _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 1/3] riscv: dts: Add dma-channels property in dma node 2022-01-17 1:35 ` Zong Li @ 2022-01-27 7:03 ` Vinod Koul -1 siblings, 0 replies; 30+ messages in thread From: Vinod Koul @ 2022-01-27 7:03 UTC (permalink / raw) To: Zong Li Cc: robh+dt, paul.walmsley, palmer, aou, krzysztof.kozlowski, conor.dooley, geert, bin.meng, green.wan, dmaengine, devicetree, linux-kernel, linux-riscv On 17-01-22, 09:35, Zong Li wrote: > Add dma-channels property, then we can determine how many channels there > by device tree. > > Signed-off-by: Zong Li <zong.li@sifive.com> > --- > arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi | 1 + > arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > index c9f6d205d2ba..3c48f2d7a4a4 100644 > --- a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > @@ -188,6 +188,7 @@ dma@3000000 { Unrelated but the node name should be dma-controller@... > reg = <0x0 0x3000000 0x0 0x8000>; > interrupt-parent = <&plic>; > interrupts = <23 24 25 26 27 28 29 30>; > + dma-channels = <4>; > #dma-cells = <1>; > }; > > diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > index 0655b5c4201d..2bdfe7f06e4b 100644 > --- a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > +++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > @@ -171,6 +171,7 @@ dma: dma@3000000 { > reg = <0x0 0x3000000 0x0 0x8000>; > interrupt-parent = <&plic0>; > interrupts = <23 24 25 26 27 28 29 30>; > + dma-channels = <4>; > #dma-cells = <1>; > }; > uart1: serial@10011000 { > -- > 2.31.1 -- ~Vinod ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 1/3] riscv: dts: Add dma-channels property in dma node @ 2022-01-27 7:03 ` Vinod Koul 0 siblings, 0 replies; 30+ messages in thread From: Vinod Koul @ 2022-01-27 7:03 UTC (permalink / raw) To: Zong Li Cc: robh+dt, paul.walmsley, palmer, aou, krzysztof.kozlowski, conor.dooley, geert, bin.meng, green.wan, dmaengine, devicetree, linux-kernel, linux-riscv On 17-01-22, 09:35, Zong Li wrote: > Add dma-channels property, then we can determine how many channels there > by device tree. > > Signed-off-by: Zong Li <zong.li@sifive.com> > --- > arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi | 1 + > arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > index c9f6d205d2ba..3c48f2d7a4a4 100644 > --- a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > @@ -188,6 +188,7 @@ dma@3000000 { Unrelated but the node name should be dma-controller@... > reg = <0x0 0x3000000 0x0 0x8000>; > interrupt-parent = <&plic>; > interrupts = <23 24 25 26 27 28 29 30>; > + dma-channels = <4>; > #dma-cells = <1>; > }; > > diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > index 0655b5c4201d..2bdfe7f06e4b 100644 > --- a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > +++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > @@ -171,6 +171,7 @@ dma: dma@3000000 { > reg = <0x0 0x3000000 0x0 0x8000>; > interrupt-parent = <&plic0>; > interrupts = <23 24 25 26 27 28 29 30>; > + dma-channels = <4>; > #dma-cells = <1>; > }; > uart1: serial@10011000 { > -- > 2.31.1 -- ~Vinod _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 1/3] riscv: dts: Add dma-channels property in dma node 2022-01-27 7:03 ` Vinod Koul @ 2022-01-27 7:35 ` Zong Li -1 siblings, 0 replies; 30+ messages in thread From: Zong Li @ 2022-01-27 7:35 UTC (permalink / raw) To: Vinod Koul Cc: Rob Herring, Paul Walmsley, Palmer Dabbelt, Albert Ou, Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven, Bin Meng, Green Wan, dmaengine, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel@vger.kernel.org List, linux-riscv On Thu, Jan 27, 2022 at 3:03 PM Vinod Koul <vkoul@kernel.org> wrote: > > On 17-01-22, 09:35, Zong Li wrote: > > Add dma-channels property, then we can determine how many channels there > > by device tree. > > > > Signed-off-by: Zong Li <zong.li@sifive.com> > > --- > > arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi | 1 + > > arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 1 + > > 2 files changed, 2 insertions(+) > > > > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > > index c9f6d205d2ba..3c48f2d7a4a4 100644 > > --- a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > > @@ -188,6 +188,7 @@ dma@3000000 { > > Unrelated but the node name should be dma-controller@... > Thanks for the correction, I guess we could give another patch for changing the node name. > > reg = <0x0 0x3000000 0x0 0x8000>; > > interrupt-parent = <&plic>; > > interrupts = <23 24 25 26 27 28 29 30>; > > + dma-channels = <4>; > > #dma-cells = <1>; > > }; > > > > diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > > index 0655b5c4201d..2bdfe7f06e4b 100644 > > --- a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > > +++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > > @@ -171,6 +171,7 @@ dma: dma@3000000 { > > reg = <0x0 0x3000000 0x0 0x8000>; > > interrupt-parent = <&plic0>; > > interrupts = <23 24 25 26 27 28 29 30>; > > + dma-channels = <4>; > > #dma-cells = <1>; > > }; > > uart1: serial@10011000 { > > -- > > 2.31.1 > > -- > ~Vinod ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 1/3] riscv: dts: Add dma-channels property in dma node @ 2022-01-27 7:35 ` Zong Li 0 siblings, 0 replies; 30+ messages in thread From: Zong Li @ 2022-01-27 7:35 UTC (permalink / raw) To: Vinod Koul Cc: Rob Herring, Paul Walmsley, Palmer Dabbelt, Albert Ou, Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven, Bin Meng, Green Wan, dmaengine, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel@vger.kernel.org List, linux-riscv On Thu, Jan 27, 2022 at 3:03 PM Vinod Koul <vkoul@kernel.org> wrote: > > On 17-01-22, 09:35, Zong Li wrote: > > Add dma-channels property, then we can determine how many channels there > > by device tree. > > > > Signed-off-by: Zong Li <zong.li@sifive.com> > > --- > > arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi | 1 + > > arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 1 + > > 2 files changed, 2 insertions(+) > > > > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > > index c9f6d205d2ba..3c48f2d7a4a4 100644 > > --- a/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > > @@ -188,6 +188,7 @@ dma@3000000 { > > Unrelated but the node name should be dma-controller@... > Thanks for the correction, I guess we could give another patch for changing the node name. > > reg = <0x0 0x3000000 0x0 0x8000>; > > interrupt-parent = <&plic>; > > interrupts = <23 24 25 26 27 28 29 30>; > > + dma-channels = <4>; > > #dma-cells = <1>; > > }; > > > > diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > > index 0655b5c4201d..2bdfe7f06e4b 100644 > > --- a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > > +++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi > > @@ -171,6 +171,7 @@ dma: dma@3000000 { > > reg = <0x0 0x3000000 0x0 0x8000>; > > interrupt-parent = <&plic0>; > > interrupts = <23 24 25 26 27 28 29 30>; > > + dma-channels = <4>; > > #dma-cells = <1>; > > }; > > uart1: serial@10011000 { > > -- > > 2.31.1 > > -- > ~Vinod _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v4 2/3] dt-bindings: Add dma-channels for pdma device node 2022-01-17 1:35 ` Zong Li @ 2022-01-17 1:35 ` Zong Li -1 siblings, 0 replies; 30+ messages in thread From: Zong Li @ 2022-01-17 1:35 UTC (permalink / raw) To: robh+dt, paul.walmsley, palmer, aou, krzysztof.kozlowski, conor.dooley, geert, bin.meng, green.wan, vkoul, dmaengine, devicetree, linux-kernel, linux-riscv Cc: Zong Li Add dma-channels property, then we can determine how many channels there by device tree, rather than statically defines it in PDMA driver Signed-off-by: Zong Li <zong.li@sifive.com> --- .../devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml index d32a71b975fe..3dbb8caefc17 100644 --- a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml +++ b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml @@ -34,6 +34,12 @@ properties: minItems: 1 maxItems: 8 + dma-channels: + description: For backwards-compatible, the default value is 4 + minimum: 1 + maximum: 4 + default: 4 + '#dma-cells': const: 1 @@ -50,6 +56,7 @@ examples: dma@3000000 { compatible = "sifive,fu540-c000-pdma"; reg = <0x3000000 0x8000>; + dma-channels = <4>; interrupts = <23 24 25 26 27 28 29 30>; #dma-cells = <1>; }; -- 2.31.1 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v4 2/3] dt-bindings: Add dma-channels for pdma device node @ 2022-01-17 1:35 ` Zong Li 0 siblings, 0 replies; 30+ messages in thread From: Zong Li @ 2022-01-17 1:35 UTC (permalink / raw) To: robh+dt, paul.walmsley, palmer, aou, krzysztof.kozlowski, conor.dooley, geert, bin.meng, green.wan, vkoul, dmaengine, devicetree, linux-kernel, linux-riscv Cc: Zong Li Add dma-channels property, then we can determine how many channels there by device tree, rather than statically defines it in PDMA driver Signed-off-by: Zong Li <zong.li@sifive.com> --- .../devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml index d32a71b975fe..3dbb8caefc17 100644 --- a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml +++ b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml @@ -34,6 +34,12 @@ properties: minItems: 1 maxItems: 8 + dma-channels: + description: For backwards-compatible, the default value is 4 + minimum: 1 + maximum: 4 + default: 4 + '#dma-cells': const: 1 @@ -50,6 +56,7 @@ examples: dma@3000000 { compatible = "sifive,fu540-c000-pdma"; reg = <0x3000000 0x8000>; + dma-channels = <4>; interrupts = <23 24 25 26 27 28 29 30>; #dma-cells = <1>; }; -- 2.31.1 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH v4 2/3] dt-bindings: Add dma-channels for pdma device node 2022-01-17 1:35 ` Zong Li @ 2022-01-20 18:51 ` Palmer Dabbelt -1 siblings, 0 replies; 30+ messages in thread From: Palmer Dabbelt @ 2022-01-20 18:51 UTC (permalink / raw) To: zong.li Cc: robh+dt, Paul Walmsley, aou, krzysztof.kozlowski, conor.dooley, geert, bin.meng, green.wan, vkoul, dmaengine, devicetree, linux-kernel, linux-riscv, zong.li On Sun, 16 Jan 2022 17:35:27 PST (-0800), zong.li@sifive.com wrote: > Add dma-channels property, then we can determine how many channels there > by device tree, rather than statically defines it in PDMA driver Maybe "statically defining it" is better here? > > Signed-off-by: Zong Li <zong.li@sifive.com> > --- > .../devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml > index d32a71b975fe..3dbb8caefc17 100644 > --- a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml > +++ b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml > @@ -34,6 +34,12 @@ properties: > minItems: 1 > maxItems: 8 > > + dma-channels: > + description: For backwards-compatible, the default value is 4 Maybe "backwards-compatibility" is better here? > + minimum: 1 > + maximum: 4 > + default: 4 > + > '#dma-cells': > const: 1 > > @@ -50,6 +56,7 @@ examples: > dma@3000000 { > compatible = "sifive,fu540-c000-pdma"; IMO we should have a "sifive,pdma-1.0.0" (or whatever the versioning scheme ended up being) here, in addition to the SOC-specific DT entry. It's kind of odd to start extending the SOC-specific DT entry, as the whole idea there is to let us have an out in case we find future compatibility issues. > reg = <0x3000000 0x8000>; > + dma-channels = <4>; > interrupts = <23 24 25 26 27 28 29 30>; > #dma-cells = <1>; > }; ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 2/3] dt-bindings: Add dma-channels for pdma device node @ 2022-01-20 18:51 ` Palmer Dabbelt 0 siblings, 0 replies; 30+ messages in thread From: Palmer Dabbelt @ 2022-01-20 18:51 UTC (permalink / raw) To: zong.li Cc: robh+dt, Paul Walmsley, aou, krzysztof.kozlowski, conor.dooley, geert, bin.meng, green.wan, vkoul, dmaengine, devicetree, linux-kernel, linux-riscv, zong.li On Sun, 16 Jan 2022 17:35:27 PST (-0800), zong.li@sifive.com wrote: > Add dma-channels property, then we can determine how many channels there > by device tree, rather than statically defines it in PDMA driver Maybe "statically defining it" is better here? > > Signed-off-by: Zong Li <zong.li@sifive.com> > --- > .../devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml > index d32a71b975fe..3dbb8caefc17 100644 > --- a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml > +++ b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml > @@ -34,6 +34,12 @@ properties: > minItems: 1 > maxItems: 8 > > + dma-channels: > + description: For backwards-compatible, the default value is 4 Maybe "backwards-compatibility" is better here? > + minimum: 1 > + maximum: 4 > + default: 4 > + > '#dma-cells': > const: 1 > > @@ -50,6 +56,7 @@ examples: > dma@3000000 { > compatible = "sifive,fu540-c000-pdma"; IMO we should have a "sifive,pdma-1.0.0" (or whatever the versioning scheme ended up being) here, in addition to the SOC-specific DT entry. It's kind of odd to start extending the SOC-specific DT entry, as the whole idea there is to let us have an out in case we find future compatibility issues. > reg = <0x3000000 0x8000>; > + dma-channels = <4>; > interrupts = <23 24 25 26 27 28 29 30>; > #dma-cells = <1>; > }; _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 2/3] dt-bindings: Add dma-channels for pdma device node 2022-01-20 18:51 ` Palmer Dabbelt @ 2022-01-21 1:57 ` Zong Li -1 siblings, 0 replies; 30+ messages in thread From: Zong Li @ 2022-01-21 1:57 UTC (permalink / raw) To: Palmer Dabbelt Cc: Rob Herring, Paul Walmsley, Albert Ou, Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven, Bin Meng, Green Wan, Vinod, dmaengine, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel@vger.kernel.org List, linux-riscv On Fri, Jan 21, 2022 at 2:51 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > On Sun, 16 Jan 2022 17:35:27 PST (-0800), zong.li@sifive.com wrote: > > Add dma-channels property, then we can determine how many channels there > > by device tree, rather than statically defines it in PDMA driver > > Maybe "statically defining it" is better here? > Thanks for the correction, I would modify it in the next version. > > > > Signed-off-by: Zong Li <zong.li@sifive.com> > > --- > > .../devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml > > index d32a71b975fe..3dbb8caefc17 100644 > > --- a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml > > +++ b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml > > @@ -34,6 +34,12 @@ properties: > > minItems: 1 > > maxItems: 8 > > > > + dma-channels: > > + description: For backwards-compatible, the default value is 4 > > Maybe "backwards-compatibility" is better here? Thanks, let me change it in the next version together. > > > + minimum: 1 > > + maximum: 4 > > + default: 4 > > + > > '#dma-cells': > > const: 1 > > > > @@ -50,6 +56,7 @@ examples: > > dma@3000000 { > > compatible = "sifive,fu540-c000-pdma"; > > IMO we should have a "sifive,pdma-1.0.0" (or whatever the versioning > scheme ended up being) here, in addition to the SOC-specific DT entry. > It's kind of odd to start extending the SOC-specific DT entry, as the > whole idea there is to let us have an out in case we find future > compatibility issues. yes, I notice that we usually have a entry with the version in other device nodes, such as "sifive,xxx0", I guess we should have a "sifive,pdma0" there, thanks for your advice, let me add it and use it in match table of pdma driver in the next version. > > > reg = <0x3000000 0x8000>; > > + dma-channels = <4>; > > interrupts = <23 24 25 26 27 28 29 30>; > > #dma-cells = <1>; > > }; ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 2/3] dt-bindings: Add dma-channels for pdma device node @ 2022-01-21 1:57 ` Zong Li 0 siblings, 0 replies; 30+ messages in thread From: Zong Li @ 2022-01-21 1:57 UTC (permalink / raw) To: Palmer Dabbelt Cc: Rob Herring, Paul Walmsley, Albert Ou, Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven, Bin Meng, Green Wan, Vinod, dmaengine, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel@vger.kernel.org List, linux-riscv On Fri, Jan 21, 2022 at 2:51 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > On Sun, 16 Jan 2022 17:35:27 PST (-0800), zong.li@sifive.com wrote: > > Add dma-channels property, then we can determine how many channels there > > by device tree, rather than statically defines it in PDMA driver > > Maybe "statically defining it" is better here? > Thanks for the correction, I would modify it in the next version. > > > > Signed-off-by: Zong Li <zong.li@sifive.com> > > --- > > .../devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml > > index d32a71b975fe..3dbb8caefc17 100644 > > --- a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml > > +++ b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml > > @@ -34,6 +34,12 @@ properties: > > minItems: 1 > > maxItems: 8 > > > > + dma-channels: > > + description: For backwards-compatible, the default value is 4 > > Maybe "backwards-compatibility" is better here? Thanks, let me change it in the next version together. > > > + minimum: 1 > > + maximum: 4 > > + default: 4 > > + > > '#dma-cells': > > const: 1 > > > > @@ -50,6 +56,7 @@ examples: > > dma@3000000 { > > compatible = "sifive,fu540-c000-pdma"; > > IMO we should have a "sifive,pdma-1.0.0" (or whatever the versioning > scheme ended up being) here, in addition to the SOC-specific DT entry. > It's kind of odd to start extending the SOC-specific DT entry, as the > whole idea there is to let us have an out in case we find future > compatibility issues. yes, I notice that we usually have a entry with the version in other device nodes, such as "sifive,xxx0", I guess we should have a "sifive,pdma0" there, thanks for your advice, let me add it and use it in match table of pdma driver in the next version. > > > reg = <0x3000000 0x8000>; > > + dma-channels = <4>; > > interrupts = <23 24 25 26 27 28 29 30>; > > #dma-cells = <1>; > > }; _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v4 3/3] dmaengine: sf-pdma: Get number of channel by device tree 2022-01-17 1:35 ` Zong Li @ 2022-01-17 1:35 ` Zong Li -1 siblings, 0 replies; 30+ messages in thread From: Zong Li @ 2022-01-17 1:35 UTC (permalink / raw) To: robh+dt, paul.walmsley, palmer, aou, krzysztof.kozlowski, conor.dooley, geert, bin.meng, green.wan, vkoul, dmaengine, devicetree, linux-kernel, linux-riscv Cc: Zong Li It currently assumes that there are always four channels, it would cause the error if there is actually less than four channels. Change that by getting number of channel from device tree. For backwards-compatible, it uses the default value (i.e. 4) when there is no 'dma-channels' information in dts. Signed-off-by: Zong Li <zong.li@sifive.com> --- drivers/dma/sf-pdma/sf-pdma.c | 20 +++++++++++++------- drivers/dma/sf-pdma/sf-pdma.h | 8 ++------ 2 files changed, 15 insertions(+), 13 deletions(-) diff --git a/drivers/dma/sf-pdma/sf-pdma.c b/drivers/dma/sf-pdma/sf-pdma.c index f12606aeff87..1264add9897e 100644 --- a/drivers/dma/sf-pdma/sf-pdma.c +++ b/drivers/dma/sf-pdma/sf-pdma.c @@ -482,9 +482,7 @@ static void sf_pdma_setup_chans(struct sf_pdma *pdma) static int sf_pdma_probe(struct platform_device *pdev) { struct sf_pdma *pdma; - struct sf_pdma_chan *chan; struct resource *res; - int len, chans; int ret; const enum dma_slave_buswidth widths = DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES | @@ -492,13 +490,21 @@ static int sf_pdma_probe(struct platform_device *pdev) DMA_SLAVE_BUSWIDTH_16_BYTES | DMA_SLAVE_BUSWIDTH_32_BYTES | DMA_SLAVE_BUSWIDTH_64_BYTES; - chans = PDMA_NR_CH; - len = sizeof(*pdma) + sizeof(*chan) * chans; - pdma = devm_kzalloc(&pdev->dev, len, GFP_KERNEL); + pdma = devm_kzalloc(&pdev->dev, sizeof(*pdma), GFP_KERNEL); if (!pdma) return -ENOMEM; - pdma->n_chans = chans; + ret = of_property_read_u32(pdev->dev.of_node, "dma-channels", + &pdma->n_chans); + if (ret) { + dev_notice(&pdev->dev, "set number of channels to default value: 4\n"); + pdma->n_chans = PDMA_MAX_NR_CH; + } + + if (pdma->n_chans > PDMA_MAX_NR_CH) { + dev_err(&pdev->dev, "the number of channels exceeds the maximum\n"); + return -EINVAL; + } res = platform_get_resource(pdev, IORESOURCE_MEM, 0); pdma->membase = devm_ioremap_resource(&pdev->dev, res); @@ -556,7 +562,7 @@ static int sf_pdma_remove(struct platform_device *pdev) struct sf_pdma_chan *ch; int i; - for (i = 0; i < PDMA_NR_CH; i++) { + for (i = 0; i < pdma->n_chans; i++) { ch = &pdma->chans[i]; devm_free_irq(&pdev->dev, ch->txirq, ch); diff --git a/drivers/dma/sf-pdma/sf-pdma.h b/drivers/dma/sf-pdma/sf-pdma.h index 0c20167b097d..8127d792f639 100644 --- a/drivers/dma/sf-pdma/sf-pdma.h +++ b/drivers/dma/sf-pdma/sf-pdma.h @@ -22,11 +22,7 @@ #include "../dmaengine.h" #include "../virt-dma.h" -#define PDMA_NR_CH 4 - -#if (PDMA_NR_CH != 4) -#error "Please define PDMA_NR_CH to 4" -#endif +#define PDMA_MAX_NR_CH 4 #define PDMA_BASE_ADDR 0x3000000 #define PDMA_CHAN_OFFSET 0x1000 @@ -118,7 +114,7 @@ struct sf_pdma { void __iomem *membase; void __iomem *mappedbase; u32 n_chans; - struct sf_pdma_chan chans[PDMA_NR_CH]; + struct sf_pdma_chan chans[PDMA_MAX_NR_CH]; }; #endif /* _SF_PDMA_H */ -- 2.31.1 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v4 3/3] dmaengine: sf-pdma: Get number of channel by device tree @ 2022-01-17 1:35 ` Zong Li 0 siblings, 0 replies; 30+ messages in thread From: Zong Li @ 2022-01-17 1:35 UTC (permalink / raw) To: robh+dt, paul.walmsley, palmer, aou, krzysztof.kozlowski, conor.dooley, geert, bin.meng, green.wan, vkoul, dmaengine, devicetree, linux-kernel, linux-riscv Cc: Zong Li It currently assumes that there are always four channels, it would cause the error if there is actually less than four channels. Change that by getting number of channel from device tree. For backwards-compatible, it uses the default value (i.e. 4) when there is no 'dma-channels' information in dts. Signed-off-by: Zong Li <zong.li@sifive.com> --- drivers/dma/sf-pdma/sf-pdma.c | 20 +++++++++++++------- drivers/dma/sf-pdma/sf-pdma.h | 8 ++------ 2 files changed, 15 insertions(+), 13 deletions(-) diff --git a/drivers/dma/sf-pdma/sf-pdma.c b/drivers/dma/sf-pdma/sf-pdma.c index f12606aeff87..1264add9897e 100644 --- a/drivers/dma/sf-pdma/sf-pdma.c +++ b/drivers/dma/sf-pdma/sf-pdma.c @@ -482,9 +482,7 @@ static void sf_pdma_setup_chans(struct sf_pdma *pdma) static int sf_pdma_probe(struct platform_device *pdev) { struct sf_pdma *pdma; - struct sf_pdma_chan *chan; struct resource *res; - int len, chans; int ret; const enum dma_slave_buswidth widths = DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES | @@ -492,13 +490,21 @@ static int sf_pdma_probe(struct platform_device *pdev) DMA_SLAVE_BUSWIDTH_16_BYTES | DMA_SLAVE_BUSWIDTH_32_BYTES | DMA_SLAVE_BUSWIDTH_64_BYTES; - chans = PDMA_NR_CH; - len = sizeof(*pdma) + sizeof(*chan) * chans; - pdma = devm_kzalloc(&pdev->dev, len, GFP_KERNEL); + pdma = devm_kzalloc(&pdev->dev, sizeof(*pdma), GFP_KERNEL); if (!pdma) return -ENOMEM; - pdma->n_chans = chans; + ret = of_property_read_u32(pdev->dev.of_node, "dma-channels", + &pdma->n_chans); + if (ret) { + dev_notice(&pdev->dev, "set number of channels to default value: 4\n"); + pdma->n_chans = PDMA_MAX_NR_CH; + } + + if (pdma->n_chans > PDMA_MAX_NR_CH) { + dev_err(&pdev->dev, "the number of channels exceeds the maximum\n"); + return -EINVAL; + } res = platform_get_resource(pdev, IORESOURCE_MEM, 0); pdma->membase = devm_ioremap_resource(&pdev->dev, res); @@ -556,7 +562,7 @@ static int sf_pdma_remove(struct platform_device *pdev) struct sf_pdma_chan *ch; int i; - for (i = 0; i < PDMA_NR_CH; i++) { + for (i = 0; i < pdma->n_chans; i++) { ch = &pdma->chans[i]; devm_free_irq(&pdev->dev, ch->txirq, ch); diff --git a/drivers/dma/sf-pdma/sf-pdma.h b/drivers/dma/sf-pdma/sf-pdma.h index 0c20167b097d..8127d792f639 100644 --- a/drivers/dma/sf-pdma/sf-pdma.h +++ b/drivers/dma/sf-pdma/sf-pdma.h @@ -22,11 +22,7 @@ #include "../dmaengine.h" #include "../virt-dma.h" -#define PDMA_NR_CH 4 - -#if (PDMA_NR_CH != 4) -#error "Please define PDMA_NR_CH to 4" -#endif +#define PDMA_MAX_NR_CH 4 #define PDMA_BASE_ADDR 0x3000000 #define PDMA_CHAN_OFFSET 0x1000 @@ -118,7 +114,7 @@ struct sf_pdma { void __iomem *membase; void __iomem *mappedbase; u32 n_chans; - struct sf_pdma_chan chans[PDMA_NR_CH]; + struct sf_pdma_chan chans[PDMA_MAX_NR_CH]; }; #endif /* _SF_PDMA_H */ -- 2.31.1 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH v4 3/3] dmaengine: sf-pdma: Get number of channel by device tree 2022-01-17 1:35 ` Zong Li @ 2022-01-20 18:51 ` Palmer Dabbelt -1 siblings, 0 replies; 30+ messages in thread From: Palmer Dabbelt @ 2022-01-20 18:51 UTC (permalink / raw) To: zong.li Cc: robh+dt, Paul Walmsley, aou, krzysztof.kozlowski, conor.dooley, geert, bin.meng, green.wan, vkoul, dmaengine, devicetree, linux-kernel, linux-riscv, zong.li On Sun, 16 Jan 2022 17:35:28 PST (-0800), zong.li@sifive.com wrote: > It currently assumes that there are always four channels, it would > cause the error if there is actually less than four channels. Change > that by getting number of channel from device tree. > > For backwards-compatible, it uses the default value (i.e. 4) when there > is no 'dma-channels' information in dts. Some of the same wording issues here as those I pointed out in the DT bindings patch. > Signed-off-by: Zong Li <zong.li@sifive.com> > --- > drivers/dma/sf-pdma/sf-pdma.c | 20 +++++++++++++------- > drivers/dma/sf-pdma/sf-pdma.h | 8 ++------ > 2 files changed, 15 insertions(+), 13 deletions(-) > > diff --git a/drivers/dma/sf-pdma/sf-pdma.c b/drivers/dma/sf-pdma/sf-pdma.c > index f12606aeff87..1264add9897e 100644 > --- a/drivers/dma/sf-pdma/sf-pdma.c > +++ b/drivers/dma/sf-pdma/sf-pdma.c > @@ -482,9 +482,7 @@ static void sf_pdma_setup_chans(struct sf_pdma *pdma) > static int sf_pdma_probe(struct platform_device *pdev) > { > struct sf_pdma *pdma; > - struct sf_pdma_chan *chan; > struct resource *res; > - int len, chans; > int ret; > const enum dma_slave_buswidth widths = > DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES | > @@ -492,13 +490,21 @@ static int sf_pdma_probe(struct platform_device *pdev) > DMA_SLAVE_BUSWIDTH_16_BYTES | DMA_SLAVE_BUSWIDTH_32_BYTES | > DMA_SLAVE_BUSWIDTH_64_BYTES; > > - chans = PDMA_NR_CH; > - len = sizeof(*pdma) + sizeof(*chan) * chans; > - pdma = devm_kzalloc(&pdev->dev, len, GFP_KERNEL); > + pdma = devm_kzalloc(&pdev->dev, sizeof(*pdma), GFP_KERNEL); > if (!pdma) > return -ENOMEM; > > - pdma->n_chans = chans; > + ret = of_property_read_u32(pdev->dev.of_node, "dma-channels", > + &pdma->n_chans); > + if (ret) { > + dev_notice(&pdev->dev, "set number of channels to default value: 4\n"); > + pdma->n_chans = PDMA_MAX_NR_CH; > + } > + > + if (pdma->n_chans > PDMA_MAX_NR_CH) { > + dev_err(&pdev->dev, "the number of channels exceeds the maximum\n"); > + return -EINVAL; Can we get away with just using only the number of channels the driver actually supports? ie, just never sending an op to the channels above MAX_NR_CH? That should leave us with nothing to track. > + } > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > pdma->membase = devm_ioremap_resource(&pdev->dev, res); > @@ -556,7 +562,7 @@ static int sf_pdma_remove(struct platform_device *pdev) > struct sf_pdma_chan *ch; > int i; > > - for (i = 0; i < PDMA_NR_CH; i++) { > + for (i = 0; i < pdma->n_chans; i++) { > ch = &pdma->chans[i]; > > devm_free_irq(&pdev->dev, ch->txirq, ch); > diff --git a/drivers/dma/sf-pdma/sf-pdma.h b/drivers/dma/sf-pdma/sf-pdma.h > index 0c20167b097d..8127d792f639 100644 > --- a/drivers/dma/sf-pdma/sf-pdma.h > +++ b/drivers/dma/sf-pdma/sf-pdma.h > @@ -22,11 +22,7 @@ > #include "../dmaengine.h" > #include "../virt-dma.h" > > -#define PDMA_NR_CH 4 > - > -#if (PDMA_NR_CH != 4) > -#error "Please define PDMA_NR_CH to 4" > -#endif > +#define PDMA_MAX_NR_CH 4 > > #define PDMA_BASE_ADDR 0x3000000 > #define PDMA_CHAN_OFFSET 0x1000 > @@ -118,7 +114,7 @@ struct sf_pdma { > void __iomem *membase; > void __iomem *mappedbase; > u32 n_chans; > - struct sf_pdma_chan chans[PDMA_NR_CH]; > + struct sf_pdma_chan chans[PDMA_MAX_NR_CH]; > }; > > #endif /* _SF_PDMA_H */ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 3/3] dmaengine: sf-pdma: Get number of channel by device tree @ 2022-01-20 18:51 ` Palmer Dabbelt 0 siblings, 0 replies; 30+ messages in thread From: Palmer Dabbelt @ 2022-01-20 18:51 UTC (permalink / raw) To: zong.li Cc: robh+dt, Paul Walmsley, aou, krzysztof.kozlowski, conor.dooley, geert, bin.meng, green.wan, vkoul, dmaengine, devicetree, linux-kernel, linux-riscv, zong.li On Sun, 16 Jan 2022 17:35:28 PST (-0800), zong.li@sifive.com wrote: > It currently assumes that there are always four channels, it would > cause the error if there is actually less than four channels. Change > that by getting number of channel from device tree. > > For backwards-compatible, it uses the default value (i.e. 4) when there > is no 'dma-channels' information in dts. Some of the same wording issues here as those I pointed out in the DT bindings patch. > Signed-off-by: Zong Li <zong.li@sifive.com> > --- > drivers/dma/sf-pdma/sf-pdma.c | 20 +++++++++++++------- > drivers/dma/sf-pdma/sf-pdma.h | 8 ++------ > 2 files changed, 15 insertions(+), 13 deletions(-) > > diff --git a/drivers/dma/sf-pdma/sf-pdma.c b/drivers/dma/sf-pdma/sf-pdma.c > index f12606aeff87..1264add9897e 100644 > --- a/drivers/dma/sf-pdma/sf-pdma.c > +++ b/drivers/dma/sf-pdma/sf-pdma.c > @@ -482,9 +482,7 @@ static void sf_pdma_setup_chans(struct sf_pdma *pdma) > static int sf_pdma_probe(struct platform_device *pdev) > { > struct sf_pdma *pdma; > - struct sf_pdma_chan *chan; > struct resource *res; > - int len, chans; > int ret; > const enum dma_slave_buswidth widths = > DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES | > @@ -492,13 +490,21 @@ static int sf_pdma_probe(struct platform_device *pdev) > DMA_SLAVE_BUSWIDTH_16_BYTES | DMA_SLAVE_BUSWIDTH_32_BYTES | > DMA_SLAVE_BUSWIDTH_64_BYTES; > > - chans = PDMA_NR_CH; > - len = sizeof(*pdma) + sizeof(*chan) * chans; > - pdma = devm_kzalloc(&pdev->dev, len, GFP_KERNEL); > + pdma = devm_kzalloc(&pdev->dev, sizeof(*pdma), GFP_KERNEL); > if (!pdma) > return -ENOMEM; > > - pdma->n_chans = chans; > + ret = of_property_read_u32(pdev->dev.of_node, "dma-channels", > + &pdma->n_chans); > + if (ret) { > + dev_notice(&pdev->dev, "set number of channels to default value: 4\n"); > + pdma->n_chans = PDMA_MAX_NR_CH; > + } > + > + if (pdma->n_chans > PDMA_MAX_NR_CH) { > + dev_err(&pdev->dev, "the number of channels exceeds the maximum\n"); > + return -EINVAL; Can we get away with just using only the number of channels the driver actually supports? ie, just never sending an op to the channels above MAX_NR_CH? That should leave us with nothing to track. > + } > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > pdma->membase = devm_ioremap_resource(&pdev->dev, res); > @@ -556,7 +562,7 @@ static int sf_pdma_remove(struct platform_device *pdev) > struct sf_pdma_chan *ch; > int i; > > - for (i = 0; i < PDMA_NR_CH; i++) { > + for (i = 0; i < pdma->n_chans; i++) { > ch = &pdma->chans[i]; > > devm_free_irq(&pdev->dev, ch->txirq, ch); > diff --git a/drivers/dma/sf-pdma/sf-pdma.h b/drivers/dma/sf-pdma/sf-pdma.h > index 0c20167b097d..8127d792f639 100644 > --- a/drivers/dma/sf-pdma/sf-pdma.h > +++ b/drivers/dma/sf-pdma/sf-pdma.h > @@ -22,11 +22,7 @@ > #include "../dmaengine.h" > #include "../virt-dma.h" > > -#define PDMA_NR_CH 4 > - > -#if (PDMA_NR_CH != 4) > -#error "Please define PDMA_NR_CH to 4" > -#endif > +#define PDMA_MAX_NR_CH 4 > > #define PDMA_BASE_ADDR 0x3000000 > #define PDMA_CHAN_OFFSET 0x1000 > @@ -118,7 +114,7 @@ struct sf_pdma { > void __iomem *membase; > void __iomem *mappedbase; > u32 n_chans; > - struct sf_pdma_chan chans[PDMA_NR_CH]; > + struct sf_pdma_chan chans[PDMA_MAX_NR_CH]; > }; > > #endif /* _SF_PDMA_H */ _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 3/3] dmaengine: sf-pdma: Get number of channel by device tree 2022-01-20 18:51 ` Palmer Dabbelt @ 2022-01-21 2:21 ` Zong Li -1 siblings, 0 replies; 30+ messages in thread From: Zong Li @ 2022-01-21 2:21 UTC (permalink / raw) To: Palmer Dabbelt Cc: Rob Herring, Paul Walmsley, Albert Ou, Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven, Bin Meng, Green Wan, Vinod, dmaengine, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel@vger.kernel.org List, linux-riscv On Fri, Jan 21, 2022 at 2:52 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > On Sun, 16 Jan 2022 17:35:28 PST (-0800), zong.li@sifive.com wrote: > > It currently assumes that there are always four channels, it would > > cause the error if there is actually less than four channels. Change > > that by getting number of channel from device tree. > > > > For backwards-compatible, it uses the default value (i.e. 4) when there > > is no 'dma-channels' information in dts. > > Some of the same wording issues here as those I pointed out in the DT > bindings patch. > > > Signed-off-by: Zong Li <zong.li@sifive.com> > > --- > > drivers/dma/sf-pdma/sf-pdma.c | 20 +++++++++++++------- > > drivers/dma/sf-pdma/sf-pdma.h | 8 ++------ > > 2 files changed, 15 insertions(+), 13 deletions(-) > > > > diff --git a/drivers/dma/sf-pdma/sf-pdma.c b/drivers/dma/sf-pdma/sf-pdma.c > > index f12606aeff87..1264add9897e 100644 > > --- a/drivers/dma/sf-pdma/sf-pdma.c > > +++ b/drivers/dma/sf-pdma/sf-pdma.c > > @@ -482,9 +482,7 @@ static void sf_pdma_setup_chans(struct sf_pdma *pdma) > > static int sf_pdma_probe(struct platform_device *pdev) > > { > > struct sf_pdma *pdma; > > - struct sf_pdma_chan *chan; > > struct resource *res; > > - int len, chans; > > int ret; > > const enum dma_slave_buswidth widths = > > DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES | > > @@ -492,13 +490,21 @@ static int sf_pdma_probe(struct platform_device *pdev) > > DMA_SLAVE_BUSWIDTH_16_BYTES | DMA_SLAVE_BUSWIDTH_32_BYTES | > > DMA_SLAVE_BUSWIDTH_64_BYTES; > > > > - chans = PDMA_NR_CH; > > - len = sizeof(*pdma) + sizeof(*chan) * chans; > > - pdma = devm_kzalloc(&pdev->dev, len, GFP_KERNEL); > > + pdma = devm_kzalloc(&pdev->dev, sizeof(*pdma), GFP_KERNEL); > > if (!pdma) > > return -ENOMEM; > > > > - pdma->n_chans = chans; > > + ret = of_property_read_u32(pdev->dev.of_node, "dma-channels", > > + &pdma->n_chans); > > + if (ret) { > > + dev_notice(&pdev->dev, "set number of channels to default value: 4\n"); > > + pdma->n_chans = PDMA_MAX_NR_CH; > > + } > > + > > + if (pdma->n_chans > PDMA_MAX_NR_CH) { > > + dev_err(&pdev->dev, "the number of channels exceeds the maximum\n"); > > + return -EINVAL; > > Can we get away with just using only the number of channels the driver > actually supports? ie, just never sending an op to the channels above > MAX_NR_CH? That should leave us with nothing to track. It might be a bit like when pdma->n_chans is bigger than the maximum, set the pdma->chans to PDMA_MAX_NR_CH, then we could ensure that we don't access the channels above the maximum. If I understand correctly, I gave the similar thought in the thread of v2 patch, and there are some discussions on that, but this way seems to lead to hard-to-track problems. > > > + } > > > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > pdma->membase = devm_ioremap_resource(&pdev->dev, res); > > @@ -556,7 +562,7 @@ static int sf_pdma_remove(struct platform_device *pdev) > > struct sf_pdma_chan *ch; > > int i; > > > > - for (i = 0; i < PDMA_NR_CH; i++) { > > + for (i = 0; i < pdma->n_chans; i++) { > > ch = &pdma->chans[i]; > > > > devm_free_irq(&pdev->dev, ch->txirq, ch); > > diff --git a/drivers/dma/sf-pdma/sf-pdma.h b/drivers/dma/sf-pdma/sf-pdma.h > > index 0c20167b097d..8127d792f639 100644 > > --- a/drivers/dma/sf-pdma/sf-pdma.h > > +++ b/drivers/dma/sf-pdma/sf-pdma.h > > @@ -22,11 +22,7 @@ > > #include "../dmaengine.h" > > #include "../virt-dma.h" > > > > -#define PDMA_NR_CH 4 > > - > > -#if (PDMA_NR_CH != 4) > > -#error "Please define PDMA_NR_CH to 4" > > -#endif > > +#define PDMA_MAX_NR_CH 4 > > > > #define PDMA_BASE_ADDR 0x3000000 > > #define PDMA_CHAN_OFFSET 0x1000 > > @@ -118,7 +114,7 @@ struct sf_pdma { > > void __iomem *membase; > > void __iomem *mappedbase; > > u32 n_chans; > > - struct sf_pdma_chan chans[PDMA_NR_CH]; > > + struct sf_pdma_chan chans[PDMA_MAX_NR_CH]; > > }; > > > > #endif /* _SF_PDMA_H */ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 3/3] dmaengine: sf-pdma: Get number of channel by device tree @ 2022-01-21 2:21 ` Zong Li 0 siblings, 0 replies; 30+ messages in thread From: Zong Li @ 2022-01-21 2:21 UTC (permalink / raw) To: Palmer Dabbelt Cc: Rob Herring, Paul Walmsley, Albert Ou, Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven, Bin Meng, Green Wan, Vinod, dmaengine, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel@vger.kernel.org List, linux-riscv On Fri, Jan 21, 2022 at 2:52 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > On Sun, 16 Jan 2022 17:35:28 PST (-0800), zong.li@sifive.com wrote: > > It currently assumes that there are always four channels, it would > > cause the error if there is actually less than four channels. Change > > that by getting number of channel from device tree. > > > > For backwards-compatible, it uses the default value (i.e. 4) when there > > is no 'dma-channels' information in dts. > > Some of the same wording issues here as those I pointed out in the DT > bindings patch. > > > Signed-off-by: Zong Li <zong.li@sifive.com> > > --- > > drivers/dma/sf-pdma/sf-pdma.c | 20 +++++++++++++------- > > drivers/dma/sf-pdma/sf-pdma.h | 8 ++------ > > 2 files changed, 15 insertions(+), 13 deletions(-) > > > > diff --git a/drivers/dma/sf-pdma/sf-pdma.c b/drivers/dma/sf-pdma/sf-pdma.c > > index f12606aeff87..1264add9897e 100644 > > --- a/drivers/dma/sf-pdma/sf-pdma.c > > +++ b/drivers/dma/sf-pdma/sf-pdma.c > > @@ -482,9 +482,7 @@ static void sf_pdma_setup_chans(struct sf_pdma *pdma) > > static int sf_pdma_probe(struct platform_device *pdev) > > { > > struct sf_pdma *pdma; > > - struct sf_pdma_chan *chan; > > struct resource *res; > > - int len, chans; > > int ret; > > const enum dma_slave_buswidth widths = > > DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES | > > @@ -492,13 +490,21 @@ static int sf_pdma_probe(struct platform_device *pdev) > > DMA_SLAVE_BUSWIDTH_16_BYTES | DMA_SLAVE_BUSWIDTH_32_BYTES | > > DMA_SLAVE_BUSWIDTH_64_BYTES; > > > > - chans = PDMA_NR_CH; > > - len = sizeof(*pdma) + sizeof(*chan) * chans; > > - pdma = devm_kzalloc(&pdev->dev, len, GFP_KERNEL); > > + pdma = devm_kzalloc(&pdev->dev, sizeof(*pdma), GFP_KERNEL); > > if (!pdma) > > return -ENOMEM; > > > > - pdma->n_chans = chans; > > + ret = of_property_read_u32(pdev->dev.of_node, "dma-channels", > > + &pdma->n_chans); > > + if (ret) { > > + dev_notice(&pdev->dev, "set number of channels to default value: 4\n"); > > + pdma->n_chans = PDMA_MAX_NR_CH; > > + } > > + > > + if (pdma->n_chans > PDMA_MAX_NR_CH) { > > + dev_err(&pdev->dev, "the number of channels exceeds the maximum\n"); > > + return -EINVAL; > > Can we get away with just using only the number of channels the driver > actually supports? ie, just never sending an op to the channels above > MAX_NR_CH? That should leave us with nothing to track. It might be a bit like when pdma->n_chans is bigger than the maximum, set the pdma->chans to PDMA_MAX_NR_CH, then we could ensure that we don't access the channels above the maximum. If I understand correctly, I gave the similar thought in the thread of v2 patch, and there are some discussions on that, but this way seems to lead to hard-to-track problems. > > > + } > > > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > pdma->membase = devm_ioremap_resource(&pdev->dev, res); > > @@ -556,7 +562,7 @@ static int sf_pdma_remove(struct platform_device *pdev) > > struct sf_pdma_chan *ch; > > int i; > > > > - for (i = 0; i < PDMA_NR_CH; i++) { > > + for (i = 0; i < pdma->n_chans; i++) { > > ch = &pdma->chans[i]; > > > > devm_free_irq(&pdev->dev, ch->txirq, ch); > > diff --git a/drivers/dma/sf-pdma/sf-pdma.h b/drivers/dma/sf-pdma/sf-pdma.h > > index 0c20167b097d..8127d792f639 100644 > > --- a/drivers/dma/sf-pdma/sf-pdma.h > > +++ b/drivers/dma/sf-pdma/sf-pdma.h > > @@ -22,11 +22,7 @@ > > #include "../dmaengine.h" > > #include "../virt-dma.h" > > > > -#define PDMA_NR_CH 4 > > - > > -#if (PDMA_NR_CH != 4) > > -#error "Please define PDMA_NR_CH to 4" > > -#endif > > +#define PDMA_MAX_NR_CH 4 > > > > #define PDMA_BASE_ADDR 0x3000000 > > #define PDMA_CHAN_OFFSET 0x1000 > > @@ -118,7 +114,7 @@ struct sf_pdma { > > void __iomem *membase; > > void __iomem *mappedbase; > > u32 n_chans; > > - struct sf_pdma_chan chans[PDMA_NR_CH]; > > + struct sf_pdma_chan chans[PDMA_MAX_NR_CH]; > > }; > > > > #endif /* _SF_PDMA_H */ _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 3/3] dmaengine: sf-pdma: Get number of channel by device tree 2022-01-21 2:21 ` Zong Li @ 2022-01-21 8:33 ` Geert Uytterhoeven -1 siblings, 0 replies; 30+ messages in thread From: Geert Uytterhoeven @ 2022-01-21 8:33 UTC (permalink / raw) To: Zong Li Cc: Palmer Dabbelt, Rob Herring, Paul Walmsley, Albert Ou, Krzysztof Kozlowski, Conor Dooley, Bin Meng, Green Wan, Vinod, dmaengine, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel@vger.kernel.org List, linux-riscv Hi Zong, Palmer, On Fri, Jan 21, 2022 at 3:21 AM Zong Li <zong.li@sifive.com> wrote: > On Fri, Jan 21, 2022 at 2:52 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > On Sun, 16 Jan 2022 17:35:28 PST (-0800), zong.li@sifive.com wrote: > > > It currently assumes that there are always four channels, it would > > > cause the error if there is actually less than four channels. Change > > > that by getting number of channel from device tree. > > > > > > For backwards-compatible, it uses the default value (i.e. 4) when there > > > is no 'dma-channels' information in dts. > > > > Some of the same wording issues here as those I pointed out in the DT > > bindings patch. > > > > > Signed-off-by: Zong Li <zong.li@sifive.com> > > > --- a/drivers/dma/sf-pdma/sf-pdma.c > > > +++ b/drivers/dma/sf-pdma/sf-pdma.c > > > @@ -482,9 +482,7 @@ static void sf_pdma_setup_chans(struct sf_pdma *pdma) > > > static int sf_pdma_probe(struct platform_device *pdev) > > > { > > > struct sf_pdma *pdma; > > > - struct sf_pdma_chan *chan; > > > struct resource *res; > > > - int len, chans; > > > int ret; > > > const enum dma_slave_buswidth widths = > > > DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES | > > > @@ -492,13 +490,21 @@ static int sf_pdma_probe(struct platform_device *pdev) > > > DMA_SLAVE_BUSWIDTH_16_BYTES | DMA_SLAVE_BUSWIDTH_32_BYTES | > > > DMA_SLAVE_BUSWIDTH_64_BYTES; > > > > > > - chans = PDMA_NR_CH; > > > - len = sizeof(*pdma) + sizeof(*chan) * chans; > > > - pdma = devm_kzalloc(&pdev->dev, len, GFP_KERNEL); > > > + pdma = devm_kzalloc(&pdev->dev, sizeof(*pdma), GFP_KERNEL); > > > if (!pdma) > > > return -ENOMEM; > > > > > > - pdma->n_chans = chans; > > > + ret = of_property_read_u32(pdev->dev.of_node, "dma-channels", > > > + &pdma->n_chans); > > > + if (ret) { > > > + dev_notice(&pdev->dev, "set number of channels to default value: 4\n"); > > > + pdma->n_chans = PDMA_MAX_NR_CH; > > > + } > > > + > > > + if (pdma->n_chans > PDMA_MAX_NR_CH) { > > > + dev_err(&pdev->dev, "the number of channels exceeds the maximum\n"); > > > + return -EINVAL; > > > > Can we get away with just using only the number of channels the driver > > actually supports? ie, just never sending an op to the channels above > > MAX_NR_CH? That should leave us with nothing to track. In theory we can... > It might be a bit like when pdma->n_chans is bigger than the maximum, > set the pdma->chans to PDMA_MAX_NR_CH, then we could ensure that we > don't access the channels above the maximum. If I understand > correctly, I gave the similar thought in the thread of v2 patch, and > there are some discussions on that, but this way seems to lead to > hard-to-track problems. ... but that would mean that when a new variant appears that supports more channels, no error is printed, and people might not notice immediately that the higher channels are never used. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 3/3] dmaengine: sf-pdma: Get number of channel by device tree @ 2022-01-21 8:33 ` Geert Uytterhoeven 0 siblings, 0 replies; 30+ messages in thread From: Geert Uytterhoeven @ 2022-01-21 8:33 UTC (permalink / raw) To: Zong Li Cc: Palmer Dabbelt, Rob Herring, Paul Walmsley, Albert Ou, Krzysztof Kozlowski, Conor Dooley, Bin Meng, Green Wan, Vinod, dmaengine, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel@vger.kernel.org List, linux-riscv Hi Zong, Palmer, On Fri, Jan 21, 2022 at 3:21 AM Zong Li <zong.li@sifive.com> wrote: > On Fri, Jan 21, 2022 at 2:52 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > On Sun, 16 Jan 2022 17:35:28 PST (-0800), zong.li@sifive.com wrote: > > > It currently assumes that there are always four channels, it would > > > cause the error if there is actually less than four channels. Change > > > that by getting number of channel from device tree. > > > > > > For backwards-compatible, it uses the default value (i.e. 4) when there > > > is no 'dma-channels' information in dts. > > > > Some of the same wording issues here as those I pointed out in the DT > > bindings patch. > > > > > Signed-off-by: Zong Li <zong.li@sifive.com> > > > --- a/drivers/dma/sf-pdma/sf-pdma.c > > > +++ b/drivers/dma/sf-pdma/sf-pdma.c > > > @@ -482,9 +482,7 @@ static void sf_pdma_setup_chans(struct sf_pdma *pdma) > > > static int sf_pdma_probe(struct platform_device *pdev) > > > { > > > struct sf_pdma *pdma; > > > - struct sf_pdma_chan *chan; > > > struct resource *res; > > > - int len, chans; > > > int ret; > > > const enum dma_slave_buswidth widths = > > > DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES | > > > @@ -492,13 +490,21 @@ static int sf_pdma_probe(struct platform_device *pdev) > > > DMA_SLAVE_BUSWIDTH_16_BYTES | DMA_SLAVE_BUSWIDTH_32_BYTES | > > > DMA_SLAVE_BUSWIDTH_64_BYTES; > > > > > > - chans = PDMA_NR_CH; > > > - len = sizeof(*pdma) + sizeof(*chan) * chans; > > > - pdma = devm_kzalloc(&pdev->dev, len, GFP_KERNEL); > > > + pdma = devm_kzalloc(&pdev->dev, sizeof(*pdma), GFP_KERNEL); > > > if (!pdma) > > > return -ENOMEM; > > > > > > - pdma->n_chans = chans; > > > + ret = of_property_read_u32(pdev->dev.of_node, "dma-channels", > > > + &pdma->n_chans); > > > + if (ret) { > > > + dev_notice(&pdev->dev, "set number of channels to default value: 4\n"); > > > + pdma->n_chans = PDMA_MAX_NR_CH; > > > + } > > > + > > > + if (pdma->n_chans > PDMA_MAX_NR_CH) { > > > + dev_err(&pdev->dev, "the number of channels exceeds the maximum\n"); > > > + return -EINVAL; > > > > Can we get away with just using only the number of channels the driver > > actually supports? ie, just never sending an op to the channels above > > MAX_NR_CH? That should leave us with nothing to track. In theory we can... > It might be a bit like when pdma->n_chans is bigger than the maximum, > set the pdma->chans to PDMA_MAX_NR_CH, then we could ensure that we > don't access the channels above the maximum. If I understand > correctly, I gave the similar thought in the thread of v2 patch, and > there are some discussions on that, but this way seems to lead to > hard-to-track problems. ... but that would mean that when a new variant appears that supports more channels, no error is printed, and people might not notice immediately that the higher channels are never used. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 3/3] dmaengine: sf-pdma: Get number of channel by device tree 2022-01-21 8:33 ` Geert Uytterhoeven @ 2022-01-21 10:29 ` Zong Li -1 siblings, 0 replies; 30+ messages in thread From: Zong Li @ 2022-01-21 10:29 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Palmer Dabbelt, Rob Herring, Paul Walmsley, Albert Ou, Krzysztof Kozlowski, Conor Dooley, Bin Meng, Green Wan, Vinod, dmaengine, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel@vger.kernel.org List, linux-riscv On Fri, Jan 21, 2022 at 4:33 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Zong, Palmer, > > On Fri, Jan 21, 2022 at 3:21 AM Zong Li <zong.li@sifive.com> wrote: > > On Fri, Jan 21, 2022 at 2:52 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > > On Sun, 16 Jan 2022 17:35:28 PST (-0800), zong.li@sifive.com wrote: > > > > It currently assumes that there are always four channels, it would > > > > cause the error if there is actually less than four channels. Change > > > > that by getting number of channel from device tree. > > > > > > > > For backwards-compatible, it uses the default value (i.e. 4) when there > > > > is no 'dma-channels' information in dts. > > > > > > Some of the same wording issues here as those I pointed out in the DT > > > bindings patch. > > > > > > > Signed-off-by: Zong Li <zong.li@sifive.com> > > > > > --- a/drivers/dma/sf-pdma/sf-pdma.c > > > > +++ b/drivers/dma/sf-pdma/sf-pdma.c > > > > @@ -482,9 +482,7 @@ static void sf_pdma_setup_chans(struct sf_pdma *pdma) > > > > static int sf_pdma_probe(struct platform_device *pdev) > > > > { > > > > struct sf_pdma *pdma; > > > > - struct sf_pdma_chan *chan; > > > > struct resource *res; > > > > - int len, chans; > > > > int ret; > > > > const enum dma_slave_buswidth widths = > > > > DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES | > > > > @@ -492,13 +490,21 @@ static int sf_pdma_probe(struct platform_device *pdev) > > > > DMA_SLAVE_BUSWIDTH_16_BYTES | DMA_SLAVE_BUSWIDTH_32_BYTES | > > > > DMA_SLAVE_BUSWIDTH_64_BYTES; > > > > > > > > - chans = PDMA_NR_CH; > > > > - len = sizeof(*pdma) + sizeof(*chan) * chans; > > > > - pdma = devm_kzalloc(&pdev->dev, len, GFP_KERNEL); > > > > + pdma = devm_kzalloc(&pdev->dev, sizeof(*pdma), GFP_KERNEL); > > > > if (!pdma) > > > > return -ENOMEM; > > > > > > > > - pdma->n_chans = chans; > > > > + ret = of_property_read_u32(pdev->dev.of_node, "dma-channels", > > > > + &pdma->n_chans); > > > > + if (ret) { > > > > + dev_notice(&pdev->dev, "set number of channels to default value: 4\n"); > > > > + pdma->n_chans = PDMA_MAX_NR_CH; > > > > + } > > > > + > > > > + if (pdma->n_chans > PDMA_MAX_NR_CH) { > > > > + dev_err(&pdev->dev, "the number of channels exceeds the maximum\n"); > > > > + return -EINVAL; > > > > > > Can we get away with just using only the number of channels the driver > > > actually supports? ie, just never sending an op to the channels above > > > MAX_NR_CH? That should leave us with nothing to track. > > In theory we can... > > > It might be a bit like when pdma->n_chans is bigger than the maximum, > > set the pdma->chans to PDMA_MAX_NR_CH, then we could ensure that we > > don't access the channels above the maximum. If I understand > > correctly, I gave the similar thought in the thread of v2 patch, and > > there are some discussions on that, but this way seems to lead to > > hard-to-track problems. > > ... but that would mean that when a new variant appears that supports > more channels, no error is printed, and people might not notice > immediately that the higher channels are never used. > I guess people might need to follow the dt-bindings, so they couldn't specify the number of channels to the value which is more than maximum. But as you mentioned, if people don't notice that and specify it more than maximum, they wouldn't be aware that the higher channels are never used. It seems to me that we could keep returning the error there, or show a warning message and use PDMA_MAX_NR_CH in that situation, both looks good to me. > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 3/3] dmaengine: sf-pdma: Get number of channel by device tree @ 2022-01-21 10:29 ` Zong Li 0 siblings, 0 replies; 30+ messages in thread From: Zong Li @ 2022-01-21 10:29 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Palmer Dabbelt, Rob Herring, Paul Walmsley, Albert Ou, Krzysztof Kozlowski, Conor Dooley, Bin Meng, Green Wan, Vinod, dmaengine, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel@vger.kernel.org List, linux-riscv On Fri, Jan 21, 2022 at 4:33 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Zong, Palmer, > > On Fri, Jan 21, 2022 at 3:21 AM Zong Li <zong.li@sifive.com> wrote: > > On Fri, Jan 21, 2022 at 2:52 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > > On Sun, 16 Jan 2022 17:35:28 PST (-0800), zong.li@sifive.com wrote: > > > > It currently assumes that there are always four channels, it would > > > > cause the error if there is actually less than four channels. Change > > > > that by getting number of channel from device tree. > > > > > > > > For backwards-compatible, it uses the default value (i.e. 4) when there > > > > is no 'dma-channels' information in dts. > > > > > > Some of the same wording issues here as those I pointed out in the DT > > > bindings patch. > > > > > > > Signed-off-by: Zong Li <zong.li@sifive.com> > > > > > --- a/drivers/dma/sf-pdma/sf-pdma.c > > > > +++ b/drivers/dma/sf-pdma/sf-pdma.c > > > > @@ -482,9 +482,7 @@ static void sf_pdma_setup_chans(struct sf_pdma *pdma) > > > > static int sf_pdma_probe(struct platform_device *pdev) > > > > { > > > > struct sf_pdma *pdma; > > > > - struct sf_pdma_chan *chan; > > > > struct resource *res; > > > > - int len, chans; > > > > int ret; > > > > const enum dma_slave_buswidth widths = > > > > DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES | > > > > @@ -492,13 +490,21 @@ static int sf_pdma_probe(struct platform_device *pdev) > > > > DMA_SLAVE_BUSWIDTH_16_BYTES | DMA_SLAVE_BUSWIDTH_32_BYTES | > > > > DMA_SLAVE_BUSWIDTH_64_BYTES; > > > > > > > > - chans = PDMA_NR_CH; > > > > - len = sizeof(*pdma) + sizeof(*chan) * chans; > > > > - pdma = devm_kzalloc(&pdev->dev, len, GFP_KERNEL); > > > > + pdma = devm_kzalloc(&pdev->dev, sizeof(*pdma), GFP_KERNEL); > > > > if (!pdma) > > > > return -ENOMEM; > > > > > > > > - pdma->n_chans = chans; > > > > + ret = of_property_read_u32(pdev->dev.of_node, "dma-channels", > > > > + &pdma->n_chans); > > > > + if (ret) { > > > > + dev_notice(&pdev->dev, "set number of channels to default value: 4\n"); > > > > + pdma->n_chans = PDMA_MAX_NR_CH; > > > > + } > > > > + > > > > + if (pdma->n_chans > PDMA_MAX_NR_CH) { > > > > + dev_err(&pdev->dev, "the number of channels exceeds the maximum\n"); > > > > + return -EINVAL; > > > > > > Can we get away with just using only the number of channels the driver > > > actually supports? ie, just never sending an op to the channels above > > > MAX_NR_CH? That should leave us with nothing to track. > > In theory we can... > > > It might be a bit like when pdma->n_chans is bigger than the maximum, > > set the pdma->chans to PDMA_MAX_NR_CH, then we could ensure that we > > don't access the channels above the maximum. If I understand > > correctly, I gave the similar thought in the thread of v2 patch, and > > there are some discussions on that, but this way seems to lead to > > hard-to-track problems. > > ... but that would mean that when a new variant appears that supports > more channels, no error is printed, and people might not notice > immediately that the higher channels are never used. > I guess people might need to follow the dt-bindings, so they couldn't specify the number of channels to the value which is more than maximum. But as you mentioned, if people don't notice that and specify it more than maximum, they wouldn't be aware that the higher channels are never used. It seems to me that we could keep returning the error there, or show a warning message and use PDMA_MAX_NR_CH in that situation, both looks good to me. > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 3/3] dmaengine: sf-pdma: Get number of channel by device tree 2022-01-21 10:29 ` Zong Li @ 2022-01-25 5:08 ` Zong Li -1 siblings, 0 replies; 30+ messages in thread From: Zong Li @ 2022-01-25 5:08 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Palmer Dabbelt, Rob Herring, Paul Walmsley, Albert Ou, Krzysztof Kozlowski, Conor Dooley, Bin Meng, Green Wan, Vinod, dmaengine, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel@vger.kernel.org List, linux-riscv On Fri, Jan 21, 2022 at 6:29 PM Zong Li <zong.li@sifive.com> wrote: > > On Fri, Jan 21, 2022 at 4:33 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > Hi Zong, Palmer, > > > > On Fri, Jan 21, 2022 at 3:21 AM Zong Li <zong.li@sifive.com> wrote: > > > On Fri, Jan 21, 2022 at 2:52 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > > > On Sun, 16 Jan 2022 17:35:28 PST (-0800), zong.li@sifive.com wrote: > > > > > It currently assumes that there are always four channels, it would > > > > > cause the error if there is actually less than four channels. Change > > > > > that by getting number of channel from device tree. > > > > > > > > > > For backwards-compatible, it uses the default value (i.e. 4) when there > > > > > is no 'dma-channels' information in dts. > > > > > > > > Some of the same wording issues here as those I pointed out in the DT > > > > bindings patch. > > > > > > > > > Signed-off-by: Zong Li <zong.li@sifive.com> > > > > > > > --- a/drivers/dma/sf-pdma/sf-pdma.c > > > > > +++ b/drivers/dma/sf-pdma/sf-pdma.c > > > > > @@ -482,9 +482,7 @@ static void sf_pdma_setup_chans(struct sf_pdma *pdma) > > > > > static int sf_pdma_probe(struct platform_device *pdev) > > > > > { > > > > > struct sf_pdma *pdma; > > > > > - struct sf_pdma_chan *chan; > > > > > struct resource *res; > > > > > - int len, chans; > > > > > int ret; > > > > > const enum dma_slave_buswidth widths = > > > > > DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES | > > > > > @@ -492,13 +490,21 @@ static int sf_pdma_probe(struct platform_device *pdev) > > > > > DMA_SLAVE_BUSWIDTH_16_BYTES | DMA_SLAVE_BUSWIDTH_32_BYTES | > > > > > DMA_SLAVE_BUSWIDTH_64_BYTES; > > > > > > > > > > - chans = PDMA_NR_CH; > > > > > - len = sizeof(*pdma) + sizeof(*chan) * chans; > > > > > - pdma = devm_kzalloc(&pdev->dev, len, GFP_KERNEL); > > > > > + pdma = devm_kzalloc(&pdev->dev, sizeof(*pdma), GFP_KERNEL); > > > > > if (!pdma) > > > > > return -ENOMEM; > > > > > > > > > > - pdma->n_chans = chans; > > > > > + ret = of_property_read_u32(pdev->dev.of_node, "dma-channels", > > > > > + &pdma->n_chans); > > > > > + if (ret) { > > > > > + dev_notice(&pdev->dev, "set number of channels to default value: 4\n"); > > > > > + pdma->n_chans = PDMA_MAX_NR_CH; > > > > > + } > > > > > + > > > > > + if (pdma->n_chans > PDMA_MAX_NR_CH) { > > > > > + dev_err(&pdev->dev, "the number of channels exceeds the maximum\n"); > > > > > + return -EINVAL; > > > > > > > > Can we get away with just using only the number of channels the driver > > > > actually supports? ie, just never sending an op to the channels above > > > > MAX_NR_CH? That should leave us with nothing to track. > > > > In theory we can... > > > > > It might be a bit like when pdma->n_chans is bigger than the maximum, > > > set the pdma->chans to PDMA_MAX_NR_CH, then we could ensure that we > > > don't access the channels above the maximum. If I understand > > > correctly, I gave the similar thought in the thread of v2 patch, and > > > there are some discussions on that, but this way seems to lead to > > > hard-to-track problems. > > > > ... but that would mean that when a new variant appears that supports > > more channels, no error is printed, and people might not notice > > immediately that the higher channels are never used. > > > > I guess people might need to follow the dt-bindings, so they couldn't > specify the number of channels to the value which is more than > maximum. But as you mentioned, if people don't notice that and specify > it more than maximum, they wouldn't be aware that the higher channels > are never used. It seems to me that we could keep returning the error > there, or show a warning message and use PDMA_MAX_NR_CH in that > situation, both looks good to me. > Hi all, thank you for the review, I'd like to prepare the next version patch, if current implementation of this part is ok to you, I will keep it in the next version. Please let me know if anything can be improved. Thanks > > Gr{oetje,eeting}s, > > > > Geert > > > > -- > > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > > > In personal conversations with technical people, I call myself a hacker. But > > when I'm talking to journalists I just say "programmer" or something like that. > > -- Linus Torvalds _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 3/3] dmaengine: sf-pdma: Get number of channel by device tree @ 2022-01-25 5:08 ` Zong Li 0 siblings, 0 replies; 30+ messages in thread From: Zong Li @ 2022-01-25 5:08 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Palmer Dabbelt, Rob Herring, Paul Walmsley, Albert Ou, Krzysztof Kozlowski, Conor Dooley, Bin Meng, Green Wan, Vinod, dmaengine, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel@vger.kernel.org List, linux-riscv On Fri, Jan 21, 2022 at 6:29 PM Zong Li <zong.li@sifive.com> wrote: > > On Fri, Jan 21, 2022 at 4:33 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > Hi Zong, Palmer, > > > > On Fri, Jan 21, 2022 at 3:21 AM Zong Li <zong.li@sifive.com> wrote: > > > On Fri, Jan 21, 2022 at 2:52 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > > > On Sun, 16 Jan 2022 17:35:28 PST (-0800), zong.li@sifive.com wrote: > > > > > It currently assumes that there are always four channels, it would > > > > > cause the error if there is actually less than four channels. Change > > > > > that by getting number of channel from device tree. > > > > > > > > > > For backwards-compatible, it uses the default value (i.e. 4) when there > > > > > is no 'dma-channels' information in dts. > > > > > > > > Some of the same wording issues here as those I pointed out in the DT > > > > bindings patch. > > > > > > > > > Signed-off-by: Zong Li <zong.li@sifive.com> > > > > > > > --- a/drivers/dma/sf-pdma/sf-pdma.c > > > > > +++ b/drivers/dma/sf-pdma/sf-pdma.c > > > > > @@ -482,9 +482,7 @@ static void sf_pdma_setup_chans(struct sf_pdma *pdma) > > > > > static int sf_pdma_probe(struct platform_device *pdev) > > > > > { > > > > > struct sf_pdma *pdma; > > > > > - struct sf_pdma_chan *chan; > > > > > struct resource *res; > > > > > - int len, chans; > > > > > int ret; > > > > > const enum dma_slave_buswidth widths = > > > > > DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES | > > > > > @@ -492,13 +490,21 @@ static int sf_pdma_probe(struct platform_device *pdev) > > > > > DMA_SLAVE_BUSWIDTH_16_BYTES | DMA_SLAVE_BUSWIDTH_32_BYTES | > > > > > DMA_SLAVE_BUSWIDTH_64_BYTES; > > > > > > > > > > - chans = PDMA_NR_CH; > > > > > - len = sizeof(*pdma) + sizeof(*chan) * chans; > > > > > - pdma = devm_kzalloc(&pdev->dev, len, GFP_KERNEL); > > > > > + pdma = devm_kzalloc(&pdev->dev, sizeof(*pdma), GFP_KERNEL); > > > > > if (!pdma) > > > > > return -ENOMEM; > > > > > > > > > > - pdma->n_chans = chans; > > > > > + ret = of_property_read_u32(pdev->dev.of_node, "dma-channels", > > > > > + &pdma->n_chans); > > > > > + if (ret) { > > > > > + dev_notice(&pdev->dev, "set number of channels to default value: 4\n"); > > > > > + pdma->n_chans = PDMA_MAX_NR_CH; > > > > > + } > > > > > + > > > > > + if (pdma->n_chans > PDMA_MAX_NR_CH) { > > > > > + dev_err(&pdev->dev, "the number of channels exceeds the maximum\n"); > > > > > + return -EINVAL; > > > > > > > > Can we get away with just using only the number of channels the driver > > > > actually supports? ie, just never sending an op to the channels above > > > > MAX_NR_CH? That should leave us with nothing to track. > > > > In theory we can... > > > > > It might be a bit like when pdma->n_chans is bigger than the maximum, > > > set the pdma->chans to PDMA_MAX_NR_CH, then we could ensure that we > > > don't access the channels above the maximum. If I understand > > > correctly, I gave the similar thought in the thread of v2 patch, and > > > there are some discussions on that, but this way seems to lead to > > > hard-to-track problems. > > > > ... but that would mean that when a new variant appears that supports > > more channels, no error is printed, and people might not notice > > immediately that the higher channels are never used. > > > > I guess people might need to follow the dt-bindings, so they couldn't > specify the number of channels to the value which is more than > maximum. But as you mentioned, if people don't notice that and specify > it more than maximum, they wouldn't be aware that the higher channels > are never used. It seems to me that we could keep returning the error > there, or show a warning message and use PDMA_MAX_NR_CH in that > situation, both looks good to me. > Hi all, thank you for the review, I'd like to prepare the next version patch, if current implementation of this part is ok to you, I will keep it in the next version. Please let me know if anything can be improved. Thanks > > Gr{oetje,eeting}s, > > > > Geert > > > > -- > > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > > > In personal conversations with technical people, I call myself a hacker. But > > when I'm talking to journalists I just say "programmer" or something like that. > > -- Linus Torvalds ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2022-01-27 7:35 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-17 1:35 [PATCH v4 0/3] Determine the number of DMA channels by 'dma-channels' property Zong Li 2022-01-17 1:35 ` Zong Li 2022-01-17 1:35 ` [PATCH v4 1/3] riscv: dts: Add dma-channels property in dma node Zong Li 2022-01-17 1:35 ` Zong Li 2022-01-18 15:04 ` Conor.Dooley 2022-01-18 15:04 ` Conor.Dooley 2022-01-20 18:51 ` Palmer Dabbelt 2022-01-20 18:51 ` Palmer Dabbelt 2022-01-27 7:03 ` Vinod Koul 2022-01-27 7:03 ` Vinod Koul 2022-01-27 7:35 ` Zong Li 2022-01-27 7:35 ` Zong Li 2022-01-17 1:35 ` [PATCH v4 2/3] dt-bindings: Add dma-channels for pdma device node Zong Li 2022-01-17 1:35 ` Zong Li 2022-01-20 18:51 ` Palmer Dabbelt 2022-01-20 18:51 ` Palmer Dabbelt 2022-01-21 1:57 ` Zong Li 2022-01-21 1:57 ` Zong Li 2022-01-17 1:35 ` [PATCH v4 3/3] dmaengine: sf-pdma: Get number of channel by device tree Zong Li 2022-01-17 1:35 ` Zong Li 2022-01-20 18:51 ` Palmer Dabbelt 2022-01-20 18:51 ` Palmer Dabbelt 2022-01-21 2:21 ` Zong Li 2022-01-21 2:21 ` Zong Li 2022-01-21 8:33 ` Geert Uytterhoeven 2022-01-21 8:33 ` Geert Uytterhoeven 2022-01-21 10:29 ` Zong Li 2022-01-21 10:29 ` Zong Li 2022-01-25 5:08 ` Zong Li 2022-01-25 5:08 ` Zong Li
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.