From: Liviu Dudau <Liviu.Dudau@arm.com>
To: James Bottomley <jbottomley@parallels.com>
Cc: "bhelgaas@google.com" <bhelgaas@google.com>,
"rdunlap@infradead.org" <rdunlap@infradead.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] DMA-API: Change dma_declare_coherent_memory() CPU address to phys_addr_t
Date: Fri, 2 May 2014 12:02:20 +0100 [thread overview]
Message-ID: <20140502110220.GK4750@e106497-lin.cambridge.arm.com> (raw)
In-Reply-To: <1398953290.2313.15.camel@dabdike.int.hansenpartnership.com>
On Thu, May 01, 2014 at 03:08:12PM +0100, James Bottomley wrote:
> On Wed, 2014-04-30 at 14:33 -0600, Bjorn Helgaas wrote:
> > dma_declare_coherent_memory() takes two addresses for a region of memory: a
> > "bus_addr" and a "device_addr". I think the intent is that "bus_addr" is
> > the physical address a *CPU* would use to access the region, and
> > "device_addr" is the bus address the *device* would use to address the
> > region.
> >
> > Rename "bus_addr" to "phys_addr" and change its type to phys_addr_t.
>
> Remind me what the difference between phys_addr_t and dma_addr_t are.
>
> I thought phys_addr_t was the maximum address the CPU could reach after
> address translation and dma_addr_t was the maximum physical address any
> bus attached memory mapped devices could appear at. (of course, mostly
> they're the same).
My understanding is that dma_addr_t has nothing to do (directly) with the
bus the device is on. In the way I understand things, dma_addr_t is the
range of addresses that a DMA engine (possibly inside a device) can access.
So it is possible to have a device sitting on a PCI bus that uses addresses
for dma_addr_t that are 32bit but those addresses are then translated by
the bus translation setup into phys_addr_t and that can be any size
(preferrably >= dma_addr_t).
One way of seeing dma_addr_t is a translated IO physical address. And yes,
that means that there are two ways of expressing a phys_addr_t, except
that dma_addr_t is further restricted to the space that the DMA engine can
access and how the address output of the DMA engine gets mapped on the
physical busses.
Best regards,
Liviu
>
> The intent of dma_declare_coherent_memory() is to take a range of memory
> provided by some device on the bus and allow the CPU to allocate regions
> from it for use as things like descriptors. The CPU treats it as real
> memory, but, in fact, it is a mapped region of an attached device.
>
> If my definition is correct, then bus_addr should be dma_addr_t because
> it has to be mapped from a device and dma_addr_t is the correct type for
> device addresses. If I've got the definition wrong, then we should
> document it somewhere, because it's probably confusing other people as
> well.
>
> James
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
prev parent reply other threads:[~2014-05-02 11:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-30 20:33 Bjorn Helgaas
2014-05-01 0:07 ` Greg Kroah-Hartman
2014-05-01 7:48 ` Bjorn Helgaas
2014-05-01 14:08 ` James Bottomley
2014-05-01 19:05 ` Bjorn Helgaas
2014-05-02 6:11 ` James Bottomley
2014-05-02 8:42 ` Arnd Bergmann
2014-05-05 23:01 ` Bjorn Helgaas
2014-05-06 2:42 ` James Bottomley
2014-05-06 9:29 ` Arnd Bergmann
2014-05-06 13:18 ` Bjorn Helgaas
2014-05-06 13:42 ` James Bottomley
2014-05-06 14:09 ` Arnd Bergmann
2014-05-02 18:34 ` Bjorn Helgaas
2014-05-02 11:18 ` Liviu Dudau
2014-05-05 22:42 ` Bjorn Helgaas
2014-05-06 8:59 ` Liviu Dudau
2014-05-06 20:22 ` Bjorn Helgaas
2014-05-02 11:02 ` Liviu Dudau [this message]
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=20140502110220.GK4750@e106497-lin.cambridge.arm.com \
--to=liviu.dudau@arm.com \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=jbottomley@parallels.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rdunlap@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
all inboxes | Powered by JetHome®