[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2d6fa51d-27af-4f90-2bd6-144112ce75ad@intel.com>
Date: Tue, 28 May 2019 14:45:16 +0300
From: Adrian Hunter <adrian.hunter@...el.com>
To: Arend Van Spriel <arend.vanspriel@...adcom.com>,
Douglas Anderson <dianders@...omium.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
Kalle Valo <kvalo@...eaurora.org>
Cc: linux-rockchip@...ts.infradead.org,
Double Lo <double.lo@...ress.com>, briannorris@...omium.org,
Madhan Mohan R <madhanmohan.r@...ress.com>, mka@...omium.org,
Wright Feng <wright.feng@...ress.com>,
Chi-Hsien Lin <chi-hsien.lin@...ress.com>,
Jiong Wu <lohengrin1024@...il.com>,
Ritesh Harjani <riteshh@...eaurora.org>,
linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
Shawn Lin <shawn.lin@...k-chips.com>,
Wolfram Sang <wsa+renesas@...g-engineering.com>,
Avri Altman <avri.altman@....com>, Martin Hicks <mort@...k.org>
Subject: Re: [PATCH 2/3] mmc: core: API for temporarily disabling
auto-retuning due to errors
On 28/05/19 2:21 PM, Arend Van Spriel wrote:
>
>
> On 5/28/2019 12:04 PM, Adrian Hunter wrote:
>> On 26/05/19 9:42 PM, Arend Van Spriel wrote:
>>> On 5/18/2019 12:54 AM, Douglas Anderson wrote:
>>>> Normally when the MMC core sees an "-EILSEQ" error returned by a host
>>>> controller then it will trigger a retuning of the card. This is
>>>> generally a good idea.
>>>
>>> Probably a question for Adrian, but how is this retuning scheduled. I recall
>>> seeing something in mmc_request_done. How about deferring the retuning upon
>>> a release host or is that too sdio specific.
>>
>> Below is what I have been carrying the last 4 years. But according to
>> Douglas'
>> patch, the release would need to be further down. See 2nd diff below.
>> Would that work?
>
> That makes sense. The loop is needed because the device can be a bit bone
> headed. So indeed after the loop the device should be awake and able to
> handle CMD19.
What if tuning is needed to read SBSDIO_FUNC1_SLEEPCSR successfully?
Powered by blists - more mailing lists