Re: [Linaro-mm-sig] [RFC 1/4] dma-buf: Add constraints sharing information

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

 



On 10/11/2014 11:55 AM, Daniel Vetter wrote:
On Sat, Oct 11, 2014 at 01:37:55AM +0530, Sumit Semwal wrote:
At present, struct device lacks a mechanism of exposing memory
access constraints for the device.

Consequently, there is also no mechanism to share these constraints
while sharing buffers using dma-buf.

If we add support for sharing such constraints, we could use that
to try to collect requirements of different buffer-sharing devices
to allocate buffers from a pool that satisfies requirements of all
such devices.

This is an attempt to add this support; at the moment, only a bitmask
is added, but if post discussion, we realise we need more information,
we could always extend the definition of constraint.

A new dma-buf op is also added, to allow exporters to interpret or decide
on constraint-masks on their own. A default implementation is provided to
just AND (&) all the constraint-masks.

What constitutes a constraint-mask could be left for interpretation on a
per-platform basis, while defining some common masks.

Signed-off-by: Sumit Semwal <sumit.semwal@xxxxxxxxxx>
Cc: linux-kernel@xxxxxxxxxxxxxxx
Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
Cc: linux-media@xxxxxxxxxxxxxxx
Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx
Cc: linaro-mm-sig@xxxxxxxxxxxxxxxx

Just a few high-level comments, I'm between conference travel but
hopefully I can discuss this a bit at plumbers next week.

- I agree that for the insane specific cases we need something opaque like
   the access constraints mask you propose here. But for the normal case I
   think the existing dma constraints in dma_params would go a long way,
   and I think we should look at Rob's RFC from aeons ago to solve those:

   https://lkml.org/lkml/2012/7/19/285

   With this we should be able to cover the allocation constraints of 90%
   of all cases hopefully.

- I'm not sure whether an opaque bitmask is good enough really, I suspect
   that we also need various priorities between different allocators. With
   the option that some allocators are flat-out incompatible.


From my experience with Ion, the bitmask is okay if you have only a few
types but as soon as there are multiple regions it gets complicated and
when you start adding in priority via id it really gets unwieldy.

Thanks,
Laura


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux