, just drop the in-kernel
copy of the ion code now, as it's not used, and is only causing problems
for everyone involved.
Cc: "Arve Hjønnevåg"
Cc: "Christian König"
Cc: Christian Brauner
Cc: Christoph Hellwig
Cc: Hridya Valsaraju
Cc: Joel Fernandes
Cc: John Stultz
Cc:
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
On 8/26/19 3:55 AM, Alexey Skidanov wrote:
On 8/26/19 11:36 AM, Laura Abbott wrote:
On 8/23/19 10:28 PM, Alexey Skidanov wrote:
In ion_cma_heap, the allocated buffer is represented by a single
struct scatterlist instance. The length field of this struct is
32 bit, hence the maximal size of
On 8/23/19 10:28 PM, Alexey Skidanov wrote:
In ion_cma_heap, the allocated buffer is represented by a single
struct scatterlist instance. The length field of this struct is
32 bit, hence the maximal size of requested buffer should be
less than 4GB.
The len paramer of the allocation function is 6
ing Ion
out of staging and this is something I mentioned to John Stultz. I don't
think we've thought too hard about how to do the actual limiting so
suggestions are welcome.
Thanks,
Laura
Best regards,
Alexander
[1]: https://github.com/google/syzkaller
[2
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
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
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
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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
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.
pool = sys_heap->pools[i];
if (only_scan) {
We're in the process of significantly reworking Ion so I
don't think it makes sense to take these as we work to
get things out of staging. You can resubmit this later,
but when you do please split this into two separ
I found that the comments had several typos such as "aenable", "internaly" and
some others.
I fixed them all.
Signed-off-by: Laura Lazzati
---
drivers/staging/octeon-usb/octeon-hcd.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/driver
m to want out of Ion ("I know I want memory type X please
give it to me"). That's not to say that this was a perfect or
even the correct approach, just what made the most sense based
on users.
Thanks,
Laura
___
devel mailing list
de.
(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
___
devel
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
8778-1-git-send-email-saberlily@hisilicon.com/T/#u
(I'm also very behind on Ion e-mail and need to catch up...)
Laura
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
ags in dma-buf really solves anything
given drivers can use the attributes directly with dma_map
anyway, which is what we're looking to do. The intention
is for the driver creating the dma_buf attachment to have
the knowledge of which flags to use.
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
. The same commment applies to the follow up patch,
I don't quite see how it's being used.
Thanks,
Laura
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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
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/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
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
ssion on how to let those heaps and associated function actually
be called in some way in tree. I expect them to either get called
in tree or be replaced.
Thanks,
Laura
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverprojec
NULL
except here. We can make it required and check for it at some point,
for now lets just prevent this from causing a NULL pointer exception.
I'm not so keen on this one. In the "new" API with heap querying, the
name string is the only way to identify the heap. I think Laura
menti
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
hy does the buffer need to be cleaned here? I just got through reading
the thread linked by Laura in the other reply. I do like +Brian's
suggestion of tracking if the buffer has had CPU access since the last
time and only flushing the cache if it has. As unmapped heaps never get
CPU mapped th
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 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
c3@DESKTOP-E1NTVVP.localdomain/
for some background on that problem.
Thanks,
Laura
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
lways
* are at the end of this enum
Overall this seems way too similar to the carveout heap
to justify adding another heap type. It also still missing
the part of where exactly you call ion_unmapped_heap_create.
Figuring that out is one of the blocking items for
On 1/2/19 10:28 PM, Alexey Skidanov wrote:
On 1/3/19 12:37 AM, Laura Abbott wrote:
On 12/20/18 1:29 PM, Alexey Skidanov wrote:
On 12/20/18 10:36 PM, Laura Abbott wrote:
On 12/16/18 2:46 AM, Alexey Skidanov wrote:
Chunk heap instantiation should be supported for device tree platforms
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 12/20/18 1:29 PM, Alexey Skidanov wrote:
On 12/20/18 10:36 PM, Laura Abbott wrote:
On 12/16/18 2:46 AM, Alexey Skidanov wrote:
Chunk heap instantiation should be supported for device tree platforms
and
non device tree platforms. For device tree platforms, it's a platform
specific
to work. All setup is supposed to happen in begin_cpu_access.
I agree calling map kernel each time isn't great but I think
this needs to be worked out with dma_buf.
Thanks,
Laura
Signed-off-by: Qing Xia
---
drivers/staging/android/ion/ion.c | 46 ++-
1
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/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
original purpose of the chunk heap was a carveout where
you could easily get allocations large than PAGE_SIZE to
reduce TLB pressure. Do you have another use case for the
chunk heap?
Sumit, do you have any thoughts?
Thanks,
Laura
Link:
http://driverdev.linuxdriverproject.org/pipermail/driverdev-de
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 11/30/18 6:43 AM, Yangtao Li wrote:
seq_file.h does not need to be included,so remove it.
Acked-by: Laura Abbott
Signed-off-by: Yangtao Li
---
drivers/staging/android/ion/ion.c | 1 -
drivers/staging/android/ion/ion_system_heap.c | 1 -
2 files changed, 2 deletions
On 11/27/18 12:07 PM, Alexey Skidanov wrote:
On 11/27/18 9:20 PM, Laura Abbott wrote:
On 11/26/18 10:43 AM, Alexey Skidanov wrote:
On 11/26/18 6:39 PM, Laura Abbott wrote:
On 11/25/18 2:02 PM, Alexey Skidanov wrote:
On 11/25/18 11:40 PM, Laura Abbott wrote:
On 11/25/18 1:22 PM, Alexey
On 11/26/18 10:43 AM, Alexey Skidanov wrote:
On 11/26/18 6:39 PM, Laura Abbott wrote:
On 11/25/18 2:02 PM, Alexey Skidanov wrote:
On 11/25/18 11:40 PM, Laura Abbott wrote:
On 11/25/18 1:22 PM, Alexey Skidanov wrote:
On 11/25/18 10:51 PM, Laura Abbott wrote:
On 11/11/18 11:29 AM
On 11/25/18 2:02 PM, Alexey Skidanov wrote:
On 11/25/18 11:40 PM, Laura Abbott wrote:
On 11/25/18 1:22 PM, Alexey Skidanov wrote:
On 11/25/18 10:51 PM, Laura Abbott wrote:
On 11/11/18 11:29 AM, Alexey Skidanov wrote:
Create chunk heap of specified size and base address by adding
On 11/25/18 1:22 PM, Alexey Skidanov wrote:
On 11/25/18 10:51 PM, Laura Abbott wrote:
On 11/11/18 11:29 AM, Alexey Skidanov wrote:
Create chunk heap of specified size and base address by adding
"ion_chunk_heap=size@start" kernel boot parameter.
Signed-off-by: Alexey Skidanov
---
ell the kernel to reserve
the memory early enough and then get that information to
Ion. Hard coding memory locations tends to be buggy from
my past experience with Ion.
If you'd like to see about coming up with a complete solution,
feel free to resubmit but I'm still strongly considerin
On 11/8/18 11:34 AM, Alexey Skidanov wrote:
On 11/8/18 9:15 PM, Laura Abbott wrote:
On 10/22/18 2:15 PM, Alexey Skidanov wrote:
Heap name is mundatory.
I'm wary of this and the other change because it misses the
broader problem of dealing with the carveout heaps.
I still want to r
ut at this point
the focus needs to be on moving Ion out of staging and
if we can't get an end-to-end solution for carveout/chunk
heaps to be allocated in tree this needs to be removed.
Thanks,
Laura
Signed-off-by: Alexey Skidanov
---
drivers/staging/android/ion/ion_carveout_heap.c | 1 +
;
- the number of allocated bytes watermark.
Acked-by: Laura Abbott
Signed-off-by: Alexey Skidanov
---
v3:
Removed debugfs_create_dir() return value checking
v4:
Added spinlock to protect heap statistics
v5:
Rebased on staging-next
drivers/staging/android/ion/ion.c
On 10/22/2018 07:02 AM, Alexey Skidanov wrote:
The heap name might be uninitialized and access might crash the
kernel.
The heap name should never be null so this seems like this is being
fixed in the wrong place. Can you explain more how you are hitting
this issue?
Thanks,
Laura
Signed-off
ut it's escaping me. If you wanted
to do the work to move away from remap_pfn_range, that would
be appreciated.
Thanks,
Laura
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On 10/03/2018 01:03 PM, Alexey Skidanov wrote:
On 10/03/2018 09:07 PM, Laura Abbott wrote:
On 10/02/2018 07:27 AM, Alexey Skidanov wrote:
Hi,
Sometimes HW requires memory buffer to be aligned in order to be used
properly. Of course, we may overcome the lack of aligned allocation
support
k it again. I'm not
opposed to adding alignment support for the CMA via the allocation
flags. I'm probably going to remove the carveout and chunk heap because
nobody has stepped up to figure out how to tie allocation of those
to device tree or anoth
;
- the number of allocated bytes watermark.
If none of the other Android people have strong opinions
Acked-by: Laura Abbott
Signed-off-by: Alexey Skidanov
---
v3:
Removed debugfs_create_dir() return value checking
v4:
Added spinlock to protect heap statistics
drivers
On 09/11/2018 04:29 AM, Alexey Skidanov wrote:
Heap statistics have been removed and currently even basics statistics
are missing.
This patch creates per heap debugfs directory /sys/kernel/debug/
and adds the following counters:
- the number of allocated buffers;
- the number of allocated bytes;
bit more before giving an Ack. Give me to the end of the
week to take a look.
Thanks,
Laura
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
the git hash?
15c6098cfec5 ("staging: android: ion: Remove ion_handle and ion_client")
According to Laura, "The goal was to rip out the racy handle/buffer mess
and the associated debugfs there"
Yes, the debugfs was removed with that commit because the underlying
handle/clien
patch to remove all this code because it's dead on mainline
anyway. For future work, we should look to make the debugfs
output clearer to avoid ambiguity.
Thanks,
Laura
Signed-off-by: jun qian
---
drivers/staging/android/ion/ion_system_heap.c | 4 ++--
1 file changed, 2 insertions(+), 2
On 09/04/2018 10:03 PM, Alexey Skidanov wrote:
ION had supported heap debug info under /sys/kernel/debug/ion/.
This support have been removed but some leftovers (dead code) still exist.
This patch removes the existing dead code.
Acked-by: Laura Abbott
Fixes: 15c6098cfec5 ("st
ly no way to use it
safely.
This patch is applied on top of 4.4.y, and applies to older kernels
too. 4.9.y was fixed separately. Kernels 4.12 and later are
unaffected, since all the underlying ion_handle infrastructure has been
ripped out.
Acked-by: Laura Abbott
Cc: sta...@vger.kernel.or
("staging: android: ion: Remove ion_handle and ion_client")) specified
somewhere in the commit text so if you add that, you can add
Acked-by: Laura Abbott
Signed-off-by: Alexey Skidanov
---
drivers/staging/android/ion/ion.h | 5 -
drivers/staging/android/ion/io
: Laura Abbott
---
drivers/staging/android/ion/ion_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion_heap.c
b/drivers/staging/android/ion/ion_heap.c
index 772dad65396e..f32c12439eee 100644
--- a/drivers/staging/android/ion/ion_heap.c
+++ b
: syzbot
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index e74db7902549..a68329411b29 100644
--- a/drivers/staging/android/ion/ion.c
+++ b
On 05/09/2018 11:59 PM, Dmitry Vyukov wrote:
On Wed, Jan 10, 2018 at 7:14 PM, Laura Abbott wrote:
On 01/09/2018 02:58 PM, syzbot wrote:
Hello,
syzkaller hit the following crash on
06d41862286aa7bc634a1dd9e6e7e96f925ef30a
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
On 05/07/2018 07:51 AM, Nathan Chancellor wrote:
On Mon, May 07, 2018 at 06:46:23AM -0700, Laura Abbott wrote:
On 05/06/2018 06:43 PM, Nathan Chancellor wrote:
Hi everyone,
I compiled the ion driver with W=1 where I encountered the two following
warnings and I had a couple of questions about
On 05/07/2018 07:40 AM, Nathan Chancellor wrote:
On Mon, May 07, 2018 at 06:37:52AM -0700, Laura Abbott wrote:
On 05/06/2018 06:18 PM, Nathan Chancellor wrote:
checkpatch.pl complains these are invalid because the rules in
Documentation/process/license-rules.rst state that C headers should
n they be removed?
I'd still like to delete it. I haven't seen anyone come out to re-work it.
That said, I think my preference is still to keep it for now until
we do another round of updates.
Thanks for looking at these.
Laura
If any part of this email was formatted
ex_init(&buffer->lock);
mutex_lock(&dev->buffer_lock);
Acked-by: Laura Abbott
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
ick read of the SPDX specification that says they have to use //.
I think this is going to generate a lot of possible noise so it
might be worth adjusting checkpatch.
Thanks,
Laura
Signed-off-by: Nathan Chancellor
---
drivers/staging/android/ion/ion.h | 2 +-
drivers/staging/android/uapi/ion.h |
On 04/27/2018 02:29 AM, vji...@codeaurora.org wrote:
On 2018-04-27 10:40, vji...@codeaurora.org wrote:
On 2018-04-25 21:17, Laura Abbott wrote:
On 04/24/2018 08:43 PM, vji...@codeaurora.org wrote:
From: Vijayanand Jitta
An issue is observed where mallocs are failing due to overcommit
->order)));
return page;
}
I'm sure this fixes the problem but I don't think we want to
start throwing page adjustments into Ion. Why isn't this
memory already considered reclaimable by existing calculations?
Thanks,
Laura
ixups should be
small these days.
Acked-by: Laura Abbott
Cc: Laura Abbott
Cc: Sumit Semwal
Cc: de...@driverdev.osuosl.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org (moderated for non-subscribers)
Cc: Greg Kroah-Hartman
Signed-off-by: Daniel Vetter
---
MAINTAINER
e that can be shared between drivers.
If you're not using Android its probably safe to
The formatting here looks a little funny, did you manually edit the
patch to take out the diff-stat and index? The patch seem to apply
okay, so I'm just curious. Eithe
On 03/08/2018 04:45 PM, Liam Mark wrote:
On Wed, 7 Mar 2018, Laura Abbott wrote:
On 02/28/2018 09:18 PM, Liam Mark wrote:
The issue:
Currently in ION if you allocate uncached memory it is possible that there
are still dirty lines in the cache. And often these dirty lines in the
cache are
u know it's needed.
- The locking/sequencing with userspace could be tricky
since userspace may not like us ripping mappings out from
underneath if it's trying to access.
Thoughts?
Thanks,
Laura
___
devel mailing lis
On 02/26/2018 09:07 AM, Shuah Khan wrote:
On 02/19/2018 11:33 AM, Daniel Vetter wrote:
On Mon, Feb 19, 2018 at 10:18:21AM -0800, Laura Abbott wrote:
On 02/19/2018 07:31 AM, Daniel Vetter wrote:
On Thu, Feb 15, 2018 at 05:24:45PM -0800, Laura Abbott wrote:
Ion is designed to be a framework
There's no need to print messages each time we alloc and free. Remove them.
Signed-off-by: Laura Abbott
---
v2: No changes
---
tools/testing/selftests/android/ion/ionutils.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/tools/testing/selftests/android/ion/ionutils.c
b/tools/te
Ion is designed to be a framework used by other clients who perform
operations on the buffer. Use the DRM vgem client as a simple consumer.
In conjunction with the dma-buf sync ioctls, this tests the full attach/map
path for the system heap.
Reviewed-by: Daniel Vetter
Signed-off-by: Laura Abbott
er to actually make some of the dma_buf calls. The vgem
DRM driver exists mostly for testing and works great for this case.
Changes since v1:
- Dropped RFC
- Feedback/review from Daniel Vetter about DRM ioctls
Thanks,
Laura
Laura Abbott (2):
selftests: ion: Remove some prints
selftests: ion
On 02/19/2018 07:31 AM, Daniel Vetter wrote:
On Thu, Feb 15, 2018 at 05:24:45PM -0800, Laura Abbott wrote:
Ion is designed to be a framework used by other clients who perform
operations on the buffer. Use the DRM vgem client as a simple consumer.
In conjunction with the dma-buf sync ioctls
On 02/16/2018 04:17 AM, Alexey Skidanov wrote:
On 02/16/2018 01:48 AM, Laura Abbott wrote:
On 02/12/2018 02:33 PM, Alexey Skidanov wrote:
Current ion kernel mapping implementation uses vmap() to map previously
allocated buffers into kernel virtual address space.
On 32-bit platforms, vmap
l comments.
Thanks,
Laura
Laura Abbott (2):
selftests: ion: Remove some prints
selftests: ion: Add simple test with the vgem driver
tools/testing/selftests/android/ion/Makefile | 3 +-
tools/testing/selftests/android/ion/config| 1 +
tools/testing/selftests/android/ion/ion
Ion is designed to be a framework used by other clients who perform
operations on the buffer. Use the DRM vgem client as a simple consumer.
In conjunction with the dma-buf sync ioctls, this tests the full attach/map
path for the system heap.
Signed-off-by: Laura Abbott
---
tools/testing
There's no need to print messages each time we alloc and free. Remove them.
Signed-off-by: Laura Abbott
---
tools/testing/selftests/android/ion/ionutils.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/tools/testing/selftests/android/ion/ionutils.c
b/tools/testing/selftests/an
table, offset));
}
This unfortunately doesn't work for uncached buffers. We need to create
an uncached alias otherwise we break what little coherency that guarantees.
I'm still convinced that we can't actually do the uncached buffers
correctly and they should be remo
#x27;s cleaner if we initialize the new list. You can add my
Ack when you update with a new change log clarifying this.
Thanks,
Laura
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
, the following sequences:
- write to the buffer
- DMA read
or
- DMA write
- read from the buffer
may be problematic.
Thanks,
Alexey
Have you looked at the dma_buf sync ioctl? (see include/uapi/linux/dma-buf.h)
Thanks,
Laura
___
devel mailing li
On 02/12/2018 12:22 PM, Alexey Skidanov wrote:
On 02/12/2018 09:52 PM, Laura Abbott wrote:
On 02/12/2018 11:11 AM, Alexey Skidanov wrote:
On 02/12/2018 08:42 PM, Laura Abbott wrote:
On 02/10/2018 02:17 AM, Alexey Skidanov wrote:
Current ion defined allocation ioctl doesn't all
this in the complete opposite
order of course). I'm assuming this passed your internal tests Liam?
Thanks,
Laura
Fixes: 2a55e7b5e544 ("staging: android: ion: Call dma_map_sg for syncing and
mapping")
Signed-off-by: Liam Mark
---
drivers/staging/android/ion/ion.c | 16 ++
this in the complete opposite
order of course). I'm assuming this passed your internal tests Liam?
Thanks,
Laura
Fixes: 2a55e7b5e544 ("staging: android: ion: Call dma_map_sg for syncing and
mapping")
Signed-off-by: Liam Mark
---
drivers/staging/android/ion/ion.c | 16 ++
On 02/12/2018 11:21 AM, Alexey Skidanov wrote:
On 02/12/2018 08:30 PM, Laura Abbott wrote:
On 02/10/2018 01:43 AM, Alexey Skidanov wrote:
Hi,
Current ion kernel mapping implementation uses vmap() to map previously
allocated buffers into kernel virtual address space. On 32 bit
platforms
On 02/12/2018 11:11 AM, Alexey Skidanov wrote:
On 02/12/2018 08:42 PM, Laura Abbott wrote:
On 02/10/2018 02:17 AM, Alexey Skidanov wrote:
Current ion defined allocation ioctl doesn't allow to specify the
requested
allocation alignment. CMA heap allocates buffers aligned on buffer size
hy it was removed
from the ABI in the first place).
The alignment came from the behavior of the DMA APIs. Do you
actually need to specify any alignment from userspace or do
you only need page size?
Thanks,
Laura
To fix this, we add an alignment parameter to the allocation ioctl.
Signed-off-by: A
d the entire buffer. We got away
with this because the in kernel mapping APIs are used very infrequently
and with buffers that never triggered an exhaustion of vmalloc
space.
If we actually start seeing problems with this we can fix it up
but I don't consider this a high priority item.
Tha
On 02/07/2018 07:10 AM, Alexey Skidanov wrote:
On 02/07/2018 04:58 PM, Laura Abbott wrote:
On 02/06/2018 11:05 PM, Alexey Skidanov wrote:
Yup, you've hit upon a key problem. Having fallbacks be stable
was always a problem and the recommendation these days is to
not rely on them. Yo
ave a proposal to make fallbacks work reliably without
overly complicating the ABI I'm happy to review it.
Thanks,
Laura
I think it's possible to "automate" the "manual fallback" behavior. But
the real issues is using heap id to specify the particular heap object.
Current
Are you planning to use Ion with GPU drivers? I'm especially
interested in this if you have a non-Android use case.
Thanks,
Laura
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
s always a problem and the recommendation these days is to
not rely on them. You can specify a heap at a time and fallback
manually if you want that behavior.
If you have a proposal to make fallbacks work reliably without
overly complicating the A
On 02/06/2018 03:10 PM, Laura Abbott wrote:
On 02/04/2018 07:26 PM, Yisheng Xie wrote:
ion_page_pool_add will always return 0, however ion_page_pool_free will
call ion_page_pool_free_pages when ion_page_pool_add's return value is
not 0, so it is a dead code which can be removed.
Ca
On 02/04/2018 07:26 PM, Yisheng Xie wrote:
ion_page_pool_add will always return 0, however ion_page_pool_free will
call ion_page_pool_free_pages when ion_page_pool_add's return value is
not 0, so it is a dead code which can be removed.
Can you clean up ion_page_pool_add to be a void return as
1 - 100 of 405 matches
Mail list logo
