Re: [PATCH v2] block: BFQ default for single queue devices

ysfs) to choose a non-zone aware scheduler for these devices. It's another topic than $SUBJECT patch though. I take this into account in this version. Yours, Linus Walleij

Re: [PATCH v2] block: BFQ default for single queue devices

On Mon, Oct 15, 2018 at 4:32 PM Oleksandr Natalenko wrote: > On 15.10.2018 16:10, Linus Walleij wrote: > > + /* > > + * Zoned devices must use a deadline scheduler because currently > > + * that is the only scheduler re

[PATCH v2] block: BFQ default for single queue devices

e Cc: Ulf Hansson Cc: Richard Weinberger Cc: Adrian Hunter Cc: Bart Van Assche Cc: Jan Kara Cc: Artem Bityutskiy Cc: Christoph Hellwig Cc: Alan Cox Cc: Mark Brown Cc: Damien Le Moal Cc: Johannes Thumshirn Cc: Oleksandr Natalenko Cc: Jonathan Corbet Signed-off-by: Linus Walleij --- Change

Re: [PATCH] block: BFQ default for single queue devices

On Tue, Oct 2, 2018 at 4:31 PM Jens Axboe wrote: > On 10/2/18 6:43 AM, Linus Walleij wrote: > > This sets BFQ as the default scheduler for single queue > > block devices (nr_hw_queues == 1) if it is available. This > > affects notably MMC/SD-cards but notably also UBI and &g

[PATCH] block: BFQ default for single queue devices

ustments for treating queues differently whether they are in hardware or actually not. Cc: Pavel Machek Cc: Paolo Valente Cc: Jens Axboe Cc: Ulf Hansson Cc: Richard Weinberger Cc: Artem Bityutskiy Cc: Adrian Hunter Signed-off-by: Linus Walleij --- block/elevator.c | 21 ++

[PATCH] block: mq: Add some minor doc for core structs

As it came up in discussion on the mailing list that the semantic meaning of 'blk_mq_ctx' and 'blk_mq_hw_ctx' isn't completely obvious to everyone, let's add some minimal kerneldoc for a starter. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- block/blk-mq.h | 3 +++ i

Re: [PATCH V15 06/22] mmc: block: Add blk-mq support

ncommon and I haven't been able to locate any even for testing. It is very unlikely that you have one. However you would notice it from seeing a partition attachment message (like with an ordinary SD card) when you plug in your card. Yours, Linus Walleij

Re: [PATCH V15 00/22] mmc: Add Command Queue support

r > or later. I have run some tests yesterday and today using dd, find and iozone, vanilla and with fault injection of 1% errors and 10% errors, then stressing it additionally by ejecting the card in flight randomly a few times. Everything survived, it's rock solid from what I can tell! Tested-by:

Re: [PATCH 00/12 v5] Multiqueue for MMC/SD

On Wed, Nov 15, 2017 at 2:50 PM, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 14/11/17 23:17, Linus Walleij wrote: >> We have the following risk factors: >> >> - Observed performance degradation of 1% (on x86 SDHI I guess) >> - The kernel crashes if SD

Re: [PATCH V14 00/24] mmc: Add Command Queue support

y that this patch series: Acked-by: Linus Walleij <linus.wall...@linaro.org> I gave some more explicit review on some initial patches that I think should go in as fixes. I do not expect it to perform any less than the previous iteration on my systems where it was already performing well and

Re: [PATCH V14 06/24] mmc: block: Simplify cleaning up the queue

> > Signed-off-by: Adrian Hunter <adrian.hun...@intel.com> This is way more elegant. Reviewed-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij

Re: [PATCH V14 05/24] mmc: block: No need to export mmc_cleanup_queue()

On Tue, Nov 21, 2017 at 2:42 PM, Adrian Hunter <adrian.hun...@intel.com> wrote: > mmc_cleanup_queue() is not used by a different module. Do not export it. > > Signed-off-by: Adrian Hunter <adrian.hun...@intel.com> Reviewed-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij

Re: [PATCH V14 04/24] mmc: block: Ensure that debugfs files are removed

gt; A complication is that the debugfs_root may have already been removed, so > check for that too. > > Fixes: 627c3ccfb46a ("mmc: debugfs: Move block debugfs into block module") > Signed-off-by: Adrian Hunter <adrian.hun...@intel.com> Reviewed-by: Linus Walleij <linus

Re: [PATCH V14 03/24] mmc: core: Do not leave the block driver in a suspended state

On Tue, Nov 21, 2017 at 2:42 PM, Adrian Hunter <adrian.hun...@intel.com> wrote: > The block driver must be resumed if the mmc bus fails to suspend the card. > > Signed-off-by: Adrian Hunter <adrian.hun...@intel.com> Reviewed-by: Linus Walleij <linus.wall...@linaro.org&g

Re: [PATCH V14 02/24] mmc: block: Check return value of blk_get_request()

ock: move multi-ioctl() to use block layer") > Fixes: 614f0388f580 ("mmc: block: move single ioctl() commands to block > requests") > Fixes: 627c3ccfb46a ("mmc: debugfs: Move block debugfs into block module") > Signed-off-by: Adrian Hunter <adrian.hun...@i

Re: [PATCH 00/12 v5] Multiqueue for MMC/SD

;The system is going down for reboot NOW!" message) >> >> Full log (together with SysRq-l & SysRq-t outputs) attached. > > BTW: these problems are not present in Adrian's V13 patchset > (with mmc-mq enabled by default). Yes, as I even say in the cover letter I think

Re: [PATCH V13 03/10] mmc: block: Add blk-mq support

n extreme test case, so overall it is very robust code. With the exception of card removal during I/O, feel free to add my Tested-by: Linus Walleij <linus.wall...@linaro.org> on this series. >> But what I think is nice in doing it around >> each request is that since mmc_put_card(

Re: [PATCH 00/12 v5] Multiqueue for MMC/SD

On Fri, Nov 10, 2017 at 11:01 AM, Linus Walleij <linus.wall...@linaro.org> wrote: > Removing a card during I/O does not work well however :/ > So I guess I would need to work on that if this series should > continue. (Hopefully unlikely.) I tested a bit more and it turns out th

Re: [PATCH V13 03/10] mmc: block: Add blk-mq support

Following up on this: On Thu, Nov 9, 2017 at 4:52 PM, Linus Walleij <linus.wall...@linaro.org> wrote: >> No one has ever suggested that the legacy API will remain. Once blk-mq is >> ready the old code gets deleted. > > The block layer maintainers most definately think MQ

[PATCH 11/12 v5] mmc: block: issue requests in massive parallel

shing) and one being prepared for issuing next by the block layer. This shows up when we transit to multiqueue, where this can be exploited. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- ChangeLog v4->v5: - Fixes on the errorpath: when a request reports error back, keep the areq

[PATCH 09/12 v5] mmc: queue: stop flushing the pipeline with NULL

. This kills off some FIXME's such as gettin rid of the mq->qcnt queue depth variable that was introduced a while back. It is a vital step toward multiqueue enablement that we stop pulling NULL off the end of the request queue to flush the asynchronous issueing mechanism. Signed-off-by: Linus

[PATCH 12/12 v5] mmc: switch MMC/SD to use blk-mq multiqueueing v5

by Christoph. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- ChangeLog v4->v5: - Rebase on the other changes including improved error handling. - Use quiesce and unquiesce on the queue in the suspend/resume cycle. --- drivers/mmc/core/block.c | 92 ++ dr

[PATCH 03/12 v5] mmc: core: replace waitqueue with worker

wo, and we can potentially remove the NULL flushing of the asynchronous pipeline and report block requests as finished directly from the worker. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- ChangeLog v1->v5: - Rebasing on the "next" branch in the MMC tree. ---

[PATCH 00/12 v5] Multiqueue for MMC/SD

should continue. (Hopefully unlikely.) Linus Walleij (12): mmc: core: move the asynchronous post-processing mmc: core: add a workqueue for completing requests mmc: core: replace waitqueue with worker mmc: core: do away with is_done_rcv mmc: core: do away with is_new_req mmc: core: ki

[PATCH 06/12 v5] mmc: core: kill off the context info

The last member of the context info: is_waiting_last_req is just assigned values, never checked. Delete that and the whole context info as a result. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- ChangeLog v1->v5: - Rebasing on the "next" branch in the MMC tree. --

[PATCH 10/12 v5] mmc: queue/block: pass around struct mmc_queue_req*s

: this is what we are keeping in our queue, and what the block layer helps us manager. Augment a bunch of functions to take a single argument so we can see the trees and not just a big jungle of arguments. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- ChangeLog v1->v5: -

[PATCH 02/12 v5] mmc: core: add a workqueue for completing requests

use of it. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- ChangeLog v1->v5: - Rebasing on the "next" branch in the MMC tree. --- drivers/mmc/core/core.c | 9 + drivers/mmc/core/host.c | 1 - include/linux/mmc/host.h | 4 3 files changed, 13 insert

[PATCH 01/12 v5] mmc: core: move the asynchronous post-processing

he hardware. These two later patches together restore the same optimization but in a more elegant manner that avoids the need to flush the two-stage pipleline with NULL, something we remove between these two patches in the commit named "mmc: queue: stop flushing the pipeline with NULL&quo

[PATCH 07/12 v5] mmc: queue: simplify queue logic

The if() statment checking if there is no current or previous request is now just looking ahead at something that will be concluded a few lines below. Simplify the logic by moving the assignment of .asleep. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- ChangeLog v1->v5: -

[PATCH 05/12] mmc: core: do away with is_new_req

The host context member "is_new_req" is only assigned values, never checked. Delete it. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- ChangeLog v1->v5: - Rebasing on the "next" branch in the MMC tree. --- drivers/mmc/core/core.c | 1 - drivers/mmc/co

[PATCH 04/12] mmc: core: do away with is_done_rcv

letion, we are indeed done. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- ChangeLog v1->v5: - Rebasing on the "next" branch in the MMC tree. --- drivers/mmc/core/core.c | 40 include/linux/mmc/host.h | 2 -- 2 files changed, 1

[PATCH 08/12 v5] mmc: block: shuffle retry and error handling

ack to the core. Other users of the asynchrous request that do not need to retry and use misc error handling fallbacks will work fine since a NULL ->report_done_status() is just fine. This is currently only done by the test module. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> ---

Re: [PATCH V13 05/10] mmc: cqhci: support for command queue enabled host

On Thu, Nov 9, 2017 at 1:55 PM, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 09/11/17 14:26, Linus Walleij wrote: >>>> I think the above approach to put any CQE-specific callbacks >>>> directly into the struct mmc_host_ops is way more viable. >>>

Re: [PATCH V13 08/10] mmc: block: blk-mq: Separate card polling from recovery

On Thu, Nov 9, 2017 at 2:02 PM, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 09/11/17 14:52, Linus Walleij wrote: >> On Thu, Nov 9, 2017 at 8:56 AM, Adrian Hunter <adrian.hun...@intel.com> >> wrote: >>> On 08/11/17 11:30, Linus Walleij wrote: >>

Re: [PATCH V13 06/10] mmc: sdhci-pci: Add CQHCI support for Intel GLK

On Thu, Nov 9, 2017 at 8:12 AM, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 08/11/17 11:24, Linus Walleij wrote: >> On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter <adrian.hun...@intel.com> >> wrote: >> >>> Add CQHCI initialization an

Re: [PATCH V13 03/10] mmc: block: Add blk-mq support

On Thu, Nov 9, 2017 at 11:42 AM, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 08/11/17 10:54, Linus Walleij wrote: >> On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter <adrian.hun...@intel.com> >> wrote: >> At least you could do what

Re: [PATCH V13 08/10] mmc: block: blk-mq: Separate card polling from recovery

On Thu, Nov 9, 2017 at 8:56 AM, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 08/11/17 11:30, Linus Walleij wrote: >> On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter <adrian.hun...@intel.com> >> wrote: >> >>> Recovery is simpler to unders

Re: [PATCH V13 10/10] mmc: block: blk-mq: Stop using legacy recovery

On Thu, Nov 9, 2017 at 8:43 AM, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 08/11/17 11:38, Linus Walleij wrote: >> On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter <adrian.hun...@intel.com> >> wrote: >> >>> There are only a few things the recovery

Re: [PATCH V13 07/10] mmc: block: blk-mq: Add support for direct completion

On Thu, Nov 9, 2017 at 8:27 AM, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 08/11/17 11:28, Linus Walleij wrote: >> On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter <adrian.hun...@intel.com> >> wrote: >> >>> For blk-mq, add support for completing re

Re: [PATCH V13 04/10] mmc: block: Add CQE support

On Wed, Nov 8, 2017 at 2:20 PM, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 08/11/17 11:00, Linus Walleij wrote: >> This and other bits gives me the feeling CQE is now actually ONLY >> working on the MQ path. > > I was not allowed to support non-mq. Fair enough

Re: [PATCH V13 10/10] mmc: block: blk-mq: Stop using legacy recovery

. Even faster than before. How are they supposed to know which functions are used on which path? Run ftrace? This illustrates firmly why we need to refactor and/or kill off the old block layer interface *first* then add MQ on top. Yours, Linus Walleij

Re: [PATCH V13 07/10] mmc: block: blk-mq: Add support for direct completion

need to be strictly sequenced, and this is maybe not taken into account here? Isn't there as risk that the .post callback of the next request is called before the .post callback of the previous request has returned for example? Yours, Linus Walleij

Re: [PATCH V13 06/10] mmc: sdhci-pci: Add CQHCI support for Intel GLK

eirdness of .[runtime]_suspend/resume calling into CQE-specific APIs rather than using generic host callbacks. Yours, Linus Walleij

Re: [PATCH V13 05/10] mmc: cqhci: support for command queue enabled host

all too much bolted on the side. I think the above approach to put any CQE-specific callbacks directly into the struct mmc_host_ops is way more viable. If special CQE init is needed, why a special cqhci_init() call? And cqhci_pltfm_init()? It's confusing. Can't you just call this by default from the core if the host is CQE capable? Ass a .cqhci_init() callback into mmc_host_ops if need be. cqhci_irq() seems necessary though, I see something like this is probably necessary. Yours, Linus Walleij

Re: [PATCH V13 04/10] mmc: block: Add CQE support

ore they see the benefits of MQ+CQE combined, I think that should rather be the default experience. Yours, Linus Walleij

Re: [PATCH V13 03/10] mmc: block: Add blk-mq support

ume(struct mmc_queue *mq) > +{ > + blk_mq_unquiesce_queue(mq->queue); > +} > + > +static void __mmc_queue_suspend(struct mmc_queue *mq) > +{ > + struct request_queue *q = mq->queue; > + unsigned long flags; > + > + if (!mq->suspended) { > + mq->suspended |= true; > + > + spin_lock_irqsave(q->queue_lock, flags); > + blk_stop_queue(q); > + spin_unlock_irqrestore(q->queue_lock, flags); > + > + down(>thread_sem); > + } > +} > + > +static void __mmc_queue_resume(struct mmc_queue *mq) > +{ > + struct request_queue *q = mq->queue; > + unsigned long flags; > + > + if (mq->suspended) { > + mq->suspended = false; > + > + up(>thread_sem); > + > + spin_lock_irqsave(q->queue_lock, flags); > + blk_start_queue(q); > + spin_unlock_irqrestore(q->queue_lock, flags); > + } > +} One of the good reasons to delete the old block layer is to get rid of this horrible semaphore construction. So I see it as necessary to be able to focus development efforts on code that actually has a future. > + if (q->mq_ops) > + mmc_mq_queue_suspend(mq); > + else > + __mmc_queue_suspend(mq); And then there is the code duplication again. > int qcnt; > + > + int in_flight[MMC_ISSUE_MAX]; So this is a [2] containing a counter for the number of synchronous and asynchronous requests in flight at any time. But are there really synchronous and asynchronous requests going on at the same time? Maybe on the error path I guess. I avoided this completely but I guess it may be necessary with CQE, such that in_flight[0,1] is way more than 1 or 2 at times when there are commands queued? > + boolrw_wait; > + boolwaiting; > + wait_queue_head_t wait; As mentioned I think this is a reimplementation of the completion abstraction. Yours, Linus Walleij

Re: [PATCH V13 02/10] mmc: block: Add error-handling comments

On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter <adrian.hun...@intel.com> wrote: > Add error-handling comments to explain what would also be done for blk-mq > if it used the legacy error-handling. > > Signed-off-by: Adrian Hunter <adrian.hun...@intel.com> Reviewed-by: L

Re: [PATCH V13 01/10] mmc: core: Add parameter use_blk_mq

une_now:1; /* do re-tuning at next req */ > unsigned intretune_paused:1; /* re-tuning is temporarily > disabled */ > + unsigned intuse_blk_mq:1; /* use blk-mq */ unsigned int foo:1 is really a weird way of saying "bool". We should just fix it I guess, but it's another patch. Yours, Linus Walleij

Re: [PATCH 00/12 v4] multiqueue for MMC/SD

On Fri, Oct 27, 2017 at 2:59 PM, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 27/10/17 14:25, Linus Walleij wrote: >> It is indeed tough to juggle this with the pressure to "upstream >> first" the BFQ scheduler policy that we are working on in Linaro >&g

Re: [PATCH 00/12 v4] multiqueue for MMC/SD

ly if you have tech leads and managers hovering over your shoulder every week asking how the CQE upstream work is progressing. It is indeed tough to juggle this with the pressure to "upstream first" the BFQ scheduler policy that we are working on in Linaro to increase interactivity. We need to enable this on devices pronto and that means migrating MMC/SD to MQ and MQ only. I have shared this motivation since the start, so it should come as no surprise. So I also have some pressure to "Get This Feature In Now". Yours, Linus Walleij

Re: [PATCH V12 0/5] mmc: Add Command Queue support

On Thu, Oct 26, 2017 at 3:49 PM, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 26/10/17 16:32, Linus Walleij wrote: >> My patch series switches the stack around to make it possible >> to do this. But it doesn't go the whole way to complete the requests >> from int

Re: [PATCH 00/12 v4] multiqueue for MMC/SD

On Thu, Oct 26, 2017 at 3:34 PM, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 26/10/17 15:57, Linus Walleij wrote: >> I have now worked on it for more than a year. I was side >> tracked to clean up some code, move request allocation to >> be handled by the block

Re: [PATCH V12 0/5] mmc: Add Command Queue support

suming we don't need any retune etc and just say all is fine and optimistically complete the request directly in the interrupt handler if all was OK and wait for errors to happen before retuning. Yours, Linus Walleij

[PATCH 12/12 v4] mmc: switch MMC/SD to use blk-mq multiqueueing

() as advised by Christoph. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- drivers/mmc/core/block.c | 87 ++ drivers/mmc/core/queue.c | 223 ++- drivers/mmc/core/queue.h | 8 +- 3 files changed, 139 insertions(+

[PATCH 11/12 v4] mmc: block: issue requests in massive parallel

shing) and one being prepared for issuing next by the block layer. This shows up when we transit to multiqueue, where this can be exploited. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- drivers/mmc/core/block.c | 79 +--- dri

[PATCH 09/12 v4] mmc: queue: stop flushing the pipeline with NULL

. This kills off some FIXME's such as gettin rid of the mq->qcnt queue depth variable that was introduced a while back. It is a vital step toward multiqueue enablement that we stop pulling NULL off the end of the request queue to flush the asynchronous issueing mechanism. Signed-off-by: Linus

[PATCH 07/12 v4] mmc: queue: simplify queue logic

The if() statment checking if there is no current or previous request is now just looking ahead at something that will be concluded a few lines below. Simplify the logic by moving the assignment of .asleep. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- drivers/mmc/core/queue

[PATCH 10/12 v4] mmc: queue/block: pass around struct mmc_queue_req*s

: this is what we are keeping in our queue, and what the block layer helps us manager. Augment a bunch of functions to take a single argument so we can see the trees and not just a big jungle of arguments. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- drivers/mmc/core/block.c

[PATCH 06/12 v4] mmc: core: kill off the context info

The last member of the context info: is_waiting_last_req is just assigned values, never checked. Delete that and the whole context info as a result. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- drivers/mmc/core/block.c | 2 -- drivers/mmc/core/bus.c | 1 - drivers/mm

[PATCH 04/12 v4] mmc: core: do away with is_done_rcv

letion, we are indeed done. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- drivers/mmc/core/core.c | 40 include/linux/mmc/host.h | 2 -- 2 files changed, 16 insertions(+), 26 deletions(-) diff --git a/drivers/mmc/core/core.c b/drivers/mmc/c

[PATCH 03/12 v4] mmc: core: replace waitqueue with worker

wo, and we can potentially remove the NULL flushing of the asynchronous pipeline and report block requests as finished directly from the worker. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- drivers/mmc/core/block.c | 3 ++ drivers/mmc/c

[PATCH 02/12 v4] mmc: core: add a workqueue for completing requests

use of it. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- drivers/mmc/core/core.c | 9 + drivers/mmc/core/host.c | 1 - include/linux/mmc/host.h | 4 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c

