[U-Boot] [PATCH v3] net/designware: make driver compatible with data cache

[Alexey Brodkin]

Hi Mischa,

On Wed, 2014-01-22 at 17:10 +0000, Mischa Jonker wrote:
> Hello Alexey,
> 
> In general, a very nice, clean patch.
> 
> > +	/* Flush modified buffer descriptor */
> > +	flush_dcache_range((unsigned long)desc_p,
> > +			   (unsigned long)desc_p + sizeof(struct dmamacdescr));
> > +
> 
> If I remember correctly, there is some bit that tells you if the DMA descriptor is owned by CPU or by GMAC. What if the descriptor size is smaller than the cache line size of the CPU? How do you prevent the CPU from overwriting adiacent DMA descriptors that may be owned by the GMAC?

Well, good point. It might happen with long cache line easily.

> As far as I can remember, in Linux they solve this by mapping the descriptors (not the packet buffers, these are always cacheline aligned) in uncached memory, but we cannot do that in u-boot as the MMU is still disabled. OTOH, as we may not need to have the performance benefits of the CPU and GMAC concurrently accessing the descriptor table, we may be able to work around it by handing off multiple descriptors at once from GMAC to CPU and vice versa (maybe depending on cache line size?). 

Frankly I don't see a point in trying to process few descriptors at
once. The only true failure safe scenario I may think of - CPU waits
until all descriptors are processed by GMAC and then CPU processes all
Tx or Rx descriptors. In this case CPU won't corrupt the next descriptor
used currently by CPU. But this approach will kill benefits of multiple
buffers - operation will become synchronous as if we have only 1 buffer
for Tx and one for Rx. Which might be a resolution but with penalty of
speed/time (which we don't want).

> I remember that a similar patch (that looked a lot uglier BTW) solved it by doing uncached accesses to the descriptors, but that would require using arch-specific accessor macro's (and I'm not sure if all architectures support an 'uncached access' attribute/flag with load/store instructions).

Word/byte-aligned uncached access is sweet but not universal - how many
arches have it?

As a summary - this problem is very generic (I saw other places like DW
MMC driver which use similar approach - flushing/invalidating buffer
descriptors) and without true uncached access (be it with means of MMU
or specific accessors without MMU) it's not clear how to act completely
fail-safe.

Might be we need just to add compile-time warning for cases when cache
line is longer than one unit of interest (buffer descriptor in our case)
so people at least will be informed and suggest to disable D$ for
starters.

-Alexey