threeeye
bc1d038eac
Squashed backup commit (no shallow-clone history issues) of xiaomi-mt6833-dev/kernel_xiaomi_mt6833 (lineage-23.2 branch, upstream commit 9eece662e) plus all fixes applied to get everpal_defconfig building clean against a modern (GCC 15.2.0) toolchain -- see the previous commit message on the lineage-23.2 branch (also in this repo history is not available here since this is a squashed snapshot; full incremental history lives in the local DL380 checkout and the upstream GitHub remote). Upstream: https://github.com/xiaomi-mt6833-dev/kernel_xiaomi_mt6833 (lineage-23.2)
28 lines
935 B
ReStructuredText
28 lines
935 B
ReStructuredText
============
|
|
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.
|