On Fri, Oct 07, 2016 at 10:42:17AM -0400, Rob Clark wrote:
> probably should keep the discussion on github (USAGE.md was updated a
> bit more and merged into https://github.com/cubanismo/allocator so
> look there for the latest)..
>
> but briefly:
>
> 1) my expectation is if the user is implement
Rob,
how do you know which devices are concerned when listing the constraints ?
Does combine_capabilities is done from each allocation or can it be cached ?
Regards,
Benjmain
2016-10-06 18:54 GMT+02:00 Rob Clark :
> so there is discussion about a "central userspace allocator" (ie. more
> like a
probably should keep the discussion on github (USAGE.md was updated a
bit more and merged into https://github.com/cubanismo/allocator so
look there for the latest)..
but briefly:
1) my expectation is if the user is implementing some use-case, it
knows what devices and APIs are involved, otherwise
When using dmabuf the devices have to attach themselves on the buffer
before map it
so you can know which devices will use the buffer before allocate it
when the first
dma_buf_map_attachment() is called (defered allocation)
Split dmabuf attach/map_attachment is not really done in drm or v4l2
but pa
so there is discussion about a "central userspace allocator" (ie. more
like a common userspace API that could be implemented on top of
various devices/APIs) to decide in a generic way which device could
allocate.
https://github.com/cubanismo/allocator
and I wrote up some rough thoughts/proposal
On Wed, Oct 05, 2016 at 03:40:14PM +0200, Benjamin Gaignard wrote:
> because with ion it is up to userland to decide which heap to use
> and until now userland doesn't have any way to get device constraints...
>
> I will prefer let a central allocator (in kernel) decide from the
> attached devices
because with ion it is up to userland to decide which heap to use
and until now userland doesn't have any way to get device constraints...
I will prefer let a central allocator (in kernel) decide from the
attached devices
which allocator is the best. It is what I have implemented in smaf.
Benjami
On Tue, Oct 04, 2016 at 01:47:21PM +0200, Benjamin Gaignard wrote:
> version 10 changes:
> - rebased on kernel 4.8 tag
> - minor typo fix
>
> version 9 changes:
> - rebased on 4.8-rc5
> - struct dma_attrs doesn't exist anymore so update CMA allocator
>to compile with new dma_*_attr functio
version 10 changes:
- rebased on kernel 4.8 tag
- minor typo fix
version 9 changes:
- rebased on 4.8-rc5
- struct dma_attrs doesn't exist anymore so update CMA allocator
to compile with new dma_*_attr functions
- add example SMAF use case in cover letter
version 8 changes:
- rework of th
