From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukasz Majewski Date: Fri, 11 Sep 2015 23:45:28 +0200 Subject: [U-Boot] [PATCH 1/2] mmc: dw_mmc: Increase timeout to 20 seconds In-Reply-To: <1441991999.10291.15.camel@synopsys.com> References: <1440769821-24005-1-git-send-email-l.majewski@samsung.com> <20150909090130.4385204c@amdc2363> <201509091334.20746.marex@denx.de> <1441991999.10291.15.camel@synopsys.com> Message-ID: <20150911234528.6ba30dbe@jawa> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Alexey, > 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. Was it SD card or eMMC device? > > 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. As fair as I remember, card provide this kind of information. We can try to investigate this possibility. > > 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. My gut feeling is that proper handling of eMMC would require quite a fair mmc subsystem rework. > > 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. +1 - unfortunately there were some other patches applied to this particular patch. Simple revert might be a bit tricky here. > From both points of view for keeping history > clean (compared to stacked fixes/workarounds) and from removal of > regression root cause. As I said before - +1 from me. > > It's not that I like to have infinite loops but given previous > implementation worked fine for people in the previous U-Boot release. Good justification Best regards, Lukasz Majewski > > -Alexey > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: