On 1/18/19 1:53 PM, Laura Abbott wrote:
> On 1/16/19 9:12 AM, Andrew F. Davis wrote:
>> On 1/16/19 9:28 AM, Brian Starkey wrote:
>>> Hi Andrew,
>>>
>>> On Fri, Jan 11, 2019 at 12:05:20PM -0600, Andrew F. Davis wrote:
>>>> The heap name can be used f
On 1/18/19 2:19 PM, Laura Abbott wrote:
> On 1/16/19 8:05 AM, Andrew F. Davis wrote:
>> On 1/15/19 12:58 PM, Laura Abbott wrote:
>>> On 1/15/19 9:47 AM, Andrew F. Davis wrote:
>>>> On 1/14/19 8:39 PM, Laura Abbott wrote:
>>>>> On 1/11/19 10:0
On 1/18/19 3:43 PM, Liam Mark wrote:
> On Fri, 18 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/17/19 7:04 PM, Liam Mark wrote:
>>> On Thu, 17 Jan 2019, Andrew F. Davis wrote:
>>>
>>>> On 1/16/19 4:48 PM, Liam Mark wrote:
>>>>> On Wed, 16 Jan
On 1/21/19 1:44 PM, Liam Mark wrote:
> On Mon, 21 Jan 2019, Christoph Hellwig wrote:
>
>> On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote:
And who is going to decide which ones to pass? And who documents
which ones are safe?
I'd much rather have explicit, well doc
On 1/21/19 2:20 PM, Liam Mark wrote:
> On Mon, 21 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/21/19 1:44 PM, Liam Mark wrote:
>>> On Mon, 21 Jan 2019, Christoph Hellwig wrote:
>>>
>>>> On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote:
>&
On 1/21/19 5:22 AM, Brian Starkey wrote:
> Hi,
>
> Sorry for being a bit sporadic on this. I was out travelling last week
> with little time for email.
>
> On Fri, Jan 18, 2019 at 11:16:31AM -0600, Andrew F. Davis wrote:
>> On 1/17/19 7:11 PM, Liam Mark wrote:
>>&
On 1/21/19 4:18 PM, Liam Mark wrote:
> On Mon, 21 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/21/19 2:20 PM, Liam Mark wrote:
>>> On Mon, 21 Jan 2019, Andrew F. Davis wrote:
>>>
>>>> On 1/21/19 1:44 PM, Liam Mark wrote:
>>>>> On Mon, 21 Ja
On 1/21/19 4:12 PM, Liam Mark wrote:
> On Mon, 21 Jan 2019, Christoph Hellwig wrote:
>
>> On Mon, Jan 21, 2019 at 11:44:10AM -0800, Liam Mark wrote:
>>> The main use case is for allowing clients to pass in
>>> DMA_ATTR_SKIP_CPU_SYNC in order to skip the default cache maintenance
>>> which happen
ittle different in each email, so I'd like to respond
to bits of both, I'll fix up the formatting.
> Also, adding Daniel Vetter to the mix, since he has been one of the
> core guys who shaped up dma-buf as it is today.
>
> On Tue, 22 Jan 2019 at 02:51, Andrew F. Davis w
On 1/22/19 9:23 PM, Sumit Semwal wrote:
> Hello everyone,
>
> (Thanks to Dan for letting me know my last email got corrupted :/ -
> resending it here)
>
Hmm, this one seems a bit messed up also (Thunderbird doesn't seem to
like it at least).
[snip]
> - from dma-buf PoV, ION is an exporter of d
ned-off-by: Andrew F. Davis
---
This also means we don't need to store the available heaps in a plist,
we only operation we care about is lookup, so a better data structure
should be chosen at some point, regular list or xarray maybe?
This is base on -next as to be on top of the other ta
On 1/23/19 11:11 AM, Brian Starkey wrote:
> Hi Andrew,
>
> On Wed, Jan 23, 2019 at 10:51:24AM -0600, Andrew F. Davis wrote:
>> On 1/22/19 11:33 AM, Sumit Semwal wrote:
>>> Hello everyone,
>>>
>>> Sincere apologies for chiming in a bit late here,
On 1/24/19 9:24 AM, Brian Starkey wrote:
> Hi Andrew,
>
> On Wed, Jan 23, 2019 at 01:28:35PM -0600, Andrew F. Davis wrote:
>> Previously the heap to allocate from was selected by a mask of allowed
>> heap types. This may have been done as a primitive form of constraint
>&
;)
Signed-off-by: Andrew F. Davis
---
This also means we don't need to store the available heaps in a plist,
we only operation we care about is lookup, so a better data structure
should be chosen at some point, regular list or xarray maybe?
This is base on -next as to be on top of the
On 1/29/19 5:44 PM, Liam Mark wrote:
> On Fri, 18 Jan 2019, Liam Mark wrote:
>
>> On Fri, 18 Jan 2019, Andrew F. Davis wrote:
>>
>>> On 1/18/19 12:37 PM, Liam Mark wrote:
>>>> The ION begin_cpu_access and end_cpu_access functions use the
>>>> dma
Add white-space for easier reading and remove some where it does
not belong. No functional changes, they just bug me..
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion_carveout_heap.c | 1 +
drivers/staging/android/ion/ion_chunk_heap.c| 2 +-
drivers/staging/android/ion
needed afterall..
Thanks,
Andrew
Andrew F. Davis (14):
staging: android: ion: Add proper header information
staging: android: ion: Remove empty ion_ioctl_dir() function
staging: android: ion: Merge ion-ioctl.c into ion.c
staging: android: ion: Remove leftover comment
staging: an
F. Davis
---
drivers/staging/android/ion/ion.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index bba5f682bc25..14e48f6eb734 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android
elements from this struct, just convert
these to get supplied these values from the heap registrar directly.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion.h | 23 ---
.../staging/android/ion/ion_carveout_heap.c | 12 --
drivers/staging
Various cleanups have removed the use of some headers in ION, remove
these here.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion.c | 3 ---
drivers/staging/android/ion/ion_carveout_heap.c | 4 ++--
drivers/staging/android/ion/ion_chunk_heap.c| 3 +--
3 files
When enabled the helpers functions for creating carveout and chunk heaps
should have declarations in the ION header.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion.h | 33 +++
1 file changed, 33 insertions(+)
diff --git a/drivers/staging/android
The base address is not used anywhere and tracked by the pool
allocator. No need to store this anymore.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion_chunk_heap.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/android/ion
The file ion-ioctl.c is now much to small and tightly integrated
with the main ion.c file to justify keeping it separate. Merge
this file.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/Makefile| 2 +-
drivers/staging/android/ion/ion-ioctl.c | 86
Since we use CMA APIs directly there is no device nor private heaps data,
drop this comment.
Fixes: 204f672255c2 ("staging: android: ion: Use CMA APIs directly")
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion_cma_heap.c | 4
1 file changed, 4 deletions(-)
di
The base address is not used anywhere and tracked by the pool
allocator. No need to store this anymore.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion_carveout_heap.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/android/ion
This function is empty of real function and can be replaced with
_IOC_DIR().
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion-ioctl.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/android/ion/ion-ioctl.c
b/drivers
The filenames in headers add nothing are often wrong after moves, lets
drop them here and add a little description of the files contents.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion.c | 2 +-
drivers/staging/android/ion/ion.h | 2 +-
drivers
Buffers may not be mapped from the CPU so skip cache maintenance here.
Accesses from the CPU to a cached heap should be bracketed with
{begin,end}_cpu_access calls so maintenance should not be needed anyway.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion.c | 7 ---
1
This struct is no longer documented correctly, fix this.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index 2ef78c951a6b
the secure/unmapped heap from Linaro for
the OP-TEE SDP implementation, this was re-written to match
the carveout heap helper code.
Suggested-by: Etienne Carriere
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/Kconfig | 10 ++
drivers/staging/android/ion/Makefile
On 1/14/19 8:32 PM, Laura Abbott wrote:
> On 1/11/19 10:05 AM, Andrew F. Davis wrote:
>> The "unmapped" heap is very similar to the carveout heap except
>> the backing memory is presumed to be unmappable by the host, in
>> my specific case due to firewalls. This m
On 1/14/19 8:39 PM, Laura Abbott wrote:
> On 1/11/19 10:05 AM, Andrew F. Davis wrote:
>> Hello all,
>>
>> This is a set of (hopefully) non-controversial cleanups for the ION
>> framework and current set of heaps. These were found as I start to
>> familiarize mys
On 1/15/19 11:45 AM, Liam Mark wrote:
> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/14/19 11:13 AM, Liam Mark wrote:
>>> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
>>>
>>>> Buffers may not be mapped from the CPU so skip cache maintenance he
On 1/15/19 12:38 PM, Andrew F. Davis wrote:
> On 1/15/19 11:45 AM, Liam Mark wrote:
>> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>>
>>> On 1/14/19 11:13 AM, Liam Mark wrote:
>>>> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
>>>>
>>&g
On 1/14/19 11:13 AM, Liam Mark wrote:
> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
>
>> Buffers may not be mapped from the CPU so skip cache maintenance here.
>> Accesses from the CPU to a cached heap should be bracketed with
>> {begin,end}_cpu_access calls so maintena
On 1/15/19 12:58 PM, Laura Abbott wrote:
> On 1/15/19 9:47 AM, Andrew F. Davis wrote:
>> On 1/14/19 8:39 PM, Laura Abbott wrote:
>>> On 1/11/19 10:05 AM, Andrew F. Davis wrote:
>>>> Hello all,
>>>>
>>>> This is a set of (hopefully) non-controv
On 1/15/19 1:05 PM, Laura Abbott wrote:
> On 1/15/19 10:38 AM, Andrew F. Davis wrote:
>> On 1/15/19 11:45 AM, Liam Mark wrote:
>>> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>>>
>>>> On 1/14/19 11:13 AM, Liam Mark wrote:
>>>>> On Fri, 11 Jan
On 1/15/19 1:11 PM, Laura Abbott wrote:
> On 1/15/19 10:43 AM, Laura Abbott wrote:
>> On 1/15/19 7:58 AM, Andrew F. Davis wrote:
>>> On 1/14/19 8:32 PM, Laura Abbott wrote:
>>>> On 1/11/19 10:05 AM, Andrew F. Davis wrote:
>>>>> The "unmapped
On 1/16/19 9:19 AM, Brian Starkey wrote:
> Hi :-)
>
> On Tue, Jan 15, 2019 at 12:40:16PM -0600, Andrew F. Davis wrote:
>> On 1/15/19 12:38 PM, Andrew F. Davis wrote:
>>> On 1/15/19 11:45 AM, Liam Mark wrote:
>>>> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
On 1/16/19 9:28 AM, Brian Starkey wrote:
> Hi Andrew,
>
> On Fri, Jan 11, 2019 at 12:05:20PM -0600, Andrew F. Davis wrote:
>> The heap name can be used for debugging but otherwise does not seem
>> to be required and no other part of the code will fail if left NULL
>>
On 1/16/19 4:48 PM, Liam Mark wrote:
> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/15/19 1:05 PM, Laura Abbott wrote:
>>> On 1/15/19 10:38 AM, Andrew F. Davis wrote:
>>>> On 1/15/19 11:45 AM, Liam Mark wrote:
>>>>> On Tue, 15 Jan 2019, A
On 1/16/19 4:54 PM, Liam Mark wrote:
> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/16/19 9:19 AM, Brian Starkey wrote:
>>> Hi :-)
>>>
>>> On Tue, Jan 15, 2019 at 12:40:16PM -0600, Andrew F. Davis wrote:
>>>> On 1/15/19 12:38 PM, And
On 1/18/19 3:59 AM, Greg Kroah-Hartman wrote:
> On Fri, Jan 11, 2019 at 12:05:21PM -0600, Andrew F. Davis wrote:
>> When enabled the helpers functions for creating carveout and chunk heaps
>> should have declarations in the ION header.
>
> Why? No one calls these from what I
On 1/17/19 7:04 PM, Liam Mark wrote:
> On Thu, 17 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/16/19 4:48 PM, Liam Mark wrote:
>>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
>>>
>>>> On 1/15/19 1:05 PM, Laura Abbott wrote:
>>>>> On 1/15/19
On 1/17/19 7:11 PM, Liam Mark wrote:
> On Thu, 17 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/16/19 4:54 PM, Liam Mark wrote:
>>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
>>>
>>>> On 1/16/19 9:19 AM, Brian Starkey wrote:
>>>>> Hi :-)
>
a_sync_sg_for_cpu
>
The window for this seems really small, but it does seem technically
possible, good find. for what it's worth:
Acked-by: Andrew F. Davis
> Fix this by getting the ion_buffer lock before freeing the sg table memory.
>
> Fixes: 2a55e7b5e544 ("staging: andr
On 1/18/19 12:37 PM, Liam Mark wrote:
> The ION begin_cpu_access and end_cpu_access functions use the
> dma_sync_sg_for_cpu and dma_sync_sg_for_device APIs to perform cache
> maintenance.
>
> Currently it is possible to apply cache maintenance, via the
> begin_cpu_access and end_cpu_access APIs, t
On 1/18/19 2:31 PM, Laura Abbott wrote:
> On 1/17/19 8:13 AM, Andrew F. Davis wrote:
>> On 1/16/19 4:48 PM, Liam Mark wrote:
>>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
>>>
>>>> On 1/15/19 1:05 PM, Laura Abbott wrote:
>>>>> On 1/15/19 10:38
its own permissions/sepolicy rules.
>>
>> Feedback would be greatly appreciated!
>> thanks
>> -john
>>
>> Cc: Laura Abbott
>> Cc: Sumit Semwal
>> Cc: Liam Mark
>> Cc: Brian Starkey
>> Cc: Andrew F. Davis
>> Cc: Alistair Strachan
>
ems to make the most sense here. Even heap type
doesn't look like a good thing to expose, it is just as static and
one-off as heap name, I don't see it having all that much use :/
Andrew
>> Cc: Laura Abbott
>> Cc: Sumit Semwal
>> Cc: Liam Mark
>> Cc: Brian Sta
rough RFC over the weekend if that is okay with you (not trying to walk
over your work here or anything, just want to show what I'm thinking if
any of the above doesn't make sense) :)
Thanks,
Andrew
> thanks
> -john
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit S
This framework allows a unified userspace interface for dma-buf
exporters, allowing userland to allocate specific types of memory
for use in dma-buf sharing.
Each heap is given its own device node, which a user can allocate
a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
Signed-off-by: Andrew F
On 2/25/19 6:20 PM, John Stultz wrote:
> On Mon, Feb 25, 2019 at 6:36 AM Andrew F. Davis wrote:
>>
>> This framework allows a unified userspace interface for dma-buf
>> exporters, allowing userland to allocate specific types of memory
>> for use in dma-buf sharing.
&
On 2/25/19 6:55 PM, John Stultz wrote:
> On Mon, Feb 25, 2019 at 6:36 AM Andrew F. Davis wrote:
>> +static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
>> unsigned int flags)
>> +{
>> + struct dma_heap_buffer *buffer;
>> + int fd, ret;
On 2/25/19 9:53 PM, Sumit Semwal wrote:
> On Mon, 25 Feb 2019 at 20:06, Andrew F. Davis wrote:
>>
>> This framework allows a unified userspace interface for dma-buf
>> exporters, allowing userland to allocate specific types of memory
>> for use in dma-buf sharing.
>&
On 2/26/19 12:20 AM, John Stultz wrote:
> On Mon, Feb 25, 2019 at 6:36 AM Andrew F. Davis wrote:
>>
>> This framework allows a unified userspace interface for dma-buf
>> exporters, allowing userland to allocate specific types of memory
>> for use in dma-buf sharing.
&
On 2/26/19 8:12 AM, Benjamin Gaignard wrote:
> Le lun. 25 févr. 2019 à 15:36, Andrew F. Davis a écrit :
>>
>> This framework allows a unified userspace interface for dma-buf
>> exporters, allowing userland to allocate specific types of memory
>> for use in dma-buf
On 2/26/19 5:40 PM, John Stultz wrote:
> On Tue, Feb 26, 2019 at 11:21 AM John Stultz wrote:
>>
>> On Tue, Feb 26, 2019 at 6:47 AM Andrew F. Davis wrote:
>>> On 2/26/19 12:20 AM, John Stultz wrote:
>>>> It boots w/ AOSP, and allocations seem to work, but t
On 2/27/19 3:55 PM, John Stultz wrote:
> On Wed, Feb 27, 2019 at 8:38 AM Andrew F. Davis wrote:
>>
>> On 2/26/19 5:40 PM, John Stultz wrote:
>>> On Tue, Feb 26, 2019 at 11:21 AM John Stultz wrote:
>>> I've updated the patches here:
>>> kernel:
On 3/1/19 6:06 AM, Brian Starkey wrote:
> Hi Andrew,
>
> Sorry for not managing to comment on this sooner, I've had a crazy few
> days.
>
> As the others have said, I quite like the direction here.
>
> On Mon, Feb 25, 2019 at 08:36:04AM -0600, Andrew F. Davis wrot
On 3/4/19 7:16 PM, John Stultz wrote:
> On Mon, Mar 4, 2019 at 6:53 AM Andrew F. Davis wrote:
>> On 3/1/19 6:06 AM, Brian Starkey wrote:
>>> On Mon, Feb 25, 2019 at 08:36:04AM -0600, Andrew F. Davis wrote:
>>>> +static long dma_heap_ioctl(struct file *filp, unsigne
On 3/5/19 2:54 PM, John Stultz wrote:
> From: "Andrew F. Davis"
>
> This framework allows a unified userspace interface for dma-buf
> exporters, allowing userland to allocate specific types of
> memory for use in dma-buf sharing.
>
> Each heap is given its ow
ott
>> Cc: Benjamin Gaignard
>> Cc: Greg KH
>> Cc: Sumit Semwal
>> Cc: Liam Mark
>> Cc: Brian Starkey
>> Cc: Andrew F. Davis
>> Cc: Chenbo Feng
>> Cc: Alistair Strachan
>> Cc: dri-devel@lists.freedesktop.org
>> Signed-off-by: John Stu
On 3/6/19 12:19 PM, John Stultz wrote:
> On Wed, Mar 6, 2019 at 10:15 AM Andrew F. Davis wrote:
>>
>> On 3/6/19 10:14 AM, Benjamin Gaignard wrote:
>>> Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
>>>>
>>>> Add very trivial allocation test fo
On 3/6/19 1:03 PM, John Stultz wrote:
> On Wed, Mar 6, 2019 at 10:18 AM Andrew F. Davis wrote:
>>
>> On 3/5/19 2:54 PM, John Stultz wrote:
>>> From: "Andrew F. Davis"
>>>
>>> This framework allows a unified userspace interface for dma-buf
&
mentation, so
>> thanks to its original authors and maintainters:
>> Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
>>
>> Cc: Laura Abbott
>> Cc: Benjamin Gaignard
>> Cc: Greg KH
>> Cc: Sumit Semwal
>> Cc: Liam Mark
>> Cc: Brian
On 3/13/19 5:57 PM, Liam Mark wrote:
> On Wed, 13 Mar 2019, Andrew F. Davis wrote:
>
>> On 3/13/19 3:18 PM, Liam Mark wrote:
>>> On Tue, 5 Mar 2019, John Stultz wrote:
>>>
>>>> Add generic helper dmabuf ops for dma heaps, so we can reduce
>>&g
s,
Andrew
[0] http://www.ti.com/lit/pdf/spruil1
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
[2] https://lkml.org/lkml/2019/6/6/1211
Andrew F. Davis (2):
dt-bindings: soc: ti: Add TI PAT bindings
soc: ti: Add Suppor
, 64KB, or 1MB of addresses in a window for which an incoming
transaction will be translated.
Signed-off-by: Andrew F. Davis
---
.../devicetree/bindings/misc/ti,pat.txt | 34 +++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/ti
window for which an incoming transaction will be
translated.
Signed-off-by: Andrew F. Davis
---
drivers/soc/ti/Kconfig | 9 +
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/ti-pat.c | 569
include/uapi/linux/ti-pat.h | 44 +++
4 files changed, 623
On 3/15/19 3:54 AM, Christoph Hellwig wrote:
>> +static int dma_heap_release(struct inode *inode, struct file *filp)
>> +{
>> +filp->private_data = NULL;
>> +
>> +return 0;
>> +}
>
> No point in clearing ->private_data, the file is about to be freed.
>
This was leftover from when release
On 3/15/19 3:18 PM, Laura Abbott wrote:
> On 3/5/19 12:54 PM, John Stultz wrote:
>> +DMA-BUF HEAPS FRAMEWORK
>> +M: Laura Abbott
>> +R: Liam Mark
>> +R: Brian Starkey
>> +R: "Andrew F. Davis"
>> +R: John Stultz
>> +S: Maintai
On 3/15/19 4:06 AM, Christoph Hellwig wrote:
>> +ret = remap_pfn_range(vma, addr, page_to_pfn(page), len,
>> + vma->vm_page_prot);
>
> So the same chunk could be mapped to userspace and vmap, and later on
> also DMA mapped. Who is going to take care of
On 3/19/19 7:08 AM, Brian Starkey wrote:
> Hi John,
>
> On Tue, Mar 05, 2019 at 12:54:29PM -0800, John Stultz wrote:
>> From: "Andrew F. Davis"
>
> [snip]
>
>> +
>> +#define NUM_HEAP_MINORS 128
>> +static DEFINE_IDR(dma_heap_idr);
>>
On 3/19/19 11:54 AM, Benjamin Gaignard wrote:
> Le mer. 13 mars 2019 à 23:31, John Stultz a écrit :
>>
>> On Wed, Mar 13, 2019 at 1:11 PM Liam Mark wrote:
>>> On Tue, 5 Mar 2019, John Stultz wrote:
Eventual TODOS:
* Reimplement page-pool for system heap (working on this)
* Add
On 3/20/19 4:16 AM, Benjamin Gaignard wrote:
> Le mar. 19 mars 2019 à 23:36, John Stultz a écrit :
>>
>> On Tue, Mar 19, 2019 at 2:58 PM Rob Clark wrote:
>>>
>>> On Tue, Mar 19, 2019 at 1:00 PM Andrew F. Davis wrote:
>>>>
>>>> On 3/19/19
This new export type exposes to userspace the SRAM area as a DMA-Heap,
this allows for allocations as DMA-BUFs that can be consumed by various
DMA-BUF supporting devices.
Signed-off-by: Andrew F. Davis
---
Hello all,
This is an example user of the currently RFC DMA-HEAP framework. It
exports a
The map_atomic/unmap_atomic callbacks have been removed, remove
the related comments.
Fixes: f664a5269542 ("dma-buf: remove kmap_atomic interface")
Signed-off-by: Andrew F. Davis
---
include/linux/dma-buf.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/include/linux/d
Other function have inline documentation, a couple still have
theirs at the top of the structure, update the docs and move
them inline.
Signed-off-by: Andrew F. Davis
---
include/linux/dma-buf.h | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a
On 3/19/19 9:26 AM, Brian Starkey wrote:
> Hi John,
>
> On Tue, Mar 05, 2019 at 12:54:30PM -0800, John Stultz wrote:
>
> ...
>
>> +
>> +void dma_heap_buffer_destroy(struct dma_heap_buffer *heap_buffer)
>> +{
>> +struct heap_helper_buffer *buffer = to_helper_buffer(heap_buffer);
>> +
>> +
rs:
> Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Greg KH
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Brian Starkey
> Cc: Andrew F. Davis
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: dr
counting to system/cma heaps
> * Make the kselftest more useful
> * Add other heaps folks see as useful (would love to get
> some help from actual carveout/chunk users)!
>
> That said, the main user-interface is shaping up and I wanted
> to get some input on the device model
rs:
> Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vincent Donnefort
> Cc: Sudipto Paul
> Cc: Andrew F. Davis
>
ION implementation, so
>> thanks to its original author and maintainters:
>> Benjamin Gaignard, Laura Abbott, and others!
>>
>> Cc: Laura Abbott
>> Cc: Benjamin Gaignard
>> Cc: Sumit Semwal
>> Cc: Liam Mark
>> Cc: Pratik Patel
>> Cc: Bria
On 3/29/19 10:30 AM, Benjamin Gaignard wrote:
> Le ven. 29 mars 2019 à 16:19, Andrew F. Davis a écrit :
>>
>> On 3/29/19 9:44 AM, Benjamin Gaignard wrote:
>>> Le ven. 29 mars 2019 à 01:16, John Stultz a écrit :
>>>>
>>>> This adds a CMA heap, whic
Found with scripts/coccinelle/misc/boolconv.cocci.
Signed-off-by: Andrew F. Davis
---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 1543c2f8d3d3
Benjamin Gaignard, Laura Abbott, and others!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vincent Donnefort
> Cc: Sudipto Paul
> Cc: Andrew F. Davis
> Cc: Xu YiPing
> Cc: &qu
The docs state the callback is optional but it is not, make it optional.
Signed-off-by: Andrew F. Davis
---
drivers/dma-buf/dma-buf.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 7c858020d14b
On 4/1/19 2:13 AM, Daniel Vetter wrote:
> On Fri, Mar 29, 2019 at 11:52:01AM -0500, Andrew F. Davis wrote:
>> The docs state the callback is optional but it is not, make it optional.
>>
>> Signed-off-by: Andrew F. Davis
>
> There's a bunch of dummy mmap implement
On 7/24/19 2:55 AM, Christoph Hellwig wrote:
> On Tue, Jul 23, 2019 at 01:09:55PM -0700, Rob Clark wrote:
>> On Mon, Jul 22, 2019 at 9:09 PM John Stultz wrote:
>>>
>>> On Thu, Jul 18, 2019 at 3:06 AM Christoph Hellwig
>>> wrote:
Is there any exlusion between mmap / vmap and the device
On 7/24/19 2:59 AM, Christoph Hellwig wrote:
> On Mon, Jul 22, 2019 at 10:04:06PM -0700, John Stultz wrote:
>> Apologies, I'm not sure I'm understanding your suggestion here.
>> dma_alloc_contiguous() does have some interesting optimizations
>> (avoiding allocating single page from cma), though its
On 7/25/19 8:50 AM, Christoph Hellwig wrote:
> On Wed, Jul 24, 2019 at 11:46:01AM -0400, Andrew F. Davis wrote:
>> https://patchwork.kernel.org/patch/10863957/
>>
>> It's actually a more simple heap type IMHO, but the logic inside is
>> incompatible with the syst
On 7/25/19 8:48 AM, Christoph Hellwig wrote:
> On Wed, Jul 24, 2019 at 07:38:07AM -0400, Laura Abbott wrote:
>> It's not just an optimization for Ion though. Ion was designed to
>> let the callers choose between system and multiple CMA heaps.
>
> Who cares about ion? That some out of tree android
On 7/25/19 10:04 AM, Christoph Hellwig wrote:
> On Thu, Jul 25, 2019 at 09:31:50AM -0400, Andrew F. Davis wrote:
>> But that's just it, dma-buf does not assume buffers are backed by normal
>> kernel managed memory, it is up to the buffer exporter where and when to
>>
On 7/25/19 10:11 AM, Christoph Hellwig wrote:
> On Thu, Jul 25, 2019 at 10:10:08AM -0400, Andrew F. Davis wrote:
>> Pages yes, but not "normal" pages from the kernel managed area.
>> page_to_pfn() will return bad values on the pages returned by this
>> allocator and
On 7/25/19 10:30 AM, Christoph Hellwig wrote:
> On Thu, Jul 25, 2019 at 10:25:50AM -0400, Andrew F. Davis wrote:
>> On 7/25/19 10:11 AM, Christoph Hellwig wrote:
>>> On Thu, Jul 25, 2019 at 10:10:08AM -0400, Andrew F. Davis wrote:
>>>> Pages yes, but not "normal&
On 7/25/19 9:02 AM, Christoph Hellwig wrote:
>> +struct system_heap {
>> +struct dma_heap *heap;
>> +} sys_heap;
>
> It seems like this structure could be removed and if would improve
> the code flow.
>
>> +static struct dma_heap_ops system_heap_ops = {
>> +.allocate = system_heap_allocat
On 6/18/19 5:07 AM, Tero Kristo wrote:
> On 07/06/2019 22:35, Andrew F. Davis wrote:
>> This patch adds a driver for the Page-based Address Translator (PAT)
>> present on various TI SoCs. A PAT device performs address translation
>> using tables stored in an internal SRAM. Ea
On 10/30/19 11:02 AM, Colin King wrote:
> From: Colin Ian King
>
> The variable ret is being assigned with a value that is never
> read, it is being re-assigned the same value on the err0 exit
> path. The assignment is redundant and hence can be removed.
>
> Addresses-Coverity: ("Unused value")
On 11/5/19 4:42 AM, Daniel Vetter wrote:
> On Mon, Nov 04, 2019 at 10:57:44AM -0800, John Stultz wrote:
>> On Mon, Nov 4, 2019 at 1:58 AM Daniel Vetter wrote:
>>> On Fri, Oct 25, 2019 at 11:48:32PM +, John Stultz wrote:
Now that the DMA BUF heaps core code has been queued, I wanted
t
1 - 100 of 143 matches
Mail list logo