[PATCH 05/12 v4] mmc: core: do away with is_new_req

The host context member "is_new_req" is only assigned values, never checked. Delete it. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- drivers/mmc/core/core.c | 1 - drivers/mmc/core/queue.c | 5 - include/linux/mmc/host.h | 2 -- 3 files changed, 8 deletion

[PATCH 01/12 v4] mmc: core: move the asynchronous post-processing

he hardware. These two later patches together restore the same optimization but in a more elegant manner that avoids the need to flush the two-stage pipleline with NULL, something we remove between these two patches in the commit named "mmc: queue: stop flushing the pipeline with NULL&quo

[PATCH 00/12 v4] multiqueue for MMC/SD

9 8191 204808192 7254 7434284132841928414 7476 20480 16384 7090 7481286232861928625 7454 As you can see, performance is not affected, errors are in the noise margin. Linus Walleij (12): mmc: core: move the asynchronous post-processing

Re: high overhead of functions blkg_*stats_* in bfq

x86. I paged in the x86 assembly people, they definately knows whether that is a good idea or if it sucks. (And if it was done in the past.) Yours, Linus Walleij

Re: [PATCH V8 00/14] mmc: Add Command Queue support

t from being > started. It seems my patch would not deliver in some drivers until we look into the locking semantics in the drivers. Yours, Linus Walleij

