[PATCH v4 0/3] about data busy
jh80.chung at samsung.com
Sun Feb 15 21:48:38 PST 2015
On 02/15/2015 08:41 PM, Javier Martinez Canillas wrote:
> Hello Addy,
> On Sat, Feb 14, 2015 at 7:17 AM, Addy Ke <addy.ke at 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
>> 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
>> 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>]
> [ 240.215009] [<c04c6568>] (schedule_timeout) from [<c04c3584>]
> [ 240.223251] [<c04c3584>] (wait_for_common) from [<c038a5ac>]
> [ 240.231492] [<c038a5ac>] (mmc_wait_for_req) from [<c038a6d4>]
> [ 240.239735] [<c038a6d4>] (mmc_wait_for_cmd) from [<c03905b0>]
> [ 240.247540] [<c03905b0>] (mmc_go_idle) from [<c038c578>]
> [ 240.255003] [<c038c578>] (mmc_rescan) from [<c00346e8>]
> [ 240.262897] [<c00346e8>] (process_one_work) from [<c0034a58>]
> [ 240.271048] [<c0034a58>] (worker_thread) from [<c0039070>]
> [ 240.278254] [<c0039070>] (kthread) from [<c000e680>]
> By enabling debug I see that the card is detected in dw_mci_get_cd() though.
> Alim suggested  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  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/
it needs to check when clock value only update.
As Javier and Alim are mentioned, if check whether card is busy or not in setup_bus(),
should be processed unnecessary checking.
(According to TRM, before disabling clock, check whether card is busy or not.)
if my thinking is right, chekcing is located more exactly before mci_writel(host, CLKENA, 0).
And i recommend if CLK_GATE is enabled, clkgate_delay sets to the bigger value than 3.
I'm not sure Javier's issue is same thing..I will check more this.
> Does that also solve your issue?
> Best regards,
> : https://lkml.org/lkml/2015/2/10/353
> : http://paste.debian.net/plain/148794
More information about the Linux-rockchip