From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <78df3ccd94cc441e3047a7698e43398b@hamnavoe.com> To: 9fans@9fans.net From: Richard Miller <9fans@hamnavoe.com> Date: Thu, 25 Jul 2019 11:02:06 +0100 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Raspberry Pi 4 Topicbox-Message-UUID: 024cf484-eada-11e9-9d60-3106f5b1d025 > no, i wish. only reading linux source and deciphering device tree > mazes. :( Supposedly a h/w manual is being edited now. > i think theres a bug with the dma code tho. you actually need to > invalidate caches *AFTER* the hw completed because the > core can speculatively prefetch memory and bring it into the > cache before the hardware is done writing memory. iirc the > code just cleans/invalidates BEFORE issuing the dma operation. I fixed this a long time ago, but you might have missed it because I call cachedinvse in the device drivers after return from dmawait, instead of doing it in the dma code itself. 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. Anyway this doesn't seem relevant for ether4330 because I get the same trouble using pio instead of dma.