hc
2024-12-19 9370bb92b2d16684ee45cf24e879c93c509162da
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
What:        /sys/firmware/acpi/bgrt/
Date:        January 2012
Contact:    Matthew Garrett <mjg@redhat.com>
Description:
       The BGRT is an ACPI 5.0 feature that allows the OS
       to obtain a copy of the firmware boot splash and
       some associated metadata. This is intended to be used
       by boot splash applications in order to interact with
       the firmware boot splash in order to avoid jarring
       transitions.
 
       image: The image bitmap. Currently a 32-bit BMP.
       status: 1 if the image is valid, 0 if firmware invalidated it.
       type: 0 indicates image is in BMP format.
 
       ======== ===================================================
       version: The version of the BGRT. Currently 1.
       xoffset: The number of pixels between the left of the screen
            and the left edge of the image.
       yoffset: The number of pixels between the top of the screen
            and the top edge of the image.
       ======== ===================================================
 
What:        /sys/firmware/acpi/hotplug/
Date:        February 2013
Contact:    Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
       There are separate hotplug profiles for different classes of
       devices supported by ACPI, such as containers, memory modules,
       processors, PCI root bridges etc.  A hotplug profile for a given
       class of devices is a collection of settings defining the way
       that class of devices will be handled by the ACPI core hotplug
       code.  Those profiles are represented in sysfs as subdirectories
       of /sys/firmware/acpi/hotplug/.
 
       The following setting is available to user space for each
       hotplug profile:
 
       ======== =======================================================
       enabled: If set, the ACPI core will handle notifications of
            hotplug events associated with the given class of
            devices and will allow those devices to be ejected with
            the help of the _EJ0 control method.  Unsetting it
            effectively disables hotplug for the correspoinding
            class of devices.
       ======== =======================================================
 
       The value of the above attribute is an integer number: 1 (set)
       or 0 (unset).  Attempts to write any other values to it will
       cause -EINVAL to be returned.
 
What:        /sys/firmware/acpi/interrupts/
Date:        February 2008
Contact:    Len Brown <lenb@kernel.org>
Description:
       All ACPI interrupts are handled via a single IRQ,
       the System Control Interrupt (SCI), which appears
       as "acpi" in /proc/interrupts.
 
       However, one of the main functions of ACPI is to make
       the platform understand random hardware without
       special driver support.  So while the SCI handles a few
       well known (fixed feature) interrupts sources, such
       as the power button, it can also handle a variable
       number of a "General Purpose Events" (GPE).
 
       A GPE vectors to a specified handler in AML, which
       can do a anything the BIOS writer wants from
       OS context.  GPE 0x12, for example, would vector
       to a level or edge handler called _L12 or _E12.
       The handler may do its business and return.
       Or the handler may send send a Notify event
       to a Linux device driver registered on an ACPI device,
       such as a battery, or a processor.
 
       To figure out where all the SCI's are coming from,
       /sys/firmware/acpi/interrupts contains a file listing
       every possible source, and the count of how many
       times it has triggered::
 
         $ cd /sys/firmware/acpi/interrupts
         $ grep . *
         error:         0
         ff_gbl_lock:         0   enable
         ff_pmtimer:         0  invalid
         ff_pwr_btn:         0   enable
         ff_rt_clk:         2  disable
         ff_slp_btn:         0  invalid
         gpe00:         0    invalid
         gpe01:         0     enable
         gpe02:       108     enable
         gpe03:         0    invalid
         gpe04:         0    invalid
         gpe05:         0    invalid
         gpe06:         0     enable
         gpe07:         0     enable
         gpe08:         0    invalid
         gpe09:         0    invalid
         gpe0A:         0    invalid
         gpe0B:         0    invalid
         gpe0C:         0    invalid
         gpe0D:         0    invalid
         gpe0E:         0    invalid
         gpe0F:         0    invalid
         gpe10:         0    invalid
         gpe11:         0    invalid
         gpe12:         0    invalid
         gpe13:         0    invalid
         gpe14:         0    invalid
         gpe15:         0    invalid
         gpe16:         0    invalid
         gpe17:      1084     enable
         gpe18:         0     enable
         gpe19:         0    invalid
         gpe1A:         0    invalid
         gpe1B:         0    invalid
         gpe1C:         0    invalid
         gpe1D:         0    invalid
         gpe1E:         0    invalid
         gpe1F:         0    invalid
         gpe_all:      1192
         sci:          1194
         sci_not:         0
 
       ===========  ==================================================
       sci         The number of times the ACPI SCI
                has been called and claimed an interrupt.
 
       sci_not         The number of times the ACPI SCI
                has been called and NOT claimed an interrupt.
 
       gpe_all         count of SCI caused by GPEs.
 
       gpeXX         count for individual GPE source
 
       ff_gbl_lock  Global Lock
 
       ff_pmtimer   PM Timer
 
       ff_pwr_btn   Power Button
 
       ff_rt_clk    Real Time Clock
 
       ff_slp_btn   Sleep Button
 
       error         an interrupt that can't be accounted for above.
 
       invalid      it's either a GPE or a Fixed Event that
                doesn't have an event handler.
 
       disable         the GPE/Fixed Event is valid but disabled.
 
       enable       the GPE/Fixed Event is valid and enabled.
       ===========  ==================================================
 
       Root has permission to clear any of these counters.  Eg.::
 
         # echo 0 > gpe11
 
       All counters can be cleared by clearing the total "sci"::
 
         # echo 0 > sci
 
       None of these counters has an effect on the function
       of the system, they are simply statistics.
 
       Besides this, user can also write specific strings to these files
       to enable/disable/clear ACPI interrupts in user space, which can be
       used to debug some ACPI interrupt storm issues.
 
       Note that only writing to VALID GPE/Fixed Event is allowed,
       i.e. user can only change the status of runtime GPE and
       Fixed Event with event handler installed.
 
       Let's take power button fixed event for example, please kill acpid
       and other user space applications so that the machine won't shutdown
       when pressing the power button::
 
         # cat ff_pwr_btn
         0    enabled
         # press the power button for 3 times;
         # cat ff_pwr_btn
         3    enabled
         # echo disable > ff_pwr_btn
         # cat ff_pwr_btn
         3    disabled
         # press the power button for 3 times;
         # cat ff_pwr_btn
         3    disabled
         # echo enable > ff_pwr_btn
         # cat ff_pwr_btn
         4    enabled
         /*
          * this is because the status bit is set even if the enable
          * bit is cleared, and it triggers an ACPI fixed event when
          * the enable bit is set again
          */
         # press the power button for 3 times;
         # cat ff_pwr_btn
         7    enabled
         # echo disable > ff_pwr_btn
         # press the power button for 3 times;
         # echo clear > ff_pwr_btn    /* clear the status bit */
         # echo disable > ff_pwr_btn
         # cat ff_pwr_btn
         7    enabled