mmc_spi: has anyone been successfully using it with one of the newest kernels?

[msperl]

Hi!

has anyone been able to run mmc_spi with one of the latest kernels?
The last time I have tried I was still on 3.12 or earlier - now I only get error messages like this:
mmc1: error -110 whilst initialising SD card
-110 would mean -ETIMEDOUT.

And that with 8 different SD-Cards.

Might be related to kernel versions...

Any Ideas?

Martin

[malgrati-ferdinando]

are you using spi-gpio.ko?

2015-03-26 17:10 GMT+01:00 msperl [email protected]:

Hi!

has anyone been able to run mmc_spi with one of the latest kernels?
The last time I have tried I was still on 3.12 or earlier - now I only get
error messages like this:
mmc1: error -110 whilst initialising SD card
-110 would mean -ETIMEDOUT.

And that with 8 different SD-Cards.

Might be related to kernel versions...

Any Ideas?

Martin

—
Reply to this email directly or view it on GitHub
#911.

[msperl]

no - the native spi-bcm2835 driver.

[msperl]

note that I have bisected as far as:
Working: 3.9.11-d5572370289f698b101f3d0198b1c99f17f0d278
Failing: 3.10.38-1b49b450222df26e4abf7abb6d9302f72b2ed386

Has anyone a hint what the earliest commit of 3.10 is that works on the rpi?

All commits in the 3.10 I have tried so far miss arch/arm/mach-bcm2708/bcm2708.c, so they have not been merged that early during the 3.10 cycle...

[msperl]

note that on a 4.0-rc5 the following seems to solve the issue:
(after bisecting the issue with an upstream kernel)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b189733..28e7286 100644
--- 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;

I have not tried it with a foundation kernel (yet), but it seems likely to work as well.
Why this has such a strange impact is an open question...

[Ruffio]

@msperl has your issue been resolved? If so, please close this issue. Thanks.

[msperl]

Well - afaik this has not been fixed upstream, so I assume it is not fixed downstream either (unless you have applied the above patch here: msperl@aef50a1).

So many in reality it does not make any sense compiling spi_mmc unless the patch is applied.

So from my perspective it is your call if you want to apply a variation of the patch or if you want to ship a broken driver.

You can also close the issue.

[popcornmix]

Has this been reported upstream?
We'd prefer not to apply the patch without some sort of upstream acknowledgement that it is the correct thing to do. I can't judge if the patch will create any new issues.
Of course if upstream accepts a fix for this we'll be happy to cherry-pick it.

[msperl]

The point is that it is still unclear why it fails with the dma code - or even just this section - enabled, so I guess upstream will not accept a bandaid patch. And as I am not using it (unless I work on spi-bcm2835, where I use it for test purposes)I am not pushing it.

Fact is that it does not work with a set dma_mask and you are shipping it broken right now.

[JamesH65]

@msperl Any movement on this on latest kernel?

[JamesH65]

Will be closing soon if no furthur comments.

[JamesH65]

Closing due to lack of activity. Reopen if you feel this issue is still relevant.

[TheCrazyT]

I honestly don't know why nobody complained about it.
I only got it to work after patching the mmc_spi.c at the following locations:

https://github.com/raspberrypi/linux/blob/rpi-6.1.y/drivers/mmc/host/mmc_spi.c#L1513
https://github.com/raspberrypi/linux/blob/rpi-6.1.y/drivers/mmc/host/mmc_spi.c#L1519

I patched it because spi_probe was never actually invoking mmc_spi_probe .
Somehow I then managed to figure out the problem was the check in spi_match_device.

Changed both "mmc-spi-slot" to "mmc_spi"

and used the following overlay "mmc_spi.dts":

/dts-v1/;
/plugin/;

/ {
   compatible = "brcm,bcm2835", "brcm,bcm2836", "brcm,bcm2708", "brcm,bcm2709";

   fragment@0 {
                target = <&spidev0>;
                __overlay__ {
                        status = "disabled";
                };
   };

   fragment@1 {
      target = <&spi0>;
      __overlay__ {
         // needed to avoid dtc warning
         #address-cells = <1>;
         #size-cells = <0>;
         status = "okay";
         sd1: sd1@0 {
                reg = <0>;
                status = "okay";
                compatible = "spi,mmc_spi";
                voltage-ranges = <3000 3500>;
                spi-max-frequency = <8000000>;
         };
      };
   };
};

compiled it with: dtc -@ -I dts -O dtb -o mmc_spi.dtbo mmc_spi.dts
and loaded all with sudo dtoverlay -d . mmc_spi

output from dmesg is:

[ 2546.892076] mmc_spi spi0.0: SD/MMC host mmc2, no WP, no poweroff, cd polling
[ 2547.005168] mmc2: host does not support reading read-only switch, assuming write-enable
[ 2547.005215] mmc2: new SDXC card on SPI
[ 2547.005898] mmcblk2: mmc2:0000 SD 116 GiB (ro)
[ 2547.020020]  mmcblk2: p1 p2
[ 2547.020717] mmcblk2: mmc2:0000 SD 116 GiB (ro)
[ 2554.122622] EXT4-fs (mmcblk2p2): INFO: recovery required on readonly filesystem

using this basic sd-card-reader:

[6by9]

The module is called mmc_spi. The compatible string required in an overlay is "mmc-spi-slot", exactly as stated in the binding.

I don't see an overlay being shipped as part of this kernel tree using mmc_spi / mmc-spi-slot, so I don't believe there is an issue outstanding.
The OP's post appears to have been down to changes in dma ranges which are presumably solved in the 8 years since they opened the issue.

[TheCrazyT]

@6by9 thx for clarification, will try to test the version with the "mmc-spi-slot" in the overlay instead. Guess I got confused by some examples(like here and here ) on the internet that used "mmc_spi" instead.