Commit | Line | Data |
---|---|---|
113ccc38 LR |
1 | ============ |
2 | Introduction | |
3 | ============ | |
4 | ||
5 | The firmware API enables kernel code to request files required | |
6 | for functionality from userspace, the uses vary: | |
7 | ||
8 | * Microcode for CPU errata | |
9 | * Device driver firmware, required to be loaded onto device | |
10 | microcontrollers | |
11 | * Device driver information data (calibration data, EEPROM overrides), | |
12 | some of which can be completely optional. | |
13 | ||
14 | Types of firmware requests | |
15 | ========================== | |
16 | ||
17 | There are two types of calls: | |
18 | ||
19 | * Synchronous | |
20 | * Asynchronous | |
21 | ||
22 | Which one you use vary depending on your requirements, the rule of thumb | |
23 | however is you should strive to use the asynchronous APIs unless you also | |
24 | are already using asynchronous initialization mechanisms which will not | |
25 | stall or delay boot. Even if loading firmware does not take a lot of time | |
26 | processing firmware might, and this can still delay boot or initialization, | |
27 | as such mechanisms such as asynchronous probe can help supplement drivers. |