From: Caleb Connolly <caleb.connolly@linaro.org>
To: Simon Glass <sjg@chromium.org>, Tom Rini <trini@konsulko.com>,
Lukasz Majewski <lukma@denx.de>,
Sean Anderson <seanga2@gmail.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Sumit Garg <sumit.garg@linaro.org>,
u-boot-qcom@groups.io, u-boot@lists.denx.de,
Caleb Connolly <caleb.connolly@linaro.org>
Subject: [PATCH 0/2] dm: add support for stubbing optional devices
Date: Wed, 10 Apr 2024 19:06:56 +0200 [thread overview]
Message-ID: <20240410-b4-stub-drivers-v1-0-6935bd2c07d1@linaro.org> (raw)
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)
next reply other threads:[~2024-04-10 17:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-10 17:06 Caleb Connolly [this message]
2024-04-10 17:06 ` [PATCH 1/2] dm: core: add support for fallback drivers Caleb Connolly
2024-04-10 17:27 ` Heinrich Schuchardt
2024-04-10 19:44 ` Tom Rini
2024-04-11 2:37 ` Sean Anderson
2024-05-03 15:53 ` Caleb Connolly
2024-05-03 21:18 ` Tom Rini
2024-05-03 16:10 ` Caleb Connolly
2024-04-10 17:06 ` [PATCH 2/2] clk: introduce a fallback stub driver Caleb Connolly
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240410-b4-stub-drivers-v1-0-6935bd2c07d1@linaro.org \
--to=caleb.connolly@linaro.org \
--cc=ilias.apalodimas@linaro.org \
--cc=lukma@denx.de \
--cc=neil.armstrong@linaro.org \
--cc=seanga2@gmail.com \
--cc=sjg@chromium.org \
--cc=sumit.garg@linaro.org \
--cc=trini@konsulko.com \
--cc=u-boot-qcom@groups.io \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).