Hi Hari,
Would it be possible for the bridge to check this alignment and if
it's not, it returns some error to userland and upper layers in a
chain?
Hiroshi DOYU
From: "ext Kanigeri, Hari" <[email protected]>
Subject: RE: DSP/IOMMU needs 128-byte alignment from user-space buffers?
Date: Wed, 17 Dec 2008 14:37:01 -0600
> 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.
> I think if you request the buffer from OMX component, this issue will be
> taken as there is an additional 256 bytes padding.
>
> Thank you,
> Best regards,
> Hari
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
