On 03/31/2015 08:49 AM, Martin Sperl wrote:
On 28.03.2015, at 05:09, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
As for testing: I have also tried to test with mmc_spi, but I have not
been able to make that driver work reliably in any recent kernel
versions.
Most of the time I see timeouts - and with lots of different SD-cards...
IIRC the last time I tested it successfully was with 3.12.
It'd be great if you could use "git bisect" to track down the change
that broke this.
...
Bisection between these shows the responsible commit is:
...
commit 0589342c27944e50ebd7a54f5215002b6598b748
Author: Rob Herring <rob.herring@xxxxxxxxxxx>
Date: Tue Oct 29 23:36:46 2013 -0500
of: set dma_mask to point to coherent_dma_mask
Platform devices created by DT code don't initialize dma_mask pointer to
anything. Set it to coherent_dma_mask by default if the architecture
code has not set it.
Signed-off-by: Rob Herring <rob.herring@xxxxxxxxxxx>
...
Now I went back to 4.0.rc5+ and patched it as follows:
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -179,9 +179,10 @@ static void of_dma_configure(struct device *dev)
* Set it to coherent_dma_mask by default if the architecture
* code has not set it.
*/
+/*
if (!dev->dma_mask)
dev->dma_mask = &dev->coherent_dma_mask;
-
+*/
ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
if (ret < 0) {
dma_addr = offset = 0;
And now it works - the SD card gets detected immediately,
I can mount it and everything...
Does that change cause the SDHCI core to use vs. not-use any of the
SDHCI DMA modes? If so, I wonder if this is because the upstream kernel
doesn't deal with the bcm2835's ARM physical address <-> SoC bus address
conversions, which in turn can cause DMA and CPU access to not use the
same caching settings and become incoherent, which in turn can cause DMA
data corruption. See the following link for some background:
https://www.mail-archive.com/u-boot@xxxxxxxxxxxxx/msg167376.html
[PATCH 2/3] ARM: bcm2835: implement phys_to_bus/bus_to_phys
(you'll want to read all of patches 1-3 for the complete background I
think, but patch 2 describes the HW issue)
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
