Re: EDMA with user provided virtual addresses.
Hi David, Not really. The usual way to handle that sort of thing is to make whatever user-to-kernel mapping call you need, which returns something along the lines of a scatterlist. Then just construct a chain of DMA transfers, one for each segment. Thanks for your suggestion. I still don't find anything to do user-to- kernel mapping, but I haven't had much time to search for them. ( I see you said kmap calls would apply for single highmem pages, but user space aren't really 'highmem', right?) Map that to the kernel, and it'll still be three pages but the page addresses will differ ... say, pages X, Y, and Z. Offsets and lengths will be unchanged. Now just feed EDMA a chain of three transfers. Understood... my only doubt is if EDMA in MV kernel supports transfer chaining: I recall that the driver use fixed PaRam for each channel, am I wrong? I can't use CMEM (and sincerely I'd want to use it only if strictly necessary), cause the destination address is given by a 'third party' library that wants do the allocation by itself. Thanks. bye -- Andrea Gasparini ImaVis S.r.l. web: www.imavis.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: EDMA with user provided virtual addresses.
TI's Codec Engine Linux Utils module CMEM can do what you want, but I don't know if it's even a possibility for you. EDMA requires physically contiguous buffers, so in addition to needing to know the physical address, you also must ensure that your buffers are contiguous physically, and CMEM provides both these services. Regards, - Rob -Original Message- From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincids p.com [mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.d avincidsp.com] On Behalf Of Andrea Gasparini Sent: Thursday, June 11, 2009 3:55 AM To: davinci-linux-open-source Subject: EDMA with user provided virtual addresses. Hi, I'm coding a module that takes from userspace an address pointer, and uses it to fill the memory with some EDMA process. My problem is that EDMA (fairly) wants a physical address: I usually use dma_map_single() to have returned a physical pointer to do this kind of stuff, but in this case, although, pointer are from user spaces, and so involves mmu. So, the question is: is there a way to use EDMA with (at least one) user space address? Can I know (and how) a physical address given the userspace one? If could make the answer easier: I'm not (ATM) using swap space at all, so pages are surely resident in memory. Thanks, bye! -- Andrea Gasparini ImaVis S.r.l. web: www.imavis.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: EDMA with user provided virtual addresses.
On Thursday 11 June 2009, Tivy, Robert wrote: EDMA requires physically contiguous buffers, so in addition to needing to know the physical address, you also must ensure that your buffers are contiguous physically, Not really. The usual way to handle that sort of thing is to make whatever user-to-kernel mapping call you need, which returns something along the lines of a scatterlist. Then just construct a chain of DMA transfers, one for each segment. So a 12 Kbyte userspace buffer might scan three pages: page N+0 offset 1K, len 3K page N+1 offset 0, len 4K page N+2 offset 0, len 1K Map that to the kernel, and it'll still be three pages but the page addresses will differ ... say, pages X, Y, and Z. Offsets and lengths will be unchanged. Now just feed EDMA a chain of three transfers. That kind of logic is easy to wrap in utility functions. (If it were wrapped, would non-DSP code really need CMEM?) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: EDMA with user provided virtual addresses.
-Original Message- From: David Brownell [mailto:davi...@pacbell.net] Sent: Thursday, June 11, 2009 1:09 PM To: Tivy, Robert Cc: davinci-linux-open-source@linux.davincidsp.com; Andrea Gasparini Subject: Re: EDMA with user provided virtual addresses. On Thursday 11 June 2009, Tivy, Robert wrote: EDMA requires physically contiguous buffers, so in addition to needing to know the physical address, you also must ensure that your buffers are contiguous physically, Not really. The usual way to handle that sort of thing is to make whatever user-to-kernel mapping call you need, which returns something along the lines of a scatterlist. Then just construct a chain of DMA transfers, one for each segment. So a 12 Kbyte userspace buffer might scan three pages: page N+0 offset 1K, len 3K page N+1 offset 0, len 4K page N+2 offset 0, len 1K Map that to the kernel, and it'll still be three pages but the page addresses will differ ... say, pages X, Y, and Z. Offsets and lengths will be unchanged. Now just feed EDMA a chain of three transfers. That kind of logic is easy to wrap in utility functions. (If it were wrapped, would non-DSP code really need CMEM?) Good point, thanks for letting me know. So, the requirement for phys contig buffers is mostly for HW accelerators that address memory w/o the benefit of an MMU or without chaining capability. Having one contig buf for EDMA also makes things simpler to handle, but isn't necessary. CMEM can help in the non-DSP case for those HW accelerators. One last advantage of CMEM - ARM/DSP-based combo code can move over to ARM only without any porting, or using a different allocator. - Rob___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: EDMA with user provided virtual addresses.
On Thursday 11 June 2009, Tivy, Robert wrote: That kind of logic is easy to wrap in utility functions. (If it were wrapped, would non-DSP code really need CMEM?) ... the requirement for phys contig buffers is mostly for HW accelerators that address memory w/o the benefit of an MMU or without chaining capability. (You mean ... *and* without chaining yes? If either tech is available, there is no hard requirement.) For completeness: which accelerators are those? I expect it might be quite painful to update DSP code to change assumptions like physically contiguous buffers, but on the flip side of things it seems like such changes should probably be assumed for all mainstream Linux code that's got to take buffers from userspace. Having one contig buf for EDMA also makes things simpler to handle, but isn't necessary. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: EDMA with user provided virtual addresses.
-Original Message- From: David Brownell [mailto:davi...@pacbell.net] Sent: Thursday, June 11, 2009 3:18 PM To: Tivy, Robert Cc: davinci-linux-open-source@linux.davincidsp.com; Andrea Gasparini Subject: Re: EDMA with user provided virtual addresses. On Thursday 11 June 2009, Tivy, Robert wrote: That kind of logic is easy to wrap in utility functions. (If it were wrapped, would non-DSP code really need CMEM?) ... the requirement for phys contig buffers is mostly for HW accelerators that address memory w/o the benefit of an MMU or without chaining capability. (You mean ... *and* without chaining yes? If either tech is available, there is no hard requirement.) Yes, if the bus master has *neither* an MMU nor block-chaining, phys contig bufs are needed. For completeness: which accelerators are those? I'm not sure of the specifics of each one, but I was thinking of coprocessors such as IMX/VICP/HDVICP/MJCP/etc. I expect it might be quite painful to update DSP code to change assumptions like physically contiguous buffers, but on the flip side of things it seems like such changes should probably be assumed for all mainstream Linux code that's got to take buffers from userspace. Some codecs probably don't have a choice but to require phsyically contiguous buffers, if for no other reason than to guarantee stated performance, and to maximize throughput to allow as many instances as possible on a single system. But I'm not familiar with codecs, just heard through the grapevine. - Rob ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
