Hi Laura,
On 13 October 2014 13:42, Laura Abbott lau...@codeaurora.org wrote:
On 10/10/2014 1:07 PM, Sumit Semwal wrote:
Hi,
Why:
While sharing buffers using dma-buf, currently there's no mechanism to
let
devices share their memory access constraints with each other to allow for
delayed allocation of backing storage.
This RFC attempts to introduce the idea of memory constraints of a device,
and how these constraints can be shared and used to help allocate buffers
that
can satisfy requirements of all devices attached to a particular dma-buf.
How:
A constraints_mask is added to dma_parms of the device, and at the time
of
each device attachment to a dma-buf, the dma-buf uses this
constraints_mask
to calculate the access_mask for the dma-buf.
Allocators can be defined for each of these constraints_masks, and then
helper
functions can be used to allocate the backing storage from the matching
allocator satisfying the constraints of all devices interested.
A new miscdevice, /dev/cenalloc [1] is created, which acts as the dma-buf
exporter to make this transparent to the devices.
More details in the patch description of cenalloc: Constraint-Enabled
Allocation helpers for dma-buf.
At present, the constraint_mask is only a bitmask, but it should be
possible to
change it to a struct and adapt the constraint_mask calculation
accordingly,
based on discussion.
Important requirement:
==
Of course, delayed allocation can only work if all participating devices
will wait for other devices to have 'attached' before mapping the buffer
for the first time.
As of now, users of dma-buf(drm prime, v4l2 etc) call the attach() and
then
map_attachment() almost immediately after it. This would need to be
changed if
they were to benefit from constraints.
What 'cenalloc' is not:
===
- not 'general' allocator helpers - useful only for constraints-enabled
devices that share buffers with others using dma-buf.
- not a replacement for existing allocation mechanisms inside various
subsystems; merely a possible alternative.
- no page-migration - it would be very complementary to the delayed
allocation
suggested here.
TODOs:
==
- demonstration test cases
- vma helpers for allocators
- more sample allocators
- userspace ioctl (It should be a simple one, and we have one ready, but
wanted
to agree on the kernel side of things first)
I'm interested to see the userspace ioctl. The mask based approach of
Ion does not scale well to a userspace ABI so I'm curious if cenalloc
does better.
Apologies for the delay in response.
Since with cenalloc, the decision of 'which pool to allocate from' is
not with the userspace, but is calculated based on the devices that
attach, the userspace ABI should be just a simple xxx_create, which
returns an fd that'd be the dma-buf fd. That will allow easy sharing
with other dma-buf importers via standard dma-buf API.
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
Thanks and regards,
Sumit Semwal
Kernel Team Lead - Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
