lkml.org 
[lkml]   [2011]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv4] DMAEngine: Define interleaved transfer request api
On Tue, Oct 18, 2011 at 10:26:56AM -0700, Bounine, Alexandre wrote:
> On Tue, Oct 18, 2011 at 5:50 AM, Russell King <rmk@arm.linux.org.uk> wrote:
> > 3. For architectures where there are only 32-bit DMA addresses,
> > dma_addr_t
> > will be a 32-bit type. For architectures where there are 64-bit DMA
> > addresses, it will be a 64-bit type.
> >
> > 4. If RIO can accept 64-bit DMA addresses but is only connected to 32-
> > bit
> > busses, then the top 32 address bits are not usable (it's truncated
> > in
> > hardware.) So there's no point passing around a 64-bit DMA address.
>
> Existing RapidIO controllers offer an address translation mechanism for
> inbound RIO requests which will translate RIO address into an address of
> mapped endpoint's local buffer. Some less-generic endpoints may also use
> upper address bits for their own implementation specific mapping and this
> is absolutely legal from the RIO POV. As an example of similar use may be
> a PCI bus where upper AD lines are used for device selection during PCI
> configuration cycles.
>
> So RIO addresses of any size are not blindly truncated and cannot be ignored.

See point 3 and point 6.

However, Jassi's suggestion that we redefine dma_addr_t to be 64-bit
for just the DMA engine code is utterly insane and unworkable. We
can't have typedefs which change depending on which bits of code are
being built, potentially changing the layout of structures being passed
around inside the kernel.

> > 6. 32-bit dma_addr_t with 64-bit DMA address space is a problem and is
> > probably a bug in itself - the platform should be using a 64-bit
> > dma_addr_t in this case. (see 3.)

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:


\
 
 \ /
  Last update: 2011-10-18 19:39    [W:0.110 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site