Re: [PATCH V9 13/15] mmc: block: Add CQE and blk-mq support

marshalling the requests and not doing away with the waitqueues and not completing the requests out-of-order, so we get stuck with a lump of MQ code that doesn't perform and therefore we cannot switch seamlessly to MQ. Yours, Linus Walleij

Re: [PATCH V9 09/15] mmc: core: Add parameter use_blk_mq

On Wed, Sep 27, 2017 at 2:02 PM, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 27/09/17 02:42, Linus Walleij wrote: >> On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter <adrian.hun...@intel.com> >> wrote: >> >>> Until mmc has blk-mq support fully i

Re: [PATCH 1/2 v6] mmc: block: Convert RPMB to a character device

the code and see if I'm missing something obvious. Yours, Linus Walleij

Re: [PATCH V9 12/15] mmc: core: Export mmc_retune_hold_now() and mmc_retune_release()

hold_now() into a static inline, so the commit message is a bit ambigous but who cares. Reviewed-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij

Re: [PATCH V9 10/15] mmc: core: Export mmc_start_bkops()

On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter <adrian.hun...@intel.com> wrote: > Export mmc_start_bkops() so that the block driver can use it. > > Signed-off-by: Adrian Hunter <adrian.hun...@intel.com> Reviewed-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij

Re: [PATCH V9 11/15] mmc: core: Export mmc_start_request()

On Fri, Sep 22, 2017 at 2:37 PM, Adrian Hunter <adrian.hun...@intel.com> wrote: > Export mmc_start_request() so that the block driver can use it. > > Signed-off-by: Adrian Hunter <adrian.hun...@intel.com> Reviewed-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij

Re: [PATCH V9 09/15] mmc: core: Add parameter use_blk_mq

hine you're developing on (no cross-compilation and remote target) which I guess is what some Intel people are doing with their laptops. Yours, Linus Walleij

Re: [PATCH V9 08/15] mmc: block: Factor out mmc_setup_queue()

On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter <adrian.hun...@intel.com> wrote: > Factor out some common code that will also be used with blk-mq. > > Signed-off-by: Adrian Hunter <adrian.hun...@intel.com> Reviewed-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij

Re: [PATCH V9 07/15] mmc: block: Prepare CQE data

flag, and data tag > flag. Also the request tag is needed to provide the command queue task id, > and a comment is added to explain the future possibility of defining a > priority. > > Signed-off-by: Adrian Hunter <adrian.hun...@intel.com> Reviewed-by: Linus Walleij <

Re: [PATCH V9 06/15] mmc: block: Use local variables in mmc_blk_data_prep()

On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter <adrian.hun...@intel.com> wrote: > Use local variables in mmc_blk_data_prep() in preparation for adding CQE > support which doesn't use the output variables. > > Signed-off-by: Adrian Hunter <adrian.hun...@intel.com> Re

Re: [PATCH V9 03/15] mmc: core: Add support for handling CQE requests

On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter <adrian.hun...@intel.com> wrote: > Add core support for handling CQE requests, including starting, completing > and recovering. > > Signed-off-by: Adrian Hunter <adrian.hun...@intel.com> Looks straight-forward to me. Re

Re: [PATCH V9 04/15] mmc: mmc: Enable Command Queuing

drian Hunter <adrian.hun...@intel.com> Reviewed-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij

Re: [PATCH V9 05/15] mmc: mmc: Enable CQE's

On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter <adrian.hun...@intel.com> wrote: > Enable or disable CQE when a card is added or removed respectively. > > Signed-off-by: Adrian Hunter <adrian.hun...@intel.com> Reviewed-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij

Re: [PATCH V9 01/15] mmc: core: Remove unnecessary host claim

On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter <adrian.hun...@intel.com> wrote: > Callers already have the host claimed, so remove the unnecessary > calls to mmc_claim_host() and mmc_release_host(). > > Signed-off-by: Adrian Hunter <adrian.hun...@intel.com> Good catch. Re

Re: [PATCH V8 08/14] mmc: core: Add parameter use_blk_mq

*could* simply invert the option then. Default it to "y" and only leave it as a debugging aid so that people can set it to "n" if they want to test with MQ disabled. This is also simple to revert by a oneliner just removing "default y" if there are problems with it. Yours, Linus Walleij

Re: [PATCH V8 01/14] mmc: core: Introduce host claiming by context

On Wed, Sep 13, 2017 at 1:40 PM, Adrian Hunter wrote: > Currently the host can be claimed by a task. Change this so that the host > can be claimed by a context that may or may not be a task. This provides > for the host to be claimed by a block driver queue to support

[PATCH 2/2 v6] mmc: block: Delete mmc_access_rpmb()

was badly engineered. This problem is now gone as we removed the offending RPMB block device in another patch and replaced it with a character device. Cc: Tomas Winkler <tomas.wink...@intel.com> Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- ChangeLov v5->v6: - Update the

[PATCH 1/2 v6] mmc: block: Convert RPMB to a character device

248, 1 Jan 1 2000 mmcblk3rpmb Notice the (248,0) and (248,1) character devices for RPMB. Cc: Tomas Winkler <tomas.wink...@intel.com> Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- ChangeLog v5->v6: - Prefix the bus name with mmc_ so it becomes "mmc_rpmb"

Re: [PATCH V5 11/13] mmc: block: Add CQE support

On Mon, Aug 21, 2017 at 11:27 AM, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 20/08/17 15:13, Linus Walleij wrote: >> On Thu, Aug 10, 2017 at 2:08 PM, Adrian Hunter <adrian.hun...@intel.com> >> wrote: >> >>> Add CQE support to the block driver,

Re: [PATCH V5 11/13] mmc: block: Add CQE support

