Message-ID: <79eb70f6-00b0-2939-5ec9-65e196ab4987@ti.com>
Date:   Tue, 15 Jan 2019 09:44:06 -0600
From:   "Andrew F. Davis" <afd@...com>
To:     Liam Mark <lmark@...eaurora.org>
CC:     Laura Abbott <labbott@...hat.com>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Arve Hjønnevåg <arve@...roid.com>,
        <devel@...verdev.osuosl.org>, <linux-kernel@...r.kernel.org>,
        <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on
 map/unmap

On 1/14/19 11:13 AM, Liam Mark wrote:
> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
> 
>> Buffers may not be mapped from the CPU so skip cache maintenance here.
>> Accesses from the CPU to a cached heap should be bracketed with
>> {begin,end}_cpu_access calls so maintenance should not be needed anyway.
>>
>> Signed-off-by: Andrew F. Davis <afd@...com>
>> ---
>>  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 14e48f6eb734..09cb5a8e2b09 100644
>> --- a/drivers/staging/android/ion/ion.c
>> +++ b/drivers/staging/android/ion/ion.c
>> @@ -261,8 +261,8 @@ static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
>>  
>>  	table = a->table;
>>  
>> -	if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
>> -			direction))
>> +	if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
>> +			      direction, DMA_ATTR_SKIP_CPU_SYNC))
> 
> Unfortunately I don't think you can do this for a couple reasons.
> You can't rely on {begin,end}_cpu_access calls to do cache maintenance.
> If the calls to {begin,end}_cpu_access were made before the call to 
> dma_buf_attach then there won't have been a device attached so the calls 
> to {begin,end}_cpu_access won't have done any cache maintenance.
> 

That should be okay though, if you have no attachments (or all
attachments are IO-coherent) then there is no need for cache
maintenance. Unless you mean a sequence where a non-io-coherent device
is attached later after data has already been written. Does that
sequence need supporting? DMA-BUF doesn't have to allocate the backing
memory until map_dma_buf() time, and that should only happen after all
the devices have attached so it can know where to put the buffer. So we
shouldn't expect any CPU access to buffers before all the devices are
attached and mapped, right?

> Also ION no longer provides DMA ready memory, so if you are not doing CPU 
> access then there is no requirement (that I am aware of) for you to call 
> {begin,end}_cpu_access before passing the buffer to the device and if this 
> buffer is cached and your device is not IO-coherent then the cache maintenance
> in ion_map_dma_buf and ion_unmap_dma_buf is required.
> 

If I am not doing any CPU access then why do I need CPU cache
maintenance on the buffer?

Andrew

>>  		return ERR_PTR(-ENOMEM);
>>  
>>  	return table;
>> @@ -272,7 +272,8 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
>>  			      struct sg_table *table,
>>  			      enum dma_data_direction direction)
>>  {
>> -	dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
>> +	dma_unmap_sg_attrs(attachment->dev, table->sgl, table->nents,
>> +			   direction, DMA_ATTR_SKIP_CPU_SYNC);
>>  }
>>  
>>  static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
>> -- 
>> 2.19.1
>>
>> _______________________________________________
>> devel mailing list
>> devel@...uxdriverproject.org
>> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
>>
> 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Powered by blists - more mailing lists