Skip to contentSkip to conversation

ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask

PATCH New Alexander Kurz 9 participants 19 messages Apr 11, 2016 – Apr 29, 2016 1 message not in the archive

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask

With commit 7b91369b DMA access got disabled for device drivers with zero DMA mask property. sdhci-esdhc-imx got blocked from DMA access by this.
Hence: initialize the dma mask to enable access again.

---
 arch/arm/mach-imx/devices/platform-sdhci-esdhc-imx.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
arch/arm/mach-imx/devices/platform-sdhci-esdhc-imx.c +3 -2
index a5edd7d..3d039ef 100644
@@ -71,6 +71,7 @@ struct platform_device *__init imx_add_sdhci_esdhc_imx(
 	if (!pdata)
 		pdata = &default_esdhc_pdata;
 
-	return imx_add_platform_device(data->devid, data->id, res,
-			ARRAY_SIZE(res), pdata, sizeof(*pdata));
+	return imx_add_platform_device_dmamask(data->devid, data->id, res,
+			ARRAY_SIZE(res), pdata, sizeof(*pdata),
+			DMA_BIT_MASK(32));
 }
Signature · 1 line
2.1.4
#1 lore raw

PATCH 1/1 ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask

Hello,

I added the people involved in 7b91369b4655 to Cc.

Quoted 1 line · Alexander Kurz

With commit 7b91369b DMA access got disabled for device drivers with zero

Please reference commits like:

With commit 7b91369b4655 ("mmc: sdhci: Set DMA mask when adding host") DMA access ...

Quoted 26 lines

DMA mask property. sdhci-esdhc-imx got blocked from DMA access by this.
Hence: initialize the dma mask to enable access again.

---
 arch/arm/mach-imx/devices/platform-sdhci-esdhc-imx.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
arch/arm/mach-imx/devices/platform-sdhci-esdhc-imx.c +3 -2
index a5edd7d..3d039ef 100644
@@ -71,6 +71,7 @@ struct platform_device *__init imx_add_sdhci_esdhc_imx(
 	if (!pdata)
 		pdata = &default_esdhc_pdata;
 
-	return imx_add_platform_device(data->devid, data->id, res,
-			ARRAY_SIZE(res), pdata, sizeof(*pdata));
+	return imx_add_platform_device_dmamask(data->devid, data->id, res,
+			ARRAY_SIZE(res), pdata, sizeof(*pdata),
+			DMA_BIT_MASK(32));
 }
Signature · 1 line
2.1.4
Signature · 2 lines
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
#2 lore raw

PATCH 1/1 ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask

Quoted 6 lines · Uwe Kleine-K?nig

Hello,

I added the people involved in 7b91369b4655 to Cc.

Quoted 1 line · Alexander Kurz

With commit 7b91369b DMA access got disabled for device drivers with zero

Is that because dma_set_mask_and_coherent() fails?

Quoted 34 lines

Please reference commits like:

With commit 7b91369b4655 ("mmc: sdhci: Set DMA mask when adding host") DMA access ...

Quoted 26 lines

DMA mask property. sdhci-esdhc-imx got blocked from DMA access by this.
Hence: initialize the dma mask to enable access again.

---
 arch/arm/mach-imx/devices/platform-sdhci-esdhc-imx.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
arch/arm/mach-imx/devices/platform-sdhci-esdhc-imx.c +3 -2
index a5edd7d..3d039ef 100644
@@ -71,6 +71,7 @@ struct platform_device *__init imx_add_sdhci_esdhc_imx(
 	if (!pdata)
 		pdata = &default_esdhc_pdata;
 
-	return imx_add_platform_device(data->devid, data->id, res,
-			ARRAY_SIZE(res), pdata, sizeof(*pdata));
+	return imx_add_platform_device_dmamask(data->devid, data->id, res,
+			ARRAY_SIZE(res), pdata, sizeof(*pdata),
+			DMA_BIT_MASK(32));
 }
Signature · 1 line
2.1.4
#3 lore raw

PATCH 1/1 ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask

Hi Adrian,

Quoted 9 lines · Adrian Hunter
Quoted 6 lines · Uwe Kleine-K?nig

Hello,

I added the people involved in 7b91369b4655 to Cc.

Quoted 1 line · Alexander Kurz

With commit 7b91369b DMA access got disabled for device drivers with zero

Is that because dma_set_mask_and_coherent() fails?

right, dma_set_mask_and_coherent() fails, thats the only reason for this patch. This popped up on a Kindle3 (IMX35 with eMMC based root fs).

Sorry for the checkpatch / improper commit citation issue.

Quoted 36 lines
Quoted 35 lines

Please reference commits like:

With commit 7b91369b4655 ("mmc: sdhci: Set DMA mask when adding host") DMA access ...

Quoted 26 lines

DMA mask property. sdhci-esdhc-imx got blocked from DMA access by this.
Hence: initialize the dma mask to enable access again.

---
 arch/arm/mach-imx/devices/platform-sdhci-esdhc-imx.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
arch/arm/mach-imx/devices/platform-sdhci-esdhc-imx.c +3 -2
index a5edd7d..3d039ef 100644
@@ -71,6 +71,7 @@ struct platform_device *__init imx_add_sdhci_esdhc_imx(
 	if (!pdata)
 		pdata = &default_esdhc_pdata;
 
-	return imx_add_platform_device(data->devid, data->id, res,
-			ARRAY_SIZE(res), pdata, sizeof(*pdata));
+	return imx_add_platform_device_dmamask(data->devid, data->id, res,
+			ARRAY_SIZE(res), pdata, sizeof(*pdata),
+			DMA_BIT_MASK(32));
 }
Signature · 1 line
2.1.4
#4 lore raw

PATCH 1/1 ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask

Quoted 6 lines · Alexander Kurz

Hi Adrian,

Quoted 3 lines · Adrian Hunter
Quoted 2 lines · Uwe Kleine-K?nig

Hello,

Quoted 8 lines
Quoted 6 lines
Quoted 4 lines

I added the people involved in 7b91369b4655 to Cc.

Quoted 1 line · Alexander Kurz

With commit 7b91369b DMA access got disabled for device drivers with zero

Is that because dma_set_mask_and_coherent() fails?

right, dma_set_mask_and_coherent() fails, thats the only reason for this patch. This popped up on a Kindle3 (IMX35 with eMMC based root fs).

Arnd, Alexandre : Why should dma_set_mask_and_coherent() fail in this case when DMA apparently doesn't need a dma_mask anyway?

Quoted 38 lines

Sorry for the checkpatch / improper commit citation issue.

Quoted 35 lines
Quoted 35 lines

Please reference commits like:

With commit 7b91369b4655 ("mmc: sdhci: Set DMA mask when adding host") DMA access ...

Quoted 26 lines

DMA mask property. sdhci-esdhc-imx got blocked from DMA access by this.
Hence: initialize the dma mask to enable access again.

---
 arch/arm/mach-imx/devices/platform-sdhci-esdhc-imx.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
arch/arm/mach-imx/devices/platform-sdhci-esdhc-imx.c +3 -2
index a5edd7d..3d039ef 100644
@@ -71,6 +71,7 @@ struct platform_device *__init imx_add_sdhci_esdhc_imx(
 	if (!pdata)
 		pdata = &default_esdhc_pdata;
 
-	return imx_add_platform_device(data->devid, data->id, res,
-			ARRAY_SIZE(res), pdata, sizeof(*pdata));
+	return imx_add_platform_device_dmamask(data->devid, data->id, res,
+			ARRAY_SIZE(res), pdata, sizeof(*pdata),
+			DMA_BIT_MASK(32));
 }
Signature · 1 line
2.1.4
#5 lore raw

PATCH 1/1 ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask

Quoted 10 lines · Adrian Hunter
Quoted 9 lines · Alexander Kurz

Hi Adrian,

Quoted 6 lines · Adrian Hunter
Quoted 5 lines · Uwe Kleine-K?nig

Hello,

I added the people involved in 7b91369b4655 to Cc.

On Mon, Apr 11, 2016 at 10:20:46AM +0200, Alexander Kurz wrote:

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line

With commit 7b91369b DMA access got disabled for device drivers with zero

Is that because dma_set_mask_and_coherent() fails?

right, dma_set_mask_and_coherent() fails, thats the only reason for this patch. This popped up on a Kindle3 (IMX35 with eMMC based root fs).

Arnd, Alexandre : Why should dma_set_mask_and_coherent() fail in this case when DMA apparently doesn't need a dma_mask anyway?

What do you mean "doesn't need a dma_mask" ? DMA _always_ requires a DMA mask. The DMA mask defines how many address bits are capable of being used on the bus.

If there's no DMA mask, then there's no usable address bits, and so the device is not DMA capable. Hence, dma_set_mask_and_coherent() will fail because its not possible to negotiate a non-zero number of address bits.

Signature · 3 lines
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
#6 lore raw

PATCH 1/1 ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask

Quoted 20 lines · Russell King - ARM Linux
Quoted 10 lines · Adrian Hunter
Quoted 9 lines · Alexander Kurz

Hi Adrian,

Quoted 6 lines · Adrian Hunter
Quoted 5 lines · Uwe Kleine-K?nig

Hello,

I added the people involved in 7b91369b4655 to Cc.

On Mon, Apr 11, 2016 at 10:20:46AM +0200, Alexander Kurz wrote:

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line

With commit 7b91369b DMA access got disabled for device drivers with zero

Is that because dma_set_mask_and_coherent() fails?

right, dma_set_mask_and_coherent() fails, thats the only reason for this patch. This popped up on a Kindle3 (IMX35 with eMMC based root fs).

Arnd, Alexandre : Why should dma_set_mask_and_coherent() fail in this case when DMA apparently doesn't need a dma_mask anyway?

Quoted 9 lines

What do you mean "doesn't need a dma_mask" ? DMA _always_ requires a DMA mask. The DMA mask defines how many address bits are capable of being used on the bus.

If there's no DMA mask, then there's no usable address bits, and so the device is not DMA capable. Hence, dma_set_mask_and_coherent() will fail because its not possible to negotiate a non-zero number of address bits.

The point is, now we valid dma_set_mask_and_coherent(), DMA will stop working for any other SDHCI device that hasn't allocated dev.dma_mask. Is that OK?

#7 lore raw

PATCH 1/1 ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask

Quoted 31 lines · Adrian Hunter
Quoted 20 lines · Russell King - ARM Linux
Quoted 10 lines · Adrian Hunter
Quoted 9 lines · Alexander Kurz

Hi Adrian,

Quoted 6 lines · Adrian Hunter
Quoted 5 lines · Uwe Kleine-K?nig

Hello,

I added the people involved in 7b91369b4655 to Cc.

On Mon, Apr 11, 2016 at 10:20:46AM +0200, Alexander Kurz wrote:

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line

With commit 7b91369b DMA access got disabled for device drivers with zero

Is that because dma_set_mask_and_coherent() fails?

right, dma_set_mask_and_coherent() fails, thats the only reason for this patch. This popped up on a Kindle3 (IMX35 with eMMC based root fs).

Arnd, Alexandre : Why should dma_set_mask_and_coherent() fail in this case when DMA apparently doesn't need a dma_mask anyway?

Quoted 9 lines

What do you mean "doesn't need a dma_mask" ? DMA _always_ requires a DMA mask. The DMA mask defines how many address bits are capable of being used on the bus.

If there's no DMA mask, then there's no usable address bits, and so the device is not DMA capable. Hence, dma_set_mask_and_coherent() will fail because its not possible to negotiate a non-zero number of address bits.

Quoted 3 lines

The point is, now we valid dma_set_mask_and_coherent(), DMA will stop working for any other SDHCI device that hasn't allocated dev.dma_mask. Is that OK?

Clearly these devices need to be fixed. If we want to give them a grace period, we could also (temporarily) not propagate the return value of dma_set_mask_and_coherent() and limit ourselves to emitting a big warning about the inconsistency of having SDHCI_USE_SDMA/SDHCI_USE_ADMA in the host flags while not setting a dma mask.

But in the past, how prompt have people been to react to such warnings vs. their device not working as expected?

#8 lore raw

PATCH 1/1 ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask

Quoted 5 lines · Alexandre Courbot

Clearly these devices need to be fixed. If we want to give them a grace period, we could also (temporarily) not propagate the return value of dma_set_mask_and_coherent() and limit ourselves to emitting a big warning about the inconsistency of having SDHCI_USE_SDMA/SDHCI_USE_ADMA in the host flags while not setting a dma mask.

Isn't it just easier to fix the root problem? It'll be one patch.

There's no need to add churn by changing sdhci stuff, then fixing the imx stuff, and then reverting the sdhci changes.

Signature · 3 lines
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
#9 lore raw

PATCH 1/1 ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask

Quoted 11 lines · Russell King - ARM Linux
Quoted 5 lines · Alexandre Courbot

Clearly these devices need to be fixed. If we want to give them a grace period, we could also (temporarily) not propagate the return value of dma_set_mask_and_coherent() and limit ourselves to emitting a big warning about the inconsistency of having SDHCI_USE_SDMA/SDHCI_USE_ADMA in the host flags while not setting a dma mask.

Isn't it just easier to fix the root problem? It'll be one patch.

There's no need to add churn by changing sdhci stuff, then fixing the imx stuff, and then reverting the sdhci changes.

I think Adrian was concerned that other SDHCI drivers might unknowingly be in the same case. That being said I am also in favor of fixing the root issue instead of adding temporary glue that we might eventually forget to remove...

How long it will take for everyone to fix their drivers is another question, since the device doesn't clearly break, but falls back to a degraded mode with a warning.

#10 lore raw

PATCH 1/1 ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask

Quoted 8 lines · Alexandre Courbot
Quoted 7 lines · Russell King - ARM Linux
Quoted 5 lines · Alexandre Courbot

Clearly these devices need to be fixed. If we want to give them a grace period, we could also (temporarily) not propagate the return value of dma_set_mask_and_coherent() and limit ourselves to emitting a big warning about the inconsistency of having SDHCI_USE_SDMA/SDHCI_USE_ADMA in the host flags while not setting a dma mask.

Quoted 7 lines
Quoted 4 lines

Isn't it just easier to fix the root problem? It'll be one patch.

There's no need to add churn by changing sdhci stuff, then fixing the imx stuff, and then reverting the sdhci changes.

I think Adrian was concerned that other SDHCI drivers might unknowingly be in the same case.

Yes, that is the concern.

Quoted 3 lines

That being said I am also in favor of fixing the root
issue instead of adding temporary glue that we might eventually forget to remove...

Yes, temporary glue just defers the problem.

Quoted 5 lines

How long it will take for everyone to fix their drivers is another question, since the device doesn't clearly break, but falls back to a degraded mode with a warning.

It looks like DeviceTree, PCI and ACPI enumerated devices always set up a dma_mask. I guess that just leaves devices enumerated from hard-coded platform data. I will have a look for any more of those, and also send an email for affected people to check their device setup and drivers.

#11 lore raw

PATCH 1/1 ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask

Quoted 9 lines · On Wednesday 13 April 2016 11:07:16 Adrian Hunter wrote:
Quoted 7 lines · Alexandre Courbot
Quoted 1 line · Russell King - ARM Linux

On Tue, Apr 12, 2016 at 09:25:04PM +0900, Alexandre Courbot wrote:

How long it will take for everyone to fix their drivers is another question, since the device doesn't clearly break, but falls back to a degraded mode with a warning.

Quoted 5 lines

It looks like DeviceTree, PCI and ACPI enumerated devices always set up a dma_mask. I guess that just leaves devices enumerated from hard-coded platform data. I will have a look for any more of those, and also send an email for affected people to check their device setup and drivers.

I've had a look now too and found only these three device definitions for any sdhci variant, everything else is either unused or DT-only:

arch/arm/mach-dove/common.c:    .name           = "sdhci-dove",
arch/arm/plat-samsung/devs.c:   .name           = "s3c-sdhci",

arch/arm/mach-imx/devices/platform-sdhci-esdhc-imx.c: imx_sdhci_esdhc_imx_data_entry(MX25, "sdhci-esdhc-imx25", _id, _hwid)
arch/arm/mach-imx/devices/platform-sdhci-esdhc-imx.c: imx_sdhci_esdhc_imx_data_entry(MX35, "sdhci-esdhc-imx35", _id, _hwid)

