diff options
author | Jonathan Herman <hermanjl@cs.unc.edu> | 2013-01-17 16:15:55 -0500 |
---|---|---|
committer | Jonathan Herman <hermanjl@cs.unc.edu> | 2013-01-17 16:15:55 -0500 |
commit | 8dea78da5cee153b8af9c07a2745f6c55057fe12 (patch) | |
tree | a8f4d49d63b1ecc92f2fddceba0655b2472c5bd9 /Documentation/firmware_class/README | |
parent | 406089d01562f1e2bf9f089fd7637009ebaad589 (diff) |
Patched in Tegra support.
Diffstat (limited to 'Documentation/firmware_class/README')
-rw-r--r-- | Documentation/firmware_class/README | 38 |
1 files changed, 9 insertions, 29 deletions
diff --git a/Documentation/firmware_class/README b/Documentation/firmware_class/README index 43fada989e6..7eceaff63f5 100644 --- a/Documentation/firmware_class/README +++ b/Documentation/firmware_class/README | |||
@@ -18,45 +18,32 @@ | |||
18 | High level behavior (mixed): | 18 | High level behavior (mixed): |
19 | ============================ | 19 | ============================ |
20 | 20 | ||
21 | 1), kernel(driver): | 21 | kernel(driver): calls request_firmware(&fw_entry, $FIRMWARE, device) |
22 | - calls request_firmware(&fw_entry, $FIRMWARE, device) | 22 | |
23 | - kernel searchs the fimware image with name $FIRMWARE directly | 23 | userspace: |
24 | in the below search path of root filesystem: | ||
25 | User customized search path by module parameter 'path'[1] | ||
26 | "/lib/firmware/updates/" UTS_RELEASE, | ||
27 | "/lib/firmware/updates", | ||
28 | "/lib/firmware/" UTS_RELEASE, | ||
29 | "/lib/firmware" | ||
30 | - If found, goto 7), else goto 2) | ||
31 | |||
32 | [1], the 'path' is a string parameter which length should be less | ||
33 | than 256, user should pass 'firmware_class.path=$CUSTOMIZED_PATH' | ||
34 | if firmware_class is built in kernel(the general situation) | ||
35 | |||
36 | 2), userspace: | ||
37 | - /sys/class/firmware/xxx/{loading,data} appear. | 24 | - /sys/class/firmware/xxx/{loading,data} appear. |
38 | - hotplug gets called with a firmware identifier in $FIRMWARE | 25 | - hotplug gets called with a firmware identifier in $FIRMWARE |
39 | and the usual hotplug environment. | 26 | and the usual hotplug environment. |
40 | - hotplug: echo 1 > /sys/class/firmware/xxx/loading | 27 | - hotplug: echo 1 > /sys/class/firmware/xxx/loading |
41 | 28 | ||
42 | 3), kernel: Discard any previous partial load. | 29 | kernel: Discard any previous partial load. |
43 | 30 | ||
44 | 4), userspace: | 31 | userspace: |
45 | - hotplug: cat appropriate_firmware_image > \ | 32 | - hotplug: cat appropriate_firmware_image > \ |
46 | /sys/class/firmware/xxx/data | 33 | /sys/class/firmware/xxx/data |
47 | 34 | ||
48 | 5), kernel: grows a buffer in PAGE_SIZE increments to hold the image as it | 35 | kernel: grows a buffer in PAGE_SIZE increments to hold the image as it |
49 | comes in. | 36 | comes in. |
50 | 37 | ||
51 | 6), userspace: | 38 | userspace: |
52 | - hotplug: echo 0 > /sys/class/firmware/xxx/loading | 39 | - hotplug: echo 0 > /sys/class/firmware/xxx/loading |
53 | 40 | ||
54 | 7), kernel: request_firmware() returns and the driver has the firmware | 41 | kernel: request_firmware() returns and the driver has the firmware |
55 | image in fw_entry->{data,size}. If something went wrong | 42 | image in fw_entry->{data,size}. If something went wrong |
56 | request_firmware() returns non-zero and fw_entry is set to | 43 | request_firmware() returns non-zero and fw_entry is set to |
57 | NULL. | 44 | NULL. |
58 | 45 | ||
59 | 8), kernel(driver): Driver code calls release_firmware(fw_entry) releasing | 46 | kernel(driver): Driver code calls release_firmware(fw_entry) releasing |
60 | the firmware image and any related resource. | 47 | the firmware image and any related resource. |
61 | 48 | ||
62 | High level behavior (driver code): | 49 | High level behavior (driver code): |
@@ -119,10 +106,3 @@ | |||
119 | on the setup, so I think that the choice on what firmware to make | 106 | on the setup, so I think that the choice on what firmware to make |
120 | persistent should be left to userspace. | 107 | persistent should be left to userspace. |
121 | 108 | ||
122 | about firmware cache: | ||
123 | -------------------- | ||
124 | After firmware cache mechanism is introduced during system sleep, | ||
125 | request_firmware can be called safely inside device's suspend and | ||
126 | resume callback, and callers need't cache the firmware by | ||
127 | themselves any more for dealing with firmware loss during system | ||
128 | resume. | ||