Messages in this thread | | | Date | Thu, 26 Aug 2021 08:31:28 -0400 | From | Sasha Levin <> | Subject | Re: [PATCH 4.4 25/31] mmc: dw_mmc: Wait for data transfer after response errors. |
| |
On Thu, Aug 26, 2021 at 08:59:53PM +0900, Nobuhiro Iwamatsu wrote: >Hi, > > >2021年8月25日(水) 2:39 Sasha Levin <sashal@kernel.org>: >> >> From: Doug Anderson <dianders@chromium.org> >> >> [ Upstream commit 46d179525a1f6d16957dcb4624517bc04142b3e7 ] >> >> According to the DesignWare state machine description, after we get a >> "response error" or "response CRC error" we move into data transfer >> mode. That means that we don't necessarily need to special case >> trying to deal with the failure right away. We can wait until we are >> notified that the data transfer is complete (with or without errors) >> and then we can deal with the failure. >> >> It may sound strange to defer dealing with a command that we know will >> fail anyway, but this appears to fix a bug. During tuning (CMD19) on >> a specific card on an rk3288-based system, we found that we could get >> a "response CRC error". Sending the stop command after the "response >> CRC error" would then throw the system into a confused state causing >> all future tuning phases to report failure. >> >> When in the confused state, the controller would show these (hex codes >> are interrupt status register): >> CMD ERR: 0x00000046 (cmd=19) >> CMD ERR: 0x0000004e (cmd=12) >> DATA ERR: 0x00000208 >> DATA ERR: 0x0000020c >> CMD ERR: 0x00000104 (cmd=19) >> CMD ERR: 0x00000104 (cmd=12) >> DATA ERR: 0x00000208 >> DATA ERR: 0x0000020c >> ... >> ... >> >> It is inherently difficult to deal with the complexity of trying to >> correctly send a stop command while a data transfer is taking place >> since you need to deal with different corner cases caused by the fact >> that the data transfer could complete (with errors or without errors) >> during various places in sending the stop command (dw_mci_stop_dma, >> send_stop_abort, etc) >> >> Instead of adding a bunch of extra complexity to deal with this, it >> seems much simpler to just use the more straightforward (and less >> error-prone) path of letting the data transfer finish. There >> shouldn't be any huge benefit to sending the stop command slightly >> earlier, anyway. >> >> Signed-off-by: Doug Anderson <dianders@chromium.org> >> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> >> Cc: Alim Akhtar <alim.akhtar@gmail.com> >> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> >> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> >> Signed-off-by: Sasha Levin <sashal@kernel.org> > >This commit also requires the following modifications: > ba2d139b02ba68: mmc: dw_mmc: Fix occasional hang after tuning on eMMC > >Please apply this commit too.
Will do, thanks!
-- Thanks, Sasha
| |