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
On 09/07/2018 08:20 AM, jun qian wrote:
The value in the wrong position will cause misunderstanding,
when the debug infomations display in the window.
I think the existing order is okay, it's just not separated
well. It's "$count pages of order $order". I also just acked a
patch to remove all
On 09/10/2018 03:00 AM, Alexey Skidanov wrote:
On 09/10/2018 12:36 PM, Dan Carpenter wrote:
On Sun, Sep 09, 2018 at 01:44:31AM +0300, Alexey Skidanov wrote:
The heap statistics have been removed and currently even basics statistics
are missing.
Remind me why did we remove them? What was th
On 09/18/2018 10:50 AM, Greg KH wrote:
On Tue, Sep 11, 2018 at 02:29:19PM +0300, 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 num
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;
;
- 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 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, but we may easily add it because CMA and gen_pool (used by
several heaps) already support it.
Do
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
On 10/11/2018 03:44 AM, Rock Lee wrote:
On Thu, Oct 11, 2018 at 4:12 PM Dan Carpenter wrote:
On Thu, Oct 11, 2018 at 11:24:49AM +0800, Rock Lee wrote:
Hi
I tested direct io with a ion allocated buffer, got a -EFAULT
error. It turned out that ion_mmap() set VM_IO & VM_PFNMAP, but
check_vm
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-
;
- 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/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 remove the carveout and chunk heap. I get
that it's being used for out of tree work but at this po
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
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
---
drivers/staging/android/ion/ion_chunk_heap.c | 40
1 file changed, 40
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
---
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/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/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/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 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/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 code responsibility to retrieve the heap configuration data
and to call the appropriate API for hea
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 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
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/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/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/11/19 11:09 PM, Jing Xia wrote:
gfp_flags is always set high_order_gfp_flags even if allocations of
order 0 are made.But for smaller allocations, the system should be able
to reclaim some memory.
Signed-off-by: Jing Xia
Reviewed-by: Yuming Han
Reviewed-by: Zhaoyang Huang
Reviewed-by: Ors
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
(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 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 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
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
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 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
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 11/12/2014 11:18 PM, Gioh Kim wrote:
> Hi,
>
> I'm wondering why dma_alloc_coherent needs GFP_HIGHUSER | __GFP_ZERO flags in
> ion_cma_allocate().
>
> I think dma_alloc_coherent can go to __dma_alloc if the system has CMA area.
> If __GFP_WAIT flag is set, it allocates memory from atomic pool
On 11/28/2014 5:31 PM, Zeng Tao wrote:
when cma is located in highmem, virt_to_page will not
work the right way, use pfn_to_page instead.
Signed-off-by: Zeng Tao
---
drivers/staging/android/ion/ion_cma_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging
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 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
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/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(),
-
On 09/19/2017 04:55 AM, Benjamin Gaignard wrote:
2017-09-19 13:02 GMT+02:00 Greg KH :
On Tue, Sep 19, 2017 at 12:25:38PM +0200, Benjamin Gaignard wrote:
Instead a getting one common device "/dev/ion" for
all the heaps this patch allow to create one device
entry ("/dev/ionX") per heap.
Getting a
On 09/20/2017 01:45 AM, Benjamin Gaignard wrote:
Instead a getting one common device "/dev/ion" for
all the heaps this patch allow to create one device
entry ("/dev/ionX") per heap.
Getting an entry per heap could allow to set security rules
per heap and global ones for all heaps.
Allocation req
On 09/25/2017 11:56 PM, Greg KH wrote:
On Tue, Sep 26, 2017 at 07:09:14AM +0200, Daniel Vetter wrote:
On Mon, Sep 25, 2017 at 11:26:27AM -0700, Laura Abbott wrote:
On 09/20/2017 01:45 AM, Benjamin Gaignard wrote:
Instead a getting one common device "/dev/ion" for
all the heaps
On 09/26/2017 09:17 AM, Mark Brown wrote:
On Tue, Sep 26, 2017 at 02:07:05PM +0200, Benjamin Gaignard wrote:
version 4:
- add a configuration flag to switch between legacy Ion misc device
and one device per heap version.
Should this be a switch or should it just be enabling and disabling t
On 09/27/2017 06:20 AM, Benjamin Gaignard wrote:
> Instead a getting only one common device "/dev/ion" for
> all the heaps this patch allow to create one device
> entry ("/dev/ionX") per heap.
> Getting an entry per heap could allow to set security rules
> per heap and global ones for all heaps.
>
On 10/03/2017 09:48 AM, Mark Brown wrote:
> On Mon, Oct 02, 2017 at 11:07:48AM -0700, Laura Abbott wrote:
>
>> Thinking about this a bit more, I'm not 100% sure if this
>> will allow the security rules we want. Heap ids are assigned
>> dynamically and therefore so w
On 10/03/2017 04:08 PM, Sandeep Patil wrote:
> On Tue, Oct 03, 2017 at 02:42:32PM -0700, Laura Abbott wrote:
>> On 10/03/2017 09:48 AM, Mark Brown wrote:
>>> On Mon, Oct 02, 2017 at 11:07:48AM -0700, Laura Abbott wrote:
>>>
>>>> Thinking about this a bit mo
eful.
> May I ask you your point of view on those few lines ?
>
> Benjamin
>
Yes, this looks better.
Acked-by: Laura Abbott
>> Signed-off-by: Benjamin Gaignard
>> ---
>> drivers/staging/android/ion/ion-ioctl.c | 11 +--
>> 1 file changed, 5 insertion
On 10/05/2017 06:06 AM, Benjamin Gaignard wrote:
> 2017-10-04 12:17 GMT+02:00 Mark Brown :
>> On Tue, Oct 03, 2017 at 04:08:30PM -0700, Sandeep Patil wrote:
>>
>>> It is entirely possible and easy in android/ueventd to create those nodes
>>> under "/dev/ion/". (assuming the heap 'subsystem' for th
On 10/09/2017 03:08 PM, Mark Brown wrote:
> On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote:
>
>> Anyway, to move this forward I think we need to see a proof of concept
>> of using selinux to protect access to specific heaps.
>
> Aren't Unix permissions
On 10/10/2017 02:11 AM, Mark Brown wrote:
> On Mon, Oct 09, 2017 at 05:10:37PM -0700, Laura Abbott wrote:
>> On 10/09/2017 03:08 PM, Mark Brown wrote:
>>> On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote:
>
>>>> Anyway, to move this forward I think
On 09/27/2017 06:20 AM, Benjamin Gaignard wrote:
> diff --git a/drivers/staging/android/ion/ion.c
> b/drivers/staging/android/ion/ion.c
> index 93e2c90..092b24c 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -40,6 +40,8 @@
>
> #include "ion.h"
>
On 10/23/2017 08:55 AM, Benjamin Gaignard wrote:
> Instead a getting only one common device "/dev/ion" for
> all the heaps this patch allow to create one device
> entry ("/dev/ionX") per heap.
> Getting an entry per heap could allow to set security rules
> per heap and global ones for all heaps.
>
On 10/31/2017 12:11 PM, Mark Brown wrote:
> On Tue, Oct 31, 2017 at 12:03:35PM -0700, Laura Abbott wrote:
>
>> I'm not a fan of the platform bus but I have mixed feelings about
>> creating a dedicated bus type. I guess if we really need a bus
>> type we can
; is
> never read
>
Acked-by: Laura Abbott
> Signed-off-by: Colin Ian King
> ---
> drivers/staging/android/ion/ion.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion.c
> b/drivers/staging/android/ion/ion.c
> index 93e2c90
SPDX identifier is a
legally binding shorthand, which can be used instead of the full boiler
plate text.
This work is based on a script and data from Thomas Gleixner, Philippe
Ombredanne, and Kate Stewart.
For the Ion parts,
Acked-by: Laura Abbott
Cc: "Arve Hjønnevåg"
Cc: Riley And
+ different ways that files in
the kernel describe the GPL license text. And there's unneeded stuff
like the address (sometimes incorrect) for the FSF which is never
needed.
No copyright headers or other non-license-description text was removed.
For the Ion portion,
Acked-by: Laura Abbott
On 11/06/2017 07:59 AM, Benjamin Gaignard wrote:
Put include in alphabetic order
Acked-by: Laura Abbott
Signed-off-by: Benjamin Gaignard
---
drivers/staging/android/ion/ion.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/android/ion
l ones for all heaps.
Allocation requests will be only allowed if the mask_id
match with device minor.
Query request could be done on any of the devices.
With this patch, sysfs looks like:
$ ls /sys/devices/
breakpoint ion platform software system virtual
From an Ion perspective, you can have
Ac
On 12/02/2017 07:53 AM, Greg KH wrote:
This is one of the item in the TODO list before been able to unstage ION
which is my real need.
Why does it matter where in the tree this code is? Don't go adding new
things to it that are not needed. Who needs this? What userspace code
wants this type o
On 12/15/2017 12:59 PM, Sushmita Susheelendra wrote:
Use the direction argument passed into begin_cpu_access
and end_cpu_access when calling the dma_sync_sg_for_cpu/device.
The actual cache primitive called depends on the direction
passed in.
Acked-by: Laura Abbott
Signed-off-by: Sushmita
("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
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
ailable.
What's your use case where you don't have a device structure?
Thanks,
Laura
> On 2016/9/14 2:41, Laura Abbott wrote:
>> On 09/13/2016 08:14 AM, Will Deacon wrote:
>>> On Tue, Sep 13, 2016 at 08:02:20AM -0700, Laura Abbott wrote:
>>>> On 09/13/2016
On 02/22/2017 05:01 PM, Chen Feng wrote:
>
>
> On 2017/2/22 3:29, Laura Abbott wrote:
>> On 02/20/2017 10:05 PM, Chen Feng wrote:
>>> Hi Laura,
>>>
>>> When we enable kernel v4.4 or newer version on our platform, we meet the
>>> issue
>&
Laura
[1] https://marc.info/?l=linux-kernel&m=148699712602105&w=2
[2] https://marc.info/?l=linaro-mm-sig&m=148176050802908&w=2
Laura Abbott (12):
staging: android: ion: Remove dmap_cnt
staging: android: ion: Remove alignment from allocation field
staging: android: ion: Du
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
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 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
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
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 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
---
drivers/base/dma-contiguous.c | 5 +++--
include/linux/cma.h | 4 +++-
mm/cma.c
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
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/ion-ioctl.c
be allocated directly from the APIs. Switch to using
this model to avoid needing a dummy device. This also avoids awkward
caching questions.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion_cma_heap.c | 97 --
1 file changed, 26 insertions(+), 71
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
Currently, all heaps are compiled in all the time. In switching to
a better platform model, let's allow these to be compiled out for good
measure.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/Kconfig| 32
drivers/staging/android/ion/Makefile
Practiaclly speaking, most Ion heaps are either going to be available
all the time (system heaps) or found based off of the reserved-memory
node. Parse the CMA and reserved-memory nodes to assign the heaps.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/Makefile| 2
On 03/03/2017 05:29 AM, Michal Hocko wrote:
> On Thu 02-03-17 13:44:32, Laura Abbott wrote:
>> Hi,
>>
>> There's been some recent discussions[1] about Ion-like frameworks. There's
>> apparently interest in just keeping Ion since it works reasonablly well.
&
On 03/03/2017 08:37 AM, Laurent Pinchart wrote:
> Hi Laura,
>
> Thank you for the patch.
>
> On Thursday 02 Mar 2017 13:44:36 Laura Abbott wrote:
>> Technically, calling dma_buf_map_attachment should return a buffer
>> properly dma_mapped. Add calls to dma_map_sg to be
On 03/03/2017 12:18 AM, Hillf Danton wrote:
>
> On March 03, 2017 5:45 AM Laura Abbott wrote:
>>
>> +static struct sg_table *dup_sg_table(struct sg_table *table)
>> +{
>> +struct sg_table *new_table;
>> +int ret, i;
>> +struct scatte
1 - 100 of 399 matches
Mail list logo
