Hi Felipe, > So if I'm understanding correctly there's no problem with > unaligned DMM buffers if the DSP software is just reading; > the problem is when writing data back to ARM. --- That is my understanding too. For read only buffer there shouldn't be an issue with data corruption. I heard that some folks at TI are working on documenting this cache alignement issues to share with you. Please hold on. Thank you, Best regards, Hari > -----Original Message----- > From: Felipe Contreras [mailto:felipe.contreras@xxxxxxxxx] > Sent: Wednesday, December 17, 2008 3:21 PM > To: Kanigeri, Hari > Cc: linux-omap@xxxxxxxxxxxxxxx; Hiroshi DOYU > Subject: Re: DSP/IOMMU needs 128-byte alignment from > user-space buffers? > > On Wed, Dec 17, 2008 at 10:37 PM, Kanigeri, Hari > <h-kanigeri2@xxxxxx> wrote: > > Hi Felipe, > > > >> I received information from TI saying that user-space > buffers need to > >> be 128-byte aligned for the DSP to work properly. > >> > >> Is this true or is it some kind of limitation on their MMU > code that > >> might be solved by Hiroshi's iommu? > >> > >> This impacts quite drastically user-space applications > like GStreamer > >> since a memory copy would be required to achieve that 128-byte > >> alignment. > >> > >> They also claim that adding 128-byte padding at the > beginning and at > >> the end achieves the same purpose. > > > > This is to address the memory corruption that might arise > when using DMM (Dynamic memory mapping) feature. > > When the DSP processes data, the DSP cache controller loads > 128-Byte chunks (lines) from SDRAM and writes the data back > in 128-Byte chunks. If a DMM buffer does not start and end on > a 128-Byte boundary, the data preceding the start address > from the 128-Byte boundary to the Start Address and the data > at addresses trailing the end address from the End Address to > the next 128-Byte boundary will be loaded and written back as > well. If the DMM buffer was allocated on the heap of a > process running on the ARM, the preceding and trailing data, > if modified by the ARM (or other non-DSP entity) during DSP > processing, will be overwritten by the DSP cache controller, > when the 128-Byte chunks are written back to SDRAM. This can > lead to heap corruption. > > Thanks for the explanation. So it doesn't have anything to do > with IOMMU; it's the software running on the DSP that has > this limitation. > > > I think if you request the buffer from OMX component, this > issue will be taken as there is an additional 256 bytes padding. > > Yes, but in that case a memcpy would be unavoidable in many > cases, like trying to render the result of video decoding on > Xv. If the Xv buffer is unaligned; a dedicated DMM would need > to be allocated, and then the data coming from DSP would need > to be copied to the Xv buffer. That has a huge performance penalty. > > So if I'm understanding correctly there's no problem with > unaligned DMM buffers if the DSP software is just reading; > the problem is when writing data back to ARM. > > -- > Felipe Contreras > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
