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.
If DSP software is just reading, you may have to do cache
invalidate. This is to
enable subsequent read operations get latest data (if ARM has written
into the buffer).
So, even in this case, 128 byte alignment is required.
Regards,
Kishore.
-----Original Message-----
From: linux-omap-owner@xxxxxxxxxxxxxxx
[mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Felipe Contreras
Sent: Thursday, December 18, 2008 2:51 AM
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
SASKEN BUSINESS DISCLAIMER
-------------------------
This message may contain confidential, proprietary or legally privileged information. In
case you are not the original intended Recipient of the message, you must not, directly or
indirectly, use, Disclose, distribute, print, or copy any part of this message and you are
requested to delete it and inform the sender. Any views expressed in this message are
those of the individual sender unless otherwise stated. Nothing contained in this message
shall be construed as an offer or acceptance of any offer by Sasken Communication
Technologies Limited ("Sasken") unless sent with that express intent and with due
authority of Sasken. Sasken has taken enough precautions to prevent the spread of
viruses. However the company accepts no liability for any damage caused by any virus
transmitted by this email
--
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
