From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C93DCC43603 for ; Tue, 10 Dec 2019 15:18:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9E98F2053B for ; Tue, 10 Dec 2019 15:18:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="cSSUpZLt" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727448AbfLJPSG (ORCPT ); Tue, 10 Dec 2019 10:18:06 -0500 Received: from mail-vs1-f66.google.com ([209.85.217.66]:39495 "EHLO mail-vs1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727380AbfLJPSG (ORCPT ); Tue, 10 Dec 2019 10:18:06 -0500 Received: by mail-vs1-f66.google.com with SMTP id p21so13305776vsq.6 for ; Tue, 10 Dec 2019 07:18:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jcUnC0/SEm4HDTIw1YLkWhbNF7DV2HNNDkdfVlTygbE=; b=cSSUpZLtf+hCVZvTD7HbKKL/zq4Rkmgcb2lIlIkDlhoxjyGVl0vVSnKlyJSar8oMju kJKrdwjxQ132req2y4+nrrVfisVcDFp//Vza1JYfv88Pn0pawYqigZnVIjKe8hsBLtwo MCeVhuUG+FD6AVkT5efECIF5yoeCURQPE8pK5mLLWFQv5VUdlsUYexM/XG4pBnG0lMlj homajns2YyoPkCVbVSABDLsSQp/B9WvdKRwStVCpME0KK4gfjaFWk6c6Sp+tT9WhGfwd Wm0n+fvhFn2WYXhdCvCyA4aduw0ySOsjxw4ZHQ5FAt3egnPm7ELrA47hNqGA3SWWB7Yy x0ug== 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=jcUnC0/SEm4HDTIw1YLkWhbNF7DV2HNNDkdfVlTygbE=; b=nPHkVjoLRq+w3Ic0FvReOuo6+KU8T7GtcDI1bWsUR5IPzBrXk+Q7XkpU/wNt4/XJ8L VJhmily98iHrBuwPCIahWs+jlxNNzG2Fc8cqHOmbgTk5aB5LCdP1kqqcAtt8/CJmel7p /RrvKmfswyiajibuPfWMLAJy9QXZsnmmgHEI28J4/Fa3BHBjCwIqv/qLyKdLth5uYa2w zYKW8SHlezm4iQr/iiyslACus2JcH4xC5hzhCpm4q4m8X0yTU4ZRNRxEa8XpzOrnqU+a DniZ0Tm2TARRYF9OxES2FYuYyJUdrvBFNwetZ3dNGbMH162xjPvwUKTuL7H4llr2qlQu 497Q== X-Gm-Message-State: APjAAAViB4jfANuPgfwJsYUuUUj4BADhLRFm1gwvTXrWunenQQFY4ITb SmZ8U0+H/1kOMHdcjyXpI3keNGsQf04fLM4VlIgLmw== X-Google-Smtp-Source: APXvYqxHTWP37WCrbgkX6nxMLdBw/0tPKoRg5nRin2f5LJXHzhcKcpphZKWgMGaQKXGnCPL9VoXyCSqg/WxqTmWfZqM= X-Received: by 2002:a05:6102:5d1:: with SMTP id v17mr25314853vsf.200.1575991085086; Tue, 10 Dec 2019 07:18:05 -0800 (PST) MIME-Version: 1.0 References: <20191127090023.GA23040@infradead.org> In-Reply-To: From: Ulf Hansson Date: Tue, 10 Dec 2019 16:17:28 +0100 Message-ID: Subject: Re: [PATCH v6 0/4] Add MMC software queue support To: Arnd Bergmann Cc: Christoph Hellwig , Hannes Reinecke , "(Exiting) Baolin Wang" , Baolin Wang , Adrian Hunter , Asutosh Das , Orson Zhai , Lyra Zhang , Linus Walleij , Vincent Guittot , linux-mmc , "linux-kernel@vger.kernel.org" , Hannes Reinecke , linux-block , Paolo Valente Content-Type: text/plain; charset="UTF-8" Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org On Wed, 27 Nov 2019 at 13:01, Arnd Bergmann wrote: > > On Wed, Nov 27, 2019 at 10:00 AM Christoph Hellwig wrote: > > > > On Tue, Nov 26, 2019 at 12:17:15PM +0100, Hannes Reinecke wrote: > > If requests are batched enough we could just drain > > and switch every time an other partition access comes in. Especially > > so if people only use partitions for boot partitions and other rarely > > used areas. > > We only support a single user partition plus up to two boot partitions that > are accessed rarely, I don't think there is any reason to optimize switching > between them. I agree. However, let me just add some more information to this. There are more partitions, like the RPMB for example. In regards to partition switching, after serving a request to the RPMB partition, we always switch back to the main user area. I think that is sufficient. Also note that requests for the RPMB partitions are managed via REQ_OP_DRV_IN|OUT. > > The only change that I think we need here is to change the partition switch > from something that is done synchronously during ->queue_rq() to > something that fits better into normal scheme of sending a cmd to > the device, returning BLK_STS_RESOURCE from ->queue_rq. You want to translate them to be managed similar to REQ_OP_DRV_IN|OUT, no? I am just trying to understand what this would help us with, but I don't get it, sorry. I realize that I am joining the show a bit late, apologize for that. But it seems like you are forgetting about re-tuning, urgent bkops, card detect, SDIO combo cards, etc. For example, re-tuning may be required because of a CRC error on the previously sent transfer. Thus re-tuning must be done before serving the next request. Likewise, when the device signals urgent bkops status, we must not serve any new request until the card has notified us that it is ready with it's internal housekeeping operations. > Possibly this could even be turned into a standard struct request that is > added between two normal requests for different partitions at some > point, if this simplifies the logic (I suspect it won't, but it may be worth > a try). Doing so, means re-tuning, bkops, etc, also needs to be managed in the same way. Is this really the way to go? Kind regards Uffe