ARMv7中CONFIG_ARM_DMA_MEM_BUFFERABLE的疑问

lyl19

回复 19# arm-linux-gcc

Hi
请查看我板子中几个寄存器的设置sctlr.tre==1，我其实也觉得PRRR，NMRR的设定是不是有问题。

1. PRRR: 0xa81a8; 0000 0000 0000 1010 1000 0001 1010 1000
    NMRR:0x40e040e0： 0100 0000 1110 0000 0100 0000 1110 0000
pgprot_kernel:
0x45f TXE[0],C,B=(1,1,1)
PRRR[15:14]=10, NORMAL
NMRR[15:14]=01, cache, write-back, write-alloc

__pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_BUFFERABLE | L_PTE_XN)
0x647 TXE[0],C,B=(1,0,1)
PRRR[11:10]=00, strang order
NMRR[11:10]=00, noncache

__pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_UNCACHED | L_PTE_XN)
0x643 TXE[0],C,B=(1,0,0)
PRRR[9:8]=01, device
NMRR[9:8]=00, noncache

Thanks

lyl19

回复 20# asuka2001

Hi askua

你的解释非常重要，我其实也想过在有memory barrier的情况下，coherent memory应该用normal+noncache，于是我尝试过把它变成normal+noncache，但是不幸的是，在其它地方出现了kenrel crash，我也没有深入的去检查。
所以说，可以这样认为，在ARM_DMA_MEM_BUFFERABLE使能的情况下，coherent memory应该是normal+noncache，因为mb保证了normal属性的顺序性。这个时候我们把它映射成device, strong order也可以，因为只要是mb存在。但估计这个三种内存可能有性能上的差异。

所以我的第二个问题：
如果去掉ARM_DMA_MEM_BUFFERABLE，io操作没有mb了，即使这段内存被映射成strong order的，还是安全的吗？我们可以设想这在ARMv5等老的CPU应该是安全的，但ARMv7还是安全的吗？

希望两位还是去看一下DDI0406C_arm_architecture_reference_manua中A3.8， Figure A3-5，上面明确说明strong order可以保证对它的访问的顺序及完成，但如果是对normal的内存访问和对strong order的访问在一起，并不能保证顺序的。
如果说某个IO操作的数据依赖于前一个内存访问，而前一个内存访问是normal的，这样的driver还是安全的吗？

我个人觉得对于armv7，ARM_DMA_MEM_BUFFERABLE是强制使能的，也就是IO操作的mb是强制要求的。

Thanks
Roger



   

arm-linux-gcc

首先TEX[0]是为1，有宏定义#define PMD_SECT_WBWA                (PMD_SECT_TEX(1) | PMD_SECT_CACHEABLE | PMD_SECT_BUFFERABLE)

关闭CONFIG_ARM_DMA_MEM_BUFFERABLE
#define pgprot_dmacoherent(prot) \
        __pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_UNCACHED | L_PTE_XN)
得到TEX[0]=1  C=0  B=0

打开CONFIG_ARM_DMA_MEM_BUFFERABLE
#define pgprot_dmacoherent(prot) \
        __pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_BUFFERABLE | L_PTE_XN)
得到TEX[0]  C  B的值为1 0 1

proc-v7-2level.S里面有定义
.equ        PRRR,        0xff0a81a8
.equ        NMRR,        0x40e040e0

于是TEX[0]为1、C为0、B为0时，所以会选择PRRR[8:9]，根据上面定义得到PRRR[8:9]是01
于是TEX[0]为1、C为0、B为1时，所以会选择PRRR[11:10]，根据上面定义得到PRRR[11:10]是00

406C手册上，1680页最下面
00 Strongly-ordered.
01 Device.
10 Normal Memory.
11 Reserved, effect is UNPREDICTABLE.

所以打开CONFIG_ARM_DMA_MEM_BUFFERABLE时是device memory
关闭打开CONFIG_ARM_DMA_MEM_BUFFERABLE时是strong order memory


所以device memory时，iowrite32和writel的定义中的__iowmb的实际定义为dsb，这个dsb可以保证write buffer中的数据完全写入内存之后再执行后面的指令，
也就是打开CONFIG_ARM_DMA_MEM_BUFFERABLE时屏障是不能少的，否则数据可能还在write buffer中；
而strong order时，__iowmb是个空定义，因为uncache+unbuffer，不经过write buffer，所以此时无需dsb。
dsb花的时间比较久，我记得write buffer这个FIFO有几十个字节，所以你在打开CONFIG_ARM_DMA_MEM_BUFFERABLE的情况下关掉屏障会使得性能提高，但是数据却不能保持一致了


关闭CONFIG_ARM_DMA_MEM_BUFFERABLE时，smp的各个core就是直接访问内存了，就存在更多的总线竞争，就有更多时间在等待了（见前面的回帖，memset的那个例子），所以性能是低于打开CONFIG_ARM_DMA_MEM_BUFFERABLE时

而在老的单核系统中，由于只有一个core，所以竞争就只会存在cpu gpu dma之间，cpu应该是优先使用总线的，所以单核系统中关闭CONFIG_ARM_DMA_MEM_BUFFERABLE是没问题的

lyl19

Hi
请再检查一下，

所以打开CONFIG_ARM_DMA_MEM_BUFFERABLE时是device memory
关闭打开CONFIG_ARM_DMA_MEM_BUFFERABLE时是strong order memory

根据你的PRRR, 和TXE, CB，不是这样的啊，按你的计算出来，和我的计算是一致的。打开对应的是strong order，关闭对应的是device。

另外
“所以你关掉屏障会使得性能提高，但是数据却不能保持一致了”，不是说strong order=uncache+unbuffer吗？为什么去掉dsb后，数据不能保持一致了。

asuka2001

回复 22# lyl19

引入这个 patch的原因："mapping memory with differing types results in unpredictable behaviour"

我认为是因为如下：

http://archive.arm.linux.org.uk/ ... 18.d6854bd5.en.html

Subject: [RFC] Prohibit ioremap() on kernel managed RAM

ARMv6 and above have a restriction whereby aliasing virtual:physical
mappings must not have differing memory type and sharability
attributes. Strictly, this covers the memory type (strongly ordered,
device, memory), cache attributes (uncached, write combine, write
through, write back read alloc, write back write alloc) and the
shared bit.

因此作为一般的内核页面，由于已经被映射为 normal，自然不允许再次映射为 device or strongly ordered！

asuka2001

回复 22# lyl19

coherent memory应该是normal+noncache，因为mb保证了normal属性的顺序性。

NO，mb()保证的不是 normal memory的顺序性。

dma coherence buffer内的数据写入顺序其实我们不关心。我们关心的是当 buffer提交给设备做 DMA时，必须让数据对设备可见！

这里采用的方式是间接的，在 writel()中添加 wmb()强制要求后面对设备寄存器的写入发生前，drain write buffer，把数据刷到主存中！

设备 DMA完后，readl()是同理的！但是这种方式只适用于大多数硬件。

arm-linux-gcc

重新看我23楼的回帖，我编辑了一下，之前描述的不够好
下班了，晚上继续扯

lyl19

回复 26# asuka2001


    同意你的观点，dsb不仅是保证顺序，还要保证完成性。

arm-linux-gcc

dmb
dsb
isb
总共3种层次的order，dma这种数据完整性肯定是用dsb的
如果不考虑完整性只考虑先后的话用dmb就可以了

lyl19

回复 25# asuka2001

好，那我们先解决这个问题。
我确实也有看到说，一块内存要是被映射成两个不同的属性，则会出问题，会丢掉一些属性啥的。

但从目前的映射来看，这块内存被映射的是device或者strong order，它也没出什么问题啊。

另外，arm-linux-gcc, 请再查看一下，你的映射关系好像弄错了。

Thanks