ARMv7中CONFIG_ARM_DMA_MEM_BUFFERABLE的疑问

lyl19

Happy weekend guys, thanks for the help all the time.

Thanks

arm-linux-gcc

回复 30# lyl19


    我确实看错了，反了，让我再想一下

arm-linux-gcc

LZ尝试过其他都不变，将.equ        PRRR,        0xff0a81a8改为0xff0a84a8吗？

lyl19

回复 33# arm-linux-gcc


    我没有改这个，感觉改动太大了，要改我也是会改那块内存的映射关系, 我修改过使用device和strong order在都不带barrier的情况下跑throughput都正常，当然这里跑得正常并不能说就是正确的，也有可能是在这种场合下没有发生。

   另外我有个疑问：
  
“所以device memory时，iowrite32和writel的定义中的__iowmb的实际定义为dsb，这个dsb可以保证write buffer中的数据完全写入内存之后再执行后面的指令，
也就是打开CONFIG_ARM_DMA_MEM_BUFFERABLE时屏障是不能少的，否则数据可能还在write buffer中；
而strong order时，__iowmb是个空定义，因为uncache+unbuffer，不经过write buffer，所以此时无需dsb。”

device memory和strong order有bufferable的区别，然后决定了是否需要dsb，我觉得这个很重要，这个观点你确定吗，是在哪里看到的，能否帮忙指出来一下，反正在DDI0406C_arm_architecture_reference_manual没有说明device和strong order有bufferable的区别。


Thanks

arm-linux-gcc

回复 34# lyl19


    按照406C上说的，strong-order是不需要dsb的，因为不走write buffer经过；而device是需要dsb的

但是你不能只看pgprot_dmacoherent的定义，这东西只是用在dma_alloc_coherent上的；
另外还有pgprot_noncached（PS，他的定义和pgprot_stronglyordered相同），这个是用在ioremap时的；
还有pgprot_writecombine，这个是用在dma_alloc_writecombine时的。

所以直接修改PRRR的定义值，改动是最小的，只需要将0xff0a81a8改为0xff0a84a8，其他什么都不用改，就能够使得所有的pgprot_xxx与其字面意思对应上了

lyl19

谢谢你的回复。

"strong-order是不需要dsb的，因为不走write buffer经过；而device是需要dsb的", 这个你有印象吗，我有发下如下语句

spec中提到：
The only architecturally-required difference between Device and Strongly-ordered memory is that:
•a write to Strongly-ordered memory can complete only when it reaches the peripheral or memory component
accessed by the write
•a write to Device memory is permitted to complete before it reaches the peripheral or memory component
accessed by the write.

还有，为什么kernel都定义好的东西，我们这边还要修改它，是承认它有错误吗？
我查看了其它我们客户的SDK, 它们在ARM_DMA_MEM_BUFFERABLE使能的情况下，都是strong order并且barrier是使能的，所以我感觉这里的设置是没有问题的，不可能这些大厂商的SDK在这一块都出问题了吧。

Thanks

arm-linux-gcc

我问了ARM的人，TEX[0]是0，而不是1


That's for the software-only bits stored in the shadow pte at 2KB before
the actual hardware pte. The cpu_v7_set_pte_ext() function builds the
hardware pte based on the software bits and the TEX[0] bit is actually
bit 4 of the software PTE. The dirty bit causes the APX bit to be set
rather than TEX[0]. The armv6_mt_table macro in proc-marcos.S has an
explanation on how the dirty/young etc. bits get converted (though this
macro is only used for ARMv6).

lyl19

回复 37# arm-linux-gcc


    Hi arm-linux-gcc

Appreciate your explanation，you are excellent.

看了看cpu_v7_set_pte_ext，真是感觉拔云见日了, 真是没想到set_pte_ext是去设置linux pte而不是h/w pte。
所以说，通过linux pte到h/w pte映射，我们得到了如下映射

如果是以uncached去设置页表，(TEX,C,B)=(0,0,0), 这对应的是strong order，所以说IO操作不需要barrier
如果是以bufferable去设置页表，(TXE, C,B)=(0,0,1), 这对应的是normal+noncache, 所以说IO操作必须有barrier

这也是前面askua说bufferable应该映射成normal的原因，以及为什么我把ARM_DMA_MEM_BUFFERABLE关掉后，性能变差的原因(访问strong order显然比normal要消耗多)，同时也说明了我在ARM_DMA_MEM_BUFFERABLE打开的情况下，把barrier关掉是危险的，虽然性能得到提升，但其实只是问题没有发生罢了。

其实还不太想结贴，我还有两个疑问。
1. 如askua前面所说的，在DDI0406C文档中3.5.7节，
    “A physical memory location is accessed with mismatched attributes if all accesses to the location do not use a
common definition of all of the following attributes of that location..., 后面是这样操作的危害”
   如果我们使用strong order，那这里会不会有这个危险，因为最开始所有的内存在map_low的时候，都会被映射成normal，现在同样这段内存，我们又要映射成strong order，物理内存一样，不同的只是虚存而已，会不会存在这个问题呢？

2. 还是前面说的那个，在取消ARM_DMA_MEM_BUFFERABLE的情况下，IO操作将不带barrier, 在A3.8DDI0406C文档， Figure A3-5，明确说明对于normal, strong order的两个指令，不能保证其顺序性。
   我们在driver中，如果有如下指令
   int A=XX;
   A=LOAD(addr1).        //从normal内存中读出index, A=YY
  //rmb();
     write32(addr2, A).   //把这个index写入外设中，strong order类型memory。

我们知道现在write32已经不带有barrier了，那这里的rmb是不是也应该必须呢？不然会不会出现把XX而不是YY写入到外设中的情况呢？

Thanks

asuka2001

回复 38# lyl19


1. 见我22楼的回复，之所以引入 ARM_DMA_MEM_BUFFERABLE就是因为有可能造成不可预见的后果！

ARMv6 and above have a restriction whereby aliasing virtual:physical
mappings must not have differing memory type and sharability
attributes.

2. 这里没太明白你的意思。。。这里有什么顺序性问题？有 data denpendency在，指令不可能乱序，必然得先读到 A = YYY才能执行后面的写操作啊！

lyl19

回复 39# asuka2001

谢谢你的回复。
第一个问题，也就是说ARMv6以后的，就一定要把这个宏使能了，现在能懂你的意思了。

之所以问第二个问题，是因为前一段时间看了很多的多CPU之间使用barrier同步的问题(smp_mb..)，所以给我一个印象是指令间都是有可能乱序的，除了ARM spec提到的address dependency和control dependency。
然后你这里说了一个data dependency, 为什么ARM spec没有提到这一点，这个是一个最基本的保证吗？

Thanks