Re: [PATCH v1] mmc: fix async request mechanism for sequential read scenarios

[Konstantin Dorfman <kdorfman@codeaurora.org>]

Hello,

On 10/29/2012 11:40 PM, Per Forlin wrote:
> Hi,
> 
> I would like to move the focus of my concerns from root cause analysis
> to the actual patch,
> My first reflection is that the patch is relatively complex and some
> of the code looks duplicated.
> Would it be possible to simplify it and re-use  the current execution flow.
> 
> Is the following flow feasible?
> 
> in mmc_start_req():
> --------------
> if (rqc == NULL && not_resend)
>   wait_for_both_mmc_and_arrival_of_new_req
> else
>   wait_only_for_mmc
> 
> if (arrival_of_new_req) {
>    set flag to indicate fetch-new_req
>   return NULL;
> }
> -----------------
> 
> in queue.c:
> if (fetch-new_req)
>   don't overwrite previous req.
> 
> BR
> Per

You are talking about using both waiting mechanisms, old (wait on
completion) and new - wait_event_interruptible()? But how done()
callback, called on host controller irq context, will differentiate
which one is relevant for the request?

I think it is better to use single wait point for mmc thread.

Also in future plans to add second reason to wake up mmc thread from
waiting: this is urgent_request - this notification about next-to-fetch
read request, that should be executed out-of-order, using new eMMC HPI
feature (to stop currently running request).

I will publish this patch soon.

Your idea with fetch_new_req flag is good, I'll try to simplify current
patch and lets talk again.

Thanks,
-- 
Konstantin Dorfman,
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center,
Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation