From: Christoph Hellwig <hch@lst.de>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Christoph Hellwig <hch@lst.de>,
Russell King <linux@armlinux.org.uk>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,"
<iommu@lists.linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] mmc: let the dma map ops handle bouncing
Date: Thu, 11 Apr 2019 16:34:30 +0200 [thread overview]
Message-ID: <20190411143430.GA17371@lst.de> (raw)
In-Reply-To: <CAPDyKFqHrvz_5taNTx7k6Skx=Ox+9XgQHHz0LZyr4QNV9orvRw@mail.gmail.com>
On Thu, Apr 11, 2019 at 11:00:56AM +0200, Ulf Hansson wrote:
> > blk_queue_flag_clear(QUEUE_FLAG_ADD_RANDOM, mq->queue);
> > if (mmc_can_erase(card))
> > mmc_queue_setup_discard(mq->queue, card);
> >
> > - blk_queue_bounce_limit(mq->queue, limit);
> > + if (!mmc_dev(host)->dma_mask || !*mmc_dev(host)->dma_mask)
> > + blk_queue_bounce_limit(mq->queue, BLK_BOUNCE_HIGH);
>
> So this means we are not going to set a bounce limit for the queue, in
> case we have a dma mask.
>
> Why isn't that needed no more? Whats has changed?
On most architectures it was never needed, the major hold out was x86-32
with PAE. In general the dma_mask tells the DMA API layer what is
supported, and if the physical addressing doesn't support that it has to
use bounce buffering like swiotlb (or dmabounce on arm32). A couple
month ago I finally fixes x86-32 to also properly set up swiotlb,
and remove the block layerer bounce buffering that wasn't for highmem
(which is about having a kernel mapping, not addressing), and ISA DMA
(which is not handled like everything else, but we'll get there).
But for some reason I missed mmc back then, so mmc right now is the
only remaining user of address based block layer bouncing.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Russell King <linux@armlinux.org.uk>,
"list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,
" <iommu@lists.linux-foundation.org>,
Christoph Hellwig <hch@lst.de>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/2] mmc: let the dma map ops handle bouncing
Date: Thu, 11 Apr 2019 16:34:30 +0200 [thread overview]
Message-ID: <20190411143430.GA17371@lst.de> (raw)
Message-ID: <20190411143430.EUEY9oMzeIHIofrmi9BwyuMckDpCU3Y8rVBkC-8_0kI@z> (raw)
In-Reply-To: <CAPDyKFqHrvz_5taNTx7k6Skx=Ox+9XgQHHz0LZyr4QNV9orvRw@mail.gmail.com>
On Thu, Apr 11, 2019 at 11:00:56AM +0200, Ulf Hansson wrote:
> > blk_queue_flag_clear(QUEUE_FLAG_ADD_RANDOM, mq->queue);
> > if (mmc_can_erase(card))
> > mmc_queue_setup_discard(mq->queue, card);
> >
> > - blk_queue_bounce_limit(mq->queue, limit);
> > + if (!mmc_dev(host)->dma_mask || !*mmc_dev(host)->dma_mask)
> > + blk_queue_bounce_limit(mq->queue, BLK_BOUNCE_HIGH);
>
> So this means we are not going to set a bounce limit for the queue, in
> case we have a dma mask.
>
> Why isn't that needed no more? Whats has changed?
On most architectures it was never needed, the major hold out was x86-32
with PAE. In general the dma_mask tells the DMA API layer what is
supported, and if the physical addressing doesn't support that it has to
use bounce buffering like swiotlb (or dmabounce on arm32). A couple
month ago I finally fixes x86-32 to also properly set up swiotlb,
and remove the block layerer bounce buffering that wasn't for highmem
(which is about having a kernel mapping, not addressing), and ISA DMA
(which is not handled like everything else, but we'll get there).
But for some reason I missed mmc back then, so mmc right now is the
only remaining user of address based block layer bouncing.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Russell King <linux@armlinux.org.uk>,
"list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,
" <iommu@lists.linux-foundation.org>,
Christoph Hellwig <hch@lst.de>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/2] mmc: let the dma map ops handle bouncing
Date: Thu, 11 Apr 2019 16:34:30 +0200 [thread overview]
Message-ID: <20190411143430.GA17371@lst.de> (raw)
In-Reply-To: <CAPDyKFqHrvz_5taNTx7k6Skx=Ox+9XgQHHz0LZyr4QNV9orvRw@mail.gmail.com>
On Thu, Apr 11, 2019 at 11:00:56AM +0200, Ulf Hansson wrote:
> > blk_queue_flag_clear(QUEUE_FLAG_ADD_RANDOM, mq->queue);
> > if (mmc_can_erase(card))
> > mmc_queue_setup_discard(mq->queue, card);
> >
> > - blk_queue_bounce_limit(mq->queue, limit);
> > + if (!mmc_dev(host)->dma_mask || !*mmc_dev(host)->dma_mask)
> > + blk_queue_bounce_limit(mq->queue, BLK_BOUNCE_HIGH);
>
> So this means we are not going to set a bounce limit for the queue, in
> case we have a dma mask.
>
> Why isn't that needed no more? Whats has changed?
On most architectures it was never needed, the major hold out was x86-32
with PAE. In general the dma_mask tells the DMA API layer what is
supported, and if the physical addressing doesn't support that it has to
use bounce buffering like swiotlb (or dmabounce on arm32). A couple
month ago I finally fixes x86-32 to also properly set up swiotlb,
and remove the block layerer bounce buffering that wasn't for highmem
(which is about having a kernel mapping, not addressing), and ISA DMA
(which is not handled like everything else, but we'll get there).
But for some reason I missed mmc back then, so mmc right now is the
only remaining user of address based block layer bouncing.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-04-11 14:34 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-11 7:09 get rid of dma_max_pfn Christoph Hellwig
2019-04-11 7:09 ` Christoph Hellwig
2019-04-11 7:09 ` Christoph Hellwig
2019-04-11 7:09 ` Christoph Hellwig
2019-04-11 7:09 ` [PATCH 1/2] mmc: let the dma map ops handle bouncing Christoph Hellwig
2019-04-11 7:09 ` Christoph Hellwig
2019-04-11 7:09 ` Christoph Hellwig
2019-04-11 9:00 ` Ulf Hansson
2019-04-11 9:00 ` Ulf Hansson
2019-04-11 9:00 ` Ulf Hansson
2019-04-11 14:34 ` Christoph Hellwig [this message]
2019-04-11 14:34 ` Christoph Hellwig
2019-04-11 14:34 ` Christoph Hellwig
2019-04-11 7:09 ` [PATCH 2/2] dma-mapping: remove dma_max_pfn Christoph Hellwig
2019-04-11 7:09 ` Christoph Hellwig
2019-04-11 7:09 ` Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2019-06-25 9:20 get rid of dma_max_pfn Christoph Hellwig
2019-06-25 9:20 ` [PATCH 1/2] mmc: let the dma map ops handle bouncing Christoph Hellwig
2019-06-25 9:20 ` Christoph Hellwig
2019-06-25 9:20 ` Christoph Hellwig
2019-07-08 11:55 ` Ulf Hansson
2019-07-08 11:55 ` Ulf Hansson
2019-07-08 11:55 ` Ulf Hansson
2019-07-08 11:55 ` Ulf Hansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190411143430.GA17371@lst.de \
--to=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.