On 11 February 2016 at 14:32, Wolfram Sang <wsa@xxxxxxxxxxxxx> wrote: > On Thu, Feb 11, 2016 at 10:00:50AM +0100, Ulf Hansson wrote: >> On 11 February 2016 at 01:07, Wolfram Sang <wsa@xxxxxxxxxxxxx> wrote: >> >> I suspect you are using a delayed work in this driver to deal with >> >> request timeouts. >> >> >> >> The value for the delay that is used, needs to be informed towards the >> >> mmc core via the "->max_busy_timeout". >> > >> > Shouldn't that be a seperate patch? In patch 9, I add support for >> > another SoC. But your requested change will affect all SoCs. >> >> This is related to how the core treat hosts that announces >> MMC_CAP_WAIT_WHILE_BUSY. >> >> Therefore max_busy_timeout needs to be set within the same patch. > > Right. I assumed previous SoC (Gen2) were using MMC_CAP_WAIT_WHILE_BUSY > already, so this step would then have to be taken seperately to catch > all SoC. But I was wrong. > > I meanwhile found the timeout bits which are present in Gen3 and also in > Gen2 and are currently unused by the driver. While this helps explaining > that the HW has internal busy detection, its full potential is not > implemented yet. > > So, I am going to resend patch 9 without MMC_CAP_WAIT_WHILE_BUSY set and > will implement timeout handling incrementally as a seperate series. > > Sounds good? Yes, please! Kind regards Uffe
