Messages in this thread | | | Date | Tue, 18 Oct 2011 14:00:45 +0530 | Subject | Re: [PATCHv4] DMAEngine: Define interleaved transfer request api | From | Jassi Brar <> |
| |
On 18 October 2011 13:12, Russell King <rmk@arm.linux.org.uk> wrote: > On Tue, Oct 18, 2011 at 11:15:29AM +0530, Jassi Brar wrote: >> On 18 October 2011 02:37, Bounine, Alexandre <Alexandre.Bounine@idt.com> wrote: >> > With item #1 above being a separate topic, I may have a problem with #2 >> > as well: dma_addr_t is sized for the local platform and not guaranteed >> > to be a 64-bit value (which may be required by a target). >> > Agree with #3 (if #1 and #2 work). >> > >> Perhaps simply change dma_addr_t to u64 in dmaengine.h alone ? > > That's just an idiotic suggestion - there's no other way to put that. > Let's have some sanity here. > Yeah, I am not proud of the workaround, so I only probed the option. I think I need to explain myself.
The case here is that even a 32-bit RapidIO host could ask transfer against 64-bit address space on a remote device. And vice versa 64->32.
> dma_addr_t is the size of a DMA address for the CPU architecture being > built. This has no relationship to what any particular DMA engine uses. > Yes, so far the dmaengine ever only needed to transfer within platform's address-space. So the assumption that src and dst addresses could be contained within dma_addr_t, worked. If the damengine is to get rid of that assumption/constraint, the memcpy, slave_sg etc need to accept addresses specified in bigger of the host and remote address space, and u64 is the safe option. Ultimately dma_addr_t is either u32 or u64.
If you still think that's unacceptable, please do show us the optimal path forward. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |