Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp4101513ybb; Tue, 7 Apr 2020 00:23:07 -0700 (PDT) X-Google-Smtp-Source: APiQypKUknS7CGibdCsicfsx7dZ5Q3o/OO2pH5FdYDrMoxNNeDz9r1IYVHZeMflo2ixofIt0FVIy X-Received: by 2002:a9d:27a7:: with SMTP id c36mr499072otb.68.1586244186922; Tue, 07 Apr 2020 00:23:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586244186; cv=none; d=google.com; s=arc-20160816; b=rHTbRTdp0WMO7XgE7MMNjEHzlPUbXTBuYy/Kxi9DeAiWEtodtMzIzdxjc5PvwT3sFk P2sIPYvULPtts0OSW7d/2aFged8QOl18irxS0V8flT99v9BqzNO6DZyItINgh21Yy136 fF5mP7nhxndIm2rWHXDqufpeBQjayGQW2rG9GGbkt5izyskfYn7sDBiwPMcTVX8u3SZt 4mMs/MwQScOL2QDtq3aRPtzchodByCggF2y+8rFBPyoeKwleDpC/4KbHXPfKVxuAAP9M 8fw0Qeu/lKaFG6iq34jMYWGUNphNuEcfPxcGw3wndDn4CSf9d7Q833HFYePWd2LCl01a iX1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=EgyJX/tT/p7EOsEfgotNMj1exMf/z2jpwTwXDaChsqw=; b=QmCl/ZiuoqUs0UZE0FJIAs0BctLnjef1MhAMOLLD9gk3F66HZOlMKrqtJ4xRFAPnwU Ia5ZlUiRiIh7KEgnpXjX3cEDeg7X4krHsjWZQWQQS+HIr40uVA/ECQsmly36o80lJBX6 nsTrx1CciIjr7+9hnOhIjEXFkApjpl9+ckxqs0FLGaMaYzQ+Py9p+W0xtb+whU2hPeUu AR/7aoDcd8mMbyf+ZviF38L+H/JdSbawV2+KIcTg0ubSKihfY2i9AA8k6TxDayTkS57f MkdeRQc9P2MWX6x3v0aoeNf1aZP3ZLLoJt9NfNJnXDOzeKvfessY0g5XoK2KrLRsfatX GBTQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=d23qVeU9; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e27si914011oth.300.2020.04.07.00.22.55; Tue, 07 Apr 2020 00:23:06 -0700 (PDT) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=d23qVeU9; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727549AbgDGHVr (ORCPT + 99 others); Tue, 7 Apr 2020 03:21:47 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:39001 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726591AbgDGHVr (ORCPT ); Tue, 7 Apr 2020 03:21:47 -0400 Received: by mail-lj1-f194.google.com with SMTP id i20so2501506ljn.6; Tue, 07 Apr 2020 00:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EgyJX/tT/p7EOsEfgotNMj1exMf/z2jpwTwXDaChsqw=; b=d23qVeU9A4iyXSxPoFvo0fxSxwBchKebgTpZOFTYf5W6FShO0c7apqTiKZWJ0scD9o +RJbdP9KUDcwvWa+cjICZ0HVm1zes1M2o0YaacNoGAWEFK2gKIZfRBpb9XihKzzXCpH1 4FTWO+3wjPZNkD1U+7jLnZlYFrmGbT6TYAoC1LwrvgMPcW4novFqlVI4xsjdsR6D7m4b 91klmrIbMdJ1nv/SjIwbZ3ThK5usw+9lgkgdm1sgkG7BZpud8XUVq28luJCI9YHlQUZ7 rwSsjhEKvVi0agDwF/qLD5JZe2k3FcQEMJTSyAe8JWwlsuMC/kmX0XvRpCpmSG2dZoIw Dj6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EgyJX/tT/p7EOsEfgotNMj1exMf/z2jpwTwXDaChsqw=; b=RSLStfHNelRZ/1iAz9Jjmhwsp8nDT++z1m5W/FYgzu0d/oVJAt9g4v/JkHNerpu5rE zKF44qUiPsSIe8i/oHAQBAljxiQO6WUiQFmqk2n5xp53OqLNUmZvJYAUyr14NjgXo36f H6N0ccNN0kT8XuwA6pho8K+7cqvaDeqMcrtBi6+Ppfe2Pt+W8QRigd/ShFS2pSKZkdm6 jOuwkJO1Ux5+NUf+osp0yRe8XjLfW365SwhaqXCiSy3ZRGgmj+sZcTbiuW+ld0Mf/3Sz zQJlCkAHxw0QikqqTTCAs13B4xtSyhfdDSHtXP45oZY4eDgVmV6ycdVJEsY07Jb2Xl7i tlYQ== X-Gm-Message-State: AGi0PuZJ5w1B3eT6dCVNcGAOWSLn1cG6+6K4r9Ed7kZXUojYb3uq/uVL QBzb2qAfMrQy5ZByuBJiL/hMbgYOGmR8a9avnDM= X-Received: by 2002:a2e:89c5:: with SMTP id c5mr784501ljk.48.1586244104623; Tue, 07 Apr 2020 00:21:44 -0700 (PDT) MIME-Version: 1.0 References: <04c25ff9f9b17d41d734c498e4be61dee745bb30.1585896945.git.baolin.wang7@gmail.com> <5a55947b-e920-4515-49cf-163f6d539421@intel.com> In-Reply-To: <5a55947b-e920-4515-49cf-163f6d539421@intel.com> From: Baolin Wang Date: Tue, 7 Apr 2020 15:21:33 +0800 Message-ID: Subject: Re: [PATCH v4 1/3] mmc: host: Introduce the request_atomic() for the host To: Adrian Hunter Cc: Ulf Hansson , Orson Zhai , Chunyan Zhang , Arnd Bergmann , linux-mmc , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 7, 2020 at 2:38 PM Adrian Hunter wrote: > > On 3/04/20 10:05 am, Baolin Wang wrote: > > The SD host controller can process one request in the atomic context if > > the card is nonremovable, which means we can submit next request in the > > irq hard handler when using the MMC host software queue to reduce the > > latency. Thus this patch adds a new API request_atomic() for the host > > controller, as well as adding support for host software queue to submit > > a request by the new request_atomic() API. > > > > Moreover there is an unusual case that the card is busy when trying to > > send a command, and we can not polling the card status in interrupt > > context by using request_atomic() to dispatch requests. Thus we should > > queue a work to try again in the non-atomic context in case the host > > releases the busy signal later. > > > > Suggested-by: Adrian Hunter > > Signed-off-by: Baolin Wang > > > One minor point below, otherwise: > > Acked-by: Adrian Hunter > > > --- > > drivers/mmc/host/mmc_hsq.c | 29 ++++++++++++++++++++++++++++- > > drivers/mmc/host/mmc_hsq.h | 1 + > > include/linux/mmc/host.h | 3 +++ > > 3 files changed, 32 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/mmc/host/mmc_hsq.c b/drivers/mmc/host/mmc_hsq.c > > index b90b2c9..a57f802 100644 > > --- a/drivers/mmc/host/mmc_hsq.c > > +++ b/drivers/mmc/host/mmc_hsq.c > > @@ -16,11 +16,20 @@ > > #define HSQ_NUM_SLOTS 64 > > #define HSQ_INVALID_TAG HSQ_NUM_SLOTS > > > > +static void mmc_hsq_retry_handler(struct work_struct *work) > > +{ > > + struct mmc_hsq *hsq = container_of(work, struct mmc_hsq, retry_work); > > + struct mmc_host *mmc = hsq->mmc; > > + > > + mmc->ops->request(mmc, hsq->mrq); > > +} > > + > > static void mmc_hsq_pump_requests(struct mmc_hsq *hsq) > > { > > struct mmc_host *mmc = hsq->mmc; > > struct hsq_slot *slot; > > unsigned long flags; > > + int ret = 0; > > > > spin_lock_irqsave(&hsq->lock, flags); > > > > @@ -42,7 +51,24 @@ static void mmc_hsq_pump_requests(struct mmc_hsq *hsq) > > > > spin_unlock_irqrestore(&hsq->lock, flags); > > > > - mmc->ops->request(mmc, hsq->mrq); > > + if (mmc->ops->request_atomic) > > + ret = mmc->ops->request_atomic(mmc, hsq->mrq); > > + else > > + mmc->ops->request(mmc, hsq->mrq); > > + > > + /* > > + * If returning BUSY from request_atomic(), which means the card > > + * may be busy now, and we should change to non-atomic context to > > + * try again for this unusual case, to avoid time-consuming operations > > + * in the atomic context. > > + * > > + * Note: we just give a warning for other error cases, since the host > > + * driver will handle them. > > + */ > > + if (ret == -EBUSY) > > + schedule_work(&hsq->retry_work); > > + else > > + WARN_ON_ONCE(ret && ret != -EBUSY); > > 'ret != -EBUSY' is redundant because it is always true in the 'else' clause. Ah, Yes, thanks for pointing this out and I will fix it ine next version. By the way, could you help to review patch 2 and 3 in this patch set? Thanks. > > } > > > > static void mmc_hsq_update_next_tag(struct mmc_hsq *hsq, int remains) > > @@ -325,6 +351,7 @@ int mmc_hsq_init(struct mmc_hsq *hsq, struct mmc_host *mmc) > > hsq->mmc->cqe_private = hsq; > > mmc->cqe_ops = &mmc_hsq_ops; > > > > + INIT_WORK(&hsq->retry_work, mmc_hsq_retry_handler); > > spin_lock_init(&hsq->lock); > > init_waitqueue_head(&hsq->wait_queue); > > > > diff --git a/drivers/mmc/host/mmc_hsq.h b/drivers/mmc/host/mmc_hsq.h > > index 18b9cf5..ffdd9cd 100644 > > --- a/drivers/mmc/host/mmc_hsq.h > > +++ b/drivers/mmc/host/mmc_hsq.h > > @@ -12,6 +12,7 @@ struct mmc_hsq { > > wait_queue_head_t wait_queue; > > struct hsq_slot *slot; > > spinlock_t lock; > > + struct work_struct retry_work; > > > > int next_tag; > > int num_slots; > > diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h > > index c318fb5..d4a50e5d 100644 > > --- a/include/linux/mmc/host.h > > +++ b/include/linux/mmc/host.h > > @@ -92,6 +92,9 @@ struct mmc_host_ops { > > int err); > > void (*pre_req)(struct mmc_host *host, struct mmc_request *req); > > void (*request)(struct mmc_host *host, struct mmc_request *req); > > + /* Submit one request to host in atomic context. */ > > + int (*request_atomic)(struct mmc_host *host, > > + struct mmc_request *req); > > > > /* > > * Avoid calling the next three functions too often or in a "fast > > > -- Baolin Wang