STM32 Cortex-M33, such as the L5/H5/U5 series, have a cache peripheral for
instruction and data caches, which are not present in the C-M33
architecture spec.
The driver defaults to direct mapped cache as it uses less power than the
alternative set associative mapping [1]. This has also been the default in
stm32 soc initialization code for chips that have the ICACHE peripheral,
which makes it the safest choice for backward compatibility. The exception
to the rule is STM32L5, which has the n-way cache mode selected in SOC
code.
[1]: https://en.wikipedia.org/wiki/Cache_placement_policies
Signed-off-by: Henrik Lindblom <henrik.lindblom@vaisala.com>
This adds a few line use zephyr_syscall_header() to include
headers containing syscall function prototypes.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Following 4806e1087e ,
the following warning appears for some boards (e.g. `qemu_cortex_a53`)
```
CMake Warning at /zephyr/CMakeLists.txt:798 (message):
No SOURCES given to Zephyr library: drivers__cache
Excluding target from build.
```
Allow this driver to have no sources.
Signed-off-by: Henri Xavier <datacomos@huawei.com>
When a cache API function is called from userspace, this results on
ARM64 in an OOPS (bad syscall error). This is due to at least two
different factors:
- the location of the cache handlers is preventing the linker to
actually find the handlers
- specifically for ARM64 and ARC some cache handling functions are not
implemented (when userspace is not used the compiler simply optimizes
out these calls)
Fix the problem by:
- moving the userspace cache handlers to a their logical and proper
location (in the drivers directory)
- adding the missing handlers for ARM64 and ARC
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
The CPU in Aspeed AST10x0 SOC is a ARM Cortex-M4 which doesn't internal
cache memory. Aspeed implements an integrated system level cache to
accelerate instruction and data memory accesses.
Signed-off-by: Dylan Hung <dylan_hung@aspeedtech.com>
The cache API currently shipped in Zephyr is assuming that the cache
controller is always on-core thus managed at the arch level. This is not
always the case because many SoCs rely on external cache controllers as
a peripheral external to the core (for example PL310 cache controller
and the L2Cxxx family). In some cases you also want a single driver to
control a whole set of cache controllers.
Rework the cache code introducing support for external cache
controllers.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
