As U-Boot works to align itself with upstream devicetrees, there are
some common issues we start to run into, that of hardware blocks which
might be important for an OS like Linux, but which aren't useful in
U-Boot.
To offer an example: Qualcomm platforms feature a Resource Power Manager
(RPM(h)) co-processor, it can opportunistically ramp down rails and
clocks based on usage. This necessitates placing votes on these
resources for every peripheral that uses them, and as a result means
that many peripherals that we want to use in U-Boot contain references
to the RPMh clock controller. However, we don't actually need to do this
in the context of U-Boot, this is mostly something an OS would care
about.
With CONFIG_OF_LIVE it would be possible to dynamically remove such
references (we could for example add a "bootph-os" property to indicate
that the device should be ignored by U-Boot). However OF_LIVE is not
available on all boards, and is only available post-relocation. This
approach would also require adding a new DT property for every
arch/platform/board that we want to ignore.
We could instead try to handle this at the driver level, but this
becomes intractable when trying to scale across all of the drivers and
for all of the supported hardware generations. It also complicates thing
if we actually want/need to use this previously optional resource in the
future.
== The stub approach ==
The approach taken with this series is instead to allow for a stub
driver to be defined per-uclass, with the clock subsystem being the
first user. This stub driver is used as a fall back in the case where a
driver requests a device of a specific type (such as a clock controller)
and where no other driver binds to the node.
This solution allows us to immediately solve this issue for Qualcomm
platforms, and for any other architectures with similar issues. An
obvious next step is to do the same for optional power-domain
controllers.
Another benefit to this approach is that it is easy to introspect, the
stub drivers will show up in "dm tree". So the case of forgetting to
enable a driver will be much more obvious than if we tried to find the
clock, failed, and just did nothing.
== Future expansion ==
The exact scope of the stub driver (when it should match, how it should
behave) obviously depends heavily on the uclass, as such I think it
should be up to the subsystem maintainers.
An obvious next choice would be the power domain uclass. The current
architecture of U-Boot requires either disabling CONFIG_POWER_DOMAIN,
supporting every single power domain controller on your platform, or
adding DM_FLAG_DEFAULT_PD_CTRL_OFF to a bunch of drivers.
---
Caleb Connolly (2):
dm: core: add support for fallback drivers
clk: introduce a fallback stub driver
drivers/clk/Makefile | 1 +
drivers/clk/clk-fallback.c | 39 +++++++++++++++++++++++++++++++++++++++
drivers/clk/clk-uclass.c | 4 ++++
drivers/core/Kconfig | 20 ++++++++++++++++++++
drivers/core/uclass.c | 24 +++++++++++++++++++++++-
include/dm/uclass.h | 3 +++
6 files changed, 90 insertions(+), 1 deletion(-)
---
change-id: 20240410-b4-stub-drivers-1c1565bb06a6
base-commit: 56c4a3aa2ed15b64eabd067a10be2091d28a5f2f
// Caleb (they/them)
