summaryrefslogtreecommitdiffstats
path: root/Documentation/driver-api/firmware/introduction.rst
diff options
context:
space:
mode:
authorYijie Yang <yijie.yang@oss.qualcomm.com>2026-08-11 16:46:47 +0800
committerRob Herring (Arm) <robh@kernel.org>2026-08-15 15:46:52 -0500
commite1c13aed4a1641550e8c9518c96f016e1d52d09b (patch)
tree61c2297688373db165cc857b7c7adcb147a5c419 /Documentation/driver-api/firmware/introduction.rst
downloadlinux-stable-e1c13aed4a1641550e8c9518c96f016e1d52d09b.tar.gz
linux-stable-e1c13aed4a1641550e8c9518c96f016e1d52d09b.zip
dt-bindings: interconnect: qcom-bwmon: Add Maili cpu-bwmon compatiblegrafted
Add the Qualcomm Maili SoC compatible string for the CPU bandwidth monitor (BWMONv4). This falls back to the sdm845-bwmon compatible, consistent with the existing pattern used by other recent SoCs such as sm8750 and kaanapali. Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Link: https://patch.msgid.link/20260811-bwmon-v2-1-80f7f150ab9e@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Diffstat (limited to 'Documentation/driver-api/firmware/introduction.rst')
-rw-r--r--Documentation/driver-api/firmware/introduction.rst27
1 files changed, 27 insertions, 0 deletions
diff --git a/Documentation/driver-api/firmware/introduction.rst b/Documentation/driver-api/firmware/introduction.rst
new file mode 100644
index 000000000..211cb44eb
--- /dev/null
+++ b/Documentation/driver-api/firmware/introduction.rst
@@ -0,0 +1,27 @@
+============
+Introduction
+============
+
+The firmware API enables kernel code to request files required
+for functionality from userspace, the uses vary:
+
+* Microcode for CPU errata
+* Device driver firmware, required to be loaded onto device
+ microcontrollers
+* Device driver information data (calibration data, EEPROM overrides),
+ some of which can be completely optional.
+
+Types of firmware requests
+==========================
+
+There are two types of calls:
+
+* Synchronous
+* Asynchronous
+
+Which one you use vary depending on your requirements, the rule of thumb
+however is you should strive to use the asynchronous APIs unless you also
+are already using asynchronous initialization mechanisms which will not
+stall or delay boot. Even if loading firmware does not take a lot of time
+processing firmware might, and this can still delay boot or initialization,
+as such mechanisms such as asynchronous probe can help supplement drivers.