Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753130AbbBSKzi (ORCPT ); Thu, 19 Feb 2015 05:55:38 -0500 Received: from regular1.263xmail.com ([211.150.99.132]:36243 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752462AbbBSKzg (ORCPT ); Thu, 19 Feb 2015 05:55:36 -0500 X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-RL-SENDER: addy.ke@rock-chips.com X-FST-TO: linux-rockchip@lists.infradead.org X-SENDER-IP: 58.22.114.113 X-LOGIN-NAME: addy.ke@rock-chips.com X-UNIQUE-TAG: <69a05154a3133d059c885f0920273982> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Message-ID: <54E5C11B.2000307@rock-chips.com> Date: Thu, 19 Feb 2015 18:55:23 +0800 From: addy ke User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 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 References: <1423828368-18456-1-git-send-email-addy.ke@rock-chips.com> <1423894668-8886-1-git-send-email-addy.ke@rock-chips.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6415 Lines: 154 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 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] [] (__schedule) from [] (schedule+0x34/0x98) > [ 240.207290] [] (schedule) from [] > (schedule_timeout+0x120/0x16c) > [ 240.215009] [] (schedule_timeout) from [] > (wait_for_common+0xb0/0x154) > [ 240.223251] [] (wait_for_common) from [] > (mmc_wait_for_req+0xa0/0x140) > [ 240.231492] [] (mmc_wait_for_req) from [] > (mmc_wait_for_cmd+0x88/0xa8) > [ 240.239735] [] (mmc_wait_for_cmd) from [] > (mmc_go_idle+0x78/0xf8) > [ 240.247540] [] (mmc_go_idle) from [] > (mmc_rescan+0x254/0x300) > [ 240.255003] [] (mmc_rescan) from [] > (process_one_work+0x120/0x324) > [ 240.262897] [] (process_one_work) from [] > (worker_thread+0x138/0x464) > [ 240.271048] [] (worker_thread) from [] > (kthread+0xd8/0xf4) > [ 240.278254] [] (kthread) from [] > (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 > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/