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

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

 



On Fri, May 21, 2010 at 11:22 AM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote:
> On Fri, May 21, 2010 at 9:14 AM, Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
>> On Fri, May 21, 2010 at 12:22 AM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote:
>>> On Wed, May 19, 2010 at 7:50 PM, Felipe Contreras
>>> <felipe.contreras@xxxxxxxxx> wrote:
>>>> I don't know what VM_IO means, but essentially we don't want to go
>>>> find each and page when we know the memory is contiguous. Although the
>>>> fact that the memory is writecombine would help us avoid unnecessary
>>>> flushes as well :)
>>>
>>> Yes, I guess you can remove those calls from the application :)
>>
>> Can't. From GStreamer point of view the decoder is independent of the
>> renderer, so we have no way to know that.
>
> Can you please elaborate on this a little ?

GStreamer has a plug-in architecture. So one plug-in (libgstdsp.so)
issues a request for a zero-copy buffer (gst_pad_alloc_buffer()) to
the next element in the chain. We don't know who that is, nor care,
and there might be elements in the middle that pass the buffer along.

The memory could be part of the framebuffer, or randomly allocated by
user-space. One element (omapxvimagesink) might always return memory
from omapfb, another one (omapfbsink), might allocate a separate
buffer if all the omapfb memory is being used currently.

In the end, the decoder element has no idea about that. Just the
GstBuffer which has a data pointer, and a size, and that's it.

There are even more complicated use-cases like video recording
directly on the framebuffer. Other pluggable MM frameworks like
OpenMAX IL would have similar problems.

>> Perhaps if the memory map
>> operation returned some information we can avoid those calls.
>
> I don't think it should; relying on the map call to tell us what type
> of buffer we just gave it smells like a bad interface. After all, it
> is the application who originally called mmap() to get access to that
> buffer, so it already knows if it's a framebuffer of not.

Well, requesting DMA operations from user-space is already bad
interface. It's the job of the driver to do that.

Due to bad design of the driver we'll have to do them, but if there's
a way to know if such operations are redundant or not, it would have
to be returned through map call, otherwise we'll be wasting ioctl
calls.

> Anyway it's not that an important optimization to do: the ioctl will
> just fail. The negative side is that the application will have no way
> to know if this is really a failure (did I just give a wrong buffer
> address to dspbridge ?) or not (oh it's the framebuffer, there's no
> mapping for that).

Exactly; we will not know when operations fail. But also, ioctl()
calls would be wasted.

> Performance-wise, it's better than the previous implementation which
> would have executed redundant cache operation on the buffer.

Indeed.

Although I'm still worried that VM_IO != write-combine, but I guess
it's a safe assumption to do for now.

Cheers.

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