RE: DSP/IOMMU needs 128-byte alignment from user-space buffers?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Doyu-san,

> 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?

-- We can do this in Bridge. I think the userland layers (LCML, OMX, GStreamer,...) should be then aware on how to handle this error. This will require some discussion with these components owners.

Thank you,
Best regards,
Hari

> -----Original Message-----
> From: Hiroshi DOYU [mailto:Hiroshi.DOYU@xxxxxxxxx]
> Sent: Saturday, December 20, 2008 12:27 AM
> To: Kanigeri, Hari
> Cc: felipe.contreras@xxxxxxxxx; linux-omap@xxxxxxxxxxxxxxx
> Subject: Re: DSP/IOMMU needs 128-byte alignment from user-space buffers?
> 
> 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" <h-kanigeri2@xxxxxx>
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux