Add SDHCI support for APM X-Gene SoC using ARASAN SDHCI controller.

PATCH RESEND Superseded Suman Tripathi 3 participants 13 messages Apr 21, 2015 – Apr 29, 2015 1 message not in the archive

Subsystems (3)

Device tree bindings MMC, SD and SDIO Secure digital host controller interface (SDHCI) driver

lore

Share & tools

lore

Suman Tripathi

author

2015-04-21 15:42 UTC #0 lore raw

v2 cover Add SDHCI support for APM X-Gene SoC using ARASAN SDHCI controller.

This patch adds the SDHCI support for APM X-Gene SoC using ARASAN SDHCI controller.

v1 change:
* Use the CONFIG_ARM64_DMA_HAS_IOMMU for dma-mapping.

v2 change:
* Drop the IOMMU support and switching to PIO mode for arasan controller integrated inside APM X-Gene SoC.

Signed-off-by Suman Tripathi <[email protected]>

Suman Tripathi (2):
arm64: dts: Add the arasan sdhc nodes in apm-storm.dtsi.
mmc: host: Add some quirks to be read from fdt in sdhci-pltm.c

 arch/arm64/boot/dts/apm-storm.dtsi | 44 ++++++++++++++++++++++++++++++++++++++
 drivers/mmc/host/sdhci-pltfm.c     | 15 +++++++++++++
 2 files changed, 59 insertions(+)

Signature · 6 lines

1.8.2.1

_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://lists.ozlabs.org/listinfo/linuxppc-dev

A message that is not in the archive (sent off-list or not yet received): 1429630959-32649-1-git-send-email-stripathi-qTEPVZfXA3Y@public.gmane.org

Suman Tripathi

2015-04-21 15:42 UTC #2 lore raw

PATCH RESEND v2 1/2 arm64: dts: Add the arasan sdhc nodes in apm-storm.dtsi.

This patch adds the arasan sdhc nodes to reuse the of-arasan driver for APM X-Gene SoC.

Signed-off-by Suman Tripathi <[email protected]>

---
 arch/arm64/boot/dts/apm-storm.dtsi | 44 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

arch/arm64/boot/dts/apm-storm.dtsi +44 -0

index c5f0a47..fd1c142 100644
@@ -144,6 +144,40 @@
 				clock-output-names = "socplldiv2";
 			};
 
+			ahbclk: ahbclk@1f2ac000 {
+				compatible = "apm,xgene-device-clock";
+				#clock-cells = <1>;
+				clocks = <&socplldiv2 0>;
+				reg = <0x0 0x1f2ac000 0x0 0x1000
+					0x0 0x17000000 0x0 0x2000>;
+				reg-names = "csr-reg", "div-reg";
+				csr-offset = <0x0>;
+				csr-mask = <0x1>;
+				enable-offset = <0x8>;
+				enable-mask = <0x1>;
+				divider-offset = <0x164>;
+				divider-width = <0x5>;
+				divider-shift = <0x0>;
+				clock-output-names = "ahbclk";
+			};
+
+			sdioclk: sdioclk@1f2ac000 {
+				compatible = "apm,xgene-device-clock";
+				#clock-cells = <1>;
+				clocks = <&socplldiv2 0>;
+				reg = <0x0 0x1f2ac000 0x0 0x1000
+					0x0 0x17000000 0x0 0x2000>;
+				reg-names = "csr-reg", "div-reg";
+				csr-offset = <0x0>;
+				csr-mask = <0x2>;
+				enable-offset = <0x8>;
+				enable-mask = <0x2>;
+				divider-offset = <0x178>;
+				divider-width = <0x8>;
+				divider-shift = <0x0>;
+				clock-output-names = "sdioclk";
+			};
+
 			qmlclk: qmlclk {
 				compatible = "apm,xgene-device-clock";
 				#clock-cells = <1>;

@@ -282,6 +316,16 @@
 			interrupts = <0x0 0x4c 0x4>;
 		};
 
