Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp498028ybx; Wed, 6 Nov 2019 04:05:10 -0800 (PST) X-Google-Smtp-Source: APXvYqw93XCG6X6tJdrfdYkEVCRFtw4QZstUYvK+HCfRwGnUlU9hSoNUywK6Hi5/1J1BY3UOeAQL X-Received: by 2002:a50:ec83:: with SMTP id e3mr2235668edr.292.1573041909854; Wed, 06 Nov 2019 04:05:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573041909; cv=none; d=google.com; s=arc-20160816; b=diqN0OiFN2E4iyIdajdA6t4Z3xA4KJKBdnq+qa8TSslAsEJ5E4M43TxEuNEitRcuDS ffq82Aex/COyKOPDfz1+zXim1ZAEIvjMy/GJjnRUg0IKhovII8x8om+R3he0hoib2qG9 Wkxbdk0oVWSlAgS19gu+jPMZQbc37gkLlgpZQEUTxfYjipWlgPRnC09kYyeve5j5Nd4g Ayru2ney5/Zjfj5jnAmp/VVAKf+2UQyaFggw2K492k7+0sncmaAzkLranzZp3WWxEZ5j hC3uOqssZwLsCIQSIFIlY+PcKyDjWdkC8R9oNMFlRUogOevP7VR2F8R94KN3k+pQ0lfM xAog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject; bh=B9g3hQ+b5eN82KLtxh59vpOsr4jDN1zWjBmkIeCHURw=; b=FPaI1p6/auumnqIHqJJB/FG2UTMqFUo/w3JdMwXGgwQ1SPcKtVtXEOX0QIQfKIVsru Esyrqb1rutlOd78+S1Zl9TBCUfDZZNzL04pwk8kOA53XEKMEZS+zXE0mML3IkQvnfOXY sYT9x8GNGf4OXjGWcf4LahLqRYxvCYhreFEyAoeJhn6MpxrKpHu1InEvjTYGcPc7eBYe rzMN6cENaAxK5iYson85OfMLpE6EOen1D9ijzO3WirozeKguv+m/JSJ+JWagzb9P3YRS V/N8G446x1vUuKctvWhnuAOjdbN4/7vdhn/s3mp/rLINsU2q8X6R9tt0dHoN/8Mbn2bx b+sw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v3si15666845ejq.52.2019.11.06.04.04.46; Wed, 06 Nov 2019 04:05:09 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730630AbfKFMCF (ORCPT + 99 others); Wed, 6 Nov 2019 07:02:05 -0500 Received: from mga07.intel.com ([134.134.136.100]:36492 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727391AbfKFMCF (ORCPT ); Wed, 6 Nov 2019 07:02:05 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2019 04:02:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,274,1569308400"; d="scan'208";a="196184483" Received: from ahunter-desktop.fi.intel.com (HELO [10.237.72.197]) ([10.237.72.197]) by orsmga008.jf.intel.com with ESMTP; 06 Nov 2019 04:02:01 -0800 Subject: Re: [PATCH v5 4/4] mmc: host: sdhci: Add a variable to defer to complete data requests if needed To: Baolin Wang Cc: Ulf Hansson , asutoshd@codeaurora.org, Orson Zhai , Chunyan Zhang , Arnd Bergmann , Linus Walleij , Vincent Guittot , baolin.wang7@gmail.com, linux-mmc , LKML References: <19910a2f34b9be81f64637a5a5fc8d07bd5f4885.1572326519.git.baolin.wang@linaro.org> From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Message-ID: <2ed0bcd1-fa74-d095-97ee-7d0c46a4fdbb@intel.com> Date: Wed, 6 Nov 2019 14:01:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/11/19 12:48 PM, Baolin Wang wrote: > On Wed, 6 Nov 2019 at 18:10, Adrian Hunter wrote: >> >> On 29/10/19 7:43 AM, Baolin Wang wrote: >>> When using the host software queue, it will trigger the next request in >>> irq handler without a context switch. But the sdhci_request() can not be >>> called in interrupt context when using host software queue for some host >>> drivers, due to the get_cd() ops can be sleepable. >>> >>> But for some host drivers, such as Spreadtrum host driver, the card is >>> nonremovable, so the get_cd() ops is not sleepable, which means we can >>> complete the data request and trigger the next request in irq handler >>> to remove the context switch for the Spreadtrum host driver. >>> >>> Thus we still need introduce a variable in struct sdhci_host to indicate >>> that we will always to defer to complete data requests if the sdhci_request() >>> can not be called in interrupt context for some host drivers, when using >>> the host software queue. >>> >>> Suggested-by: Adrian Hunter >>> Signed-off-by: Baolin Wang >>> --- >>> drivers/mmc/host/sdhci.c | 2 +- >>> drivers/mmc/host/sdhci.h | 1 + >>> 2 files changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c >>> index 850241f..9cf2130 100644 >>> --- a/drivers/mmc/host/sdhci.c >>> +++ b/drivers/mmc/host/sdhci.c >>> @@ -3035,7 +3035,7 @@ static inline bool sdhci_defer_done(struct sdhci_host *host, >>> { >>> struct mmc_data *data = mrq->data; >>> >>> - return host->pending_reset || >>> + return host->pending_reset || (host->always_defer_done && data) || To move ahead in the meantime without a new host API, just defer always i.e. + return host->pending_reset || host->always_defer_done || >> >> I didn't realize you still wanted to call the request function in interrupt >> context. In my view that needs a new host API >> i.e. int (*request_atomic)(struct mmc_host *mmc, struct mmc_request *mrq) > > Actually there are no documentation said that the > mmc_host_ops->request() is a sleepable API, so I introduce a > host->always_defer_done flag to decide if the request can be called in > interrupt context or not, since for some host drivers, the request() > implementation can be called in interrupt context. > > Yes, I agree a new host API is more reasonable, if you do not like the > current approach, I can add new patches to introduce the new > request_atomic() API. But can I create another separate patch set to > do this? since in this patch set, the Spreadtrum host driver's > request() implementation can be called in interrupt context. Or you > still want these changes introducing new request_atomic() can be done > in this patch set? Thanks. > >> >>> ((host->flags & SDHCI_REQ_USE_DMA) && data && >>> data->host_cookie == COOKIE_MAPPED); >>> } >>> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h >>> index d89cdb9..38fbd18 100644 >>> --- a/drivers/mmc/host/sdhci.h >>> +++ b/drivers/mmc/host/sdhci.h >>> @@ -533,6 +533,7 @@ struct sdhci_host { >>> bool pending_reset; /* Cmd/data reset is pending */ >>> bool irq_wake_enabled; /* IRQ wakeup is enabled */ >>> bool v4_mode; /* Host Version 4 Enable */ >>> + bool always_defer_done; /* Always defer to complete data requests */ >>> >>> struct mmc_request *mrqs_done[SDHCI_MAX_MRQS]; /* Requests done */ >>> struct mmc_command *cmd; /* Current command */ >>> >> > >