The constraints API offered by TI HAL is meant to be used externally,
for example, when implementing a policy using their policy mechanism
(not used on Zephyr). The API is likely designed for systems where a
thin RTOS is used (e.g., FreeRTOS, TI-RTOS?), places where you basically
get a Kernel and a few services around, but not a system like Zephyr
where you also get, for example, a power management subsystem. This
means that it gets difficult for an RTOS like Zephyr to use such HAL
APIs while using its own constraints API. The first question is why we
allowed such kind of HAL code to be part of upstream Zephyr. It
certainly does useful things, but it is also uses a HAL infrastructure
which is hardly exportable to an RTOS like Zephyr. Part of the
Power_init() code, for example, should likely be in a clock controller
driver, where Zephyr APIs can be used.
The _solution_ that was done to workaround this case was allowing custom
full re-implementations of the constraints API. So we are basically
overwriting a functional API with custom HAL code because of poor HAL
designs. This is in general a bad design principle. If we allow this, we
can hardly offer any guarantees to the API users. For example, is
re-implemented as thread-safe? What is the API behavior then? ...
Platforms like TI that have incomplete support in Zephyr tend to leverage
to HAL code certain functions that should be proper Zephyr
drivers. Such platforms should not influence the design of APIs because
they lack solid foundations.
This patch removes the custom implementation since the HAL has been
patched so that it forwards PM state constraints to Zephyr.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
bb40e38527