* [PATCH v2 0/2] eliminate two common errors reported by any yaml on arm64
@ 2020-10-16 9:08 ` Zhen Lei
0 siblings, 0 replies; 54+ messages in thread
From: Zhen Lei @ 2020-10-16 9:08 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann, Florian Fainelli, Ray Jui,
Scott Branden, bcm-kernel-feedback-list, Andy Gross,
Bjorn Andersson, linux-arm-msm, devicetree, linux-arm-kernel,
linux-kernel
Cc: Zhen Lei
v1 --> v2:
Although it's simpler to delete the empty "dma-ranges" property, and the function
of_translate_one() in drivers/of/address.c will treate non "dma-ranges" case as
empty "dma-ranges". But as Arnd Bergmann suggested: it's not good for the scenario
of IOMMU disabled or absented.
This version make sure that the node have empty "dma-ranges" property have the same
"#address-cells" and "#size-cells" values as its parent node.
v1:
The following errors occured no matter which YAML file I executed on arm64.
Therefore, it is necessary to eliminate it so that people's time and energy are
not wasted every time.
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
Zhen Lei (2):
arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
arm64: dts: qcom: clear the warnings caused by empty dma-ranges
.../boot/dts/broadcom/stingray/stingray-usb.dtsi | 20 +++---
arch/arm64/boot/dts/qcom/ipq6018.dtsi | 72 +++++++++++-----------
2 files changed, 46 insertions(+), 46 deletions(-)
--
1.8.3
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH v2 0/2] eliminate two common errors reported by any yaml on arm64
@ 2020-10-16 9:08 ` Zhen Lei
0 siblings, 0 replies; 54+ messages in thread
From: Zhen Lei @ 2020-10-16 9:08 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann, Florian Fainelli, Ray Jui,
Scott Branden, bcm-kernel-feedback-list, Andy Gross,
Bjorn Andersson, linux-arm-msm, devicetree, linux-arm-kernel,
linux-kernel
Cc: Zhen Lei
v1 --> v2:
Although it's simpler to delete the empty "dma-ranges" property, and the function
of_translate_one() in drivers/of/address.c will treate non "dma-ranges" case as
empty "dma-ranges". But as Arnd Bergmann suggested: it's not good for the scenario
of IOMMU disabled or absented.
This version make sure that the node have empty "dma-ranges" property have the same
"#address-cells" and "#size-cells" values as its parent node.
v1:
The following errors occured no matter which YAML file I executed on arm64.
Therefore, it is necessary to eliminate it so that people's time and energy are
not wasted every time.
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
Zhen Lei (2):
arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
arm64: dts: qcom: clear the warnings caused by empty dma-ranges
.../boot/dts/broadcom/stingray/stingray-usb.dtsi | 20 +++---
arch/arm64/boot/dts/qcom/ipq6018.dtsi | 72 +++++++++++-----------
2 files changed, 46 insertions(+), 46 deletions(-)
--
1.8.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2020-10-16 9:08 ` Zhen Lei
@ 2020-10-16 9:08 ` Zhen Lei
-1 siblings, 0 replies; 54+ messages in thread
From: Zhen Lei @ 2020-10-16 9:08 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann, Florian Fainelli, Ray Jui,
Scott Branden, bcm-kernel-feedback-list, Andy Gross,
Bjorn Andersson, linux-arm-msm, devicetree, linux-arm-kernel,
linux-kernel
Cc: Zhen Lei
The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
property must have the same "#address-cells" and "#size-cells" values as
the parent node. Otherwise, the following warnings is reported:
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
(dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
(dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
its #size-cells (1) differs from / (2)
Arnd Bergmann figured out why it's necessary:
Also note that the #address-cells=<1> means that any device under
this bus is assumed to only support 32-bit addressing, and DMA will
have to go through a slow swiotlb in the absence of an IOMMU.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
.../boot/dts/broadcom/stingray/stingray-usb.dtsi | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
index 55259f973b5a9e4..aef8f2b00778d71 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
@@ -5,20 +5,20 @@
usb {
compatible = "simple-bus";
dma-ranges;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x0 0x68500000 0x00400000>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x0 0x0 0x0 0x68500000 0x0 0x00400000>;
usbphy0: usb-phy@0 {
compatible = "brcm,sr-usb-combo-phy";
- reg = <0x00000000 0x100>;
+ reg = <0x0 0x00000000 0x0 0x100>;
#phy-cells = <1>;
status = "disabled";
};
xhci0: usb@1000 {
compatible = "generic-xhci";
- reg = <0x00001000 0x1000>;
+ reg = <0x0 0x00001000 0x0 0x1000>;
interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>;
phys = <&usbphy0 1>, <&usbphy0 0>;
phy-names = "phy0", "phy1";
@@ -28,7 +28,7 @@
bdc0: usb@2000 {
compatible = "brcm,bdc-v0.16";
- reg = <0x00002000 0x1000>;
+ reg = <0x0 0x00002000 0x0 0x1000>;
interrupts = <GIC_SPI 259 IRQ_TYPE_LEVEL_HIGH>;
phys = <&usbphy0 0>, <&usbphy0 1>;
phy-names = "phy0", "phy1";
@@ -38,21 +38,21 @@
usbphy1: usb-phy@10000 {
compatible = "brcm,sr-usb-combo-phy";
- reg = <0x00010000 0x100>;
+ reg = <0x0 0x00010000 0x0 0x100>;
#phy-cells = <1>;
status = "disabled";
};
usbphy2: usb-phy@20000 {
compatible = "brcm,sr-usb-hs-phy";
- reg = <0x00020000 0x100>;
+ reg = <0x0 0x00020000 0x0 0x100>;
#phy-cells = <0>;
status = "disabled";
};
xhci1: usb@11000 {
compatible = "generic-xhci";
- reg = <0x00011000 0x1000>;
+ reg = <0x0 0x00011000 0x0 0x1000>;
interrupts = <GIC_SPI 263 IRQ_TYPE_LEVEL_HIGH>;
phys = <&usbphy1 1>, <&usbphy2>, <&usbphy1 0>;
phy-names = "phy0", "phy1", "phy2";
@@ -62,7 +62,7 @@
bdc1: usb@21000 {
compatible = "brcm,bdc-v0.16";
- reg = <0x00021000 0x1000>;
+ reg = <0x0 0x00021000 0x0 0x1000>;
interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>;
phys = <&usbphy2>;
phy-names = "phy0";
--
1.8.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2020-10-16 9:08 ` Zhen Lei
0 siblings, 0 replies; 54+ messages in thread
From: Zhen Lei @ 2020-10-16 9:08 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann, Florian Fainelli, Ray Jui,
Scott Branden, bcm-kernel-feedback-list, Andy Gross,
Bjorn Andersson, linux-arm-msm, devicetree, linux-arm-kernel,
linux-kernel
Cc: Zhen Lei
The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
property must have the same "#address-cells" and "#size-cells" values as
the parent node. Otherwise, the following warnings is reported:
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
(dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
(dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
its #size-cells (1) differs from / (2)
Arnd Bergmann figured out why it's necessary:
Also note that the #address-cells=<1> means that any device under
this bus is assumed to only support 32-bit addressing, and DMA will
have to go through a slow swiotlb in the absence of an IOMMU.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
.../boot/dts/broadcom/stingray/stingray-usb.dtsi | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
index 55259f973b5a9e4..aef8f2b00778d71 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
@@ -5,20 +5,20 @@
usb {
compatible = "simple-bus";
dma-ranges;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x0 0x68500000 0x00400000>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x0 0x0 0x0 0x68500000 0x0 0x00400000>;
usbphy0: usb-phy@0 {
compatible = "brcm,sr-usb-combo-phy";
- reg = <0x00000000 0x100>;
+ reg = <0x0 0x00000000 0x0 0x100>;
#phy-cells = <1>;
status = "disabled";
};
xhci0: usb@1000 {
compatible = "generic-xhci";
- reg = <0x00001000 0x1000>;
+ reg = <0x0 0x00001000 0x0 0x1000>;
interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>;
phys = <&usbphy0 1>, <&usbphy0 0>;
phy-names = "phy0", "phy1";
@@ -28,7 +28,7 @@
bdc0: usb@2000 {
compatible = "brcm,bdc-v0.16";
- reg = <0x00002000 0x1000>;
+ reg = <0x0 0x00002000 0x0 0x1000>;
interrupts = <GIC_SPI 259 IRQ_TYPE_LEVEL_HIGH>;
phys = <&usbphy0 0>, <&usbphy0 1>;
phy-names = "phy0", "phy1";
@@ -38,21 +38,21 @@
usbphy1: usb-phy@10000 {
compatible = "brcm,sr-usb-combo-phy";
- reg = <0x00010000 0x100>;
+ reg = <0x0 0x00010000 0x0 0x100>;
#phy-cells = <1>;
status = "disabled";
};
usbphy2: usb-phy@20000 {
compatible = "brcm,sr-usb-hs-phy";
- reg = <0x00020000 0x100>;
+ reg = <0x0 0x00020000 0x0 0x100>;
#phy-cells = <0>;
status = "disabled";
};
xhci1: usb@11000 {
compatible = "generic-xhci";
- reg = <0x00011000 0x1000>;
+ reg = <0x0 0x00011000 0x0 0x1000>;
interrupts = <GIC_SPI 263 IRQ_TYPE_LEVEL_HIGH>;
phys = <&usbphy1 1>, <&usbphy2>, <&usbphy1 0>;
phy-names = "phy0", "phy1", "phy2";
@@ -62,7 +62,7 @@
bdc1: usb@21000 {
compatible = "brcm,bdc-v0.16";
- reg = <0x00021000 0x1000>;
+ reg = <0x0 0x00021000 0x0 0x1000>;
interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>;
phys = <&usbphy2>;
phy-names = "phy0";
--
1.8.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v2 2/2] arm64: dts: qcom: clear the warnings caused by empty dma-ranges
2020-10-16 9:08 ` Zhen Lei
@ 2020-10-16 9:08 ` Zhen Lei
-1 siblings, 0 replies; 54+ messages in thread
From: Zhen Lei @ 2020-10-16 9:08 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann, Florian Fainelli, Ray Jui,
Scott Branden, bcm-kernel-feedback-list, Andy Gross,
Bjorn Andersson, linux-arm-msm, devicetree, linux-arm-kernel,
linux-kernel
Cc: Zhen Lei
The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
property must have the same "#address-cells" and "#size-cells" values as
the parent node. Otherwise, the following warnings is reported:
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning \
(dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but \
its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning \
(dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but \
its #size-cells (1) differs from / (2)
Arnd Bergmann figured out why it's necessary:
Also note that the #address-cells=<1> means that any device under
this bus is assumed to only support 32-bit addressing, and DMA will
have to go through a slow swiotlb in the absence of an IOMMU.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
arch/arm64/boot/dts/qcom/ipq6018.dtsi | 72 +++++++++++++++++------------------
1 file changed, 36 insertions(+), 36 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/ipq6018.dtsi b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
index a94dac76bf3fbdd..59e0cbfa2214305 100644
--- a/arch/arm64/boot/dts/qcom/ipq6018.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
@@ -179,22 +179,22 @@
};
soc: soc {
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0 0 0xffffffff>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0 0 0 0 0x0 0xffffffff>;
dma-ranges;
compatible = "simple-bus";
prng: qrng@e1000 {
compatible = "qcom,prng-ee";
- reg = <0xe3000 0x1000>;
+ reg = <0x0 0xe3000 0x0 0x1000>;
clocks = <&gcc GCC_PRNG_AHB_CLK>;
clock-names = "core";
};
cryptobam: dma@704000 {
compatible = "qcom,bam-v1.7.0";
- reg = <0x00704000 0x20000>;
+ reg = <0x0 0x00704000 0x0 0x20000>;
interrupts = <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_CRYPTO_AHB_CLK>;
clock-names = "bam_clk";
@@ -206,7 +206,7 @@
crypto: crypto@73a000 {
compatible = "qcom,crypto-v5.1";
- reg = <0x0073a000 0x6000>;
+ reg = <0x0 0x0073a000 0x0 0x6000>;
clocks = <&gcc GCC_CRYPTO_AHB_CLK>,
<&gcc GCC_CRYPTO_AXI_CLK>,
<&gcc GCC_CRYPTO_CLK>;
@@ -217,7 +217,7 @@
tlmm: pinctrl@1000000 {
compatible = "qcom,ipq6018-pinctrl";
- reg = <0x01000000 0x300000>;
+ reg = <0x0 0x01000000 0x0 0x300000>;
interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
@@ -235,7 +235,7 @@
gcc: gcc@1800000 {
compatible = "qcom,gcc-ipq6018";
- reg = <0x01800000 0x80000>;
+ reg = <0x0 0x01800000 0x0 0x80000>;
clocks = <&xo>, <&sleep_clk>;
clock-names = "xo", "sleep_clk";
#clock-cells = <1>;
@@ -244,17 +244,17 @@
tcsr_mutex_regs: syscon@1905000 {
compatible = "syscon";
- reg = <0x01905000 0x8000>;
+ reg = <0x0 0x01905000 0x0 0x8000>;
};
tcsr_q6: syscon@1945000 {
compatible = "syscon";
- reg = <0x01945000 0xe000>;
+ reg = <0x0 0x01945000 0x0 0xe000>;
};
blsp_dma: dma@7884000 {
compatible = "qcom,bam-v1.7.0";
- reg = <0x07884000 0x2b000>;
+ reg = <0x0 0x07884000 0x0 0x2b000>;
interrupts = <GIC_SPI 238 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_BLSP1_AHB_CLK>;
clock-names = "bam_clk";
@@ -264,7 +264,7 @@
blsp1_uart3: serial@78b1000 {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
- reg = <0x078b1000 0x200>;
+ reg = <0x0 0x078b1000 0x0 0x200>;
interrupts = <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_BLSP1_UART3_APPS_CLK>,
<&gcc GCC_BLSP1_AHB_CLK>;
@@ -276,7 +276,7 @@
compatible = "qcom,spi-qup-v2.2.1";
#address-cells = <1>;
#size-cells = <0>;
- reg = <0x078b5000 0x600>;
+ reg = <0x0 0x078b5000 0x0 0x600>;
interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
spi-max-frequency = <50000000>;
clocks = <&gcc GCC_BLSP1_QUP1_SPI_APPS_CLK>,
@@ -291,7 +291,7 @@
compatible = "qcom,spi-qup-v2.2.1";
#address-cells = <1>;
#size-cells = <0>;
- reg = <0x078b6000 0x600>;
+ reg = <0x0 0x078b6000 0x0 0x600>;
interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
spi-max-frequency = <50000000>;
clocks = <&gcc GCC_BLSP1_QUP2_SPI_APPS_CLK>,
@@ -306,7 +306,7 @@
compatible = "qcom,i2c-qup-v2.2.1";
#address-cells = <1>;
#size-cells = <0>;
- reg = <0x078b6000 0x600>;
+ reg = <0x0 0x078b6000 0x0 0x600>;
interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_BLSP1_AHB_CLK>,
<&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>;
@@ -321,7 +321,7 @@
compatible = "qcom,i2c-qup-v2.2.1";
#address-cells = <1>;
#size-cells = <0>;
- reg = <0x078b7000 0x600>;
+ reg = <0x0 0x078b7000 0x0 0x600>;
interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_BLSP1_AHB_CLK>,
<&gcc GCC_BLSP1_QUP3_I2C_APPS_CLK>;
@@ -336,24 +336,24 @@
compatible = "qcom,msm-qgic2";
interrupt-controller;
#interrupt-cells = <0x3>;
- reg = <0x0b000000 0x1000>, /*GICD*/
- <0x0b002000 0x1000>, /*GICC*/
- <0x0b001000 0x1000>, /*GICH*/
- <0x0b004000 0x1000>; /*GICV*/
+ reg = <0x0 0x0b000000 0x0 0x1000>, /*GICD*/
+ <0x0 0x0b002000 0x0 0x1000>, /*GICC*/
+ <0x0 0x0b001000 0x0 0x1000>, /*GICH*/
+ <0x0 0x0b004000 0x0 0x1000>; /*GICV*/
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
};
watchdog@b017000 {
compatible = "qcom,kpss-wdt";
interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
- reg = <0x0b017000 0x40>;
+ reg = <0x0 0x0b017000 0x0 0x40>;
clocks = <&sleep_clk>;
timeout-sec = <10>;
};
apcs_glb: mailbox@b111000 {
compatible = "qcom,ipq6018-apcs-apps-global";
- reg = <0x0b111000 0x1000>;
+ reg = <0x0 0x0b111000 0x0 0x1000>;
#clock-cells = <1>;
clocks = <&a53pll>, <&xo>;
clock-names = "pll", "xo";
@@ -362,7 +362,7 @@
a53pll: clock@b116000 {
compatible = "qcom,ipq6018-a53pll";
- reg = <0x0b116000 0x40>;
+ reg = <0x0 0x0b116000 0x0 0x40>;
#clock-cells = <0>;
clocks = <&xo>;
clock-names = "xo";
@@ -377,68 +377,68 @@
};
timer@b120000 {
- #address-cells = <1>;
- #size-cells = <1>;
+ #address-cells = <2>;
+ #size-cells = <2>;
ranges;
compatible = "arm,armv7-timer-mem";
- reg = <0x0b120000 0x1000>;
+ reg = <0x0 0x0b120000 0x0 0x1000>;
clock-frequency = <19200000>;
frame@b120000 {
frame-number = <0>;
interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0b121000 0x1000>,
- <0x0b122000 0x1000>;
+ reg = <0x0 0x0b121000 0x0 0x1000>,
+ <0x0 0x0b122000 0x0 0x1000>;
};
frame@b123000 {
frame-number = <1>;
interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0xb123000 0x1000>;
+ reg = <0x0 0xb123000 0x0 0x1000>;
status = "disabled";
};
frame@b124000 {
frame-number = <2>;
interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0b124000 0x1000>;
+ reg = <0x0 0x0b124000 0x0 0x1000>;
status = "disabled";
};
frame@b125000 {
frame-number = <3>;
interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0b125000 0x1000>;
+ reg = <0x0 0x0b125000 0x0 0x1000>;
status = "disabled";
};
frame@b126000 {
frame-number = <4>;
interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0b126000 0x1000>;
+ reg = <0x0 0x0b126000 0x0 0x1000>;
status = "disabled";
};
frame@b127000 {
frame-number = <5>;
interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0b127000 0x1000>;
+ reg = <0x0 0x0b127000 0x0 0x1000>;
status = "disabled";
};
frame@b128000 {
frame-number = <6>;
interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0b128000 0x1000>;
+ reg = <0x0 0x0b128000 0x0 0x1000>;
status = "disabled";
};
};
q6v5_wcss: remoteproc@cd00000 {
compatible = "qcom,ipq8074-wcss-pil";
- reg = <0x0cd00000 0x4040>,
- <0x004ab000 0x20>;
+ reg = <0x0 0x0cd00000 0x0 0x4040>,
+ <0x0 0x004ab000 0x0 0x20>;
reg-names = "qdsp6",
"rmb";
interrupts-extended = <&intc GIC_SPI 325 IRQ_TYPE_EDGE_RISING>,
--
1.8.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v2 2/2] arm64: dts: qcom: clear the warnings caused by empty dma-ranges
@ 2020-10-16 9:08 ` Zhen Lei
0 siblings, 0 replies; 54+ messages in thread
From: Zhen Lei @ 2020-10-16 9:08 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann, Florian Fainelli, Ray Jui,
Scott Branden, bcm-kernel-feedback-list, Andy Gross,
Bjorn Andersson, linux-arm-msm, devicetree, linux-arm-kernel,
linux-kernel
Cc: Zhen Lei
The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
property must have the same "#address-cells" and "#size-cells" values as
the parent node. Otherwise, the following warnings is reported:
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning \
(dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but \
its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning \
(dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but \
its #size-cells (1) differs from / (2)
Arnd Bergmann figured out why it's necessary:
Also note that the #address-cells=<1> means that any device under
this bus is assumed to only support 32-bit addressing, and DMA will
have to go through a slow swiotlb in the absence of an IOMMU.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
arch/arm64/boot/dts/qcom/ipq6018.dtsi | 72 +++++++++++++++++------------------
1 file changed, 36 insertions(+), 36 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/ipq6018.dtsi b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
index a94dac76bf3fbdd..59e0cbfa2214305 100644
--- a/arch/arm64/boot/dts/qcom/ipq6018.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
@@ -179,22 +179,22 @@
};
soc: soc {
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0 0 0xffffffff>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0 0 0 0 0x0 0xffffffff>;
dma-ranges;
compatible = "simple-bus";
prng: qrng@e1000 {
compatible = "qcom,prng-ee";
- reg = <0xe3000 0x1000>;
+ reg = <0x0 0xe3000 0x0 0x1000>;
clocks = <&gcc GCC_PRNG_AHB_CLK>;
clock-names = "core";
};
cryptobam: dma@704000 {
compatible = "qcom,bam-v1.7.0";
- reg = <0x00704000 0x20000>;
+ reg = <0x0 0x00704000 0x0 0x20000>;
interrupts = <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_CRYPTO_AHB_CLK>;
clock-names = "bam_clk";
@@ -206,7 +206,7 @@
crypto: crypto@73a000 {
compatible = "qcom,crypto-v5.1";
- reg = <0x0073a000 0x6000>;
+ reg = <0x0 0x0073a000 0x0 0x6000>;
clocks = <&gcc GCC_CRYPTO_AHB_CLK>,
<&gcc GCC_CRYPTO_AXI_CLK>,
<&gcc GCC_CRYPTO_CLK>;
@@ -217,7 +217,7 @@
tlmm: pinctrl@1000000 {
compatible = "qcom,ipq6018-pinctrl";
- reg = <0x01000000 0x300000>;
+ reg = <0x0 0x01000000 0x0 0x300000>;
interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
@@ -235,7 +235,7 @@
gcc: gcc@1800000 {
compatible = "qcom,gcc-ipq6018";
- reg = <0x01800000 0x80000>;
+ reg = <0x0 0x01800000 0x0 0x80000>;
clocks = <&xo>, <&sleep_clk>;
clock-names = "xo", "sleep_clk";
#clock-cells = <1>;
@@ -244,17 +244,17 @@
tcsr_mutex_regs: syscon@1905000 {
compatible = "syscon";
- reg = <0x01905000 0x8000>;
+ reg = <0x0 0x01905000 0x0 0x8000>;
};
tcsr_q6: syscon@1945000 {
compatible = "syscon";
- reg = <0x01945000 0xe000>;
+ reg = <0x0 0x01945000 0x0 0xe000>;
};
blsp_dma: dma@7884000 {
compatible = "qcom,bam-v1.7.0";
- reg = <0x07884000 0x2b000>;
+ reg = <0x0 0x07884000 0x0 0x2b000>;
interrupts = <GIC_SPI 238 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_BLSP1_AHB_CLK>;
clock-names = "bam_clk";
@@ -264,7 +264,7 @@
blsp1_uart3: serial@78b1000 {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
- reg = <0x078b1000 0x200>;
+ reg = <0x0 0x078b1000 0x0 0x200>;
interrupts = <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_BLSP1_UART3_APPS_CLK>,
<&gcc GCC_BLSP1_AHB_CLK>;
@@ -276,7 +276,7 @@
compatible = "qcom,spi-qup-v2.2.1";
#address-cells = <1>;
#size-cells = <0>;
- reg = <0x078b5000 0x600>;
+ reg = <0x0 0x078b5000 0x0 0x600>;
interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
spi-max-frequency = <50000000>;
clocks = <&gcc GCC_BLSP1_QUP1_SPI_APPS_CLK>,
@@ -291,7 +291,7 @@
compatible = "qcom,spi-qup-v2.2.1";
#address-cells = <1>;
#size-cells = <0>;
- reg = <0x078b6000 0x600>;
+ reg = <0x0 0x078b6000 0x0 0x600>;
interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
spi-max-frequency = <50000000>;
clocks = <&gcc GCC_BLSP1_QUP2_SPI_APPS_CLK>,
@@ -306,7 +306,7 @@
compatible = "qcom,i2c-qup-v2.2.1";
#address-cells = <1>;
#size-cells = <0>;
- reg = <0x078b6000 0x600>;
+ reg = <0x0 0x078b6000 0x0 0x600>;
interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_BLSP1_AHB_CLK>,
<&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>;
@@ -321,7 +321,7 @@
compatible = "qcom,i2c-qup-v2.2.1";
#address-cells = <1>;
#size-cells = <0>;
- reg = <0x078b7000 0x600>;
+ reg = <0x0 0x078b7000 0x0 0x600>;
interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_BLSP1_AHB_CLK>,
<&gcc GCC_BLSP1_QUP3_I2C_APPS_CLK>;
@@ -336,24 +336,24 @@
compatible = "qcom,msm-qgic2";
interrupt-controller;
#interrupt-cells = <0x3>;
- reg = <0x0b000000 0x1000>, /*GICD*/
- <0x0b002000 0x1000>, /*GICC*/
- <0x0b001000 0x1000>, /*GICH*/
- <0x0b004000 0x1000>; /*GICV*/
+ reg = <0x0 0x0b000000 0x0 0x1000>, /*GICD*/
+ <0x0 0x0b002000 0x0 0x1000>, /*GICC*/
+ <0x0 0x0b001000 0x0 0x1000>, /*GICH*/
+ <0x0 0x0b004000 0x0 0x1000>; /*GICV*/
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
};
watchdog@b017000 {
compatible = "qcom,kpss-wdt";
interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
- reg = <0x0b017000 0x40>;
+ reg = <0x0 0x0b017000 0x0 0x40>;
clocks = <&sleep_clk>;
timeout-sec = <10>;
};
apcs_glb: mailbox@b111000 {
compatible = "qcom,ipq6018-apcs-apps-global";
- reg = <0x0b111000 0x1000>;
+ reg = <0x0 0x0b111000 0x0 0x1000>;
#clock-cells = <1>;
clocks = <&a53pll>, <&xo>;
clock-names = "pll", "xo";
@@ -362,7 +362,7 @@
a53pll: clock@b116000 {
compatible = "qcom,ipq6018-a53pll";
- reg = <0x0b116000 0x40>;
+ reg = <0x0 0x0b116000 0x0 0x40>;
#clock-cells = <0>;
clocks = <&xo>;
clock-names = "xo";
@@ -377,68 +377,68 @@
};
timer@b120000 {
- #address-cells = <1>;
- #size-cells = <1>;
+ #address-cells = <2>;
+ #size-cells = <2>;
ranges;
compatible = "arm,armv7-timer-mem";
- reg = <0x0b120000 0x1000>;
+ reg = <0x0 0x0b120000 0x0 0x1000>;
clock-frequency = <19200000>;
frame@b120000 {
frame-number = <0>;
interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0b121000 0x1000>,
- <0x0b122000 0x1000>;
+ reg = <0x0 0x0b121000 0x0 0x1000>,
+ <0x0 0x0b122000 0x0 0x1000>;
};
frame@b123000 {
frame-number = <1>;
interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0xb123000 0x1000>;
+ reg = <0x0 0xb123000 0x0 0x1000>;
status = "disabled";
};
frame@b124000 {
frame-number = <2>;
interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0b124000 0x1000>;
+ reg = <0x0 0x0b124000 0x0 0x1000>;
status = "disabled";
};
frame@b125000 {
frame-number = <3>;
interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0b125000 0x1000>;
+ reg = <0x0 0x0b125000 0x0 0x1000>;
status = "disabled";
};
frame@b126000 {
frame-number = <4>;
interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0b126000 0x1000>;
+ reg = <0x0 0x0b126000 0x0 0x1000>;
status = "disabled";
};
frame@b127000 {
frame-number = <5>;
interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0b127000 0x1000>;
+ reg = <0x0 0x0b127000 0x0 0x1000>;
status = "disabled";
};
frame@b128000 {
frame-number = <6>;
interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0b128000 0x1000>;
+ reg = <0x0 0x0b128000 0x0 0x1000>;
status = "disabled";
};
};
q6v5_wcss: remoteproc@cd00000 {
compatible = "qcom,ipq8074-wcss-pil";
- reg = <0x0cd00000 0x4040>,
- <0x004ab000 0x20>;
+ reg = <0x0 0x0cd00000 0x0 0x4040>,
+ <0x0 0x004ab000 0x0 0x20>;
reg-names = "qdsp6",
"rmb";
interrupts-extended = <&intc GIC_SPI 325 IRQ_TYPE_EDGE_RISING>,
--
1.8.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
[not found] ` <CAK8P3a2TSmsNSi-XFpT6AQ3jvVxJ1AW7Uf5tAo477wtwXZwUzg@mail.gmail.com>
@ 2020-10-16 16:48 ` Florian Fainelli
0 siblings, 0 replies; 54+ messages in thread
From: Florian Fainelli @ 2020-10-16 16:48 UTC (permalink / raw)
To: Arnd Bergmann, Zhen Lei
Cc: Rob Herring, Florian Fainelli, Ray Jui, Scott Branden,
bcm-kernel-feedback-list, Andy Gross, Bjorn Andersson,
linux-arm-msm, devicetree, linux-arm-kernel, linux-kernel
On 10/16/20 4:01 AM, Arnd Bergmann wrote:
> On Fri, Oct 16, 2020 at 11:09 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>
>> The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
>> property must have the same "#address-cells" and "#size-cells" values as
>> the parent node. Otherwise, the following warnings is reported:
>>
>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
>> its #address-cells (1) differs from / (2)
>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
>> its #size-cells (1) differs from / (2)
>>
>> Arnd Bergmann figured out why it's necessary:
>> Also note that the #address-cells=<1> means that any device under
>> this bus is assumed to only support 32-bit addressing, and DMA will
>> have to go through a slow swiotlb in the absence of an IOMMU.
>>
>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> I see that at least the 'bcd' and 'xhci' devices in fact try to
> use 64-bit DMA. It would be good to test this on actual
> hardware to ensure that it works correctly when this is enabled.
>
> Ideally avoiding the swiotlb bounce buffering should only
> make it faster here, but there are many chips on which
> 64-bit DMA is broken in some form.
Is this change really an improvement though? This 'usb' pseudo bus node
could just keep being defined with #address-cells = <1> and #size-cells
= <1> so as to satisfy the 'reg' definition however we could just adjust
dma-ranges to indicate full 64-bit addressing capability. Would not that
work?
--
Florian
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2020-10-16 16:48 ` Florian Fainelli
0 siblings, 0 replies; 54+ messages in thread
From: Florian Fainelli @ 2020-10-16 16:48 UTC (permalink / raw)
To: Arnd Bergmann, Zhen Lei
Cc: devicetree, Florian Fainelli, linux-kernel, Scott Branden,
Ray Jui, Andy Gross, Bjorn Andersson, Rob Herring,
bcm-kernel-feedback-list, linux-arm-msm, linux-arm-kernel
On 10/16/20 4:01 AM, Arnd Bergmann wrote:
> On Fri, Oct 16, 2020 at 11:09 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>
>> The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
>> property must have the same "#address-cells" and "#size-cells" values as
>> the parent node. Otherwise, the following warnings is reported:
>>
>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
>> its #address-cells (1) differs from / (2)
>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
>> its #size-cells (1) differs from / (2)
>>
>> Arnd Bergmann figured out why it's necessary:
>> Also note that the #address-cells=<1> means that any device under
>> this bus is assumed to only support 32-bit addressing, and DMA will
>> have to go through a slow swiotlb in the absence of an IOMMU.
>>
>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> I see that at least the 'bcd' and 'xhci' devices in fact try to
> use 64-bit DMA. It would be good to test this on actual
> hardware to ensure that it works correctly when this is enabled.
>
> Ideally avoiding the swiotlb bounce buffering should only
> make it faster here, but there are many chips on which
> 64-bit DMA is broken in some form.
Is this change really an improvement though? This 'usb' pseudo bus node
could just keep being defined with #address-cells = <1> and #size-cells
= <1> so as to satisfy the 'reg' definition however we could just adjust
dma-ranges to indicate full 64-bit addressing capability. Would not that
work?
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
[not found] ` <CAK8P3a13ywHh7igdfDSPQz9Bw8YAnKWFLKARkk2NL5u6=6yb=w@mail.gmail.com>
@ 2020-10-16 19:27 ` Florian Fainelli
0 siblings, 0 replies; 54+ messages in thread
From: Florian Fainelli @ 2020-10-16 19:27 UTC (permalink / raw)
To: Arnd Bergmann, Florian Fainelli
Cc: Zhen Lei, Rob Herring, Ray Jui, Scott Branden,
bcm-kernel-feedback-list, Andy Gross, Bjorn Andersson,
linux-arm-msm, devicetree, linux-arm-kernel, linux-kernel
On 10/16/20 11:23 AM, Arnd Bergmann wrote:
> On Fri, Oct 16, 2020 at 6:48 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>> On 10/16/20 4:01 AM, Arnd Bergmann wrote:
>>> On Fri, Oct 16, 2020 at 11:09 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>>>
>>>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
>>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>>>
>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>>>
>>> I see that at least the 'bcd' and 'xhci' devices in fact try to
>>> use 64-bit DMA. It would be good to test this on actual
>>> hardware to ensure that it works correctly when this is enabled.
>>>
>>> Ideally avoiding the swiotlb bounce buffering should only
>>> make it faster here, but there are many chips on which
>>> 64-bit DMA is broken in some form.
>>
>> Is this change really an improvement though? This 'usb' pseudo bus node
>> could just keep being defined with #address-cells = <1> and #size-cells
>> = <1> so as to satisfy the 'reg' definition however we could just adjust
>> dma-ranges to indicate full 64-bit addressing capability. Would not that
>> work?
>
> When #address-cells is '1', you cannot specify dma-ranges that
> go beyond a 32-bit address range.
Would not it be enough to remove the 'dma-ranges' property though? Sorry
for being slow here.
--
Florian
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2020-10-16 19:27 ` Florian Fainelli
0 siblings, 0 replies; 54+ messages in thread
From: Florian Fainelli @ 2020-10-16 19:27 UTC (permalink / raw)
To: Arnd Bergmann, Florian Fainelli
Cc: devicetree, linux-kernel, Scott Branden, Ray Jui, linux-arm-msm,
Andy Gross, Bjorn Andersson, Rob Herring,
bcm-kernel-feedback-list, Zhen Lei, linux-arm-kernel
On 10/16/20 11:23 AM, Arnd Bergmann wrote:
> On Fri, Oct 16, 2020 at 6:48 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>> On 10/16/20 4:01 AM, Arnd Bergmann wrote:
>>> On Fri, Oct 16, 2020 at 11:09 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>>>
>>>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
>>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>>>
>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>>>
>>> I see that at least the 'bcd' and 'xhci' devices in fact try to
>>> use 64-bit DMA. It would be good to test this on actual
>>> hardware to ensure that it works correctly when this is enabled.
>>>
>>> Ideally avoiding the swiotlb bounce buffering should only
>>> make it faster here, but there are many chips on which
>>> 64-bit DMA is broken in some form.
>>
>> Is this change really an improvement though? This 'usb' pseudo bus node
>> could just keep being defined with #address-cells = <1> and #size-cells
>> = <1> so as to satisfy the 'reg' definition however we could just adjust
>> dma-ranges to indicate full 64-bit addressing capability. Would not that
>> work?
>
> When #address-cells is '1', you cannot specify dma-ranges that
> go beyond a 32-bit address range.
Would not it be enough to remove the 'dma-ranges' property though? Sorry
for being slow here.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2020-10-16 19:27 ` Florian Fainelli
@ 2020-10-18 2:10 ` Leizhen (ThunderTown)
-1 siblings, 0 replies; 54+ messages in thread
From: Leizhen (ThunderTown) @ 2020-10-18 2:10 UTC (permalink / raw)
To: Florian Fainelli, Arnd Bergmann
Cc: Rob Herring, Ray Jui, Scott Branden, bcm-kernel-feedback-list,
Andy Gross, Bjorn Andersson, linux-arm-msm, devicetree,
linux-arm-kernel, linux-kernel
On 2020/10/17 3:27, Florian Fainelli wrote:
> On 10/16/20 11:23 AM, Arnd Bergmann wrote:
>> On Fri, Oct 16, 2020 at 6:48 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>> On 10/16/20 4:01 AM, Arnd Bergmann wrote:
>>>> On Fri, Oct 16, 2020 at 11:09 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>>>>
>>>>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
>>>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>>>>
>>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>>>>
>>>> I see that at least the 'bcd' and 'xhci' devices in fact try to
>>>> use 64-bit DMA. It would be good to test this on actual
>>>> hardware to ensure that it works correctly when this is enabled.
>>>>
>>>> Ideally avoiding the swiotlb bounce buffering should only
>>>> make it faster here, but there are many chips on which
>>>> 64-bit DMA is broken in some form.
>>>
>>> Is this change really an improvement though? This 'usb' pseudo bus node
>>> could just keep being defined with #address-cells = <1> and #size-cells
>>> = <1> so as to satisfy the 'reg' definition however we could just adjust
>>> dma-ranges to indicate full 64-bit addressing capability. Would not that
>>> work?
>>
>> When #address-cells is '1', you cannot specify dma-ranges that
>> go beyond a 32-bit address range.
>
> Would not it be enough to remove the 'dma-ranges' property though? Sorry
> for being slow here.
Remove the 'dma-ranges' property should also work. After all, it is equivalent
to the original empty dma-ranges scheme. In addition, since the IOMMU nodes are
defined, it should be enabled. Therefore, Arnd's concern about the scenario where
the IOMMU is disabled may not be triggered. All roads lead to Rome. Which solution
should be chose depends on individual preferences. For me, either solution is fine.
The third solution is to define a non-empty dma-ranges property. However, because
stingray-usb.dtsi is included in multiple files, it may not be appropriate.
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2020-10-18 2:10 ` Leizhen (ThunderTown)
0 siblings, 0 replies; 54+ messages in thread
From: Leizhen (ThunderTown) @ 2020-10-18 2:10 UTC (permalink / raw)
To: Florian Fainelli, Arnd Bergmann
Cc: devicetree, linux-kernel, Scott Branden, Ray Jui, Andy Gross,
Bjorn Andersson, Rob Herring, bcm-kernel-feedback-list,
linux-arm-msm, linux-arm-kernel
On 2020/10/17 3:27, Florian Fainelli wrote:
> On 10/16/20 11:23 AM, Arnd Bergmann wrote:
>> On Fri, Oct 16, 2020 at 6:48 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>> On 10/16/20 4:01 AM, Arnd Bergmann wrote:
>>>> On Fri, Oct 16, 2020 at 11:09 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>>>>
>>>>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
>>>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>>>>
>>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>>>>
>>>> I see that at least the 'bcd' and 'xhci' devices in fact try to
>>>> use 64-bit DMA. It would be good to test this on actual
>>>> hardware to ensure that it works correctly when this is enabled.
>>>>
>>>> Ideally avoiding the swiotlb bounce buffering should only
>>>> make it faster here, but there are many chips on which
>>>> 64-bit DMA is broken in some form.
>>>
>>> Is this change really an improvement though? This 'usb' pseudo bus node
>>> could just keep being defined with #address-cells = <1> and #size-cells
>>> = <1> so as to satisfy the 'reg' definition however we could just adjust
>>> dma-ranges to indicate full 64-bit addressing capability. Would not that
>>> work?
>>
>> When #address-cells is '1', you cannot specify dma-ranges that
>> go beyond a 32-bit address range.
>
> Would not it be enough to remove the 'dma-ranges' property though? Sorry
> for being slow here.
Remove the 'dma-ranges' property should also work. After all, it is equivalent
to the original empty dma-ranges scheme. In addition, since the IOMMU nodes are
defined, it should be enabled. Therefore, Arnd's concern about the scenario where
the IOMMU is disabled may not be triggered. All roads lead to Rome. Which solution
should be chose depends on individual preferences. For me, either solution is fine.
The third solution is to define a non-empty dma-ranges property. However, because
stingray-usb.dtsi is included in multiple files, it may not be appropriate.
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2020-10-18 2:10 ` Leizhen (ThunderTown)
(?)
@ 2020-10-23 7:17 ` Arnd Bergmann
2020-10-26 2:21 ` Leizhen (ThunderTown)
-1 siblings, 1 reply; 54+ messages in thread
From: Arnd Bergmann @ 2020-10-23 7:17 UTC (permalink / raw)
To: Leizhen (ThunderTown)
Cc: devicetree, Florian Fainelli, Scott Branden, Ray Jui,
linux-kernel, Rob Herring, Bjorn Andersson, Andy Gross,
bcm-kernel-feedback-list, linux-arm-msm, linux-arm-kernel
On Sun, Oct 18, 2020 at 4:10 AM Leizhen (ThunderTown)
<thunder.leizhen@huawei.com> wrote:
> On 2020/10/17 3:27, Florian Fainelli wrote:
> > On 10/16/20 11:23 AM, Arnd Bergmann wrote:
> >> On Fri, Oct 16, 2020 at 6:48 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >>> On 10/16/20 4:01 AM, Arnd Bergmann wrote:
> >>>> On Fri, Oct 16, 2020 at 11:09 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
> >>>>>
> >>>>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> >>>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> >>>>
> >>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
> >>>>
> >>>> I see that at least the 'bcd' and 'xhci' devices in fact try to
> >>>> use 64-bit DMA. It would be good to test this on actual
> >>>> hardware to ensure that it works correctly when this is enabled.
> >>>>
> >>>> Ideally avoiding the swiotlb bounce buffering should only
> >>>> make it faster here, but there are many chips on which
> >>>> 64-bit DMA is broken in some form.
> >>>
> >>> Is this change really an improvement though? This 'usb' pseudo bus node
> >>> could just keep being defined with #address-cells = <1> and #size-cells
> >>> = <1> so as to satisfy the 'reg' definition however we could just adjust
> >>> dma-ranges to indicate full 64-bit addressing capability. Would not that
> >>> work?
> >>
> >> When #address-cells is '1', you cannot specify dma-ranges that
> >> go beyond a 32-bit address range.
> >
> > Would not it be enough to remove the 'dma-ranges' property though? Sorry
> > for being slow here.
>
> Remove the 'dma-ranges' property should also work. After all, it is equivalent
> to the original empty dma-ranges scheme. In addition, since the IOMMU nodes are
> defined, it should be enabled.
Are you sure? I was expecting the IOMMU not to get used here since
the devices do contain list an 'iommus' property.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2020-10-23 7:17 ` Arnd Bergmann
@ 2020-10-26 2:21 ` Leizhen (ThunderTown)
0 siblings, 0 replies; 54+ messages in thread
From: Leizhen (ThunderTown) @ 2020-10-26 2:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Florian Fainelli, Rob Herring, Ray Jui, Scott Branden,
bcm-kernel-feedback-list, Andy Gross, Bjorn Andersson,
linux-arm-msm, devicetree, linux-arm-kernel, linux-kernel
On 2020/10/23 15:17, Arnd Bergmann wrote:
> On Sun, Oct 18, 2020 at 4:10 AM Leizhen (ThunderTown)
> <thunder.leizhen@huawei.com> wrote:
>> On 2020/10/17 3:27, Florian Fainelli wrote:
>>> On 10/16/20 11:23 AM, Arnd Bergmann wrote:
>>>> On Fri, Oct 16, 2020 at 6:48 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>>> On 10/16/20 4:01 AM, Arnd Bergmann wrote:
>>>>>> On Fri, Oct 16, 2020 at 11:09 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>>>>>>
>>>>>>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
>>>>>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>>>>>>
>>>>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>>>>>>
>>>>>> I see that at least the 'bcd' and 'xhci' devices in fact try to
>>>>>> use 64-bit DMA. It would be good to test this on actual
>>>>>> hardware to ensure that it works correctly when this is enabled.
>>>>>>
>>>>>> Ideally avoiding the swiotlb bounce buffering should only
>>>>>> make it faster here, but there are many chips on which
>>>>>> 64-bit DMA is broken in some form.
>>>>>
>>>>> Is this change really an improvement though? This 'usb' pseudo bus node
>>>>> could just keep being defined with #address-cells = <1> and #size-cells
>>>>> = <1> so as to satisfy the 'reg' definition however we could just adjust
>>>>> dma-ranges to indicate full 64-bit addressing capability. Would not that
>>>>> work?
>>>>
>>>> When #address-cells is '1', you cannot specify dma-ranges that
>>>> go beyond a 32-bit address range.
>>>
>>> Would not it be enough to remove the 'dma-ranges' property though? Sorry
>>> for being slow here.
>>
>> Remove the 'dma-ranges' property should also work. After all, it is equivalent
>> to the original empty dma-ranges scheme. In addition, since the IOMMU nodes are
>> defined, it should be enabled.
>
> Are you sure? I was expecting the IOMMU not to get used here since
> the devices do contain list an 'iommus' property.
OK，If the SMMU maybe disabled, then your proposal is necessary.
>
> Arnd
>
> .
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2020-10-26 2:21 ` Leizhen (ThunderTown)
0 siblings, 0 replies; 54+ messages in thread
From: Leizhen (ThunderTown) @ 2020-10-26 2:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree, Florian Fainelli, Scott Branden, Ray Jui,
linux-kernel, Rob Herring, Bjorn Andersson, Andy Gross,
bcm-kernel-feedback-list, linux-arm-msm, linux-arm-kernel
On 2020/10/23 15:17, Arnd Bergmann wrote:
> On Sun, Oct 18, 2020 at 4:10 AM Leizhen (ThunderTown)
> <thunder.leizhen@huawei.com> wrote:
>> On 2020/10/17 3:27, Florian Fainelli wrote:
>>> On 10/16/20 11:23 AM, Arnd Bergmann wrote:
>>>> On Fri, Oct 16, 2020 at 6:48 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>>> On 10/16/20 4:01 AM, Arnd Bergmann wrote:
>>>>>> On Fri, Oct 16, 2020 at 11:09 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>>>>>>
>>>>>>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
>>>>>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>>>>>>
>>>>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>>>>>>
>>>>>> I see that at least the 'bcd' and 'xhci' devices in fact try to
>>>>>> use 64-bit DMA. It would be good to test this on actual
>>>>>> hardware to ensure that it works correctly when this is enabled.
>>>>>>
>>>>>> Ideally avoiding the swiotlb bounce buffering should only
>>>>>> make it faster here, but there are many chips on which
>>>>>> 64-bit DMA is broken in some form.
>>>>>
>>>>> Is this change really an improvement though? This 'usb' pseudo bus node
>>>>> could just keep being defined with #address-cells = <1> and #size-cells
>>>>> = <1> so as to satisfy the 'reg' definition however we could just adjust
>>>>> dma-ranges to indicate full 64-bit addressing capability. Would not that
>>>>> work?
>>>>
>>>> When #address-cells is '1', you cannot specify dma-ranges that
>>>> go beyond a 32-bit address range.
>>>
>>> Would not it be enough to remove the 'dma-ranges' property though? Sorry
>>> for being slow here.
>>
>> Remove the 'dma-ranges' property should also work. After all, it is equivalent
>> to the original empty dma-ranges scheme. In addition, since the IOMMU nodes are
>> defined, it should be enabled.
>
> Are you sure? I was expecting the IOMMU not to get used here since
> the devices do contain list an 'iommus' property.
OK，If the SMMU maybe disabled, then your proposal is necessary.
>
> Arnd
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2020-10-26 2:21 ` Leizhen (ThunderTown)
@ 2020-11-09 6:18 ` Leizhen (ThunderTown)
-1 siblings, 0 replies; 54+ messages in thread
From: Leizhen (ThunderTown) @ 2020-11-09 6:18 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Florian Fainelli, Rob Herring, Ray Jui, Scott Branden,
bcm-kernel-feedback-list, Andy Gross, Bjorn Andersson,
linux-arm-msm, devicetree, linux-arm-kernel, linux-kernel
Hi, everybody:
How do we deal with this problem? I updated the kernel to the latest and the problem still persists.
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j24 dtbs 2>err.txt
vim err.txt
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
On 2020/10/26 10:21, Leizhen (ThunderTown) wrote:
>
>
> On 2020/10/23 15:17, Arnd Bergmann wrote:
>> On Sun, Oct 18, 2020 at 4:10 AM Leizhen (ThunderTown)
>> <thunder.leizhen@huawei.com> wrote:
>>> On 2020/10/17 3:27, Florian Fainelli wrote:
>>>> On 10/16/20 11:23 AM, Arnd Bergmann wrote:
>>>>> On Fri, Oct 16, 2020 at 6:48 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>>>> On 10/16/20 4:01 AM, Arnd Bergmann wrote:
>>>>>>> On Fri, Oct 16, 2020 at 11:09 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>>>>>>>
>>>>>>>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
>>>>>>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>>>>>>>
>>>>>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>>>>>>>
>>>>>>> I see that at least the 'bcd' and 'xhci' devices in fact try to
>>>>>>> use 64-bit DMA. It would be good to test this on actual
>>>>>>> hardware to ensure that it works correctly when this is enabled.
>>>>>>>
>>>>>>> Ideally avoiding the swiotlb bounce buffering should only
>>>>>>> make it faster here, but there are many chips on which
>>>>>>> 64-bit DMA is broken in some form.
>>>>>>
>>>>>> Is this change really an improvement though? This 'usb' pseudo bus node
>>>>>> could just keep being defined with #address-cells = <1> and #size-cells
>>>>>> = <1> so as to satisfy the 'reg' definition however we could just adjust
>>>>>> dma-ranges to indicate full 64-bit addressing capability. Would not that
>>>>>> work?
>>>>>
>>>>> When #address-cells is '1', you cannot specify dma-ranges that
>>>>> go beyond a 32-bit address range.
>>>>
>>>> Would not it be enough to remove the 'dma-ranges' property though? Sorry
>>>> for being slow here.
>>>
>>> Remove the 'dma-ranges' property should also work. After all, it is equivalent
>>> to the original empty dma-ranges scheme. In addition, since the IOMMU nodes are
>>> defined, it should be enabled.
>>
>> Are you sure? I was expecting the IOMMU not to get used here since
>> the devices do contain list an 'iommus' property.
>
> OK，If the SMMU maybe disabled, then your proposal is necessary.
>
>>
>> Arnd
>>
>> .
>>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2020-11-09 6:18 ` Leizhen (ThunderTown)
0 siblings, 0 replies; 54+ messages in thread
From: Leizhen (ThunderTown) @ 2020-11-09 6:18 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree, Florian Fainelli, Scott Branden, Ray Jui,
linux-kernel, Rob Herring, Bjorn Andersson, Andy Gross,
bcm-kernel-feedback-list, linux-arm-msm, linux-arm-kernel
Hi, everybody:
How do we deal with this problem? I updated the kernel to the latest and the problem still persists.
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j24 dtbs 2>err.txt
vim err.txt
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
On 2020/10/26 10:21, Leizhen (ThunderTown) wrote:
>
>
> On 2020/10/23 15:17, Arnd Bergmann wrote:
>> On Sun, Oct 18, 2020 at 4:10 AM Leizhen (ThunderTown)
>> <thunder.leizhen@huawei.com> wrote:
>>> On 2020/10/17 3:27, Florian Fainelli wrote:
>>>> On 10/16/20 11:23 AM, Arnd Bergmann wrote:
>>>>> On Fri, Oct 16, 2020 at 6:48 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>>>> On 10/16/20 4:01 AM, Arnd Bergmann wrote:
>>>>>>> On Fri, Oct 16, 2020 at 11:09 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>>>>>>>
>>>>>>>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
>>>>>>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>>>>>>>
>>>>>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>>>>>>>
>>>>>>> I see that at least the 'bcd' and 'xhci' devices in fact try to
>>>>>>> use 64-bit DMA. It would be good to test this on actual
>>>>>>> hardware to ensure that it works correctly when this is enabled.
>>>>>>>
>>>>>>> Ideally avoiding the swiotlb bounce buffering should only
>>>>>>> make it faster here, but there are many chips on which
>>>>>>> 64-bit DMA is broken in some form.
>>>>>>
>>>>>> Is this change really an improvement though? This 'usb' pseudo bus node
>>>>>> could just keep being defined with #address-cells = <1> and #size-cells
>>>>>> = <1> so as to satisfy the 'reg' definition however we could just adjust
>>>>>> dma-ranges to indicate full 64-bit addressing capability. Would not that
>>>>>> work?
>>>>>
>>>>> When #address-cells is '1', you cannot specify dma-ranges that
>>>>> go beyond a 32-bit address range.
>>>>
>>>> Would not it be enough to remove the 'dma-ranges' property though? Sorry
>>>> for being slow here.
>>>
>>> Remove the 'dma-ranges' property should also work. After all, it is equivalent
>>> to the original empty dma-ranges scheme. In addition, since the IOMMU nodes are
>>> defined, it should be enabled.
>>
>> Are you sure? I was expecting the IOMMU not to get used here since
>> the devices do contain list an 'iommus' property.
>
> OK，If the SMMU maybe disabled, then your proposal is necessary.
>
>>
>> Arnd
>>
>> .
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2020-11-09 6:18 ` Leizhen (ThunderTown)
@ 2020-11-09 17:28 ` Florian Fainelli
-1 siblings, 0 replies; 54+ messages in thread
From: Florian Fainelli @ 2020-11-09 17:28 UTC (permalink / raw)
To: Leizhen (ThunderTown), Arnd Bergmann
Cc: Florian Fainelli, Rob Herring, Ray Jui, Scott Branden,
bcm-kernel-feedback-list, Andy Gross, Bjorn Andersson,
linux-arm-msm, devicetree, linux-arm-kernel, linux-kernel
On 11/8/20 10:18 PM, Leizhen (ThunderTown) wrote:
> Hi, everybody:
> How do we deal with this problem? I updated the kernel to the latest and the problem still persists.
>
> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j24 dtbs 2>err.txt
> vim err.txt
>
> arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
> arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
I was hoping that Ray or Scott could give this a try, and TBH, I am
still not a big fan of having to mangle the 'reg' property to be
compatible with #address-cells = <2> and #size-cells = <2>, I would have
preferred omitting the 'dma-ranges' property entirely.
We have plenty of time to get this patch applied for v5.11.
--
Florian
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2020-11-09 17:28 ` Florian Fainelli
0 siblings, 0 replies; 54+ messages in thread
From: Florian Fainelli @ 2020-11-09 17:28 UTC (permalink / raw)
To: Leizhen (ThunderTown), Arnd Bergmann
Cc: devicetree, Florian Fainelli, Scott Branden, Ray Jui,
linux-kernel, Rob Herring, Bjorn Andersson, Andy Gross,
bcm-kernel-feedback-list, linux-arm-msm, linux-arm-kernel
On 11/8/20 10:18 PM, Leizhen (ThunderTown) wrote:
> Hi, everybody:
> How do we deal with this problem? I updated the kernel to the latest and the problem still persists.
>
> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j24 dtbs 2>err.txt
> vim err.txt
>
> arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
> arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
I was hoping that Ray or Scott could give this a try, and TBH, I am
still not a big fan of having to mangle the 'reg' property to be
compatible with #address-cells = <2> and #size-cells = <2>, I would have
preferred omitting the 'dma-ranges' property entirely.
We have plenty of time to get this patch applied for v5.11.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2020-11-09 17:28 ` Florian Fainelli
@ 2020-11-09 17:56 ` Arnd Bergmann
-1 siblings, 0 replies; 54+ messages in thread
From: Arnd Bergmann @ 2020-11-09 17:56 UTC (permalink / raw)
To: Florian Fainelli
Cc: Leizhen (ThunderTown),
Rob Herring, Ray Jui, Scott Branden, bcm-kernel-feedback-list,
Andy Gross, Bjorn Andersson, linux-arm-msm, devicetree,
linux-arm-kernel, linux-kernel
On Mon, Nov 9, 2020 at 6:30 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 11/8/20 10:18 PM, Leizhen (ThunderTown) wrote:
> > Hi, everybody:
> > How do we deal with this problem? I updated the kernel to the latest and the problem still persists.
> >
> > make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j24 dtbs 2>err.txt
> > vim err.txt
> >
> > arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
> > arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
> > arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
> > arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
> > arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
> > arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
> > arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
> > arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
>
> I was hoping that Ray or Scott could give this a try, and TBH, I am
> still not a big fan of having to mangle the 'reg' property to be
> compatible with #address-cells = <2> and #size-cells = <2>, I would have
> preferred omitting the 'dma-ranges' property entirely.
>
> We have plenty of time to get this patch applied for v5.11.
I would much prefer to get the warning fixed for v5.10, once we know what the
hardware can or cannot actually do, as it is one of the warnings that shows
up in every kernelci build.
Arnd
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2020-11-09 17:56 ` Arnd Bergmann
0 siblings, 0 replies; 54+ messages in thread
From: Arnd Bergmann @ 2020-11-09 17:56 UTC (permalink / raw)
To: Florian Fainelli
Cc: devicetree, linux-kernel, Scott Branden, Ray Jui, linux-arm-msm,
Andy Gross, Bjorn Andersson, Rob Herring,
bcm-kernel-feedback-list, Leizhen (ThunderTown),
linux-arm-kernel
On Mon, Nov 9, 2020 at 6:30 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 11/8/20 10:18 PM, Leizhen (ThunderTown) wrote:
> > Hi, everybody:
> > How do we deal with this problem? I updated the kernel to the latest and the problem still persists.
> >
> > make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j24 dtbs 2>err.txt
> > vim err.txt
> >
> > arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
> > arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
> > arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
> > arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
> > arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
> > arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
> > arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
> > arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
>
> I was hoping that Ray or Scott could give this a try, and TBH, I am
> still not a big fan of having to mangle the 'reg' property to be
> compatible with #address-cells = <2> and #size-cells = <2>, I would have
> preferred omitting the 'dma-ranges' property entirely.
>
> We have plenty of time to get this patch applied for v5.11.
I would much prefer to get the warning fixed for v5.10, once we know what the
hardware can or cannot actually do, as it is one of the warnings that shows
up in every kernelci build.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2020-11-09 17:56 ` Arnd Bergmann
@ 2020-11-09 18:00 ` Florian Fainelli
-1 siblings, 0 replies; 54+ messages in thread
From: Florian Fainelli @ 2020-11-09 18:00 UTC (permalink / raw)
To: Arnd Bergmann, Florian Fainelli
Cc: Leizhen (ThunderTown),
Rob Herring, Ray Jui, Scott Branden, bcm-kernel-feedback-list,
Andy Gross, Bjorn Andersson, linux-arm-msm, devicetree,
linux-arm-kernel, linux-kernel
On 11/9/20 9:56 AM, Arnd Bergmann wrote:
> On Mon, Nov 9, 2020 at 6:30 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> On 11/8/20 10:18 PM, Leizhen (ThunderTown) wrote:
>>> Hi, everybody:
>>> How do we deal with this problem? I updated the kernel to the latest and the problem still persists.
>>>
>>> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j24 dtbs 2>err.txt
>>> vim err.txt
>>>
>>> arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
>>> arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
>>
>> I was hoping that Ray or Scott could give this a try, and TBH, I am
>> still not a big fan of having to mangle the 'reg' property to be
>> compatible with #address-cells = <2> and #size-cells = <2>, I would have
>> preferred omitting the 'dma-ranges' property entirely.
>>
>> We have plenty of time to get this patch applied for v5.11.
>
> I would much prefer to get the warning fixed for v5.10, once we know what the
> hardware can or cannot actually do, as it is one of the warnings that shows
> up in every kernelci build.
OK, in that case:
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
feel free to pick those patches directly for 5.10 fixes. Thanks!
--
Florian
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2020-11-09 18:00 ` Florian Fainelli
0 siblings, 0 replies; 54+ messages in thread
From: Florian Fainelli @ 2020-11-09 18:00 UTC (permalink / raw)
To: Arnd Bergmann, Florian Fainelli
Cc: devicetree, linux-kernel, Scott Branden, Ray Jui, linux-arm-msm,
Andy Gross, Bjorn Andersson, Rob Herring,
bcm-kernel-feedback-list, Leizhen (ThunderTown),
linux-arm-kernel
On 11/9/20 9:56 AM, Arnd Bergmann wrote:
> On Mon, Nov 9, 2020 at 6:30 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> On 11/8/20 10:18 PM, Leizhen (ThunderTown) wrote:
>>> Hi, everybody:
>>> How do we deal with this problem? I updated the kernel to the latest and the problem still persists.
>>>
>>> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j24 dtbs 2>err.txt
>>> vim err.txt
>>>
>>> arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
>>> arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #address-cells (1) differs from / (2)
>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2)
>>
>> I was hoping that Ray or Scott could give this a try, and TBH, I am
>> still not a big fan of having to mangle the 'reg' property to be
>> compatible with #address-cells = <2> and #size-cells = <2>, I would have
>> preferred omitting the 'dma-ranges' property entirely.
>>
>> We have plenty of time to get this patch applied for v5.11.
>
> I would much prefer to get the warning fixed for v5.10, once we know what the
> hardware can or cannot actually do, as it is one of the warnings that shows
> up in every kernelci build.
OK, in that case:
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
feel free to pick those patches directly for 5.10 fixes. Thanks!
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 2/2] arm64: dts: qcom: clear the warnings caused by empty dma-ranges
2020-10-16 9:08 ` Zhen Lei
@ 2020-11-11 4:44 ` Bjorn Andersson
-1 siblings, 0 replies; 54+ messages in thread
From: Bjorn Andersson @ 2020-11-11 4:44 UTC (permalink / raw)
To: Zhen Lei
Cc: Rob Herring, Arnd Bergmann, Florian Fainelli, Ray Jui,
Scott Branden, bcm-kernel-feedback-list, Andy Gross,
linux-arm-msm, devicetree, linux-arm-kernel, linux-kernel
On Fri 16 Oct 04:08 CDT 2020, Zhen Lei wrote:
> The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
> property must have the same "#address-cells" and "#size-cells" values as
> the parent node. Otherwise, the following warnings is reported:
>
> arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning \
> (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but \
> its #address-cells (1) differs from / (2)
> arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning \
> (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but \
> its #size-cells (1) differs from / (2)
>
> Arnd Bergmann figured out why it's necessary:
> Also note that the #address-cells=<1> means that any device under
> this bus is assumed to only support 32-bit addressing, and DMA will
> have to go through a slow swiotlb in the absence of an IOMMU.
>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Thanks for fixing this up Zhen!
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
and applied for 5.11.
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/ipq6018.dtsi | 72 +++++++++++++++++------------------
> 1 file changed, 36 insertions(+), 36 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/ipq6018.dtsi b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
> index a94dac76bf3fbdd..59e0cbfa2214305 100644
> --- a/arch/arm64/boot/dts/qcom/ipq6018.dtsi
> +++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
> @@ -179,22 +179,22 @@
> };
>
> soc: soc {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - ranges = <0 0 0 0xffffffff>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0 0 0 0 0x0 0xffffffff>;
> dma-ranges;
> compatible = "simple-bus";
>
> prng: qrng@e1000 {
> compatible = "qcom,prng-ee";
> - reg = <0xe3000 0x1000>;
> + reg = <0x0 0xe3000 0x0 0x1000>;
> clocks = <&gcc GCC_PRNG_AHB_CLK>;
> clock-names = "core";
> };
>
> cryptobam: dma@704000 {
> compatible = "qcom,bam-v1.7.0";
> - reg = <0x00704000 0x20000>;
> + reg = <0x0 0x00704000 0x0 0x20000>;
> interrupts = <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&gcc GCC_CRYPTO_AHB_CLK>;
> clock-names = "bam_clk";
> @@ -206,7 +206,7 @@
>
> crypto: crypto@73a000 {
> compatible = "qcom,crypto-v5.1";
> - reg = <0x0073a000 0x6000>;
> + reg = <0x0 0x0073a000 0x0 0x6000>;
> clocks = <&gcc GCC_CRYPTO_AHB_CLK>,
> <&gcc GCC_CRYPTO_AXI_CLK>,
> <&gcc GCC_CRYPTO_CLK>;
> @@ -217,7 +217,7 @@
>
> tlmm: pinctrl@1000000 {
> compatible = "qcom,ipq6018-pinctrl";
> - reg = <0x01000000 0x300000>;
> + reg = <0x0 0x01000000 0x0 0x300000>;
> interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
> gpio-controller;
> #gpio-cells = <2>;
> @@ -235,7 +235,7 @@
>
> gcc: gcc@1800000 {
> compatible = "qcom,gcc-ipq6018";
> - reg = <0x01800000 0x80000>;
> + reg = <0x0 0x01800000 0x0 0x80000>;
> clocks = <&xo>, <&sleep_clk>;
> clock-names = "xo", "sleep_clk";
> #clock-cells = <1>;
> @@ -244,17 +244,17 @@
>
> tcsr_mutex_regs: syscon@1905000 {
> compatible = "syscon";
> - reg = <0x01905000 0x8000>;
> + reg = <0x0 0x01905000 0x0 0x8000>;
> };
>
> tcsr_q6: syscon@1945000 {
> compatible = "syscon";
> - reg = <0x01945000 0xe000>;
> + reg = <0x0 0x01945000 0x0 0xe000>;
> };
>
> blsp_dma: dma@7884000 {
> compatible = "qcom,bam-v1.7.0";
> - reg = <0x07884000 0x2b000>;
> + reg = <0x0 0x07884000 0x0 0x2b000>;
> interrupts = <GIC_SPI 238 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&gcc GCC_BLSP1_AHB_CLK>;
> clock-names = "bam_clk";
> @@ -264,7 +264,7 @@
>
> blsp1_uart3: serial@78b1000 {
> compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
> - reg = <0x078b1000 0x200>;
> + reg = <0x0 0x078b1000 0x0 0x200>;
> interrupts = <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&gcc GCC_BLSP1_UART3_APPS_CLK>,
> <&gcc GCC_BLSP1_AHB_CLK>;
> @@ -276,7 +276,7 @@
> compatible = "qcom,spi-qup-v2.2.1";
> #address-cells = <1>;
> #size-cells = <0>;
> - reg = <0x078b5000 0x600>;
> + reg = <0x0 0x078b5000 0x0 0x600>;
> interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
> spi-max-frequency = <50000000>;
> clocks = <&gcc GCC_BLSP1_QUP1_SPI_APPS_CLK>,
> @@ -291,7 +291,7 @@
> compatible = "qcom,spi-qup-v2.2.1";
> #address-cells = <1>;
> #size-cells = <0>;
> - reg = <0x078b6000 0x600>;
> + reg = <0x0 0x078b6000 0x0 0x600>;
> interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
> spi-max-frequency = <50000000>;
> clocks = <&gcc GCC_BLSP1_QUP2_SPI_APPS_CLK>,
> @@ -306,7 +306,7 @@
> compatible = "qcom,i2c-qup-v2.2.1";
> #address-cells = <1>;
> #size-cells = <0>;
> - reg = <0x078b6000 0x600>;
> + reg = <0x0 0x078b6000 0x0 0x600>;
> interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&gcc GCC_BLSP1_AHB_CLK>,
> <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>;
> @@ -321,7 +321,7 @@
> compatible = "qcom,i2c-qup-v2.2.1";
> #address-cells = <1>;
> #size-cells = <0>;
> - reg = <0x078b7000 0x600>;
> + reg = <0x0 0x078b7000 0x0 0x600>;
> interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&gcc GCC_BLSP1_AHB_CLK>,
> <&gcc GCC_BLSP1_QUP3_I2C_APPS_CLK>;
> @@ -336,24 +336,24 @@
> compatible = "qcom,msm-qgic2";
> interrupt-controller;
> #interrupt-cells = <0x3>;
> - reg = <0x0b000000 0x1000>, /*GICD*/
> - <0x0b002000 0x1000>, /*GICC*/
> - <0x0b001000 0x1000>, /*GICH*/
> - <0x0b004000 0x1000>; /*GICV*/
> + reg = <0x0 0x0b000000 0x0 0x1000>, /*GICD*/
> + <0x0 0x0b002000 0x0 0x1000>, /*GICC*/
> + <0x0 0x0b001000 0x0 0x1000>, /*GICH*/
> + <0x0 0x0b004000 0x0 0x1000>; /*GICV*/
> interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> watchdog@b017000 {
> compatible = "qcom,kpss-wdt";
> interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
> - reg = <0x0b017000 0x40>;
> + reg = <0x0 0x0b017000 0x0 0x40>;
> clocks = <&sleep_clk>;
> timeout-sec = <10>;
> };
>
> apcs_glb: mailbox@b111000 {
> compatible = "qcom,ipq6018-apcs-apps-global";
> - reg = <0x0b111000 0x1000>;
> + reg = <0x0 0x0b111000 0x0 0x1000>;
> #clock-cells = <1>;
> clocks = <&a53pll>, <&xo>;
> clock-names = "pll", "xo";
> @@ -362,7 +362,7 @@
>
> a53pll: clock@b116000 {
> compatible = "qcom,ipq6018-a53pll";
> - reg = <0x0b116000 0x40>;
> + reg = <0x0 0x0b116000 0x0 0x40>;
> #clock-cells = <0>;
> clocks = <&xo>;
> clock-names = "xo";
> @@ -377,68 +377,68 @@
> };
>
> timer@b120000 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> ranges;
> compatible = "arm,armv7-timer-mem";
> - reg = <0x0b120000 0x1000>;
> + reg = <0x0 0x0b120000 0x0 0x1000>;
> clock-frequency = <19200000>;
>
> frame@b120000 {
> frame-number = <0>;
> interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
> - reg = <0x0b121000 0x1000>,
> - <0x0b122000 0x1000>;
> + reg = <0x0 0x0b121000 0x0 0x1000>,
> + <0x0 0x0b122000 0x0 0x1000>;
> };
>
> frame@b123000 {
> frame-number = <1>;
> interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
> - reg = <0xb123000 0x1000>;
> + reg = <0x0 0xb123000 0x0 0x1000>;
> status = "disabled";
> };
>
> frame@b124000 {
> frame-number = <2>;
> interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
> - reg = <0x0b124000 0x1000>;
> + reg = <0x0 0x0b124000 0x0 0x1000>;
> status = "disabled";
> };
>
> frame@b125000 {
> frame-number = <3>;
> interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
> - reg = <0x0b125000 0x1000>;
> + reg = <0x0 0x0b125000 0x0 0x1000>;
> status = "disabled";
> };
>
> frame@b126000 {
> frame-number = <4>;
> interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
> - reg = <0x0b126000 0x1000>;
> + reg = <0x0 0x0b126000 0x0 0x1000>;
> status = "disabled";
> };
>
> frame@b127000 {
> frame-number = <5>;
> interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
> - reg = <0x0b127000 0x1000>;
> + reg = <0x0 0x0b127000 0x0 0x1000>;
> status = "disabled";
> };
>
> frame@b128000 {
> frame-number = <6>;
> interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
> - reg = <0x0b128000 0x1000>;
> + reg = <0x0 0x0b128000 0x0 0x1000>;
> status = "disabled";
> };
> };
>
> q6v5_wcss: remoteproc@cd00000 {
> compatible = "qcom,ipq8074-wcss-pil";
> - reg = <0x0cd00000 0x4040>,
> - <0x004ab000 0x20>;
> + reg = <0x0 0x0cd00000 0x0 0x4040>,
> + <0x0 0x004ab000 0x0 0x20>;
> reg-names = "qdsp6",
> "rmb";
> interrupts-extended = <&intc GIC_SPI 325 IRQ_TYPE_EDGE_RISING>,
> --
> 1.8.3
>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 2/2] arm64: dts: qcom: clear the warnings caused by empty dma-ranges
@ 2020-11-11 4:44 ` Bjorn Andersson
0 siblings, 0 replies; 54+ messages in thread
From: Bjorn Andersson @ 2020-11-11 4:44 UTC (permalink / raw)
To: Zhen Lei
Cc: devicetree, Florian Fainelli, Arnd Bergmann, Scott Branden,
Ray Jui, Andy Gross, linux-kernel, Rob Herring,
bcm-kernel-feedback-list, linux-arm-msm, linux-arm-kernel
On Fri 16 Oct 04:08 CDT 2020, Zhen Lei wrote:
> The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
> property must have the same "#address-cells" and "#size-cells" values as
> the parent node. Otherwise, the following warnings is reported:
>
> arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning \
> (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but \
> its #address-cells (1) differs from / (2)
> arch/arm64/boot/dts/qcom/ipq6018.dtsi:185.3-14: Warning \
> (dma_ranges_format): /soc:dma-ranges: empty "dma-ranges" property but \
> its #size-cells (1) differs from / (2)
>
> Arnd Bergmann figured out why it's necessary:
> Also note that the #address-cells=<1> means that any device under
> this bus is assumed to only support 32-bit addressing, and DMA will
> have to go through a slow swiotlb in the absence of an IOMMU.
>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Thanks for fixing this up Zhen!
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
and applied for 5.11.
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/ipq6018.dtsi | 72 +++++++++++++++++------------------
> 1 file changed, 36 insertions(+), 36 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/ipq6018.dtsi b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
> index a94dac76bf3fbdd..59e0cbfa2214305 100644
> --- a/arch/arm64/boot/dts/qcom/ipq6018.dtsi
> +++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
> @@ -179,22 +179,22 @@
> };
>
> soc: soc {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - ranges = <0 0 0 0xffffffff>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0 0 0 0 0x0 0xffffffff>;
> dma-ranges;
> compatible = "simple-bus";
>
> prng: qrng@e1000 {
> compatible = "qcom,prng-ee";
> - reg = <0xe3000 0x1000>;
> + reg = <0x0 0xe3000 0x0 0x1000>;
> clocks = <&gcc GCC_PRNG_AHB_CLK>;
> clock-names = "core";
> };
>
> cryptobam: dma@704000 {
> compatible = "qcom,bam-v1.7.0";
> - reg = <0x00704000 0x20000>;
> + reg = <0x0 0x00704000 0x0 0x20000>;
> interrupts = <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&gcc GCC_CRYPTO_AHB_CLK>;
> clock-names = "bam_clk";
> @@ -206,7 +206,7 @@
>
> crypto: crypto@73a000 {
> compatible = "qcom,crypto-v5.1";
> - reg = <0x0073a000 0x6000>;
> + reg = <0x0 0x0073a000 0x0 0x6000>;
> clocks = <&gcc GCC_CRYPTO_AHB_CLK>,
> <&gcc GCC_CRYPTO_AXI_CLK>,
> <&gcc GCC_CRYPTO_CLK>;
> @@ -217,7 +217,7 @@
>
> tlmm: pinctrl@1000000 {
> compatible = "qcom,ipq6018-pinctrl";
> - reg = <0x01000000 0x300000>;
> + reg = <0x0 0x01000000 0x0 0x300000>;
> interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
> gpio-controller;
> #gpio-cells = <2>;
> @@ -235,7 +235,7 @@
>
> gcc: gcc@1800000 {
> compatible = "qcom,gcc-ipq6018";
> - reg = <0x01800000 0x80000>;
> + reg = <0x0 0x01800000 0x0 0x80000>;
> clocks = <&xo>, <&sleep_clk>;
> clock-names = "xo", "sleep_clk";
> #clock-cells = <1>;
> @@ -244,17 +244,17 @@
>
> tcsr_mutex_regs: syscon@1905000 {
> compatible = "syscon";
> - reg = <0x01905000 0x8000>;
> + reg = <0x0 0x01905000 0x0 0x8000>;
> };
>
> tcsr_q6: syscon@1945000 {
> compatible = "syscon";
> - reg = <0x01945000 0xe000>;
> + reg = <0x0 0x01945000 0x0 0xe000>;
> };
>
> blsp_dma: dma@7884000 {
> compatible = "qcom,bam-v1.7.0";
> - reg = <0x07884000 0x2b000>;
> + reg = <0x0 0x07884000 0x0 0x2b000>;
> interrupts = <GIC_SPI 238 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&gcc GCC_BLSP1_AHB_CLK>;
> clock-names = "bam_clk";
> @@ -264,7 +264,7 @@
>
> blsp1_uart3: serial@78b1000 {
> compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
> - reg = <0x078b1000 0x200>;
> + reg = <0x0 0x078b1000 0x0 0x200>;
> interrupts = <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&gcc GCC_BLSP1_UART3_APPS_CLK>,
> <&gcc GCC_BLSP1_AHB_CLK>;
> @@ -276,7 +276,7 @@
> compatible = "qcom,spi-qup-v2.2.1";
> #address-cells = <1>;
> #size-cells = <0>;
> - reg = <0x078b5000 0x600>;
> + reg = <0x0 0x078b5000 0x0 0x600>;
> interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
> spi-max-frequency = <50000000>;
> clocks = <&gcc GCC_BLSP1_QUP1_SPI_APPS_CLK>,
> @@ -291,7 +291,7 @@
> compatible = "qcom,spi-qup-v2.2.1";
> #address-cells = <1>;
> #size-cells = <0>;
> - reg = <0x078b6000 0x600>;
> + reg = <0x0 0x078b6000 0x0 0x600>;
> interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
> spi-max-frequency = <50000000>;
> clocks = <&gcc GCC_BLSP1_QUP2_SPI_APPS_CLK>,
> @@ -306,7 +306,7 @@
> compatible = "qcom,i2c-qup-v2.2.1";
> #address-cells = <1>;
> #size-cells = <0>;
> - reg = <0x078b6000 0x600>;
> + reg = <0x0 0x078b6000 0x0 0x600>;
> interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&gcc GCC_BLSP1_AHB_CLK>,
> <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>;
> @@ -321,7 +321,7 @@
> compatible = "qcom,i2c-qup-v2.2.1";
> #address-cells = <1>;
> #size-cells = <0>;
> - reg = <0x078b7000 0x600>;
> + reg = <0x0 0x078b7000 0x0 0x600>;
> interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&gcc GCC_BLSP1_AHB_CLK>,
> <&gcc GCC_BLSP1_QUP3_I2C_APPS_CLK>;
> @@ -336,24 +336,24 @@
> compatible = "qcom,msm-qgic2";
> interrupt-controller;
> #interrupt-cells = <0x3>;
> - reg = <0x0b000000 0x1000>, /*GICD*/
> - <0x0b002000 0x1000>, /*GICC*/
> - <0x0b001000 0x1000>, /*GICH*/
> - <0x0b004000 0x1000>; /*GICV*/
> + reg = <0x0 0x0b000000 0x0 0x1000>, /*GICD*/
> + <0x0 0x0b002000 0x0 0x1000>, /*GICC*/
> + <0x0 0x0b001000 0x0 0x1000>, /*GICH*/
> + <0x0 0x0b004000 0x0 0x1000>; /*GICV*/
> interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> watchdog@b017000 {
> compatible = "qcom,kpss-wdt";
> interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
> - reg = <0x0b017000 0x40>;
> + reg = <0x0 0x0b017000 0x0 0x40>;
> clocks = <&sleep_clk>;
> timeout-sec = <10>;
> };
>
> apcs_glb: mailbox@b111000 {
> compatible = "qcom,ipq6018-apcs-apps-global";
> - reg = <0x0b111000 0x1000>;
> + reg = <0x0 0x0b111000 0x0 0x1000>;
> #clock-cells = <1>;
> clocks = <&a53pll>, <&xo>;
> clock-names = "pll", "xo";
> @@ -362,7 +362,7 @@
>
> a53pll: clock@b116000 {
> compatible = "qcom,ipq6018-a53pll";
> - reg = <0x0b116000 0x40>;
> + reg = <0x0 0x0b116000 0x0 0x40>;
> #clock-cells = <0>;
> clocks = <&xo>;
> clock-names = "xo";
> @@ -377,68 +377,68 @@
> };
>
> timer@b120000 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> ranges;
> compatible = "arm,armv7-timer-mem";
> - reg = <0x0b120000 0x1000>;
> + reg = <0x0 0x0b120000 0x0 0x1000>;
> clock-frequency = <19200000>;
>
> frame@b120000 {
> frame-number = <0>;
> interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
> - reg = <0x0b121000 0x1000>,
> - <0x0b122000 0x1000>;
> + reg = <0x0 0x0b121000 0x0 0x1000>,
> + <0x0 0x0b122000 0x0 0x1000>;
> };
>
> frame@b123000 {
> frame-number = <1>;
> interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
> - reg = <0xb123000 0x1000>;
> + reg = <0x0 0xb123000 0x0 0x1000>;
> status = "disabled";
> };
>
> frame@b124000 {
> frame-number = <2>;
> interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
> - reg = <0x0b124000 0x1000>;
> + reg = <0x0 0x0b124000 0x0 0x1000>;
> status = "disabled";
> };
>
> frame@b125000 {
> frame-number = <3>;
> interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
> - reg = <0x0b125000 0x1000>;
> + reg = <0x0 0x0b125000 0x0 0x1000>;
> status = "disabled";
> };
>
> frame@b126000 {
> frame-number = <4>;
> interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
> - reg = <0x0b126000 0x1000>;
> + reg = <0x0 0x0b126000 0x0 0x1000>;
> status = "disabled";
> };
>
> frame@b127000 {
> frame-number = <5>;
> interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
> - reg = <0x0b127000 0x1000>;
> + reg = <0x0 0x0b127000 0x0 0x1000>;
> status = "disabled";
> };
>
> frame@b128000 {
> frame-number = <6>;
> interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
> - reg = <0x0b128000 0x1000>;
> + reg = <0x0 0x0b128000 0x0 0x1000>;
> status = "disabled";
> };
> };
>
> q6v5_wcss: remoteproc@cd00000 {
> compatible = "qcom,ipq8074-wcss-pil";
> - reg = <0x0cd00000 0x4040>,
> - <0x004ab000 0x20>;
> + reg = <0x0 0x0cd00000 0x0 0x4040>,
> + <0x0 0x004ab000 0x0 0x20>;
> reg-names = "qdsp6",
> "rmb";
> interrupts-extended = <&intc GIC_SPI 325 IRQ_TYPE_EDGE_RISING>,
> --
> 1.8.3
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2020-10-16 9:08 ` Zhen Lei
@ 2020-11-28 4:53 ` Florian Fainelli
-1 siblings, 0 replies; 54+ messages in thread
From: Florian Fainelli @ 2020-11-28 4:53 UTC (permalink / raw)
To: bcm-kernel-feedback-list, Zhen Lei, Rob Herring, Arnd Bergmann,
Ray Jui, Scott Branden, Andy Gross, Bjorn Andersson,
linux-arm-msm, devicetree, linux-arm-kernel, linux-kernel
On Fri, 16 Oct 2020 17:08:32 +0800, Zhen Lei <thunder.leizhen@huawei.com> wrote:
> The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
> property must have the same "#address-cells" and "#size-cells" values as
> the parent node. Otherwise, the following warnings is reported:
>
> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
> its #address-cells (1) differs from / (2)
> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
> its #size-cells (1) differs from / (2)
>
> Arnd Bergmann figured out why it's necessary:
> Also note that the #address-cells=<1> means that any device under
> this bus is assumed to only support 32-bit addressing, and DMA will
> have to go through a slow swiotlb in the absence of an IOMMU.
>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> ---
Applied to devicetree-arm64/next, thanks!
--
Florian
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2020-11-28 4:53 ` Florian Fainelli
0 siblings, 0 replies; 54+ messages in thread
From: Florian Fainelli @ 2020-11-28 4:53 UTC (permalink / raw)
To: bcm-kernel-feedback-list, Zhen Lei, Rob Herring, Arnd Bergmann,
Ray Jui, Scott Branden, Andy Gross, Bjorn Andersson,
linux-arm-msm, devicetree, linux-arm-kernel, linux-kernel
On Fri, 16 Oct 2020 17:08:32 +0800, Zhen Lei <thunder.leizhen@huawei.com> wrote:
> The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
> property must have the same "#address-cells" and "#size-cells" values as
> the parent node. Otherwise, the following warnings is reported:
>
> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
> its #address-cells (1) differs from / (2)
> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
> its #size-cells (1) differs from / (2)
>
> Arnd Bergmann figured out why it's necessary:
> Also note that the #address-cells=<1> means that any device under
> this bus is assumed to only support 32-bit addressing, and DMA will
> have to go through a slow swiotlb in the absence of an IOMMU.
>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> ---
Applied to devicetree-arm64/next, thanks!
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2020-11-28 4:53 ` Florian Fainelli
@ 2020-11-28 9:58 ` Arnd Bergmann
-1 siblings, 0 replies; 54+ messages in thread
From: Arnd Bergmann @ 2020-11-28 9:58 UTC (permalink / raw)
To: Florian Fainelli
Cc: bcm-kernel-feedback-list, Zhen Lei, Rob Herring, Arnd Bergmann,
Ray Jui, Scott Branden, Andy Gross, Bjorn Andersson,
linux-arm-msm, devicetree, linux-arm-kernel, linux-kernel
On Sat, Nov 28, 2020 at 5:53 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On Fri, 16 Oct 2020 17:08:32 +0800, Zhen Lei <thunder.leizhen@huawei.com> wrote:
> > The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
> > property must have the same "#address-cells" and "#size-cells" values as
> > the parent node. Otherwise, the following warnings is reported:
> >
> > arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
> > (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
> > its #address-cells (1) differs from / (2)
> > arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
> > (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
> > its #size-cells (1) differs from / (2)
> >
> > Arnd Bergmann figured out why it's necessary:
> > Also note that the #address-cells=<1> means that any device under
> > this bus is assumed to only support 32-bit addressing, and DMA will
> > have to go through a slow swiotlb in the absence of an IOMMU.
> >
> > Suggested-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> > ---
>
> Applied to devicetree-arm64/next, thanks!
The notification may have gone missing, but I had merged it into v5.10-fixes
already, and as of today, it's in mainline, so you can drop it from your
next branch, or just leave it in if you want to avoid taking things out of
your tree.
Arnd
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2020-11-28 9:58 ` Arnd Bergmann
0 siblings, 0 replies; 54+ messages in thread
From: Arnd Bergmann @ 2020-11-28 9:58 UTC (permalink / raw)
To: Florian Fainelli
Cc: devicetree, linux-kernel, Arnd Bergmann, Scott Branden, Ray Jui,
linux-arm-msm, Andy Gross, Bjorn Andersson, Rob Herring,
bcm-kernel-feedback-list, Zhen Lei, linux-arm-kernel
On Sat, Nov 28, 2020 at 5:53 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On Fri, 16 Oct 2020 17:08:32 +0800, Zhen Lei <thunder.leizhen@huawei.com> wrote:
> > The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
> > property must have the same "#address-cells" and "#size-cells" values as
> > the parent node. Otherwise, the following warnings is reported:
> >
> > arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
> > (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
> > its #address-cells (1) differs from / (2)
> > arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
> > (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
> > its #size-cells (1) differs from / (2)
> >
> > Arnd Bergmann figured out why it's necessary:
> > Also note that the #address-cells=<1> means that any device under
> > this bus is assumed to only support 32-bit addressing, and DMA will
> > have to go through a slow swiotlb in the absence of an IOMMU.
> >
> > Suggested-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> > ---
>
> Applied to devicetree-arm64/next, thanks!
The notification may have gone missing, but I had merged it into v5.10-fixes
already, and as of today, it's in mainline, so you can drop it from your
next branch, or just leave it in if you want to avoid taking things out of
your tree.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2020-11-28 9:58 ` Arnd Bergmann
@ 2020-12-14 19:09 ` Ray Jui
-1 siblings, 0 replies; 54+ messages in thread
From: Ray Jui @ 2020-12-14 19:09 UTC (permalink / raw)
To: Arnd Bergmann, Florian Fainelli
Cc: bcm-kernel-feedback-list, Zhen Lei, Rob Herring, Arnd Bergmann,
Ray Jui, Scott Branden, Andy Gross, Bjorn Andersson,
linux-arm-msm, devicetree, linux-arm-kernel, linux-kernel,
Bharat Gooty
[-- Attachment #1: Type: text/plain, Size: 2620 bytes --]
+ Bharat
On 11/28/2020 1:58 AM, Arnd Bergmann wrote:
> On Sat, Nov 28, 2020 at 5:53 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> On Fri, 16 Oct 2020 17:08:32 +0800, Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>> The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
>>> property must have the same "#address-cells" and "#size-cells" values as
>>> the parent node. Otherwise, the following warnings is reported:
>>>
>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
>>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
>>> its #address-cells (1) differs from / (2)
>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
>>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
>>> its #size-cells (1) differs from / (2)
>>>
>>> Arnd Bergmann figured out why it's necessary:
>>> Also note that the #address-cells=<1> means that any device under
>>> this bus is assumed to only support 32-bit addressing, and DMA will
>>> have to go through a slow swiotlb in the absence of an IOMMU.
>>>
>>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>>> ---
>>
>> Applied to devicetree-arm64/next, thanks!
>
> The notification may have gone missing, but I had merged it into v5.10-fixes
> already, and as of today, it's in mainline, so you can drop it from your
> next branch, or just leave it in if you want to avoid taking things out of
> your tree.
>
> Arnd
>
It looks like this patch might have caused a regression on Stingray USB.
Bharat, could you please confirm?
The fix would be to properly define the dma-ranges to be 32-bit (0x0 ~
0xffffffff) since IOMMU is disabled on this device and the device's DMA
engine is on a 32-bit bus.
Thanks,
Ray
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4151 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2020-12-14 19:09 ` Ray Jui
0 siblings, 0 replies; 54+ messages in thread
From: Ray Jui @ 2020-12-14 19:09 UTC (permalink / raw)
To: Arnd Bergmann, Florian Fainelli
Cc: devicetree, linux-kernel, Arnd Bergmann, Scott Branden, Ray Jui,
linux-arm-msm, Andy Gross, Bjorn Andersson, Rob Herring,
bcm-kernel-feedback-list, Zhen Lei, linux-arm-kernel,
Bharat Gooty
[-- Attachment #1.1: Type: text/plain, Size: 2620 bytes --]
+ Bharat
On 11/28/2020 1:58 AM, Arnd Bergmann wrote:
> On Sat, Nov 28, 2020 at 5:53 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> On Fri, 16 Oct 2020 17:08:32 +0800, Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>> The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
>>> property must have the same "#address-cells" and "#size-cells" values as
>>> the parent node. Otherwise, the following warnings is reported:
>>>
>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
>>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
>>> its #address-cells (1) differs from / (2)
>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
>>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
>>> its #size-cells (1) differs from / (2)
>>>
>>> Arnd Bergmann figured out why it's necessary:
>>> Also note that the #address-cells=<1> means that any device under
>>> this bus is assumed to only support 32-bit addressing, and DMA will
>>> have to go through a slow swiotlb in the absence of an IOMMU.
>>>
>>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>>> ---
>>
>> Applied to devicetree-arm64/next, thanks!
>
> The notification may have gone missing, but I had merged it into v5.10-fixes
> already, and as of today, it's in mainline, so you can drop it from your
> next branch, or just leave it in if you want to avoid taking things out of
> your tree.
>
> Arnd
>
It looks like this patch might have caused a regression on Stingray USB.
Bharat, could you please confirm?
The fix would be to properly define the dma-ranges to be 32-bit (0x0 ~
0xffffffff) since IOMMU is disabled on this device and the device's DMA
engine is on a 32-bit bus.
Thanks,
Ray
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4151 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2020-12-14 19:09 ` Ray Jui
@ 2020-12-14 19:46 ` Arnd Bergmann
-1 siblings, 0 replies; 54+ messages in thread
From: Arnd Bergmann @ 2020-12-14 19:46 UTC (permalink / raw)
To: Ray Jui
Cc: Florian Fainelli, devicetree, linux-kernel, Arnd Bergmann,
Scott Branden, Ray Jui, linux-arm-msm, Andy Gross,
Bjorn Andersson, Rob Herring, bcm-kernel-feedback-list, Zhen Lei,
linux-arm-kernel, Bharat Gooty
On Mon, Dec 14, 2020 at 8:09 PM Ray Jui <ray.jui@broadcom.com> wrote:
> On 11/28/2020 1:58 AM, Arnd Bergmann wrote:
> > On Sat, Nov 28, 2020 at 5:53 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >>
> >> On Fri, 16 Oct 2020 17:08:32 +0800, Zhen Lei <thunder.leizhen@huawei.com> wrote:
> >>> The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
> >>> property must have the same "#address-cells" and "#size-cells" values as
> >>> the parent node. Otherwise, the following warnings is reported:
> >>>
> >>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
> >>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
> >>> its #address-cells (1) differs from / (2)
> >>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
> >>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
> >>> its #size-cells (1) differs from / (2)
> >>>
> >>> Arnd Bergmann figured out why it's necessary:
> >>> Also note that the #address-cells=<1> means that any device under
> >>> this bus is assumed to only support 32-bit addressing, and DMA will
> >>> have to go through a slow swiotlb in the absence of an IOMMU.
> >>>
> >>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> >>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> >>> ---
> >>
> >> Applied to devicetree-arm64/next, thanks!
> >
> > The notification may have gone missing, but I had merged it into v5.10-fixes
> > already, and as of today, it's in mainline, so you can drop it from your
> > next branch, or just leave it in if you want to avoid taking things out of
> > your tree.
>
> It looks like this patch might have caused a regression on Stingray USB.
> Bharat, could you please confirm?
Well, this is what I had asked about originally, I assumed that
Florian had asked someone with access to the datasheet.
> The fix would be to properly define the dma-ranges to be 32-bit (0x0 ~
> 0xffffffff) since IOMMU is disabled on this device and the device's DMA
> engine is on a 32-bit bus.
That's not how dma-ranges work, they tell you what the capabilities
of the bus are, while the capabilities of the device are identified by
the properties of that device.
The device claims to be compatible with "generic-xhci", so the
driver asks for a 64-bit mask to be set according to the xhci
specification. If this device is not xhci compliant, then it should
not ask for a 64-bit mask.
However, if this is a 64-bit capable bus master on a 32-bit bus,
then the dma-ranges property should list the capabilities of the
bus, so the kernel can force the driver to fall back to 32-bit addressing.
Arnd
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2020-12-14 19:46 ` Arnd Bergmann
0 siblings, 0 replies; 54+ messages in thread
From: Arnd Bergmann @ 2020-12-14 19:46 UTC (permalink / raw)
To: Ray Jui
Cc: devicetree, Florian Fainelli, Scott Branden, Arnd Bergmann,
Ray Jui, Zhen Lei, linux-kernel, Rob Herring, Bjorn Andersson,
Andy Gross, bcm-kernel-feedback-list, linux-arm-msm,
linux-arm-kernel, Bharat Gooty
On Mon, Dec 14, 2020 at 8:09 PM Ray Jui <ray.jui@broadcom.com> wrote:
> On 11/28/2020 1:58 AM, Arnd Bergmann wrote:
> > On Sat, Nov 28, 2020 at 5:53 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >>
> >> On Fri, 16 Oct 2020 17:08:32 +0800, Zhen Lei <thunder.leizhen@huawei.com> wrote:
> >>> The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
> >>> property must have the same "#address-cells" and "#size-cells" values as
> >>> the parent node. Otherwise, the following warnings is reported:
> >>>
> >>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
> >>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
> >>> its #address-cells (1) differs from / (2)
> >>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
> >>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
> >>> its #size-cells (1) differs from / (2)
> >>>
> >>> Arnd Bergmann figured out why it's necessary:
> >>> Also note that the #address-cells=<1> means that any device under
> >>> this bus is assumed to only support 32-bit addressing, and DMA will
> >>> have to go through a slow swiotlb in the absence of an IOMMU.
> >>>
> >>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> >>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> >>> ---
> >>
> >> Applied to devicetree-arm64/next, thanks!
> >
> > The notification may have gone missing, but I had merged it into v5.10-fixes
> > already, and as of today, it's in mainline, so you can drop it from your
> > next branch, or just leave it in if you want to avoid taking things out of
> > your tree.
>
> It looks like this patch might have caused a regression on Stingray USB.
> Bharat, could you please confirm?
Well, this is what I had asked about originally, I assumed that
Florian had asked someone with access to the datasheet.
> The fix would be to properly define the dma-ranges to be 32-bit (0x0 ~
> 0xffffffff) since IOMMU is disabled on this device and the device's DMA
> engine is on a 32-bit bus.
That's not how dma-ranges work, they tell you what the capabilities
of the bus are, while the capabilities of the device are identified by
the properties of that device.
The device claims to be compatible with "generic-xhci", so the
driver asks for a 64-bit mask to be set according to the xhci
specification. If this device is not xhci compliant, then it should
not ask for a 64-bit mask.
However, if this is a 64-bit capable bus master on a 32-bit bus,
then the dma-ranges property should list the capabilities of the
bus, so the kernel can force the driver to fall back to 32-bit addressing.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2020-12-14 19:46 ` Arnd Bergmann
@ 2020-12-15 15:40 ` Florian Fainelli
-1 siblings, 0 replies; 54+ messages in thread
From: Florian Fainelli @ 2020-12-15 15:40 UTC (permalink / raw)
To: Arnd Bergmann, Ray Jui
Cc: Florian Fainelli, devicetree, linux-kernel, Arnd Bergmann,
Scott Branden, Ray Jui, linux-arm-msm, Andy Gross,
Bjorn Andersson, Rob Herring, bcm-kernel-feedback-list, Zhen Lei,
linux-arm-kernel, Bharat Gooty
On 12/14/2020 11:46 AM, Arnd Bergmann wrote:
> On Mon, Dec 14, 2020 at 8:09 PM Ray Jui <ray.jui@broadcom.com> wrote:
>> On 11/28/2020 1:58 AM, Arnd Bergmann wrote:
>>> On Sat, Nov 28, 2020 at 5:53 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>>
>>>> On Fri, 16 Oct 2020 17:08:32 +0800, Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>>>> The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
>>>>> property must have the same "#address-cells" and "#size-cells" values as
>>>>> the parent node. Otherwise, the following warnings is reported:
>>>>>
>>>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
>>>>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
>>>>> its #address-cells (1) differs from / (2)
>>>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
>>>>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
>>>>> its #size-cells (1) differs from / (2)
>>>>>
>>>>> Arnd Bergmann figured out why it's necessary:
>>>>> Also note that the #address-cells=<1> means that any device under
>>>>> this bus is assumed to only support 32-bit addressing, and DMA will
>>>>> have to go through a slow swiotlb in the absence of an IOMMU.
>>>>>
>>>>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
>>>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>>>>> ---
>>>>
>>>> Applied to devicetree-arm64/next, thanks!
>>>
>>> The notification may have gone missing, but I had merged it into v5.10-fixes
>>> already, and as of today, it's in mainline, so you can drop it from your
>>> next branch, or just leave it in if you want to avoid taking things out of
>>> your tree.
>>
>> It looks like this patch might have caused a regression on Stingray USB.
>> Bharat, could you please confirm?
>
> Well, this is what I had asked about originally, I assumed that
> Florian had asked someone with access to the datasheet.
It looks like we had some bad communication here, the notification email
indicating that you had applied the patch did not make it through, and I
failed to make you aware that I was waiting for some testing from Scott
and Ray.
--
Florian
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2020-12-15 15:40 ` Florian Fainelli
0 siblings, 0 replies; 54+ messages in thread
From: Florian Fainelli @ 2020-12-15 15:40 UTC (permalink / raw)
To: Arnd Bergmann, Ray Jui
Cc: devicetree, Florian Fainelli, Scott Branden, Arnd Bergmann,
Ray Jui, Zhen Lei, linux-kernel, Rob Herring, Bjorn Andersson,
Andy Gross, bcm-kernel-feedback-list, linux-arm-msm,
linux-arm-kernel, Bharat Gooty
On 12/14/2020 11:46 AM, Arnd Bergmann wrote:
> On Mon, Dec 14, 2020 at 8:09 PM Ray Jui <ray.jui@broadcom.com> wrote:
>> On 11/28/2020 1:58 AM, Arnd Bergmann wrote:
>>> On Sat, Nov 28, 2020 at 5:53 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>>
>>>> On Fri, 16 Oct 2020 17:08:32 +0800, Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>>>> The scripts/dtc/checks.c requires that the node have empty "dma-ranges"
>>>>> property must have the same "#address-cells" and "#size-cells" values as
>>>>> the parent node. Otherwise, the following warnings is reported:
>>>>>
>>>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
>>>>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
>>>>> its #address-cells (1) differs from / (2)
>>>>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning \
>>>>> (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but \
>>>>> its #size-cells (1) differs from / (2)
>>>>>
>>>>> Arnd Bergmann figured out why it's necessary:
>>>>> Also note that the #address-cells=<1> means that any device under
>>>>> this bus is assumed to only support 32-bit addressing, and DMA will
>>>>> have to go through a slow swiotlb in the absence of an IOMMU.
>>>>>
>>>>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
>>>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>>>>> ---
>>>>
>>>> Applied to devicetree-arm64/next, thanks!
>>>
>>> The notification may have gone missing, but I had merged it into v5.10-fixes
>>> already, and as of today, it's in mainline, so you can drop it from your
>>> next branch, or just leave it in if you want to avoid taking things out of
>>> your tree.
>>
>> It looks like this patch might have caused a regression on Stingray USB.
>> Bharat, could you please confirm?
>
> Well, this is what I had asked about originally, I assumed that
> Florian had asked someone with access to the datasheet.
It looks like we had some bad communication here, the notification email
indicating that you had applied the patch did not make it through, and I
failed to make you aware that I was waiting for some testing from Scott
and Ray.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
[not found] ` <CACvutz9v+TBUbrCo3X-u5ebbs04nR0y0yQN3qWfSAyZVy9RM2g@mail.gmail.com>
@ 2020-12-15 15:41 ` Florian Fainelli
0 siblings, 0 replies; 54+ messages in thread
From: Florian Fainelli @ 2020-12-15 15:41 UTC (permalink / raw)
To: Bharat Gooty, Arnd Bergmann
Cc: Ray Jui, Florian Fainelli, devicetree, linux-kernel,
Arnd Bergmann, Scott Branden, Ray Jui, linux-arm-msm, Andy Gross,
Bjorn Andersson, Rob Herring, bcm-kernel-feedback-list, Zhen Lei,
linux-arm-kernel
On 12/15/2020 5:19 AM, Bharat Gooty wrote:
> Since the IOMMU is disabled and DMA engine is on 32-bit bus, We can not
> give the complete DDR for the USB DMA.
> So restricting the usable DAM size to 4GB.
Thanks, can you make this a proper patch submission along with a Fixes:
tag that is:
Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by
empty dma-ranges")
--
Florian
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2020-12-15 15:41 ` Florian Fainelli
0 siblings, 0 replies; 54+ messages in thread
From: Florian Fainelli @ 2020-12-15 15:41 UTC (permalink / raw)
To: Bharat Gooty, Arnd Bergmann
Cc: devicetree, Florian Fainelli, Scott Branden, Arnd Bergmann,
Ray Jui, Zhen Lei, linux-kernel, Rob Herring, Bjorn Andersson,
Andy Gross, Ray Jui, linux-arm-msm, bcm-kernel-feedback-list,
linux-arm-kernel
On 12/15/2020 5:19 AM, Bharat Gooty wrote:
> Since the IOMMU is disabled and DMA engine is on 32-bit bus, We can not
> give the complete DDR for the USB DMA.
> So restricting the usable DAM size to 4GB.
Thanks, can you make this a proper patch submission along with a Fixes:
tag that is:
Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by
empty dma-ranges")
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2020-12-15 15:41 ` Florian Fainelli
@ 2020-12-15 15:49 ` Arnd Bergmann
-1 siblings, 0 replies; 54+ messages in thread
From: Arnd Bergmann @ 2020-12-15 15:49 UTC (permalink / raw)
To: Florian Fainelli
Cc: Bharat Gooty, Ray Jui, devicetree, linux-kernel, Arnd Bergmann,
Scott Branden, Ray Jui, linux-arm-msm, Andy Gross,
Bjorn Andersson, Rob Herring, bcm-kernel-feedback-list, Zhen Lei,
linux-arm-kernel
On Tue, Dec 15, 2020 at 4:41 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 12/15/2020 5:19 AM, Bharat Gooty wrote:
> > Since the IOMMU is disabled and DMA engine is on 32-bit bus, We can not
> > give the complete DDR for the USB DMA.
> > So restricting the usable DAM size to 4GB.
>
> Thanks, can you make this a proper patch submission along with a Fixes:
> tag that is:
>
> Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by
> empty dma-ranges")
Yes, that would be helpful, though I would appreciate a better description
that explains what is actually going on: is it the device or the bus that
has the 32-bit limitation, and if it is indeed a bug in the device, why do
you pretend that this is a 64-bit device on a 32-bit bus instead (this
could also use a comment in the dts file)?
Arnd
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2020-12-15 15:49 ` Arnd Bergmann
0 siblings, 0 replies; 54+ messages in thread
From: Arnd Bergmann @ 2020-12-15 15:49 UTC (permalink / raw)
To: Florian Fainelli
Cc: devicetree, Bharat Gooty, Scott Branden, Ray Jui, Zhen Lei,
linux-kernel, Rob Herring, Bjorn Andersson, Andy Gross, Ray Jui,
linux-arm-kernel, linux-arm-msm, bcm-kernel-feedback-list,
Arnd Bergmann
On Tue, Dec 15, 2020 at 4:41 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 12/15/2020 5:19 AM, Bharat Gooty wrote:
> > Since the IOMMU is disabled and DMA engine is on 32-bit bus, We can not
> > give the complete DDR for the USB DMA.
> > So restricting the usable DAM size to 4GB.
>
> Thanks, can you make this a proper patch submission along with a Fixes:
> tag that is:
>
> Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by
> empty dma-ranges")
Yes, that would be helpful, though I would appreciate a better description
that explains what is actually going on: is it the device or the bus that
has the 32-bit limitation, and if it is indeed a bug in the device, why do
you pretend that this is a 64-bit device on a 32-bit bus instead (this
could also use a comment in the dts file)?
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 0/2] eliminate two common errors reported by any yaml on arm64
2020-10-16 9:08 ` Zhen Lei
` (2 preceding siblings ...)
(?)
@ 2020-12-29 20:15 ` patchwork-bot+linux-arm-msm
-1 siblings, 0 replies; 54+ messages in thread
From: patchwork-bot+linux-arm-msm @ 2020-12-29 20:15 UTC (permalink / raw)
To: Leizhen; +Cc: linux-arm-msm
Hello:
This series was applied to qcom/linux.git (refs/heads/for-next):
On Fri, 16 Oct 2020 17:08:31 +0800 you wrote:
> v1 --> v2:
> Although it's simpler to delete the empty "dma-ranges" property, and the function
> of_translate_one() in drivers/of/address.c will treate non "dma-ranges" case as
> empty "dma-ranges". But as Arnd Bergmann suggested: it's not good for the scenario
> of IOMMU disabled or absented.
>
> This version make sure that the node have empty "dma-ranges" property have the same
> "#address-cells" and "#size-cells" values as its parent node.
>
> [...]
Here is the summary with links:
- [v2,1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
https://git.kernel.org/qcom/c/2013a4b684b6
- [v2,2/2] arm64: dts: qcom: clear the warnings caused by empty dma-ranges
https://git.kernel.org/qcom/c/e3389b0a1495
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2020-12-15 15:49 ` Arnd Bergmann
@ 2021-01-12 18:28 ` Ray Jui
-1 siblings, 0 replies; 54+ messages in thread
From: Ray Jui @ 2021-01-12 18:28 UTC (permalink / raw)
To: Arnd Bergmann, Florian Fainelli
Cc: Bharat Gooty, devicetree, linux-kernel, Arnd Bergmann,
Scott Branden, Ray Jui, linux-arm-msm, Andy Gross,
Bjorn Andersson, Rob Herring, bcm-kernel-feedback-list, Zhen Lei,
linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]
Hi Arnd,
On 2020-12-15 7:49 a.m., Arnd Bergmann wrote:
> On Tue, Dec 15, 2020 at 4:41 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> On 12/15/2020 5:19 AM, Bharat Gooty wrote:
>>> Since the IOMMU is disabled and DMA engine is on 32-bit bus, We can not
>>> give the complete DDR for the USB DMA.
>>> So restricting the usable DAM size to 4GB.
>>
>> Thanks, can you make this a proper patch submission along with a Fixes:
>> tag that is:
>>
>> Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by
>> empty dma-ranges")
>
> Yes, that would be helpful, though I would appreciate a better description
> that explains what is actually going on: is it the device or the bus that
> has the 32-bit limitation, and if it is indeed a bug in the device, why do
> you pretend that this is a 64-bit device on a 32-bit bus instead (this
> could also use a comment in the dts file)?
>
> Arnd
>
Sorry for the delay in reply. Bharat finally got time to do some
investigation to confirm the following:
These USB controllers indeed can address 64-bit. However, on the bus
internally, only 40-bits are connected to the interconnect of CCN. As a
result, the 'dma-ranges' should be modified to address 40-bit in size.
We also have a somewhat related question, is it true that since v5.10,
defining of 'dma-ranges' on the bus node where its child device node has
implication of IOMMU usage (through 'iommus' or 'iommu-map') is now
mandatory? My understanding is that the 'dma-ranges' in this scheme will
define the IOVA address to system address mapping required by all
devices on that bus. Please help to confirm if my understanding is correct.
Thanks,
Ray
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4151 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2021-01-12 18:28 ` Ray Jui
0 siblings, 0 replies; 54+ messages in thread
From: Ray Jui @ 2021-01-12 18:28 UTC (permalink / raw)
To: Arnd Bergmann, Florian Fainelli
Cc: devicetree, Bharat Gooty, Scott Branden, Ray Jui, Zhen Lei,
linux-kernel, Rob Herring, Bjorn Andersson, Andy Gross,
Arnd Bergmann, linux-arm-msm, bcm-kernel-feedback-list,
linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1688 bytes --]
Hi Arnd,
On 2020-12-15 7:49 a.m., Arnd Bergmann wrote:
> On Tue, Dec 15, 2020 at 4:41 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> On 12/15/2020 5:19 AM, Bharat Gooty wrote:
>>> Since the IOMMU is disabled and DMA engine is on 32-bit bus, We can not
>>> give the complete DDR for the USB DMA.
>>> So restricting the usable DAM size to 4GB.
>>
>> Thanks, can you make this a proper patch submission along with a Fixes:
>> tag that is:
>>
>> Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by
>> empty dma-ranges")
>
> Yes, that would be helpful, though I would appreciate a better description
> that explains what is actually going on: is it the device or the bus that
> has the 32-bit limitation, and if it is indeed a bug in the device, why do
> you pretend that this is a 64-bit device on a 32-bit bus instead (this
> could also use a comment in the dts file)?
>
> Arnd
>
Sorry for the delay in reply. Bharat finally got time to do some
investigation to confirm the following:
These USB controllers indeed can address 64-bit. However, on the bus
internally, only 40-bits are connected to the interconnect of CCN. As a
result, the 'dma-ranges' should be modified to address 40-bit in size.
We also have a somewhat related question, is it true that since v5.10,
defining of 'dma-ranges' on the bus node where its child device node has
implication of IOMMU usage (through 'iommus' or 'iommu-map') is now
mandatory? My understanding is that the 'dma-ranges' in this scheme will
define the IOVA address to system address mapping required by all
devices on that bus. Please help to confirm if my understanding is correct.
Thanks,
Ray
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4151 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2021-01-12 18:28 ` Ray Jui
@ 2021-01-12 20:40 ` Arnd Bergmann
-1 siblings, 0 replies; 54+ messages in thread
From: Arnd Bergmann @ 2021-01-12 20:40 UTC (permalink / raw)
To: Ray Jui
Cc: Florian Fainelli, Bharat Gooty, devicetree, linux-kernel,
Arnd Bergmann, Scott Branden, Ray Jui, linux-arm-msm, Andy Gross,
Bjorn Andersson, Rob Herring, bcm-kernel-feedback-list, Zhen Lei,
linux-arm-kernel
On Tue, Jan 12, 2021 at 7:28 PM Ray Jui <ray.jui@broadcom.com> wrote:
> On 2020-12-15 7:49 a.m., Arnd Bergmann wrote:
> > On Tue, Dec 15, 2020 at 4:41 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >>
> >> On 12/15/2020 5:19 AM, Bharat Gooty wrote:
> >>> Since the IOMMU is disabled and DMA engine is on 32-bit bus, We can not
> >>> give the complete DDR for the USB DMA.
> >>> So restricting the usable DAM size to 4GB.
> >>
> >> Thanks, can you make this a proper patch submission along with a Fixes:
> >> tag that is:
> >>
> >> Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by
> >> empty dma-ranges")
> >
> > Yes, that would be helpful, though I would appreciate a better description
> > that explains what is actually going on: is it the device or the bus that
> > has the 32-bit limitation, and if it is indeed a bug in the device, why do
> > you pretend that this is a 64-bit device on a 32-bit bus instead (this
> > could also use a comment in the dts file)?
> >
> > Arnd
> >
>
> Sorry for the delay in reply. Bharat finally got time to do some
> investigation to confirm the following:
>
> These USB controllers indeed can address 64-bit. However, on the bus
> internally, only 40-bits are connected to the interconnect of CCN. As a
> result, the 'dma-ranges' should be modified to address 40-bit in size.
a 40-bit range is effectively the same as a 64-bit range though, so I
think you'll still need a driver quirk if the device cannot use the whole 40
bit addressing but is limited to 32 bits because of a bug in its dma engine.
> We also have a somewhat related question, is it true that since v5.10,
> defining of 'dma-ranges' on the bus node where its child device node has
> implication of IOMMU usage (through 'iommus' or 'iommu-map') is now
> mandatory? My understanding is that the 'dma-ranges' in this scheme will
> define the IOVA address to system address mapping required by all
> devices on that bus. Please help to confirm if my understanding is correct
I have not actually seen that change. In general, you should always
have a dma-ranges property in the parent of a DMA master, I think
we just never enforced that and fall back to a 32-bit mask by default.
Arnd
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2021-01-12 20:40 ` Arnd Bergmann
0 siblings, 0 replies; 54+ messages in thread
From: Arnd Bergmann @ 2021-01-12 20:40 UTC (permalink / raw)
To: Ray Jui
Cc: devicetree, Florian Fainelli, Bharat Gooty, Scott Branden,
Ray Jui, Zhen Lei, linux-kernel, Rob Herring, Bjorn Andersson,
Andy Gross, Arnd Bergmann, linux-arm-msm,
bcm-kernel-feedback-list, linux-arm-kernel
On Tue, Jan 12, 2021 at 7:28 PM Ray Jui <ray.jui@broadcom.com> wrote:
> On 2020-12-15 7:49 a.m., Arnd Bergmann wrote:
> > On Tue, Dec 15, 2020 at 4:41 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >>
> >> On 12/15/2020 5:19 AM, Bharat Gooty wrote:
> >>> Since the IOMMU is disabled and DMA engine is on 32-bit bus, We can not
> >>> give the complete DDR for the USB DMA.
> >>> So restricting the usable DAM size to 4GB.
> >>
> >> Thanks, can you make this a proper patch submission along with a Fixes:
> >> tag that is:
> >>
> >> Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by
> >> empty dma-ranges")
> >
> > Yes, that would be helpful, though I would appreciate a better description
> > that explains what is actually going on: is it the device or the bus that
> > has the 32-bit limitation, and if it is indeed a bug in the device, why do
> > you pretend that this is a 64-bit device on a 32-bit bus instead (this
> > could also use a comment in the dts file)?
> >
> > Arnd
> >
>
> Sorry for the delay in reply. Bharat finally got time to do some
> investigation to confirm the following:
>
> These USB controllers indeed can address 64-bit. However, on the bus
> internally, only 40-bits are connected to the interconnect of CCN. As a
> result, the 'dma-ranges' should be modified to address 40-bit in size.
a 40-bit range is effectively the same as a 64-bit range though, so I
think you'll still need a driver quirk if the device cannot use the whole 40
bit addressing but is limited to 32 bits because of a bug in its dma engine.
> We also have a somewhat related question, is it true that since v5.10,
> defining of 'dma-ranges' on the bus node where its child device node has
> implication of IOMMU usage (through 'iommus' or 'iommu-map') is now
> mandatory? My understanding is that the 'dma-ranges' in this scheme will
> define the IOVA address to system address mapping required by all
> devices on that bus. Please help to confirm if my understanding is correct
I have not actually seen that change. In general, you should always
have a dma-ranges property in the parent of a DMA master, I think
we just never enforced that and fall back to a 32-bit mask by default.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2021-01-12 20:40 ` Arnd Bergmann
@ 2021-01-12 20:57 ` Ray Jui
-1 siblings, 0 replies; 54+ messages in thread
From: Ray Jui @ 2021-01-12 20:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Florian Fainelli, Bharat Gooty, devicetree, linux-kernel,
Arnd Bergmann, Scott Branden, Ray Jui, linux-arm-msm, Andy Gross,
Bjorn Andersson, Rob Herring, bcm-kernel-feedback-list, Zhen Lei,
linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 2699 bytes --]
On 1/12/2021 12:40 PM, Arnd Bergmann wrote:
> On Tue, Jan 12, 2021 at 7:28 PM Ray Jui <ray.jui@broadcom.com> wrote:
>> On 2020-12-15 7:49 a.m., Arnd Bergmann wrote:
>>> On Tue, Dec 15, 2020 at 4:41 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>>
>>>> On 12/15/2020 5:19 AM, Bharat Gooty wrote:
>>>>> Since the IOMMU is disabled and DMA engine is on 32-bit bus, We can not
>>>>> give the complete DDR for the USB DMA.
>>>>> So restricting the usable DAM size to 4GB.
>>>>
>>>> Thanks, can you make this a proper patch submission along with a Fixes:
>>>> tag that is:
>>>>
>>>> Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by
>>>> empty dma-ranges")
>>>
>>> Yes, that would be helpful, though I would appreciate a better description
>>> that explains what is actually going on: is it the device or the bus that
>>> has the 32-bit limitation, and if it is indeed a bug in the device, why do
>>> you pretend that this is a 64-bit device on a 32-bit bus instead (this
>>> could also use a comment in the dts file)?
>>>
>>> Arnd
>>>
>>
>> Sorry for the delay in reply. Bharat finally got time to do some
>> investigation to confirm the following:
>>
>> These USB controllers indeed can address 64-bit. However, on the bus
>> internally, only 40-bits are connected to the interconnect of CCN. As a
>> result, the 'dma-ranges' should be modified to address 40-bit in size.
>
> a 40-bit range is effectively the same as a 64-bit range though, so I
> think you'll still need a driver quirk if the device cannot use the whole 40
> bit addressing but is limited to 32 bits because of a bug in its dma engine.
>
Bharat can correct me if I'm wrong, but I don't think we have a bug in
the USB DMA engine that causes it can only address 32-bit. I believe we
can set dma-ranges size to 40-bit here.
The dma-range property is though required to be specified, instead of
leaving it as empty, with the use of IOMMU. That seems to be a v5.10
specific behavior as I described below.
Thanks,
Ray
>> We also have a somewhat related question, is it true that since v5.10,
>> defining of 'dma-ranges' on the bus node where its child device node has
>> implication of IOMMU usage (through 'iommus' or 'iommu-map') is now
>> mandatory? My understanding is that the 'dma-ranges' in this scheme will
>> define the IOVA address to system address mapping required by all
>> devices on that bus. Please help to confirm if my understanding is correct
>
> I have not actually seen that change. In general, you should always
> have a dma-ranges property in the parent of a DMA master, I think
> we just never enforced that and fall back to a 32-bit mask by default.
>
> Arnd
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4151 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2021-01-12 20:57 ` Ray Jui
0 siblings, 0 replies; 54+ messages in thread
From: Ray Jui @ 2021-01-12 20:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree, Florian Fainelli, Bharat Gooty, Scott Branden,
Ray Jui, Zhen Lei, linux-kernel, Rob Herring, Bjorn Andersson,
Andy Gross, Arnd Bergmann, linux-arm-msm,
bcm-kernel-feedback-list, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 2699 bytes --]
On 1/12/2021 12:40 PM, Arnd Bergmann wrote:
> On Tue, Jan 12, 2021 at 7:28 PM Ray Jui <ray.jui@broadcom.com> wrote:
>> On 2020-12-15 7:49 a.m., Arnd Bergmann wrote:
>>> On Tue, Dec 15, 2020 at 4:41 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>>
>>>> On 12/15/2020 5:19 AM, Bharat Gooty wrote:
>>>>> Since the IOMMU is disabled and DMA engine is on 32-bit bus, We can not
>>>>> give the complete DDR for the USB DMA.
>>>>> So restricting the usable DAM size to 4GB.
>>>>
>>>> Thanks, can you make this a proper patch submission along with a Fixes:
>>>> tag that is:
>>>>
>>>> Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by
>>>> empty dma-ranges")
>>>
>>> Yes, that would be helpful, though I would appreciate a better description
>>> that explains what is actually going on: is it the device or the bus that
>>> has the 32-bit limitation, and if it is indeed a bug in the device, why do
>>> you pretend that this is a 64-bit device on a 32-bit bus instead (this
>>> could also use a comment in the dts file)?
>>>
>>> Arnd
>>>
>>
>> Sorry for the delay in reply. Bharat finally got time to do some
>> investigation to confirm the following:
>>
>> These USB controllers indeed can address 64-bit. However, on the bus
>> internally, only 40-bits are connected to the interconnect of CCN. As a
>> result, the 'dma-ranges' should be modified to address 40-bit in size.
>
> a 40-bit range is effectively the same as a 64-bit range though, so I
> think you'll still need a driver quirk if the device cannot use the whole 40
> bit addressing but is limited to 32 bits because of a bug in its dma engine.
>
Bharat can correct me if I'm wrong, but I don't think we have a bug in
the USB DMA engine that causes it can only address 32-bit. I believe we
can set dma-ranges size to 40-bit here.
The dma-range property is though required to be specified, instead of
leaving it as empty, with the use of IOMMU. That seems to be a v5.10
specific behavior as I described below.
Thanks,
Ray
>> We also have a somewhat related question, is it true that since v5.10,
>> defining of 'dma-ranges' on the bus node where its child device node has
>> implication of IOMMU usage (through 'iommus' or 'iommu-map') is now
>> mandatory? My understanding is that the 'dma-ranges' in this scheme will
>> define the IOVA address to system address mapping required by all
>> devices on that bus. Please help to confirm if my understanding is correct
>
> I have not actually seen that change. In general, you should always
> have a dma-ranges property in the parent of a DMA master, I think
> we just never enforced that and fall back to a 32-bit mask by default.
>
> Arnd
>
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4151 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* RE: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2021-01-12 20:57 ` Ray Jui
@ 2021-01-13 3:42 ` Bharat Gooty
-1 siblings, 0 replies; 54+ messages in thread
From: Bharat Gooty @ 2021-01-13 3:42 UTC (permalink / raw)
To: Ray Jui, Arnd Bergmann
Cc: Florian Fainelli, devicetree, linux-kernel, Arnd Bergmann,
Scott Branden, Ray Jui, linux-arm-msm, Andy Gross,
Bjorn Andersson, Rob Herring, bcm-kernel-feedback-list, Zhen Lei,
linux-arm-kernel, Bharat Gooty
[-- Attachment #1: Type: text/plain, Size: 4505 bytes --]
Hello Ray,
I had cross checked with Design and integration team.
Yes we can set the "dma-rages" to 40 bit DMA ranges. Tested, it is working.
Thanks,
-Bharat
-----Original Message-----
From: Ray Jui <ray.jui@broadcom.com>
Sent: Wednesday, January 13, 2021 2:28 AM
To: Arnd Bergmann <arnd@kernel.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>; Bharat Gooty
<bharat.gooty@broadcom.com>; devicetree <devicetree@vger.kernel.org>;
linux-kernel <linux-kernel@vger.kernel.org>; Arnd Bergmann <arnd@arndb.de>;
Scott Branden <sbranden@broadcom.com>; Ray Jui <rjui@broadcom.com>;
linux-arm-msm <linux-arm-msm@vger.kernel.org>; Andy Gross
<agross@kernel.org>; Bjorn Andersson <bjorn.andersson@linaro.org>; Rob
Herring <robh+dt@kernel.org>; bcm-kernel-feedback-list
<bcm-kernel-feedback-list@broadcom.com>; Zhen Lei
<thunder.leizhen@huawei.com>; linux-arm-kernel
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused
by empty dma-ranges
On 1/12/2021 12:40 PM, Arnd Bergmann wrote:
> On Tue, Jan 12, 2021 at 7:28 PM Ray Jui <ray.jui@broadcom.com> wrote:
>> On 2020-12-15 7:49 a.m., Arnd Bergmann wrote:
>>> On Tue, Dec 15, 2020 at 4:41 PM Florian Fainelli <f.fainelli@gmail.com>
>>> wrote:
>>>>
>>>> On 12/15/2020 5:19 AM, Bharat Gooty wrote:
>>>>> Since the IOMMU is disabled and DMA engine is on 32-bit bus, We can
>>>>> not
>>>>> give the complete DDR for the USB DMA.
>>>>> So restricting the usable DAM size to 4GB.
>>>>
>>>> Thanks, can you make this a proper patch submission along with a Fixes:
>>>> tag that is:
>>>>
>>>> Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused
>>>> by
>>>> empty dma-ranges")
>>>
>>> Yes, that would be helpful, though I would appreciate a better
>>> description
>>> that explains what is actually going on: is it the device or the bus
>>> that
>>> has the 32-bit limitation, and if it is indeed a bug in the device, why
>>> do
>>> you pretend that this is a 64-bit device on a 32-bit bus instead (this
>>> could also use a comment in the dts file)?
>>>
>>> Arnd
>>>
>>
>> Sorry for the delay in reply. Bharat finally got time to do some
>> investigation to confirm the following:
>>
>> These USB controllers indeed can address 64-bit. However, on the bus
>> internally, only 40-bits are connected to the interconnect of CCN. As a
>> result, the 'dma-ranges' should be modified to address 40-bit in size.
>
> a 40-bit range is effectively the same as a 64-bit range though, so I
> think you'll still need a driver quirk if the device cannot use the whole
> 40
> bit addressing but is limited to 32 bits because of a bug in its dma
> engine.
>
Bharat can correct me if I'm wrong, but I don't think we have a bug in
the USB DMA engine that causes it can only address 32-bit. I believe we
can set dma-ranges size to 40-bit here.
The dma-range property is though required to be specified, instead of
leaving it as empty, with the use of IOMMU. That seems to be a v5.10
specific behavior as I described below.
Thanks,
Ray
>> We also have a somewhat related question, is it true that since v5.10,
>> defining of 'dma-ranges' on the bus node where its child device node has
>> implication of IOMMU usage (through 'iommus' or 'iommu-map') is now
>> mandatory? My understanding is that the 'dma-ranges' in this scheme will
>> define the IOVA address to system address mapping required by all
>> devices on that bus. Please help to confirm if my understanding is
>> correct
>
> I have not actually seen that change. In general, you should always
> have a dma-ranges property in the parent of a DMA master, I think
> we just never enforced that and fall back to a 32-bit mask by default.
>
> Arnd
>
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4166 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* RE: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2021-01-13 3:42 ` Bharat Gooty
0 siblings, 0 replies; 54+ messages in thread
From: Bharat Gooty @ 2021-01-13 3:42 UTC (permalink / raw)
To: Ray Jui, Arnd Bergmann
Cc: devicetree, Florian Fainelli, Scott Branden, Arnd Bergmann,
Ray Jui, Zhen Lei, linux-kernel, Rob Herring, Bjorn Andersson,
Andy Gross, bcm-kernel-feedback-list, linux-arm-msm,
linux-arm-kernel, Bharat Gooty
[-- Attachment #1.1: Type: text/plain, Size: 4505 bytes --]
Hello Ray,
I had cross checked with Design and integration team.
Yes we can set the "dma-rages" to 40 bit DMA ranges. Tested, it is working.
Thanks,
-Bharat
-----Original Message-----
From: Ray Jui <ray.jui@broadcom.com>
Sent: Wednesday, January 13, 2021 2:28 AM
To: Arnd Bergmann <arnd@kernel.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>; Bharat Gooty
<bharat.gooty@broadcom.com>; devicetree <devicetree@vger.kernel.org>;
linux-kernel <linux-kernel@vger.kernel.org>; Arnd Bergmann <arnd@arndb.de>;
Scott Branden <sbranden@broadcom.com>; Ray Jui <rjui@broadcom.com>;
linux-arm-msm <linux-arm-msm@vger.kernel.org>; Andy Gross
<agross@kernel.org>; Bjorn Andersson <bjorn.andersson@linaro.org>; Rob
Herring <robh+dt@kernel.org>; bcm-kernel-feedback-list
<bcm-kernel-feedback-list@broadcom.com>; Zhen Lei
<thunder.leizhen@huawei.com>; linux-arm-kernel
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused
by empty dma-ranges
On 1/12/2021 12:40 PM, Arnd Bergmann wrote:
> On Tue, Jan 12, 2021 at 7:28 PM Ray Jui <ray.jui@broadcom.com> wrote:
>> On 2020-12-15 7:49 a.m., Arnd Bergmann wrote:
>>> On Tue, Dec 15, 2020 at 4:41 PM Florian Fainelli <f.fainelli@gmail.com>
>>> wrote:
>>>>
>>>> On 12/15/2020 5:19 AM, Bharat Gooty wrote:
>>>>> Since the IOMMU is disabled and DMA engine is on 32-bit bus, We can
>>>>> not
>>>>> give the complete DDR for the USB DMA.
>>>>> So restricting the usable DAM size to 4GB.
>>>>
>>>> Thanks, can you make this a proper patch submission along with a Fixes:
>>>> tag that is:
>>>>
>>>> Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused
>>>> by
>>>> empty dma-ranges")
>>>
>>> Yes, that would be helpful, though I would appreciate a better
>>> description
>>> that explains what is actually going on: is it the device or the bus
>>> that
>>> has the 32-bit limitation, and if it is indeed a bug in the device, why
>>> do
>>> you pretend that this is a 64-bit device on a 32-bit bus instead (this
>>> could also use a comment in the dts file)?
>>>
>>> Arnd
>>>
>>
>> Sorry for the delay in reply. Bharat finally got time to do some
>> investigation to confirm the following:
>>
>> These USB controllers indeed can address 64-bit. However, on the bus
>> internally, only 40-bits are connected to the interconnect of CCN. As a
>> result, the 'dma-ranges' should be modified to address 40-bit in size.
>
> a 40-bit range is effectively the same as a 64-bit range though, so I
> think you'll still need a driver quirk if the device cannot use the whole
> 40
> bit addressing but is limited to 32 bits because of a bug in its dma
> engine.
>
Bharat can correct me if I'm wrong, but I don't think we have a bug in
the USB DMA engine that causes it can only address 32-bit. I believe we
can set dma-ranges size to 40-bit here.
The dma-range property is though required to be specified, instead of
leaving it as empty, with the use of IOMMU. That seems to be a v5.10
specific behavior as I described below.
Thanks,
Ray
>> We also have a somewhat related question, is it true that since v5.10,
>> defining of 'dma-ranges' on the bus node where its child device node has
>> implication of IOMMU usage (through 'iommus' or 'iommu-map') is now
>> mandatory? My understanding is that the 'dma-ranges' in this scheme will
>> define the IOVA address to system address mapping required by all
>> devices on that bus. Please help to confirm if my understanding is
>> correct
>
> I have not actually seen that change. In general, you should always
> have a dma-ranges property in the parent of a DMA master, I think
> we just never enforced that and fall back to a 32-bit mask by default.
>
> Arnd
>
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4166 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2021-01-13 3:42 ` Bharat Gooty
@ 2021-01-13 8:05 ` Arnd Bergmann
-1 siblings, 0 replies; 54+ messages in thread
From: Arnd Bergmann @ 2021-01-13 8:05 UTC (permalink / raw)
To: Bharat Gooty
Cc: Ray Jui, Florian Fainelli, devicetree, linux-kernel,
Arnd Bergmann, Scott Branden, Ray Jui, linux-arm-msm, Andy Gross,
Bjorn Andersson, Rob Herring, bcm-kernel-feedback-list, Zhen Lei,
linux-arm-kernel
On Wed, Jan 13, 2021 at 4:42 AM Bharat Gooty <bharat.gooty@broadcom.com> wrote:
>
> Hello Ray,
>
> I had cross checked with Design and integration team.
> Yes we can set the "dma-rages" to 40 bit DMA ranges. Tested, it is working.
>
> -----Original Message-----
> From: Ray Jui <ray.jui@broadcom.com>
>
> Bharat can correct me if I'm wrong, but I don't think we have a bug in
> the USB DMA engine that causes it can only address 32-bit. I believe we
> can set dma-ranges size to 40-bit here.
>
> The dma-range property is though required to be specified, instead of
> leaving it as empty, with the use of IOMMU. That seems to be a v5.10
> specific behavior as I described below.
Ok, thanks for double-checking. I had misremembered the version
that actually went into the as the one that used 64-bit dma-ranges
and thought that was what broke, rather than the version without
dma-ranges.
If any of you want to send me that bugfix directly, or have Florian
pick it up through his fixes branch, I'll make sure we get it into v5.11.
Arnd
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2021-01-13 8:05 ` Arnd Bergmann
0 siblings, 0 replies; 54+ messages in thread
From: Arnd Bergmann @ 2021-01-13 8:05 UTC (permalink / raw)
To: Bharat Gooty
Cc: devicetree, Florian Fainelli, Scott Branden, Arnd Bergmann,
Ray Jui, Zhen Lei, linux-kernel, Rob Herring, Bjorn Andersson,
Andy Gross, Ray Jui, linux-arm-msm, bcm-kernel-feedback-list,
linux-arm-kernel
On Wed, Jan 13, 2021 at 4:42 AM Bharat Gooty <bharat.gooty@broadcom.com> wrote:
>
> Hello Ray,
>
> I had cross checked with Design and integration team.
> Yes we can set the "dma-rages" to 40 bit DMA ranges. Tested, it is working.
>
> -----Original Message-----
> From: Ray Jui <ray.jui@broadcom.com>
>
> Bharat can correct me if I'm wrong, but I don't think we have a bug in
> the USB DMA engine that causes it can only address 32-bit. I believe we
> can set dma-ranges size to 40-bit here.
>
> The dma-range property is though required to be specified, instead of
> leaving it as empty, with the use of IOMMU. That seems to be a v5.10
> specific behavior as I described below.
Ok, thanks for double-checking. I had misremembered the version
that actually went into the as the one that used 64-bit dma-ranges
and thought that was what broke, rather than the version without
dma-ranges.
If any of you want to send me that bugfix directly, or have Florian
pick it up through his fixes branch, I'll make sure we get it into v5.11.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2021-01-13 8:05 ` Arnd Bergmann
@ 2021-01-13 16:55 ` Florian Fainelli
-1 siblings, 0 replies; 54+ messages in thread
From: Florian Fainelli @ 2021-01-13 16:55 UTC (permalink / raw)
To: Arnd Bergmann, Bharat Gooty
Cc: Ray Jui, devicetree, linux-kernel, Arnd Bergmann, Scott Branden,
Ray Jui, linux-arm-msm, Andy Gross, Bjorn Andersson, Rob Herring,
bcm-kernel-feedback-list, Zhen Lei, linux-arm-kernel
On 1/13/21 12:05 AM, Arnd Bergmann wrote:
> On Wed, Jan 13, 2021 at 4:42 AM Bharat Gooty <bharat.gooty@broadcom.com> wrote:
>>
>> Hello Ray,
>>
>> I had cross checked with Design and integration team.
>> Yes we can set the "dma-rages" to 40 bit DMA ranges. Tested, it is working.
>>
>> -----Original Message-----
>> From: Ray Jui <ray.jui@broadcom.com>
>>
>> Bharat can correct me if I'm wrong, but I don't think we have a bug in
>> the USB DMA engine that causes it can only address 32-bit. I believe we
>> can set dma-ranges size to 40-bit here.
>>
>> The dma-range property is though required to be specified, instead of
>> leaving it as empty, with the use of IOMMU. That seems to be a v5.10
>> specific behavior as I described below.
>
> Ok, thanks for double-checking. I had misremembered the version
> that actually went into the as the one that used 64-bit dma-ranges
> and thought that was what broke, rather than the version without
> dma-ranges.
>
> If any of you want to send me that bugfix directly, or have Florian
> pick it up through his fixes branch, I'll make sure we get it into v5.11.
I have another change for v5.11 that I would like to send, so please do
send a bugfix when you get a chance and we can lump those two changes
together, say, by the end of the week?
--
Florian
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2021-01-13 16:55 ` Florian Fainelli
0 siblings, 0 replies; 54+ messages in thread
From: Florian Fainelli @ 2021-01-13 16:55 UTC (permalink / raw)
To: Arnd Bergmann, Bharat Gooty
Cc: devicetree, Arnd Bergmann, Scott Branden, Ray Jui, Zhen Lei,
linux-kernel, Rob Herring, Bjorn Andersson, Andy Gross, Ray Jui,
linux-arm-msm, bcm-kernel-feedback-list, linux-arm-kernel
On 1/13/21 12:05 AM, Arnd Bergmann wrote:
> On Wed, Jan 13, 2021 at 4:42 AM Bharat Gooty <bharat.gooty@broadcom.com> wrote:
>>
>> Hello Ray,
>>
>> I had cross checked with Design and integration team.
>> Yes we can set the "dma-rages" to 40 bit DMA ranges. Tested, it is working.
>>
>> -----Original Message-----
>> From: Ray Jui <ray.jui@broadcom.com>
>>
>> Bharat can correct me if I'm wrong, but I don't think we have a bug in
>> the USB DMA engine that causes it can only address 32-bit. I believe we
>> can set dma-ranges size to 40-bit here.
>>
>> The dma-range property is though required to be specified, instead of
>> leaving it as empty, with the use of IOMMU. That seems to be a v5.10
>> specific behavior as I described below.
>
> Ok, thanks for double-checking. I had misremembered the version
> that actually went into the as the one that used 64-bit dma-ranges
> and thought that was what broke, rather than the version without
> dma-ranges.
>
> If any of you want to send me that bugfix directly, or have Florian
> pick it up through his fixes branch, I'll make sure we get it into v5.11.
I have another change for v5.11 that I would like to send, so please do
send a bugfix when you get a chance and we can lump those two changes
together, say, by the end of the week?
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
2021-01-13 16:55 ` Florian Fainelli
@ 2021-01-13 17:45 ` Ray Jui
-1 siblings, 0 replies; 54+ messages in thread
From: Ray Jui @ 2021-01-13 17:45 UTC (permalink / raw)
To: Florian Fainelli, Arnd Bergmann, Bharat Gooty
Cc: devicetree, linux-kernel, Arnd Bergmann, Scott Branden, Ray Jui,
linux-arm-msm, Andy Gross, Bjorn Andersson, Rob Herring,
bcm-kernel-feedback-list, Zhen Lei, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]
Hi Bharat,
On 1/13/2021 8:55 AM, Florian Fainelli wrote:
> On 1/13/21 12:05 AM, Arnd Bergmann wrote:
>> On Wed, Jan 13, 2021 at 4:42 AM Bharat Gooty <bharat.gooty@broadcom.com> wrote:
>>>
>>> Hello Ray,
>>>
>>> I had cross checked with Design and integration team.
>>> Yes we can set the "dma-rages" to 40 bit DMA ranges. Tested, it is working.
>>>
>>> -----Original Message-----
>>> From: Ray Jui <ray.jui@broadcom.com>
>>>
>>> Bharat can correct me if I'm wrong, but I don't think we have a bug in
>>> the USB DMA engine that causes it can only address 32-bit. I believe we
>>> can set dma-ranges size to 40-bit here.
>>>
>>> The dma-range property is though required to be specified, instead of
>>> leaving it as empty, with the use of IOMMU. That seems to be a v5.10
>>> specific behavior as I described below.
>>
>> Ok, thanks for double-checking. I had misremembered the version
>> that actually went into the as the one that used 64-bit dma-ranges
>> and thought that was what broke, rather than the version without
>> dma-ranges.
>>
>> If any of you want to send me that bugfix directly, or have Florian
>> pick it up through his fixes branch, I'll make sure we get it into v5.11.
>
> I have another change for v5.11 that I would like to send, so please do
> send a bugfix when you get a chance and we can lump those two changes
> together, say, by the end of the week?
>
Would you be able to help to send this out by the end of this week as
Florian advised? Your previous patch with the extension to 40-bit in
size plus a fixes-by tag should do!
Thanks!
Ray
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4151 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges
@ 2021-01-13 17:45 ` Ray Jui
0 siblings, 0 replies; 54+ messages in thread
From: Ray Jui @ 2021-01-13 17:45 UTC (permalink / raw)
To: Florian Fainelli, Arnd Bergmann, Bharat Gooty
Cc: devicetree, Arnd Bergmann, Scott Branden, linux-arm-msm,
Zhen Lei, linux-kernel, Rob Herring, Bjorn Andersson, Andy Gross,
bcm-kernel-feedback-list, Ray Jui, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1574 bytes --]
Hi Bharat,
On 1/13/2021 8:55 AM, Florian Fainelli wrote:
> On 1/13/21 12:05 AM, Arnd Bergmann wrote:
>> On Wed, Jan 13, 2021 at 4:42 AM Bharat Gooty <bharat.gooty@broadcom.com> wrote:
>>>
>>> Hello Ray,
>>>
>>> I had cross checked with Design and integration team.
>>> Yes we can set the "dma-rages" to 40 bit DMA ranges. Tested, it is working.
>>>
>>> -----Original Message-----
>>> From: Ray Jui <ray.jui@broadcom.com>
>>>
>>> Bharat can correct me if I'm wrong, but I don't think we have a bug in
>>> the USB DMA engine that causes it can only address 32-bit. I believe we
>>> can set dma-ranges size to 40-bit here.
>>>
>>> The dma-range property is though required to be specified, instead of
>>> leaving it as empty, with the use of IOMMU. That seems to be a v5.10
>>> specific behavior as I described below.
>>
>> Ok, thanks for double-checking. I had misremembered the version
>> that actually went into the as the one that used 64-bit dma-ranges
>> and thought that was what broke, rather than the version without
>> dma-ranges.
>>
>> If any of you want to send me that bugfix directly, or have Florian
>> pick it up through his fixes branch, I'll make sure we get it into v5.11.
>
> I have another change for v5.11 that I would like to send, so please do
> send a bugfix when you get a chance and we can lump those two changes
> together, say, by the end of the week?
>
Would you be able to help to send this out by the end of this week as
Florian advised? Your previous patch with the extension to 40-bit in
size plus a fixes-by tag should do!
Thanks!
Ray
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4151 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
end of thread, other threads:[~2021-01-13 17:48 UTC | newest]
Thread overview: 54+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-16 9:08 [PATCH v2 0/2] eliminate two common errors reported by any yaml on arm64 Zhen Lei
2020-10-16 9:08 ` Zhen Lei
2020-10-16 9:08 ` [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges Zhen Lei
2020-10-16 9:08 ` Zhen Lei
[not found] ` <CAK8P3a2TSmsNSi-XFpT6AQ3jvVxJ1AW7Uf5tAo477wtwXZwUzg@mail.gmail.com>
2020-10-16 16:48 ` Florian Fainelli
2020-10-16 16:48 ` Florian Fainelli
[not found] ` <CAK8P3a13ywHh7igdfDSPQz9Bw8YAnKWFLKARkk2NL5u6=6yb=w@mail.gmail.com>
2020-10-16 19:27 ` Florian Fainelli
2020-10-16 19:27 ` Florian Fainelli
2020-10-18 2:10 ` Leizhen (ThunderTown)
2020-10-18 2:10 ` Leizhen (ThunderTown)
2020-10-23 7:17 ` Arnd Bergmann
2020-10-26 2:21 ` Leizhen (ThunderTown)
2020-10-26 2:21 ` Leizhen (ThunderTown)
2020-11-09 6:18 ` Leizhen (ThunderTown)
2020-11-09 6:18 ` Leizhen (ThunderTown)
2020-11-09 17:28 ` Florian Fainelli
2020-11-09 17:28 ` Florian Fainelli
2020-11-09 17:56 ` Arnd Bergmann
2020-11-09 17:56 ` Arnd Bergmann
2020-11-09 18:00 ` Florian Fainelli
2020-11-09 18:00 ` Florian Fainelli
2020-11-28 4:53 ` Florian Fainelli
2020-11-28 4:53 ` Florian Fainelli
2020-11-28 9:58 ` Arnd Bergmann
2020-11-28 9:58 ` Arnd Bergmann
2020-12-14 19:09 ` Ray Jui
2020-12-14 19:09 ` Ray Jui
2020-12-14 19:46 ` Arnd Bergmann
2020-12-14 19:46 ` Arnd Bergmann
2020-12-15 15:40 ` Florian Fainelli
2020-12-15 15:40 ` Florian Fainelli
[not found] ` <CACvutz9v+TBUbrCo3X-u5ebbs04nR0y0yQN3qWfSAyZVy9RM2g@mail.gmail.com>
2020-12-15 15:41 ` Florian Fainelli
2020-12-15 15:41 ` Florian Fainelli
2020-12-15 15:49 ` Arnd Bergmann
2020-12-15 15:49 ` Arnd Bergmann
2021-01-12 18:28 ` Ray Jui
2021-01-12 18:28 ` Ray Jui
2021-01-12 20:40 ` Arnd Bergmann
2021-01-12 20:40 ` Arnd Bergmann
2021-01-12 20:57 ` Ray Jui
2021-01-12 20:57 ` Ray Jui
2021-01-13 3:42 ` Bharat Gooty
2021-01-13 3:42 ` Bharat Gooty
2021-01-13 8:05 ` Arnd Bergmann
2021-01-13 8:05 ` Arnd Bergmann
2021-01-13 16:55 ` Florian Fainelli
2021-01-13 16:55 ` Florian Fainelli
2021-01-13 17:45 ` Ray Jui
2021-01-13 17:45 ` Ray Jui
2020-10-16 9:08 ` [PATCH v2 2/2] arm64: dts: qcom: " Zhen Lei
2020-10-16 9:08 ` Zhen Lei
2020-11-11 4:44 ` Bjorn Andersson
2020-11-11 4:44 ` Bjorn Andersson
2020-12-29 20:15 ` [PATCH v2 0/2] eliminate two common errors reported by any yaml on arm64 patchwork-bot+linux-arm-msm
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.