The mmc part in exynos supports SDIO interrupts and they work fine, so
turn the capability on. With this I see download speeds increase
about 10x. This is a port of a change present in the Chrome OS tree
that can be found at <https://gerrit.chromium.org/gerrit/#/c/26729/>.
Signed-off-by: Doug Anderson <[email protected]>
---
drivers/mmc/host/dw_mmc-exynos.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index c7f0976..3a227be 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -192,10 +192,10 @@ static int dw_mci_exynos_setup_bus(struct dw_mci *host,
/* Common capabilities of Exynos4/Exynos5 SoC */
static unsigned long exynos_dwmmc_caps[4] = {
MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
- MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23,
- MMC_CAP_CMD23,
- MMC_CAP_CMD23,
- MMC_CAP_CMD23,
+ MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
+ MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
+ MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
+ MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
};
static const struct dw_mci_drv_data exynos_drv_data = {
--
1.8.1.3
Friday, April 12, 2013, Doug Anderson wrote:
> The mmc part in exynos supports SDIO interrupts and they work fine, so
> turn the capability on. With this I see download speeds increase
> about 10x. This is a port of a change present in the Chrome OS tree
> that can be found at <https://gerrit.chromium.org/gerrit/#/c/26729/>.
>
> Signed-off-by: Doug Anderson <[email protected]>
> ---
> drivers/mmc/host/dw_mmc-exynos.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
> index c7f0976..3a227be 100644
> --- a/drivers/mmc/host/dw_mmc-exynos.c
> +++ b/drivers/mmc/host/dw_mmc-exynos.c
> @@ -192,10 +192,10 @@ static int dw_mci_exynos_setup_bus(struct dw_mci *host,
> /* Common capabilities of Exynos4/Exynos5 SoC */
> static unsigned long exynos_dwmmc_caps[4] = {
> MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
> - MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23,
> - MMC_CAP_CMD23,
> - MMC_CAP_CMD23,
> - MMC_CAP_CMD23,
> + MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
> + MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
This line for [1]
> + MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
> + MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
[1] is for mshc1. mshc1 is only used for SDIO.
As I know, The others are improper for SDIO.
Thanks,
Seungwon Jeon
> };
>
> static const struct dw_mci_drv_data exynos_drv_data = {
> --
> 1.8.1.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Seungwon,
On Mon, Apr 15, 2013 at 5:14 AM, Seungwon Jeon <[email protected]> wrote:
>> + MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
>> + MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
> This line for [1]
>> + MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
>> + MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
> [1] is for mshc1. mshc1 is only used for SDIO.
> As I know, The others are improper for SDIO.
I'm nearly certain that all of the ports are OK for SDIO. Specifically:
* On the ARM Chromebook (exynos5250) we are using mmc3 (12230000) for
the SDIO connection to WiFi.
* I have plugged in an external WiFi module to the SD card slot on the
ARM Chromebook and seen it work (including interrupts). This is mmc2
(12220000).
* I have seen a board where mmc1 was wired up to WiFi and seen it work.
It is possible that mmc0 wouldn't work for SDIO. I've never tested it
since mmc0 is intended for eMMC and every system I've worked with has
eMMC on that port. There is some evidence that mmc0 would work for
SDIO, though: there is a muxing slot on GPC0[2] for SD_0_CARD_INT_n.
That implies that mmc0 ought to also work for SDIO (and even could be
configured for an external eSDIO interrupt, I guess).
Thanks!
-Doug
On Tuesday, April 16, 2013, Doug Anderson
> Seungwon,
>
> On Mon, Apr 15, 2013 at 5:14 AM, Seungwon Jeon <[email protected]> wrote:
> >> + MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
> >> + MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
> > This line for [1]
> >> + MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
> >> + MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
> > [1] is for mshc1. mshc1 is only used for SDIO.
> > As I know, The others are improper for SDIO.
>
> I'm nearly certain that all of the ports are OK for SDIO. Specifically:
>
> * On the ARM Chromebook (exynos5250) we are using mmc3 (12230000) for
> the SDIO connection to WiFi.
>
> * I have plugged in an external WiFi module to the SD card slot on the
> ARM Chromebook and seen it work (including interrupts). This is mmc2
> (12220000).
Yes, we also have tested WiFi module type of sd slot with ch#2.
>
> * I have seen a board where mmc1 was wired up to WiFi and seen it work.
Yes, mmc2, mmc3 can
>
>
> It is possible that mmc0 wouldn't work for SDIO. I've never tested it
> since mmc0 is intended for eMMC and every system I've worked with has
> eMMC on that port. There is some evidence that mmc0 would work for
> SDIO, though: there is a muxing slot on GPC0[2] for SD_0_CARD_INT_n.
> That implies that mmc0 ought to also work for SDIO (and even could be
> configured for an external eSDIO interrupt, I guess).
I don't mean that SDIO is impossible except in ch#1.
Basically, SDIO device can be attached on all host's channel and may works.
In case of ch#0, it's almost dedicated for eMMC and is actually arranged for eMMC.
And ch#1 is recommended for SDIO and can support UHS-I speed.
So, I don't think MMC_CAP_SDIO_IRQ is needed to ch#0.
Similarly, MMC_CAP_SDIO_IRQ is not a good choice for ch#2, ch#3 by default.
If needed for specific channel, it can be got from dts as property.
if (of_find_property(np, "cap-sdio-irq", NULL))
pdata->caps |= MMC_CAP_SDIO_IRQ;
Thanks,
Seungwon Jeon
>
>
> Thanks!
>
> -Doug
Seungwon,
On Tue, Apr 16, 2013 at 2:30 AM, Seungwon Jeon <[email protected]> wrote:
> If needed for specific channel, it can be got from dts as property.
> if (of_find_property(np, "cap-sdio-irq", NULL))
> pdata->caps |= MMC_CAP_SDIO_IRQ;
Oh! I missed that these new properties had gone in. That is a much
better way to do it. Let's abandon this patch and I'll post up a
device tree change that turns interrupts for the right ports on the
exynos5250-snow and we can call it done.
Thanks for the review and for pointing me to the new properties!
-Doug