From: Christoph Hellwig <hch@lst.de>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>,
m.szyprowski@samsung.com, hch@lst.de,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org
Subject: Re: [RFC][PATCH] dma-mapping: align default segment_boundary_mask with dma_mask
Date: Mon, 16 Mar 2020 13:46:52 +0100 [thread overview]
Message-ID: <20200316124652.GA17386@lst.de> (raw)
In-Reply-To: <f36ac67e-0eca-46df-78ec-c8b1c4fbe951@arm.com>
On Mon, Mar 16, 2020 at 12:12:08PM +0000, Robin Murphy wrote:
> On 2020-03-14 12:00 am, Nicolin Chen wrote:
>> More and more drivers set dma_masks above DMA_BIT_MAKS(32) while
>> only a handful of drivers call dma_set_seg_boundary(). This means
>> that most drivers have a 4GB segmention boundary because DMA API
>> returns DMA_BIT_MAKS(32) as a default value, though they might be
>> able to handle things above 32-bit.
>
> Don't assume the boundary mask and the DMA mask are related. There do exist
> devices which can DMA to a 64-bit address space in general, but due to
> descriptor formats/hardware design/whatever still require any single
> transfer not to cross some smaller boundary. XHCI is 64-bit yet requires
> most things not to cross a 64KB boundary. EHCI's 64-bit mode is an example
> of the 4GB boundary (not the best example, admittedly, but it undeniably
> exists).
Yes, which is what the boundary is for. But why would we default to
something restrictive by default even if the driver didn't ask for it?
next prev parent reply other threads:[~2020-03-16 12:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-14 0:00 [RFC][PATCH] dma-mapping: align default segment_boundary_mask with dma_mask Nicolin Chen
2020-03-16 10:45 ` Christoph Hellwig
2020-03-16 12:12 ` Robin Murphy
2020-03-16 12:46 ` Christoph Hellwig [this message]
2020-03-16 13:16 ` Robin Murphy
2020-03-16 21:42 ` Nicolin Chen
2020-03-16 21:39 ` Nicolin Chen
2020-03-16 12:48 ` Christoph Hellwig
2020-03-16 21:45 ` Nicolin Chen
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=20200316124652.GA17386@lst.de \
--to=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=nicoleotsuka@gmail.com \
--cc=robin.murphy@arm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).