diff options
| author | Yijie Yang <yijie.yang@oss.qualcomm.com> | 2026-08-11 16:46:47 +0800 |
|---|---|---|
| committer | Rob Herring (Arm) <robh@kernel.org> | 2026-08-15 15:46:52 -0500 |
| commit | e1c13aed4a1641550e8c9518c96f016e1d52d09b (patch) | |
| tree | 61c2297688373db165cc857b7c7adcb147a5c419 /Documentation/driver-api/firmware/introduction.rst | |
| download | linux-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.rst | 27 |
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. |
