________________________________________
发件人: Mark Brown [broonie(a)linaro.org]
发送时间: 2014年5月8日 16:41
收件人: Panshilin (Peter)
抄送: Alex Shi; Guodong Xu; Haojian Zhuang; linaro-kernel(a)lists.linaro.org
主题: Re: help:a issue about arm64 dma coherent Re: Is this patch included in LSK April release
On Wed, May 07, 2014 at 09:38:57AM +0000, Panshilin (Peter) wrote:
> we use arm64 dma_alloc_coherent to get a expected non-cacheable
> buffer. but when we use the buffer as a dma memory for device, after
> cpu write datas to the buffer, It is not coherent in ddr so that
> device cann't get proper datas. so we find the LSK current version's
> dma alloc is malfunctional.
> we have to flushcacheall after cpu write datas and It is ok. It shows
> that dma_alloc_coherent doesn't work properly.
Yes, this is the case. The code in mainline didn't work at the time the
last release was made and as only models were available for testing this
code could not be verified in LSK at that time. This should be resolved
in the 14.05 release.
From: Mark Brown <broonie(a)linaro.org>
Since newer DT bindings include references to include/dt-bindings we need
to make this available to build DTs using them. Upstream has a number of
reworkings which are much more invasive but featureful, just include a
minimal fix.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
scripts/Makefile.lib | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index f97869f1f09b..c4b37f6b5478 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -152,6 +152,7 @@ ld_flags = $(LDFLAGS) $(ldflags-y)
dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc \
-I$(srctree)/arch/$(SRCARCH)/boot/dts \
-I$(srctree)/arch/$(SRCARCH)/boot/dts/include \
+ -I$(srctree)/include \
-undef -D__DTS__
# Finds the multi-part object the current object will be linked into
--
2.0.0.rc2
Implement and enable context tracking for arm64 (which is
a prerequisite for FULL_NOHZ support). This patchset
builds upon earlier work by Kevin Hilman and is based on 3.15-rc2.
Larry Bassel (2):
arm64: adjust el0_sync so that a function can be called
arm64: enable context tracking
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/thread_info.h | 1 +
arch/arm64/kernel/entry.S | 36 +++++++++++++++++++++++++++++++-----
3 files changed, 33 insertions(+), 5 deletions(-)
--
1.8.3.2
Dear All:
we use arm64 dma_alloc_coherent to get a expected non-cacheable buffer. but when we use the buffer as a dma memory for device, after cpu write datas to the buffer, It is not coherent in ddr so that device cann't get proper datas. so we find the LSK current version's dma alloc is malfunctional.
we have to flushcacheall after cpu write datas and It is ok. It shows that dma_alloc_coherent doesn't work properly.
thanks
Peter
________________________________________
发件人: Alex Shi [alex.shi(a)linaro.org]
发送时间: 2014年5月7日 12:06
收件人: Panshilin (Peter); Mark Brown; Guodong Xu; Haojian Zhuang
主题: Re: 答复: 答复: Is this patch included in LSK April release
CC to guodong.
Peter,
I am not MM experts. So could you like to give bit more detailed info of
your concern?
I did find not any abuse of flush_cache_all in arm64 code.
And AFAIK, If you have no a *hardware* cache coherency unit for DMA
access, do you? kernel need to flush(inv) cache lines which involved.
but don't need to flush all. Flush range of involved address is fine.
Did you try this?
On 05/06/2014 05:10 PM, Panshilin (Peter) wrote:
> we verified the patch based on linaro lsk April release and it didn't work .now we have to call flush cache all before start dma transfer. obviously it is not ok for dma coherent function in LSK. Please solve this issue as soon as you can. urgency, thanks .
> ________________________________________
> 发件人: Alex Shi [alex.shi(a)linaro.org]
> 发送时间: 2014年5月6日 10:08
> 收件人: Panshilin (Peter); Mark Brown
> 主题: Re: 答复: Is this patch included in LSK April release
>
>> On 05/05/2014 03:18 PM, Panshilin (Peter) wrote:
>>> de2db74 arm64: Make DMA coherent and strongly ordered mappings not
>
> Peter, did you try the patch in your hardware? Does it work?
>
> --
> Thanks
> Alex
>
--
Thanks
Alex