+		sdhc0: sdhc@1c000000 {
+			device_type = "sdhc";
+			compatible = "arasan,sdhci-8.9a";
+			reg = <0x0 0x1c000000 0x0 0x100>;
+			interrupts = <0x0 0x49 0x4>;
+			dma-coherent;
+			clock-names = "clk_xin", "clk_ahb";
+			clocks = <&sdioclk 0>, <&ahbclk 0>;
+		};
+
 		phy1: phy@1f21a000 {
 			compatible = "apm,xgene-phy";
 			reg = <0x0 0x1f21a000 0x0 0x100>;

Signature · 6 lines

1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Suman Tripathi

2015-04-21 15:42 UTC #3 lore raw

PATCH RESEND v2 2/2 mmc: host: Add some quirks to be read from fdt in sdhci-pltm.c

In reply to a message not in the archive

This patch adds some quirks support to be read from fdt.

Signed-off-by Suman Tripathi <[email protected]>

---
 drivers/mmc/host/sdhci-pltfm.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

drivers/mmc/host/sdhci-pltfm.c +15 -0

index bef250e..9f6a4b9 100644
@@ -85,6 +85,21 @@ void sdhci_get_of_property(struct platform_device *pdev)
 
 		if (of_get_property(np, "broken-cd", NULL))
 			host->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;
+		
+		if (of_get_property(np, "delay-after-power", NULL))
+			host->quirks |= SDHCI_QUIRK_DELAY_AFTER_POWER;
+
+		if (of_get_property(np, "no-hispd", NULL))
+			host->quirks |= SDHCI_QUIRK_NO_HISPD_BIT;
+
+		if (of_get_property(np, "broken-adma", NULL))
+			host->quirks |= SDHCI_QUIRK_BROKEN_ADMA;
+		
+		if (of_get_property(np, "broken-dma", NULL))
+			host->quirks |= SDHCI_QUIRK_BROKEN_DMA;
+
+		if (of_get_property(np, "no-cmd23", NULL))
+			host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
 
 		if (of_get_property(np, "no-1-8-v", NULL))
 			host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;

Signature · 6 lines

1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Arnd Bergmann

2015-04-21 15:46 UTC #4 lore raw

PATCH RESEND v2 2/2 mmc: host: Add some quirks to be read from fdt in sdhci-pltm.c

Quoted 16 lines · On Tuesday 21 April 2015 21:12:39 Suman Tripathi wrote:

index bef250e..9f6a4b9 100644

drivers/mmc/host/sdhci-pltfm.c +8 -0

@@ -85,6 +85,21 @@ void sdhci_get_of_property(struct platform_device *pdev)
 
                if (of_get_property(np, "broken-cd", NULL))
                        host->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;
+               
+               if (of_get_property(np, "delay-after-power", NULL))
+                       host->quirks |= SDHCI_QUIRK_DELAY_AFTER_POWER;
+
+               if (of_get_property(np, "no-hispd", NULL))
+                       host->quirks |= SDHCI_QUIRK_NO_HISPD_BIT;
+
+               if (of_get_property(np, "broken-adma", NULL))

drivers/mmc/host/sdhci-pltfm.c void sdhci_get_of_property(struct platform_device *pdev) · line 105

Quoted 10 lines

drivers/mmc/host/sdhci-pltfm.c +7 -0

+                       host->quirks |= SDHCI_QUIRK_BROKEN_ADMA;
+               
+               if (of_get_property(np, "broken-dma", NULL))
+                       host->quirks |= SDHCI_QUIRK_BROKEN_DMA;
+
+               if (of_get_property(np, "no-cmd23", NULL))
+                       host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
 
                if (of_get_property(np, "no-1-8-v", NULL))
                        host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;

Any property you add needs to be documented in the DT binding.

If possible, add generic properties for each bug you have mmc.txt rather than the driver specific sdhci.txt, and implement the parsing in a common function that is used for all mmc hosts.

An alternative would be to set all these bits based on the compatible string of your host, if that is the only one that has all these bugs.

Arnd

Suman Tripathi

author

2015-04-27 15:03 UTC #5 lore raw

PATCH RESEND v2 2/2 mmc: host: Add some quirks to be read from fdt in sdhci-pltm.c

Quoted 16 lines · On Tuesday 21 April 2015 21:12:39 Suman Tripathi wrote:

index bef250e..9f6a4b9 100644

drivers/mmc/host/sdhci-pltfm.c +8 -0

@@ -85,6 +85,21 @@ void sdhci_get_of_property(struct platform_device *pdev)
 
                if (of_get_property(np, "broken-cd", NULL))
                        host->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;
+
+               if (of_get_property(np, "delay-after-power", NULL))
+                       host->quirks |= SDHCI_QUIRK_DELAY_AFTER_POWER;
+
+               if (of_get_property(np, "no-hispd", NULL))
+                       host->quirks |= SDHCI_QUIRK_NO_HISPD_BIT;
+
+               if (of_get_property(np, "broken-adma", NULL))

drivers/mmc/host/sdhci-pltfm.c void sdhci_get_of_property(struct platform_device *pdev) · line 105

Quoted 10 lines

drivers/mmc/host/sdhci-pltfm.c +7 -0

+                       host->quirks |= SDHCI_QUIRK_BROKEN_ADMA;
+
+               if (of_get_property(np, "broken-dma", NULL))
+                       host->quirks |= SDHCI_QUIRK_BROKEN_DMA;
+
+               if (of_get_property(np, "no-cmd23", NULL))
+                       host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
 
                if (of_get_property(np, "no-1-8-v", NULL))
                        host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;

Any property you add needs to be documented in the DT binding.

If possible, add generic properties for each bug you have mmc.txt rather than the driver specific sdhci.txt, and implement the I will add the binding in mmc.txt. I thought this was present but not.

parsing in a common function that is used for all mmc hosts. As per mine understanding the sdhci_get_of_porperty is a common parsing function . Am I wrong ??

An alternative would be to set all these bits based on the compatible string of your host, if that is the only one that has all these bugs.

The host driver (arasan) is reused but this quirks are needed due to board issues. so I have a control over dtb only to fix this.

Quoted 38 lines · Arnd Bergmann

Quoted 16 lines · On Tuesday 21 April 2015 21:12:39 Suman Tripathi wrote:
index bef250e..9f6a4b9 100644
drivers/mmc/host/sdhci-pltfm.c +8 -0
@@ -85,6 +85,21 @@ void sdhci_get_of_property(struct platform_device *pdev)
 
                if (of_get_property(np, "broken-cd", NULL))
                        host->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;
+
+               if (of_get_property(np, "delay-after-power", NULL))
+                       host->quirks |= SDHCI_QUIRK_DELAY_AFTER_POWER;
+
+               if (of_get_property(np, "no-hispd", NULL))
+                       host->quirks |= SDHCI_QUIRK_NO_HISPD_BIT;
+
+               if (of_get_property(np, "broken-adma", NULL))
drivers/mmc/host/sdhci-pltfm.c void sdhci_get_of_property(struct platform_device *pdev) · line 105
Quoted 10 lines
drivers/mmc/host/sdhci-pltfm.c +7 -0
+                       host->quirks |= SDHCI_QUIRK_BROKEN_ADMA;
+
+               if (of_get_property(np, "broken-dma", NULL))
+                       host->quirks |= SDHCI_QUIRK_BROKEN_DMA;
+
+               if (of_get_property(np, "no-cmd23", NULL))
+                       host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
 
                if (of_get_property(np, "no-1-8-v", NULL))
                        host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
Any property you add needs to be documented in the DT binding.
If possible, add generic properties for each bug you have mmc.txt rather than the driver specific sdhci.txt, and implement the parsing in a common function that is used for all mmc hosts.
An alternative would be to set all these bits based on the compatible string of your host, if that is the only one that has all these bugs.
Arnd

Signature · 3 lines

Thanks,
with regards,
Suman Tripathi

Arnd Bergmann

2015-04-27 15:25 UTC #6 lore raw

PATCH RESEND v2 2/2 mmc: host: Add some quirks to be read from fdt in sdhci-pltm.c

Quoted 33 lines · On Monday 27 April 2015 20:33:25 Suman Tripathi wrote:

Quoted 27 lines · On Tuesday 21 April 2015 21:12:39 Suman Tripathi wrote:

Quoted 26 lines

index bef250e..9f6a4b9 100644

drivers/mmc/host/sdhci-pltfm.c +15 -0

@@ -85,6 +85,21 @@ void sdhci_get_of_property(struct platform_device
 *pdev)
 
                if (of_get_property(np, "broken-cd", NULL))
                        host->quirks |=
 SDHCI_QUIRK_BROKEN_CARD_DETECTION;
 
+
+               if (of_get_property(np, "delay-after-power", NULL))
+                       host->quirks |= SDHCI_QUIRK_DELAY_AFTER_POWER;
+
+               if (of_get_property(np, "no-hispd", NULL))
+                       host->quirks |= SDHCI_QUIRK_NO_HISPD_BIT;
+
+               if (of_get_property(np, "broken-adma", NULL))
+                       host->quirks |= SDHCI_QUIRK_BROKEN_ADMA;
+
+               if (of_get_property(np, "broken-dma", NULL))
+                       host->quirks |= SDHCI_QUIRK_BROKEN_DMA;
+
+               if (of_get_property(np, "no-cmd23", NULL))
+                       host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;

Quoted 6 lines

Quoted 2 lines
                if (of_get_property(np, "no-1-8-v", NULL))
                        host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
Any property you add needs to be documented in the DT binding. If possible, add generic properties for each bug you have mmc.txt rather than the driver specific sdhci.txt, and implement the

Quoted 5 lines

I will add the binding in mmc.txt. I thought this was present but not.
Quoted 1 line
parsing in a common function that is used for all mmc hosts.
As per mine understanding the sdhci_get_of_porperty is a common parsing function . Am I wrong ??

No, this is only used for sdhci, not for the other controllers.

Quoted 5 lines

Quoted 2 lines
An alternative would be to set all these bits based on the compatible string of your host, if that is the only one that has all these bugs.
The host driver (arasan) is reused but this quirks are needed due to board issues. so I have a control over dtb only to fix this.

What is the nature of the bug on that board? Is there a different way to describe that without introducing six new properties?

Arnd

Suman Tripathi

author

2015-04-27 15:55 UTC #7 lore raw

PATCH RESEND v2 2/2 mmc: host: Add some quirks to be read from fdt in sdhci-pltm.c

Quoted 33 lines · On Monday 27 April 2015 20:33:25 Suman Tripathi wrote:

Quoted 27 lines · On Tuesday 21 April 2015 21:12:39 Suman Tripathi wrote:

Quoted 26 lines

index bef250e..9f6a4b9 100644

drivers/mmc/host/sdhci-pltfm.c +15 -0

@@ -85,6 +85,21 @@ void sdhci_get_of_property(struct platform_device
 *pdev)
 
                if (of_get_property(np, "broken-cd", NULL))
                        host->quirks |=
 SDHCI_QUIRK_BROKEN_CARD_DETECTION;
 
+
+               if (of_get_property(np, "delay-after-power", NULL))
+                       host->quirks |= SDHCI_QUIRK_DELAY_AFTER_POWER;
+
+               if (of_get_property(np, "no-hispd", NULL))
+                       host->quirks |= SDHCI_QUIRK_NO_HISPD_BIT;
+
+               if (of_get_property(np, "broken-adma", NULL))
+                       host->quirks |= SDHCI_QUIRK_BROKEN_ADMA;
+
+               if (of_get_property(np, "broken-dma", NULL))
+                       host->quirks |= SDHCI_QUIRK_BROKEN_DMA;
+
+               if (of_get_property(np, "no-cmd23", NULL))
+                       host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;

Quoted 6 lines

Quoted 2 lines
                if (of_get_property(np, "no-1-8-v", NULL))
                        host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
Any property you add needs to be documented in the DT binding. If possible, add generic properties for each bug you have mmc.txt rather than the driver specific sdhci.txt, and implement the

Quoted 5 lines

I will add the binding in mmc.txt. I thought this was present but not.
Quoted 1 line
parsing in a common function that is used for all mmc hosts.
As per mine understanding the sdhci_get_of_porperty is a common parsing function . Am I wrong ??

No, this is only used for sdhci, not for the other controllers.

But our's is a SHCI variant so I added it in this file.

Quoted 5 lines

Quoted 2 lines
An alternative would be to set all these bits based on the compatible string of your host, if that is the only one that has all these bugs.
The host driver (arasan) is reused but this quirks are needed due to board issues. so I have a control over dtb only to fix this.

What is the nature of the bug on that board? Is there a different way to describe that without introducing six new properties?

Sorry it is board and IP as well SoC errata's,

1. Delay after power is required due to some voltage issues that will be fixed in next board revision

2. We need to support PIO mode as of now because DMA or ADMA requires some kind of translation driver that I am working on.

3. The version of arasan variant we have in our SoC doesn't have the HISPD bit field in HI-SPEED SD card. So this makes HI-SPEED sdcard work.

4. NO_CMD23 is required for eMMC cards.

These are not new properties. Only the fact is I am using it for our SoC from dtb. These quirks are already there in mmc common framework. Nothing is new.

Quoted 52 lines · Arnd Bergmann

Quoted 33 lines · On Monday 27 April 2015 20:33:25 Suman Tripathi wrote:
Quoted 27 lines · On Tuesday 21 April 2015 21:12:39 Suman Tripathi wrote:
Quoted 26 lines
index bef250e..9f6a4b9 100644
drivers/mmc/host/sdhci-pltfm.c +15 -0
@@ -85,6 +85,21 @@ void sdhci_get_of_property(struct platform_device
 *pdev)
 
                if (of_get_property(np, "broken-cd", NULL))
                        host->quirks |=
 SDHCI_QUIRK_BROKEN_CARD_DETECTION;
 
+
+               if (of_get_property(np, "delay-after-power", NULL))
+                       host->quirks |= SDHCI_QUIRK_DELAY_AFTER_POWER;
+
+               if (of_get_property(np, "no-hispd", NULL))
+                       host->quirks |= SDHCI_QUIRK_NO_HISPD_BIT;
+
+               if (of_get_property(np, "broken-adma", NULL))
+                       host->quirks |= SDHCI_QUIRK_BROKEN_ADMA;
+
+               if (of_get_property(np, "broken-dma", NULL))
+                       host->quirks |= SDHCI_QUIRK_BROKEN_DMA;
+
+               if (of_get_property(np, "no-cmd23", NULL))
+                       host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
Quoted 6 lines
Quoted 2 lines
                if (of_get_property(np, "no-1-8-v", NULL))
                        host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
Any property you add needs to be documented in the DT binding. If possible, add generic properties for each bug you have mmc.txt rather than the driver specific sdhci.txt, and implement the
Quoted 5 lines
I will add the binding in mmc.txt. I thought this was present but not.
Quoted 1 line
parsing in a common function that is used for all mmc hosts.
As per mine understanding the sdhci_get_of_porperty is a common parsing function . Am I wrong ??
No, this is only used for sdhci, not for the other controllers.
Quoted 5 lines
Quoted 2 lines
An alternative would be to set all these bits based on the compatible string of your host, if that is the only one that has all these bugs.
The host driver (arasan) is reused but this quirks are needed due to board issues. so I have a control over dtb only to fix this.
What is the nature of the bug on that board? Is there a different way to describe that without introducing six new properties?
Arnd

Signature · 3 lines

Thanks,
with regards,
Suman Tripathi

Arnd Bergmann

2015-04-27 19:49 UTC #8 lore raw

PATCH RESEND v2 2/2 mmc: host: Add some quirks to be read from fdt in sdhci-pltm.c

Quoted 15 lines · On Monday 27 April 2015 21:25:20 Suman Tripathi wrote:

Quoted 15 lines · On Monday 27 April 2015 20:33:25 Suman Tripathi wrote:
Quoted 14 lines
Quoted 13 lines · On Tuesday 21 April 2015 21:12:39 Suman Tripathi wrote:
drivers/mmc/host/sdhci-pltfm.c void sdhci_get_of_property(struct platform_device *pdev) · line 105
Quoted 8 lines
drivers/mmc/host/sdhci-pltfm.c +4 -0
+                       host->quirks |= SDHCI_QUIRK_BROKEN_DMA;
+
+               if (of_get_property(np, "no-cmd23", NULL))
+                       host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
 
                if (of_get_property(np, "no-1-8-v", NULL))
 
                        host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
Any property you add needs to be documented in the DT binding. If possible, add generic properties for each bug you have mmc.txt rather than the driver specific sdhci.txt, and implement the

Quoted 7 lines

Quoted 6 lines
Quoted 6 lines
I will add the binding in mmc.txt. I thought this was present but not.
Quoted 1 line
parsing in a common function that is used for all mmc hosts.
As per mine understanding the sdhci_get_of_porperty is a common parsing function . Am I wrong ??

A small side note: please fix your email client to use proper attribution of the citations. The way you reply, nobody knows what you are saying compare to what you quote. Also, reduce the quotation to the parts you are replying to.

Quoted 3 lines

Quoted 1 line
No, this is only used for sdhci, not for the other controllers.
But our's is a SHCI variant so I added it in this file.

That's my point: a lot of the bugs are independent of the specific host controller and could happen with any one of them. We want to ensure that nobody tries to add another property with similar semantics and a different name just because they are using a different driver.

Quoted 6 lines

Quoted 5 lines
Quoted 2 lines
An alternative would be to set all these bits based on the compatible string of your host, if that is the only one that has all these bugs.
The host driver (arasan) is reused but this quirks are needed due to board issues. so I have a control over dtb only to fix this.

Quoted 7 lines

What is the nature of the bug on that board? Is there a different way to describe that without introducing six new properties?
Sorry it is board and IP as well SoC errata's,
1. Delay after power is required due to some voltage issues that will be fixed in next board revision

This is clearly not sdhci-specific, so make that a generic property for all mmc.

Quoted 2 lines

2. We need to support PIO mode as of now because DMA or ADMA requires some kind of translation driver that I am working on.

But this does not describe the hardware properties. Don't add properties that describe the lack of a kernel driver. If you can't do DMA yet, use a dma-ranges property that lists one empty range to prevent dma_set_mask() from working, so it will fall back to PIO mode. You may have to fix the driver if that doesn't already work.

What kind of driver do you need here?

Quoted 9 lines

3. The version of arasan variant we have in our SoC doesn't have the HISPD bit field in HI-SPEED SD card. So this makes HI-SPEED sdcard work.
4. NO_CMD23 is required for eMMC cards.
These are not new properties. Only the fact is I am using it for our SoC from dtb. These quirks are already there in mmc common framework. Nothing is new.

Are you sure that you have version 8.9a of the Arasan SDHCI? This sounds like version specific quirks, so they are probably present in each SoC that uses the same version.

Arnd

Suman Tripathi

author

2015-04-28 16:53 UTC #9 lore raw

Re: [PATCH v2 RESEND 2/2] mmc: host: Add some quirks to be read from fdt in sdhci-pltm.c

Quoted 6 lines · On Monday 27 April 2015 21:25:20 Suman Tripathi wrote:

Quoted 6 lines · On Monday 27 April 2015 20:33:25 Suman Tripathi wrote:
Quoted 5 lines
Quoted 5 lines · On Tuesday 21 April 2015 21:12:39 Suman Tripathi wrote:
drivers/mmc/host/sdhci-pltfm.c void sdhci_get_of_property(struct platform_device *pdev)
Quoted 4 lines
drivers/mmc/host/sdhci-pltfm.c +4 -0
+                       host->quirks |= SDHCI_QUIRK_BROKEN_DMA;
+
+               if (of_get_property(np, "no-cmd23", NULL))
+                       host->quirks2 |=

SDHCI_QUIRK2_HOST_NO_CMD23;

Quoted 9 lines

Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
Quoted 4 lines
                if (of_get_property(np, "no-1-8-v", NULL))

                        host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
Any property you add needs to be documented in the DT binding. If possible, add generic properties for each bug you have mmc.txt rather than the driver specific sdhci.txt, and implement the

Quoted 7 lines

Quoted 6 lines
Quoted 6 lines
I will add the binding in mmc.txt. I thought this was present but not.
Quoted 1 line
parsing in a common function that is used for all mmc hosts.
As per mine understanding the sdhci_get_of_porperty is a common parsing function . Am I wrong ??

Ok . sorry for that ..

Quoted 3 lines

Quoted 1 line
No, this is only used for sdhci, not for the other controllers.
But our's is a SHCI variant so I added it in this file.

Then I am not finding a reason why we have sdhci_get_of_property function ?? .
I added a generic names like broken-adma that everyone can reuse it. I
made mistake of not adding it in the binding.

For eg : broken-cd is not added by me but I can use it. So I added something like broken-adma as it was not present.

Quoted 6 lines

Quoted 5 lines
Quoted 2 lines
An alternative would be to set all these bits based on the compatible string of your host, if that is the only one that has all these bugs.
The host driver (arasan) is reused but this quirks are needed due to board issues. so I have a control over dtb only to fix this.

Quoted 7 lines

What is the nature of the bug on that board? Is there a different way to describe that without introducing six new properties?
Sorry it is board and IP as well SoC errata's,
1. Delay after power is required due to some voltage issues that will be fixed in next board revision

This is clearly not sdhci-specific, so make that a generic property for all mmc.
okay.

Quoted 2 lines

2. We need to support PIO mode as of now because DMA or ADMA requires some kind of translation driver that I am working on.

The generic sdhc framework doesn't have this capabiltiy. It uses the quirks to identify the broken DMA and ADMA modes even
if the controller is capable of.

What kind of driver do you need here?
For DMA and adma we need some 32 bit to 64 bit translation driver. The existing arasan driver only support 32 bit.

Quoted 9 lines

3. The version of arasan variant we have in our SoC doesn't have the HISPD bit field in HI-SPEED SD card. So this makes HI-SPEED sdcard work.
4. NO_CMD23 is required for eMMC cards.
These are not new properties. Only the fact is I am using it for our SoC from dtb. These quirks are already there in mmc common framework. Nothing is new.

Are you sure that you have version 8.9a of the Arasan SDHCI? Yes
This sounds
like version specific quirks, so they are probably present in each SoC that uses the same version.
Not sure.

Quoted 85 lines · Arnd Bergmann

Quoted 6 lines · On Monday 27 April 2015 21:25:20 Suman Tripathi wrote:
Quoted 6 lines · On Monday 27 April 2015 20:33:25 Suman Tripathi wrote:
Quoted 5 lines
Quoted 5 lines · On Tuesday 21 April 2015 21:12:39 Suman Tripathi wrote:
drivers/mmc/host/sdhci-pltfm.c void sdhci_get_of_property(struct platform_device *pdev)
Quoted 4 lines
drivers/mmc/host/sdhci-pltfm.c +4 -0
+                       host->quirks |= SDHCI_QUIRK_BROKEN_DMA;
+
+               if (of_get_property(np, "no-cmd23", NULL))
+                       host->quirks2 |=
SDHCI_QUIRK2_HOST_NO_CMD23;
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 8 lines
Quoted 4 lines
                if (of_get_property(np, "no-1-8-v", NULL))

                        host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
Any property you add needs to be documented in the DT binding. If possible, add generic properties for each bug you have mmc.txt rather than the driver specific sdhci.txt, and implement the
I will add the binding in mmc.txt. I thought this was present but
not.
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
parsing in a common function that is used for all mmc hosts.
As per mine understanding the sdhci_get_of_porperty is a common parsing function . Am I wrong ??
A small side note: please fix your email client to use proper attribution of the citations. The way you reply, nobody knows what you are saying compare to what you quote. Also, reduce the quotation to the parts you are replying to.
Quoted 3 lines
Quoted 1 line
No, this is only used for sdhci, not for the other controllers.
But our's is a SHCI variant so I added it in this file.
That's my point: a lot of the bugs are independent of the specific host controller and could happen with any one of them. We want to ensure that nobody tries to add another property with similar semantics and a different name just because they are using a different driver.
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
An alternative would be to set all these bits based on the compatible string of your host, if that is the only one that has all these bugs.
The host driver (arasan) is reused but this quirks are needed due to board issues. so I have a control over dtb only to fix this.
Quoted 7 lines
What is the nature of the bug on that board? Is there a different way to describe that without introducing six new properties?
Sorry it is board and IP as well SoC errata's,
1. Delay after power is required due to some voltage issues that will be fixed in next board revision
This is clearly not sdhci-specific, so make that a generic property for all mmc.
Quoted 2 lines
2. We need to support PIO mode as of now because DMA or ADMA requires some kind of translation driver that I am working on.
But this does not describe the hardware properties. Don't add properties that describe the lack of a kernel driver. If you can't do DMA yet, use a dma-ranges property that lists one empty range to prevent dma_set_mask() from working, so it will fall back to PIO mode. You may have to fix the driver if that doesn't already work.
What kind of driver do you need here?
Quoted 9 lines
3. The version of arasan variant we have in our SoC doesn't have the HISPD bit field in HI-SPEED SD card. So this makes HI-SPEED sdcard work.
4. NO_CMD23 is required for eMMC cards.
These are not new properties. Only the fact is I am using it for our SoC from dtb. These quirks are already there in mmc common framework. Nothing is new.
Are you sure that you have version 8.9a of the Arasan SDHCI? This sounds like version specific quirks, so they are probably present in each SoC that uses the same version.
Arnd

Signature · 3 lines

Thanks,
with regards,
Suman Tripathi

_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://lists.ozlabs.org/listinfo/linuxppc-dev

Suman Tripathi

author

2015-04-29 07:04 UTC #10 lore raw

PATCH RESEND v2 2/2 mmc: host: Add some quirks to be read from fdt in sdhci-pltm.c

In reply to Arnd Bergmann

Hi Arnd,

Please ignore the previous reply.

Quoted 20 lines · Arnd Bergmann

Quoted 19 lines · On Monday 27 April 2015 21:25:20 Suman Tripathi wrote:
Quoted 19 lines · On Monday 27 April 2015 20:33:25 Suman Tripathi wrote:
Quoted 18 lines
Quoted 6 lines · On Tuesday 21 April 2015 21:12:39 Suman Tripathi wrote:
Quoted 5 lines
drivers/mmc/host/sdhci-pltfm.c +4 -0
+                       host->quirks |= SDHCI_QUIRK_BROKEN_DMA;
+
+               if (of_get_property(np, "no-cmd23", NULL))
+                       host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
Quoted 7 lines
Quoted 3 lines
                if (of_get_property(np, "no-1-8-v", NULL))

                        host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
Any property you add needs to be documented in the DT binding. If possible, add generic properties for each bug you have mmc.txt rather than the driver specific sdhci.txt, and implement the
I will add the binding in mmc.txt. I thought this was present but not.
Quoted 1 line
parsing in a common function that is used for all mmc hosts.

Quoted 9 lines

Quoted 3 lines
Quoted 2 lines
Quoted 2 lines
As per mine understanding the sdhci_get_of_porperty is a common parsing function . Am I wrong ??
A small side note: please fix your email client to use proper attribution of the citations. The way you reply, nobody knows what you are saying compare to what you quote. Also, reduce the quotation to the parts you are replying to.

Okay. Sorry for that. I fixed it.

Quoted 9 lines

Quoted 3 lines
Quoted 1 line
No, this is only used for sdhci, not for the other controllers.
But our's is a SHCI variant so I added it in this file.
That's my point: a lot of the bugs are independent of the specific host controller and could happen with any one of them. We want to ensure that nobody tries to add another property with similar semantics and a different name just because they are using a different driver.

Then I am not finding a reason why we have sdhci_get_of_property function ?? .
I added a generic names like broken-adma that everyone can reuse it.
I made mistake of not adding it in the binding.

For eg : broken-cd is not added by me but I can use it. So I added something like broken-adma as it was not present.

Quoted 10 lines

Quoted 10 lines
Quoted 6 lines
Quoted 3 lines
An alternative would be to set all these bits based on the compatible string of your host, if that is the only one that has all these bugs.
The host driver (arasan) is reused but this quirks are needed due to board issues. so I have a control over dtb only to fix this.
What is the nature of the bug on that board? Is there a different way to describe that without introducing six new properties?

Quoted 8 lines

Quoted 4 lines
Sorry it is board and IP as well SoC errata's,
1. Delay after power is required due to some voltage issues that will be fixed in next board revision
This is clearly not sdhci-specific, so make that a generic property for all mmc.

Okay

Quoted 9 lines

Quoted 2 lines
2. We need to support PIO mode as of now because DMA or ADMA requires some kind of translation driver that I am working on.
But this does not describe the hardware properties. Don't add properties that describe the lack of a kernel driver. If you can't do DMA yet, use a dma-ranges property that lists one empty range to prevent dma_set_mask() from working, so it will fall back to PIO mode. You may have to fix the driver if that doesn't already work.

The generic sdhc framework doesn't have this capabiltiy. It uses the quirks to identify the broken DMA and ADMA modes even
if the controller is capable of.

Quoted 1 line

What kind of driver do you need here?

For DMA and adma we need some 32 bit to 64 bit translation driver. The existing arasan driver only support 32 bit.

Quoted 5 lines

Quoted 5 lines
3. The version of arasan variant we have in our SoC doesn't have the HISPD bit field in HI-SPEED SD card. So this makes HI-SPEED sdcard work.

Quoted 7 lines

Quoted 5 lines
4. NO_CMD23 is required for eMMC cards.
These are not new properties. Only the fact is I am using it for our SoC from dtb. These quirks are already there in mmc common framework. Nothing is new.
Are you sure that you have version 8.9a of the Arasan SDHCI? This sounds

No We are using 4.9a ARASAN SDHCI

Quoted 2 lines

like version specific quirks, so they are probably present in each SoC that uses the same version.

Not sure

Quoted 2 lines

Arnd

Signature · 3 lines

Thanks,
with regards,
Suman Tripathi

Arnd Bergmann

2015-04-29 09:15 UTC #11 lore raw

PATCH RESEND v2 2/2 mmc: host: Add some quirks to be read from fdt in sdhci-pltm.c

Quoted 25 lines · On Wednesday 29 April 2015 12:34:41 Suman Tripathi wrote:

Quoted 24 lines · Arnd Bergmann
Quoted 22 lines · On Monday 27 April 2015 21:25:20 Suman Tripathi wrote:
Quoted 21 lines · On Monday 27 April 2015 20:33:25 Suman Tripathi wrote:
Quoted 20 lines
Quoted 6 lines · On Tuesday 21 April 2015 21:12:39 Suman Tripathi wrote:
Quoted 5 lines
(quoted diff) +4 -0
+                       host->quirks |= SDHCI_QUIRK_BROKEN_DMA;
+
+               if (of_get_property(np, "no-cmd23", NULL))
+                       host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
Quoted 7 lines
Quoted 3 lines
                if (of_get_property(np, "no-1-8-v", NULL))

                        host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
Any property you add needs to be documented in the DT binding. If possible, add generic properties for each bug you have mmc.txt rather than the driver specific sdhci.txt, and implement the
I will add the binding in mmc.txt. I thought this was present but not.
Quoted 1 line
parsing in a common function that is used for all mmc hosts.
As per mine understanding the sdhci_get_of_porperty is a common parsing function . Am I wrong ??

Quoted 7 lines

Quoted 5 lines
A small side note: please fix your email client to use proper attribution of the citations. The way you reply, nobody knows what you are saying compare to what you quote. Also, reduce the quotation to the parts you are replying to.
Okay. Sorry for that. I fixed it.

Ok, much better.

Quoted 10 lines

Quoted 9 lines
Quoted 3 lines
Quoted 1 line
No, this is only used for sdhci, not for the other controllers.
But our's is a SHCI variant so I added it in this file.
That's my point: a lot of the bugs are independent of the specific host controller and could happen with any one of them. We want to ensure that nobody tries to add another property with similar semantics and a different name just because they are using a different driver.

Quoted 6 lines

Then I am not finding a reason why we have sdhci_get_of_property function ?? .
I added a generic names like broken-adma that everyone can reuse it.
I made mistake of not adding it in the binding.
For eg : broken-cd is not added by me but I can use it. So I added something like broken-adma as it was not present.

The common mmc_of_parse() handles "broken-cd", and the sdhci_get_of_property() does so too. This is really a mistake we made earlier when it was added to sdhi instead of the common code. We should remove the parsing for that property from the sdhci driver and have the core handle it always, but that require someone to do it and ensure that no subtle ABI changes are introduced on the way.

For new properties, the right way is to add it to the common function only.

Quoted 10 lines

Quoted 9 lines
Quoted 2 lines
2. We need to support PIO mode as of now because DMA or ADMA requires some kind of translation driver that I am working on.
But this does not describe the hardware properties. Don't add properties that describe the lack of a kernel driver. If you can't do DMA yet, use a dma-ranges property that lists one empty range to prevent dma_set_mask() from working, so it will fall back to PIO mode. You may have to fix the driver if that doesn't already work.

Quoted 8 lines

The generic sdhc framework doesn't have this capabiltiy. It uses the quirks to identify the broken DMA and ADMA modes even
if the controller is capable of.
Quoted 1 line
What kind of driver do you need here?
For DMA and adma we need some 32 bit to 64 bit translation driver. The existing arasan driver only support 32 bit.

Ok, that sounds like a very simple case: The width of the DMA is determined from DT by looking at the dma-ranges properties. If it doesn't work, one of these steps that are supposed to happen are broken and you should try to find out which one that is and fix it:

- The parent node of the sdhci device in DT must not claim to support 64 bit if the bus is only 32-bit wide. A dma-ranges property containing "<0 0 1 0>" would describe a bus that has a 32-bit DMA address range that is 1:1 mapped to the root bus, which is the default.

- The ARM64 code must check that property in a call to dma_set_mask() or dma_set_mask_and_coherent(), and not allow a mask to be set that exceeds the size of the dma-ranges property.

- The sdhci driver must call dma_set_mask() or dma_set_mask_and_coherent() with the mask that is claimed by the device (usually 32 bit or 64 bit) and check the result.

- If the call to dma_set_mask() for the 64-bit mask fails, the driver must fall back to using the 32-bit mask and not attempt to use the 64-bit DMA registers.

This is the behavior we require anyway, and if this all works, you don't need the extra quirks.

The above assumes that the limitation is enforced by the bus (e.g. an AHB bus can only do 32-bit DMA). It would be a little different if you have a 64-bit AXI bus and the Arasan device itself is limited to 32-bit independent of the width of the bus it is connected to. Can you find out which of these two cases you have?

Quoted 6 lines

Quoted 6 lines
Quoted 6 lines
3. The version of arasan variant we have in our SoC doesn't have the HISPD bit field in HI-SPEED SD card. So this makes HI-SPEED sdcard work.
4. NO_CMD23 is required for eMMC cards.

Quoted 7 lines

Quoted 5 lines
Quoted 3 lines
These are not new properties. Only the fact is I am using it for our SoC from dtb. These quirks are already there in mmc common framework. Nothing is new.
Are you sure that you have version 8.9a of the Arasan SDHCI? This sounds
No We are using 4.9a ARASAN SDHCI

Ok, then add a compatible string for this version to the arasan binding, and set the quirks flags only for the 4.9a version and not for the 8.9a version.

Arnd

Suman Tripathi

author

2015-04-29 14:25 UTC #12 lore raw

Re: [PATCH v2 RESEND 2/2] mmc: host: Add some quirks to be read from fdt in sdhci-pltm.c

Quoted 60 lines · Arnd Bergmann

Quoted 5 lines · On Wednesday 29 April 2015 12:34:41 Suman Tripathi wrote:
Quoted 4 lines · Arnd Bergmann
Quoted 3 lines · On Monday 27 April 2015 21:25:20 Suman Tripathi wrote:
Quoted 3 lines · On Monday 27 April 2015 20:33:25 Suman Tripathi wrote:
Quoted 2 lines
Quoted 2 lines · On Tuesday 21 April 2015 21:12:39 Suman Tripathi wrote:
Quoted 1 line
+ host->quirks |=
SDHCI_QUIRK_BROKEN_DMA;
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Review
Quoted 3 lines
(quoted diff) +3 -0
+
+               if (of_get_property(np, "no-cmd23", NULL))
+                       host->quirks2 |=
SDHCI_QUIRK2_HOST_NO_CMD23;
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
                if (of_get_property(np, "no-1-8-v", NULL))

                        host->quirks2 |=
SDHCI_QUIRK2_NO_1_8_V;
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Any property you add needs to be documented in the DT binding. If possible, add generic properties for each bug you have
mmc.txt
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
rather than the driver specific sdhci.txt, and implement the
I will add the binding in mmc.txt. I thought this was present but
not.
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
parsing in a common function that is used for all mmc hosts.
As per mine understanding the sdhci_get_of_porperty is a common parsing function . Am I wrong ??
A small side note: please fix your email client to use proper
attribution
Quoted 6 lines
Quoted 4 lines
of the citations. The way you reply, nobody knows what you are saying compare to what you quote. Also, reduce the quotation to the parts you are replying to.
Okay. Sorry for that. I fixed it.
Ok, much better.
Quoted 11 lines
Quoted 9 lines
Quoted 3 lines
Quoted 1 line
No, this is only used for sdhci, not for the other controllers.
But our's is a SHCI variant so I added it in this file.
That's my point: a lot of the bugs are independent of the specific host controller and could happen with any one of them. We want to ensure that nobody tries to add another property with similar semantics and a different name just because they are using a different driver.
Then I am not finding a reason why we have sdhci_get_of_property
function ?? .
Quoted 5 lines
I added a generic names like broken-adma that everyone can reuse it.
I made mistake of not adding it in the binding.
For eg : broken-cd is not added by me but I can use it. So I added something like broken-adma as it was not present.

Quoted 8 lines

The common mmc_of_parse() handles "broken-cd", and the sdhci_get_of_property()
does so too. This is really a mistake we made earlier when it was added to sdhi instead of the common code. We should remove the parsing for that property from the sdhci driver and have the core handle it always, but that require someone to do it and ensure that no subtle ABI changes are introduced on the way.

I was not aware of the mmc_of_parse() . Agree now.

Quoted 38 lines

For new properties, the right way is to add it to the common function only.
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
2. We need to support PIO mode as of now because DMA or ADMA requires some kind of translation driver that I am working on.
But this does not describe the hardware properties. Don't add
properties
Quoted 6 lines
Quoted 5 lines
that describe the lack of a kernel driver. If you can't do DMA yet, use a dma-ranges property that lists one empty range to prevent dma_set_mask() from working, so it will fall back to PIO mode. You may have to fix the driver if that doesn't already work.
Quoted 8 lines
The generic sdhc framework doesn't have this capabiltiy. It uses the quirks to identify the broken DMA and ADMA modes even
if the controller is capable of.
Quoted 1 line
What kind of driver do you need here?
For DMA and adma we need some 32 bit to 64 bit translation driver. The existing arasan driver only support 32 bit.
Ok, that sounds like a very simple case: The width of the DMA is determined from DT by looking at the dma-ranges properties. If it doesn't work, one of these steps that are supposed to happen are broken and you should try to find out which one that is and fix it:
- The parent node of the sdhci device in DT must not claim to support 64 bit if the bus is only 32-bit wide. A dma-ranges property containing "<0 0 1 0>" would describe a bus that has a 32-bit DMA address range that is 1:1 mapped to the root bus, which is the default.
- The ARM64 code must check that property in a call to dma_set_mask() or dma_set_mask_and_coherent(), and not allow a mask to be set that exceeds the size of the dma-ranges property.

Quoted 8 lines

- The sdhci driver must call dma_set_mask() or dma_set_mask_and_coherent() with the mask that is claimed by the device (usually 32 bit or 64 bit) and check the result.
- If the call to dma_set_mask() for the 64-bit mask fails, the driver must fall back to using the 32-bit mask and not attempt to use the 64-bit DMA registers.

This is the behavior we require anyway, and if this all works, you don't

Quoted 8 lines

need the extra quirks.
The above assumes that the limitation is enforced by the bus (e.g. an AHB bus can only do 32-bit DMA). It would be a little different if you have a 64-bit AXI bus and the Arasan device itself is limited to 32-bit independent of the width of the bus it is connected to. Can you find out which of these two cases you have?

We have 64 bit AXI and Arasan device or controller is 32 bit . So there is 64 bit AXI to 32 bit AHB translation.

Quoted 10 lines

Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
3. The version of arasan variant we have in our SoC doesn't have the HISPD bit field in HI-SPEED SD card. So this makes HI-SPEED sdcard work.
4. NO_CMD23 is required for eMMC cards.
These are not new properties. Only the fact is I am using it for our SoC from dtb. These quirks are already there in mmc common framework. Nothing is new.

Quoted 9 lines

Quoted 1 line
Quoted 1 line
Are you sure that you have version 8.9a of the Arasan SDHCI? This
sounds
Quoted 2 lines
No We are using 4.9a ARASAN SDHCI
Ok, then add a compatible string for this version to the arasan binding, and set the quirks flags only for the 4.9a version and not for the 8.9a version.

Okay

Quoted 3 lines

Arnd

Signature · 3 lines

Thanks,
with regards,
Suman Tripathi

_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://lists.ozlabs.org/listinfo/linuxppc-dev

Arnd Bergmann

2015-04-29 14:45 UTC #13 lore raw

PATCH RESEND v2 2/2 mmc: host: Add some quirks to be read from fdt in sdhci-pltm.c

Quoted 10 lines · On Wednesday 29 April 2015 19:55:53 Suman Tripathi wrote:

Quoted 7 lines
The above assumes that the limitation is enforced by the bus (e.g. an AHB bus can only do 32-bit DMA). It would be a little different if you have a 64-bit AXI bus and the Arasan device itself is limited to 32-bit independent of the width of the bus it is connected to. Can you find out which of these two cases you have?
We have 64 bit AXI and Arasan device or controller is 32 bit . So there is 64 bit AXI to 32 bit AHB translation.

Please be very specific here. If this is an AHB based MMC controller, you should model that AHB bus in DT, with the 32-bit dma-ranges.

However, if this is an AXI based MMC controller that is limited to 32-bit DMA, the correct change would be to make ensure that the driver never asks for a 64-bit DMA mask with this hardware.

Both will result in a 32-bit dma mask being used, and high DMA handled through the block bounce code or swiotlb, but it's best to ensure that the DT representation matches the actual hardware as closely as possible, so it keeps working when you change something in a future chip.

Arnd