From patchwork Thu Feb 9 15:33:51 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 9565059 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 30A6A60216 for ; Thu, 9 Feb 2017 16:08:53 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1EFEF28450 for ; Thu, 9 Feb 2017 16:08:53 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 123AF28480; Thu, 9 Feb 2017 16:08:53 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9438428450 for ; Thu, 9 Feb 2017 16:08:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751226AbdBIQIv (ORCPT ); Thu, 9 Feb 2017 11:08:51 -0500 Received: from mail-lf0-f48.google.com ([209.85.215.48]:32800 "EHLO mail-lf0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751722AbdBIQIu (ORCPT ); Thu, 9 Feb 2017 11:08:50 -0500 Received: by mail-lf0-f48.google.com with SMTP id x1so5190743lff.0 for ; Thu, 09 Feb 2017 08:07:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=XW7KvRqBWr3hFy8GfNhHyJ9vA/FQrqihEf8e/iVI+bU=; b=YiSIkY4i3YEIeA+702FdsV1xU3abrDFE4icC/VD6YMjbQB4b6RnDLsnaKgn6ZiQkb8 Pmy7+J3X5LQELchaXX4UluHc29B+sCBqRMp/pIifrkoazBmcn9dSo2f3Xn+DmXCuDS/P p6Bx2waTJNCZ5wQWbDe5B2DCcJuXGIKtvPnWU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=XW7KvRqBWr3hFy8GfNhHyJ9vA/FQrqihEf8e/iVI+bU=; b=AtBXZFnqMyuIHPkFvaCPBbv+WniKtd/SVhnc4Cp6myj8R0MaTd7f3Lgm2ZjUM2H5YL qPkRpsmX5nXucKznHFh9g84zypznECB9xOPX43S1bixFaGY4HqIQ7V7JaIxAtRHp2Ut/ jgvByjfU0tzO2MDDufTpAEnusUYP6Vnz78YADq1YbZQFDBCQlNi4fJZDg7qSxs6dj1V9 muL6Awb+yximLiqbhRNQajLVFfuqqp4Tq35Bh5/HsSO8gDi2FXQUfK5dtdkqUZ9PG+Pp DQeSDGAT4MdgUmvUs181856drZR5L3YM/hM+erF+cy8PIPaEypWazIQ6x8Z2ljKVWHf8 1DFg== X-Gm-Message-State: AMke39nnm9O9VZkBQiFEOpKINj1jMI3TMRGT28FlxVV4XXPAFQbi8uBsBUwA5JiVJ6xqxL8o X-Received: by 10.25.4.9 with SMTP id 9mr1267455lfe.45.1486654486292; Thu, 09 Feb 2017 07:34:46 -0800 (PST) Received: from gnarp.ideon.se ([85.235.10.227]) by smtp.gmail.com with ESMTPSA id e86sm3670614lji.32.2017.02.09.07.34.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 07:34:45 -0800 (PST) From: Linus Walleij To: linux-mmc@vger.kernel.org, Ulf Hansson , Adrian Hunter , Paolo Valente Cc: Chunyan Zhang , Baolin Wang , linux-block@vger.kernel.org, Jens Axboe , Christoph Hellwig , Arnd Bergmann , Linus Walleij Subject: [PATCH 04/16] mmc: core: move the asynchronous post-processing Date: Thu, 9 Feb 2017 16:33:51 +0100 Message-Id: <20170209153403.9730-5-linus.walleij@linaro.org> X-Mailer: git-send-email 2.9.3 In-Reply-To: <20170209153403.9730-1-linus.walleij@linaro.org> References: <20170209153403.9730-1-linus.walleij@linaro.org> Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This moves the asynchronous post-processing of a request over to the finalization function. The patch has a slight semantic change: Both places will be in the code path for if (host->areq) and in the same sequence, but before this patch, the next request was started before performing post-processing. The effect is that whereas before, the post- and preprocessing happened after starting the next request, now the preprocessing will happen after the request is done and before the next has started which would cut half of the pre/post optimizations out. The idea is to later move the finalization to a worker started by mmc_request_done() and introduce a completion where the code now has a TODO comment so that we can push in a new request as soon as the host has completed the previous one. Signed-off-by: Linus Walleij --- drivers/mmc/core/core.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index 8dbed198750f..0972c649ea7a 100644 --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -643,6 +643,9 @@ static enum mmc_blk_status mmc_finalize_areq(struct mmc_host *host) mmc_start_bkops(host->card, true); } + /* Successfully postprocess the old request at this point */ + mmc_post_req(host, host->areq->mrq, 0); + return status; } @@ -687,10 +690,6 @@ struct mmc_async_req *mmc_start_areq(struct mmc_host *host, if (status == MMC_BLK_SUCCESS && areq) start_err = __mmc_start_data_req(host, areq->mrq); - /* Postprocess the old request at this point */ - if (host->areq) - mmc_post_req(host, host->areq->mrq, 0); - /* Cancel a prepared request if it was not started. */ if ((status != MMC_BLK_SUCCESS || start_err) && areq) mmc_post_req(host, areq->mrq, -EINVAL);