On 12/19/18 9:19 AM, Zeng Tao wrote:
In some usecases, the buffer cached attribute is not determined at
allocation time, it's determined just before the real cpu mapping.
And from the memory view of point, a buffer should not have the cached
attribute util is really mapped by the cpu. So in this
On 12/19/18 5:39 PM, Zengtao (B) wrote:
Hi laura:
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Thursday, December 20, 2018 2:10 AM
To: Zengtao (B) ; sumit.sem...@linaro.org
Cc: Greg Kroah-Hartman ; Arve Hjønnevåg
; Todd Kjos ; Martijn Coenen
; Joel Fernandes
On 12/23/18 6:47 PM, Zengtao (B) wrote:
Hi laura:
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Friday, December 21, 2018 4:50 AM
To: Zengtao (B) ; sumit.sem...@linaro.org
Cc: Greg Kroah-Hartman ; Arve Hjønnevåg
; Todd Kjos ; Martijn Coenen
; Joel Fernandes
On 12/24/18 12:19 AM, Qing Xia wrote:
Now, as Google's user guide, if userspace need clean ION buffer's
cache, they should call ioctl(fd, DMA_BUF_IOCTL_SYNC, sync). Then
we found that ion_dma_buf_begin_cpu_access/ion_dma_buf_end_cpu_access
will do ION buffer's map_kernel, it's not necessary. And
On 1/3/19 5:42 PM, Zengtao (B) wrote:
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Thursday, January 03, 2019 6:31 AM
To: Zengtao (B) ; sumit.sem...@linaro.org
Cc: Greg Kroah-Hartman ; Arve Hjønnevåg
; Todd Kjos ; Martijn Coenen
; Joel Fernandes ;
de
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 memory can still be
allocated from and used by devices that do have access to the
bac
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 myself with the framework to help in whatever way I
can in getting all this up to the standard
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" 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 firew
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-controversial cleanups for the ION
framework and current set of heaps. These were found as I start to
familiarize myself
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 2019, Andrew F. Davis wrote:
Buffers may not be mapped from the CPU so skip cache maintenance here.
Accesses fro
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" heap is very similar to the carveout heap except
the backing memory is presumed to be unmappable b
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 for debugging but otherwise does not seem
to be required and no other part of the code will fail if left NUL
On 1/18/19 1: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 can tell.
Which makes me bel
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:05 AM, Andrew F. Davis wrote:
Hello all,
This is a set of (hopefully) non-controversial cleanups for the ION
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 AM, Andrew F. Davis wrote:
On 1/15/19 11:45 AM, Liam Mark wrote:
On Tue, 15 Jan 2019, Andrew F. Davis wrote
ttachment->priv;
struct ion_buffer *buffer = dmabuf->priv;
- free_duped_table(a->table);
mutex_lock(&buffer->lock);
list_del(&a->list);
mutex_unlock(&buffer->lock);
+ free_duped_table(a->table)
On 1/18/19 12:43 PM, Andrew F. Davis wrote:
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 AM, Andrew F. Davis wrote
On 1/18/19 10:37 AM, Liam Mark wrote:
Add support for configuring dma mapping attributes when mapping
and unmapping memory through dma_buf_map_attachment and
dma_buf_unmap_attachment.
Signed-off-by: Liam Mark
---
include/linux/dma-buf.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/
On 1/18/19 1:32 PM, Liam Mark wrote:
On Fri, 18 Jan 2019, Laura Abbott wrote:
On 1/18/19 10:37 AM, Liam Mark wrote:
Add support for configuring dma mapping attributes when mapping
and unmapping memory through dma_buf_map_attachment and
dma_buf_unmap_attachment.
Signed-off-by: Liam Mark
On 1/19/19 2:25 AM, Christoph Hellwig wrote:
On Fri, Jan 18, 2019 at 10:37:46AM -0800, Liam Mark wrote:
Add support for configuring dma mapping attributes when mapping
and unmapping memory through dma_buf_map_attachment and
dma_buf_unmap_attachment.
Signed-off-by: Liam Mark
And who is going
On 2/15/19 11:01 AM, John Stultz wrote:
On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey wrote:
Hi John,
On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
[snip]
Some thoughts, as this ABI break has the potential to be pretty painful.
1) Unfortunately, this ABI is exposed *throu
On 2/15/19 12:24 PM, John Stultz wrote:
With all the slight interface changes ion has had
through its time in staging, keeping userland working
properly has been a pain. Assuming more churn going
forward, provide a proper version interface.
Cc: Laura Abbott
Cc: Sumit Semwal
Cc: Liam Mark
Cc
On 2/19/19 9:21 AM, John Stultz wrote:
On Mon, Feb 18, 2019 at 3:51 AM Brian Starkey wrote:
On Fri, Feb 15, 2019 at 12:24:08PM -0800, John Stultz wrote:
This is a *very early RFC* (it builds, that's all I'll say :)
but I wanted to share it to get some initial feedback before I
go down the rabi
e anything if we
don't expose it as part of the ABI?
Cc: Laura Abbott
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Brian Starkey
Cc: Andrew F. Davis
Cc: Alistair Strachan
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/staging/android/ion/ion-ioctl.c | 12 +
e
naming.
Every CMA region getting exposed was a side effect of doing
the eneumeration without tying it to devicetree or other firmware.
I'm not opposed to limiting the heaps exposed if we can find
a good way to do so that's still compliant with devicetree/whatever.
Thanks,
Laura
Cc:
(i = 0; i < NUM_ORDERS; i++) {
struct ion_page_pool *pool;
+ gfp_t gfp_flags = low_order_gfp_flags;
if (orders[i] > 4)
gfp_flags = high_order_gfp_flags;
Acked-by: Laura Abbott
___
dri-devel
implement the per-heap devices for ION.
The main benefit is that it avoids multiplexing heap operations
through the /dev/ion interface, and allows for each heap to have
its own permissions/sepolicy rules.
Feedback would be greatly appreciated!
thanks
-john
Cc: Laura Abbott
Cc: Sumit Semwal
Cc:
On 1/24/19 8:44 AM, Brian Starkey wrote:
On Thu, Jan 24, 2019 at 10:04:46AM -0600, Andrew F. Davis wrote:
On 1/23/19 11:11 AM, Brian Starkey wrote:
[snip]
I'm very new to all this, so any pointers to history in this area are
appreciated.
[snip]
In case you didn't come across it alrea
On 2/19/19 1:39 PM, Andrew F. Davis wrote:
On 2/19/19 3:13 PM, Laura Abbott wrote:
On 2/15/19 12:24 PM, John Stultz wrote:
The per-device heaps don't support HEAP_QUERY ioctl, since
the name is provided in the devnode path and the heapid isn't
useful with the new interface (one uses
On 2/19/19 1:30 PM, Andrew F. Davis wrote:
On 2/19/19 3:25 PM, Laura Abbott wrote:
On 2/15/19 12:24 PM, John Stultz wrote:
This is a *very early RFC* (it builds, that's all I'll say :)
but I wanted to share it to get some initial feedback before I
go down the rabit hole of trying to
On 2/22/19 9:24 AM, John Stultz wrote:
On Fri, Feb 22, 2019 at 8:55 AM Andrew F. Davis wrote:
On 2/21/19 1:40 AM, John Stultz wrote:
Here is a very early peek at my dmabuf pools patchset, which
tries to destage a fair chunk of ION functionality.
This build and boots, but I've not gotten to te
On 2/25/19 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.
Each heap is given its own device node, which a user can allocate
a dma-buf fd from using the D
using fault injection.
Fix it by skipping the second free.
Reported-by: syzbot+e73f2fb5ed5a5df36...@syzkaller.appspotmail.com
Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
Reviewed-by: Chris Wilson
Cc: Laura Abbott
Cc: Daniel Vetter
Cc: sta...@vger.kernel.org
Signed-of
sn't have the page pooling so that particular bug may
not be applicable but given this is not the first time I've
seen Ion used as a DoS mechanism, it would be good to think about
putting in some basic checks.
Thanks,
Laura
Thoughts and feedback would be greatly appreciated!
thanks
-joh
hink we're at the point where nobody wants the
carveout and chunk heaps so I'd actually be okay with removing
those files. Just to be explicit:
Acked-by: Laura Abbott
Thanks,
Laura
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 7/3/19 4:18 AM, Nishka Dasgupta wrote:
Remove file ion_chunk_heap.c as its functions and definitions are not
used anywhere else.
Issue found with Coccinelle.
Acked-by: Laura Abbott
Signed-off-by: Nishka Dasgupta
---
drivers/staging/android/ion/Kconfig | 9 --
drivers
On 3/6/19 9:01 AM, John Stultz wrote:
On Wed, Mar 6, 2019 at 8:14 AM Benjamin Gaignard
wrote:
Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
+
+ printf("Allocating 1 MEG\n");
+ ret = dmabuf_heap_alloc(heap_fd, ONE_MEG, 0, &dmabuf_fd);
+ if (ret)
+ goto out;
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: Maintained
+L: linux-me...@vger.kernel.org
+L: dri-devel@lists.freedesktop.org
+L:
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 (particularly from GreKH)
and any other API/ABI specific input.
thanks
-john
Cc: Laura Abbott
Cc: Be
On 3/15/19 1:13 PM, John Stultz wrote:
On Fri, Mar 15, 2019 at 1:07 PM Laura Abbott wrote:
On 3/6/19 9:01 AM, John Stultz wrote:
On Wed, Mar 6, 2019 at 8:14 AM Benjamin Gaignard
wrote:
Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
+
+ printf("Allocating 1 MEG\n");
+
On 3/15/19 2:29 PM, John Stultz wrote:
On Fri, Mar 15, 2019 at 1: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: Maintained
+L:
On 3/20/19 7:23 AM, Vlastimil Babka wrote:
You should have CC'd the ION maintainers/lists per
./scripts/get_maintainer.pl - CCing now.
On 3/14/19 12:06 PM, Zhaoyang Huang wrote:
From: Zhaoyang Huang
Two action for this patch:
1. set a batch size for system heap's shrinker, which can have it b
On 3/29/19 11:40 AM, Zeng Tao wrote:
There are two reasons for this patch:
1. There are some potential requirements for ion_alloc in kernel space,
some media drivers need to allocate media buffers from ion instead of
buddy or dma framework, this is more convient and clean very for media
drivers.
On 3/29/19 7:26 PM, Zengtao (B) wrote:
Hi laura:
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Friday, March 29, 2019 9:27 PM
To: Zengtao (B) ; sumit.sem...@linaro.org
Cc: Greg Kroah-Hartman ; Arve Hjønnevåg
; Todd Kjos ; Martijn Coenen
; Joel Fernandes
sting buffers
- * @buffer_lock: lock protecting the tree of buffers
* @lock: rwsem protecting the tree of heaps and clients
*/
struct ion_device {
struct miscdevice dev;
- struct rb_root buffers;
- struct mutex buffer_lock;
struct rw_semaphore lock;
struct plist_head heaps;
struct dentry *debug_root;
Acked-by: Laura Abbott
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 focus o
On 7/17/19 12:31 PM, Alexander Popov wrote:
Hello!
The syzkaller [1] has a trouble with fuzzing the Linux kernel with ION Memory
Allocator.
Syzkaller uses several methods [2] to limit memory consumption of the userspace
processes calling the syscalls for testing the kernel:
- setrlimit(),
-
implemenation.
Signed-off-by: Daniel Vetter
Cc: Laura Abbott
Cc: Sumit Semwal
Cc: de...@driverdev.osuosl.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/staging/android/ion/ion.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/st
On 9/29/19 3:28 AM, jun.zh...@intel.com wrote:
From: zhang jun
we see tons of warning like:
[ 45.846872] x86/PAT: NDK MediaCodec_:3753 map pfn RAM range req
write-combining for [mem 0x1e7a8-0x1e7a87fff], got write-back
[ 45.848827] x86/PAT: .vorbis.decoder:4088 map pfn RAM range req
wri
hristoph)
* Fix indentation by using shorter argument names (suggested by
Christoph)
* Remove unused private_flags value
* Add forgotten include file to fix build issue on x86
* Checkpatch whitespace fixups
Thoughts and feedback would be greatly appreciated!
thanks
-john
Cc: Laura Abbott
Cc: Benja
Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
useful to have an explicit name attached to each region. Store the name
in each CMA structure.
Signed-off-by: Laura Abbott
---
v3: Added default name suggestion per Sumit. Fixup powerpc call site.
---
arch/powerpc/kvm
t of small
steps I'd like to go ahead and merge this series assuming there are no more
major objections. More work can happen on top of this.
Changes from v2:
- Dropped the RFC tag
- Minor bisectability fixes
- Sumit's comment about CMA naming
- Updated the TODO list
Thanks,
Laura
Laur
Technically, calling dma_buf_map_attachment should return a buffer
properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
ensure this happens. As a side effect, this lets Ion buffers take
advantage of the dma_buf sync ioctls.
Signed-off-by: Laura Abbott
---
drivers/staging/android
The new method of syncing with dma_map means that the page faulting sync
implementation is no longer applicable. Remove it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 117 --
1 file changed, 117 deletions(-)
diff --git a/drivers
Frameworks (e.g. Ion) may want to iterate over each possible CMA area to
allow for enumeration. Introduce a function to allow a callback.
Signed-off-by: Laura Abbott
---
include/linux/cma.h | 2 ++
mm/cma.c| 14 ++
2 files changed, 16 insertions(+)
diff --git a/include
The align field was supposed to be used to specify the alignment of
the allocation. Nobody actually does anything with it except to check
if the alignment specified is out of bounds. Since this has no effect
on the actual allocation, just remove it.
Signed-off-by: Laura Abbott
---
drivers
Ion is now moving towards a unified interfact. This makes the custom
ioctl interface unneeded. Remove it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/compat_ion.c | 40 --
drivers/staging/android/ion/ion-ioctl.c| 11 ---
drivers/staging
With the expansion of dma-buf and the move for Ion to be come just an
allocator, the import mechanism is mostly useless. There isn't a kernel
component to Ion anymore and handles are private to Ion. Remove this
interface.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/compat_
The reference counting of dma_map calls was removed. Remove the
associated counter field as well.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion_priv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion_priv.h
b/drivers/staging/android/ion
Ion currently returns a single sg_table on each dma_map call. This is
incorrect for later usage.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion.c
Now that we call dma_map in the dma_buf API callbacks there is no need
to use the existing cache APIs. Remove the sync ioctl and the existing
bad dma_sync calls. Explicit caching can be handled with the dma_buf
sync API.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/compat_ion.c
Device specific platform support has been haphazard for Ion. There have
been several independent attempts and there are still objections to
what bindings exist right now. Just remove everything for a fresh start.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/Kconfig
ION_IOC_MAP is the same as ION_IOC_SHARE. We really don't need two
identical interfaces. Remove it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/compat_ion.c | 1 -
drivers/staging/android/ion/ion-ioctl.c | 1 -
drivers/staging/android/uapi/ion.h | 10 --
3
lso remove the useless alignment field from the allocation
structure.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/Makefile | 3 -
drivers/staging/android/ion/compat_ion.c | 152 ---
drivers/staging/android/ion/compat_ion.h | 29 --
drive
be allocated directly from the APIs. Switch to using
this model to avoid needing a dummy device. This also mitigates some of
the caching problems (e.g. dma_alloc_coherent only returning uncached
memory).
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/Kconfig| 7 +++
drivers
Ion current has ion_priv.h and ion.h as header files. ion.h was intended
to be used for public APIs but Ion never ended up really having anything
public. Combine the two headers so there is only one internal header.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion-ioctl.c
Now that we have proper caching, stop setting the DMA address manually.
It should be set after properly calling dma_map.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/staging
Once upon a time, phys_addr_t was not everywhere in the kernel. These
days it is used enough places that having a separate Ion type doesn't
make sense. Remove the extra type and just use phys_addr_t directly.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.h
at to use. Switch to a model where Ion creates its
device unconditionally and heaps are registed as available regions.
Currently, only system and CMA heaps are converted over to the new
model. Carveout and chunk heaps can be converted over when someone wants
to figure out how.
Signed-off-by:
Nobody uses this interface externally. Drop it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 59 ---
1 file changed, 59 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 7d40233
give confusing data (orphaned
allocations) so it can be replaced with something better if people
actually want it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion-ioctl.c | 53 +--
drivers/staging/android/ion/ion.c | 701 ++--
drivers/staging
This never got set in the ioctl. Properly set a return value of 0 on
success.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 9eeb06f..d6fd350
Most of the items have been taken care of by a clean up series. Remove
the completed items and add a few new ones.
Signed-off-by: Laura Abbott
---
drivers/staging/android/TODO | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/android/TODO
Enable the GEM dma-buf import interfaces in addition to the export
interfaces. This lets vgem be used as a test source for other allocators
(e.g. Ion).
Signed-off-by: Laura Abbott
---
drivers/gpu/drm/vgem/vgem_drv.c | 135
drivers/gpu/drm/vgem
unit
test. I plan to extend that test with support for testing import as well.
RFC is for general direction and feedback since I'm not that familiar with
DRM internals.
Thanks,
Laura
[1] lkml.kernel.org/r/<1491245884-15852-1-git-send-email-labb...@redhat.com>
Laura Abbott (2):
drm/v
The vgem driver is currently registered independent of any actual
device. Some usage of the dmabuf APIs require an actual device structure
to do anything. Register a dummy platform device for use with dmabuf.
Signed-off-by: Laura Abbott
---
I realize the original driver had a note about '
On 04/07/2017 12:39 AM, Chris Wilson wrote:
> On Thu, Apr 06, 2017 at 04:18:33PM -0700, Laura Abbott wrote:
>>
>> Enable the GEM dma-buf import interfaces in addition to the export
>> interfaces. This lets vgem be used as a test source for other allocators
>
On 04/07/2017 09:58 AM, Chris Wilson wrote:
> On Fri, Apr 07, 2017 at 09:18:30AM -0700, Laura Abbott wrote:
>> On 04/07/2017 12:39 AM, Chris Wilson wrote:
>>> On Thu, Apr 06, 2017 at 04:18:33PM -0700, Laura Abbott wrote:
>>>>
>>>> Enable the GEM dma-buf i
On 04/08/2017 11:12 AM, Emil Velikov wrote:
> Hi Laura,
>
> Couple of trivial nitpicks below.
>
> On 3 April 2017 at 19:57, Laura Abbott wrote:
>
>> --- a/drivers/staging/android/ion/ion.h
>> +++ b/drivers/staging/android/ion/ion.h
>> @@ -1,5 +1,5 @@
>&
On 04/08/2017 03:38 AM, Greg Kroah-Hartman wrote:
> On Mon, Apr 03, 2017 at 11:57:42AM -0700, Laura Abbott wrote:
>> Hi,
>>
>> This is v3 of the series to do some serious Ion cleanup in preparation for
>> moving out of staging. I didn't hear much on v2 so I'
On 04/10/2017 09:25 AM, Greg Kroah-Hartman wrote:
> On Mon, Apr 10, 2017 at 09:20:27AM -0700, Laura Abbott wrote:
>> On 04/08/2017 03:38 AM, Greg Kroah-Hartman wrote:
>>> On Mon, Apr 03, 2017 at 11:57:42AM -0700, Laura Abbott wrote:
>>>> Hi,
>>>>
>&g
On 04/10/2017 11:47 PM, Laurent Pinchart wrote:
> Hi Laura,
>
> Thank you for the patch.
>
> On Monday 03 Apr 2017 11:57:55 Laura Abbott wrote:
>> When CMA was first introduced, its primary use was for DMA allocation
>> and the only way to get CMA memory was to ca
SYNC, rather than done implicitly
> inside the read/write, so that the user can avoid synchronisation if
> they so choose.
>
> v2: Lots of little fixes, plus a real llseek() implements so that the
> first basic little test cases work!
>
> Testcase: igt/prime_rw
> Signed-off
On 04/12/2017 12:38 PM, Chris Wilson wrote:
> On Wed, Apr 12, 2017 at 11:29:18AM -0700, Laura Abbott wrote:
>> On 04/07/2017 02:25 PM, Chris Wilson wrote:
>>> It is expected that processes will pass dma-buf fd between drivers, and
>>> only using the fd themselves for
On 04/12/2017 01:12 PM, Chris Wilson wrote:
> On Wed, Apr 12, 2017 at 12:57:00PM -0700, Laura Abbott wrote:
>> On 04/12/2017 12:38 PM, Chris Wilson wrote:
>>> On Wed, Apr 12, 2017 at 11:29:18AM -0700, Laura Abbott wrote:
>>>> Both the read/write are missing the
hanks,
Laura
Laura Abbott (12):
cma: Store a name in the cma structure
cma: Introduce cma_for_each_area
staging: android: ion: Use CMA APIs directly
staging: android: ion: Stop butchering the DMA address
staging: android: ion: Break the ABI in the name of forward progress
staging: android
Frameworks (e.g. Ion) may want to iterate over each possible CMA area to
allow for enumeration. Introduce a function to allow a callback.
Signed-off-by: Laura Abbott
---
include/linux/cma.h | 2 ++
mm/cma.c| 14 ++
2 files changed, 16 insertions(+)
diff --git a/include
Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
useful to have an explicit name attached to each region. Store the name
in each CMA structure.
Signed-off-by: Laura Abbott
---
arch/powerpc/kvm/book3s_hv_builtin.c | 3 ++-
drivers/base/dma-contiguous.c| 5
be allocated directly from the APIs. Switch to using
this model to avoid needing a dummy device. This also mitigates some of
the caching problems (e.g. dma_alloc_coherent only returning uncached
memory).
Signed-off-by: Laura Abbott
---
v4: Put some #ifdef around CMA heap functions. This is ugly but
Now that we have proper caching, stop setting the DMA address manually.
It should be set after properly calling dma_map.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/staging
lso remove the useless alignment field from the allocation
structure.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/Makefile | 3 -
drivers/staging/android/ion/compat_ion.c | 152 ---
drivers/staging/android/ion/compat_ion.h | 29 --
drive
Once upon a time, phys_addr_t was not everywhere in the kernel. These
days it is used enough places that having a separate Ion type doesn't
make sense. Remove the extra type and just use phys_addr_t directly.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.h
at to use. Switch to a model where Ion creates its
device unconditionally and heaps are registed as available regions.
Currently, only system and CMA heaps are converted over to the new
model. Carveout and chunk heaps can be converted over when someone wants
to figure out how.
Signed-off-by:
Nobody uses this interface externally. Drop it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 59 ---
1 file changed, 59 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 7d40233
Most of the items have been taken care of by a clean up series. Remove
the completed items and add a few new ones.
Signed-off-by: Laura Abbott
---
drivers/staging/android/TODO | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/android/TODO
This never got set in the ioctl. Properly set a return value of 0 on
success.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 9eeb06f..d6fd350
give confusing data (orphaned
allocations) so it can be replaced with something better if people
actually want it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion-ioctl.c | 53 +--
drivers/staging/android/ion/ion.c | 701 ++--
drivers/staging
Ion current has ion_priv.h and ion.h as header files. ion.h was intended
to be used for public APIs but Ion never ended up really having anything
public. Combine the two headers so there is only one internal header.
Signed-off-by: Laura Abbott
---
v4: minor cleanup suggested by Emil Velikov
on,
Acked-by: Laura Abbott
I did some major Ion refactoring but I don't think this
will conflict.
Thanks,
Laura
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
The vgem driver is currently registered independent of any actual
device. Some usage of the dmabuf APIs require an actual device structure
to do anything. Register a dummy platform device for use with dmabuf.
Signed-off-by: Laura Abbott
---
v2: Store the platform device in the platformdev field
1 - 100 of 232 matches
Mail list logo
