From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC 1/8] arm: make SWIOTLB available
Date: Thu, 1 Aug 2013 12:09:27 +0100 [thread overview]
Message-ID: <20130801110927.GF24642@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <1375292732-7627-1-git-send-email-stefano.stabellini@eu.citrix.com>
On Wed, Jul 31, 2013 at 06:45:25PM +0100, Stefano Stabellini wrote:
> +static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
> +{
> + unsigned int offset = paddr & ~PAGE_MASK;
> + return pfn_to_dma(dev, paddr >> PAGE_SHIFT) + offset;
> +}
> +
> +static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dev_addr)
> +{
> + unsigned int offset = dev_addr & ~PAGE_MASK;
> + return (dma_to_pfn(dev, dev_addr) << PAGE_SHIFT) + offset;
> +}
These two helpers look fine on the face of it.
> +static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
> +{
> + if (!dev->dma_mask)
> + return 0;
> +
> + return addr + size - 1 <= *dev->dma_mask;
> +}
You may wish to have a closer look at the DMA bounce code, because this
assumes that DMA masks are a set of zeros followed by a set of ones.
That may not always be the case (and we have the odd platform where that
isn't the case.)
It has always bugged me that we call this thing a dma _mask_ and then
much kernel code treats it as a limit - it should've been called "dma
limit" if that's how it was to be interpreted. If it really is a _mask_
then the right way to test whether a DMA address/size is possible is:
u64 limit, mask = *dev->dma_mask;
limit = (mask + 1) & ~mask;
if (limit && size > limit)
return 0;
if ((addr | (addr + size - 1)) & ~mask)
return 0;
return 1;
The first checks whether 'size' fits within the least significant
contiguous set of '1' bits in the DMA mask, and the second checks
whether the region itself contains any address bits which may not
meet the DMA mask.
I guess if we aren't going to encounter any of these cases anymore,
your test is entirely sufficient.
next prev parent reply other threads:[~2013-08-01 11:09 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-31 17:44 [PATCH RFC 0/8] enable swiotlb-xen on arm and arm64 Stefano Stabellini
2013-07-31 17:45 ` [PATCH RFC 1/8] arm: make SWIOTLB available Stefano Stabellini
2013-08-01 0:32 ` Konrad Rzeszutek Wilk
2013-08-02 11:59 ` Stefano Stabellini
2013-08-02 12:13 ` Konrad Rzeszutek Wilk
2013-08-02 12:18 ` Stefano Stabellini
2013-08-01 11:09 ` Russell King - ARM Linux [this message]
2013-08-02 12:09 ` Stefano Stabellini
2013-07-31 17:45 ` [PATCH RFC 2/8] arm: introduce a global dma_ops pointer Stefano Stabellini
2013-07-31 17:45 ` [PATCH RFC 3/8] arm64: do not initialize arm64_swiotlb if dma_ops is already set Stefano Stabellini
2013-07-31 17:45 ` [PATCH RFC 4/8] xen/arm,arm64: move Xen initialization earlier Stefano Stabellini
2013-08-01 0:35 ` Konrad Rzeszutek Wilk
2013-07-31 17:45 ` [PATCH RFC 5/8] xen: introduce XENMEM_get_dma_buf and xen_put_dma_buf Stefano Stabellini
2013-08-01 0:36 ` Konrad Rzeszutek Wilk
2013-08-01 15:13 ` Stefano Stabellini
2013-07-31 17:45 ` [PATCH RFC 6/8] xen: make xen_create_contiguous_region return the dma address Stefano Stabellini
2013-08-01 11:34 ` David Vrabel
2013-07-31 17:45 ` [PATCH RFC 7/8] swiotlb-xen: support autotranslate guests Stefano Stabellini
2013-07-31 19:03 ` Stefano Stabellini
2013-08-02 12:37 ` Konrad Rzeszutek Wilk
2013-08-02 16:12 ` Stefano Stabellini
2013-07-31 17:45 ` [PATCH RFC 8/8] xen/arm,arm64: enable SWIOTLB_XEN Stefano Stabellini
2013-08-02 12:40 ` Konrad Rzeszutek Wilk
2013-08-02 16:25 ` Stefano Stabellini
2013-07-31 19:44 ` [PATCH RFC 0/8] enable swiotlb-xen on arm and arm64 Stefano Stabellini
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=20130801110927.GF24642@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.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 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).