Fishwaldo opened a new pull request, #20064:
URL: https://github.com/apache/nuttx/pull/20064
## Summary
The EIC7700X is not cache coherent. No device that moves data on its own
snoops the harts' caches or is snooped by them, so software has to maintain
the cache around every transfer. These cores have no Zicbom, so there is no
instruction that can do it: maintenance is a store to the L3 controller
carrying the physical address of a cache block. This implements the
`up_*_dcache` interface on top of that.
That store is the only operation the hardware has, and it writes back and
invalidates together, so a block cannot be dropped without being written out
first. Two consequences, documented at the top of the file:
- a range being invalidated must own whole 64-byte blocks, which
`up_invalidate_dcache()` asserts, or a shared end block written back during
a transfer lands on top of what the device delivered
- cleaning has no alignment requirement, so a transmit buffer can sit
anywhere
The L3 is inclusive of the L1 data cache and back invalidates it, so one
store
per block maintains the whole hierarchy with nothing to do per hart. The
three
`up_*_dcache_all()` entry points are a fence for that reason: no whole
hierarchy operation exists, naming every block would be fifteen and a half
million stores, and the harts are coherent with each other so only ordering
is
left to do.
## Why now
Nothing in tree calls this yet. It is a prerequisite for the EIC7700X eMMC
and
SD driver, which follows in its own PR and cannot use its DMA engine without
it, and any future Ethernet or USB driver on this SoC inherits the same
rules.
It is split out because it is independent of that driver and reviewable on
its
own.
## Testing
Built with `-Wno-cpp -Werror` for `eic7700-evb:nsh`, and booted on the ESWIN
EIC7700 EVB as part of the integration branch, where the storage driver
exercises it on every transfer: eMMC and SD both enumerate, mount and read.
`tools/checkpatch.sh -c -u -m -g master..HEAD` passes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
