What to do with rtems_cache_disable_data()?

[Peter Dufault]

> On Jun 14, 2024, at 5:47 AM, Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
> 
> Hello,
> 
> an user noticed that for example on the Xilinx Zynq 7000 BSP, the rtems_cache_disable_data() doesn't work.
> 
> I had a look at this and managed to disable the L1 and L2 caches, however, afterwards I got not that far. On the Cortex-A cores it seems at least the L1 data cache is required to provide support for atomic operations:
> 
> https://stackoverflow.com/questions/76207164/disabled-dcache-will-prevent-atomic-flag-from-being-set
> 
> I guess we have this situation on most modern chips with caches since the reservation granule is usually a cache line. How do we want to deal with rtems_cache_disable_data() in this case? From my point of view, this function as no real use case and adding it in the first place was a mistake.
> 
> We have a couple of options:
> 
> * Make the rtems_cache_disable_data() directive a no-operation. Afterwards the cache is still enabled, and an user may get confused.
> 
> * Issue a fatal error if someone calls rtems_cache_disable_data().
> 
> * Really disable the cache and let the user figure out that the atomic operations no longer work. Disabling the data cache can be a quite complex thing to do.
> 
> * Add a return status code to rtems_cache_disable_data() and let it return RTEMS_UNSATISFIED for example.

Assuming "this function has no real use case and adding it in the first place was a mistake" how about:

- In the active release continue to disable the data cache but add a warning attribute 'warning ("Disabling data cache breaks atomic functionality")';
- In the next release change it to an error attribute and change the function behavior to do nothing except return RTEMS_UNSATISFIED (in case someone somehow still calls it), or better change it to call an RTEMS fatal function.

Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering