Re: [RFC/PATCH 0/6] DSPBRIDGE: fix mem+cache API issues

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

 



On Mon, May 17, 2010 at 2:15 AM, Felipe Contreras
<felipe.contreras@xxxxxxxxx> wrote:
> Hi Ohad,
>
> On Mon, May 17, 2010 at 1:35 AM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote:
>> On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras
>> <felipe.contreras@xxxxxxxxx> wrote:
>>> I looked into the dma code (I guess it's in arch/arm/mm/dma-mapping.c)
>>> and I don't understand what dma_unmap_sg is supposed to do.
>>
>> Portable code must use the dma_unmap_* APIs.
>>
>> As you mentioned, one of the things it's crucial for
>> (but not used in our case) is bounce buffers:
>> e.g. when doing a DMA from a device using a buffer
>> that is out of the platform's DMA reach,
>> the DMA API uses bounce buffers: data DMA'ed to that
>> bounce buffer, and then the dma unmap copies it back
>> to the original buffer).
>
> Yes, but in dspbridge the most important use-case is video
> encoding/decoding, so we definitely don't want bouncing buffers.
> Besides, from what I can see very few platforms need them.
>
>> Another thing unmap is taking care of is speculative prefetch:
>> modern ARM processors can access the buffer during DMA
>> in order to speculatively prefetch data into the cache. Naturally
>> this can seriously break a DMA from a device, so unmap is
>> invalidating the caches to prevent this.
>>
>> The current dspbridge cache API is mostly relying on the
>> application to do the right thing: application programmer should
>> decide when to clean, flush or invalidate the caches in order
>> to have a successful DMA operation.
>>
>> This is prone to mistakes, it's not portable, and of course
>> not upstreamable.
>>
>> Using the standard DMA API we take the freedom from the
>> application programmer - we just ask him/her to tell us before
>> a DMA operation begins, and after it ends. The DMA API
>> is then responsible to do the right thing.
>
> It is a higher level of abstraction, but the application still needs
> to do the right thing, and errors can still happen. Anyway, I see now
> the changes 2.6.34.
> can
>> I read at your latest posts that after rebasing to newest dspbridge
>> code the issue doesn't reproduce anymore ? Please tell me if it's back.
>
> Yes... I haven't tried in the old commit you started from + the patch
> Omar suggested, but I guess there's no need for that any more. I can
> play with this code now :)

Out of curiosity, what board/environment do you use to play with
the code ? I'd like to run the same use cases you do, so I can
reproduce any issue you may bump into.

Thanks,
Ohad.

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

[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