| Message ID | 1423578559-27947-1-git-send-email-a.hajda@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Andrzej, On Tue, Feb 10, 2015 at 7:59 PM, Andrzej Hajda <a.hajda@samsung.com> wrote: > According to specs for version 250A, status register should be > tested before clock update. Otherwise in case MMC card is missing > mci_send_cmd timeouts and subsequent CTYPE registry write causes system hang. > This behavior has been observed on Exynos5422/Odroid-XU3. > A similar patch was posted recently[1], did you check that? [1] http://www.spinics.net/lists/linux-doc/msg28092.html > Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> > --- > Hi, > > This version corrects usleep to usleep_range function call. > > Regards > Andrzej > --- > drivers/mmc/host/dw_mmc.c | 26 ++++++++++++++++++++++++-- > drivers/mmc/host/dw_mmc.h | 1 + > 2 files changed, 25 insertions(+), 2 deletions(-) > > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c > index 67c0451..6619c8a 100644 > --- a/drivers/mmc/host/dw_mmc.c > +++ b/drivers/mmc/host/dw_mmc.c > @@ -878,6 +878,25 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg) > cmd, arg, cmd_status); > } > > +static bool dw_mci_wait_busy(struct dw_mci *host) > +{ > + unsigned long timeout; > + > + if (host->verid < DW_MMC_250A) > + return true; > + I wonder this might be true for 240A as well. > + timeout = jiffies + msecs_to_jiffies(500); > + while (time_before(jiffies, timeout)) { > + if (!(mci_readl(host, STATUS) & SDMMC_STATUS_BUSY)) > + return true; > + > + usleep_range(1000, 2000); > + } > + dev_err(host->dev, "Busy timeout\n"); Probably you need a controller reset here to bring back controller is original state. > + > + return false; > +} > + > static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit) > { > struct dw_mci *host = slot->host; > @@ -891,8 +910,11 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit) > sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH; > > if (!clock) { > - mci_writel(host, CLKENA, 0); > - mci_send_cmd(slot, sdmmc_cmd_bits, 0); > + if (dw_mci_wait_busy(host)) { > + mci_writel(host, CLKENA, 0); > + mci_send_cmd(slot, sdmmc_cmd_bits, 0); > + } else > + return; > } else if (clock != host->current_speed || force_clkinit) { > div = host->bus_hz / clock; > if (host->bus_hz % clock && host->bus_hz > clock) > diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h > index 0d0f7a27..ea6d4d1 100644 > --- a/drivers/mmc/host/dw_mmc.h > +++ b/drivers/mmc/host/dw_mmc.h > @@ -15,6 +15,7 @@ > #define _DW_MMC_H_ > > #define DW_MMC_240A 0x240a > +#define DW_MMC_250A 0x250a > > #define SDMMC_CTRL 0x000 > #define SDMMC_PWREN 0x004 > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Thanks for comments. On 02/10/2015 03:54 PM, Alim Akhtar wrote: > Hi Andrzej, > > On Tue, Feb 10, 2015 at 7:59 PM, Andrzej Hajda <a.hajda@samsung.com> wrote: >> According to specs for version 250A, status register should be >> tested before clock update. Otherwise in case MMC card is missing >> mci_send_cmd timeouts and subsequent CTYPE registry write causes system hang. >> This behavior has been observed on Exynos5422/Odroid-XU3. >> > A similar patch was posted recently[1], did you check that? > [1] http://www.spinics.net/lists/linux-doc/msg28092.html No, thanks for pointing it. I will look at it closer. > >> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> >> --- >> Hi, >> >> This version corrects usleep to usleep_range function call. >> >> Regards >> Andrzej >> --- >> drivers/mmc/host/dw_mmc.c | 26 ++++++++++++++++++++++++-- >> drivers/mmc/host/dw_mmc.h | 1 + >> 2 files changed, 25 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c >> index 67c0451..6619c8a 100644 >> --- a/drivers/mmc/host/dw_mmc.c >> +++ b/drivers/mmc/host/dw_mmc.c >> @@ -878,6 +878,25 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg) >> cmd, arg, cmd_status); >> } >> >> +static bool dw_mci_wait_busy(struct dw_mci *host) >> +{ >> + unsigned long timeout; >> + >> + if (host->verid < DW_MMC_250A) >> + return true; >> + > I wonder this might be true for 240A as well. Odroid-U3 board with Exynos4412 and MMC 240A does not have this problem. On the other side busy check does not hurt it anyway. Relevant part of dmesg for Exynos4412/mmc_240a: ... [ 2.193967] mmc1: req done (CMD55): -110: 00000000 00000000 00000000 00000000 [ 2.194000] mmc1: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 7 width 0 timing 0 [ 2.194010] mmc1: starting CMD1 arg 00000000 flags 000000e1 [ 2.194821] mmc1: req done (CMD1): -110: 00000000 00000000 00000000 00000000 [ 2.194854] mmc1: clock 0Hz busmode 2 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 3.195404] mmc1: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 7 width 0 timing 0 ... and for Exynos5422/mmc_250a: [ 3.530672] mmc0: req done (CMD55): -5: 00000000 00000000 00000000 00000000 [ 3.530707] mmc0: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 21 width 0 timing 0 [ 3.530716] mmc0: starting CMD1 arg 00000000 flags 000000e1 [ 3.531004] mmc0: req done (CMD1): -5: 00000000 00000000 00000000 00000000 [ 3.531039] mmc0: clock 0Hz busmode 2 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 4.031304] mmc_host mmc0: Busy timeout (cmd 0x202000 arg 0x0) [ 5.031323] mmc0: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 21 width 0 timing 0 [ 5.536385] mmc_host mmc0: Busy timeout (cmd 0x202000 arg 0x0) > >> + timeout = jiffies + msecs_to_jiffies(500); >> + while (time_before(jiffies, timeout)) { >> + if (!(mci_readl(host, STATUS) & SDMMC_STATUS_BUSY)) >> + return true; >> + >> + usleep_range(1000, 2000); >> + } >> + dev_err(host->dev, "Busy timeout\n"); > Probably you need a controller reset here to bring back controller is > original state. OK. Regards Andrzej >> + >> + return false; >> +} >> + >> static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit) >> { >> struct dw_mci *host = slot->host; >> @@ -891,8 +910,11 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit) >> sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH; >> >> if (!clock) { >> - mci_writel(host, CLKENA, 0); >> - mci_send_cmd(slot, sdmmc_cmd_bits, 0); >> + if (dw_mci_wait_busy(host)) { >> + mci_writel(host, CLKENA, 0); >> + mci_send_cmd(slot, sdmmc_cmd_bits, 0); >> + } else >> + return; >> } else if (clock != host->current_speed || force_clkinit) { >> div = host->bus_hz / clock; >> if (host->bus_hz % clock && host->bus_hz > clock) >> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h >> index 0d0f7a27..ea6d4d1 100644 >> --- a/drivers/mmc/host/dw_mmc.h >> +++ b/drivers/mmc/host/dw_mmc.h >> @@ -15,6 +15,7 @@ >> #define _DW_MMC_H_ >> >> #define DW_MMC_240A 0x240a >> +#define DW_MMC_250A 0x250a >> >> #define SDMMC_CTRL 0x000 >> #define SDMMC_PWREN 0x004 >> -- >> 1.9.1 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/11/2015 04:51 PM, Andrzej Hajda wrote: > Hi, > > Thanks for comments. > > On 02/10/2015 03:54 PM, Alim Akhtar wrote: >> Hi Andrzej, >> >> On Tue, Feb 10, 2015 at 7:59 PM, Andrzej Hajda <a.hajda@samsung.com> wrote: >>> According to specs for version 250A, status register should be >>> tested before clock update. Otherwise in case MMC card is missing >>> mci_send_cmd timeouts and subsequent CTYPE registry write causes system hang. >>> This behavior has been observed on Exynos5422/Odroid-XU3. >>> >> A similar patch was posted recently[1], did you check that? >> [1] http://www.spinics.net/lists/linux-doc/msg28092.html > > No, thanks for pointing it. I will look at it closer. > >> >>> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> >>> --- >>> Hi, >>> >>> This version corrects usleep to usleep_range function call. >>> >>> Regards >>> Andrzej >>> --- >>> drivers/mmc/host/dw_mmc.c | 26 ++++++++++++++++++++++++-- >>> drivers/mmc/host/dw_mmc.h | 1 + >>> 2 files changed, 25 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c >>> index 67c0451..6619c8a 100644 >>> --- a/drivers/mmc/host/dw_mmc.c >>> +++ b/drivers/mmc/host/dw_mmc.c >>> @@ -878,6 +878,25 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg) >>> cmd, arg, cmd_status); >>> } >>> >>> +static bool dw_mci_wait_busy(struct dw_mci *host) >>> +{ >>> + unsigned long timeout; >>> + >>> + if (host->verid < DW_MMC_250A) >>> + return true; >>> + >> I wonder this might be true for 240A as well. > > Odroid-U3 board with Exynos4412 and MMC 240A does not have this problem. > On the other side busy check does not hurt it anyway. Which kernel version do you use? I also have the exynos5422 board, but i didn't find the below error yet. It doesn't relate with IP version. If you share your environment, i can check with exynos5422 board. I'm not sure but this patch could be dropped. Because this patch is just only checking whether card is busy or not. this patch(mmc:dw_mmc: fix bug that case 'timeout sending command') can cover your patch. Best Regards, Jaehoon Chung > > Relevant part of dmesg for Exynos4412/mmc_240a: > ... > [ 2.193967] mmc1: req done (CMD55): -110: 00000000 00000000 00000000 > 00000000 > [ 2.194000] mmc1: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 7 > width 0 timing 0 > [ 2.194010] mmc1: starting CMD1 arg 00000000 flags 000000e1 > [ 2.194821] mmc1: req done (CMD1): -110: 00000000 00000000 00000000 > 00000000 > [ 2.194854] mmc1: clock 0Hz busmode 2 powermode 0 cs 0 Vdd 0 width 0 > timing 0 > [ 3.195404] mmc1: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 7 width 0 > timing 0 > ... > and for Exynos5422/mmc_250a: > [ 3.530672] mmc0: req done (CMD55): -5: 00000000 00000000 00000000 > 00000000 > [ 3.530707] mmc0: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 21 > width 0 timing 0 > [ 3.530716] mmc0: starting CMD1 arg 00000000 flags 000000e1 > [ 3.531004] mmc0: req done (CMD1): -5: 00000000 00000000 00000000 > 00000000 > [ 3.531039] mmc0: clock 0Hz busmode 2 powermode 0 cs 0 Vdd 0 width 0 > timing 0 > [ 4.031304] mmc_host mmc0: Busy timeout (cmd 0x202000 arg 0x0) > [ 5.031323] mmc0: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 21 width 0 > timing 0 > [ 5.536385] mmc_host mmc0: Busy timeout (cmd 0x202000 arg 0x0) > >> >>> + timeout = jiffies + msecs_to_jiffies(500); >>> + while (time_before(jiffies, timeout)) { >>> + if (!(mci_readl(host, STATUS) & SDMMC_STATUS_BUSY)) >>> + return true; >>> + >>> + usleep_range(1000, 2000); >>> + } >>> + dev_err(host->dev, "Busy timeout\n"); >> Probably you need a controller reset here to bring back controller is >> original state. > > OK. > > Regards > Andrzej > > >>> + >>> + return false; >>> +} >>> + >>> static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit) >>> { >>> struct dw_mci *host = slot->host; >>> @@ -891,8 +910,11 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit) >>> sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH; >>> >>> if (!clock) { >>> - mci_writel(host, CLKENA, 0); >>> - mci_send_cmd(slot, sdmmc_cmd_bits, 0); >>> + if (dw_mci_wait_busy(host)) { >>> + mci_writel(host, CLKENA, 0); >>> + mci_send_cmd(slot, sdmmc_cmd_bits, 0); >>> + } else >>> + return; >>> } else if (clock != host->current_speed || force_clkinit) { >>> div = host->bus_hz / clock; >>> if (host->bus_hz % clock && host->bus_hz > clock) >>> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h >>> index 0d0f7a27..ea6d4d1 100644 >>> --- a/drivers/mmc/host/dw_mmc.h >>> +++ b/drivers/mmc/host/dw_mmc.h >>> @@ -15,6 +15,7 @@ >>> #define _DW_MMC_H_ >>> >>> #define DW_MMC_240A 0x240a >>> +#define DW_MMC_250A 0x250a >>> >>> #define SDMMC_CTRL 0x000 >>> #define SDMMC_PWREN 0x004 >>> -- >>> 1.9.1 >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/11/2015 09:32 AM, Jaehoon Chung wrote: > On 02/11/2015 04:51 PM, Andrzej Hajda wrote: >> Hi, >> >> Thanks for comments. >> >> On 02/10/2015 03:54 PM, Alim Akhtar wrote: >>> Hi Andrzej, >>> >>> On Tue, Feb 10, 2015 at 7:59 PM, Andrzej Hajda <a.hajda@samsung.com> wrote: >>>> According to specs for version 250A, status register should be >>>> tested before clock update. Otherwise in case MMC card is missing >>>> mci_send_cmd timeouts and subsequent CTYPE registry write causes system hang. >>>> This behavior has been observed on Exynos5422/Odroid-XU3. >>>> >>> A similar patch was posted recently[1], did you check that? >>> [1] http://www.spinics.net/lists/linux-doc/msg28092.html >> No, thanks for pointing it. I will look at it closer. >> >>>> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> >>>> --- >>>> Hi, >>>> >>>> This version corrects usleep to usleep_range function call. >>>> >>>> Regards >>>> Andrzej >>>> --- >>>> drivers/mmc/host/dw_mmc.c | 26 ++++++++++++++++++++++++-- >>>> drivers/mmc/host/dw_mmc.h | 1 + >>>> 2 files changed, 25 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c >>>> index 67c0451..6619c8a 100644 >>>> --- a/drivers/mmc/host/dw_mmc.c >>>> +++ b/drivers/mmc/host/dw_mmc.c >>>> @@ -878,6 +878,25 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg) >>>> cmd, arg, cmd_status); >>>> } >>>> >>>> +static bool dw_mci_wait_busy(struct dw_mci *host) >>>> +{ >>>> + unsigned long timeout; >>>> + >>>> + if (host->verid < DW_MMC_250A) >>>> + return true; >>>> + >>> I wonder this might be true for 240A as well. >> Odroid-U3 board with Exynos4412 and MMC 240A does not have this problem. >> On the other side busy check does not hurt it anyway. > Which kernel version do you use? > I also have the exynos5422 board, but i didn't find the below error yet. > It doesn't relate with IP version. > If you share your environment, i can check with exynos5422 board. linux-next on odroid-xu3. With MMC card removed, booting from sdcard. Please also note that broken-cd quirk is on in dts. > > I'm not sure but this patch could be dropped. > Because this patch is just only checking whether card is busy or not. > > this patch(mmc:dw_mmc: fix bug that case 'timeout sending command') can cover your patch. I will test it. Regards Andrzej > > Best Regards, > Jaehoon Chung > >> Relevant part of dmesg for Exynos4412/mmc_240a: >> ... >> [ 2.193967] mmc1: req done (CMD55): -110: 00000000 00000000 00000000 >> 00000000 >> [ 2.194000] mmc1: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 7 >> width 0 timing 0 >> [ 2.194010] mmc1: starting CMD1 arg 00000000 flags 000000e1 >> [ 2.194821] mmc1: req done (CMD1): -110: 00000000 00000000 00000000 >> 00000000 >> [ 2.194854] mmc1: clock 0Hz busmode 2 powermode 0 cs 0 Vdd 0 width 0 >> timing 0 >> [ 3.195404] mmc1: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 7 width 0 >> timing 0 >> ... >> and for Exynos5422/mmc_250a: >> [ 3.530672] mmc0: req done (CMD55): -5: 00000000 00000000 00000000 >> 00000000 >> [ 3.530707] mmc0: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 21 >> width 0 timing 0 >> [ 3.530716] mmc0: starting CMD1 arg 00000000 flags 000000e1 >> [ 3.531004] mmc0: req done (CMD1): -5: 00000000 00000000 00000000 >> 00000000 >> [ 3.531039] mmc0: clock 0Hz busmode 2 powermode 0 cs 0 Vdd 0 width 0 >> timing 0 >> [ 4.031304] mmc_host mmc0: Busy timeout (cmd 0x202000 arg 0x0) >> [ 5.031323] mmc0: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 21 width 0 >> timing 0 >> [ 5.536385] mmc_host mmc0: Busy timeout (cmd 0x202000 arg 0x0) >> >>>> + timeout = jiffies + msecs_to_jiffies(500); >>>> + while (time_before(jiffies, timeout)) { >>>> + if (!(mci_readl(host, STATUS) & SDMMC_STATUS_BUSY)) >>>> + return true; >>>> + >>>> + usleep_range(1000, 2000); >>>> + } >>>> + dev_err(host->dev, "Busy timeout\n"); >>> Probably you need a controller reset here to bring back controller is >>> original state. >> OK. >> >> Regards >> Andrzej >> >> >>>> + >>>> + return false; >>>> +} >>>> + >>>> static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit) >>>> { >>>> struct dw_mci *host = slot->host; >>>> @@ -891,8 +910,11 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit) >>>> sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH; >>>> >>>> if (!clock) { >>>> - mci_writel(host, CLKENA, 0); >>>> - mci_send_cmd(slot, sdmmc_cmd_bits, 0); >>>> + if (dw_mci_wait_busy(host)) { >>>> + mci_writel(host, CLKENA, 0); >>>> + mci_send_cmd(slot, sdmmc_cmd_bits, 0); >>>> + } else >>>> + return; >>>> } else if (clock != host->current_speed || force_clkinit) { >>>> div = host->bus_hz / clock; >>>> if (host->bus_hz % clock && host->bus_hz > clock) >>>> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h >>>> index 0d0f7a27..ea6d4d1 100644 >>>> --- a/drivers/mmc/host/dw_mmc.h >>>> +++ b/drivers/mmc/host/dw_mmc.h >>>> @@ -15,6 +15,7 @@ >>>> #define _DW_MMC_H_ >>>> >>>> #define DW_MMC_240A 0x240a >>>> +#define DW_MMC_250A 0x250a >>>> >>>> #define SDMMC_CTRL 0x000 >>>> #define SDMMC_PWREN 0x004 >>>> -- >>>> 1.9.1 >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in >>>> the body of a message to majordomo@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Andrzej, On Wed, Feb 11, 2015 at 10:06 AM, Andrzej Hajda <a.hajda@samsung.com> wrote: > On 02/11/2015 09:32 AM, Jaehoon Chung wrote: >> On 02/11/2015 04:51 PM, Andrzej Hajda wrote: >>> Hi, >>> >>> Thanks for comments. >>> >>> On 02/10/2015 03:54 PM, Alim Akhtar wrote: >>>> Hi Andrzej, >>>> >>>> On Tue, Feb 10, 2015 at 7:59 PM, Andrzej Hajda <a.hajda@samsung.com> wrote: >>>>> According to specs for version 250A, status register should be >>>>> tested before clock update. Otherwise in case MMC card is missing >>>>> mci_send_cmd timeouts and subsequent CTYPE registry write causes system hang. >>>>> This behavior has been observed on Exynos5422/Odroid-XU3. I've also observed the same behavior (mmc command send timing out and system hang) on an Exynos5420 Peach Pit Chromebook and an Exynos5800 Peach Pi Chromebok which both have the same dw_mmc 250A IP version. Unfortunately $subject doesn't seem to be enough since even with that applied I got: [ 4.264418] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000) [ 4.283988] random: nonblocking pool is initialized [ 28.054406] INFO: rcu_sched detected stalls on CPUs/tasks: [ 28.058412] 0: (5 ticks this GP) idle=65f/140000000000001/0 softirq=215/216 fqs=39 [ 28.066129] (detected by 1, t=4765 jiffies, g=-294, c=-295, q=2) [ 28.072202] Task dump for CPU 0: [ 28.075412] kworker/u16:0 R running 0 6 2 0x00000002 [ 28.081749] Workqueue: kmmcd mmc_rescan [ 28.085570] [<c04c2698>] (__schedule) from [<00000000>] ( (null)) [ 28.091724] rcu_sched kthread starved for 796 jiffies! >>>>> >>>>> +static bool dw_mci_wait_busy(struct dw_mci *host) >>>>> +{ >>>>> + unsigned long timeout; >>>>> + >>>>> + if (host->verid < DW_MMC_250A) >>>>> + return true; >>>>> + >>>> I wonder this might be true for 240A as well. >>> Odroid-U3 board with Exynos4412 and MMC 240A does not have this problem. >>> On the other side busy check does not hurt it anyway. This problem also does not happen on an Exynos5250 Snow Chromebook which has a dw_mmc IP version 241A. >> Which kernel version do you use? >> I also have the exynos5422 board, but i didn't find the below error yet. >> It doesn't relate with IP version. >> If you share your environment, i can check with exynos5422 board. > > linux-next on odroid-xu3. With MMC card removed, booting from sdcard. > Please also note that broken-cd quirk is on in dts. > I tested by trying to add wifi support to the Peach Pit/Pi Chromebooks which have an SDIO wifi chip attached to mmc@12210000. This [0] is the patch I've on top of linux-next fwiw. >> >> I'm not sure but this patch could be dropped. >> Because this patch is just only checking whether card is busy or not. >> >> this patch(mmc:dw_mmc: fix bug that case 'timeout sending command') can cover your patch. > > I will test it. > I tested it and although the mentioned patch does fix the mmc commands send timing out, now card detection seems to not be working since the kernel keeps waiting for aiting for root device /dev/mmcblk1p4... and the this error is shown: [ 4.249434] dwmmc_exynos 12210000.mmc: Data busy (status 0x306) So I tried the other patch from Addy's series "mmc: dw_mmc: Don't start command while data busy" but it did not have an effect. I still see the data busy error and the uSD card is not detected. Best regards, Javier [0]: http://paste.debian.net/plain/145877 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Andrzej. On 02/13/2015 01:53 AM, Javier Martinez Canillas wrote: > Hello Andrzej, > > On Wed, Feb 11, 2015 at 10:06 AM, Andrzej Hajda <a.hajda@samsung.com> wrote: >> On 02/11/2015 09:32 AM, Jaehoon Chung wrote: >>> On 02/11/2015 04:51 PM, Andrzej Hajda wrote: >>>> Hi, >>>> >>>> Thanks for comments. >>>> >>>> On 02/10/2015 03:54 PM, Alim Akhtar wrote: >>>>> Hi Andrzej, >>>>> >>>>> On Tue, Feb 10, 2015 at 7:59 PM, Andrzej Hajda <a.hajda@samsung.com> wrote: >>>>>> According to specs for version 250A, status register should be >>>>>> tested before clock update. Otherwise in case MMC card is missing >>>>>> mci_send_cmd timeouts and subsequent CTYPE registry write causes system hang. >>>>>> This behavior has been observed on Exynos5422/Odroid-XU3. > > I've also observed the same behavior (mmc command send timing out and > system hang) on an Exynos5420 Peach Pit Chromebook and an Exynos5800 > Peach Pi Chromebok which both have the same dw_mmc 250A IP version. > > Unfortunately $subject doesn't seem to be enough since even with that > applied I got: > > [ 4.264418] mmc_host mmc1: Timeout sending command (cmd 0x202000 > arg 0x0 status 0x80202000) > [ 4.283988] random: nonblocking pool is initialized > [ 28.054406] INFO: rcu_sched detected stalls on CPUs/tasks: > [ 28.058412] 0: (5 ticks this GP) idle=65f/140000000000001/0 > softirq=215/216 fqs=39 > [ 28.066129] (detected by 1, t=4765 jiffies, g=-294, c=-295, q=2) > [ 28.072202] Task dump for CPU 0: > [ 28.075412] kworker/u16:0 R running 0 6 2 0x00000002 > [ 28.081749] Workqueue: kmmcd mmc_rescan > [ 28.085570] [<c04c2698>] (__schedule) from [<00000000>] ( (null)) > [ 28.091724] rcu_sched kthread starved for 796 jiffies! > >>>>>> >>>>>> +static bool dw_mci_wait_busy(struct dw_mci *host) >>>>>> +{ >>>>>> + unsigned long timeout; >>>>>> + >>>>>> + if (host->verid < DW_MMC_250A) >>>>>> + return true; >>>>>> + >>>>> I wonder this might be true for 240A as well. >>>> Odroid-U3 board with Exynos4412 and MMC 240A does not have this problem. >>>> On the other side busy check does not hurt it anyway. > > This problem also does not happen on an Exynos5250 Snow Chromebook > which has a dw_mmc IP version 241A. > >>> Which kernel version do you use? >>> I also have the exynos5422 board, but i didn't find the below error yet. >>> It doesn't relate with IP version. >>> If you share your environment, i can check with exynos5422 board. >> >> linux-next on odroid-xu3. With MMC card removed, booting from sdcard. >> Please also note that broken-cd quirk is on in dts. I can't find this problem on exynos5422 board.(Odroix-xu3) Could you share the properties into dts file? Best Regards, Jaehoon Chung >> > > I tested by trying to add wifi support to the Peach Pit/Pi Chromebooks > which have an SDIO wifi chip attached to mmc@12210000. This [0] is the > patch I've on top of linux-next fwiw. > >>> >>> I'm not sure but this patch could be dropped. >>> Because this patch is just only checking whether card is busy or not. >>> >>> this patch(mmc:dw_mmc: fix bug that case 'timeout sending command') can cover your patch. >> >> I will test it. >> > > I tested it and although the mentioned patch does fix the mmc commands > send timing out, now card detection seems to not be working since the > kernel keeps waiting for aiting for root device /dev/mmcblk1p4... > > and the this error is shown: > > [ 4.249434] dwmmc_exynos 12210000.mmc: Data busy (status 0x306) > > So I tried the other patch from Addy's series "mmc: dw_mmc: Don't > start command while data busy" but it did not have an effect. I still > see the data busy error and the uSD card is not detected. > > Best regards, > Javier > > [0]: http://paste.debian.net/plain/145877 > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/13/2015 08:30 AM, Jaehoon Chung wrote: > Hi, Andrzej. > > On 02/13/2015 01:53 AM, Javier Martinez Canillas wrote: >> Hello Andrzej, >> >> On Wed, Feb 11, 2015 at 10:06 AM, Andrzej Hajda <a.hajda@samsung.com> wrote: >>> On 02/11/2015 09:32 AM, Jaehoon Chung wrote: >>>> On 02/11/2015 04:51 PM, Andrzej Hajda wrote: >>>>> Hi, >>>>> >>>>> Thanks for comments. >>>>> >>>>> On 02/10/2015 03:54 PM, Alim Akhtar wrote: >>>>>> Hi Andrzej, >>>>>> >>>>>> On Tue, Feb 10, 2015 at 7:59 PM, Andrzej Hajda <a.hajda@samsung.com> wrote: >>>>>>> According to specs for version 250A, status register should be >>>>>>> tested before clock update. Otherwise in case MMC card is missing >>>>>>> mci_send_cmd timeouts and subsequent CTYPE registry write causes system hang. >>>>>>> This behavior has been observed on Exynos5422/Odroid-XU3. >> I've also observed the same behavior (mmc command send timing out and >> system hang) on an Exynos5420 Peach Pit Chromebook and an Exynos5800 >> Peach Pi Chromebok which both have the same dw_mmc 250A IP version. >> >> Unfortunately $subject doesn't seem to be enough since even with that >> applied I got: >> >> [ 4.264418] mmc_host mmc1: Timeout sending command (cmd 0x202000 >> arg 0x0 status 0x80202000) >> [ 4.283988] random: nonblocking pool is initialized >> [ 28.054406] INFO: rcu_sched detected stalls on CPUs/tasks: >> [ 28.058412] 0: (5 ticks this GP) idle=65f/140000000000001/0 >> softirq=215/216 fqs=39 >> [ 28.066129] (detected by 1, t=4765 jiffies, g=-294, c=-295, q=2) >> [ 28.072202] Task dump for CPU 0: >> [ 28.075412] kworker/u16:0 R running 0 6 2 0x00000002 >> [ 28.081749] Workqueue: kmmcd mmc_rescan >> [ 28.085570] [<c04c2698>] (__schedule) from [<00000000>] ( (null)) >> [ 28.091724] rcu_sched kthread starved for 796 jiffies! >> >>>>>>> +static bool dw_mci_wait_busy(struct dw_mci *host) >>>>>>> +{ >>>>>>> + unsigned long timeout; >>>>>>> + >>>>>>> + if (host->verid < DW_MMC_250A) >>>>>>> + return true; >>>>>>> + >>>>>> I wonder this might be true for 240A as well. >>>>> Odroid-U3 board with Exynos4412 and MMC 240A does not have this problem. >>>>> On the other side busy check does not hurt it anyway. >> This problem also does not happen on an Exynos5250 Snow Chromebook >> which has a dw_mmc IP version 241A. >> >>>> Which kernel version do you use? >>>> I also have the exynos5422 board, but i didn't find the below error yet. >>>> It doesn't relate with IP version. >>>> If you share your environment, i can check with exynos5422 board. >>> linux-next on odroid-xu3. With MMC card removed, booting from sdcard. >>> Please also note that broken-cd quirk is on in dts. > I can't find this problem on exynos5422 board.(Odroix-xu3) > Could you share the properties into dts file? It is just linux-next with exynos_defconfig and arch/arm/boot/dts/exynos5422-odroidxu3.dts, without changes: ... &mmc_0 { status = "okay"; mmc-pwrseq = <&emmc_pwrseq>; broken-cd; card-detect-delay = <200>; samsung,dw-mshc-ciu-div = <3>; samsung,dw-mshc-sdr-timing = <0 4>; samsung,dw-mshc-ddr-timing = <0 2>; pinctrl-names = "default"; pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>; bus-width = <8>; cap-mmc-highspeed; }; ... Regarding hardware: eMMC card removed, booting from sdcard. Regards Andrzej > > > Best Regards, > Jaehoon Chung > >> I tested by trying to add wifi support to the Peach Pit/Pi Chromebooks >> which have an SDIO wifi chip attached to mmc@12210000. This [0] is the >> patch I've on top of linux-next fwiw. >> >>>> I'm not sure but this patch could be dropped. >>>> Because this patch is just only checking whether card is busy or not. >>>> >>>> this patch(mmc:dw_mmc: fix bug that case 'timeout sending command') can cover your patch. >>> I will test it. >>> >> I tested it and although the mentioned patch does fix the mmc commands >> send timing out, now card detection seems to not be working since the >> kernel keeps waiting for aiting for root device /dev/mmcblk1p4... >> >> and the this error is shown: >> >> [ 4.249434] dwmmc_exynos 12210000.mmc: Data busy (status 0x306) >> >> So I tried the other patch from Addy's series "mmc: dw_mmc: Don't >> start command while data busy" but it did not have an effect. I still >> see the data busy error and the uSD card is not detected. >> >> Best regards, >> Javier >> >> [0]: http://paste.debian.net/plain/145877 >> > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/13/2015 05:13 PM, Andrzej Hajda wrote: > On 02/13/2015 08:30 AM, Jaehoon Chung wrote: >> Hi, Andrzej. >> >> On 02/13/2015 01:53 AM, Javier Martinez Canillas wrote: >>> Hello Andrzej, >>> >>> On Wed, Feb 11, 2015 at 10:06 AM, Andrzej Hajda <a.hajda@samsung.com> wrote: >>>> On 02/11/2015 09:32 AM, Jaehoon Chung wrote: >>>>> On 02/11/2015 04:51 PM, Andrzej Hajda wrote: >>>>>> Hi, >>>>>> >>>>>> Thanks for comments. >>>>>> >>>>>> On 02/10/2015 03:54 PM, Alim Akhtar wrote: >>>>>>> Hi Andrzej, >>>>>>> >>>>>>> On Tue, Feb 10, 2015 at 7:59 PM, Andrzej Hajda <a.hajda@samsung.com> wrote: >>>>>>>> According to specs for version 250A, status register should be >>>>>>>> tested before clock update. Otherwise in case MMC card is missing >>>>>>>> mci_send_cmd timeouts and subsequent CTYPE registry write causes system hang. >>>>>>>> This behavior has been observed on Exynos5422/Odroid-XU3. >>> I've also observed the same behavior (mmc command send timing out and >>> system hang) on an Exynos5420 Peach Pit Chromebook and an Exynos5800 >>> Peach Pi Chromebok which both have the same dw_mmc 250A IP version. >>> >>> Unfortunately $subject doesn't seem to be enough since even with that >>> applied I got: >>> >>> [ 4.264418] mmc_host mmc1: Timeout sending command (cmd 0x202000 >>> arg 0x0 status 0x80202000) >>> [ 4.283988] random: nonblocking pool is initialized >>> [ 28.054406] INFO: rcu_sched detected stalls on CPUs/tasks: >>> [ 28.058412] 0: (5 ticks this GP) idle=65f/140000000000001/0 >>> softirq=215/216 fqs=39 >>> [ 28.066129] (detected by 1, t=4765 jiffies, g=-294, c=-295, q=2) >>> [ 28.072202] Task dump for CPU 0: >>> [ 28.075412] kworker/u16:0 R running 0 6 2 0x00000002 >>> [ 28.081749] Workqueue: kmmcd mmc_rescan >>> [ 28.085570] [<c04c2698>] (__schedule) from [<00000000>] ( (null)) >>> [ 28.091724] rcu_sched kthread starved for 796 jiffies! >>> >>>>>>>> +static bool dw_mci_wait_busy(struct dw_mci *host) >>>>>>>> +{ >>>>>>>> + unsigned long timeout; >>>>>>>> + >>>>>>>> + if (host->verid < DW_MMC_250A) >>>>>>>> + return true; >>>>>>>> + >>>>>>> I wonder this might be true for 240A as well. >>>>>> Odroid-U3 board with Exynos4412 and MMC 240A does not have this problem. >>>>>> On the other side busy check does not hurt it anyway. >>> This problem also does not happen on an Exynos5250 Snow Chromebook >>> which has a dw_mmc IP version 241A. >>> >>>>> Which kernel version do you use? >>>>> I also have the exynos5422 board, but i didn't find the below error yet. >>>>> It doesn't relate with IP version. >>>>> If you share your environment, i can check with exynos5422 board. >>>> linux-next on odroid-xu3. With MMC card removed, booting from sdcard. >>>> Please also note that broken-cd quirk is on in dts. >> I can't find this problem on exynos5422 board.(Odroix-xu3) >> Could you share the properties into dts file? > > It is just linux-next with exynos_defconfig and > arch/arm/boot/dts/exynos5422-odroidxu3.dts, without changes: > ... > &mmc_0 { > status = "okay"; > mmc-pwrseq = <&emmc_pwrseq>; > broken-cd; > card-detect-delay = <200>; > samsung,dw-mshc-ciu-div = <3>; > samsung,dw-mshc-sdr-timing = <0 4>; > samsung,dw-mshc-ddr-timing = <0 2>; > pinctrl-names = "default"; > pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>; > bus-width = <8>; > cap-mmc-highspeed; > }; > ... This is node relevant to eMMC. I have tested with exynos5422 board(Odroid-xu3) and latest linux-next. (Without eMMC card, just booting from SD-card.) root-device is SD-card, right? When i try to boot with platform image, it's working fine from Sd-card. I can't find anything.. Best Regards, Jaehoon Chung > > Regarding hardware: > eMMC card removed, > booting from sdcard. > > Regards > Andrzej > >> >> >> Best Regards, >> Jaehoon Chung >> >>> I tested by trying to add wifi support to the Peach Pit/Pi Chromebooks >>> which have an SDIO wifi chip attached to mmc@12210000. This [0] is the >>> patch I've on top of linux-next fwiw. >>> >>>>> I'm not sure but this patch could be dropped. >>>>> Because this patch is just only checking whether card is busy or not. >>>>> >>>>> this patch(mmc:dw_mmc: fix bug that case 'timeout sending command') can cover your patch. >>>> I will test it. >>>> >>> I tested it and although the mentioned patch does fix the mmc commands >>> send timing out, now card detection seems to not be working since the >>> kernel keeps waiting for aiting for root device /dev/mmcblk1p4... >>> >>> and the this error is shown: >>> >>> [ 4.249434] dwmmc_exynos 12210000.mmc: Data busy (status 0x306) >>> >>> So I tried the other patch from Addy's series "mmc: dw_mmc: Don't >>> start command while data busy" but it did not have an effect. I still >>> see the data busy error and the uSD card is not detected. >>> >>> Best regards, >>> Javier >>> >>> [0]: http://paste.debian.net/plain/145877 >>> >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/13/2015 12:10 PM, Jaehoon Chung wrote: > On 02/13/2015 05:13 PM, Andrzej Hajda wrote: >> On 02/13/2015 08:30 AM, Jaehoon Chung wrote: >>> Hi, Andrzej. >>> >>> On 02/13/2015 01:53 AM, Javier Martinez Canillas wrote: >>>> Hello Andrzej, >>>> >>>> On Wed, Feb 11, 2015 at 10:06 AM, Andrzej Hajda <a.hajda@samsung.com> wrote: >>>>> On 02/11/2015 09:32 AM, Jaehoon Chung wrote: >>>>>> On 02/11/2015 04:51 PM, Andrzej Hajda wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Thanks for comments. >>>>>>> >>>>>>> On 02/10/2015 03:54 PM, Alim Akhtar wrote: >>>>>>>> Hi Andrzej, >>>>>>>> >>>>>>>> On Tue, Feb 10, 2015 at 7:59 PM, Andrzej Hajda <a.hajda@samsung.com> wrote: >>>>>>>>> According to specs for version 250A, status register should be >>>>>>>>> tested before clock update. Otherwise in case MMC card is missing >>>>>>>>> mci_send_cmd timeouts and subsequent CTYPE registry write causes system hang. >>>>>>>>> This behavior has been observed on Exynos5422/Odroid-XU3. >>>> I've also observed the same behavior (mmc command send timing out and >>>> system hang) on an Exynos5420 Peach Pit Chromebook and an Exynos5800 >>>> Peach Pi Chromebok which both have the same dw_mmc 250A IP version. >>>> >>>> Unfortunately $subject doesn't seem to be enough since even with that >>>> applied I got: >>>> >>>> [ 4.264418] mmc_host mmc1: Timeout sending command (cmd 0x202000 >>>> arg 0x0 status 0x80202000) >>>> [ 4.283988] random: nonblocking pool is initialized >>>> [ 28.054406] INFO: rcu_sched detected stalls on CPUs/tasks: >>>> [ 28.058412] 0: (5 ticks this GP) idle=65f/140000000000001/0 >>>> softirq=215/216 fqs=39 >>>> [ 28.066129] (detected by 1, t=4765 jiffies, g=-294, c=-295, q=2) >>>> [ 28.072202] Task dump for CPU 0: >>>> [ 28.075412] kworker/u16:0 R running 0 6 2 0x00000002 >>>> [ 28.081749] Workqueue: kmmcd mmc_rescan >>>> [ 28.085570] [<c04c2698>] (__schedule) from [<00000000>] ( (null)) >>>> [ 28.091724] rcu_sched kthread starved for 796 jiffies! >>>> >>>>>>>>> +static bool dw_mci_wait_busy(struct dw_mci *host) >>>>>>>>> +{ >>>>>>>>> + unsigned long timeout; >>>>>>>>> + >>>>>>>>> + if (host->verid < DW_MMC_250A) >>>>>>>>> + return true; >>>>>>>>> + >>>>>>>> I wonder this might be true for 240A as well. >>>>>>> Odroid-U3 board with Exynos4412 and MMC 240A does not have this problem. >>>>>>> On the other side busy check does not hurt it anyway. >>>> This problem also does not happen on an Exynos5250 Snow Chromebook >>>> which has a dw_mmc IP version 241A. >>>> >>>>>> Which kernel version do you use? >>>>>> I also have the exynos5422 board, but i didn't find the below error yet. >>>>>> It doesn't relate with IP version. >>>>>> If you share your environment, i can check with exynos5422 board. >>>>> linux-next on odroid-xu3. With MMC card removed, booting from sdcard. >>>>> Please also note that broken-cd quirk is on in dts. >>> I can't find this problem on exynos5422 board.(Odroix-xu3) >>> Could you share the properties into dts file? >> It is just linux-next with exynos_defconfig and >> arch/arm/boot/dts/exynos5422-odroidxu3.dts, without changes: >> ... >> &mmc_0 { >> status = "okay"; >> mmc-pwrseq = <&emmc_pwrseq>; >> broken-cd; >> card-detect-delay = <200>; >> samsung,dw-mshc-ciu-div = <3>; >> samsung,dw-mshc-sdr-timing = <0 4>; >> samsung,dw-mshc-ddr-timing = <0 2>; >> pinctrl-names = "default"; >> pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>; >> bus-width = <8>; >> cap-mmc-highspeed; >> }; >> ... > This is node relevant to eMMC. > I have tested with exynos5422 board(Odroid-xu3) and latest linux-next. > (Without eMMC card, just booting from SD-card.) > root-device is SD-card, right? When i try to boot with platform image, it's working fine from Sd-card. > I can't find anything.. Strange, I have tested it on two odroids-xu3, the same effects. Full configuration: Board: odroid-xu3, rev 0.2, 20140529 Configuration: eMMC slot empty, Kernel in MicroSD slot, SanDisk 4GB HCI, SW1 set to off (boot from uSD) Kernel: linux-next + Addy's patches '[PATCH v4 0/3] about data busy'[1], with exynos_defconfig. And below mmc logs (I have disabled &mmc_2 node, just to make logs cleaner). I have also used maxcpus=0 and loglevel=9. And every mci_write has been prepended by: pr_err("%s:%pS:%s:%d: status=%#x %s(%#x)=%s(%#x)\n", current->comm, __builtin_return_address(0), __func__, __LINE__, (u32)mci_readl(dev, STATUS), #reg, SDMMC_##reg, #value, (u32)(value)) Without eMMC card: http://paste.debian.net/149780/ With eMMC card: http://paste.debian.net/149786/ I have already sent dirty patch resolving the issue for my boards [1]. [1]: http://permalink.gmane.org/gmane.linux.kernel.mmc/31209 Regards Andrzej > > Best Regards, > Jaehoon Chung > >> Regarding hardware: >> eMMC card removed, >> booting from sdcard. >> >> Regards >> Andrzej >> >>> >>> Best Regards, >>> Jaehoon Chung >>> >>>> I tested by trying to add wifi support to the Peach Pit/Pi Chromebooks >>>> which have an SDIO wifi chip attached to mmc@12210000. This [0] is the >>>> patch I've on top of linux-next fwiw. >>>> >>>>>> I'm not sure but this patch could be dropped. >>>>>> Because this patch is just only checking whether card is busy or not. >>>>>> >>>>>> this patch(mmc:dw_mmc: fix bug that case 'timeout sending command') can cover your patch. >>>>> I will test it. >>>>> >>>> I tested it and although the mentioned patch does fix the mmc commands >>>> send timing out, now card detection seems to not be working since the >>>> kernel keeps waiting for aiting for root device /dev/mmcblk1p4... >>>> >>>> and the this error is shown: >>>> >>>> [ 4.249434] dwmmc_exynos 12210000.mmc: Data busy (status 0x306) >>>> >>>> So I tried the other patch from Addy's series "mmc: dw_mmc: Don't >>>> start command while data busy" but it did not have an effect. I still >>>> see the data busy error and the uSD card is not detected. >>>> >>>> Best regards, >>>> Javier >>>> >>>> [0]: http://paste.debian.net/plain/145877 >>>> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index 67c0451..6619c8a 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -878,6 +878,25 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg) cmd, arg, cmd_status); } +static bool dw_mci_wait_busy(struct dw_mci *host) +{ + unsigned long timeout; + + if (host->verid < DW_MMC_250A) + return true; + + timeout = jiffies + msecs_to_jiffies(500); + while (time_before(jiffies, timeout)) { + if (!(mci_readl(host, STATUS) & SDMMC_STATUS_BUSY)) + return true; + + usleep_range(1000, 2000); + } + dev_err(host->dev, "Busy timeout\n"); + + return false; +} + static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit) { struct dw_mci *host = slot->host; @@ -891,8 +910,11 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit) sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH; if (!clock) { - mci_writel(host, CLKENA, 0); - mci_send_cmd(slot, sdmmc_cmd_bits, 0); + if (dw_mci_wait_busy(host)) { + mci_writel(host, CLKENA, 0); + mci_send_cmd(slot, sdmmc_cmd_bits, 0); + } else + return; } else if (clock != host->current_speed || force_clkinit) { div = host->bus_hz / clock; if (host->bus_hz % clock && host->bus_hz > clock) diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h index 0d0f7a27..ea6d4d1 100644 --- a/drivers/mmc/host/dw_mmc.h +++ b/drivers/mmc/host/dw_mmc.h @@ -15,6 +15,7 @@ #define _DW_MMC_H_ #define DW_MMC_240A 0x240a +#define DW_MMC_250A 0x250a #define SDMMC_CTRL 0x000 #define SDMMC_PWREN 0x004
According to specs for version 250A, status register should be tested before clock update. Otherwise in case MMC card is missing mci_send_cmd timeouts and subsequent CTYPE registry write causes system hang. This behavior has been observed on Exynos5422/Odroid-XU3. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> --- Hi, This version corrects usleep to usleep_range function call. Regards Andrzej --- drivers/mmc/host/dw_mmc.c | 26 ++++++++++++++++++++++++-- drivers/mmc/host/dw_mmc.h | 1 + 2 files changed, 25 insertions(+), 2 deletions(-)