Re: [PATCH v10 0/3] Secure Memory Allocation Framework

2016-10-10 Thread John Einar Reitan
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

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

2016-10-07 Thread Rob Clark
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,

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

2016-10-07 Thread Benjamin Gaignard
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

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

2016-10-06 Thread Rob Clark
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

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

2016-10-06 Thread Benjamin Gaignard
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

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

2016-10-05 Thread Daniel Vetter
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

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

2016-10-05 Thread Benjamin Gaignard
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.

Re: [PATCH v10 0/3] Secure Memory Allocation Framework

2016-10-05 Thread Daniel Vetter
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

[PATCH v10 0/3] Secure Memory Allocation Framework

2016-10-04 Thread Benjamin Gaignard
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