+ Sumit
Hi Sumit,
Do you have any thoughts on this patch?
It fixes a potential crash in on older kernel and I think limiting
begin/end_cpu_access to only apply cache maintenance when the buffer is
dma mapped makes sense from a logical perspective and performance
perspective.
On Wed, 6
On Fri, 4 Jan 2019, Skidanov, Alexey wrote:
>
>
> > -Original Message-
> > From: Liam Mark [mailto:lm...@codeaurora.org]
> > Sent: Friday, January 04, 2019 19:42
> > To: Skidanov, Alexey
> > Cc: Laura Abbott ; Greg KH ;
> > de...@
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_sync_sg_for_cpu and dma_sync_sg_for_device APIs to p
On Mon, 21 Jan 2019, 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 Tue, 22 Jan 2019, Andrew F. Davis wrote:
> 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 p
On Tue, 22 Jan 2019, Andrew F. Davis 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 Mon, 21 Jan 2019, Brian Starkey wrote:
> Hi Liam,
>
> On Fri, Jan 18, 2019 at 10:37:47AM -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_attac
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 Jan 2019, Christoph Hellwig wrote:
> >>>
> >>
On Mon, 21 Jan 2019, Christoph Hellwig wrote:
> On Mon, Jan 21, 2019 at 12:20:42PM -0800, Liam Mark wrote:
> > I have left this to clients, but if they own the buffer they can have the
> > knowledge as to whether CPU access is needed in that use case (example for
>
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 happens in d
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:
> >>>> And who is going to decide which ones to pas
On Fri, 18 Jan 2019, Andrew F. Davis wrote:
> 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 Mon, 21 Jan 2019, Andrew F. Davis wrote:
> 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 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 documented dma-buf flags that
> > >
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 2019, Andrew F. Davis 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:
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_sync_sg_for_cpu and dma_sync_sg_for_device APIs to perform cache
> > maintenance.
> >
> > Curren
("staging: android: ion: Call dma_map_sg for syncing and
mapping")
Signed-off-by: Liam Mark
---
drivers/staging/android/ion/ion.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android
accessed by the CPU.
Signed-off-by: Liam Mark
---
drivers/staging/android/ion/ion.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 1fe633a7fdba..0aae845b20ba 100644
--- a/drivers/staging/android/ion
: 2a55e7b5e544 ("staging: android: ion: Call dma_map_sg for syncing and
mapping")
Signed-off-by: Liam Mark
---
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/i
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/include/linux/dma-buf.h b/include/linux
Some stability changes to improve ION robustness and a perf related
change to make it easier for clients to avoid unnecessary cache
maintenance, such as when buffers are clean and haven't had any CPU
access.
Liam Mark (4):
staging: android: ion: Support cpu access during dma_buf_detach
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 :-)
> >>>
> >>> On Tue, Jan 15, 2019 at 12:4
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 10:38 AM, Andrew F. Davis wrote:
> >>>> On 1/
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, Andrew F. Davis wrote:
> >>> On 1/15/19 11:45 AM, L
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 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 from the CPU to a cached heap should
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 maintenance should not be needed anyway.
>
> Signed-off-by: Andrew F. Davis
>
On Tue, 18 Dec 2018, Alexey Skidanov wrote:
> >>> I was wondering if we could re-open the discussion on adding support to
> >>> ION for dma_buf_vmap.
> >>> It seems like the patch was not taken as the reviewers wanted more
> >>> evidence of an upstream use case.
> >>>
> >>> Here would be my
On Sun, 16 Dec 2018, Alexey Skidanov wrote:
>
>
> On 12/16/18 7:20 AM, Liam Mark wrote:
> > On Tue, 6 Feb 2018, Alexey Skidanov wrote:
> >
> >>
> >>
> >> On 02/07/2018 01:56 AM, Laura Abbott wrote:
> >>> On 01/31/2018 10:10 PM, Alexe
On Tue, 6 Feb 2018, Alexey Skidanov wrote:
>
>
> On 02/07/2018 01:56 AM, Laura Abbott wrote:
> > On 01/31/2018 10:10 PM, Alexey Skidanov wrote:
> >>
> >> On 01/31/2018 03:00 PM, Greg KH wrote:
> >>> On Wed, Jan 31, 2018 at 02:03:42PM +0200, Alexey Skidanov wrote:
> Any driver may access
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
> &g
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
> &g
where there is minimal CPU access
and therefore uncached memory performs better.
Signed-off-by: Liam Mark <lm...@codeaurora.org>
---
drivers/staging/android/ion/ion.c | 16
drivers/staging/android/ion/ion.h | 5 -
drivers/staging/andro
where there is minimal CPU access
and therefore uncached memory performs better.
Signed-off-by: Liam Mark
---
drivers/staging/android/ion/ion.c | 16
drivers/staging/android/ion/ion.h | 5 -
drivers/staging/android/ion/ion_cma_heap.c| 3
Fix the dup_sg_table function to initialize the dma_address of the new
sg list entries instead of the source dma_address entries.
Since ION duplicates the sg_list this issue does not appear to result in
an actual bug.
Signed-off-by: Liam Mark <lm...@codeaurora.org>
Acked-by: Laura Abbott
Fix the dup_sg_table function to initialize the dma_address of the new
sg list entries instead of the source dma_address entries.
Since ION duplicates the sg_list this issue does not appear to result in
an actual bug.
Signed-off-by: Liam Mark
Acked-by: Laura Abbott
---
Changes in v2:
- Add
On Fri, 16 Feb 2018, Greg KH wrote:
> On Fri, Feb 09, 2018 at 10:16:56PM -0800, Liam Mark wrote:
> > Fix the dup_sg_table function to initialize the dma_address of the new
> > sg list entries instead of the source dma_address entries.
> >
> > Fixes: 17fd283f3
On Fri, 16 Feb 2018, Greg KH wrote:
> On Fri, Feb 09, 2018 at 10:16:56PM -0800, Liam Mark wrote:
> > Fix the dup_sg_table function to initialize the dma_address of the new
> > sg list entries instead of the source dma_address entries.
> >
> > Fixes: 17fd283f3
On Thu, 15 Feb 2018, Laura Abbott wrote:
> On 02/12/2018 01:25 PM, Liam Mark wrote:
> >
> > On Mon, 12 Feb 2018, Dan Carpenter wrote:
> >
> > > On Fri, Feb 09, 2018 at 10:16:56PM -0800, Liam Mark wrote:
> > > > Fix the dup_sg_table function to initia
On Thu, 15 Feb 2018, Laura Abbott wrote:
> On 02/12/2018 01:25 PM, Liam Mark wrote:
> >
> > On Mon, 12 Feb 2018, Dan Carpenter wrote:
> >
> > > On Fri, Feb 09, 2018 at 10:16:56PM -0800, Liam Mark wrote:
> > > > Fix the dup_sg_table function to initia
On Mon, 12 Feb 2018, Laura Abbott wrote:
> On 02/09/2018 10:21 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.
> >
> > Curren
On Mon, 12 Feb 2018, Laura Abbott wrote:
> On 02/09/2018 10:21 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.
> >
> > Curren
On Mon, 12 Feb 2018, Dan Carpenter wrote:
> On Fri, Feb 09, 2018 at 10:16:56PM -0800, Liam Mark wrote:
> > Fix the dup_sg_table function to initialize the dma_address of the new
> > sg list entries instead of the source dma_address entries.
> >
> > Fixes: 17fd283f3
On Mon, 12 Feb 2018, Dan Carpenter wrote:
> On Fri, Feb 09, 2018 at 10:16:56PM -0800, Liam Mark wrote:
> > Fix the dup_sg_table function to initialize the dma_address of the new
> > sg list entries instead of the source dma_address entries.
> >
> > Fixes: 17fd283f3
pping")
Signed-off-by: Liam Mark <lm...@codeaurora.org>
---
drivers/staging/android/ion/ion.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index f480885e346b..e5df5272823d 1006
pping")
Signed-off-by: Liam Mark
---
drivers/staging/android/ion/ion.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index f480885e346b..e5df5272823d 100644
--- a/drivers/staging/android
Fix the dup_sg_table function to initialize the dma_address of the new
sg list entries instead of the source dma_address entries.
Fixes: 17fd283f3870 ("staging: android: ion: Duplicate sg_table")
Signed-off-by: Liam Mark <lm...@codeaurora.org>
---
drivers/staging/android/ion/ion.
Fix the dup_sg_table function to initialize the dma_address of the new
sg list entries instead of the source dma_address entries.
Fixes: 17fd283f3870 ("staging: android: ion: Duplicate sg_table")
Signed-off-by: Liam Mark
---
drivers/staging/android/ion/ion.c | 2 +-
1 file changed, 1
("staging: android: ion: Use CMA APIs directly")
Signed-off-by: Liam Mark <lm...@codeaurora.org>
---
Changes in v2:
- Clean up the commit message.
- Add 'Fixes:'
Changes in v3:
- Add support for highmem pages
drivers/staging/android/ion/ion_cma_heap.c | 17 +
1 f
("staging: android: ion: Use CMA APIs directly")
Signed-off-by: Liam Mark
---
Changes in v2:
- Clean up the commit message.
- Add 'Fixes:'
Changes in v3:
- Add support for highmem pages
drivers/staging/android/ion/ion_cma_heap.c | 17 +
1 file changed, 17 inser
On Wed, 24 Jan 2018, Laura Abbott wrote:
> On 01/22/2018 09:46 AM, Liam Mark wrote:
> > Since commit 204f672255c2 ("staging: android: ion: Use CMA APIs directly")
> > the CMA API is now used directly and therefore the allocated memory is no
> > longer automatica
On Wed, 24 Jan 2018, Laura Abbott wrote:
> On 01/22/2018 09:46 AM, Liam Mark wrote:
> > Since commit 204f672255c2 ("staging: android: ion: Use CMA APIs directly")
> > the CMA API is now used directly and therefore the allocated memory is no
> > longer automatica
("staging: android: ion: Use CMA APIs directly")
Signed-off-by: Liam Mark <lm...@codeaurora.org>
---
Changes in v2:
- Clean up the commit message.
- Add 'Fixes:'
drivers/staging/android/ion/ion_cma_heap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/and
("staging: android: ion: Use CMA APIs directly")
Signed-off-by: Liam Mark
---
Changes in v2:
- Clean up the commit message.
- Add 'Fixes:'
drivers/staging/android/ion/ion_cma_heap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/android/ion/ion_cma_heap.c
b/dri
On Sat, 20 Jan 2018, Greg KH wrote:
> On Fri, Jan 19, 2018 at 11:16:47AM -0800, Liam Mark wrote:
> > Since the CMA API is now used directly the allocated memory is no longer
> > automatically zeroed.
> >
> > Explicitly zero CMA allocated memory to ensure that no data
On Sat, 20 Jan 2018, Greg KH wrote:
> On Fri, Jan 19, 2018 at 11:16:47AM -0800, Liam Mark wrote:
> > Since the CMA API is now used directly the allocated memory is no longer
> > automatically zeroed.
> >
> > Explicitly zero CMA allocated memory to ensure that no data
On Fri, 19 Jan 2018, Dan Carpenter wrote:
> On Fri, Jan 19, 2018 at 11:16:47AM -0800, Liam Mark wrote:
> > Since the CMA API is now used directly the allocated memory is no longer
> > automatically zeroed.
> >
> > Explicitly zero CMA allocated memory to ens
On Fri, 19 Jan 2018, Dan Carpenter wrote:
> On Fri, Jan 19, 2018 at 11:16:47AM -0800, Liam Mark wrote:
> > Since the CMA API is now used directly the allocated memory is no longer
> > automatically zeroed.
> >
> > Explicitly zero CMA allocated memory to ens
Since the CMA API is now used directly the allocated memory is no longer
automatically zeroed.
Explicitly zero CMA allocated memory to ensure that no data is exposed
to userspace.
Change-Id: I08e143707a0d31610821a7f16826c262bf3c1999
Signed-off-by: Liam Mark <lm...@codeaurora.org>
---
d
Since the CMA API is now used directly the allocated memory is no longer
automatically zeroed.
Explicitly zero CMA allocated memory to ensure that no data is exposed
to userspace.
Change-Id: I08e143707a0d31610821a7f16826c262bf3c1999
Signed-off-by: Liam Mark
---
drivers/staging/android/ion
61 matches
Mail list logo
