[EXT] Re: The problem about arm64: io: Relax implicit barriers in default I/O accessors

[Will Deacon]

On Mon, Jun 21, 2021 at 05:26:41PM +0100, Will Deacon wrote:
> On Mon, Jun 21, 2021 at 04:11:57PM +0000, Frank Li wrote:
> > > Oh, interesting. Maybe this is a case where OSH vs SY actually makes a
> > > difference. I'm not quite sure what it means for the coherency of normal,
> > > non-cacheable accesses (which are outer-shareable) so that probably needs a
> > > bit more thought.
> > > 
> > > Can you confirm that the issue *does* still occur if you use dmb(osh)
> > > instead of dmb(oshst), please?
> > 
> > After get ARM support https://services.arm.com/support/s/case/5003t00001RuJHw, 
> > This issue have some progress. 
> > 
> > Our system configure SYSBARDISABLE = 0x0, So ARM core barrier propagate to CCI-400
> > 
> > Our DMA and USB is located below downstream of CCI-400. So USB or DMA is located
> > in system shared domain. Only use dmb(st), CCI-400 wait for previous transaction
> > Complete. When dma(osh), the response is sent when snoop responses are received for
> > all earlier transactions. CCI-400 don't wait for previous write finish. 
> 
> Thanks for following up. I'll cook a patch to fix this...

... and in doing so, I realised I still have a question about this.

If a CPU is writing to a zero-initialised non-cacheable buffer in memory
and does something like:

	buffer[0] = 1;
	dma_wmb();	// DMB OSHST
	buffer[64] = 1;

would a non-coherent device reading this be able to see buffer[64] == 1
but buffer[0] = 0? In other words, do we need to upgrade the dmb_* barriers
as well as the I/O accessors, or are they still ordered by the bus fabric
because all of the accesses are going to the DDR?

Will