Out of these, the s3c and dove variants set a 32-bit DMA mask, so as far as I can tell, only imx has the problem.

Arnd

#12 lore raw

PATCH 1/1 ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask

Quoted 19 lines · Arnd Bergmann
Quoted 9 lines · On Wednesday 13 April 2016 11:07:16 Adrian Hunter wrote:
Quoted 7 lines · Alexandre Courbot
Quoted 1 line · Russell King - ARM Linux

On Tue, Apr 12, 2016 at 09:25:04PM +0900, Alexandre Courbot wrote:

How long it will take for everyone to fix their drivers is another question, since the device doesn't clearly break, but falls back to a degraded mode with a warning.

Quoted 5 lines

It looks like DeviceTree, PCI and ACPI enumerated devices always set up a dma_mask. I guess that just leaves devices enumerated from hard-coded platform data. I will have a look for any more of those, and also send an email for affected people to check their device setup and drivers.

I've had a look now too and found only these three device definitions for any sdhci variant, everything else is either unused or DT-only:

Quoted 8 lines
arch/arm/mach-dove/common.c:    .name           = "sdhci-dove",
arch/arm/plat-samsung/devs.c:   .name           = "s3c-sdhci",

arch/arm/mach-imx/devices/platform-sdhci-esdhc-imx.c: imx_sdhci_esdhc_imx_data_entry(MX25, "sdhci-esdhc-imx25", _id, _hwid)
arch/arm/mach-imx/devices/platform-sdhci-esdhc-imx.c: imx_sdhci_esdhc_imx_data_entry(MX35, "sdhci-esdhc-imx35", _id, _hwid)

Out of these, the s3c and dove variants set a 32-bit DMA mask, so as far as I can tell, only imx has the problem.

Thanks for looking.

It looked to me like sdhci-pxav3 devices created by mmp2_add_sdhost() might also be candidates.

#13 lore raw

PATCH 1/1 ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask

Quoted 6 lines · On Monday 18 April 2016 09:58:04 Adrian Hunter wrote:

Thanks for looking.

It looked to me like sdhci-pxav3 devices created by mmp2_add_sdhost() might also be candidates.

Oh, you are right, I missed that.

I remember looking at sdhci-pxav2 and not finding any machine defining one, but I must have skipped over sdhci-pxav3 failing to realize that this is a different one.

Arnd

A message that is not in the archive (sent off-list or not yet received): [email protected]

#15 lore raw

Potential issue with SDHCI DMA

+ linux-mmc

Quoted 44 lines · Adrian Hunter
Quoted 8 lines · Arnd Bergmann
Quoted 6 lines · On Monday 18 April 2016 09:58:04 Adrian Hunter wrote:

Thanks for looking.

It looked to me like sdhci-pxav3 devices created by mmp2_add_sdhost() might also be candidates.

Quoted 8 lines

Oh, you are right, I missed that.

I remember looking at sdhci-pxav2 and not finding any machine defining one, but I must have skipped over sdhci-pxav3 failing to realize that this is a different one.

Arnd

OK, so my plan to email sdhci driver maintainers ran into a snag. It turned out to be too hard to dig up email addresses. I have grabbed a few names and cc'ed them to this email anyway.

For those people, the issue is this:

An unexpected side-effect of commit 7b91369b4655 ("mmc: sdhci: Set DMA mask when adding host") is that SDHCI devices that do not define a DMA mask may find that DMA no longer works. That was the case for a sdhci-esdhc-imx device, but that has been fixed - refer commit fc26fe9c3869 ("ARM: mach-imx:
sdhci-esdhc-imx: initialize DMA mask").

DeviceTree, ACPI and PCI always set up a DMA mask for devices that they enumerate, so only hard-coded platform devices are expected to be affected.

We found only one other candidate: sdhci-pxav3 devices created by mmp2_add_sdhost(). Not sure if anyone has looked at that though.

Obviously, if you are unsure if your devices are affected, you can test and if there is a problem you will see the warning messages "mmcX: Failed to set 32-bit DMA mask" and "mmcX: No suitable DMA available - falling back to PIO".

Regards
Adrian

#16 lore raw

Potential issue with SDHCI DMA

Dear Adrian,

Quoted 38 lines · On Fri, 29 Apr 2016 11:59:39 +0300 Adrian Hunter wrote:

+ linux-mmc

Quoted 35 lines · Adrian Hunter
Quoted 8 lines · Arnd Bergmann
Quoted 6 lines · On Monday 18 April 2016 09:58:04 Adrian Hunter wrote:

Thanks for looking.

It looked to me like sdhci-pxav3 devices created by mmp2_add_sdhost() might also be candidates.

Quoted 8 lines

Oh, you are right, I missed that.

I remember looking at sdhci-pxav2 and not finding any machine defining one, but I must have skipped over sdhci-pxav3 failing to realize that this is a different one.

Arnd

OK, so my plan to email sdhci driver maintainers ran into a snag. It turned out to be too hard to dig up email addresses. I have grabbed a few names and cc'ed them to this email anyway.

For those people, the issue is this:

An unexpected side-effect of commit 7b91369b4655 ("mmc: sdhci: Set DMA mask when adding host") is that SDHCI devices that do not define a DMA mask may find that DMA no longer works. That was the case for a sdhci-esdhc-imx device, but that has been fixed - refer commit fc26fe9c3869 ("ARM: mach-imx:
sdhci-esdhc-imx: initialize DMA mask").

DeviceTree, ACPI and PCI always set up a DMA mask for devices that they enumerate, so only hard-coded platform devices are expected to be affected.

We found only one other candidate: sdhci-pxav3 devices created by mmp2_add_sdhost(). Not sure if anyone has looked at that though.

Thanks for the kind remind. All Marvell berlin SoCs' linux kernel (no matter upstreamed or internal) are DT based, so we (berlin SoCs) are not affected by this issue.

I'm not sure who is maintaining mmp.

Thanks,
Jisheng

Quoted 10 lines
Quoted 9 lines

Obviously, if you are unsure if your devices are affected, you can test and if there is a problem you will see the warning messages "mmcX: Failed to set 32-bit DMA mask" and "mmcX: No suitable DMA available - falling back to PIO".

Regards
Adrian

#17 lore raw

PATCH 1/1 ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask

In reply to Adrian Hunter
Quoted 11 lines · Adrian Hunter
Quoted 9 lines · Russell King - ARM Linux

What do you mean "doesn't need a dma_mask" ? DMA _always_ requires a DMA mask. The DMA mask defines how many address bits are capable of being used on the bus.

If there's no DMA mask, then there's no usable address bits, and so the device is not DMA capable. Hence, dma_set_mask_and_coherent() will fail because its not possible to negotiate a non-zero number of address bits.

Quoted 3 lines

The point is, now we valid dma_set_mask_and_coherent(), DMA will stop working for any other SDHCI device that hasn't allocated dev.dma_mask. Is that OK?

Two latent bugs.

1) Any device that doesn't have dma_mask allocated isn't capable of streaming DMA, but may be capable of coherent DMA - a device which is capable _should_ have a defaulted dma_mask setup.

2) Drivers must always use the dma_set_mask*() family of functions if they intend to use DMA.

Requirement (2) is nothing new, and predates MMC as a whole, so it's a long-standing latent bug.

Signature · 3 lines
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
#18 lore raw

PATCH 1/1 ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask

In reply to Alexander Kurz

Hello.

Quoted 1 line · Alexander Kurz

With commit 7b91369b DMA access got disabled for device drivers with zero

scripts/checkpatch.pl enforces certain commit citing style, your doesn't
match it.

Quoted 2 lines

DMA mask property. sdhci-esdhc-imx got blocked from DMA access by this.
Hence: initialize the dma mask to enable access again.

DMA -- please be consistent.

Quoted 1 line

[...]

MBR, Sergei

#19 lore raw

PATCH 1/1 ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask

In reply to Alexander Kurz
Quoted 5 lines · Alexander Kurz

With commit 7b91369b DMA access got disabled for device drivers with zero DMA mask property. sdhci-esdhc-imx got blocked from DMA access by this.
Hence: initialize the dma mask to enable access again.

I fixed up the commit log per comments from Uwe and Sergei, and then applied the patch as a fix for v4.6-rc.

Shawn