From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konstantin Dorfman Subject: Re: [PATCH v1] mmc: fix async request mechanism for sequential read scenarios Date: Tue, 30 Oct 2012 14:23:13 +0200 Message-ID: <508FC6B1.2090300@codeaurora.org> References: <5088206C.7080101@stericsson.com> <50893E88.9000908@codeaurora.org> <5089549D.3060507@stericsson.com> <508D2F2E.3020006@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from wolverine01.qualcomm.com ([199.106.114.254]:63203 "EHLO wolverine01.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755632Ab2J3MXQ (ORCPT ); Tue, 30 Oct 2012 08:23:16 -0400 In-Reply-To: Sender: linux-mmc-owner@vger.kernel.org List-Id: linux-mmc@vger.kernel.org To: Per Forlin Cc: Venkatraman S , "cjb@laptop.org" , "linux-mmc@vger.kernel.org" On 10/30/2012 09:45 AM, Per Forlin wrote: > minor clarification, > > On Mon, Oct 29, 2012 at 10:40 PM, Per Forlin wrote: >> >> Is the following flow feasible? >> >> in mmc_start_req(): >> -------------- >> if (rqc == NULL && not_resend) > && request_is_ongoing (in case of resend request is never ongoing > >> wait_for_both_mmc_and_arrival_of_new_req > We should wake up if any of the two events occur. > >> 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. >> > > This is somewhat a subset of the your patch. Maybe I'm missing parts > of the complexity. > I haven't figured out why a new mmc_start_data_req() is needed. A new > mechanism for waiting is required. You're right, it was no reason to add new function, we can use mmc_start_req() and just change mechanism for waiting, I will fix this to minimize changes. -- Konstantin Dorfman, QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation