From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <BB93560F2D01BD14E5D6511F61088E49@felloff.net>
Date: Thu, 25 Jul 2019 13:19:32 +0200
From: cinap_lenrek@felloff.net
To: 9fans@9fans.net
In-Reply-To: 78df3ccd94cc441e3047a7698e43398b@hamnavoe.com
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Raspberry Pi 4
Topicbox-Message-UUID: 02c43292-eada-11e9-9d60-3106f5b1d025

> Your dmaflush code doesn't look to me like it will do the right
> thing if the dma buffer isn't cache aligned.  (Could this ever be
> the case in the 9front kernel?) Suppose dma starts, cpu prefetches
> some old data into the cache line overlapping the start of the dma
> buffer, then dma completes.

> Your dmaflush then calls cachedwbse which writes back the pre-fetched
> data, overwriting the new data which dma wrote to memory.

what? where? it should call dmaflush with the clean parameter set
to zero after the hardware has completed the dma:

dma.c:228: 		dmaflush(0, ctlr->flush, ctlr->len);

dmaflush() then calls cachedwbinvse() on the partial cache lines
which should just invalidate IFF the lines are clean. the write back should
only happen when the lines are dirty. in that case the damage has already
been done and the wb at least makes sure we wont loose the dirty data
from the cache.

so the underlying assumption here is that a cache clean operation
writes back only when the line is dirty. correct me if i'm wrong
here.

so yes, it will not work correctly for an invalidate when the buffer
is not cache line size aligned and the partial start or end gets
modified while the dma operation is in flight.

--
cinap