From: addy ke <addy.ke@rock-chips.com> To: javier@dowhile0.org Cc: jh80.chung@samsung.com, ulf.hansson@linaro.org, olof@lixom.net, alim.akhtar@gmail.com, a.hajda@samsung.com, dianders@chromium.org, heiko@sntech.de, cf@rock-chips.com, lintao@rock-chips.com, huangtao@rock-chips.com, linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org Subject: Re: [PATCH v4 0/3] about data busy Date: Thu, 19 Feb 2015 18:55:23 +0800 [thread overview] Message-ID: <54E5C11B.2000307@rock-chips.com> (raw) In-Reply-To: <CABxcv==G_sKsvWHX6rJP7EUv8jE=01k-JeGGXgiwiCN53pxdmQ@mail.gmail.com> Hi, Javier and Alim These days are Spring Festival holiday. Sorry for late reply. On 2015/2/15 19:41, Javier Martinez Canillas wrote: > Hello Addy, > > On Sat, Feb 14, 2015 at 7:17 AM, Addy Ke <addy.ke@rock-chips.com> wrote: >> patch 1: This patch can fix bug that controller is still data busy after >> reset all blocks. After this patch, I still get data busy in >> set_ios(). >> >> patch 2: This patch fix bug 'Timeout sending command'. After patch1 and >> patch2, there is no mmc errors after: >> cd /sys/bus/platform/drivers/dwmmc_rockchip >> for i in $(seq 1 10000); do >> echo "========================" $i >> echo ff0c0000.dwmmc > unbind >> sleep .5 >> echo ff0c0000.dwmmc > bind >> sleep 2 >> done >> >> patch3: This patch fix bug that there is data busy before sdio send CMD53. >> But This patch is necessary for sd and mmc too. >> > > I faced the same 'Timeout sending command' error when trying to enable > support for the SDIO wifi chip attached to mmc@12210000 (mmc1) on an > Exynos5420 Peach Pit Chromebook. On booting the kernel log shows: > > mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000) > > 0x202000 == SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT so your patch > #2 dw_mci_setup_bus() avoids the mmc comand to time out. However, it > has a side effect since with your series the uSD that in mmc@12220000 > (mmc2) fails to be detected and the kernel log shows: > > [ 5.466432] Waiting for root device /dev/mmcblk1p4... > [ 240.169436] INFO: task kworker/u16:1:50 blocked for more than 120 seconds. > [ 240.174844] Not tainted > 3.19.0-next-20150211-00006-g045d4aba96ce-dirty #476 > [ 240.182302] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 240.190109] kworker/u16:1 D c04c2710 0 50 2 0x00000000 > [ 240.196446] Workqueue: kmmcd mmc_rescan > [ 240.200249] [<c04c2710>] (__schedule) from [<c04c2ac0>] (schedule+0x34/0x98) > [ 240.207290] [<c04c2ac0>] (schedule) from [<c04c6568>] > (schedule_timeout+0x120/0x16c) > [ 240.215009] [<c04c6568>] (schedule_timeout) from [<c04c3584>] > (wait_for_common+0xb0/0x154) > [ 240.223251] [<c04c3584>] (wait_for_common) from [<c038a5ac>] > (mmc_wait_for_req+0xa0/0x140) > [ 240.231492] [<c038a5ac>] (mmc_wait_for_req) from [<c038a6d4>] > (mmc_wait_for_cmd+0x88/0xa8) > [ 240.239735] [<c038a6d4>] (mmc_wait_for_cmd) from [<c03905b0>] > (mmc_go_idle+0x78/0xf8) > [ 240.247540] [<c03905b0>] (mmc_go_idle) from [<c038c578>] > (mmc_rescan+0x254/0x300) > [ 240.255003] [<c038c578>] (mmc_rescan) from [<c00346e8>] > (process_one_work+0x120/0x324) > [ 240.262897] [<c00346e8>] (process_one_work) from [<c0034a58>] > (worker_thread+0x138/0x464) > [ 240.271048] [<c0034a58>] (worker_thread) from [<c0039070>] > (kthread+0xd8/0xf4) > [ 240.278254] [<c0039070>] (kthread) from [<c000e680>] > (ret_from_fork+0x14/0x34) > > > By enabling debug I see that the card is detected in dw_mci_get_cd() though. > > Alim suggested [0] that dw_mci_wait_busy() should be called in > mci_send_cmd() instead dw_mci_setup_bus() because the controller hangs > when when sending update clock cmd in different cases. > > I modified [1] your patch #2 to do what Alim suggested and only with > that patch on top of linux-next I have neither the the "Timeout > sending command" error nor the uSD not getting detected errors. Linux > mounts the rootfs from the uSD and the wifi SDIO device is enumerated > and listed in /sys/bus/sdio/devices/ > > Does that also solve your issue? After merge Alim patch,and set re_try 8, it can pass test by: cd /sys/bus/platform/drivers/dwmmc_rockchip for i in $(seq 1 10000); do echo "========================" $i echo ff0c0000.dwmmc > unbind sleep .5 echo ff0c0000.dwmmc > bind sleep 2 done My card is ADATA UHS-1 card(SDR50). The maximum retry count is 6. [ 1146.907596] mmc1: card 59b4 removed [ 1147.421036] dwmmc_rockchip ff0c0000.dwmmc: Using internal DMA controller. [ 1147.427827] dwmmc_rockchip ff0c0000.dwmmc: Version ID is 270a [ 1147.433958] dwmmc_rockchip ff0c0000.dwmmc: DW MMC controller at irq 64, 32 bit host data width, 256 deep fifo [ 1147.444269] dwmmc_rockchip ff0c0000.dwmmc: Got CD GPIO #221. [ 1147.450381] dwmmc_rockchip ff0c0000.dwmmc: Got WP GPIO #226. [ 1147.456046] ff0c0000.dwmmc supply card-external-vcc not found, using dummy regulator [ 1148.519400] dwmmc_rockchip ff0c0000.dwmmc: Data busy (status 0x206) [ 1149.019451] dwmmc_rockchip ff0c0000.dwmmc: Data busy (status 0x206) [ 1149.519382] dwmmc_rockchip ff0c0000.dwmmc: Data busy (status 0x206) [ 1150.019492] dwmmc_rockchip ff0c0000.dwmmc: Data busy (status 0x206) [ 1150.519442] dwmmc_rockchip ff0c0000.dwmmc: Data busy (status 0x206) >>>>>>>>>>>>>>>>>>>>>>>>> if re_try is 5, I still get "Timeout sending command". [ 1150.525711] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000) [ 1150.534723] rockchip-iodomain io-domains.25: Setting to 3300000 done So re_try must bigger than 6, but I don't known which value is reansonable. Do you have any idear about it? This is the patch Alim suggests: + int re_try = 8; /* just random for now, 1 re-try should be ok */ - mci_writel(host, CMDARG, arg); - wmb(); - mci_writel(host, CMD, SDMMC_CMD_START | cmd); + while(re_try--) { + mci_writel(host, CMDARG, arg); + wmb(); + mci_writel(host, CMD, SDMMC_CMD_START | cmd); - while (time_before(jiffies, timeout)) { - cmd_status = mci_readl(host, CMD); - if (!(cmd_status & SDMMC_CMD_START)) - return; + while (time_before(jiffies, timeout)) { + cmd_status = mci_readl(host, CMD); + if (!(cmd_status & SDMMC_CMD_START)) + return; + } + + dw_mci_wait_busy(slot); > > Best regards, > Javier > > [0]: https://lkml.org/lkml/2015/2/10/353 > [1]: http://paste.debian.net/plain/148794 > > >
WARNING: multiple messages have this Message-ID (diff)
From: addy.ke@rock-chips.com (addy ke) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v4 0/3] about data busy Date: Thu, 19 Feb 2015 18:55:23 +0800 [thread overview] Message-ID: <54E5C11B.2000307@rock-chips.com> (raw) In-Reply-To: <CABxcv==G_sKsvWHX6rJP7EUv8jE=01k-JeGGXgiwiCN53pxdmQ@mail.gmail.com> Hi, Javier and Alim These days are Spring Festival holiday. Sorry for late reply. On 2015/2/15 19:41, Javier Martinez Canillas wrote: > Hello Addy, > > On Sat, Feb 14, 2015 at 7:17 AM, Addy Ke <addy.ke@rock-chips.com> wrote: >> patch 1: This patch can fix bug that controller is still data busy after >> reset all blocks. After this patch, I still get data busy in >> set_ios(). >> >> patch 2: This patch fix bug 'Timeout sending command'. After patch1 and >> patch2, there is no mmc errors after: >> cd /sys/bus/platform/drivers/dwmmc_rockchip >> for i in $(seq 1 10000); do >> echo "========================" $i >> echo ff0c0000.dwmmc > unbind >> sleep .5 >> echo ff0c0000.dwmmc > bind >> sleep 2 >> done >> >> patch3: This patch fix bug that there is data busy before sdio send CMD53. >> But This patch is necessary for sd and mmc too. >> > > I faced the same 'Timeout sending command' error when trying to enable > support for the SDIO wifi chip attached to mmc at 12210000 (mmc1) on an > Exynos5420 Peach Pit Chromebook. On booting the kernel log shows: > > mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000) > > 0x202000 == SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT so your patch > #2 dw_mci_setup_bus() avoids the mmc comand to time out. However, it > has a side effect since with your series the uSD that in mmc at 12220000 > (mmc2) fails to be detected and the kernel log shows: > > [ 5.466432] Waiting for root device /dev/mmcblk1p4... > [ 240.169436] INFO: task kworker/u16:1:50 blocked for more than 120 seconds. > [ 240.174844] Not tainted > 3.19.0-next-20150211-00006-g045d4aba96ce-dirty #476 > [ 240.182302] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 240.190109] kworker/u16:1 D c04c2710 0 50 2 0x00000000 > [ 240.196446] Workqueue: kmmcd mmc_rescan > [ 240.200249] [<c04c2710>] (__schedule) from [<c04c2ac0>] (schedule+0x34/0x98) > [ 240.207290] [<c04c2ac0>] (schedule) from [<c04c6568>] > (schedule_timeout+0x120/0x16c) > [ 240.215009] [<c04c6568>] (schedule_timeout) from [<c04c3584>] > (wait_for_common+0xb0/0x154) > [ 240.223251] [<c04c3584>] (wait_for_common) from [<c038a5ac>] > (mmc_wait_for_req+0xa0/0x140) > [ 240.231492] [<c038a5ac>] (mmc_wait_for_req) from [<c038a6d4>] > (mmc_wait_for_cmd+0x88/0xa8) > [ 240.239735] [<c038a6d4>] (mmc_wait_for_cmd) from [<c03905b0>] > (mmc_go_idle+0x78/0xf8) > [ 240.247540] [<c03905b0>] (mmc_go_idle) from [<c038c578>] > (mmc_rescan+0x254/0x300) > [ 240.255003] [<c038c578>] (mmc_rescan) from [<c00346e8>] > (process_one_work+0x120/0x324) > [ 240.262897] [<c00346e8>] (process_one_work) from [<c0034a58>] > (worker_thread+0x138/0x464) > [ 240.271048] [<c0034a58>] (worker_thread) from [<c0039070>] > (kthread+0xd8/0xf4) > [ 240.278254] [<c0039070>] (kthread) from [<c000e680>] > (ret_from_fork+0x14/0x34) > > > By enabling debug I see that the card is detected in dw_mci_get_cd() though. > > Alim suggested [0] that dw_mci_wait_busy() should be called in > mci_send_cmd() instead dw_mci_setup_bus() because the controller hangs > when when sending update clock cmd in different cases. > > I modified [1] your patch #2 to do what Alim suggested and only with > that patch on top of linux-next I have neither the the "Timeout > sending command" error nor the uSD not getting detected errors. Linux > mounts the rootfs from the uSD and the wifi SDIO device is enumerated > and listed in /sys/bus/sdio/devices/ > > Does that also solve your issue? After merge Alim patch,and set re_try 8, it can pass test by: cd /sys/bus/platform/drivers/dwmmc_rockchip for i in $(seq 1 10000); do echo "========================" $i echo ff0c0000.dwmmc > unbind sleep .5 echo ff0c0000.dwmmc > bind sleep 2 done My card is ADATA UHS-1 card(SDR50). The maximum retry count is 6. [ 1146.907596] mmc1: card 59b4 removed [ 1147.421036] dwmmc_rockchip ff0c0000.dwmmc: Using internal DMA controller. [ 1147.427827] dwmmc_rockchip ff0c0000.dwmmc: Version ID is 270a [ 1147.433958] dwmmc_rockchip ff0c0000.dwmmc: DW MMC controller at irq 64, 32 bit host data width, 256 deep fifo [ 1147.444269] dwmmc_rockchip ff0c0000.dwmmc: Got CD GPIO #221. [ 1147.450381] dwmmc_rockchip ff0c0000.dwmmc: Got WP GPIO #226. [ 1147.456046] ff0c0000.dwmmc supply card-external-vcc not found, using dummy regulator [ 1148.519400] dwmmc_rockchip ff0c0000.dwmmc: Data busy (status 0x206) [ 1149.019451] dwmmc_rockchip ff0c0000.dwmmc: Data busy (status 0x206) [ 1149.519382] dwmmc_rockchip ff0c0000.dwmmc: Data busy (status 0x206) [ 1150.019492] dwmmc_rockchip ff0c0000.dwmmc: Data busy (status 0x206) [ 1150.519442] dwmmc_rockchip ff0c0000.dwmmc: Data busy (status 0x206) >>>>>>>>>>>>>>>>>>>>>>>>> if re_try is 5, I still get "Timeout sending command". [ 1150.525711] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000) [ 1150.534723] rockchip-iodomain io-domains.25: Setting to 3300000 done So re_try must bigger than 6, but I don't known which value is reansonable. Do you have any idear about it? This is the patch Alim suggests: + int re_try = 8; /* just random for now, 1 re-try should be ok */ - mci_writel(host, CMDARG, arg); - wmb(); - mci_writel(host, CMD, SDMMC_CMD_START | cmd); + while(re_try--) { + mci_writel(host, CMDARG, arg); + wmb(); + mci_writel(host, CMD, SDMMC_CMD_START | cmd); - while (time_before(jiffies, timeout)) { - cmd_status = mci_readl(host, CMD); - if (!(cmd_status & SDMMC_CMD_START)) - return; + while (time_before(jiffies, timeout)) { + cmd_status = mci_readl(host, CMD); + if (!(cmd_status & SDMMC_CMD_START)) + return; + } + + dw_mci_wait_busy(slot); > > Best regards, > Javier > > [0]: https://lkml.org/lkml/2015/2/10/353 > [1]: http://paste.debian.net/plain/148794 > > >
next prev parent reply other threads:[~2015-02-19 10:55 UTC|newest] Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-02-05 11:13 [PATCH] mmc: dw_mmc: fix bug that cause 'Timeout sending command' Addy Ke 2015-02-05 11:13 ` Addy Ke 2015-02-09 4:48 ` Ulf Hansson 2015-02-09 4:51 ` Ulf Hansson 2015-02-09 4:51 ` Ulf Hansson 2015-02-09 4:51 ` Ulf Hansson 2015-02-09 6:56 ` Addy 2015-02-09 6:56 ` Addy 2015-02-09 6:56 ` Addy 2015-02-09 7:04 ` Jaehoon Chung 2015-02-09 7:04 ` Jaehoon Chung 2015-02-09 7:04 ` Jaehoon Chung 2015-02-09 9:17 ` addy ke 2015-02-09 9:17 ` addy ke 2015-02-09 9:17 ` addy ke 2015-02-09 7:25 ` [PATCH v2 0/2] about data busy Addy Ke 2015-02-09 7:25 ` Addy Ke 2015-02-09 7:25 ` Addy Ke 2015-02-09 7:25 ` [PATCH v2 1/2] mmc: dw_mmc: fix bug that cause 'Timeout sending command' Addy Ke 2015-02-09 7:25 ` Addy Ke 2015-02-09 10:01 ` Jaehoon Chung 2015-02-09 10:01 ` Jaehoon Chung 2015-02-11 3:07 ` Addy 2015-02-11 3:07 ` Addy 2015-02-10 15:22 ` Alim Akhtar 2015-02-10 15:22 ` Alim Akhtar 2015-02-10 15:22 ` Alim Akhtar 2015-02-11 2:57 ` Addy 2015-02-11 2:57 ` Addy 2015-02-11 2:57 ` Addy 2015-02-11 3:25 ` Ulf Hansson 2015-02-11 3:46 ` Jaehoon Chung 2015-02-11 3:52 ` Ulf Hansson 2015-02-11 11:58 ` Andrzej Hajda 2015-02-11 23:20 ` Alim Akhtar 2015-02-11 23:20 ` Alim Akhtar 2015-02-12 2:28 ` addy ke 2015-02-12 11:10 ` Andrzej Hajda 2015-02-12 13:59 ` Alim Akhtar 2015-02-12 13:59 ` Alim Akhtar 2015-02-13 8:15 ` addy ke 2015-02-12 11:13 ` Andrzej Hajda 2015-02-12 11:13 ` Andrzej Hajda 2015-02-12 13:53 ` Alim Akhtar 2015-02-12 13:53 ` Alim Akhtar 2015-02-09 7:25 ` [PATCH v2 2/2] mmc: dw_mmc: Don't start command while data busy Addy Ke 2015-02-09 7:25 ` Addy Ke 2015-02-13 11:52 ` [PATCH v3 0/3] about " Addy Ke 2015-02-13 11:52 ` Addy Ke 2015-02-13 11:52 ` [PATCH v3 1/3] mmc: dw_mmc: update clock after host reach a stable voltage Addy Ke 2015-02-13 11:52 ` Addy Ke 2015-02-13 11:52 ` [PATCH v3 2/3] mmc: dw_mmc: fix bug that cause 'Timeout sending command' Addy Ke 2015-02-13 11:52 ` Addy Ke 2015-02-13 11:52 ` [PATCH v3 3/3] mmc: dw_mmc: Don't start command while data busy Addy Ke 2015-02-13 11:52 ` Addy Ke 2015-02-14 6:17 ` [PATCH v4 0/3] about " Addy Ke 2015-02-14 6:17 ` Addy Ke 2015-02-14 6:17 ` [PATCH v4 1/3] mmc: dw_mmc: update clock after host reach a stable voltage Addy Ke 2015-02-14 6:17 ` Addy Ke 2015-02-15 23:28 ` Alim Akhtar 2015-02-15 23:28 ` Alim Akhtar 2015-02-19 10:30 ` addy ke 2015-02-19 10:30 ` addy ke 2015-02-19 23:49 ` Doug Anderson 2015-02-19 23:49 ` Doug Anderson 2015-02-20 0:02 ` Russell King - ARM Linux 2015-02-20 0:02 ` Russell King - ARM Linux 2015-02-20 1:04 ` Doug Anderson 2015-02-20 1:04 ` Doug Anderson 2015-02-20 19:05 ` Doug Anderson 2015-02-20 19:05 ` Doug Anderson 2015-02-25 7:52 ` Alim Akhtar 2015-02-25 7:52 ` Alim Akhtar 2015-02-25 9:56 ` Jaehoon Chung 2015-02-25 9:56 ` Jaehoon Chung 2015-02-25 21:05 ` Doug Anderson 2015-02-25 21:05 ` Doug Anderson 2015-02-14 6:17 ` [PATCH v4 2/3] mmc: dw_mmc: fix bug that cause 'Timeout sending command' Addy Ke 2015-02-14 6:17 ` Addy Ke 2015-02-14 6:17 ` [PATCH v4 3/3] mmc: dw_mmc: Don't start command while data busy Addy Ke 2015-02-14 6:17 ` Addy Ke 2015-02-20 0:21 ` Doug Anderson 2015-02-20 0:21 ` Doug Anderson 2015-02-15 11:41 ` [PATCH v4 0/3] about " Javier Martinez Canillas 2015-02-15 11:41 ` Javier Martinez Canillas 2015-02-16 5:48 ` Jaehoon Chung 2015-02-16 5:48 ` Jaehoon Chung 2015-02-16 11:09 ` Javier Martinez Canillas 2015-02-16 11:09 ` Javier Martinez Canillas 2015-02-19 10:55 ` addy ke [this message] 2015-02-19 10:55 ` addy ke 2015-02-20 19:03 ` Doug Anderson 2015-02-20 19:03 ` Doug Anderson
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=54E5C11B.2000307@rock-chips.com \ --to=addy.ke@rock-chips.com \ --cc=a.hajda@samsung.com \ --cc=alim.akhtar@gmail.com \ --cc=cf@rock-chips.com \ --cc=dianders@chromium.org \ --cc=heiko@sntech.de \ --cc=huangtao@rock-chips.com \ --cc=javier@dowhile0.org \ --cc=jh80.chung@samsung.com \ --cc=lintao@rock-chips.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mmc@vger.kernel.org \ --cc=linux-rockchip@lists.infradead.org \ --cc=olof@lixom.net \ --cc=ulf.hansson@linaro.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.