is the case I need to be told. What we need is an MMC stack where it is clear where blocks come in and out and how they are processed by the block layer, but now we already have a scary Rube Goldberg-machine and it is not getting better. If people have different feelings they can tell me off right now. I have my hopes up that we can get the code lesser and more readable with MQ, as I tried to illustrate in my attempts, which are indeed lame because they don't work because of misc and SDIO use cases, but I'm honestly doing my best. Currently with other clean-ups to get a clean surface to do that. As it stands, the MQ migration work size is in some spots doubled or more than doubled after this commit :( Yours, Linus Walleij

Re: [PATCH V5 02/13] mmc: core: Add members to mmc_request and mmc_data for CQE's

tag" was some metadata associated with a request. Not that I am a block layer expert. Why can't we just name this "task_id" if that is what it is in Linux terms? Does the specification call it "tag"? Yours, Linus Walleij

Re: [PATCH 4/5] RFC: mmc: block: Convert RPMB to a character device

a function input. (...) >> + ret = mmc_blk_alloc_rpmb_part(card, md, >> + card->part[idx].size >> 9, >> + card->part[idx].name); > Extract partition access bits formcard->part[idx].part_cfg, OK I am trying my best with this too... Yours, Linus Walleij

Re: [PATCH 4/6 v2] mmc: block: move single ioctl() commands to block requests

On Wed, Jul 5, 2017 at 9:00 PM, Christoph Hellwig <h...@lst.de> wrote: > On Thu, May 18, 2017 at 11:36:14AM +0200, Christoph Hellwig wrote: >> On Thu, May 18, 2017 at 11:29:34AM +0200, Linus Walleij wrote: >> > We are storing the ioctl() in/out argument as a pointer in >

[PATCH 3/3 v4] mmc: debugfs: Move block debugfs into block module

and into block.c. Tested during heavy dd load by cat:in the status file. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- ChangeLog v3->v4: - Squash all the refactorings of these operations into a big commit simply moving all the debugfs over to the block layer and only creating the f

[PATCH 1/3 v4] mmc: block: Anonymize the drv op data pointer

We have a data pointer for the ioctl() data, but we need to pass other data along with the DRV_OP:s, so make this a void * so it can be reused. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- ChangeLog v3->v4: - No changes just resending ChangeLog v2->v3: - No changes ju

Re: [PATCH 2/5] mmc: block: Refactor mmc_blk_part_switch()

On Mon, Jun 19, 2017 at 9:53 PM, Tomas Winkler <tom...@gmail.com> wrote: > On Thu, Jun 15, 2017 at 3:12 PM, Linus Walleij <linus.wall...@linaro.org> > wrote: >> >> Instead of passing a struct mmc_blk_data * to mmc_blk_part_switch() >> let's pass the act

[PATCH 5/5] mmc: block: Delete mmc_access_rpmb()

device/disk with its own submit queue competing with the main partition, and submitting requests in parallel. This is now gone as we removed the offending RPMB block device in another patch. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- This patch is not an RFC since it is a l

[PATCH 4/5] RFC: mmc: block: Convert RPMB to a character device

248, 1 Jan 1 2000 mmcblk3rpmb Notice the (248,0) and (248,1) character devices for RPMB. Tomas Winkler <tomas.wink...@intel.com> Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- Some discussion points: I am aware of Tomas Winklers attempts to make RPMB handling int

[PATCH 2/5] mmc: block: Refactor mmc_blk_part_switch()

-by: Linus Walleij <linus.wall...@linaro.org> --- drivers/mmc/core/block.c | 25 + 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index d1b824e65590..94b97f97be1a 100644 --- a/drivers/mmc/core/block.c +++ b/d

[PATCH 3/5] mmc: block: Reparametrize mmc_blk_ioctl_[multi]_cmd()

for a specific block device but rather for a specific partition/area. Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- drivers/mmc/core/block.c | 43 ++- 1 file changed, 18 insertions(+), 25 deletions(-) diff --git a/drivers/mmc/core/block.c b/drive

[PATCH 1/5] mmc: block: Move duplicate check

ed-off-by: Linus Walleij <linus.wall...@linaro.org> --- ChangeLog v1->v2: - We need to check the block device only if an actual well-known ioctl() is coming in, on the path of the switch() statments, only those branches that handle actual ioctl()s. Create a new helper function to ch

[PATCH 0/5] Convert RPMB block device to a character device

onsequence of the character device conversion. For motivation and in-depth description of the problem I am trying to solve, see patch 4, the RFC. Linus Walleij (5): mmc: block: Move duplicate check mmc: block: Refactor mmc_blk_part_switch() mmc: block: Reparametrize mmc_blk_ioctl_[multi]_cmd() RFC:

Re: [RFC PATCH] mmc: core: Remove CONFIG_MMC_BLOCK_BOUNCE option.

nce, and that would be a per-host setting. It would be good to hear from people seeing benefits from bounce buffers about this. What hardware is there that acually sees a significant improvement with bounce buffers? Pierre, what host were you developing this for? Maybe I can try to get the same and test it. Yours, Linus Walleij

  1   2   >