On 12/07/2016 05:16 PM, Justin Chen wrote:
From: Justin Chen <justin.chen@xxxxxxxxxxxx>
Add cacheinfo support for MIPS architectures.
Use information from the cpuinfo_mips struct to populate the
cacheinfo struct. This allows an architecture agnostic approach,
however this also means if cache information is not properly
populated within the cpuinfo_mips struct, there is nothing
we can do. (I.E. c-r3k.c)
Justin, for architecture agnostic approach of work with caches the
cpuinfo_mips lacks more information:
1. L1I-L1D coherency status (is L1I coherent to L1D)
2. L1D-L2 coherency status (is L1D coherent to L2)
3. L1I-L2 coherency status (is L1I coherent to L2)
4. L1I refill from L1D (snoops L1D) or L2 (may require L1D flush)?
5. L1D cache aliasing disabled by HW
6. L1I cache aliasing disabled by HW
7. Barrier existence and it's type between various cache flushes as is
as between cache flush and final (completed) state.
8. Cache ownership (current: assumed that sibling CPUs share L1 - may
be shared_cpu_map?)
9. Is address cache flush operation global in system or pure local?
10. Is index cache flush operation global in system or pure local?
Without that the proposed cpuinfo_mips struct is basically useless.
Regards,
- Leonid
