mirror of
https://github.com/AetherDroid/android_kernel_samsung_on5xelte.git
synced 2025-09-06 00:17:46 -04:00
Fixed MTP to work with TWRP
This commit is contained in:
awab228
commit
f6dfaef42e
50820 changed files with 20846062 additions and 0 deletions
206
Documentation/ABI/testing/sysfs-firmware-acpi
Normal file
206
Documentation/ABI/testing/sysfs-firmware-acpi
Normal file
|
|
@ -0,0 +1,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/hotplug/force_remove
|
||||
Date: May 2013
|
||||
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
||||
Description:
|
||||
The number in this file (0 or 1) determines whether (1) or not
|
||||
(0) the ACPI subsystem will allow devices to be hot-removed even
|
||||
if they cannot be put offline gracefully (from the kernel's
|
||||
viewpoint). That number can be changed by writing a boolean
|
||||
value to this file.
|
||||
|
||||
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 writting 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
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue