From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey Brodkin Date: Fri, 11 Sep 2015 17:20:00 +0000 Subject: [U-Boot] [PATCH 1/2] mmc: dw_mmc: Increase timeout to 20 seconds In-Reply-To: <201509091334.20746.marex@denx.de> References: <1440769821-24005-1-git-send-email-l.majewski@samsung.com> <20150909090130.4385204c@amdc2363> <201509091334.20746.marex@denx.de> Message-ID: <1441991999.10291.15.camel@synopsys.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Marek, Lukasz, > On Wednesday, September 09, 2015 at 09:01:30 AM, Lukasz Majewski wrote: > > Hi, > > > > > The commit: d9dbb97be0e4a550457aec5f11afefb446169c90 > > > "mmc: dw_mmc: Zap endless timeout" removed endless loop waiting for > > > end of dw mmc transfer. > > > > > > For some workloads - dfu test @ Odroid XU3 (sending 8MiB file) - > > > and SD cards (e.g. MicroSD Kingston 4GiB, Adata 4GiB) > > > the default timeout is to short. > > > > > > The new value - 20 seconds - takes into account the situation when SD > > > card triggers internal clean up. Such process may take more than 10 > > > seconds on some cards. > > > > > > Signed-off-by: Lukasz Majewski > > > Cc: Marek Vasut > > > Cc: Pantelis Antoniou > > > Cc: Tom Rini > > > > Are there any more questions regarding this patch or is it ready for > > submission as fix for v2015.10? > > No comments, just apply this. > > But this should really be fixed properly in the next MW. > > Best regards, > Marek Vasut FWIW I faced similar problem even reading data. At least on one of my boards reading of ~8Mb file took ~1.7 seconds and so 1 second timeout was interrupting data exchange. So indeed we need to have some dirty hack for upcoming release like bumping timeout to something really huge but later we need to fix that problem properly. I though proper solution would be to set timeout depending of amount of data to be exchanged... something like take slowest speed of SD/MMC that is allowed by spec and calculate delay based on how much time it might take for that slow device and for safety multiply it by say 2. Now from this thread I see that there're other reasons that might affect length of at least write operation. In other words it could be complicated unfortunately. Still we need to fix regression first with virtually infinite timeout :) I would even thing that simple revert of Marek's patch may make sense for now. From both points of view for keeping history clean (compared to stacked fixes/workarounds) and from removal of regression root cause. It's not that I like to have infinite loops but given previous implementation worked fine for people in the previous U-Boot release. -Alexey