devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
To: Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
Subject: Re: [PATCH V3] of: Set the DMA mask to 64 bits when dma_addr_t is 64-bits
Date: Sat, 6 Jul 2013 10:15:11 +0100	[thread overview]
Message-ID: <20130706091511.GN24642@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CACVXFVNT3j5o9a+N9FDA07Si+cngqAZkcqh6YYOf3rHsMvRgRg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Sat, Jul 06, 2013 at 10:21:05AM +0800, Ming Lei wrote:
> But please see below words in Documentation/DMA-API.txt:
> 
>            Further, the physical address of the memory must be within the
>            dma_mask of the device (the dma_mask represents a bit mask of the
>            addressable region for the device.  I.e., if the physical address of
>            the memory anded with the dma_mask is still equal to the physical
>            address, then the device can perform DMA to the memory).
> 
> You may argue that the description is about dev->dma_mask, but the
> usage should be same.
> 
> In fact, most of devices in ARM SoC(even with LPAE enabled) doesn't
> support 64bit DMA, so I don't see the point that the default mask is set
> as 64bit.

There's another couple of issues there:

(a) Linux assumes that physical memory starts at location zero.  There
    are various places in the kernel that assume that this holds true:

	max_dma_pfn = (dma_mask >> PAGE_SHIFT) + 1

    One notable place is the block layer.  I've suggested to Santosh a
    way to fix this but I need to help him a little more with it.

(b) Device DMA addresses are a *separate* address space to the physical
    address space.  Device DMA addresses are the addresses which need to
    be programmed into the device to perform DMA to the identified
    location.

What (b) means is that if you are ending up with a 64-bit address to be
programmed into a 32-bit only register, there is something very very
wrong.  What this also means is that a 32-bit DMA mask should suffice,
because if the DMA address results in a 32-bit address _for the DMA
device_ then we are within its capabilities.

In any case, the work around is not to set the DMA mask to be 64-bit.
Think about it.  What if you have 8GB of physical memory in a LPAE
system, but your DMA controllers can only be programmed with a 32-bit
address?

Lastly, think about what I said last night about most of the ARM drivers
being rather buggy in that they do not call either dma_set_mask() or
dma_set_coherent_mask().

So, I think we're well past the point where we need to stop assuming that
DMA masks somehow relate to physical addresses, and that they can be used
to indicate a range of physical addresses starting at zero and extending
up to and including the mask value.  To call such a thing a "mask" is
absolutely absurd.

  parent reply	other threads:[~2013-07-06  9:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-26 20:31 [PATCH V3] of: Set the DMA mask to 64 bits when dma_addr_t is 64-bits Laura Abbott
2013-04-26 20:52 ` Catalin Marinas
2013-04-26 21:32 ` Rob Herring
2013-07-03 14:15   ` Ming Lei
2013-07-05 19:33     ` Laura Abbott
2013-07-06  2:21       ` Ming Lei
     [not found]         ` <CACVXFVNT3j5o9a+N9FDA07Si+cngqAZkcqh6YYOf3rHsMvRgRg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-07-06  9:15           ` Russell King - ARM Linux [this message]
2013-07-08 10:03             ` Ming Lei
     [not found]               ` <CACVXFVNF0ZukAw5d1Uv_d0oE6arci7AyVtVEPRb0=hx+0dX6pA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-07-08 10:44                 ` Russell King - ARM Linux
     [not found]       ` <51D71F81.5090503-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2013-07-08 10:42         ` Russell King - ARM Linux
     [not found]           ` <20130708104254.GS24642-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2013-07-09  2:38             ` Laura Abbott
     [not found]     ` <CACVXFVPfkqP+UyoGd-+QFRzndSam_DtU=utrBPYCPjQCGQ_F6g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-07-05 22:19       ` Russell King - ARM Linux

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=20130706091511.GN24642@n2100.arm.linux.org.uk \
    --to=linux-lfz/pmaqli7xmaaqvzeohq@public.gmane.org \
    --cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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).