Merge branch 'master' into fixes
This commit is contained in:
Russell King
Коммит
4de3a8e101
|
|
@ -0,0 +1,75 @@
|
|||
What: /sys/bus/xen-backend/devices/*/devtype
|
||||
Date: Feb 2009
|
||||
KernelVersion: 2.6.38
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
The type of the device. e.g., one of: 'vbd' (block),
|
||||
'vif' (network), or 'vfb' (framebuffer).
|
||||
|
||||
What: /sys/bus/xen-backend/devices/*/nodename
|
||||
Date: Feb 2009
|
||||
KernelVersion: 2.6.38
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
XenStore node (under /local/domain/NNN/) for this
|
||||
backend device.
|
||||
|
||||
What: /sys/bus/xen-backend/devices/vbd-*/physical_device
|
||||
Date: April 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
The major:minor number (in hexidecimal) of the
|
||||
physical device providing the storage for this backend
|
||||
block device.
|
||||
|
||||
What: /sys/bus/xen-backend/devices/vbd-*/mode
|
||||
Date: April 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Whether the block device is read-only ('r') or
|
||||
read-write ('w').
|
||||
|
||||
What: /sys/bus/xen-backend/devices/vbd-*/statistics/f_req
|
||||
Date: April 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Number of flush requests from the frontend.
|
||||
|
||||
What: /sys/bus/xen-backend/devices/vbd-*/statistics/oo_req
|
||||
Date: April 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Number of requests delayed because the backend was too
|
||||
busy processing previous requests.
|
||||
|
||||
What: /sys/bus/xen-backend/devices/vbd-*/statistics/rd_req
|
||||
Date: April 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Number of read requests from the frontend.
|
||||
|
||||
What: /sys/bus/xen-backend/devices/vbd-*/statistics/rd_sect
|
||||
Date: April 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Number of sectors read by the frontend.
|
||||
|
||||
What: /sys/bus/xen-backend/devices/vbd-*/statistics/wr_req
|
||||
Date: April 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Number of write requests from the frontend.
|
||||
|
||||
What: /sys/bus/xen-backend/devices/vbd-*/statistics/wr_sect
|
||||
Date: April 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Number of sectors written by the frontend.
|
||||
|
|
@ -0,0 +1,77 @@
|
|||
What: /sys/devices/system/xen_memory/xen_memory0/max_retry_count
|
||||
Date: May 2011
|
||||
KernelVersion: 2.6.39
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
The maximum number of times the balloon driver will
|
||||
attempt to increase the balloon before giving up. See
|
||||
also 'retry_count' below.
|
||||
A value of zero means retry forever and is the default one.
|
||||
|
||||
What: /sys/devices/system/xen_memory/xen_memory0/max_schedule_delay
|
||||
Date: May 2011
|
||||
KernelVersion: 2.6.39
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
The limit that 'schedule_delay' (see below) will be
|
||||
increased to. The default value is 32 seconds.
|
||||
|
||||
What: /sys/devices/system/xen_memory/xen_memory0/retry_count
|
||||
Date: May 2011
|
||||
KernelVersion: 2.6.39
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
The current number of times that the balloon driver
|
||||
has attempted to increase the size of the balloon.
|
||||
The default value is one. With max_retry_count being
|
||||
zero (unlimited), this means that the driver will attempt
|
||||
to retry with a 'schedule_delay' delay.
|
||||
|
||||
What: /sys/devices/system/xen_memory/xen_memory0/schedule_delay
|
||||
Date: May 2011
|
||||
KernelVersion: 2.6.39
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
The time (in seconds) to wait between attempts to
|
||||
increase the balloon. Each time the balloon cannot be
|
||||
increased, 'schedule_delay' is increased (until
|
||||
'max_schedule_delay' is reached at which point it
|
||||
will use the max value).
|
||||
|
||||
What: /sys/devices/system/xen_memory/xen_memory0/target
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
The target number of pages to adjust this domain's
|
||||
memory reservation to.
|
||||
|
||||
What: /sys/devices/system/xen_memory/xen_memory0/target_kb
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
As target above, except the value is in KiB.
|
||||
|
||||
What: /sys/devices/system/xen_memory/xen_memory0/info/current_kb
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Current size (in KiB) of this domain's memory
|
||||
reservation.
|
||||
|
||||
What: /sys/devices/system/xen_memory/xen_memory0/info/high_kb
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Amount (in KiB) of high memory in the balloon.
|
||||
|
||||
What: /sys/devices/system/xen_memory/xen_memory0/info/low_kb
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Amount (in KiB) of low (or normal) memory in the
|
||||
balloon.
|
||||
|
|
@ -66,6 +66,24 @@ Description:
|
|||
re-discover previously removed devices.
|
||||
Depends on CONFIG_HOTPLUG.
|
||||
|
||||
What: /sys/bus/pci/devices/.../msi_irqs/
|
||||
Date: September, 2011
|
||||
Contact: Neil Horman <nhorman@tuxdriver.com>
|
||||
Description:
|
||||
The /sys/devices/.../msi_irqs directory contains a variable set
|
||||
of sub-directories, with each sub-directory being named after a
|
||||
corresponding msi irq vector allocated to that device. Each
|
||||
numbered sub-directory N contains attributes of that irq.
|
||||
Note that this directory is not created for device drivers which
|
||||
do not support msi irqs
|
||||
|
||||
What: /sys/bus/pci/devices/.../msi_irqs/<N>/mode
|
||||
Date: September 2011
|
||||
Contact: Neil Horman <nhorman@tuxdriver.com>
|
||||
Description:
|
||||
This attribute indicates the mode that the irq vector named by
|
||||
the parent directory is in (msi vs. msix)
|
||||
|
||||
What: /sys/bus/pci/devices/.../remove
|
||||
Date: January 2009
|
||||
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
|
||||
|
|
|
|||
|
|
@ -119,6 +119,31 @@ Description:
|
|||
Write a 1 to force the device to disconnect
|
||||
(equivalent to unplugging a wired USB device).
|
||||
|
||||
What: /sys/bus/usb/drivers/.../new_id
|
||||
Date: October 2011
|
||||
Contact: linux-usb@vger.kernel.org
|
||||
Description:
|
||||
Writing a device ID to this file will attempt to
|
||||
dynamically add a new device ID to a USB device driver.
|
||||
This may allow the driver to support more hardware than
|
||||
was included in the driver's static device ID support
|
||||
table at compile time. The format for the device ID is:
|
||||
idVendor idProduct bInterfaceClass.
|
||||
The vendor ID and device ID fields are required, the
|
||||
interface class is optional.
|
||||
Upon successfully adding an ID, the driver will probe
|
||||
for the device and attempt to bind to it. For example:
|
||||
# echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id
|
||||
|
||||
What: /sys/bus/usb-serial/drivers/.../new_id
|
||||
Date: October 2011
|
||||
Contact: linux-usb@vger.kernel.org
|
||||
Description:
|
||||
For serial USB drivers, this attribute appears under the
|
||||
extra bus folder "usb-serial" in sysfs; apart from that
|
||||
difference, all descriptions from the entry
|
||||
"/sys/bus/usb/drivers/.../new_id" apply.
|
||||
|
||||
What: /sys/bus/usb/drivers/.../remove_id
|
||||
Date: November 2009
|
||||
Contact: CHENG Renquan <rqcheng@smu.edu.sg>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,12 @@
|
|||
What: Attribute for calibrating ST-Ericsson AB8500 Real Time Clock
|
||||
Date: Oct 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Mark Godfrey <mark.godfrey@stericsson.com>
|
||||
Description: The rtc_calibration attribute allows the userspace to
|
||||
calibrate the AB8500.s 32KHz Real Time Clock.
|
||||
Every 60 seconds the AB8500 will correct the RTC's value
|
||||
by adding to it the value of this attribute.
|
||||
The range of the attribute is -127 to +127 in units of
|
||||
30.5 micro-seconds (half-parts-per-million of the 32KHz clock)
|
||||
Users: The /vendor/st-ericsson/base_utilities/core/rtc_calibration
|
||||
daemon uses this interface.
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
What: /sys/devices/platform/docg3/f[0-3]_dps[01]_is_keylocked
|
||||
Date: November 2011
|
||||
KernelVersion: 3.3
|
||||
Contact: Robert Jarzmik <robert.jarzmik@free.fr>
|
||||
Description:
|
||||
Show whether the floor (0 to 4), protection area (0 or 1) is
|
||||
keylocked. Each docg3 chip (or floor) has 2 protection areas,
|
||||
which can cover any part of it, block aligned, called DPS.
|
||||
The protection has information embedded whether it blocks reads,
|
||||
writes or both.
|
||||
The result is:
|
||||
0 -> the DPS is not keylocked
|
||||
1 -> the DPS is keylocked
|
||||
Users: None identified so far.
|
||||
|
||||
What: /sys/devices/platform/docg3/f[0-3]_dps[01]_protection_key
|
||||
Date: November 2011
|
||||
KernelVersion: 3.3
|
||||
Contact: Robert Jarzmik <robert.jarzmik@free.fr>
|
||||
Description:
|
||||
Enter the protection key for the floor (0 to 4), protection area
|
||||
(0 or 1). Each docg3 chip (or floor) has 2 protection areas,
|
||||
which can cover any part of it, block aligned, called DPS.
|
||||
The protection has information embedded whether it blocks reads,
|
||||
writes or both.
|
||||
The protection key is a string of 8 bytes (value 0-255).
|
||||
Entering the correct value toggle the lock, and can be observed
|
||||
through f[0-3]_dps[01]_is_keylocked.
|
||||
Possible values are:
|
||||
- 8 bytes
|
||||
Typical values are:
|
||||
- "00000000"
|
||||
- "12345678"
|
||||
Users: None identified so far.
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
What: /sys/module/hid_logitech/drivers/hid:logitech/<dev>/range.
|
||||
Date: July 2011
|
||||
KernelVersion: 3.2
|
||||
Contact: Michal Malý <madcatxster@gmail.com>
|
||||
Contact: Michal Malý <madcatxster@gmail.com>
|
||||
Description: Display minimum, maximum and current range of the steering
|
||||
wheel. Writing a value within min and max boundaries sets the
|
||||
range of the wheel.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,9 @@
|
|||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/quirks
|
||||
Date: November 2011
|
||||
Contact: Benjamin Tissoires <benjamin.tissoires@gmail.com>
|
||||
Description: The integer value of this attribute corresponds to the
|
||||
quirks actually in place to handle the device's protocol.
|
||||
When read, this attribute returns the current settings (see
|
||||
MT_QUIRKS_* in hid-multitouch.c).
|
||||
When written this attribute change on the fly the quirks, then
|
||||
the protocol to handle the device.
|
||||
|
|
@ -0,0 +1,135 @@
|
|||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/actual_profile
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The integer value of this attribute ranges from 0-4.
|
||||
When read, this attribute returns the number of the actual
|
||||
profile. This value is persistent, so its equivalent to the
|
||||
profile that's active when the device is powered on next time.
|
||||
When written, this file sets the number of the startup profile
|
||||
and the device activates this profile immediately.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/info
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns general data like firmware version.
|
||||
The data is 6 bytes long.
|
||||
This file is readonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/key_mask
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one deactivate certain keys like
|
||||
windows and application keys, to prevent accidental presses.
|
||||
Profile number for which this settings occur is included in
|
||||
written data. The data has to be 6 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_capslock
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
capslock key for a specific profile. Profile number is included
|
||||
in written data. The data has to be 6 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_easyzone
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
easyzone keys for a specific profile. Profile number is included
|
||||
in written data. The data has to be 65 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_function
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
function keys for a specific profile. Profile number is included
|
||||
in written data. The data has to be 41 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_macro
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the macro
|
||||
keys for a specific profile. Profile number is included in
|
||||
written data. The data has to be 35 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_media
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the media
|
||||
keys for a specific profile. Profile number is included in
|
||||
written data. The data has to be 29 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_thumbster
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
thumbster keys for a specific profile. Profile number is included
|
||||
in written data. The data has to be 23 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/last_set
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the time in secs since
|
||||
epoch in which the last configuration took place.
|
||||
The data has to be 20 bytes long.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/light
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the backlight intensity for
|
||||
a specific profile. Profile number is included in written data.
|
||||
The data has to be 10 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/macro
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one store macros with max 500
|
||||
keystrokes for a specific button for a specific profile.
|
||||
Button and profile numbers are included in written data.
|
||||
The data has to be 2083 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile and key to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/control
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one select which data from which
|
||||
profile will be read next. The data has to be 3 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/talk
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one trigger easyshift functionality
|
||||
from the host.
|
||||
The data has to be 16 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
|
@ -8,3 +8,15 @@ Contact: David Herrmann <dh.herrmann@googlemail.com>
|
|||
Description: Make it possible to set/get current led state. Reading from it
|
||||
returns 0 if led is off and 1 if it is on. Writing 0 to it
|
||||
disables the led, writing 1 enables it.
|
||||
|
||||
What: /sys/bus/hid/drivers/wiimote/<dev>/extension
|
||||
Date: August 2011
|
||||
KernelVersion: 3.2
|
||||
Contact: David Herrmann <dh.herrmann@googlemail.com>
|
||||
Description: This file contains the currently connected and initialized
|
||||
extensions. It can be one of: none, motionp, nunchuck, classic,
|
||||
motionp+nunchuck, motionp+classic
|
||||
motionp is the official Nintendo Motion+ extension, nunchuck is
|
||||
the official Nintendo Nunchuck extension and classic is the
|
||||
Nintendo Classic Controller extension. The motionp extension can
|
||||
be combined with the other two.
|
||||
|
|
|
|||
|
|
@ -15,9 +15,9 @@ Contact: linux-input@vger.kernel.org
|
|||
Description:
|
||||
Attribute group for control of the status LEDs and the OLEDs.
|
||||
This attribute group is only available for Intuos 4 M, L,
|
||||
and XL (with LEDs and OLEDs) and Cintiq 21UX2 (LEDs only).
|
||||
Therefore its presence implicitly signifies the presence of
|
||||
said LEDs and OLEDs on the tablet device.
|
||||
and XL (with LEDs and OLEDs) and Cintiq 21UX2 and Cintiq 24HD
|
||||
(LEDs only). Therefore its presence implicitly signifies the
|
||||
presence of said LEDs and OLEDs on the tablet device.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance
|
||||
Date: August 2011
|
||||
|
|
@ -41,16 +41,17 @@ Date: August 2011
|
|||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Writing to this file sets which one of the four (for Intuos 4)
|
||||
or of the right four (for Cintiq 21UX2) status LEDs is active (0..3).
|
||||
The other three LEDs on the same side are always inactive.
|
||||
or of the right four (for Cintiq 21UX2 and Cintiq 24HD) status
|
||||
LEDs is active (0..3). The other three LEDs on the same side are
|
||||
always inactive.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select
|
||||
Date: September 2011
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Writing to this file sets which one of the left four (for Cintiq 21UX2)
|
||||
status LEDs is active (0..3). The other three LEDs on the left are always
|
||||
inactive.
|
||||
Writing to this file sets which one of the left four (for Cintiq 21UX2
|
||||
and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on
|
||||
the left are always inactive.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/buttons_luminance
|
||||
Date: August 2011
|
||||
|
|
|
|||
|
|
@ -346,6 +346,10 @@ Description:
|
|||
number of objects per slab. If a slab cannot be allocated
|
||||
because of fragmentation, SLUB will retry with the minimum order
|
||||
possible depending on its characteristics.
|
||||
When debug_guardpage_minorder=N (N > 0) parameter is specified
|
||||
(see Documentation/kernel-parameters.txt), the minimum possible
|
||||
order is used and this sysfs entry can not be used to change
|
||||
the order at run time.
|
||||
|
||||
What: /sys/kernel/slab/cache/order_fallback
|
||||
Date: April 2008
|
||||
|
|
|
|||
|
|
@ -404,7 +404,7 @@
|
|||
/* SNDRV_CARDS: maximum number of cards supported by this module */
|
||||
static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX;
|
||||
static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR;
|
||||
static int enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP;
|
||||
static bool enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP;
|
||||
|
||||
/* definition of the chip-specific record */
|
||||
struct mychip {
|
||||
|
|
|
|||
|
|
@ -275,8 +275,8 @@ versions.
|
|||
If no 2.6.x.y kernel is available, then the highest numbered 2.6.x
|
||||
kernel is the current stable kernel.
|
||||
|
||||
2.6.x.y are maintained by the "stable" team <stable@kernel.org>, and are
|
||||
released as needs dictate. The normal release period is approximately
|
||||
2.6.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and
|
||||
are released as needs dictate. The normal release period is approximately
|
||||
two weeks, but it can be longer if there are no pressing problems. A
|
||||
security-related problem, instead, can cause a release to happen almost
|
||||
instantly.
|
||||
|
|
|
|||
|
|
@ -594,53 +594,44 @@ rmdir() will fail with it. From this behavior, pre_destroy() can be
|
|||
called multiple times against a cgroup.
|
||||
|
||||
int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
|
||||
struct task_struct *task)
|
||||
struct cgroup_taskset *tset)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called prior to moving a task into a cgroup; if the subsystem
|
||||
returns an error, this will abort the attach operation. If a NULL
|
||||
task is passed, then a successful result indicates that *any*
|
||||
unspecified task can be moved into the cgroup. Note that this isn't
|
||||
called on a fork. If this method returns 0 (success) then this should
|
||||
remain valid while the caller holds cgroup_mutex and it is ensured that either
|
||||
Called prior to moving one or more tasks into a cgroup; if the
|
||||
subsystem returns an error, this will abort the attach operation.
|
||||
@tset contains the tasks to be attached and is guaranteed to have at
|
||||
least one task in it.
|
||||
|
||||
If there are multiple tasks in the taskset, then:
|
||||
- it's guaranteed that all are from the same thread group
|
||||
- @tset contains all tasks from the thread group whether or not
|
||||
they're switching cgroups
|
||||
- the first task is the leader
|
||||
|
||||
Each @tset entry also contains the task's old cgroup and tasks which
|
||||
aren't switching cgroup can be skipped easily using the
|
||||
cgroup_taskset_for_each() iterator. Note that this isn't called on a
|
||||
fork. If this method returns 0 (success) then this should remain valid
|
||||
while the caller holds cgroup_mutex and it is ensured that either
|
||||
attach() or cancel_attach() will be called in future.
|
||||
|
||||
int can_attach_task(struct cgroup *cgrp, struct task_struct *tsk);
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
As can_attach, but for operations that must be run once per task to be
|
||||
attached (possibly many when using cgroup_attach_proc). Called after
|
||||
can_attach.
|
||||
|
||||
void cancel_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
|
||||
struct task_struct *task, bool threadgroup)
|
||||
struct cgroup_taskset *tset)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called when a task attach operation has failed after can_attach() has succeeded.
|
||||
A subsystem whose can_attach() has some side-effects should provide this
|
||||
function, so that the subsystem can implement a rollback. If not, not necessary.
|
||||
This will be called only about subsystems whose can_attach() operation have
|
||||
succeeded.
|
||||
|
||||
void pre_attach(struct cgroup *cgrp);
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
For any non-per-thread attachment work that needs to happen before
|
||||
attach_task. Needed by cpuset.
|
||||
succeeded. The parameters are identical to can_attach().
|
||||
|
||||
void attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
|
||||
struct cgroup *old_cgrp, struct task_struct *task)
|
||||
struct cgroup_taskset *tset)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called after the task has been attached to the cgroup, to allow any
|
||||
post-attachment activity that requires memory allocations or blocking.
|
||||
|
||||
void attach_task(struct cgroup *cgrp, struct task_struct *tsk);
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
As attach, but for operations that must be run once per task to be attached,
|
||||
like can_attach_task. Called before attach. Currently does not support any
|
||||
subsystem that might need the old_cgrp for every thread in the group.
|
||||
The parameters are identical to can_attach().
|
||||
|
||||
void fork(struct cgroup_subsy *ss, struct task_struct *task)
|
||||
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ Brief summary of control files.
|
|||
memory.failcnt # show the number of memory usage hits limits
|
||||
memory.memsw.failcnt # show the number of memory+Swap hits limits
|
||||
memory.max_usage_in_bytes # show max memory usage recorded
|
||||
memory.memsw.usage_in_bytes # show max memory+Swap usage recorded
|
||||
memory.memsw.max_usage_in_bytes # show max memory+Swap usage recorded
|
||||
memory.soft_limit_in_bytes # set/show soft limit of memory usage
|
||||
memory.stat # show various statistics
|
||||
memory.use_hierarchy # set/show hierarchical account enabled
|
||||
|
|
@ -410,8 +410,11 @@ memory.stat file includes following statistics
|
|||
cache - # of bytes of page cache memory.
|
||||
rss - # of bytes of anonymous and swap cache memory.
|
||||
mapped_file - # of bytes of mapped file (includes tmpfs/shmem)
|
||||
pgpgin - # of pages paged in (equivalent to # of charging events).
|
||||
pgpgout - # of pages paged out (equivalent to # of uncharging events).
|
||||
pgpgin - # of charging events to the memory cgroup. The charging
|
||||
event happens each time a page is accounted as either mapped
|
||||
anon page(RSS) or cache page(Page Cache) to the cgroup.
|
||||
pgpgout - # of uncharging events to the memory cgroup. The uncharging
|
||||
event happens each time a page is unaccounted from the cgroup.
|
||||
swap - # of bytes of swap usage
|
||||
inactive_anon - # of bytes of anonymous memory and swap cache memory on
|
||||
LRU list.
|
||||
|
|
|
|||
|
|
@ -127,7 +127,7 @@ in the bash (as said, 1000 is default), do:
|
|||
echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) \
|
||||
>ondemand/sampling_rate
|
||||
|
||||
show_sampling_rate_min:
|
||||
sampling_rate_min:
|
||||
The sampling rate is limited by the HW transition latency:
|
||||
transition_latency * 100
|
||||
Or by kernel restrictions:
|
||||
|
|
@ -140,8 +140,6 @@ HZ=100: min=200000us (200ms)
|
|||
The highest value of kernel and HW latency restrictions is shown and
|
||||
used as the minimum sampling rate.
|
||||
|
||||
show_sampling_rate_max: THIS INTERFACE IS DEPRECATED, DON'T USE IT.
|
||||
|
||||
up_threshold: defines what the average CPU usage between the samplings
|
||||
of 'sampling_rate' needs to be for the kernel to make a decision on
|
||||
whether it should increase the frequency. For example when it is set
|
||||
|
|
|
|||
|
|
@ -271,10 +271,10 @@ copies should go to:
|
|||
the linux-kernel list.
|
||||
|
||||
- If you are fixing a bug, think about whether the fix should go into the
|
||||
next stable update. If so, stable@kernel.org should get a copy of the
|
||||
patch. Also add a "Cc: stable@kernel.org" to the tags within the patch
|
||||
itself; that will cause the stable team to get a notification when your
|
||||
fix goes into the mainline.
|
||||
next stable update. If so, stable@vger.kernel.org should get a copy of
|
||||
the patch. Also add a "Cc: stable@vger.kernel.org" to the tags within
|
||||
the patch itself; that will cause the stable team to get a notification
|
||||
when your fix goes into the mainline.
|
||||
|
||||
When selecting recipients for a patch, it is good to have an idea of who
|
||||
you think will eventually accept the patch and get it merged. While it
|
||||
|
|
|
|||
|
|
@ -379,7 +379,7 @@ Your cooperation is appreciated.
|
|||
162 = /dev/smbus System Management Bus
|
||||
163 = /dev/lik Logitech Internet Keyboard
|
||||
164 = /dev/ipmo Intel Intelligent Platform Management
|
||||
165 = /dev/vmmon VMWare virtual machine monitor
|
||||
165 = /dev/vmmon VMware virtual machine monitor
|
||||
166 = /dev/i2o/ctl I2O configuration manager
|
||||
167 = /dev/specialix_sxctl Specialix serial control
|
||||
168 = /dev/tcldrv Technology Concepts serial control
|
||||
|
|
|
|||
|
|
@ -21,6 +21,10 @@ i.MX53 Smart Mobile Reference Design Board
|
|||
Required root node properties:
|
||||
- compatible = "fsl,imx53-smd", "fsl,imx53";
|
||||
|
||||
i.MX6 Quad SABRE Automotive Board
|
||||
i.MX6 Quad Armadillo2 Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6q-sabreauto", "fsl,imx6q";
|
||||
- compatible = "fsl,imx6q-arm2", "fsl,imx6q";
|
||||
|
||||
i.MX6 Quad SABRE Lite Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6q-sabrelite", "fsl,imx6q";
|
||||
|
|
|
|||
|
|
@ -0,0 +1,8 @@
|
|||
* Insignal's Exynos4210 based Origen evaluation board
|
||||
|
||||
Origen low-cost evaluation board is based on Samsung's Exynos4210 SoC.
|
||||
|
||||
Required root node properties:
|
||||
- compatible = should be one or more of the following.
|
||||
(a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
|
||||
(b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
* Samsung's Exynos4210 based SMDKV310 evaluation board
|
||||
|
||||
SMDKV310 evaluation board is based on Samsung's Exynos4210 SoC.
|
||||
|
||||
Required root node properties:
|
||||
- compatible = should be one or more of the following.
|
||||
(a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
|
||||
(b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
NVIDIA Tegra device tree bindings
|
||||
-------------------------------------------
|
||||
|
||||
Boards with the tegra20 SoC shall have the following properties:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible = "nvidia,tegra20";
|
||||
|
||||
Boards with the tegra30 SoC shall have the following properties:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible = "nvidia,tegra30";
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
C6X PLL Clock Controllers
|
||||
-------------------------
|
||||
|
||||
This is a first-cut support for the SoC clock controllers. This is still
|
||||
under development and will probably change as the common device tree
|
||||
clock support is added to the kernel.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: "ti,c64x+pll"
|
||||
May also have SoC-specific value to support SoC-specific initialization
|
||||
in the driver. One of:
|
||||
"ti,c6455-pll"
|
||||
"ti,c6457-pll"
|
||||
"ti,c6472-pll"
|
||||
"ti,c6474-pll"
|
||||
|
||||
- reg: base address and size of register area
|
||||
- clock-frequency: input clock frequency in hz
|
||||
|
||||
|
||||
Optional properties:
|
||||
|
||||
- ti,c64x+pll-bypass-delay: CPU cycles to delay when entering bypass mode
|
||||
|
||||
- ti,c64x+pll-reset-delay: CPU cycles to delay after PLL reset
|
||||
|
||||
- ti,c64x+pll-lock-delay: CPU cycles to delay after PLL frequency change
|
||||
|
||||
Example:
|
||||
|
||||
clock-controller@29a0000 {
|
||||
compatible = "ti,c6472-pll", "ti,c64x+pll";
|
||||
reg = <0x029a0000 0x200>;
|
||||
clock-frequency = <25000000>;
|
||||
|
||||
ti,c64x+pll-bypass-delay = <200>;
|
||||
ti,c64x+pll-reset-delay = <12000>;
|
||||
ti,c64x+pll-lock-delay = <80000>;
|
||||
};
|
||||
|
|
@ -0,0 +1,127 @@
|
|||
Device State Configuration Registers
|
||||
------------------------------------
|
||||
|
||||
TI C6X SoCs contain a region of miscellaneous registers which provide various
|
||||
function for SoC control or status. Details vary considerably among from SoC
|
||||
to SoC with no two being alike.
|
||||
|
||||
In general, the Device State Configuraion Registers (DSCR) will provide one or
|
||||
more configuration registers often protected by a lock register where one or
|
||||
more key values must be written to a lock register in order to unlock the
|
||||
configuration register for writes. These configuration register may be used to
|
||||
enable (and disable in some cases) SoC pin drivers, select peripheral clock
|
||||
sources (internal or pin), etc. In some cases, a configuration register is
|
||||
write once or the individual bits are write once. In addition to device config,
|
||||
the DSCR block may provide registers which which are used to reset peripherals,
|
||||
provide device ID information, provide ethernet MAC addresses, as well as other
|
||||
miscellaneous functions.
|
||||
|
||||
For device state control (enable/disable), each device control is assigned an
|
||||
id which is used by individual device drivers to control the state as needed.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: must be "ti,c64x+dscr"
|
||||
- reg: register area base and size
|
||||
|
||||
Optional properties:
|
||||
|
||||
NOTE: These are optional in that not all SoCs will have all properties. For
|
||||
SoCs which do support a given property, leaving the property out of the
|
||||
device tree will result in reduced functionality or possibly driver
|
||||
failure.
|
||||
|
||||
- ti,dscr-devstat
|
||||
offset of the devstat register
|
||||
|
||||
- ti,dscr-silicon-rev
|
||||
offset, start bit, and bitsize of silicon revision field
|
||||
|
||||
- ti,dscr-rmii-resets
|
||||
offset and bitmask of RMII reset field. May have multiple tuples if more
|
||||
than one ethernet port is available.
|
||||
|
||||
- ti,dscr-locked-regs
|
||||
possibly multiple tuples describing registers which are write protected by
|
||||
a lock register. Each tuple consists of the register offset, lock register
|
||||
offsset, and the key value used to unlock the register.
|
||||
|
||||
- ti,dscr-kick-regs
|
||||
offset and key values of two "kick" registers used to write protect other
|
||||
registers in DSCR. On SoCs using kick registers, the first key must be
|
||||
written to the first kick register and the second key must be written to
|
||||
the second register before other registers in the area are write-enabled.
|
||||
|
||||
- ti,dscr-mac-fuse-regs
|
||||
MAC addresses are contained in two registers. Each element of a MAC address
|
||||
is contained in a single byte. This property has two tuples. Each tuple has
|
||||
a register offset and four cells representing bytes in the register from
|
||||
most significant to least. The value of these four cells is the MAC byte
|
||||
index (1-6) of the byte within the register. A value of 0 means the byte
|
||||
is unused in the MAC address.
|
||||
|
||||
- ti,dscr-devstate-ctl-regs
|
||||
This property describes the bitfields used to control the state of devices.
|
||||
Each tuple describes a range of identical bitfields used to control one or
|
||||
more devices (one bitfield per device). The layout of each tuple is:
|
||||
|
||||
start_id num_ids reg enable disable start_bit nbits
|
||||
|
||||
Where:
|
||||
start_id is device id for the first device control in the range
|
||||
num_ids is the number of device controls in the range
|
||||
reg is the offset of the register holding the control bits
|
||||
enable is the value to enable a device
|
||||
disable is the value to disable a device (0xffffffff if cannot disable)
|
||||
start_bit is the bit number of the first bit in the range
|
||||
nbits is the number of bits per device control
|
||||
|
||||
- ti,dscr-devstate-stat-regs
|
||||
This property describes the bitfields used to provide device state status
|
||||
for device states controlled by the DSCR. Each tuple describes a range of
|
||||
identical bitfields used to provide status for one or more devices (one
|
||||
bitfield per device). The layout of each tuple is:
|
||||
|
||||
start_id num_ids reg enable disable start_bit nbits
|
||||
|
||||
Where:
|
||||
start_id is device id for the first device status in the range
|
||||
num_ids is the number of devices covered by the range
|
||||
reg is the offset of the register holding the status bits
|
||||
enable is the value indicating device is enabled
|
||||
disable is the value indicating device is disabled
|
||||
start_bit is the bit number of the first bit in the range
|
||||
nbits is the number of bits per device status
|
||||
|
||||
- ti,dscr-privperm
|
||||
Offset and default value for register used to set access privilege for
|
||||
some SoC devices.
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
device-state-config-regs@2a80000 {
|
||||
compatible = "ti,c64x+dscr";
|
||||
reg = <0x02a80000 0x41000>;
|
||||
|
||||
ti,dscr-devstat = <0>;
|
||||
ti,dscr-silicon-rev = <8 28 0xf>;
|
||||
ti,dscr-rmii-resets = <0x40020 0x00040000>;
|
||||
|
||||
ti,dscr-locked-regs = <0x40008 0x40004 0x0f0a0b00>;
|
||||
ti,dscr-devstate-ctl-regs =
|
||||
<0 12 0x40008 1 0 0 2
|
||||
12 1 0x40008 3 0 30 2
|
||||
13 2 0x4002c 1 0xffffffff 0 1>;
|
||||
ti,dscr-devstate-stat-regs =
|
||||
<0 10 0x40014 1 0 0 3
|
||||
10 2 0x40018 1 0 0 3>;
|
||||
|
||||
ti,dscr-mac-fuse-regs = <0x700 1 2 3 4
|
||||
0x704 5 6 0 0>;
|
||||
|
||||
ti,dscr-privperm = <0x41c 0xaaaaaaaa>;
|
||||
|
||||
ti,dscr-kick-regs = <0x38 0x83E70B13
|
||||
0x3c 0x95A4F1E0>;
|
||||
};
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
External Memory Interface
|
||||
-------------------------
|
||||
|
||||
The emifa node describes a simple external bus controller found on some C6X
|
||||
SoCs. This interface provides external busses with a number of chip selects.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: must be "ti,c64x+emifa", "simple-bus"
|
||||
- reg: register area base and size
|
||||
- #address-cells: must be 2 (chip-select + offset)
|
||||
- #size-cells: must be 1
|
||||
- ranges: mapping from EMIFA space to parent space
|
||||
|
||||
|
||||
Optional properties:
|
||||
|
||||
- ti,dscr-dev-enable: Device ID if EMIF is enabled/disabled from DSCR
|
||||
|
||||
- ti,emifa-burst-priority:
|
||||
Number of memory transfers after which the EMIF will elevate the priority
|
||||
of the oldest command in the command FIFO. Setting this field to 255
|
||||
disables this feature, thereby allowing old commands to stay in the FIFO
|
||||
indefinitely.
|
||||
|
||||
- ti,emifa-ce-config:
|
||||
Configuration values for each of the supported chip selects.
|
||||
|
||||
Example:
|
||||
|
||||
emifa@70000000 {
|
||||
compatible = "ti,c64x+emifa", "simple-bus";
|
||||
#address-cells = <2>;
|
||||
#size-cells = <1>;
|
||||
reg = <0x70000000 0x100>;
|
||||
ranges = <0x2 0x0 0xa0000000 0x00000008
|
||||
0x3 0x0 0xb0000000 0x00400000
|
||||
0x4 0x0 0xc0000000 0x10000000
|
||||
0x5 0x0 0xD0000000 0x10000000>;
|
||||
|
||||
ti,dscr-dev-enable = <13>;
|
||||
ti,emifa-burst-priority = <255>;
|
||||
ti,emifa-ce-config = <0x00240120
|
||||
0x00240120
|
||||
0x00240122
|
||||
0x00240122>;
|
||||
|
||||
flash@3,0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compatible = "cfi-flash";
|
||||
reg = <0x3 0x0 0x400000>;
|
||||
bank-width = <1>;
|
||||
device-width = <1>;
|
||||
partition@0 {
|
||||
reg = <0x0 0x400000>;
|
||||
label = "NOR";
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
This shows a flash chip attached to chip select 3.
|
||||
|
|
@ -0,0 +1,104 @@
|
|||
C6X Interrupt Chips
|
||||
-------------------
|
||||
|
||||
* C64X+ Core Interrupt Controller
|
||||
|
||||
The core interrupt controller provides 16 prioritized interrupts to the
|
||||
C64X+ core. Priority 0 and 1 are used for reset and NMI respectively.
|
||||
Priority 2 and 3 are reserved. Priority 4-15 are used for interrupt
|
||||
sources coming from outside the core.
|
||||
|
||||
Required properties:
|
||||
--------------------
|
||||
- compatible: Should be "ti,c64x+core-pic";
|
||||
- #interrupt-cells: <1>
|
||||
|
||||
Interrupt Specifier Definition
|
||||
------------------------------
|
||||
Single cell specifying the core interrupt priority level (4-15) where
|
||||
4 is highest priority and 15 is lowest priority.
|
||||
|
||||
Example
|
||||
-------
|
||||
core_pic: interrupt-controller@0 {
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
compatible = "ti,c64x+core-pic";
|
||||
};
|
||||
|
||||
|
||||
|
||||
* C64x+ Megamodule Interrupt Controller
|
||||
|
||||
The megamodule PIC consists of four interrupt mupliplexers each of which
|
||||
combine up to 32 interrupt inputs into a single interrupt output which
|
||||
may be cascaded into the core interrupt controller. The megamodule PIC
|
||||
has a total of 12 outputs cascading into the core interrupt controller.
|
||||
One for each core interrupt priority level. In addition to the combined
|
||||
interrupt sources, individual megamodule interrupts may be cascaded to
|
||||
the core interrupt controller. When an individual interrupt is cascaded,
|
||||
it is no longer handled through a megamodule interrupt combiner and is
|
||||
considered to have the core interrupt controller as the parent.
|
||||
|
||||
Required properties:
|
||||
--------------------
|
||||
- compatible: "ti,c64x+megamod-pic"
|
||||
- interrupt-controller
|
||||
- #interrupt-cells: <1>
|
||||
- reg: base address and size of register area
|
||||
- interrupt-parent: must be core interrupt controller
|
||||
- interrupts: This should have four cells; one for each interrupt combiner.
|
||||
The cells contain the core priority interrupt to which the
|
||||
corresponding combiner output is wired.
|
||||
|
||||
Optional properties:
|
||||
--------------------
|
||||
- ti,c64x+megamod-pic-mux: Array of 12 cells correspnding to the 12 core
|
||||
priority interrupts. The first cell corresponds to
|
||||
core priority 4 and the last cell corresponds to
|
||||
core priority 15. The value of each cell is the
|
||||
megamodule interrupt source which is MUXed to
|
||||
the core interrupt corresponding to the cell
|
||||
position. Allowed values are 4 - 127. Mapping for
|
||||
interrupts 0 - 3 (combined interrupt sources) are
|
||||
ignored.
|
||||
|
||||
Interrupt Specifier Definition
|
||||
------------------------------
|
||||
Single cell specifying the megamodule interrupt source (4-127). Note that
|
||||
interrupts mapped directly to the core with "ti,c64x+megamod-pic-mux" will
|
||||
use the core interrupt controller as their parent and the specifier will
|
||||
be the core priority level, not the megamodule interrupt number.
|
||||
|
||||
Examples
|
||||
--------
|
||||
megamod_pic: interrupt-controller@1800000 {
|
||||
compatible = "ti,c64x+megamod-pic";
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x1800000 0x1000>;
|
||||
interrupt-parent = <&core_pic>;
|
||||
interrupts = < 12 13 14 15 >;
|
||||
};
|
||||
|
||||
This is a minimal example where all individual interrupts go through a
|
||||
combiner. Combiner-0 is mapped to core interrupt 12, combiner-1 is mapped
|
||||
to interrupt 13, etc.
|
||||
|
||||
|
||||
megamod_pic: interrupt-controller@1800000 {
|
||||
compatible = "ti,c64x+megamod-pic";
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x1800000 0x1000>;
|
||||
interrupt-parent = <&core_pic>;
|
||||
interrupts = < 12 13 14 15 >;
|
||||
ti,c64x+megamod-pic-mux = < 0 0 0 0
|
||||
32 0 0 0
|
||||
0 0 0 0 >;
|
||||
};
|
||||
|
||||
This the same as the first example except that megamodule interrupt 32 is
|
||||
mapped directly to core priority interrupt 8. The node using this interrupt
|
||||
must set the core controller as its interrupt parent and use 8 in the
|
||||
interrupt specifier value.
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
C6X System-on-Chip
|
||||
------------------
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: "simple-bus"
|
||||
- #address-cells: must be 1
|
||||
- #size-cells: must be 1
|
||||
- ranges
|
||||
|
||||
Optional properties:
|
||||
|
||||
- model: specific SoC model
|
||||
|
||||
- nodes for IP blocks within SoC
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
soc {
|
||||
compatible = "simple-bus";
|
||||
model = "tms320c6455";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges;
|
||||
|
||||
...
|
||||
};
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
Timer64
|
||||
-------
|
||||
|
||||
The timer64 node describes C6X event timers.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: must be "ti,c64x+timer64"
|
||||
- reg: base address and size of register region
|
||||
- interrupt-parent: interrupt controller
|
||||
- interrupts: interrupt id
|
||||
|
||||
Optional properties:
|
||||
|
||||
- ti,dscr-dev-enable: Device ID used to enable timer IP through DSCR interface.
|
||||
|
||||
- ti,core-mask: on multi-core SoCs, bitmask of cores allowed to use this timer.
|
||||
|
||||
Example:
|
||||
timer0: timer@25e0000 {
|
||||
compatible = "ti,c64x+timer64";
|
||||
ti,core-mask = < 0x01 >;
|
||||
reg = <0x25e0000 0x40>;
|
||||
interrupt-parent = <&megamod_pic>;
|
||||
interrupts = < 16 >;
|
||||
};
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
* ARM PrimeCell PL330 DMA Controller
|
||||
|
||||
The ARM PrimeCell PL330 DMA controller can move blocks of memory contents
|
||||
between memory and peripherals or memory to memory.
|
||||
|
||||
Required properties:
|
||||
- compatible: should include both "arm,pl330" and "arm,primecell".
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- interrupts: interrupt number to the cpu.
|
||||
|
||||
Example:
|
||||
|
||||
pdma0: pdma@12680000 {
|
||||
compatible = "arm,pl330", "arm,primecell";
|
||||
reg = <0x12680000 0x1000>;
|
||||
interrupts = <99>;
|
||||
};
|
||||
|
||||
Client drivers (device nodes requiring dma transfers from dev-to-mem or
|
||||
mem-to-dev) should specify the DMA channel numbers using a two-value pair
|
||||
as shown below.
|
||||
|
||||
[property name] = <[phandle of the dma controller] [dma request id]>;
|
||||
|
||||
where 'dma request id' is the dma request number which is connected
|
||||
to the client controller. The 'property name' is recommended to be
|
||||
of the form <name>-dma-channel.
|
||||
|
||||
Example: tx-dma-channel = <&pdma0 12>;
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
Samsung Exynos4 GPIO Controller
|
||||
|
||||
Required properties:
|
||||
- compatible: Compatible property value should be "samsung,exynos4-gpio>".
|
||||
|
||||
- reg: Physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
|
||||
- #gpio-cells: Should be 4. The syntax of the gpio specifier used by client nodes
|
||||
should be the following with values derived from the SoC user manual.
|
||||
<[phandle of the gpio controller node]
|
||||
[pin number within the gpio controller]
|
||||
[mux function]
|
||||
[pull up/down]
|
||||
[drive strength]>
|
||||
|
||||
Values for gpio specifier:
|
||||
- Pin number: is a value between 0 to 7.
|
||||
- Pull Up/Down: 0 - Pull Up/Down Disabled.
|
||||
1 - Pull Down Enabled.
|
||||
3 - Pull Up Enabled.
|
||||
- Drive Strength: 0 - 1x,
|
||||
1 - 3x,
|
||||
2 - 2x,
|
||||
3 - 4x
|
||||
|
||||
- gpio-controller: Specifies that the node is a gpio controller.
|
||||
- #address-cells: should be 1.
|
||||
- #size-cells: should be 1.
|
||||
|
||||
Example:
|
||||
|
||||
gpa0: gpio-controller@11400000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compatible = "samsung,exynos4-gpio";
|
||||
reg = <0x11400000 0x20>;
|
||||
#gpio-cells = <4>;
|
||||
gpio-controller;
|
||||
};
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
* Synopsys DesignWare I2C
|
||||
|
||||
Required properties :
|
||||
|
||||
- compatible : should be "snps,designware-i2c"
|
||||
- reg : Offset and length of the register set for the device
|
||||
- interrupts : <IRQ> where IRQ is the interrupt number.
|
||||
|
||||
Recommended properties :
|
||||
|
||||
- clock-frequency : desired I2C bus clock frequency in Hz.
|
||||
|
||||
Example :
|
||||
|
||||
i2c@f0000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
compatible = "snps,designware-i2c";
|
||||
reg = <0xf0000 0x1000>;
|
||||
interrupts = <11>;
|
||||
clock-frequency = <400000>;
|
||||
};
|
||||
|
|
@ -0,0 +1,58 @@
|
|||
This is a list of trivial i2c devices that have simple device tree
|
||||
bindings, consisting only of a compatible field, an address and
|
||||
possibly an interrupt line.
|
||||
|
||||
If a device needs more specific bindings, such as properties to
|
||||
describe some aspect of it, there needs to be a specific binding
|
||||
document for it just like any other devices.
|
||||
|
||||
|
||||
Compatible Vendor / Chip
|
||||
========== =============
|
||||
ad,ad7414 SMBus/I2C Digital Temperature Sensor in 6-Pin SOT with SMBus Alert and Over Temperature Pin
|
||||
ad,adm9240 ADM9240: Complete System Hardware Monitor for uProcessor-Based Systems
|
||||
adi,adt7461 +/-1C TDM Extended Temp Range I.C
|
||||
adt7461 +/-1C TDM Extended Temp Range I.C
|
||||
at,24c08 i2c serial eeprom (24cxx)
|
||||
atmel,24c02 i2c serial eeprom (24cxx)
|
||||
catalyst,24c32 i2c serial eeprom
|
||||
dallas,ds1307 64 x 8, Serial, I2C Real-Time Clock
|
||||
dallas,ds1338 I2C RTC with 56-Byte NV RAM
|
||||
dallas,ds1339 I2C Serial Real-Time Clock
|
||||
dallas,ds1340 I2C RTC with Trickle Charger
|
||||
dallas,ds1374 I2C, 32-Bit Binary Counter Watchdog RTC with Trickle Charger and Reset Input/Output
|
||||
dallas,ds1631 High-Precision Digital Thermometer
|
||||
dallas,ds1682 Total-Elapsed-Time Recorder with Alarm
|
||||
dallas,ds1775 Tiny Digital Thermometer and Thermostat
|
||||
dallas,ds3232 Extremely Accurate I²C RTC with Integrated Crystal and SRAM
|
||||
dallas,ds4510 CPU Supervisor with Nonvolatile Memory and Programmable I/O
|
||||
dallas,ds75 Digital Thermometer and Thermostat
|
||||
dialog,da9053 DA9053: flexible system level PMIC with multicore support
|
||||
epson,rx8025 High-Stability. I2C-Bus INTERFACE REAL TIME CLOCK MODULE
|
||||
epson,rx8581 I2C-BUS INTERFACE REAL TIME CLOCK MODULE
|
||||
fsl,mag3110 MAG3110: Xtrinsic High Accuracy, 3D Magnetometer
|
||||
fsl,mc13892 MC13892: Power Management Integrated Circuit (PMIC) for i.MX35/51
|
||||
fsl,mma8450 MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic Accelerometer
|
||||
fsl,mpr121 MPR121: Proximity Capacitive Touch Sensor Controller
|
||||
fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec
|
||||
maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator
|
||||
maxim,max1237 Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs
|
||||
maxim,max6625 9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface
|
||||
mc,rv3029c2 Real Time Clock Module with I2C-Bus
|
||||
national,lm75 I2C TEMP SENSOR
|
||||
national,lm80 Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor
|
||||
national,lm92 ±0.33°C Accurate, 12-Bit + Sign Temperature Sensor and Thermal Window Comparator with Two-Wire Interface
|
||||
nxp,pca9556 Octal SMBus and I2C registered interface
|
||||
nxp,pca9557 8-bit I2C-bus and SMBus I/O port with reset
|
||||
nxp,pcf8563 Real-time clock/calendar
|
||||
ovti,ov5642 OV5642: Color CMOS QSXGA (5-megapixel) Image Sensor with OmniBSI and Embedded TrueFocus
|
||||
pericom,pt7c4338 Real-time Clock Module
|
||||
plx,pex8648 48-Lane, 12-Port PCI Express Gen 2 (5.0 GT/s) Switch
|
||||
ramtron,24c64 i2c serial eeprom (24cxx)
|
||||
ricoh,rs5c372a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
|
||||
samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
|
||||
st-micro,24c256 i2c serial eeprom (24cxx)
|
||||
stm,m41t00 Serial Access TIMEKEEPER
|
||||
stm,m41t62 Serial real-time clock (RTC) with alarm
|
||||
stm,m41t80 M41T80 - SERIAL ACCESS RTC WITH ALARMS
|
||||
ti,tsc2003 I2C Touch-Screen Controller
|
||||
|
|
@ -0,0 +1,88 @@
|
|||
* Samsung's Keypad Controller device tree bindings
|
||||
|
||||
Samsung's Keypad controller is used to interface a SoC with a matrix-type
|
||||
keypad device. The keypad controller supports multiple row and column lines.
|
||||
A key can be placed at each intersection of a unique row and a unique column.
|
||||
The keypad controller can sense a key-press and key-release and report the
|
||||
event using a interrupt to the cpu.
|
||||
|
||||
Required SoC Specific Properties:
|
||||
- compatible: should be one of the following
|
||||
- "samsung,s3c6410-keypad": For controllers compatible with s3c6410 keypad
|
||||
controller.
|
||||
- "samsung,s5pv210-keypad": For controllers compatible with s5pv210 keypad
|
||||
controller.
|
||||
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
|
||||
- interrupts: The interrupt number to the cpu.
|
||||
|
||||
Required Board Specific Properties:
|
||||
- samsung,keypad-num-rows: Number of row lines connected to the keypad
|
||||
controller.
|
||||
|
||||
- samsung,keypad-num-columns: Number of column lines connected to the
|
||||
keypad controller.
|
||||
|
||||
- row-gpios: List of gpios used as row lines. The gpio specifier for
|
||||
this property depends on the gpio controller to which these row lines
|
||||
are connected.
|
||||
|
||||
- col-gpios: List of gpios used as column lines. The gpio specifier for
|
||||
this property depends on the gpio controller to which these column
|
||||
lines are connected.
|
||||
|
||||
- Keys represented as child nodes: Each key connected to the keypad
|
||||
controller is represented as a child node to the keypad controller
|
||||
device node and should include the following properties.
|
||||
- keypad,row: the row number to which the key is connected.
|
||||
- keypad,column: the column number to which the key is connected.
|
||||
- linux,code: the key-code to be reported when the key is pressed
|
||||
and released.
|
||||
|
||||
Optional Properties specific to linux:
|
||||
- linux,keypad-no-autorepeat: do no enable autorepeat feature.
|
||||
- linux,keypad-wakeup: use any event on keypad as wakeup event.
|
||||
|
||||
|
||||
Example:
|
||||
keypad@100A0000 {
|
||||
compatible = "samsung,s5pv210-keypad";
|
||||
reg = <0x100A0000 0x100>;
|
||||
interrupts = <173>;
|
||||
samsung,keypad-num-rows = <2>;
|
||||
samsung,keypad-num-columns = <8>;
|
||||
linux,input-no-autorepeat;
|
||||
linux,input-wakeup;
|
||||
|
||||
row-gpios = <&gpx2 0 3 3 0
|
||||
&gpx2 1 3 3 0>;
|
||||
|
||||
col-gpios = <&gpx1 0 3 0 0
|
||||
&gpx1 1 3 0 0
|
||||
&gpx1 2 3 0 0
|
||||
&gpx1 3 3 0 0
|
||||
&gpx1 4 3 0 0
|
||||
&gpx1 5 3 0 0
|
||||
&gpx1 6 3 0 0
|
||||
&gpx1 7 3 0 0>;
|
||||
|
||||
key_1 {
|
||||
keypad,row = <0>;
|
||||
keypad,column = <3>;
|
||||
linux,code = <2>;
|
||||
};
|
||||
|
||||
key_2 {
|
||||
keypad,row = <0>;
|
||||
keypad,column = <4>;
|
||||
linux,code = <3>;
|
||||
};
|
||||
|
||||
key_3 {
|
||||
keypad,row = <0>;
|
||||
keypad,column = <5>;
|
||||
linux,code = <4>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
* Tegra keyboard controller
|
||||
|
||||
Required properties:
|
||||
- compatible: "nvidia,tegra20-kbc"
|
||||
|
||||
Optional properties:
|
||||
- debounce-delay: delay in milliseconds per row scan for debouncing
|
||||
- repeat-delay: delay in milliseconds before repeat starts
|
||||
- ghost-filter: enable ghost filtering for this device
|
||||
- wakeup-source: configure keyboard as a wakeup source for suspend/resume
|
||||
|
||||
Example:
|
||||
|
||||
keyboard: keyboard {
|
||||
compatible = "nvidia,tegra20-kbc";
|
||||
reg = <0x7000e200 0x100>;
|
||||
ghost-filter;
|
||||
};
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
GPIO assisted NAND flash
|
||||
|
||||
The GPIO assisted NAND flash uses a memory mapped interface to
|
||||
read/write the NAND commands and data and GPIO pins for the control
|
||||
signals.
|
||||
|
||||
Required properties:
|
||||
- compatible : "gpio-control-nand"
|
||||
- reg : should specify localbus chip select and size used for the chip. The
|
||||
resource describes the data bus connected to the NAND flash and all accesses
|
||||
are made in native endianness.
|
||||
- #address-cells, #size-cells : Must be present if the device has sub-nodes
|
||||
representing partitions.
|
||||
- gpios : specifies the gpio pins to control the NAND device. nwp is an
|
||||
optional gpio and may be set to 0 if not present.
|
||||
|
||||
Optional properties:
|
||||
- bank-width : Width (in bytes) of the device. If not present, the width
|
||||
defaults to 1 byte.
|
||||
- chip-delay : chip dependent delay for transferring data from array to
|
||||
read registers (tR). If not present then a default of 20us is used.
|
||||
- gpio-control-nand,io-sync-reg : A 64-bit physical address for a read
|
||||
location used to guard against bus reordering with regards to accesses to
|
||||
the GPIO's and the NAND flash data bus. If present, then after changing
|
||||
GPIO state and before and after command byte writes, this register will be
|
||||
read to ensure that the GPIO accesses have completed.
|
||||
|
||||
Examples:
|
||||
|
||||
gpio-nand@1,0 {
|
||||
compatible = "gpio-control-nand";
|
||||
reg = <1 0x0000 0x2>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
gpios = <&banka 1 0 /* rdy */
|
||||
&banka 2 0 /* nce */
|
||||
&banka 3 0 /* ale */
|
||||
&banka 4 0 /* cle */
|
||||
0 /* nwp */>;
|
||||
|
||||
partition@0 {
|
||||
...
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
* Cadence MACB/GEM Ethernet controller
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "cdns,[<chip>-]{macb|gem}"
|
||||
Use "cdns,at91sam9260-macb" Atmel at91sam9260 and at91sam9263 SoCs.
|
||||
Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: "cdns,macb".
|
||||
Use "cnds,pc302-gem" for Picochip picoXcell pc302 and later devices based on
|
||||
the Cadence GEM, or the generic form: "cdns,gem".
|
||||
- reg: Address and length of the register set for the device
|
||||
- interrupts: Should contain macb interrupt
|
||||
- phy-mode: String, operation mode of the PHY interface.
|
||||
Supported values are: "mii", "rmii", "gmii", "rgmii".
|
||||
|
||||
Optional properties:
|
||||
- local-mac-address: 6 bytes, mac address
|
||||
|
||||
Examples:
|
||||
|
||||
macb0: ethernet@fffc4000 {
|
||||
compatible = "cdns,at32ap7000-macb";
|
||||
reg = <0xfffc4000 0x4000>;
|
||||
interrupts = <21>;
|
||||
phy-mode = "rmii";
|
||||
local-mac-address = [3a 0e 03 04 05 06];
|
||||
};
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
NVIDIA compliant embedded controller
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "nvidia,nvec".
|
||||
- reg : the iomem of the i2c slave controller
|
||||
- interrupts : the interrupt line of the i2c slave controller
|
||||
- clock-frequency : the frequency of the i2c bus
|
||||
- gpios : the gpio used for ec request
|
||||
- slave-addr: the i2c address of the slave controller
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
OLPC battery
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Required properties:
|
||||
- compatible : "olpc,xo1-battery"
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
SBS sbs-battery
|
||||
~~~~~~~~~~
|
||||
|
||||
Required properties :
|
||||
- compatible : "sbs,sbs-battery"
|
||||
|
||||
Optional properties :
|
||||
- sbs,i2c-retry-count : The number of times to retry i2c transactions on i2c
|
||||
IO failure.
|
||||
- sbs,poll-retry-count : The number of times to try looking for new status
|
||||
after an external change notification.
|
||||
- sbs,battery-detect-gpios : The gpio which signals battery detection and
|
||||
a flag specifying its polarity.
|
||||
|
||||
Example:
|
||||
|
||||
bq20z75@b {
|
||||
compatible = "sbs,sbs-battery";
|
||||
reg = < 0xb >;
|
||||
sbs,i2c-retry-count = <2>;
|
||||
sbs,poll-retry-count = <10>;
|
||||
sbs,battery-detect-gpios = <&gpio-controller 122 1>;
|
||||
}
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
Fixed Voltage regulators
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be "regulator-fixed";
|
||||
|
||||
Optional properties:
|
||||
- gpio: gpio to use for enable control
|
||||
- startup-delay-us: startup time in microseconds
|
||||
- enable-active-high: Polarity of GPIO is Active high
|
||||
If this property is missing, the default assumed is Active low.
|
||||
|
||||
Any property defined as part of the core regulator
|
||||
binding, defined in regulator.txt, can also be used.
|
||||
However a fixed voltage regulator is expected to have the
|
||||
regulator-min-microvolt and regulator-max-microvolt
|
||||
to be the same.
|
||||
|
||||
Example:
|
||||
|
||||
abc: fixedregulator@0 {
|
||||
compatible = "regulator-fixed";
|
||||
regulator-name = "fixed-supply";
|
||||
regulator-min-microvolt = <1800000>;
|
||||
regulator-max-microvolt = <1800000>;
|
||||
gpio = <&gpio1 16 0>;
|
||||
startup-delay-us = <70000>;
|
||||
enable-active-high;
|
||||
regulator-boot-on
|
||||
};
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
Voltage/Current Regulators
|
||||
|
||||
Optional properties:
|
||||
- regulator-name: A string used as a descriptive name for regulator outputs
|
||||
- regulator-min-microvolt: smallest voltage consumers may set
|
||||
- regulator-max-microvolt: largest voltage consumers may set
|
||||
- regulator-microvolt-offset: Offset applied to voltages to compensate for voltage drops
|
||||
- regulator-min-microamp: smallest current consumers may set
|
||||
- regulator-max-microamp: largest current consumers may set
|
||||
- regulator-always-on: boolean, regulator should never be disabled
|
||||
- regulator-boot-on: bootloader/firmware enabled regulator
|
||||
- <name>-supply: phandle to the parent supply/regulator node
|
||||
|
||||
Example:
|
||||
|
||||
xyzreg: regulator@0 {
|
||||
regulator-min-microvolt = <1000000>;
|
||||
regulator-max-microvolt = <2500000>;
|
||||
regulator-always-on;
|
||||
vin-supply = <&vin>;
|
||||
};
|
||||
|
||||
Regulator Consumers:
|
||||
Consumer nodes can reference one or more of its supplies/
|
||||
regulators using the below bindings.
|
||||
|
||||
- <name>-supply: phandle to the regulator node
|
||||
|
||||
These are the same bindings that a regulator in the above
|
||||
example used to reference its own supply, in which case
|
||||
its just seen as a special case of a regulator being a
|
||||
consumer itself.
|
||||
|
||||
Example of a consumer device node (mmc) referencing two
|
||||
regulators (twl_reg1 and twl_reg2),
|
||||
|
||||
twl_reg1: regulator@0 {
|
||||
...
|
||||
...
|
||||
...
|
||||
};
|
||||
|
||||
twl_reg2: regulator@1 {
|
||||
...
|
||||
...
|
||||
...
|
||||
};
|
||||
|
||||
mmc: mmc@0x0 {
|
||||
...
|
||||
...
|
||||
vmmc-supply = <&twl_reg1>;
|
||||
vmmcaux-supply = <&twl_reg2>;
|
||||
};
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
* Samsung's S3C Real Time Clock controller
|
||||
|
||||
Required properties:
|
||||
- compatible: should be one of the following.
|
||||
* "samsung,s3c2410-rtc" - for controllers compatible with s3c2410 rtc.
|
||||
* "samsung,s3c6410-rtc" - for controllers compatible with s3c6410 rtc.
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- interrupts: Two interrupt numbers to the cpu should be specified. First
|
||||
interrupt number is the rtc alarm interupt and second interrupt number
|
||||
is the rtc tick interrupt. The number of cells representing a interrupt
|
||||
depends on the parent interrupt controller.
|
||||
|
||||
Example:
|
||||
|
||||
rtc@10070000 {
|
||||
compatible = "samsung,s3c6410-rtc";
|
||||
reg = <0x10070000 0x100>;
|
||||
interrupts = <44 0 45 0>;
|
||||
};
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
* TI twl RTC
|
||||
|
||||
The TWL family (twl4030/6030) contains a RTC.
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be twl4030-rtc
|
||||
|
||||
Examples:
|
||||
|
||||
rtc@0 {
|
||||
compatible = "ti,twl4030-rtc";
|
||||
};
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
OMAP UART controller
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "ti,omap2-uart" for OMAP2 controllers
|
||||
- compatible : should be "ti,omap3-uart" for OMAP3 controllers
|
||||
- compatible : should be "ti,omap4-uart" for OMAP4 controllers
|
||||
- ti,hwmods : Must be "uart<n>", n being the instance number (1-based)
|
||||
|
||||
Optional properties:
|
||||
- clock-frequency : frequency of the clock input to the UART
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
* Samsung's UART Controller
|
||||
|
||||
The Samsung's UART controller is used for interfacing SoC with serial communicaion
|
||||
devices.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be
|
||||
- "samsung,exynos4210-uart", for UART's compatible with Exynos4210 uart ports.
|
||||
|
||||
- reg: base physical address of the controller and length of memory mapped
|
||||
region.
|
||||
|
||||
- interrupts: interrupt number to the cpu. The interrupt specifier format depends
|
||||
on the interrupt controller parent.
|
||||
|
|
@ -0,0 +1,71 @@
|
|||
NVIDIA Tegra audio complex
|
||||
|
||||
Required properties:
|
||||
- compatible : "nvidia,tegra-audio-wm8903"
|
||||
- nvidia,model : The user-visible name of this sound complex.
|
||||
- nvidia,audio-routing : A list of the connections between audio components.
|
||||
Each entry is a pair of strings, the first being the connection's sink,
|
||||
the second being the connection's source. Valid names for sources and
|
||||
sinks are the WM8903's pins, and the jacks on the board:
|
||||
|
||||
WM8903 pins:
|
||||
|
||||
* IN1L
|
||||
* IN1R
|
||||
* IN2L
|
||||
* IN2R
|
||||
* IN3L
|
||||
* IN3R
|
||||
* DMICDAT
|
||||
* HPOUTL
|
||||
* HPOUTR
|
||||
* LINEOUTL
|
||||
* LINEOUTR
|
||||
* LOP
|
||||
* LON
|
||||
* ROP
|
||||
* RON
|
||||
* MICBIAS
|
||||
|
||||
Board connectors:
|
||||
|
||||
* Headphone Jack
|
||||
* Int Spk
|
||||
* Mic Jack
|
||||
|
||||
- nvidia,i2s-controller : The phandle of the Tegra I2S1 controller
|
||||
- nvidia,audio-codec : The phandle of the WM8903 audio codec
|
||||
|
||||
Optional properties:
|
||||
- nvidia,spkr-en-gpios : The GPIO that enables the speakers
|
||||
- nvidia,hp-mute-gpios : The GPIO that mutes the headphones
|
||||
- nvidia,hp-det-gpios : The GPIO that detect headphones are plugged in
|
||||
- nvidia,int-mic-en-gpios : The GPIO that enables the internal microphone
|
||||
- nvidia,ext-mic-en-gpios : The GPIO that enables the external microphone
|
||||
|
||||
Example:
|
||||
|
||||
sound {
|
||||
compatible = "nvidia,tegra-audio-wm8903-harmony",
|
||||
"nvidia,tegra-audio-wm8903"
|
||||
nvidia,model = "tegra-wm8903-harmony";
|
||||
|
||||
nvidia,audio-routing =
|
||||
"Headphone Jack", "HPOUTR",
|
||||
"Headphone Jack", "HPOUTL",
|
||||
"Int Spk", "ROP",
|
||||
"Int Spk", "RON",
|
||||
"Int Spk", "LOP",
|
||||
"Int Spk", "LON",
|
||||
"Mic Jack", "MICBIAS",
|
||||
"IN1L", "Mic Jack";
|
||||
|
||||
nvidia,i2s-controller = <&i2s1>;
|
||||
nvidia,audio-codec = <&wm8903>;
|
||||
|
||||
nvidia,spkr-en-gpios = <&codec 2 0>;
|
||||
nvidia,hp-det-gpios = <&gpio 178 0>; /* gpio PW2 */
|
||||
nvidia,int-mic-en-gpios = <&gpio 184 0>; /*gpio PX0 */
|
||||
nvidia,ext-mic-en-gpios = <&gpio 185 0>; /* gpio PX1 */
|
||||
};
|
||||
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
NVIDIA Tegra 20 DAS (Digital Audio Switch) controller
|
||||
|
||||
Required properties:
|
||||
- compatible : "nvidia,tegra20-das"
|
||||
- reg : Should contain DAS registers location and length
|
||||
|
||||
Example:
|
||||
|
||||
das@70000c00 {
|
||||
compatible = "nvidia,tegra20-das";
|
||||
reg = <0x70000c00 0x80>;
|
||||
};
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
NVIDIA Tegra 20 I2S controller
|
||||
|
||||
Required properties:
|
||||
- compatible : "nvidia,tegra20-i2s"
|
||||
- reg : Should contain I2S registers location and length
|
||||
- interrupts : Should contain I2S interrupt
|
||||
- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
|
||||
request selector for this I2S controller
|
||||
|
||||
Example:
|
||||
|
||||
i2s@70002800 {
|
||||
compatible = "nvidia,tegra20-i2s";
|
||||
reg = <0x70002800 0x200>;
|
||||
interrupts = < 45 >;
|
||||
nvidia,dma-request-selector = < &apbdma 2 >;
|
||||
};
|
||||
|
|
@ -0,0 +1,50 @@
|
|||
WM8903 audio CODEC
|
||||
|
||||
This device supports I2C only.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "wlf,wm8903"
|
||||
|
||||
- reg : the I2C address of the device.
|
||||
|
||||
- gpio-controller : Indicates this device is a GPIO controller.
|
||||
|
||||
- #gpio-cells : Should be two. The first cell is the pin number and the
|
||||
second cell is used to specify optional parameters (currently unused).
|
||||
|
||||
Optional properties:
|
||||
|
||||
- interrupts : The interrupt line the codec is connected to.
|
||||
|
||||
- micdet-cfg : Default register value for R6 (Mic Bias). If absent, the
|
||||
default is 0.
|
||||
|
||||
- micdet-delay : The debounce delay for microphone detection in mS. If
|
||||
absent, the default is 100.
|
||||
|
||||
- gpio-cfg : A list of GPIO configuration register values. The list must
|
||||
be 5 entries long. If absent, no configuration of these registers is
|
||||
performed. If any entry has the value 0xffffffff, that GPIO's
|
||||
configuration will not be modified.
|
||||
|
||||
Example:
|
||||
|
||||
codec: wm8903@1a {
|
||||
compatible = "wlf,wm8903";
|
||||
reg = <0x1a>;
|
||||
interrupts = < 347 >;
|
||||
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
|
||||
micdet-cfg = <0>;
|
||||
micdet-delay = <100>;
|
||||
gpio-cfg = <
|
||||
0x0600 /* DMIC_LR, output */
|
||||
0x0680 /* DMIC_DAT, input */
|
||||
0x0000 /* GPIO, output, low */
|
||||
0x0200 /* Interrupt, output */
|
||||
0x01a0 /* BCLK, input, active high */
|
||||
>;
|
||||
};
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
WM1811/WM8994/WM8958 audio CODEC
|
||||
|
||||
These devices support both I2C and SPI (configured with pin strapping
|
||||
on the board).
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "wlf,wm1811", "wlf,wm8994", "wlf,wm8958"
|
||||
|
||||
- reg : the I2C address of the device for I2C, the chip select
|
||||
number for SPI.
|
||||
|
||||
Example:
|
||||
|
||||
codec: wm8994@1a {
|
||||
compatible = "wlf,wm8994";
|
||||
reg = <0x1a>;
|
||||
};
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
Tegra SOC USB controllers
|
||||
|
||||
The device node for a USB controller that is part of a Tegra
|
||||
SOC is as described in the document "Open Firmware Recommended
|
||||
Practice : Universal Serial Bus" with the following modifications
|
||||
and additions :
|
||||
|
||||
Required properties :
|
||||
- compatible : Should be "nvidia,tegra20-ehci" for USB controllers
|
||||
used in host mode.
|
||||
- phy_type : Should be one of "ulpi" or "utmi".
|
||||
- nvidia,vbus-gpio : If present, specifies a gpio that needs to be
|
||||
activated for the bus to be powered.
|
||||
|
|
@ -8,7 +8,9 @@ amcc Applied Micro Circuits Corporation (APM, formally AMCC)
|
|||
apm Applied Micro Circuits Corporation (APM)
|
||||
arm ARM Ltd.
|
||||
atmel Atmel Corporation
|
||||
cavium Cavium, Inc.
|
||||
chrp Common Hardware Reference Platform
|
||||
cortina Cortina Systems, Inc.
|
||||
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
|
||||
denx Denx Software Engineering
|
||||
epson Seiko Epson Corp.
|
||||
|
|
@ -32,10 +34,13 @@ powervr Imagination Technologies
|
|||
qcom Qualcomm, Inc.
|
||||
ramtron Ramtron International
|
||||
samsung Samsung Semiconductor
|
||||
sbs Smart Battery System
|
||||
schindler Schindler
|
||||
sil Silicon Image
|
||||
simtek
|
||||
sirf SiRF Technology, Inc.
|
||||
st STMicroelectronics
|
||||
stericsson ST-Ericsson
|
||||
ti Texas Instruments
|
||||
wlf Wolfson Microelectronics
|
||||
xlnx Xilinx
|
||||
|
|
|
|||
|
|
@ -0,0 +1,96 @@
|
|||
Digital Signature Verification API
|
||||
|
||||
CONTENTS
|
||||
|
||||
1. Introduction
|
||||
2. API
|
||||
3. User-space utilities
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
Digital signature verification API provides a method to verify digital signature.
|
||||
Currently digital signatures are used by the IMA/EVM integrity protection subsystem.
|
||||
|
||||
Digital signature verification is implemented using cut-down kernel port of
|
||||
GnuPG multi-precision integers (MPI) library. The kernel port provides
|
||||
memory allocation errors handling, has been refactored according to kernel
|
||||
coding style, and checkpatch.pl reported errors and warnings have been fixed.
|
||||
|
||||
Public key and signature consist of header and MPIs.
|
||||
|
||||
struct pubkey_hdr {
|
||||
uint8_t version; /* key format version */
|
||||
time_t timestamp; /* key made, always 0 for now */
|
||||
uint8_t algo;
|
||||
uint8_t nmpi;
|
||||
char mpi[0];
|
||||
} __packed;
|
||||
|
||||
struct signature_hdr {
|
||||
uint8_t version; /* signature format version */
|
||||
time_t timestamp; /* signature made */
|
||||
uint8_t algo;
|
||||
uint8_t hash;
|
||||
uint8_t keyid[8];
|
||||
uint8_t nmpi;
|
||||
char mpi[0];
|
||||
} __packed;
|
||||
|
||||
keyid equals to SHA1[12-19] over the total key content.
|
||||
Signature header is used as an input to generate a signature.
|
||||
Such approach insures that key or signature header could not be changed.
|
||||
It protects timestamp from been changed and can be used for rollback
|
||||
protection.
|
||||
|
||||
2. API
|
||||
|
||||
API currently includes only 1 function:
|
||||
|
||||
digsig_verify() - digital signature verification with public key
|
||||
|
||||
|
||||
/**
|
||||
* digsig_verify() - digital signature verification with public key
|
||||
* @keyring: keyring to search key in
|
||||
* @sig: digital signature
|
||||
* @sigen: length of the signature
|
||||
* @data: data
|
||||
* @datalen: length of the data
|
||||
* @return: 0 on success, -EINVAL otherwise
|
||||
*
|
||||
* Verifies data integrity against digital signature.
|
||||
* Currently only RSA is supported.
|
||||
* Normally hash of the content is used as a data for this function.
|
||||
*
|
||||
*/
|
||||
int digsig_verify(struct key *keyring, const char *sig, int siglen,
|
||||
const char *data, int datalen);
|
||||
|
||||
3. User-space utilities
|
||||
|
||||
The signing and key management utilities evm-utils provide functionality
|
||||
to generate signatures, to load keys into the kernel keyring.
|
||||
Keys can be in PEM or converted to the kernel format.
|
||||
When the key is added to the kernel keyring, the keyid defines the name
|
||||
of the key: 5D2B05FC633EE3E8 in the example bellow.
|
||||
|
||||
Here is example output of the keyctl utility.
|
||||
|
||||
$ keyctl show
|
||||
Session Keyring
|
||||
-3 --alswrv 0 0 keyring: _ses
|
||||
603976250 --alswrv 0 -1 \_ keyring: _uid.0
|
||||
817777377 --alswrv 0 0 \_ user: kmk
|
||||
891974900 --alswrv 0 0 \_ encrypted: evm-key
|
||||
170323636 --alswrv 0 0 \_ keyring: _module
|
||||
548221616 --alswrv 0 0 \_ keyring: _ima
|
||||
128198054 --alswrv 0 0 \_ keyring: _evm
|
||||
|
||||
$ keyctl list 128198054
|
||||
1 key in keyring:
|
||||
620789745: --alswrv 0 0 user: 5D2B05FC633EE3E8
|
||||
|
||||
|
||||
Dmitry Kasatkin
|
||||
06.10.2011
|
||||
|
|
@ -0,0 +1,224 @@
|
|||
DMA Buffer Sharing API Guide
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Sumit Semwal
|
||||
<sumit dot semwal at linaro dot org>
|
||||
<sumit dot semwal at ti dot com>
|
||||
|
||||
This document serves as a guide to device-driver writers on what is the dma-buf
|
||||
buffer sharing API, how to use it for exporting and using shared buffers.
|
||||
|
||||
Any device driver which wishes to be a part of DMA buffer sharing, can do so as
|
||||
either the 'exporter' of buffers, or the 'user' of buffers.
|
||||
|
||||
Say a driver A wants to use buffers created by driver B, then we call B as the
|
||||
exporter, and A as buffer-user.
|
||||
|
||||
The exporter
|
||||
- implements and manages operations[1] for the buffer
|
||||
- allows other users to share the buffer by using dma_buf sharing APIs,
|
||||
- manages the details of buffer allocation,
|
||||
- decides about the actual backing storage where this allocation happens,
|
||||
- takes care of any migration of scatterlist - for all (shared) users of this
|
||||
buffer,
|
||||
|
||||
The buffer-user
|
||||
- is one of (many) sharing users of the buffer.
|
||||
- doesn't need to worry about how the buffer is allocated, or where.
|
||||
- needs a mechanism to get access to the scatterlist that makes up this buffer
|
||||
in memory, mapped into its own address space, so it can access the same area
|
||||
of memory.
|
||||
|
||||
*IMPORTANT*: [see https://lkml.org/lkml/2011/12/20/211 for more details]
|
||||
For this first version, A buffer shared using the dma_buf sharing API:
|
||||
- *may* be exported to user space using "mmap" *ONLY* by exporter, outside of
|
||||
this framework.
|
||||
- may be used *ONLY* by importers that do not need CPU access to the buffer.
|
||||
|
||||
The dma_buf buffer sharing API usage contains the following steps:
|
||||
|
||||
1. Exporter announces that it wishes to export a buffer
|
||||
2. Userspace gets the file descriptor associated with the exported buffer, and
|
||||
passes it around to potential buffer-users based on use case
|
||||
3. Each buffer-user 'connects' itself to the buffer
|
||||
4. When needed, buffer-user requests access to the buffer from exporter
|
||||
5. When finished with its use, the buffer-user notifies end-of-DMA to exporter
|
||||
6. when buffer-user is done using this buffer completely, it 'disconnects'
|
||||
itself from the buffer.
|
||||
|
||||
|
||||
1. Exporter's announcement of buffer export
|
||||
|
||||
The buffer exporter announces its wish to export a buffer. In this, it
|
||||
connects its own private buffer data, provides implementation for operations
|
||||
that can be performed on the exported dma_buf, and flags for the file
|
||||
associated with this buffer.
|
||||
|
||||
Interface:
|
||||
struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
|
||||
size_t size, int flags)
|
||||
|
||||
If this succeeds, dma_buf_export allocates a dma_buf structure, and returns a
|
||||
pointer to the same. It also associates an anonymous file with this buffer,
|
||||
so it can be exported. On failure to allocate the dma_buf object, it returns
|
||||
NULL.
|
||||
|
||||
2. Userspace gets a handle to pass around to potential buffer-users
|
||||
|
||||
Userspace entity requests for a file-descriptor (fd) which is a handle to the
|
||||
anonymous file associated with the buffer. It can then share the fd with other
|
||||
drivers and/or processes.
|
||||
|
||||
Interface:
|
||||
int dma_buf_fd(struct dma_buf *dmabuf)
|
||||
|
||||
This API installs an fd for the anonymous file associated with this buffer;
|
||||
returns either 'fd', or error.
|
||||
|
||||
3. Each buffer-user 'connects' itself to the buffer
|
||||
|
||||
Each buffer-user now gets a reference to the buffer, using the fd passed to
|
||||
it.
|
||||
|
||||
Interface:
|
||||
struct dma_buf *dma_buf_get(int fd)
|
||||
|
||||
This API will return a reference to the dma_buf, and increment refcount for
|
||||
it.
|
||||
|
||||
After this, the buffer-user needs to attach its device with the buffer, which
|
||||
helps the exporter to know of device buffer constraints.
|
||||
|
||||
Interface:
|
||||
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
|
||||
struct device *dev)
|
||||
|
||||
This API returns reference to an attachment structure, which is then used
|
||||
for scatterlist operations. It will optionally call the 'attach' dma_buf
|
||||
operation, if provided by the exporter.
|
||||
|
||||
The dma-buf sharing framework does the bookkeeping bits related to managing
|
||||
the list of all attachments to a buffer.
|
||||
|
||||
Until this stage, the buffer-exporter has the option to choose not to actually
|
||||
allocate the backing storage for this buffer, but wait for the first buffer-user
|
||||
to request use of buffer for allocation.
|
||||
|
||||
|
||||
4. When needed, buffer-user requests access to the buffer
|
||||
|
||||
Whenever a buffer-user wants to use the buffer for any DMA, it asks for
|
||||
access to the buffer using dma_buf_map_attachment API. At least one attach to
|
||||
the buffer must have happened before map_dma_buf can be called.
|
||||
|
||||
Interface:
|
||||
struct sg_table * dma_buf_map_attachment(struct dma_buf_attachment *,
|
||||
enum dma_data_direction);
|
||||
|
||||
This is a wrapper to dma_buf->ops->map_dma_buf operation, which hides the
|
||||
"dma_buf->ops->" indirection from the users of this interface.
|
||||
|
||||
In struct dma_buf_ops, map_dma_buf is defined as
|
||||
struct sg_table * (*map_dma_buf)(struct dma_buf_attachment *,
|
||||
enum dma_data_direction);
|
||||
|
||||
It is one of the buffer operations that must be implemented by the exporter.
|
||||
It should return the sg_table containing scatterlist for this buffer, mapped
|
||||
into caller's address space.
|
||||
|
||||
If this is being called for the first time, the exporter can now choose to
|
||||
scan through the list of attachments for this buffer, collate the requirements
|
||||
of the attached devices, and choose an appropriate backing storage for the
|
||||
buffer.
|
||||
|
||||
Based on enum dma_data_direction, it might be possible to have multiple users
|
||||
accessing at the same time (for reading, maybe), or any other kind of sharing
|
||||
that the exporter might wish to make available to buffer-users.
|
||||
|
||||
map_dma_buf() operation can return -EINTR if it is interrupted by a signal.
|
||||
|
||||
|
||||
5. When finished, the buffer-user notifies end-of-DMA to exporter
|
||||
|
||||
Once the DMA for the current buffer-user is over, it signals 'end-of-DMA' to
|
||||
the exporter using the dma_buf_unmap_attachment API.
|
||||
|
||||
Interface:
|
||||
void dma_buf_unmap_attachment(struct dma_buf_attachment *,
|
||||
struct sg_table *);
|
||||
|
||||
This is a wrapper to dma_buf->ops->unmap_dma_buf() operation, which hides the
|
||||
"dma_buf->ops->" indirection from the users of this interface.
|
||||
|
||||
In struct dma_buf_ops, unmap_dma_buf is defined as
|
||||
void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *);
|
||||
|
||||
unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like
|
||||
map_dma_buf, this API also must be implemented by the exporter.
|
||||
|
||||
|
||||
6. when buffer-user is done using this buffer, it 'disconnects' itself from the
|
||||
buffer.
|
||||
|
||||
After the buffer-user has no more interest in using this buffer, it should
|
||||
disconnect itself from the buffer:
|
||||
|
||||
- it first detaches itself from the buffer.
|
||||
|
||||
Interface:
|
||||
void dma_buf_detach(struct dma_buf *dmabuf,
|
||||
struct dma_buf_attachment *dmabuf_attach);
|
||||
|
||||
This API removes the attachment from the list in dmabuf, and optionally calls
|
||||
dma_buf->ops->detach(), if provided by exporter, for any housekeeping bits.
|
||||
|
||||
- Then, the buffer-user returns the buffer reference to exporter.
|
||||
|
||||
Interface:
|
||||
void dma_buf_put(struct dma_buf *dmabuf);
|
||||
|
||||
This API then reduces the refcount for this buffer.
|
||||
|
||||
If, as a result of this call, the refcount becomes 0, the 'release' file
|
||||
operation related to this fd is called. It calls the dmabuf->ops->release()
|
||||
operation in turn, and frees the memory allocated for dmabuf when exported.
|
||||
|
||||
NOTES:
|
||||
- Importance of attach-detach and {map,unmap}_dma_buf operation pairs
|
||||
The attach-detach calls allow the exporter to figure out backing-storage
|
||||
constraints for the currently-interested devices. This allows preferential
|
||||
allocation, and/or migration of pages across different types of storage
|
||||
available, if possible.
|
||||
|
||||
Bracketing of DMA access with {map,unmap}_dma_buf operations is essential
|
||||
to allow just-in-time backing of storage, and migration mid-way through a
|
||||
use-case.
|
||||
|
||||
- Migration of backing storage if needed
|
||||
If after
|
||||
- at least one map_dma_buf has happened,
|
||||
- and the backing storage has been allocated for this buffer,
|
||||
another new buffer-user intends to attach itself to this buffer, it might
|
||||
be allowed, if possible for the exporter.
|
||||
|
||||
In case it is allowed by the exporter:
|
||||
if the new buffer-user has stricter 'backing-storage constraints', and the
|
||||
exporter can handle these constraints, the exporter can just stall on the
|
||||
map_dma_buf until all outstanding access is completed (as signalled by
|
||||
unmap_dma_buf).
|
||||
Once all users have finished accessing and have unmapped this buffer, the
|
||||
exporter could potentially move the buffer to the stricter backing-storage,
|
||||
and then allow further {map,unmap}_dma_buf operations from any buffer-user
|
||||
from the migrated backing-storage.
|
||||
|
||||
If the exporter cannot fulfil the backing-storage constraints of the new
|
||||
buffer-user device as requested, dma_buf_attach() would return an error to
|
||||
denote non-compatibility of the new buffer-sharing request with the current
|
||||
buffer.
|
||||
|
||||
If the exporter chooses not to allow an attach() operation once a
|
||||
map_dma_buf() API has been called, it simply returns an error.
|
||||
|
||||
References:
|
||||
[1] struct dma_buf_ops in include/linux/dma-buf.h
|
||||
[2] All interfaces mentioned above defined in include/linux/dma-buf.h
|
||||
|
|
@ -66,7 +66,6 @@ GRTAGS
|
|||
GSYMS
|
||||
GTAGS
|
||||
Image
|
||||
Kerntypes
|
||||
Module.markers
|
||||
Module.symvers
|
||||
PENDING
|
||||
|
|
|
|||
|
|
@ -262,6 +262,7 @@ IOMAP
|
|||
devm_ioremap()
|
||||
devm_ioremap_nocache()
|
||||
devm_iounmap()
|
||||
devm_request_and_ioremap() : checks resource, requests region, ioremaps
|
||||
pcim_iomap()
|
||||
pcim_iounmap()
|
||||
pcim_iomap_table() : array of mapped addresses indexed by BAR
|
||||
|
|
|
|||
|
|
@ -85,17 +85,6 @@ Who: Robin Getz <rgetz@blackfin.uclinux.org> & Matt Mackall <mpm@selenic.com>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: Deprecated snapshot ioctls
|
||||
When: 2.6.36
|
||||
|
||||
Why: The ioctls in kernel/power/user.c were marked as deprecated long time
|
||||
ago. Now they notify users about that so that they need to replace
|
||||
their userspace. After some more time, remove them completely.
|
||||
|
||||
Who: Jiri Slaby <jirislaby@gmail.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: The ieee80211_regdom module parameter
|
||||
When: March 2010 / desktop catchup
|
||||
|
||||
|
|
@ -361,15 +350,6 @@ Who: anybody or Florian Mickler <florian@mickler.org>
|
|||
|
||||
----------------------------
|
||||
|
||||
What: KVM paravirt mmu host support
|
||||
When: January 2011
|
||||
Why: The paravirt mmu host support is slower than non-paravirt mmu, both
|
||||
on newer and older hardware. It is already not exposed to the guest,
|
||||
and kept only for live migration purposes.
|
||||
Who: Avi Kivity <avi@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: iwlwifi 50XX module parameters
|
||||
When: 3.0
|
||||
Why: The "..50" modules parameters were used to configure 5000 series and
|
||||
|
|
@ -534,6 +514,20 @@ Why: In 3.0, we can now autodetect internal 3G device and already have
|
|||
information log when acer-wmi initial.
|
||||
Who: Lee, Chun-Yi <jlee@novell.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: /sys/devices/platform/_UDC_/udc/_UDC_/is_dualspeed file and
|
||||
is_dualspeed line in /sys/devices/platform/ci13xxx_*/udc/device file.
|
||||
When: 3.8
|
||||
Why: The is_dualspeed file is superseded by maximum_speed in the same
|
||||
directory and is_dualspeed line in device file is superseded by
|
||||
max_speed line in the same file.
|
||||
|
||||
The maximum_speed/max_speed specifies maximum speed supported by UDC.
|
||||
To check if dualspeeed is supported, check if the value is >= 3.
|
||||
Various possible speeds are defined in <linux/usb/ch9.h>.
|
||||
Who: Michal Nazarewicz <mina86@mina86.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: The XFS nodelaylog mount option
|
||||
|
|
@ -550,3 +544,15 @@ When: 3.5
|
|||
Why: The iwlagn module has been renamed iwlwifi. The alias will be around
|
||||
for backward compatibility for several cycles and then dropped.
|
||||
Who: Don Fry <donald.h.fry@intel.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: pci_scan_bus_parented()
|
||||
When: 3.5
|
||||
Why: The pci_scan_bus_parented() interface creates a new root bus. The
|
||||
bus is created with default resources (ioport_resource and
|
||||
iomem_resource) that are always wrong, so we rely on arch code to
|
||||
correct them later. Callers of pci_scan_bus_parented() should
|
||||
convert to using pci_scan_root_bus() so they can supply a list of
|
||||
bus resources when the bus is created.
|
||||
Who: Bjorn Helgaas <bhelgaas@google.com>
|
||||
|
|
|
|||
|
|
@ -37,15 +37,15 @@ d_manage: no no yes (ref-walk) maybe
|
|||
|
||||
--------------------------- inode_operations ---------------------------
|
||||
prototypes:
|
||||
int (*create) (struct inode *,struct dentry *,int, struct nameidata *);
|
||||
int (*create) (struct inode *,struct dentry *,umode_t, struct nameidata *);
|
||||
struct dentry * (*lookup) (struct inode *,struct dentry *, struct nameid
|
||||
ata *);
|
||||
int (*link) (struct dentry *,struct inode *,struct dentry *);
|
||||
int (*unlink) (struct inode *,struct dentry *);
|
||||
int (*symlink) (struct inode *,struct dentry *,const char *);
|
||||
int (*mkdir) (struct inode *,struct dentry *,int);
|
||||
int (*mkdir) (struct inode *,struct dentry *,umode_t);
|
||||
int (*rmdir) (struct inode *,struct dentry *);
|
||||
int (*mknod) (struct inode *,struct dentry *,int,dev_t);
|
||||
int (*mknod) (struct inode *,struct dentry *,umode_t,dev_t);
|
||||
int (*rename) (struct inode *, struct dentry *,
|
||||
struct inode *, struct dentry *);
|
||||
int (*readlink) (struct dentry *, char __user *,int);
|
||||
|
|
@ -117,7 +117,7 @@ prototypes:
|
|||
int (*statfs) (struct dentry *, struct kstatfs *);
|
||||
int (*remount_fs) (struct super_block *, int *, char *);
|
||||
void (*umount_begin) (struct super_block *);
|
||||
int (*show_options)(struct seq_file *, struct vfsmount *);
|
||||
int (*show_options)(struct seq_file *, struct dentry *);
|
||||
ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t);
|
||||
ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t);
|
||||
int (*bdev_try_to_free_page)(struct super_block*, struct page*, gfp_t);
|
||||
|
|
|
|||
|
|
@ -192,7 +192,7 @@ attribute value uses the store_attribute() method.
|
|||
struct configfs_attribute {
|
||||
char *ca_name;
|
||||
struct module *ca_owner;
|
||||
mode_t ca_mode;
|
||||
umode_t ca_mode;
|
||||
};
|
||||
|
||||
When a config_item wants an attribute to appear as a file in the item's
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ described below will work.
|
|||
|
||||
The most general way to create a file within a debugfs directory is with:
|
||||
|
||||
struct dentry *debugfs_create_file(const char *name, mode_t mode,
|
||||
struct dentry *debugfs_create_file(const char *name, umode_t mode,
|
||||
struct dentry *parent, void *data,
|
||||
const struct file_operations *fops);
|
||||
|
||||
|
|
@ -53,13 +53,13 @@ actually necessary; the debugfs code provides a number of helper functions
|
|||
for simple situations. Files containing a single integer value can be
|
||||
created with any of:
|
||||
|
||||
struct dentry *debugfs_create_u8(const char *name, mode_t mode,
|
||||
struct dentry *debugfs_create_u8(const char *name, umode_t mode,
|
||||
struct dentry *parent, u8 *value);
|
||||
struct dentry *debugfs_create_u16(const char *name, mode_t mode,
|
||||
struct dentry *debugfs_create_u16(const char *name, umode_t mode,
|
||||
struct dentry *parent, u16 *value);
|
||||
struct dentry *debugfs_create_u32(const char *name, mode_t mode,
|
||||
struct dentry *debugfs_create_u32(const char *name, umode_t mode,
|
||||
struct dentry *parent, u32 *value);
|
||||
struct dentry *debugfs_create_u64(const char *name, mode_t mode,
|
||||
struct dentry *debugfs_create_u64(const char *name, umode_t mode,
|
||||
struct dentry *parent, u64 *value);
|
||||
|
||||
These files support both reading and writing the given value; if a specific
|
||||
|
|
@ -67,13 +67,13 @@ file should not be written to, simply set the mode bits accordingly. The
|
|||
values in these files are in decimal; if hexadecimal is more appropriate,
|
||||
the following functions can be used instead:
|
||||
|
||||
struct dentry *debugfs_create_x8(const char *name, mode_t mode,
|
||||
struct dentry *debugfs_create_x8(const char *name, umode_t mode,
|
||||
struct dentry *parent, u8 *value);
|
||||
struct dentry *debugfs_create_x16(const char *name, mode_t mode,
|
||||
struct dentry *debugfs_create_x16(const char *name, umode_t mode,
|
||||
struct dentry *parent, u16 *value);
|
||||
struct dentry *debugfs_create_x32(const char *name, mode_t mode,
|
||||
struct dentry *debugfs_create_x32(const char *name, umode_t mode,
|
||||
struct dentry *parent, u32 *value);
|
||||
struct dentry *debugfs_create_x64(const char *name, mode_t mode,
|
||||
struct dentry *debugfs_create_x64(const char *name, umode_t mode,
|
||||
struct dentry *parent, u64 *value);
|
||||
|
||||
These functions are useful as long as the developer knows the size of the
|
||||
|
|
@ -81,7 +81,7 @@ value to be exported. Some types can have different widths on different
|
|||
architectures, though, complicating the situation somewhat. There is a
|
||||
function meant to help out in one special case:
|
||||
|
||||
struct dentry *debugfs_create_size_t(const char *name, mode_t mode,
|
||||
struct dentry *debugfs_create_size_t(const char *name, umode_t mode,
|
||||
struct dentry *parent,
|
||||
size_t *value);
|
||||
|
||||
|
|
@ -90,21 +90,22 @@ a variable of type size_t.
|
|||
|
||||
Boolean values can be placed in debugfs with:
|
||||
|
||||
struct dentry *debugfs_create_bool(const char *name, mode_t mode,
|
||||
struct dentry *debugfs_create_bool(const char *name, umode_t mode,
|
||||
struct dentry *parent, u32 *value);
|
||||
|
||||
A read on the resulting file will yield either Y (for non-zero values) or
|
||||
N, followed by a newline. If written to, it will accept either upper- or
|
||||
lower-case values, or 1 or 0. Any other input will be silently ignored.
|
||||
|
||||
Finally, a block of arbitrary binary data can be exported with:
|
||||
Another option is exporting a block of arbitrary binary data, with
|
||||
this structure and function:
|
||||
|
||||
struct debugfs_blob_wrapper {
|
||||
void *data;
|
||||
unsigned long size;
|
||||
};
|
||||
|
||||
struct dentry *debugfs_create_blob(const char *name, mode_t mode,
|
||||
struct dentry *debugfs_create_blob(const char *name, umode_t mode,
|
||||
struct dentry *parent,
|
||||
struct debugfs_blob_wrapper *blob);
|
||||
|
||||
|
|
@ -115,6 +116,35 @@ can be used to export binary information, but there does not appear to be
|
|||
any code which does so in the mainline. Note that all files created with
|
||||
debugfs_create_blob() are read-only.
|
||||
|
||||
If you want to dump a block of registers (something that happens quite
|
||||
often during development, even if little such code reaches mainline.
|
||||
Debugfs offers two functions: one to make a registers-only file, and
|
||||
another to insert a register block in the middle of another sequential
|
||||
file.
|
||||
|
||||
struct debugfs_reg32 {
|
||||
char *name;
|
||||
unsigned long offset;
|
||||
};
|
||||
|
||||
struct debugfs_regset32 {
|
||||
struct debugfs_reg32 *regs;
|
||||
int nregs;
|
||||
void __iomem *base;
|
||||
};
|
||||
|
||||
struct dentry *debugfs_create_regset32(const char *name, mode_t mode,
|
||||
struct dentry *parent,
|
||||
struct debugfs_regset32 *regset);
|
||||
|
||||
int debugfs_print_regs32(struct seq_file *s, struct debugfs_reg32 *regs,
|
||||
int nregs, void __iomem *base, char *prefix);
|
||||
|
||||
The "base" argument may be 0, but you may want to build the reg32 array
|
||||
using __stringify, and a number of register names (macros) are actually
|
||||
byte offsets over a base for the register block.
|
||||
|
||||
|
||||
There are a couple of other directory-oriented helper functions:
|
||||
|
||||
struct dentry *debugfs_rename(struct dentry *old_dir,
|
||||
|
|
|
|||
|
|
@ -581,6 +581,13 @@ Table of Ext4 specific ioctls
|
|||
behaviour may change in the future as it is
|
||||
not necessary and has been done this way only
|
||||
for sake of simplicity.
|
||||
|
||||
EXT4_IOC_RESIZE_FS Resize the filesystem to a new size. The number
|
||||
of blocks of resized filesystem is passed in via
|
||||
64 bit integer argument. The kernel allocates
|
||||
bitmaps and inode table, the userspace tool thus
|
||||
just passes the new number of blocks.
|
||||
|
||||
..............................................................................
|
||||
|
||||
References
|
||||
|
|
|
|||
|
|
@ -41,6 +41,8 @@ Table of Contents
|
|||
3.5 /proc/<pid>/mountinfo - Information about mounts
|
||||
3.6 /proc/<pid>/comm & /proc/<pid>/task/<tid>/comm
|
||||
|
||||
4 Configuring procfs
|
||||
4.1 Mount options
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
Preface
|
||||
|
|
@ -305,6 +307,9 @@ Table 1-4: Contents of the stat files (as of 2.6.30-rc7)
|
|||
blkio_ticks time spent waiting for block IO
|
||||
gtime guest time of the task in jiffies
|
||||
cgtime guest time of the task children in jiffies
|
||||
start_data address above which program data+bss is placed
|
||||
end_data address below which program data+bss is placed
|
||||
start_brk address above which program heap can be expanded with brk()
|
||||
..............................................................................
|
||||
|
||||
The /proc/PID/maps file containing the currently mapped memory regions and
|
||||
|
|
@ -1542,3 +1547,40 @@ a task to set its own or one of its thread siblings comm value. The comm value
|
|||
is limited in size compared to the cmdline value, so writing anything longer
|
||||
then the kernel's TASK_COMM_LEN (currently 16 chars) will result in a truncated
|
||||
comm value.
|
||||
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
Configuring procfs
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
4.1 Mount options
|
||||
---------------------
|
||||
|
||||
The following mount options are supported:
|
||||
|
||||
hidepid= Set /proc/<pid>/ access mode.
|
||||
gid= Set the group authorized to learn processes information.
|
||||
|
||||
hidepid=0 means classic mode - everybody may access all /proc/<pid>/ directories
|
||||
(default).
|
||||
|
||||
hidepid=1 means users may not access any /proc/<pid>/ directories but their
|
||||
own. Sensitive files like cmdline, sched*, status are now protected against
|
||||
other users. This makes it impossible to learn whether any user runs
|
||||
specific program (given the program doesn't reveal itself by its behaviour).
|
||||
As an additional bonus, as /proc/<pid>/cmdline is unaccessible for other users,
|
||||
poorly written programs passing sensitive information via program arguments are
|
||||
now protected against local eavesdroppers.
|
||||
|
||||
hidepid=2 means hidepid=1 plus all /proc/<pid>/ will be fully invisible to other
|
||||
users. It doesn't mean that it hides a fact whether a process with a specific
|
||||
pid value exists (it can be learned by other means, e.g. by "kill -0 $PID"),
|
||||
but it hides process' uid and gid, which may be learned by stat()'ing
|
||||
/proc/<pid>/ otherwise. It greatly complicates an intruder's task of gathering
|
||||
information about running processes, whether some daemon runs with elevated
|
||||
privileges, whether other user runs some sensitive program, whether other users
|
||||
run any program at all, etc.
|
||||
|
||||
gid= defines a group authorized to learn processes information otherwise
|
||||
prohibited by hidepid=. If you use some daemon like identd which needs to learn
|
||||
information about processes information, just add identd to this group.
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ An attribute definition is simply:
|
|||
struct attribute {
|
||||
char * name;
|
||||
struct module *owner;
|
||||
mode_t mode;
|
||||
umode_t mode;
|
||||
};
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -225,7 +225,7 @@ struct super_operations {
|
|||
void (*clear_inode) (struct inode *);
|
||||
void (*umount_begin) (struct super_block *);
|
||||
|
||||
int (*show_options)(struct seq_file *, struct vfsmount *);
|
||||
int (*show_options)(struct seq_file *, struct dentry *);
|
||||
|
||||
ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t);
|
||||
ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t);
|
||||
|
|
@ -341,14 +341,14 @@ This describes how the VFS can manipulate an inode in your
|
|||
filesystem. As of kernel 2.6.22, the following members are defined:
|
||||
|
||||
struct inode_operations {
|
||||
int (*create) (struct inode *,struct dentry *,int, struct nameidata *);
|
||||
int (*create) (struct inode *,struct dentry *, umode_t, struct nameidata *);
|
||||
struct dentry * (*lookup) (struct inode *,struct dentry *, struct nameidata *);
|
||||
int (*link) (struct dentry *,struct inode *,struct dentry *);
|
||||
int (*unlink) (struct inode *,struct dentry *);
|
||||
int (*symlink) (struct inode *,struct dentry *,const char *);
|
||||
int (*mkdir) (struct inode *,struct dentry *,int);
|
||||
int (*mkdir) (struct inode *,struct dentry *,umode_t);
|
||||
int (*rmdir) (struct inode *,struct dentry *);
|
||||
int (*mknod) (struct inode *,struct dentry *,int,dev_t);
|
||||
int (*mknod) (struct inode *,struct dentry *,umode_t,dev_t);
|
||||
int (*rename) (struct inode *, struct dentry *,
|
||||
struct inode *, struct dentry *);
|
||||
int (*readlink) (struct dentry *, char __user *,int);
|
||||
|
|
|
|||
|
|
@ -2,9 +2,8 @@ Kernel driver pmbus
|
|||
====================
|
||||
|
||||
Supported chips:
|
||||
* Ericsson BMR45X series
|
||||
DC/DC Converter
|
||||
Prefixes: 'bmr450', 'bmr451', 'bmr453', 'bmr454'
|
||||
* Ericsson BMR453, BMR454
|
||||
Prefixes: 'bmr453', 'bmr454'
|
||||
Addresses scanned: -
|
||||
Datasheet:
|
||||
http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146395
|
||||
|
|
|
|||
|
|
@ -6,6 +6,10 @@ Supported chips:
|
|||
Prefix: 'zl2004'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://www.intersil.com/data/fn/fn6847.pdf
|
||||
* Intersil / Zilker Labs ZL2005
|
||||
Prefix: 'zl2005'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://www.intersil.com/data/fn/fn6848.pdf
|
||||
* Intersil / Zilker Labs ZL2006
|
||||
Prefix: 'zl2006'
|
||||
Addresses scanned: -
|
||||
|
|
@ -30,6 +34,17 @@ Supported chips:
|
|||
Prefix: 'zl6105'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://www.intersil.com/data/fn/fn6906.pdf
|
||||
* Ericsson BMR450, BMR451
|
||||
Prefix: 'bmr450', 'bmr451'
|
||||
Addresses scanned: -
|
||||
Datasheet:
|
||||
http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146401
|
||||
* Ericsson BMR462, BMR463, BMR464
|
||||
Prefixes: 'bmr462', 'bmr463', 'bmr464'
|
||||
Addresses scanned: -
|
||||
Datasheet:
|
||||
http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146256
|
||||
|
||||
|
||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,188 @@
|
|||
ALPS Touchpad Protocol
|
||||
----------------------
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
Currently the ALPS touchpad driver supports four protocol versions in use by
|
||||
ALPS touchpads, called versions 1, 2, 3, and 4. Information about the various
|
||||
protocol versions is contained in the following sections.
|
||||
|
||||
Detection
|
||||
---------
|
||||
|
||||
All ALPS touchpads should respond to the "E6 report" command sequence:
|
||||
E8-E6-E6-E6-E9. An ALPS touchpad should respond with either 00-00-0A or
|
||||
00-00-64.
|
||||
|
||||
If the E6 report is successful, the touchpad model is identified using the "E7
|
||||
report" sequence: E8-E7-E7-E7-E9. The response is the model signature and is
|
||||
matched against known models in the alps_model_data_array.
|
||||
|
||||
With protocol versions 3 and 4, the E7 report model signature is always
|
||||
73-02-64. To differentiate between these versions, the response from the
|
||||
"Enter Command Mode" sequence must be inspected as described below.
|
||||
|
||||
Command Mode
|
||||
------------
|
||||
|
||||
Protocol versions 3 and 4 have a command mode that is used to read and write
|
||||
one-byte device registers in a 16-bit address space. The command sequence
|
||||
EC-EC-EC-E9 places the device in command mode, and the device will respond
|
||||
with 88-07 followed by a third byte. This third byte can be used to determine
|
||||
whether the devices uses the version 3 or 4 protocol.
|
||||
|
||||
To exit command mode, PSMOUSE_CMD_SETSTREAM (EA) is sent to the touchpad.
|
||||
|
||||
While in command mode, register addresses can be set by first sending a
|
||||
specific command, either EC for v3 devices or F5 for v4 devices. Then the
|
||||
address is sent one nibble at a time, where each nibble is encoded as a
|
||||
command with optional data. This enoding differs slightly between the v3 and
|
||||
v4 protocols.
|
||||
|
||||
Once an address has been set, the addressed register can be read by sending
|
||||
PSMOUSE_CMD_GETINFO (E9). The first two bytes of the response contains the
|
||||
address of the register being read, and the third contains the value of the
|
||||
register. Registers are written by writing the value one nibble at a time
|
||||
using the same encoding used for addresses.
|
||||
|
||||
Packet Format
|
||||
-------------
|
||||
|
||||
In the following tables, the following notation is used.
|
||||
|
||||
CAPITALS = stick, miniscules = touchpad
|
||||
|
||||
?'s can have different meanings on different models, such as wheel rotation,
|
||||
extra buttons, stick buttons on a dualpoint, etc.
|
||||
|
||||
PS/2 packet format
|
||||
------------------
|
||||
|
||||
byte 0: 0 0 YSGN XSGN 1 M R L
|
||||
byte 1: X7 X6 X5 X4 X3 X2 X1 X0
|
||||
byte 2: Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0
|
||||
|
||||
Note that the device never signals overflow condition.
|
||||
|
||||
ALPS Absolute Mode - Protocol Verion 1
|
||||
--------------------------------------
|
||||
|
||||
byte 0: 1 0 0 0 1 x9 x8 x7
|
||||
byte 1: 0 x6 x5 x4 x3 x2 x1 x0
|
||||
byte 2: 0 ? ? l r ? fin ges
|
||||
byte 3: 0 ? ? ? ? y9 y8 y7
|
||||
byte 4: 0 y6 y5 y4 y3 y2 y1 y0
|
||||
byte 5: 0 z6 z5 z4 z3 z2 z1 z0
|
||||
|
||||
ALPS Absolute Mode - Protocol Version 2
|
||||
---------------------------------------
|
||||
|
||||
byte 0: 1 ? ? ? 1 ? ? ?
|
||||
byte 1: 0 x6 x5 x4 x3 x2 x1 x0
|
||||
byte 2: 0 x10 x9 x8 x7 ? fin ges
|
||||
byte 3: 0 y9 y8 y7 1 M R L
|
||||
byte 4: 0 y6 y5 y4 y3 y2 y1 y0
|
||||
byte 5: 0 z6 z5 z4 z3 z2 z1 z0
|
||||
|
||||
Dualpoint device -- interleaved packet format
|
||||
---------------------------------------------
|
||||
|
||||
byte 0: 1 1 0 0 1 1 1 1
|
||||
byte 1: 0 x6 x5 x4 x3 x2 x1 x0
|
||||
byte 2: 0 x10 x9 x8 x7 0 fin ges
|
||||
byte 3: 0 0 YSGN XSGN 1 1 1 1
|
||||
byte 4: X7 X6 X5 X4 X3 X2 X1 X0
|
||||
byte 5: Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0
|
||||
byte 6: 0 y9 y8 y7 1 m r l
|
||||
byte 7: 0 y6 y5 y4 y3 y2 y1 y0
|
||||
byte 8: 0 z6 z5 z4 z3 z2 z1 z0
|
||||
|
||||
ALPS Absolute Mode - Protocol Version 3
|
||||
---------------------------------------
|
||||
|
||||
ALPS protocol version 3 has three different packet formats. The first two are
|
||||
associated with touchpad events, and the third is associatd with trackstick
|
||||
events.
|
||||
|
||||
The first type is the touchpad position packet.
|
||||
|
||||
byte 0: 1 ? x1 x0 1 1 1 1
|
||||
byte 1: 0 x10 x9 x8 x7 x6 x5 x4
|
||||
byte 2: 0 y10 y9 y8 y7 y6 y5 y4
|
||||
byte 3: 0 M R L 1 m r l
|
||||
byte 4: 0 mt x3 x2 y3 y2 y1 y0
|
||||
byte 5: 0 z6 z5 z4 z3 z2 z1 z0
|
||||
|
||||
Note that for some devices the trackstick buttons are reported in this packet,
|
||||
and on others it is reported in the trackstick packets.
|
||||
|
||||
The second packet type contains bitmaps representing the x and y axes. In the
|
||||
bitmaps a given bit is set if there is a finger covering that position on the
|
||||
given axis. Thus the bitmap packet can be used for low-resolution multi-touch
|
||||
data, although finger tracking is not possible. This packet also encodes the
|
||||
number of contacts (f1 and f0 in the table below).
|
||||
|
||||
byte 0: 1 1 x1 x0 1 1 1 1
|
||||
byte 1: 0 x8 x7 x6 x5 x4 x3 x2
|
||||
byte 2: 0 y7 y6 y5 y4 y3 y2 y1
|
||||
byte 3: 0 y10 y9 y8 1 1 1 1
|
||||
byte 4: 0 x14 x13 x12 x11 x10 x9 y0
|
||||
byte 5: 0 1 ? ? ? ? f1 f0
|
||||
|
||||
This packet only appears after a position packet with the mt bit set, and
|
||||
ususally only appears when there are two or more contacts (although
|
||||
ocassionally it's seen with only a single contact).
|
||||
|
||||
The final v3 packet type is the trackstick packet.
|
||||
|
||||
byte 0: 1 1 x7 y7 1 1 1 1
|
||||
byte 1: 0 x6 x5 x4 x3 x2 x1 x0
|
||||
byte 2: 0 y6 y5 y4 y3 y2 y1 y0
|
||||
byte 3: 0 1 0 0 1 0 0 0
|
||||
byte 4: 0 z4 z3 z2 z1 z0 ? ?
|
||||
byte 5: 0 0 1 1 1 1 1 1
|
||||
|
||||
ALPS Absolute Mode - Protocol Version 4
|
||||
---------------------------------------
|
||||
|
||||
Protocol version 4 has an 8-byte packet format.
|
||||
|
||||
byte 0: 1 ? x1 x0 1 1 1 1
|
||||
byte 1: 0 x10 x9 x8 x7 x6 x5 x4
|
||||
byte 2: 0 y10 y9 y8 y7 y6 y5 y4
|
||||
byte 3: 0 1 x3 x2 y3 y2 y1 y0
|
||||
byte 4: 0 ? ? ? 1 ? r l
|
||||
byte 5: 0 z6 z5 z4 z3 z2 z1 z0
|
||||
byte 6: bitmap data (described below)
|
||||
byte 7: bitmap data (described below)
|
||||
|
||||
The last two bytes represent a partial bitmap packet, with 3 full packets
|
||||
required to construct a complete bitmap packet. Once assembled, the 6-byte
|
||||
bitmap packet has the following format:
|
||||
|
||||
byte 0: 0 1 x7 x6 x5 x4 x3 x2
|
||||
byte 1: 0 x1 x0 y4 y3 y2 y1 y0
|
||||
byte 2: 0 0 ? x14 x13 x12 x11 x10
|
||||
byte 3: 0 x9 x8 y9 y8 y7 y6 y5
|
||||
byte 4: 0 0 0 0 0 0 0 0
|
||||
byte 5: 0 0 0 0 0 0 0 y10
|
||||
|
||||
There are several things worth noting here.
|
||||
|
||||
1) In the bitmap data, bit 6 of byte 0 serves as a sync byte to
|
||||
identify the first fragment of a bitmap packet.
|
||||
|
||||
2) The bitmaps represent the same data as in the v3 bitmap packets, although
|
||||
the packet layout is different.
|
||||
|
||||
3) There doesn't seem to be a count of the contact points anywhere in the v4
|
||||
protocol packets. Deriving a count of contact points must be done by
|
||||
analyzing the bitmaps.
|
||||
|
||||
4) There is a 3 to 1 ratio of position packets to bitmap packets. Therefore
|
||||
MT position can only be updated for every third ST position update, and
|
||||
the count of contact points can only be updated every third packet as
|
||||
well.
|
||||
|
||||
So far no v4 devices with tracksticks have been encountered.
|
||||
|
|
@ -0,0 +1,103 @@
|
|||
Driver for tilt-switches connected via GPIOs
|
||||
============================================
|
||||
|
||||
Generic driver to read data from tilt switches connected via gpios.
|
||||
Orientation can be provided by one or more than one tilt switches,
|
||||
i.e. each tilt switch providing one axis, and the number of axes
|
||||
is also not limited.
|
||||
|
||||
|
||||
Data structures:
|
||||
----------------
|
||||
|
||||
The array of struct gpio in the gpios field is used to list the gpios
|
||||
that represent the current tilt state.
|
||||
|
||||
The array of struct gpio_tilt_axis describes the axes that are reported
|
||||
to the input system. The values set therein are used for the
|
||||
input_set_abs_params calls needed to init the axes.
|
||||
|
||||
The array of struct gpio_tilt_state maps gpio states to the corresponding
|
||||
values to report. The gpio state is represented as a bitfield where the
|
||||
bit-index corresponds to the index of the gpio in the struct gpio array.
|
||||
In the same manner the values stored in the axes array correspond to
|
||||
the elements of the gpio_tilt_axis-array.
|
||||
|
||||
|
||||
Example:
|
||||
--------
|
||||
|
||||
Example configuration for a single TS1003 tilt switch that rotates around
|
||||
one axis in 4 steps and emitts the current tilt via two GPIOs.
|
||||
|
||||
static int sg060_tilt_enable(struct device *dev) {
|
||||
/* code to enable the sensors */
|
||||
};
|
||||
|
||||
static void sg060_tilt_disable(struct device *dev) {
|
||||
/* code to disable the sensors */
|
||||
};
|
||||
|
||||
static struct gpio sg060_tilt_gpios[] = {
|
||||
{ SG060_TILT_GPIO_SENSOR1, GPIOF_IN, "tilt_sensor1" },
|
||||
{ SG060_TILT_GPIO_SENSOR2, GPIOF_IN, "tilt_sensor2" },
|
||||
};
|
||||
|
||||
static struct gpio_tilt_state sg060_tilt_states[] = {
|
||||
{
|
||||
.gpios = (0 << 1) | (0 << 0),
|
||||
.axes = (int[]) {
|
||||
0,
|
||||
},
|
||||
}, {
|
||||
.gpios = (0 << 1) | (1 << 0),
|
||||
.axes = (int[]) {
|
||||
1, /* 90 degrees */
|
||||
},
|
||||
}, {
|
||||
.gpios = (1 << 1) | (1 << 0),
|
||||
.axes = (int[]) {
|
||||
2, /* 180 degrees */
|
||||
},
|
||||
}, {
|
||||
.gpios = (1 << 1) | (0 << 0),
|
||||
.axes = (int[]) {
|
||||
3, /* 270 degrees */
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
static struct gpio_tilt_axis sg060_tilt_axes[] = {
|
||||
{
|
||||
.axis = ABS_RY,
|
||||
.min = 0,
|
||||
.max = 3,
|
||||
.fuzz = 0,
|
||||
.flat = 0,
|
||||
},
|
||||
};
|
||||
|
||||
static struct gpio_tilt_platform_data sg060_tilt_pdata= {
|
||||
.gpios = sg060_tilt_gpios,
|
||||
.nr_gpios = ARRAY_SIZE(sg060_tilt_gpios),
|
||||
|
||||
.axes = sg060_tilt_axes,
|
||||
.nr_axes = ARRAY_SIZE(sg060_tilt_axes),
|
||||
|
||||
.states = sg060_tilt_states,
|
||||
.nr_states = ARRAY_SIZE(sg060_tilt_states),
|
||||
|
||||
.debounce_interval = 100,
|
||||
|
||||
.poll_interval = 1000,
|
||||
.enable = sg060_tilt_enable,
|
||||
.disable = sg060_tilt_disable,
|
||||
};
|
||||
|
||||
static struct platform_device sg060_device_tilt = {
|
||||
.name = "gpio-tilt-polled",
|
||||
.id = -1,
|
||||
.dev = {
|
||||
.platform_data = &sg060_tilt_pdata,
|
||||
},
|
||||
};
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
Copyright (C) 2002-2010 Sentelic Corporation.
|
||||
Last update: Jan-13-2010
|
||||
Copyright (C) 2002-2011 Sentelic Corporation.
|
||||
Last update: Dec-07-2011
|
||||
|
||||
==============================================================================
|
||||
* Finger Sensing Pad Intellimouse Mode(scrolling wheel, 4th and 5th buttons)
|
||||
|
|
@ -140,6 +140,7 @@ BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------
|
|||
Byte 1: Bit7~Bit6 => 00, Normal data packet
|
||||
=> 01, Absolute coordination packet
|
||||
=> 10, Notify packet
|
||||
=> 11, Normal data packet with on-pad click
|
||||
Bit5 => Valid bit, 0 means that the coordinate is invalid or finger up.
|
||||
When both fingers are up, the last two reports have zero valid
|
||||
bit.
|
||||
|
|
@ -164,6 +165,7 @@ BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------
|
|||
Byte 1: Bit7~Bit6 => 00, Normal data packet
|
||||
=> 01, Absolute coordinates packet
|
||||
=> 10, Notify packet
|
||||
=> 11, Normal data packet with on-pad click
|
||||
Bit5 => Valid bit, 0 means that the coordinate is invalid or finger up.
|
||||
When both fingers are up, the last two reports have zero valid
|
||||
bit.
|
||||
|
|
@ -188,6 +190,7 @@ BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------
|
|||
Byte 1: Bit7~Bit6 => 00, Normal data packet
|
||||
=> 01, Absolute coordinates packet
|
||||
=> 10, Notify packet
|
||||
=> 11, Normal data packet with on-pad click
|
||||
Bit5 => 1
|
||||
Bit4 => when in absolute coordinates mode (valid when EN_PKT_GO is 1):
|
||||
0: left button is generated by the on-pad command
|
||||
|
|
@ -205,7 +208,7 @@ Byte 4: Bit7 => scroll right button
|
|||
Bit6 => scroll left button
|
||||
Bit5 => scroll down button
|
||||
Bit4 => scroll up button
|
||||
* Note that if gesture and additional buttoni (Bit4~Bit7)
|
||||
* Note that if gesture and additional button (Bit4~Bit7)
|
||||
happen at the same time, the button information will not
|
||||
be sent.
|
||||
Bit3~Bit0 => Reserved
|
||||
|
|
@ -227,6 +230,7 @@ BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------
|
|||
Byte 1: Bit7~Bit6 => 00, Normal data packet
|
||||
=> 01, Absolute coordinates packet
|
||||
=> 10, Notify packet
|
||||
=> 11, Normal data packet with on-pad click
|
||||
Bit5 => Valid bit, 0 means that the coordinate is invalid or finger up.
|
||||
When both fingers are up, the last two reports have zero valid
|
||||
bit.
|
||||
|
|
@ -253,6 +257,7 @@ BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------
|
|||
Byte 1: Bit7~Bit6 => 00, Normal data packet
|
||||
=> 01, Absolute coordination packet
|
||||
=> 10, Notify packet
|
||||
=> 11, Normal data packet with on-pad click
|
||||
Bit5 => Valid bit, 0 means that the coordinate is invalid or finger up.
|
||||
When both fingers are up, the last two reports have zero valid
|
||||
bit.
|
||||
|
|
@ -279,8 +284,9 @@ BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------
|
|||
Byte 1: Bit7~Bit6 => 00, Normal data packet
|
||||
=> 01, Absolute coordination packet
|
||||
=> 10, Notify packet
|
||||
=> 11, Normal data packet with on-pad click
|
||||
Bit5 => 1
|
||||
Bit4 => when in absolute coordinate mode (valid when EN_PKT_GO is 1):
|
||||
Bit4 => when in absolute coordinates mode (valid when EN_PKT_GO is 1):
|
||||
0: left button is generated by the on-pad command
|
||||
1: left button is generated by the external button
|
||||
Bit3 => 1
|
||||
|
|
@ -306,6 +312,110 @@ Sample sequence of Multi-finger, Multi-coordinate mode:
|
|||
notify packet (valid bit == 1), abs pkt 1, abs pkt 2, abs pkt 1,
|
||||
abs pkt 2, ..., notify packet (valid bit == 0)
|
||||
|
||||
==============================================================================
|
||||
* Absolute position for STL3888-Cx and STL3888-Dx.
|
||||
==============================================================================
|
||||
Single Finger, Absolute Coordinate Mode (SFAC)
|
||||
Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
|
||||
BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------|
|
||||
1 |0|1|0|P|1|M|R|L| 2 |X|X|X|X|X|X|X|X| 3 |Y|Y|Y|Y|Y|Y|Y|Y| 4 |r|l|B|F|X|X|Y|Y|
|
||||
|---------------| |---------------| |---------------| |---------------|
|
||||
|
||||
Byte 1: Bit7~Bit6 => 00, Normal data packet
|
||||
=> 01, Absolute coordinates packet
|
||||
=> 10, Notify packet
|
||||
Bit5 => Coordinate mode(always 0 in SFAC mode):
|
||||
0: single-finger absolute coordinates (SFAC) mode
|
||||
1: multi-finger, multiple coordinates (MFMC) mode
|
||||
Bit4 => 0: The LEFT button is generated by on-pad command (OPC)
|
||||
1: The LEFT button is generated by external button
|
||||
Default is 1 even if the LEFT button is not pressed.
|
||||
Bit3 => Always 1, as specified by PS/2 protocol.
|
||||
Bit2 => Middle Button, 1 is pressed, 0 is not pressed.
|
||||
Bit1 => Right Button, 1 is pressed, 0 is not pressed.
|
||||
Bit0 => Left Button, 1 is pressed, 0 is not pressed.
|
||||
Byte 2: X coordinate (xpos[9:2])
|
||||
Byte 3: Y coordinate (ypos[9:2])
|
||||
Byte 4: Bit1~Bit0 => Y coordinate (xpos[1:0])
|
||||
Bit3~Bit2 => X coordinate (ypos[1:0])
|
||||
Bit4 => 4th mouse button(forward one page)
|
||||
Bit5 => 5th mouse button(backward one page)
|
||||
Bit6 => scroll left button
|
||||
Bit7 => scroll right button
|
||||
|
||||
Multi Finger, Multiple Coordinates Mode (MFMC):
|
||||
Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
|
||||
BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------|
|
||||
1 |0|1|1|P|1|F|R|L| 2 |X|X|X|X|X|X|X|X| 3 |Y|Y|Y|Y|Y|Y|Y|Y| 4 |r|l|B|F|X|X|Y|Y|
|
||||
|---------------| |---------------| |---------------| |---------------|
|
||||
|
||||
Byte 1: Bit7~Bit6 => 00, Normal data packet
|
||||
=> 01, Absolute coordination packet
|
||||
=> 10, Notify packet
|
||||
Bit5 => Coordinate mode (always 1 in MFMC mode):
|
||||
0: single-finger absolute coordinates (SFAC) mode
|
||||
1: multi-finger, multiple coordinates (MFMC) mode
|
||||
Bit4 => 0: The LEFT button is generated by on-pad command (OPC)
|
||||
1: The LEFT button is generated by external button
|
||||
Default is 1 even if the LEFT button is not pressed.
|
||||
Bit3 => Always 1, as specified by PS/2 protocol.
|
||||
Bit2 => Finger index, 0 is the first finger, 1 is the second finger.
|
||||
If bit 1 and 0 are all 1 and bit 4 is 0, the middle external
|
||||
button is pressed.
|
||||
Bit1 => Right Button, 1 is pressed, 0 is not pressed.
|
||||
Bit0 => Left Button, 1 is pressed, 0 is not pressed.
|
||||
Byte 2: X coordinate (xpos[9:2])
|
||||
Byte 3: Y coordinate (ypos[9:2])
|
||||
Byte 4: Bit1~Bit0 => Y coordinate (xpos[1:0])
|
||||
Bit3~Bit2 => X coordinate (ypos[1:0])
|
||||
Bit4 => 4th mouse button(forward one page)
|
||||
Bit5 => 5th mouse button(backward one page)
|
||||
Bit6 => scroll left button
|
||||
Bit7 => scroll right button
|
||||
|
||||
When one of the two fingers is up, the device will output four consecutive
|
||||
MFMC#0 report packets with zero X and Y to represent 1st finger is up or
|
||||
four consecutive MFMC#1 report packets with zero X and Y to represent that
|
||||
the 2nd finger is up. On the other hand, if both fingers are up, the device
|
||||
will output four consecutive single-finger, absolute coordinate(SFAC) packets
|
||||
with zero X and Y.
|
||||
|
||||
Notify Packet for STL3888-Cx/Dx
|
||||
Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
|
||||
BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------|
|
||||
1 |1|0|0|P|1|M|R|L| 2 |C|C|C|C|C|C|C|C| 3 |0|0|F|F|0|0|0|i| 4 |r|l|u|d|0|0|0|0|
|
||||
|---------------| |---------------| |---------------| |---------------|
|
||||
|
||||
Byte 1: Bit7~Bit6 => 00, Normal data packet
|
||||
=> 01, Absolute coordinates packet
|
||||
=> 10, Notify packet
|
||||
Bit5 => Always 0
|
||||
Bit4 => 0: The LEFT button is generated by on-pad command(OPC)
|
||||
1: The LEFT button is generated by external button
|
||||
Default is 1 even if the LEFT button is not pressed.
|
||||
Bit3 => 1
|
||||
Bit2 => Middle Button, 1 is pressed, 0 is not pressed.
|
||||
Bit1 => Right Button, 1 is pressed, 0 is not pressed.
|
||||
Bit0 => Left Button, 1 is pressed, 0 is not pressed.
|
||||
Byte 2: Message type:
|
||||
0xba => gesture information
|
||||
0xc0 => one finger hold-rotating gesture
|
||||
Byte 3: The first parameter for the received message:
|
||||
0xba => gesture ID (refer to the 'Gesture ID' section)
|
||||
0xc0 => region ID
|
||||
Byte 4: The second parameter for the received message:
|
||||
0xba => N/A
|
||||
0xc0 => finger up/down information
|
||||
|
||||
Sample sequence of Multi-finger, Multi-coordinates mode:
|
||||
|
||||
notify packet (valid bit == 1), MFMC packet 1 (byte 1, bit 2 == 0),
|
||||
MFMC packet 2 (byte 1, bit 2 == 1), MFMC packet 1, MFMC packet 2,
|
||||
..., notify packet (valid bit == 0)
|
||||
|
||||
That is, when the device is in MFMC mode, the host will receive
|
||||
interleaved absolute coordinate packets for each finger.
|
||||
|
||||
==============================================================================
|
||||
* FSP Enable/Disable packet
|
||||
==============================================================================
|
||||
|
|
@ -348,9 +458,10 @@ http://www.computer-engineering.org/ps2mouse/
|
|||
==============================================================================
|
||||
1. Identify FSP by reading device ID(0x00) and version(0x01) register
|
||||
|
||||
2. Determine number of buttons by reading status2 (0x0b) register
|
||||
2a. For FSP version < STL3888 Cx, determine number of buttons by reading
|
||||
the 'test mode status' (0x20) register:
|
||||
|
||||
buttons = reg[0x0b] & 0x30
|
||||
buttons = reg[0x20] & 0x30
|
||||
|
||||
if buttons == 0x30 or buttons == 0x20:
|
||||
# two/four buttons
|
||||
|
|
@ -365,6 +476,10 @@ http://www.computer-engineering.org/ps2mouse/
|
|||
Refer to 'Finger Sensing Pad PS/2 Mouse Intellimouse'
|
||||
section A for packet parsing detail
|
||||
|
||||
2b. For FSP version >= STL3888 Cx:
|
||||
Refer to 'Finger Sensing Pad PS/2 Mouse Intellimouse'
|
||||
section A for packet parsing detail (ignore byte 4, bit ~ 7)
|
||||
|
||||
==============================================================================
|
||||
* Programming Sequence for Register Reading/Writing
|
||||
==============================================================================
|
||||
|
|
@ -374,7 +489,7 @@ Register inversion requirement:
|
|||
Following values needed to be inverted(the '~' operator in C) before being
|
||||
sent to FSP:
|
||||
|
||||
0xe9, 0xee, 0xf2 and 0xff.
|
||||
0xe8, 0xe9, 0xee, 0xf2, 0xf3 and 0xff.
|
||||
|
||||
Register swapping requirement:
|
||||
|
||||
|
|
@ -415,7 +530,18 @@ Register reading sequence:
|
|||
|
||||
8. send 0xe9(status request) PS/2 command to FSP;
|
||||
|
||||
9. the response read from FSP should be the requested register value.
|
||||
9. the 4th byte of the response read from FSP should be the
|
||||
requested register value(?? indicates don't care byte):
|
||||
|
||||
host: 0xe9
|
||||
3888: 0xfa (??) (??) (val)
|
||||
|
||||
* Note that since the Cx release, the hardware will return 1's
|
||||
complement of the register value at the 3rd byte of status request
|
||||
result:
|
||||
|
||||
host: 0xe9
|
||||
3888: 0xfa (??) (~val) (val)
|
||||
|
||||
Register writing sequence:
|
||||
|
||||
|
|
@ -465,71 +591,194 @@ Register writing sequence:
|
|||
|
||||
9. the register writing sequence is completed.
|
||||
|
||||
* Note that since the Cx release, the hardware will return 1's
|
||||
complement of the register value at the 3rd byte of status request
|
||||
result. Host can optionally send another 0xe9 (status request) PS/2
|
||||
command to FSP at the end of register writing to verify that the
|
||||
register writing operation is successful (?? indicates don't care
|
||||
byte):
|
||||
|
||||
host: 0xe9
|
||||
3888: 0xfa (??) (~val) (val)
|
||||
|
||||
==============================================================================
|
||||
* Programming Sequence for Page Register Reading/Writing
|
||||
==============================================================================
|
||||
|
||||
In order to overcome the limitation of maximum number of registers
|
||||
supported, the hardware separates register into different groups called
|
||||
'pages.' Each page is able to include up to 255 registers.
|
||||
|
||||
The default page after power up is 0x82; therefore, if one has to get
|
||||
access to register 0x8301, one has to use following sequence to switch
|
||||
to page 0x83, then start reading/writing from/to offset 0x01 by using
|
||||
the register read/write sequence described in previous section.
|
||||
|
||||
Page register reading sequence:
|
||||
|
||||
1. send 0xf3 PS/2 command to FSP;
|
||||
|
||||
2. send 0x66 PS/2 command to FSP;
|
||||
|
||||
3. send 0x88 PS/2 command to FSP;
|
||||
|
||||
4. send 0xf3 PS/2 command to FSP;
|
||||
|
||||
5. send 0x83 PS/2 command to FSP;
|
||||
|
||||
6. send 0x88 PS/2 command to FSP;
|
||||
|
||||
7. send 0xe9(status request) PS/2 command to FSP;
|
||||
|
||||
8. the response read from FSP should be the requested page value.
|
||||
|
||||
Page register writing sequence:
|
||||
|
||||
1. send 0xf3 PS/2 command to FSP;
|
||||
|
||||
2. send 0x38 PS/2 command to FSP;
|
||||
|
||||
3. send 0x88 PS/2 command to FSP;
|
||||
|
||||
4. send 0xf3 PS/2 command to FSP;
|
||||
|
||||
5. if the page address being written is not required to be
|
||||
inverted(refer to the 'Register inversion requirement' section),
|
||||
goto step 6
|
||||
|
||||
5a. send 0x47 PS/2 command to FSP;
|
||||
|
||||
5b. send the inverted page address to FSP and goto step 9;
|
||||
|
||||
6. if the page address being written is not required to be
|
||||
swapped(refer to the 'Register swapping requirement' section),
|
||||
goto step 7
|
||||
|
||||
6a. send 0x44 PS/2 command to FSP;
|
||||
|
||||
6b. send the swapped page address to FSP and goto step 9;
|
||||
|
||||
7. send 0x33 PS/2 command to FSP;
|
||||
|
||||
8. send the page address to FSP;
|
||||
|
||||
9. the page register writing sequence is completed.
|
||||
|
||||
==============================================================================
|
||||
* Gesture ID
|
||||
==============================================================================
|
||||
|
||||
Unlike other devices which sends multiple fingers' coordinates to host,
|
||||
FSP processes multiple fingers' coordinates internally and convert them
|
||||
into a 8 bits integer, namely 'Gesture ID.' Following is a list of
|
||||
supported gesture IDs:
|
||||
|
||||
ID Description
|
||||
0x86 2 finger straight up
|
||||
0x82 2 finger straight down
|
||||
0x80 2 finger straight right
|
||||
0x84 2 finger straight left
|
||||
0x8f 2 finger zoom in
|
||||
0x8b 2 finger zoom out
|
||||
0xc0 2 finger curve, counter clockwise
|
||||
0xc4 2 finger curve, clockwise
|
||||
0x2e 3 finger straight up
|
||||
0x2a 3 finger straight down
|
||||
0x28 3 finger straight right
|
||||
0x2c 3 finger straight left
|
||||
0x38 palm
|
||||
|
||||
==============================================================================
|
||||
* Register Listing
|
||||
==============================================================================
|
||||
|
||||
Registers are represented in 16 bits values. The higher 8 bits represent
|
||||
the page address and the lower 8 bits represent the relative offset within
|
||||
that particular page. Refer to the 'Programming Sequence for Page Register
|
||||
Reading/Writing' section for instructions on how to change current page
|
||||
address.
|
||||
|
||||
offset width default r/w name
|
||||
0x00 bit7~bit0 0x01 RO device ID
|
||||
0x8200 bit7~bit0 0x01 RO device ID
|
||||
|
||||
0x01 bit7~bit0 0xc0 RW version ID
|
||||
0x8201 bit7~bit0 RW version ID
|
||||
0xc1: STL3888 Ax
|
||||
0xd0 ~ 0xd2: STL3888 Bx
|
||||
0xe0 ~ 0xe1: STL3888 Cx
|
||||
0xe2 ~ 0xe3: STL3888 Dx
|
||||
|
||||
0x02 bit7~bit0 0x01 RO vendor ID
|
||||
0x8202 bit7~bit0 0x01 RO vendor ID
|
||||
|
||||
0x03 bit7~bit0 0x01 RO product ID
|
||||
0x8203 bit7~bit0 0x01 RO product ID
|
||||
|
||||
0x04 bit3~bit0 0x01 RW revision ID
|
||||
0x8204 bit3~bit0 0x01 RW revision ID
|
||||
|
||||
0x0b RO test mode status 1
|
||||
bit3 1 RO 0: rotate 180 degree, 1: no rotation
|
||||
0x820b test mode status 1
|
||||
bit3 1 RO 0: rotate 180 degree
|
||||
1: no rotation
|
||||
*only supported by H/W prior to Cx
|
||||
|
||||
bit5~bit4 RO number of buttons
|
||||
11 => 2, lbtn/rbtn
|
||||
10 => 4, lbtn/rbtn/scru/scrd
|
||||
01 => 6, lbtn/rbtn/scru/scrd/scrl/scrr
|
||||
00 => 6, lbtn/rbtn/scru/scrd/fbtn/bbtn
|
||||
0x820f register file page control
|
||||
bit2 0 RW 1: rotate 180 degree
|
||||
0: no rotation
|
||||
*supported since Cx
|
||||
|
||||
0x0f RW register file page control
|
||||
bit0 0 RW 1 to enable page 1 register files
|
||||
*only supported by H/W prior to Cx
|
||||
|
||||
0x10 RW system control 1
|
||||
0x8210 RW system control 1
|
||||
bit0 1 RW Reserved, must be 1
|
||||
bit1 0 RW Reserved, must be 0
|
||||
bit4 1 RW Reserved, must be 0
|
||||
bit5 0 RW register clock gating enable
|
||||
bit4 0 RW Reserved, must be 0
|
||||
bit5 1 RW register clock gating enable
|
||||
0: read only, 1: read/write enable
|
||||
(Note that following registers does not require clock gating being
|
||||
enabled prior to write: 05 06 07 08 09 0c 0f 10 11 12 16 17 18 23 2e
|
||||
40 41 42 43. In addition to that, this bit must be 1 when gesture
|
||||
mode is enabled)
|
||||
|
||||
0x31 RW on-pad command detection
|
||||
0x8220 test mode status
|
||||
bit5~bit4 RO number of buttons
|
||||
11 => 2, lbtn/rbtn
|
||||
10 => 4, lbtn/rbtn/scru/scrd
|
||||
01 => 6, lbtn/rbtn/scru/scrd/scrl/scrr
|
||||
00 => 6, lbtn/rbtn/scru/scrd/fbtn/bbtn
|
||||
*only supported by H/W prior to Cx
|
||||
|
||||
0x8231 RW on-pad command detection
|
||||
bit7 0 RW on-pad command left button down tag
|
||||
enable
|
||||
0: disable, 1: enable
|
||||
*only supported by H/W prior to Cx
|
||||
|
||||
0x34 RW on-pad command control 5
|
||||
0x8234 RW on-pad command control 5
|
||||
bit4~bit0 0x05 RW XLO in 0s/4/1, so 03h = 0010.1b = 2.5
|
||||
(Note that position unit is in 0.5 scanline)
|
||||
*only supported by H/W prior to Cx
|
||||
|
||||
bit7 0 RW on-pad tap zone enable
|
||||
0: disable, 1: enable
|
||||
*only supported by H/W prior to Cx
|
||||
|
||||
0x35 RW on-pad command control 6
|
||||
0x8235 RW on-pad command control 6
|
||||
bit4~bit0 0x1d RW XHI in 0s/4/1, so 19h = 1100.1b = 12.5
|
||||
(Note that position unit is in 0.5 scanline)
|
||||
*only supported by H/W prior to Cx
|
||||
|
||||
0x36 RW on-pad command control 7
|
||||
0x8236 RW on-pad command control 7
|
||||
bit4~bit0 0x04 RW YLO in 0s/4/1, so 03h = 0010.1b = 2.5
|
||||
(Note that position unit is in 0.5 scanline)
|
||||
*only supported by H/W prior to Cx
|
||||
|
||||
0x37 RW on-pad command control 8
|
||||
0x8237 RW on-pad command control 8
|
||||
bit4~bit0 0x13 RW YHI in 0s/4/1, so 11h = 1000.1b = 8.5
|
||||
(Note that position unit is in 0.5 scanline)
|
||||
*only supported by H/W prior to Cx
|
||||
|
||||
0x40 RW system control 5
|
||||
0x8240 RW system control 5
|
||||
bit1 0 RW FSP Intellimouse mode enable
|
||||
0: disable, 1: enable
|
||||
*only supported by H/W prior to Cx
|
||||
|
||||
bit2 0 RW movement + abs. coordinate mode enable
|
||||
0: disable, 1: enable
|
||||
|
|
@ -537,6 +786,7 @@ offset width default r/w name
|
|||
bit 1 is not set. However, the format is different from that of bit 1.
|
||||
In addition, when bit 1 and bit 2 are set at the same time, bit 2 will
|
||||
override bit 1.)
|
||||
*only supported by H/W prior to Cx
|
||||
|
||||
bit3 0 RW abs. coordinate only mode enable
|
||||
0: disable, 1: enable
|
||||
|
|
@ -544,9 +794,11 @@ offset width default r/w name
|
|||
bit 1 is not set. However, the format is different from that of bit 1.
|
||||
In addition, when bit 1, bit 2 and bit 3 are set at the same time,
|
||||
bit 3 will override bit 1 and 2.)
|
||||
*only supported by H/W prior to Cx
|
||||
|
||||
bit5 0 RW auto switch enable
|
||||
0: disable, 1: enable
|
||||
*only supported by H/W prior to Cx
|
||||
|
||||
bit6 0 RW G0 abs. + notify packet format enable
|
||||
0: disable, 1: enable
|
||||
|
|
@ -554,18 +806,68 @@ offset width default r/w name
|
|||
bit 2 and 3. That is, if any of those bit is 1, host will receive
|
||||
absolute coordinates; otherwise, host only receives packets with
|
||||
relative coordinate.)
|
||||
*only supported by H/W prior to Cx
|
||||
|
||||
bit7 0 RW EN_PS2_F2: PS/2 gesture mode 2nd
|
||||
finger packet enable
|
||||
0: disable, 1: enable
|
||||
*only supported by H/W prior to Cx
|
||||
|
||||
0x43 RW on-pad control
|
||||
0x8243 RW on-pad control
|
||||
bit0 0 RW on-pad control enable
|
||||
0: disable, 1: enable
|
||||
(Note that if this bit is cleared, bit 3/5 will be ineffective)
|
||||
*only supported by H/W prior to Cx
|
||||
|
||||
bit3 0 RW on-pad fix vertical scrolling enable
|
||||
0: disable, 1: enable
|
||||
*only supported by H/W prior to Cx
|
||||
|
||||
bit5 0 RW on-pad fix horizontal scrolling enable
|
||||
0: disable, 1: enable
|
||||
*only supported by H/W prior to Cx
|
||||
|
||||
0x8290 RW software control register 1
|
||||
bit0 0 RW absolute coordination mode
|
||||
0: disable, 1: enable
|
||||
*supported since Cx
|
||||
|
||||
bit1 0 RW gesture ID output
|
||||
0: disable, 1: enable
|
||||
*supported since Cx
|
||||
|
||||
bit2 0 RW two fingers' coordinates output
|
||||
0: disable, 1: enable
|
||||
*supported since Cx
|
||||
|
||||
bit3 0 RW finger up one packet output
|
||||
0: disable, 1: enable
|
||||
*supported since Cx
|
||||
|
||||
bit4 0 RW absolute coordination continuous mode
|
||||
0: disable, 1: enable
|
||||
*supported since Cx
|
||||
|
||||
bit6~bit5 00 RW gesture group selection
|
||||
00: basic
|
||||
01: suite
|
||||
10: suite pro
|
||||
11: advanced
|
||||
*supported since Cx
|
||||
|
||||
bit7 0 RW Bx packet output compatible mode
|
||||
0: disable, 1: enable *supported since Cx
|
||||
*supported since Cx
|
||||
|
||||
|
||||
0x833d RW on-pad command control 1
|
||||
bit7 1 RW on-pad command detection enable
|
||||
0: disable, 1: enable
|
||||
*supported since Cx
|
||||
|
||||
0x833e RW on-pad command detection
|
||||
bit7 0 RW on-pad command left button down tag
|
||||
enable. Works only in H/W based PS/2
|
||||
data packet mode.
|
||||
0: disable, 1: enable
|
||||
*supported since Cx
|
||||
|
|
|
|||
|
|
@ -17,8 +17,8 @@ You can use common commands, such as cp and scp, to copy the
|
|||
memory image to a dump file on the local disk, or across the network to
|
||||
a remote system.
|
||||
|
||||
Kdump and kexec are currently supported on the x86, x86_64, ppc64 and ia64
|
||||
architectures.
|
||||
Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64,
|
||||
and s390x architectures.
|
||||
|
||||
When the system kernel boots, it reserves a small section of memory for
|
||||
the dump-capture kernel. This ensures that ongoing Direct Memory Access
|
||||
|
|
@ -34,11 +34,18 @@ Similarly on PPC64 machines first 32KB of physical memory is needed for
|
|||
booting regardless of where the kernel is loaded and to support 64K page
|
||||
size kexec backs up the first 64KB memory.
|
||||
|
||||
For s390x, when kdump is triggered, the crashkernel region is exchanged
|
||||
with the region [0, crashkernel region size] and then the kdump kernel
|
||||
runs in [0, crashkernel region size]. Therefore no relocatable kernel is
|
||||
needed for s390x.
|
||||
|
||||
All of the necessary information about the system kernel's core image is
|
||||
encoded in the ELF format, and stored in a reserved area of memory
|
||||
before a crash. The physical address of the start of the ELF header is
|
||||
passed to the dump-capture kernel through the elfcorehdr= boot
|
||||
parameter.
|
||||
parameter. Optionally the size of the ELF header can also be passed
|
||||
when using the elfcorehdr=[size[KMG]@]offset[KMG] syntax.
|
||||
|
||||
|
||||
With the dump-capture kernel, you can access the memory image, or "old
|
||||
memory," in two ways:
|
||||
|
|
@ -291,6 +298,10 @@ Boot into System Kernel
|
|||
The region may be automatically placed on ia64, see the
|
||||
dump-capture kernel config option notes above.
|
||||
|
||||
On s390x, typically use "crashkernel=xxM". The value of xx is dependent
|
||||
on the memory consumption of the kdump system. In general this is not
|
||||
dependent on the memory size of the production system.
|
||||
|
||||
Load the Dump-capture Kernel
|
||||
============================
|
||||
|
||||
|
|
@ -308,6 +319,8 @@ For ppc64:
|
|||
- Use vmlinux
|
||||
For ia64:
|
||||
- Use vmlinux or vmlinuz.gz
|
||||
For s390x:
|
||||
- Use image or bzImage
|
||||
|
||||
|
||||
If you are using a uncompressed vmlinux image then use following command
|
||||
|
|
@ -337,6 +350,8 @@ For i386, x86_64 and ia64:
|
|||
For ppc64:
|
||||
"1 maxcpus=1 noirqdistrib reset_devices"
|
||||
|
||||
For s390x:
|
||||
"1 maxcpus=1 cgroup_disable=memory"
|
||||
|
||||
Notes on loading the dump-capture kernel:
|
||||
|
||||
|
|
@ -362,6 +377,20 @@ Notes on loading the dump-capture kernel:
|
|||
dump. Hence generally it is useful either to build a UP dump-capture
|
||||
kernel or specify maxcpus=1 option while loading dump-capture kernel.
|
||||
|
||||
* For s390x there are two kdump modes: If a ELF header is specified with
|
||||
the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
|
||||
is done on all other architectures. If no elfcorehdr= kernel parameter is
|
||||
specified, the s390x kdump kernel dynamically creates the header. The
|
||||
second mode has the advantage that for CPU and memory hotplug, kdump has
|
||||
not to be reloaded with kexec_load().
|
||||
|
||||
* For s390x systems with many attached devices the "cio_ignore" kernel
|
||||
parameter should be used for the kdump kernel in order to prevent allocation
|
||||
of kernel memory for devices that are not relevant for kdump. The same
|
||||
applies to systems that use SCSI/FCP devices. In that case the
|
||||
"allow_lun_scan" zfcp module parameter should be set to zero before
|
||||
setting FCP devices online.
|
||||
|
||||
Kernel Panic
|
||||
============
|
||||
|
||||
|
|
|
|||
|
|
@ -329,6 +329,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
is a lot of faster
|
||||
off - do not initialize any AMD IOMMU found in
|
||||
the system
|
||||
force_isolation - Force device isolation for all
|
||||
devices. The IOMMU driver is not
|
||||
allowed anymore to lift isolation
|
||||
requirements as needed. This option
|
||||
does not override iommu=pt
|
||||
|
||||
amijoy.map= [HW,JOY] Amiga joystick support
|
||||
Map of devices attached to JOY0DAT and JOY1DAT
|
||||
|
|
@ -623,6 +628,25 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
no_debug_objects
|
||||
[KNL] Disable object debugging
|
||||
|
||||
debug_guardpage_minorder=
|
||||
[KNL] When CONFIG_DEBUG_PAGEALLOC is set, this
|
||||
parameter allows control of the order of pages that will
|
||||
be intentionally kept free (and hence protected) by the
|
||||
buddy allocator. Bigger value increase the probability
|
||||
of catching random memory corruption, but reduce the
|
||||
amount of memory for normal system use. The maximum
|
||||
possible value is MAX_ORDER/2. Setting this parameter
|
||||
to 1 or 2 should be enough to identify most random
|
||||
memory corruption problems caused by bugs in kernel or
|
||||
driver code when a CPU writes to (or reads from) a
|
||||
random memory location. Note that there exists a class
|
||||
of memory corruptions problems caused by buggy H/W or
|
||||
F/W or by drivers badly programing DMA (basically when
|
||||
memory is written at bus level and the CPU MMU is
|
||||
bypassed) which are not detectable by
|
||||
CONFIG_DEBUG_PAGEALLOC, hence this option will not help
|
||||
tracking down these problems.
|
||||
|
||||
debugpat [X86] Enable PAT debugging
|
||||
|
||||
decnet.addr= [HW,NET]
|
||||
|
|
@ -1059,7 +1083,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
nomerge
|
||||
forcesac
|
||||
soft
|
||||
pt [x86, IA-64]
|
||||
pt [x86, IA-64]
|
||||
group_mf [x86, IA-64]
|
||||
|
||||
|
||||
io7= [HW] IO7 for Marvel based alpha systems
|
||||
See comment before marvel_specify_io7 in
|
||||
|
|
@ -1178,9 +1204,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
kvm.ignore_msrs=[KVM] Ignore guest accesses to unhandled MSRs.
|
||||
Default is 0 (don't ignore, but inject #GP)
|
||||
|
||||
kvm.oos_shadow= [KVM] Disable out-of-sync shadow paging.
|
||||
Default is 1 (enabled)
|
||||
|
||||
kvm.mmu_audit= [KVM] This is a R/W parameter which allows audit
|
||||
KVM MMU at runtime.
|
||||
Default is 0 (off)
|
||||
|
|
@ -1630,12 +1653,17 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
The default is to return 64-bit inode numbers.
|
||||
|
||||
nfs.nfs4_disable_idmapping=
|
||||
[NFSv4] When set, this option disables the NFSv4
|
||||
idmapper on the client, but only if the mount
|
||||
is using the 'sec=sys' security flavour. This may
|
||||
make migration from legacy NFSv2/v3 systems easier
|
||||
provided that the server has the appropriate support.
|
||||
The default is to always enable NFSv4 idmapping.
|
||||
[NFSv4] When set to the default of '1', this option
|
||||
ensures that both the RPC level authentication
|
||||
scheme and the NFS level operations agree to use
|
||||
numeric uids/gids if the mount is using the
|
||||
'sec=sys' security flavour. In effect it is
|
||||
disabling idmapping, which can make migration from
|
||||
legacy NFSv2/v3 systems to NFSv4 easier.
|
||||
Servers that do not support this mode of operation
|
||||
will be autodetected by the client, and it will fall
|
||||
back to using the idmapper.
|
||||
To turn off this behaviour, set the value to '0'.
|
||||
|
||||
nmi_debug= [KNL,AVR32,SH] Specify one or more actions to take
|
||||
when a NMI is triggered.
|
||||
|
|
@ -1796,6 +1824,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
nomfgpt [X86-32] Disable Multi-Function General Purpose
|
||||
Timer usage (for AMD Geode machines).
|
||||
|
||||
nonmi_ipi [X86] Disable using NMI IPIs during panic/reboot to
|
||||
shutdown the other cpus. Instead use the REBOOT_VECTOR
|
||||
irq.
|
||||
|
||||
nopat [X86] Disable PAT (page attribute table extension of
|
||||
pagetables) support.
|
||||
|
||||
|
|
@ -2367,6 +2399,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
|
||||
slram= [HW,MTD]
|
||||
|
||||
slab_max_order= [MM, SLAB]
|
||||
Determines the maximum allowed order for slabs.
|
||||
A high setting may cause OOMs due to memory
|
||||
fragmentation. Defaults to 1 for systems with
|
||||
more than 32MB of RAM, 0 otherwise.
|
||||
|
||||
slub_debug[=options[,slabs]] [MM, SLUB]
|
||||
Enabling slub_debug allows one to determine the
|
||||
culprit if slab objects become corrupted. Enabling
|
||||
|
|
@ -2637,6 +2675,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
[USB] Start with the old device initialization
|
||||
scheme (default 0 = off).
|
||||
|
||||
usbcore.usbfs_memory_mb=
|
||||
[USB] Memory limit (in MB) for buffers allocated by
|
||||
usbfs (default = 16, 0 = max = 2047).
|
||||
|
||||
usbcore.use_both_schemes=
|
||||
[USB] Try the other device initialization scheme
|
||||
if the first one fails (default 1 = enabled).
|
||||
|
|
|
|||
|
|
@ -357,14 +357,14 @@ Each directory contains:
|
|||
written to, that device.
|
||||
|
||||
state
|
||||
A file recording the current state of the device in the array
|
||||
A file recording the current state of the device in the array
|
||||
which can be a comma separated list of
|
||||
faulty - device has been kicked from active use due to
|
||||
a detected fault or it has unacknowledged bad
|
||||
blocks
|
||||
a detected fault, or it has unacknowledged bad
|
||||
blocks
|
||||
in_sync - device is a fully in-sync member of the array
|
||||
writemostly - device will only be subject to read
|
||||
requests if there are no other options.
|
||||
requests if there are no other options.
|
||||
This applies only to raid1 arrays.
|
||||
blocked - device has failed, and the failure hasn't been
|
||||
acknowledged yet by the metadata handler.
|
||||
|
|
@ -374,6 +374,13 @@ Each directory contains:
|
|||
This includes spares that are in the process
|
||||
of being recovered to
|
||||
write_error - device has ever seen a write error.
|
||||
want_replacement - device is (mostly) working but probably
|
||||
should be replaced, either due to errors or
|
||||
due to user request.
|
||||
replacement - device is a replacement for another active
|
||||
device with same raid_disk.
|
||||
|
||||
|
||||
This list may grow in future.
|
||||
This can be written to.
|
||||
Writing "faulty" simulates a failure on the device.
|
||||
|
|
@ -386,6 +393,13 @@ Each directory contains:
|
|||
Writing "in_sync" sets the in_sync flag.
|
||||
Writing "write_error" sets writeerrorseen flag.
|
||||
Writing "-write_error" clears writeerrorseen flag.
|
||||
Writing "want_replacement" is allowed at any time except to a
|
||||
replacement device or a spare. It sets the flag.
|
||||
Writing "-want_replacement" is allowed at any time. It clears
|
||||
the flag.
|
||||
Writing "replacement" or "-replacement" is only allowed before
|
||||
starting the array. It sets or clears the flag.
|
||||
|
||||
|
||||
This file responds to select/poll. Any change to 'faulty'
|
||||
or 'blocked' causes an event.
|
||||
|
|
|
|||
|
|
@ -7,12 +7,9 @@ This subsystem deals with:
|
|||
|
||||
- Multiplexing of pins, pads, fingers (etc) see below for details
|
||||
|
||||
The intention is to also deal with:
|
||||
|
||||
- Software-controlled biasing and driving mode specific pins, such as
|
||||
pull-up/down, open drain etc, load capacitance configuration when controlled
|
||||
by software, etc.
|
||||
|
||||
- Configuration of pins, pads, fingers (etc), such as software-controlled
|
||||
biasing and driving mode specific pins, such as pull-up/down, open drain,
|
||||
load capacitance etc.
|
||||
|
||||
Top-level interface
|
||||
===================
|
||||
|
|
@ -32,7 +29,7 @@ Definition of PIN:
|
|||
be sparse - i.e. there may be gaps in the space with numbers where no
|
||||
pin exists.
|
||||
|
||||
When a PIN CONTROLLER is instatiated, it will register a descriptor to the
|
||||
When a PIN CONTROLLER is instantiated, it will register a descriptor to the
|
||||
pin control framework, and this descriptor contains an array of pin descriptors
|
||||
describing the pins handled by this specific pin controller.
|
||||
|
||||
|
|
@ -61,14 +58,14 @@ this in our driver:
|
|||
|
||||
#include <linux/pinctrl/pinctrl.h>
|
||||
|
||||
const struct pinctrl_pin_desc __refdata foo_pins[] = {
|
||||
PINCTRL_PIN(0, "A1"),
|
||||
PINCTRL_PIN(1, "A2"),
|
||||
PINCTRL_PIN(2, "A3"),
|
||||
const struct pinctrl_pin_desc foo_pins[] = {
|
||||
PINCTRL_PIN(0, "A8"),
|
||||
PINCTRL_PIN(1, "B8"),
|
||||
PINCTRL_PIN(2, "C8"),
|
||||
...
|
||||
PINCTRL_PIN(61, "H6"),
|
||||
PINCTRL_PIN(62, "H7"),
|
||||
PINCTRL_PIN(63, "H8"),
|
||||
PINCTRL_PIN(61, "F1"),
|
||||
PINCTRL_PIN(62, "G1"),
|
||||
PINCTRL_PIN(63, "H1"),
|
||||
};
|
||||
|
||||
static struct pinctrl_desc foo_desc = {
|
||||
|
|
@ -88,11 +85,16 @@ int __init foo_probe(void)
|
|||
pr_err("could not register foo pin driver\n");
|
||||
}
|
||||
|
||||
To enable the pinctrl subsystem and the subgroups for PINMUX and PINCONF and
|
||||
selected drivers, you need to select them from your machine's Kconfig entry,
|
||||
since these are so tightly integrated with the machines they are used on.
|
||||
See for example arch/arm/mach-u300/Kconfig for an example.
|
||||
|
||||
Pins usually have fancier names than this. You can find these in the dataheet
|
||||
for your chip. Notice that the core pinctrl.h file provides a fancy macro
|
||||
called PINCTRL_PIN() to create the struct entries. As you can see I enumerated
|
||||
the pins from 0 in the upper left corner to 63 in the lower right corner,
|
||||
this enumeration was arbitrarily chosen, in practice you need to think
|
||||
the pins from 0 in the upper left corner to 63 in the lower right corner.
|
||||
This enumeration was arbitrarily chosen, in practice you need to think
|
||||
through your numbering system so that it matches the layout of registers
|
||||
and such things in your driver, or the code may become complicated. You must
|
||||
also consider matching of offsets to the GPIO ranges that may be handled by
|
||||
|
|
@ -133,8 +135,8 @@ struct foo_group {
|
|||
const unsigned num_pins;
|
||||
};
|
||||
|
||||
static unsigned int spi0_pins[] = { 0, 8, 16, 24 };
|
||||
static unsigned int i2c0_pins[] = { 24, 25 };
|
||||
static const unsigned int spi0_pins[] = { 0, 8, 16, 24 };
|
||||
static const unsigned int i2c0_pins[] = { 24, 25 };
|
||||
|
||||
static const struct foo_group foo_groups[] = {
|
||||
{
|
||||
|
|
@ -193,6 +195,88 @@ structure, for example specific register ranges associated with each group
|
|||
and so on.
|
||||
|
||||
|
||||
Pin configuration
|
||||
=================
|
||||
|
||||
Pins can sometimes be software-configured in an various ways, mostly related
|
||||
to their electronic properties when used as inputs or outputs. For example you
|
||||
may be able to make an output pin high impedance, or "tristate" meaning it is
|
||||
effectively disconnected. You may be able to connect an input pin to VDD or GND
|
||||
using a certain resistor value - pull up and pull down - so that the pin has a
|
||||
stable value when nothing is driving the rail it is connected to, or when it's
|
||||
unconnected.
|
||||
|
||||
For example, a platform may do this:
|
||||
|
||||
ret = pin_config_set("foo-dev", "FOO_GPIO_PIN", PLATFORM_X_PULL_UP);
|
||||
|
||||
To pull up a pin to VDD. The pin configuration driver implements callbacks for
|
||||
changing pin configuration in the pin controller ops like this:
|
||||
|
||||
#include <linux/pinctrl/pinctrl.h>
|
||||
#include <linux/pinctrl/pinconf.h>
|
||||
#include "platform_x_pindefs.h"
|
||||
|
||||
static int foo_pin_config_get(struct pinctrl_dev *pctldev,
|
||||
unsigned offset,
|
||||
unsigned long *config)
|
||||
{
|
||||
struct my_conftype conf;
|
||||
|
||||
... Find setting for pin @ offset ...
|
||||
|
||||
*config = (unsigned long) conf;
|
||||
}
|
||||
|
||||
static int foo_pin_config_set(struct pinctrl_dev *pctldev,
|
||||
unsigned offset,
|
||||
unsigned long config)
|
||||
{
|
||||
struct my_conftype *conf = (struct my_conftype *) config;
|
||||
|
||||
switch (conf) {
|
||||
case PLATFORM_X_PULL_UP:
|
||||
...
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
static int foo_pin_config_group_get (struct pinctrl_dev *pctldev,
|
||||
unsigned selector,
|
||||
unsigned long *config)
|
||||
{
|
||||
...
|
||||
}
|
||||
|
||||
static int foo_pin_config_group_set (struct pinctrl_dev *pctldev,
|
||||
unsigned selector,
|
||||
unsigned long config)
|
||||
{
|
||||
...
|
||||
}
|
||||
|
||||
static struct pinconf_ops foo_pconf_ops = {
|
||||
.pin_config_get = foo_pin_config_get,
|
||||
.pin_config_set = foo_pin_config_set,
|
||||
.pin_config_group_get = foo_pin_config_group_get,
|
||||
.pin_config_group_set = foo_pin_config_group_set,
|
||||
};
|
||||
|
||||
/* Pin config operations are handled by some pin controller */
|
||||
static struct pinctrl_desc foo_desc = {
|
||||
...
|
||||
.confops = &foo_pconf_ops,
|
||||
};
|
||||
|
||||
Since some controllers have special logic for handling entire groups of pins
|
||||
they can exploit the special whole-group pin control function. The
|
||||
pin_config_group_set() callback is allowed to return the error code -EAGAIN,
|
||||
for groups it does not want to handle, or if it just wants to do some
|
||||
group-level handling and then fall through to iterate over all pins, in which
|
||||
case each individual pin will be treated by separate pin_config_set() calls as
|
||||
well.
|
||||
|
||||
|
||||
Interaction with the GPIO subsystem
|
||||
===================================
|
||||
|
||||
|
|
@ -214,19 +298,20 @@ static struct pinctrl_gpio_range gpio_range_a = {
|
|||
.name = "chip a",
|
||||
.id = 0,
|
||||
.base = 32,
|
||||
.pin_base = 32,
|
||||
.npins = 16,
|
||||
.gc = &chip_a;
|
||||
};
|
||||
|
||||
static struct pinctrl_gpio_range gpio_range_a = {
|
||||
static struct pinctrl_gpio_range gpio_range_b = {
|
||||
.name = "chip b",
|
||||
.id = 0,
|
||||
.base = 48,
|
||||
.pin_base = 64,
|
||||
.npins = 8,
|
||||
.gc = &chip_b;
|
||||
};
|
||||
|
||||
|
||||
{
|
||||
struct pinctrl_dev *pctl;
|
||||
...
|
||||
|
|
@ -235,42 +320,39 @@ static struct pinctrl_gpio_range gpio_range_a = {
|
|||
}
|
||||
|
||||
So this complex system has one pin controller handling two different
|
||||
GPIO chips. Chip a has 16 pins and chip b has 8 pins. They are mapped in
|
||||
the global GPIO pin space at:
|
||||
GPIO chips. "chip a" has 16 pins and "chip b" has 8 pins. The "chip a" and
|
||||
"chip b" have different .pin_base, which means a start pin number of the
|
||||
GPIO range.
|
||||
|
||||
chip a: [32 .. 47]
|
||||
chip b: [48 .. 55]
|
||||
The GPIO range of "chip a" starts from the GPIO base of 32 and actual
|
||||
pin range also starts from 32. However "chip b" has different starting
|
||||
offset for the GPIO range and pin range. The GPIO range of "chip b" starts
|
||||
from GPIO number 48, while the pin range of "chip b" starts from 64.
|
||||
|
||||
We can convert a gpio number to actual pin number using this "pin_base".
|
||||
They are mapped in the global GPIO pin space at:
|
||||
|
||||
chip a:
|
||||
- GPIO range : [32 .. 47]
|
||||
- pin range : [32 .. 47]
|
||||
chip b:
|
||||
- GPIO range : [48 .. 55]
|
||||
- pin range : [64 .. 71]
|
||||
|
||||
When GPIO-specific functions in the pin control subsystem are called, these
|
||||
ranges will be used to look up the apropriate pin controller by inspecting
|
||||
ranges will be used to look up the appropriate pin controller by inspecting
|
||||
and matching the pin to the pin ranges across all controllers. When a
|
||||
pin controller handling the matching range is found, GPIO-specific functions
|
||||
will be called on that specific pin controller.
|
||||
|
||||
For all functionalities dealing with pin biasing, pin muxing etc, the pin
|
||||
controller subsystem will subtract the range's .base offset from the passed
|
||||
in gpio pin number, and pass that on to the pin control driver, so the driver
|
||||
will get an offset into its handled number range. Further it is also passed
|
||||
in gpio number, and add the ranges's .pin_base offset to retrive a pin number.
|
||||
After that, the subsystem passes it on to the pin control driver, so the driver
|
||||
will get an pin number into its handled number range. Further it is also passed
|
||||
the range ID value, so that the pin controller knows which range it should
|
||||
deal with.
|
||||
|
||||
For example: if a user issues pinctrl_gpio_set_foo(50), the pin control
|
||||
subsystem will find that the second range on this pin controller matches,
|
||||
subtract the base 48 and call the
|
||||
pinctrl_driver_gpio_set_foo(pinctrl, range, 2) where the latter function has
|
||||
this signature:
|
||||
|
||||
int pinctrl_driver_gpio_set_foo(struct pinctrl_dev *pctldev,
|
||||
struct pinctrl_gpio_range *rangeid,
|
||||
unsigned offset);
|
||||
|
||||
Now the driver knows that we want to do some GPIO-specific operation on the
|
||||
second GPIO range handled by "chip b", at offset 2 in that specific range.
|
||||
|
||||
(If the GPIO subsystem is ever refactored to use a local per-GPIO controller
|
||||
pin space, this mapping will need to be augmented accordingly.)
|
||||
|
||||
|
||||
PINMUX interfaces
|
||||
=================
|
||||
|
||||
|
|
@ -438,7 +520,7 @@ you. Define enumerators only for the pins you can control if that makes sense.
|
|||
|
||||
Assumptions:
|
||||
|
||||
We assume that the number possible function maps to pin groups is limited by
|
||||
We assume that the number of possible function maps to pin groups is limited by
|
||||
the hardware. I.e. we assume that there is no system where any function can be
|
||||
mapped to any pin, like in a phone exchange. So the available pins groups for
|
||||
a certain function will be limited to a few choices (say up to eight or so),
|
||||
|
|
@ -585,7 +667,7 @@ int foo_list_funcs(struct pinctrl_dev *pctldev, unsigned selector)
|
|||
|
||||
const char *foo_get_fname(struct pinctrl_dev *pctldev, unsigned selector)
|
||||
{
|
||||
return myfuncs[selector].name;
|
||||
return foo_functions[selector].name;
|
||||
}
|
||||
|
||||
static int foo_get_groups(struct pinctrl_dev *pctldev, unsigned selector,
|
||||
|
|
@ -600,16 +682,16 @@ static int foo_get_groups(struct pinctrl_dev *pctldev, unsigned selector,
|
|||
int foo_enable(struct pinctrl_dev *pctldev, unsigned selector,
|
||||
unsigned group)
|
||||
{
|
||||
u8 regbit = (1 << group);
|
||||
u8 regbit = (1 << selector + group);
|
||||
|
||||
writeb((readb(MUX)|regbit), MUX)
|
||||
return 0;
|
||||
}
|
||||
|
||||
int foo_disable(struct pinctrl_dev *pctldev, unsigned selector,
|
||||
void foo_disable(struct pinctrl_dev *pctldev, unsigned selector,
|
||||
unsigned group)
|
||||
{
|
||||
u8 regbit = (1 << group);
|
||||
u8 regbit = (1 << selector + group);
|
||||
|
||||
writeb((readb(MUX) & ~(regbit)), MUX)
|
||||
return 0;
|
||||
|
|
@ -647,6 +729,17 @@ All the above functions are mandatory to implement for a pinmux driver.
|
|||
Pinmux interaction with the GPIO subsystem
|
||||
==========================================
|
||||
|
||||
The public pinmux API contains two functions named pinmux_request_gpio()
|
||||
and pinmux_free_gpio(). These two functions shall *ONLY* be called from
|
||||
gpiolib-based drivers as part of their gpio_request() and
|
||||
gpio_free() semantics. Likewise the pinmux_gpio_direction_[input|output]
|
||||
shall only be called from within respective gpio_direction_[input|output]
|
||||
gpiolib implementation.
|
||||
|
||||
NOTE that platforms and individual drivers shall *NOT* request GPIO pins to be
|
||||
muxed in. Instead, implement a proper gpiolib driver and have that driver
|
||||
request proper muxing for its pins.
|
||||
|
||||
The function list could become long, especially if you can convert every
|
||||
individual pin into a GPIO pin independent of any other pins, and then try
|
||||
the approach to define every pin as a function.
|
||||
|
|
@ -654,19 +747,24 @@ the approach to define every pin as a function.
|
|||
In this case, the function array would become 64 entries for each GPIO
|
||||
setting and then the device functions.
|
||||
|
||||
For this reason there is an additional function a pinmux driver can implement
|
||||
to enable only GPIO on an individual pin: .gpio_request_enable(). The same
|
||||
.free() function as for other functions is assumed to be usable also for
|
||||
GPIO pins.
|
||||
For this reason there are two functions a pinmux driver can implement
|
||||
to enable only GPIO on an individual pin: .gpio_request_enable() and
|
||||
.gpio_disable_free().
|
||||
|
||||
This function will pass in the affected GPIO range identified by the pin
|
||||
controller core, so you know which GPIO pins are being affected by the request
|
||||
operation.
|
||||
|
||||
Alternatively it is fully allowed to use named functions for each GPIO
|
||||
pin, the pinmux_request_gpio() will attempt to obtain the function "gpioN"
|
||||
where "N" is the global GPIO pin number if no special GPIO-handler is
|
||||
registered.
|
||||
If your driver needs to have an indication from the framework of whether the
|
||||
GPIO pin shall be used for input or output you can implement the
|
||||
.gpio_set_direction() function. As described this shall be called from the
|
||||
gpiolib driver and the affected GPIO range, pin offset and desired direction
|
||||
will be passed along to this function.
|
||||
|
||||
Alternatively to using these special functions, it is fully allowed to use
|
||||
named functions for each GPIO pin, the pinmux_request_gpio() will attempt to
|
||||
obtain the function "gpioN" where "N" is the global GPIO pin number if no
|
||||
special GPIO-handler is registered.
|
||||
|
||||
|
||||
Pinmux board/machine configuration
|
||||
|
|
@ -683,19 +781,19 @@ spi on the second function mapping:
|
|||
|
||||
#include <linux/pinctrl/machine.h>
|
||||
|
||||
static struct pinmux_map pmx_mapping[] = {
|
||||
static const struct pinmux_map __initdata pmx_mapping[] = {
|
||||
{
|
||||
.ctrl_dev_name = "pinctrl.0",
|
||||
.ctrl_dev_name = "pinctrl-foo",
|
||||
.function = "spi0",
|
||||
.dev_name = "foo-spi.0",
|
||||
},
|
||||
{
|
||||
.ctrl_dev_name = "pinctrl.0",
|
||||
.ctrl_dev_name = "pinctrl-foo",
|
||||
.function = "i2c0",
|
||||
.dev_name = "foo-i2c.0",
|
||||
},
|
||||
{
|
||||
.ctrl_dev_name = "pinctrl.0",
|
||||
.ctrl_dev_name = "pinctrl-foo",
|
||||
.function = "mmc0",
|
||||
.dev_name = "foo-mmc.0",
|
||||
},
|
||||
|
|
@ -714,14 +812,14 @@ for example if they are not yet instantiated or cumbersome to obtain.
|
|||
|
||||
You register this pinmux mapping to the pinmux subsystem by simply:
|
||||
|
||||
ret = pinmux_register_mappings(&pmx_mapping, ARRAY_SIZE(pmx_mapping));
|
||||
ret = pinmux_register_mappings(pmx_mapping, ARRAY_SIZE(pmx_mapping));
|
||||
|
||||
Since the above construct is pretty common there is a helper macro to make
|
||||
it even more compact which assumes you want to use pinctrl.0 and position
|
||||
it even more compact which assumes you want to use pinctrl-foo and position
|
||||
0 for mapping, for example:
|
||||
|
||||
static struct pinmux_map pmx_mapping[] = {
|
||||
PINMUX_MAP_PRIMARY("I2CMAP", "i2c0", "foo-i2c.0"),
|
||||
static struct pinmux_map __initdata pmx_mapping[] = {
|
||||
PINMUX_MAP("I2CMAP", "pinctrl-foo", "i2c0", "foo-i2c.0"),
|
||||
};
|
||||
|
||||
|
||||
|
|
@ -734,14 +832,14 @@ As it is possible to map a function to different groups of pins an optional
|
|||
...
|
||||
{
|
||||
.name = "spi0-pos-A",
|
||||
.ctrl_dev_name = "pinctrl.0",
|
||||
.ctrl_dev_name = "pinctrl-foo",
|
||||
.function = "spi0",
|
||||
.group = "spi0_0_grp",
|
||||
.dev_name = "foo-spi.0",
|
||||
},
|
||||
{
|
||||
.name = "spi0-pos-B",
|
||||
.ctrl_dev_name = "pinctrl.0",
|
||||
.ctrl_dev_name = "pinctrl-foo",
|
||||
.function = "spi0",
|
||||
.group = "spi0_1_grp",
|
||||
.dev_name = "foo-spi.0",
|
||||
|
|
@ -760,46 +858,46 @@ case), we define a mapping like this:
|
|||
...
|
||||
{
|
||||
.name "2bit"
|
||||
.ctrl_dev_name = "pinctrl.0",
|
||||
.function = "mmc0",
|
||||
.group = "mmc0_0_grp",
|
||||
.dev_name = "foo-mmc.0",
|
||||
},
|
||||
{
|
||||
.name "4bit"
|
||||
.ctrl_dev_name = "pinctrl.0",
|
||||
.function = "mmc0",
|
||||
.group = "mmc0_0_grp",
|
||||
.dev_name = "foo-mmc.0",
|
||||
},
|
||||
{
|
||||
.name "4bit"
|
||||
.ctrl_dev_name = "pinctrl.0",
|
||||
.ctrl_dev_name = "pinctrl-foo",
|
||||
.function = "mmc0",
|
||||
.group = "mmc0_1_grp",
|
||||
.dev_name = "foo-mmc.0",
|
||||
},
|
||||
{
|
||||
.name "8bit"
|
||||
.ctrl_dev_name = "pinctrl.0",
|
||||
.function = "mmc0",
|
||||
.group = "mmc0_0_grp",
|
||||
.dev_name = "foo-mmc.0",
|
||||
},
|
||||
{
|
||||
.name "8bit"
|
||||
.ctrl_dev_name = "pinctrl.0",
|
||||
.name "4bit"
|
||||
.ctrl_dev_name = "pinctrl-foo",
|
||||
.function = "mmc0",
|
||||
.group = "mmc0_1_grp",
|
||||
.dev_name = "foo-mmc.0",
|
||||
},
|
||||
{
|
||||
.name "8bit"
|
||||
.ctrl_dev_name = "pinctrl.0",
|
||||
.name "4bit"
|
||||
.ctrl_dev_name = "pinctrl-foo",
|
||||
.function = "mmc0",
|
||||
.group = "mmc0_2_grp",
|
||||
.dev_name = "foo-mmc.0",
|
||||
},
|
||||
{
|
||||
.name "8bit"
|
||||
.ctrl_dev_name = "pinctrl-foo",
|
||||
.function = "mmc0",
|
||||
.group = "mmc0_1_grp",
|
||||
.dev_name = "foo-mmc.0",
|
||||
},
|
||||
{
|
||||
.name "8bit"
|
||||
.ctrl_dev_name = "pinctrl-foo",
|
||||
.function = "mmc0",
|
||||
.group = "mmc0_2_grp",
|
||||
.dev_name = "foo-mmc.0",
|
||||
},
|
||||
{
|
||||
.name "8bit"
|
||||
.ctrl_dev_name = "pinctrl-foo",
|
||||
.function = "mmc0",
|
||||
.group = "mmc0_3_grp",
|
||||
.dev_name = "foo-mmc.0",
|
||||
},
|
||||
...
|
||||
|
||||
The result of grabbing this mapping from the device with something like
|
||||
|
|
@ -898,7 +996,7 @@ like this:
|
|||
|
||||
{
|
||||
.name "POWERMAP"
|
||||
.ctrl_dev_name = "pinctrl.0",
|
||||
.ctrl_dev_name = "pinctrl-foo",
|
||||
.function = "power_func",
|
||||
.hog_on_boot = true,
|
||||
},
|
||||
|
|
|
|||
|
|
@ -0,0 +1,163 @@
|
|||
Charger Manager
|
||||
(C) 2011 MyungJoo Ham <myungjoo.ham@samsung.com>, GPL
|
||||
|
||||
Charger Manager provides in-kernel battery charger management that
|
||||
requires temperature monitoring during suspend-to-RAM state
|
||||
and where each battery may have multiple chargers attached and the userland
|
||||
wants to look at the aggregated information of the multiple chargers.
|
||||
|
||||
Charger Manager is a platform_driver with power-supply-class entries.
|
||||
An instance of Charger Manager (a platform-device created with Charger-Manager)
|
||||
represents an independent battery with chargers. If there are multiple
|
||||
batteries with their own chargers acting independently in a system,
|
||||
the system may need multiple instances of Charger Manager.
|
||||
|
||||
1. Introduction
|
||||
===============
|
||||
|
||||
Charger Manager supports the following:
|
||||
|
||||
* Support for multiple chargers (e.g., a device with USB, AC, and solar panels)
|
||||
A system may have multiple chargers (or power sources) and some of
|
||||
they may be activated at the same time. Each charger may have its
|
||||
own power-supply-class and each power-supply-class can provide
|
||||
different information about the battery status. This framework
|
||||
aggregates charger-related information from multiple sources and
|
||||
shows combined information as a single power-supply-class.
|
||||
|
||||
* Support for in suspend-to-RAM polling (with suspend_again callback)
|
||||
While the battery is being charged and the system is in suspend-to-RAM,
|
||||
we may need to monitor the battery health by looking at the ambient or
|
||||
battery temperature. We can accomplish this by waking up the system
|
||||
periodically. However, such a method wakes up devices unncessary for
|
||||
monitoring the battery health and tasks, and user processes that are
|
||||
supposed to be kept suspended. That, in turn, incurs unnecessary power
|
||||
consumption and slow down charging process. Or even, such peak power
|
||||
consumption can stop chargers in the middle of charging
|
||||
(external power input < device power consumption), which not
|
||||
only affects the charging time, but the lifespan of the battery.
|
||||
|
||||
Charger Manager provides a function "cm_suspend_again" that can be
|
||||
used as suspend_again callback of platform_suspend_ops. If the platform
|
||||
requires tasks other than cm_suspend_again, it may implement its own
|
||||
suspend_again callback that calls cm_suspend_again in the middle.
|
||||
Normally, the platform will need to resume and suspend some devices
|
||||
that are used by Charger Manager.
|
||||
|
||||
2. Global Charger-Manager Data related with suspend_again
|
||||
========================================================
|
||||
In order to setup Charger Manager with suspend-again feature
|
||||
(in-suspend monitoring), the user should provide charger_global_desc
|
||||
with setup_charger_manager(struct charger_global_desc *).
|
||||
This charger_global_desc data for in-suspend monitoring is global
|
||||
as the name suggests. Thus, the user needs to provide only once even
|
||||
if there are multiple batteries. If there are multiple batteries, the
|
||||
multiple instances of Charger Manager share the same charger_global_desc
|
||||
and it will manage in-suspend monitoring for all instances of Charger Manager.
|
||||
|
||||
The user needs to provide all the two entries properly in order to activate
|
||||
in-suspend monitoring:
|
||||
|
||||
struct charger_global_desc {
|
||||
|
||||
char *rtc_name;
|
||||
: The name of rtc (e.g., "rtc0") used to wakeup the system from
|
||||
suspend for Charger Manager. The alarm interrupt (AIE) of the rtc
|
||||
should be able to wake up the system from suspend. Charger Manager
|
||||
saves and restores the alarm value and use the previously-defined
|
||||
alarm if it is going to go off earlier than Charger Manager so that
|
||||
Charger Manager does not interfere with previously-defined alarms.
|
||||
|
||||
bool (*rtc_only_wakeup)(void);
|
||||
: This callback should let CM know whether
|
||||
the wakeup-from-suspend is caused only by the alarm of "rtc" in the
|
||||
same struct. If there is any other wakeup source triggered the
|
||||
wakeup, it should return false. If the "rtc" is the only wakeup
|
||||
reason, it should return true.
|
||||
};
|
||||
|
||||
3. How to setup suspend_again
|
||||
=============================
|
||||
Charger Manager provides a function "extern bool cm_suspend_again(void)".
|
||||
When cm_suspend_again is called, it monitors every battery. The suspend_ops
|
||||
callback of the system's platform_suspend_ops can call cm_suspend_again
|
||||
function to know whether Charger Manager wants to suspend again or not.
|
||||
If there are no other devices or tasks that want to use suspend_again
|
||||
feature, the platform_suspend_ops may directly refer to cm_suspend_again
|
||||
for its suspend_again callback.
|
||||
|
||||
The cm_suspend_again() returns true (meaning "I want to suspend again")
|
||||
if the system was woken up by Charger Manager and the polling
|
||||
(in-suspend monitoring) results in "normal".
|
||||
|
||||
4. Charger-Manager Data (struct charger_desc)
|
||||
=============================================
|
||||
For each battery charged independently from other batteries (if a series of
|
||||
batteries are charged by a single charger, they are counted as one independent
|
||||
battery), an instance of Charger Manager is attached to it.
|
||||
|
||||
struct charger_desc {
|
||||
|
||||
char *psy_name;
|
||||
: The power-supply-class name of the battery. Default is
|
||||
"battery" if psy_name is NULL. Users can access the psy entries
|
||||
at "/sys/class/power_supply/[psy_name]/".
|
||||
|
||||
enum polling_modes polling_mode;
|
||||
: CM_POLL_DISABLE: do not poll this battery.
|
||||
CM_POLL_ALWAYS: always poll this battery.
|
||||
CM_POLL_EXTERNAL_POWER_ONLY: poll this battery if and only if
|
||||
an external power source is attached.
|
||||
CM_POLL_CHARGING_ONLY: poll this battery if and only if the
|
||||
battery is being charged.
|
||||
|
||||
unsigned int fullbatt_uV;
|
||||
: If specified with a non-zero value, Charger Manager assumes
|
||||
that the battery is full (capacity = 100) if the battery is not being
|
||||
charged and the battery voltage is equal to or greater than
|
||||
fullbatt_uV.
|
||||
|
||||
unsigned int polling_interval_ms;
|
||||
: Required polling interval in ms. Charger Manager will poll
|
||||
this battery every polling_interval_ms or more frequently.
|
||||
|
||||
enum data_source battery_present;
|
||||
CM_FUEL_GAUGE: get battery presence information from fuel gauge.
|
||||
CM_CHARGER_STAT: get battery presence from chargers.
|
||||
|
||||
char **psy_charger_stat;
|
||||
: An array ending with NULL that has power-supply-class names of
|
||||
chargers. Each power-supply-class should provide "PRESENT" (if
|
||||
battery_present is "CM_CHARGER_STAT"), "ONLINE" (shows whether an
|
||||
external power source is attached or not), and "STATUS" (shows whether
|
||||
the battery is {"FULL" or not FULL} or {"FULL", "Charging",
|
||||
"Discharging", "NotCharging"}).
|
||||
|
||||
int num_charger_regulators;
|
||||
struct regulator_bulk_data *charger_regulators;
|
||||
: Regulators representing the chargers in the form for
|
||||
regulator framework's bulk functions.
|
||||
|
||||
char *psy_fuel_gauge;
|
||||
: Power-supply-class name of the fuel gauge.
|
||||
|
||||
int (*temperature_out_of_range)(int *mC);
|
||||
bool measure_battery_temp;
|
||||
: This callback returns 0 if the temperature is safe for charging,
|
||||
a positive number if it is too hot to charge, and a negative number
|
||||
if it is too cold to charge. With the variable mC, the callback returns
|
||||
the temperature in 1/1000 of centigrade.
|
||||
The source of temperature can be battery or ambient one according to
|
||||
the value of measure_battery_temp.
|
||||
};
|
||||
|
||||
5. Other Considerations
|
||||
=======================
|
||||
|
||||
At the charger/battery-related events such as battery-pulled-out,
|
||||
charger-pulled-out, charger-inserted, DCIN-over/under-voltage, charger-stopped,
|
||||
and others critical to chargers, the system should be configured to wake up.
|
||||
At least the following should wake up the system from a suspend:
|
||||
a) charger-on/off b) external-power-in/out c) battery-in/out (while charging)
|
||||
|
||||
It is usually accomplished by configuring the PMIC as a wakeup source.
|
||||
|
|
@ -126,7 +126,9 @@ The core methods to suspend and resume devices reside in struct dev_pm_ops
|
|||
pointed to by the ops member of struct dev_pm_domain, or by the pm member of
|
||||
struct bus_type, struct device_type and struct class. They are mostly of
|
||||
interest to the people writing infrastructure for platforms and buses, like PCI
|
||||
or USB, or device type and device class drivers.
|
||||
or USB, or device type and device class drivers. They also are relevant to the
|
||||
writers of device drivers whose subsystems (PM domains, device types, device
|
||||
classes and bus types) don't provide all power management methods.
|
||||
|
||||
Bus drivers implement these methods as appropriate for the hardware and the
|
||||
drivers using it; PCI works differently from USB, and so on. Not many people
|
||||
|
|
@ -268,32 +270,35 @@ various phases always run after tasks have been frozen and before they are
|
|||
unfrozen. Furthermore, the *_noirq phases run at a time when IRQ handlers have
|
||||
been disabled (except for those marked with the IRQF_NO_SUSPEND flag).
|
||||
|
||||
All phases use PM domain, bus, type, or class callbacks (that is, methods
|
||||
defined in dev->pm_domain->ops, dev->bus->pm, dev->type->pm, or dev->class->pm).
|
||||
These callbacks are regarded by the PM core as mutually exclusive. Moreover,
|
||||
PM domain callbacks always take precedence over bus, type and class callbacks,
|
||||
while type callbacks take precedence over bus and class callbacks, and class
|
||||
callbacks take precedence over bus callbacks. To be precise, the following
|
||||
rules are used to determine which callback to execute in the given phase:
|
||||
All phases use PM domain, bus, type, class or driver callbacks (that is, methods
|
||||
defined in dev->pm_domain->ops, dev->bus->pm, dev->type->pm, dev->class->pm or
|
||||
dev->driver->pm). These callbacks are regarded by the PM core as mutually
|
||||
exclusive. Moreover, PM domain callbacks always take precedence over all of the
|
||||
other callbacks and, for example, type callbacks take precedence over bus, class
|
||||
and driver callbacks. To be precise, the following rules are used to determine
|
||||
which callback to execute in the given phase:
|
||||
|
||||
1. If dev->pm_domain is present, the PM core will attempt to execute the
|
||||
callback included in dev->pm_domain->ops. If that callback is not
|
||||
present, no action will be carried out for the given device.
|
||||
1. If dev->pm_domain is present, the PM core will choose the callback
|
||||
included in dev->pm_domain->ops for execution
|
||||
|
||||
2. Otherwise, if both dev->type and dev->type->pm are present, the callback
|
||||
included in dev->type->pm will be executed.
|
||||
included in dev->type->pm will be chosen for execution.
|
||||
|
||||
3. Otherwise, if both dev->class and dev->class->pm are present, the
|
||||
callback included in dev->class->pm will be executed.
|
||||
callback included in dev->class->pm will be chosen for execution.
|
||||
|
||||
4. Otherwise, if both dev->bus and dev->bus->pm are present, the callback
|
||||
included in dev->bus->pm will be executed.
|
||||
included in dev->bus->pm will be chosen for execution.
|
||||
|
||||
This allows PM domains and device types to override callbacks provided by bus
|
||||
types or device classes if necessary.
|
||||
|
||||
These callbacks may in turn invoke device- or driver-specific methods stored in
|
||||
dev->driver->pm, but they don't have to.
|
||||
The PM domain, type, class and bus callbacks may in turn invoke device- or
|
||||
driver-specific methods stored in dev->driver->pm, but they don't have to do
|
||||
that.
|
||||
|
||||
If the subsystem callback chosen for execution is not present, the PM core will
|
||||
execute the corresponding method from dev->driver->pm instead if there is one.
|
||||
|
||||
|
||||
Entering System Suspend
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ freeze_processes() (defined in kernel/power/process.c) is called. It executes
|
|||
try_to_freeze_tasks() that sets TIF_FREEZE for all of the freezable tasks and
|
||||
either wakes them up, if they are kernel threads, or sends fake signals to them,
|
||||
if they are user space processes. A task that has TIF_FREEZE set, should react
|
||||
to it by calling the function called refrigerator() (defined in
|
||||
to it by calling the function called __refrigerator() (defined in
|
||||
kernel/freezer.c), which sets the task's PF_FROZEN flag, changes its state
|
||||
to TASK_UNINTERRUPTIBLE and makes it loop until PF_FROZEN is cleared for it.
|
||||
Then, we say that the task is 'frozen' and therefore the set of functions
|
||||
|
|
@ -29,10 +29,10 @@ handling this mechanism is referred to as 'the freezer' (these functions are
|
|||
defined in kernel/power/process.c, kernel/freezer.c & include/linux/freezer.h).
|
||||
User space processes are generally frozen before kernel threads.
|
||||
|
||||
It is not recommended to call refrigerator() directly. Instead, it is
|
||||
recommended to use the try_to_freeze() function (defined in
|
||||
include/linux/freezer.h), that checks the task's TIF_FREEZE flag and makes the
|
||||
task enter refrigerator() if the flag is set.
|
||||
__refrigerator() must not be called directly. Instead, use the
|
||||
try_to_freeze() function (defined in include/linux/freezer.h), that checks
|
||||
the task's TIF_FREEZE flag and makes the task enter __refrigerator() if the
|
||||
flag is set.
|
||||
|
||||
For user space processes try_to_freeze() is called automatically from the
|
||||
signal-handling code, but the freezable kernel threads need to call it
|
||||
|
|
@ -61,13 +61,13 @@ wait_event_freezable() and wait_event_freezable_timeout() macros.
|
|||
After the system memory state has been restored from a hibernation image and
|
||||
devices have been reinitialized, the function thaw_processes() is called in
|
||||
order to clear the PF_FROZEN flag for each frozen task. Then, the tasks that
|
||||
have been frozen leave refrigerator() and continue running.
|
||||
have been frozen leave __refrigerator() and continue running.
|
||||
|
||||
III. Which kernel threads are freezable?
|
||||
|
||||
Kernel threads are not freezable by default. However, a kernel thread may clear
|
||||
PF_NOFREEZE for itself by calling set_freezable() (the resetting of PF_NOFREEZE
|
||||
directly is strongly discouraged). From this point it is regarded as freezable
|
||||
directly is not allowed). From this point it is regarded as freezable
|
||||
and must call try_to_freeze() in a suitable place.
|
||||
|
||||
IV. Why do we do that?
|
||||
|
|
@ -176,3 +176,28 @@ tasks, since it generally exists anyway.
|
|||
A driver must have all firmwares it may need in RAM before suspend() is called.
|
||||
If keeping them is not practical, for example due to their size, they must be
|
||||
requested early enough using the suspend notifier API described in notifiers.txt.
|
||||
|
||||
VI. Are there any precautions to be taken to prevent freezing failures?
|
||||
|
||||
Yes, there are.
|
||||
|
||||
First of all, grabbing the 'pm_mutex' lock to mutually exclude a piece of code
|
||||
from system-wide sleep such as suspend/hibernation is not encouraged.
|
||||
If possible, that piece of code must instead hook onto the suspend/hibernation
|
||||
notifiers to achieve mutual exclusion. Look at the CPU-Hotplug code
|
||||
(kernel/cpu.c) for an example.
|
||||
|
||||
However, if that is not feasible, and grabbing 'pm_mutex' is deemed necessary,
|
||||
it is strongly discouraged to directly call mutex_[un]lock(&pm_mutex) since
|
||||
that could lead to freezing failures, because if the suspend/hibernate code
|
||||
successfully acquired the 'pm_mutex' lock, and hence that other entity failed
|
||||
to acquire the lock, then that task would get blocked in TASK_UNINTERRUPTIBLE
|
||||
state. As a consequence, the freezer would not be able to freeze that task,
|
||||
leading to freezing failure.
|
||||
|
||||
However, the [un]lock_system_sleep() APIs are safe to use in this scenario,
|
||||
since they ask the freezer to skip freezing this task, since it is anyway
|
||||
"frozen enough" as it is blocked on 'pm_mutex', which will be released
|
||||
only after the entire suspend/hibernation sequence is complete.
|
||||
So, to summarize, use [un]lock_system_sleep() instead of directly using
|
||||
mutex_[un]lock(&pm_mutex). That would prevent freezing failures.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Drivers can register a regulator by calling :-
|
|||
|
||||
struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
|
||||
struct device *dev, struct regulator_init_data *init_data,
|
||||
void *driver_data);
|
||||
void *driver_data, struct device_node *of_node);
|
||||
|
||||
This will register the regulators capabilities and operations to the regulator
|
||||
core.
|
||||
|
|
|
|||
|
|
@ -57,6 +57,10 @@ the following:
|
|||
|
||||
4. Bus type of the device, if both dev->bus and dev->bus->pm are present.
|
||||
|
||||
If the subsystem chosen by applying the above rules doesn't provide the relevant
|
||||
callback, the PM core will invoke the corresponding driver callback stored in
|
||||
dev->driver->pm directly (if present).
|
||||
|
||||
The PM core always checks which callback to use in the order given above, so the
|
||||
priority order of callbacks from high to low is: PM domain, device type, class
|
||||
and bus type. Moreover, the high-priority one will always take precedence over
|
||||
|
|
@ -64,86 +68,88 @@ a low-priority one. The PM domain, bus type, device type and class callbacks
|
|||
are referred to as subsystem-level callbacks in what follows.
|
||||
|
||||
By default, the callbacks are always invoked in process context with interrupts
|
||||
enabled. However, subsystems can use the pm_runtime_irq_safe() helper function
|
||||
to tell the PM core that their ->runtime_suspend(), ->runtime_resume() and
|
||||
->runtime_idle() callbacks may be invoked in atomic context with interrupts
|
||||
disabled for a given device. This implies that the callback routines in
|
||||
question must not block or sleep, but it also means that the synchronous helper
|
||||
functions listed at the end of Section 4 may be used for that device within an
|
||||
interrupt handler or generally in an atomic context.
|
||||
enabled. However, the pm_runtime_irq_safe() helper function can be used to tell
|
||||
the PM core that it is safe to run the ->runtime_suspend(), ->runtime_resume()
|
||||
and ->runtime_idle() callbacks for the given device in atomic context with
|
||||
interrupts disabled. This implies that the callback routines in question must
|
||||
not block or sleep, but it also means that the synchronous helper functions
|
||||
listed at the end of Section 4 may be used for that device within an interrupt
|
||||
handler or generally in an atomic context.
|
||||
|
||||
The subsystem-level suspend callback is _entirely_ _responsible_ for handling
|
||||
the suspend of the device as appropriate, which may, but need not include
|
||||
executing the device driver's own ->runtime_suspend() callback (from the
|
||||
The subsystem-level suspend callback, if present, is _entirely_ _responsible_
|
||||
for handling the suspend of the device as appropriate, which may, but need not
|
||||
include executing the device driver's own ->runtime_suspend() callback (from the
|
||||
PM core's point of view it is not necessary to implement a ->runtime_suspend()
|
||||
callback in a device driver as long as the subsystem-level suspend callback
|
||||
knows what to do to handle the device).
|
||||
|
||||
* Once the subsystem-level suspend callback has completed successfully
|
||||
for given device, the PM core regards the device as suspended, which need
|
||||
not mean that the device has been put into a low power state. It is
|
||||
supposed to mean, however, that the device will not process data and will
|
||||
not communicate with the CPU(s) and RAM until the subsystem-level resume
|
||||
callback is executed for it. The runtime PM status of a device after
|
||||
successful execution of the subsystem-level suspend callback is 'suspended'.
|
||||
* Once the subsystem-level suspend callback (or the driver suspend callback,
|
||||
if invoked directly) has completed successfully for the given device, the PM
|
||||
core regards the device as suspended, which need not mean that it has been
|
||||
put into a low power state. It is supposed to mean, however, that the
|
||||
device will not process data and will not communicate with the CPU(s) and
|
||||
RAM until the appropriate resume callback is executed for it. The runtime
|
||||
PM status of a device after successful execution of the suspend callback is
|
||||
'suspended'.
|
||||
|
||||
* If the subsystem-level suspend callback returns -EBUSY or -EAGAIN,
|
||||
the device's runtime PM status is 'active', which means that the device
|
||||
_must_ be fully operational afterwards.
|
||||
* If the suspend callback returns -EBUSY or -EAGAIN, the device's runtime PM
|
||||
status remains 'active', which means that the device _must_ be fully
|
||||
operational afterwards.
|
||||
|
||||
* If the subsystem-level suspend callback returns an error code different
|
||||
from -EBUSY or -EAGAIN, the PM core regards this as a fatal error and will
|
||||
refuse to run the helper functions described in Section 4 for the device,
|
||||
until the status of it is directly set either to 'active', or to 'suspended'
|
||||
(the PM core provides special helper functions for this purpose).
|
||||
* If the suspend callback returns an error code different from -EBUSY and
|
||||
-EAGAIN, the PM core regards this as a fatal error and will refuse to run
|
||||
the helper functions described in Section 4 for the device until its status
|
||||
is directly set to either'active', or 'suspended' (the PM core provides
|
||||
special helper functions for this purpose).
|
||||
|
||||
In particular, if the driver requires remote wake-up capability (i.e. hardware
|
||||
In particular, if the driver requires remote wakeup capability (i.e. hardware
|
||||
mechanism allowing the device to request a change of its power state, such as
|
||||
PCI PME) for proper functioning and device_run_wake() returns 'false' for the
|
||||
device, then ->runtime_suspend() should return -EBUSY. On the other hand, if
|
||||
device_run_wake() returns 'true' for the device and the device is put into a low
|
||||
power state during the execution of the subsystem-level suspend callback, it is
|
||||
expected that remote wake-up will be enabled for the device. Generally, remote
|
||||
wake-up should be enabled for all input devices put into a low power state at
|
||||
run time.
|
||||
device_run_wake() returns 'true' for the device and the device is put into a
|
||||
low-power state during the execution of the suspend callback, it is expected
|
||||
that remote wakeup will be enabled for the device. Generally, remote wakeup
|
||||
should be enabled for all input devices put into low-power states at run time.
|
||||
|
||||
The subsystem-level resume callback is _entirely_ _responsible_ for handling the
|
||||
resume of the device as appropriate, which may, but need not include executing
|
||||
the device driver's own ->runtime_resume() callback (from the PM core's point of
|
||||
view it is not necessary to implement a ->runtime_resume() callback in a device
|
||||
driver as long as the subsystem-level resume callback knows what to do to handle
|
||||
the device).
|
||||
The subsystem-level resume callback, if present, is _entirely_ _responsible_ for
|
||||
handling the resume of the device as appropriate, which may, but need not
|
||||
include executing the device driver's own ->runtime_resume() callback (from the
|
||||
PM core's point of view it is not necessary to implement a ->runtime_resume()
|
||||
callback in a device driver as long as the subsystem-level resume callback knows
|
||||
what to do to handle the device).
|
||||
|
||||
* Once the subsystem-level resume callback has completed successfully, the PM
|
||||
core regards the device as fully operational, which means that the device
|
||||
_must_ be able to complete I/O operations as needed. The runtime PM status
|
||||
of the device is then 'active'.
|
||||
* Once the subsystem-level resume callback (or the driver resume callback, if
|
||||
invoked directly) has completed successfully, the PM core regards the device
|
||||
as fully operational, which means that the device _must_ be able to complete
|
||||
I/O operations as needed. The runtime PM status of the device is then
|
||||
'active'.
|
||||
|
||||
* If the subsystem-level resume callback returns an error code, the PM core
|
||||
regards this as a fatal error and will refuse to run the helper functions
|
||||
described in Section 4 for the device, until its status is directly set
|
||||
either to 'active' or to 'suspended' (the PM core provides special helper
|
||||
functions for this purpose).
|
||||
* If the resume callback returns an error code, the PM core regards this as a
|
||||
fatal error and will refuse to run the helper functions described in Section
|
||||
4 for the device, until its status is directly set to either 'active', or
|
||||
'suspended' (by means of special helper functions provided by the PM core
|
||||
for this purpose).
|
||||
|
||||
The subsystem-level idle callback is executed by the PM core whenever the device
|
||||
appears to be idle, which is indicated to the PM core by two counters, the
|
||||
device's usage counter and the counter of 'active' children of the device.
|
||||
The idle callback (a subsystem-level one, if present, or the driver one) is
|
||||
executed by the PM core whenever the device appears to be idle, which is
|
||||
indicated to the PM core by two counters, the device's usage counter and the
|
||||
counter of 'active' children of the device.
|
||||
|
||||
* If any of these counters is decreased using a helper function provided by
|
||||
the PM core and it turns out to be equal to zero, the other counter is
|
||||
checked. If that counter also is equal to zero, the PM core executes the
|
||||
subsystem-level idle callback with the device as an argument.
|
||||
idle callback with the device as its argument.
|
||||
|
||||
The action performed by a subsystem-level idle callback is totally dependent on
|
||||
the subsystem in question, but the expected and recommended action is to check
|
||||
The action performed by the idle callback is totally dependent on the subsystem
|
||||
(or driver) in question, but the expected and recommended action is to check
|
||||
if the device can be suspended (i.e. if all of the conditions necessary for
|
||||
suspending the device are satisfied) and to queue up a suspend request for the
|
||||
device in that case. The value returned by this callback is ignored by the PM
|
||||
core.
|
||||
|
||||
The helper functions provided by the PM core, described in Section 4, guarantee
|
||||
that the following constraints are met with respect to the bus type's runtime
|
||||
PM callbacks:
|
||||
that the following constraints are met with respect to runtime PM callbacks for
|
||||
one device:
|
||||
|
||||
(1) The callbacks are mutually exclusive (e.g. it is forbidden to execute
|
||||
->runtime_suspend() in parallel with ->runtime_resume() or with another
|
||||
|
|
|
|||
|
|
@ -41,7 +41,6 @@ ldd
|
|||
Debugging modules
|
||||
The proc file system
|
||||
Starting points for debugging scripting languages etc.
|
||||
Dumptool & Lcrash
|
||||
SysRq
|
||||
References
|
||||
Special Thanks
|
||||
|
|
@ -2455,39 +2454,6 @@ jdb <filename> another fully interactive gdb style debugger.
|
|||
|
||||
|
||||
|
||||
Dumptool & Lcrash ( lkcd )
|
||||
==========================
|
||||
Michael Holzheu & others here at IBM have a fairly mature port of
|
||||
SGI's lcrash tool which allows one to look at kernel structures in a
|
||||
running kernel.
|
||||
|
||||
It also complements a tool called dumptool which dumps all the kernel's
|
||||
memory pages & registers to either a tape or a disk.
|
||||
This can be used by tech support or an ambitious end user do
|
||||
post mortem debugging of a machine like gdb core dumps.
|
||||
|
||||
Going into how to use this tool in detail will be explained
|
||||
in other documentation supplied by IBM with the patches & the
|
||||
lcrash homepage http://oss.sgi.com/projects/lkcd/ & the lcrash manpage.
|
||||
|
||||
How they work
|
||||
-------------
|
||||
Lcrash is a perfectly normal program,however, it requires 2
|
||||
additional files, Kerntypes which is built using a patch to the
|
||||
linux kernel sources in the linux root directory & the System.map.
|
||||
|
||||
Kerntypes is an objectfile whose sole purpose in life
|
||||
is to provide stabs debug info to lcrash, to do this
|
||||
Kerntypes is built from kerntypes.c which just includes the most commonly
|
||||
referenced header files used when debugging, lcrash can then read the
|
||||
.stabs section of this file.
|
||||
|
||||
Debugging a live system it uses /dev/mem
|
||||
alternatively for post mortem debugging it uses the data
|
||||
collected by dumptool.
|
||||
|
||||
|
||||
|
||||
SysRq
|
||||
=====
|
||||
This is now supported by linux for s/390 & z/Architecture.
|
||||
|
|
|
|||
|
|
@ -16,32 +16,13 @@ fill in to get the driver working.
|
|||
Compile Time Flags
|
||||
==================
|
||||
|
||||
The driver may be either io mapped or memory mapped. This is
|
||||
selectable by configuration flags:
|
||||
|
||||
CONFIG_53C700_MEM_MAPPED
|
||||
|
||||
define if the driver is memory mapped.
|
||||
|
||||
CONFIG_53C700_IO_MAPPED
|
||||
|
||||
define if the driver is to be io mapped.
|
||||
|
||||
One or other of the above flags *must* be defined.
|
||||
|
||||
Other flags are:
|
||||
A compile time flag is:
|
||||
|
||||
CONFIG_53C700_LE_ON_BE
|
||||
|
||||
define if the chipset must be supported in little endian mode on a big
|
||||
endian architecture (used for the 700 on parisc).
|
||||
|
||||
CONFIG_53C700_USE_CONSISTENT
|
||||
|
||||
allocate consistent memory (should only be used if your architecture
|
||||
has a mixture of consistent and inconsistent memory). Fully
|
||||
consistent or fully inconsistent architectures should not define this.
|
||||
|
||||
|
||||
Using the Chip Core Driver
|
||||
==========================
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
00-INDEX
|
||||
- this file.
|
||||
LSM.txt
|
||||
- description of the Linux Security Module framework.
|
||||
SELinux.txt
|
||||
- how to get started with the SELinux security enhancement.
|
||||
Smack.txt
|
||||
|
|
|
|||
|
|
@ -0,0 +1,34 @@
|
|||
Linux Security Module framework
|
||||
-------------------------------
|
||||
|
||||
The Linux Security Module (LSM) framework provides a mechanism for
|
||||
various security checks to be hooked by new kernel extensions. The name
|
||||
"module" is a bit of a misnomer since these extensions are not actually
|
||||
loadable kernel modules. Instead, they are selectable at build-time via
|
||||
CONFIG_DEFAULT_SECURITY and can be overridden at boot-time via the
|
||||
"security=..." kernel command line argument, in the case where multiple
|
||||
LSMs were built into a given kernel.
|
||||
|
||||
The primary users of the LSM interface are Mandatory Access Control
|
||||
(MAC) extensions which provide a comprehensive security policy. Examples
|
||||
include SELinux, Smack, Tomoyo, and AppArmor. In addition to the larger
|
||||
MAC extensions, other extensions can be built using the LSM to provide
|
||||
specific changes to system operation when these tweaks are not available
|
||||
in the core functionality of Linux itself.
|
||||
|
||||
Without a specific LSM built into the kernel, the default LSM will be the
|
||||
Linux capabilities system. Most LSMs choose to extend the capabilities
|
||||
system, building their checks on top of the defined capability hooks.
|
||||
For more details on capabilities, see capabilities(7) in the Linux
|
||||
man-pages project.
|
||||
|
||||
Based on http://kerneltrap.org/Linux/Documenting_Security_Module_Intent,
|
||||
a new LSM is accepted into the kernel when its intent (a description of
|
||||
what it tries to protect against and in what cases one would expect to
|
||||
use it) has been appropriately documented in Documentation/security/.
|
||||
This allows an LSM's code to be easily compared to its goals, and so
|
||||
that end users and distros can make a more informed decision about which
|
||||
LSMs suit their requirements.
|
||||
|
||||
For extensive documentation on the available LSM hook interfaces, please
|
||||
see include/linux/security.h.
|
||||
|
|
@ -221,10 +221,10 @@ The Linux kernel supports the following types of credentials:
|
|||
(5) LSM
|
||||
|
||||
The Linux Security Module allows extra controls to be placed over the
|
||||
operations that a task may do. Currently Linux supports two main
|
||||
alternate LSM options: SELinux and Smack.
|
||||
operations that a task may do. Currently Linux supports several LSM
|
||||
options.
|
||||
|
||||
Both work by labelling the objects in a system and then applying sets of
|
||||
Some work by labelling the objects in a system and then applying sets of
|
||||
rules (policies) that say what operations a task with one label may do to
|
||||
an object with another label.
|
||||
|
||||
|
|
|
|||
|
|
@ -101,7 +101,7 @@ hardware.
|
|||
Returns the current state of modem control inputs. The state
|
||||
of the outputs should not be returned, since the core keeps
|
||||
track of their state. The state information should include:
|
||||
- TIOCM_DCD state of DCD signal
|
||||
- TIOCM_CAR state of DCD signal
|
||||
- TIOCM_CTS state of CTS signal
|
||||
- TIOCM_DSR state of DSR signal
|
||||
- TIOCM_RI state of RI signal
|
||||
|
|
|
|||
|
|
@ -42,19 +42,7 @@ ALC260
|
|||
|
||||
ALC262
|
||||
======
|
||||
fujitsu Fujitsu Laptop
|
||||
benq Benq ED8
|
||||
benq-t31 Benq T31
|
||||
hippo Hippo (ATI) with jack detection, Sony UX-90s
|
||||
hippo_1 Hippo (Benq) with jack detection
|
||||
toshiba-s06 Toshiba S06
|
||||
toshiba-rx1 Toshiba RX1
|
||||
tyan Tyan Thunder n6650W (S2915-E)
|
||||
ultra Samsung Q1 Ultra Vista model
|
||||
lenovo-3000 Lenovo 3000 y410
|
||||
nec NEC Versa S9100
|
||||
basic fixed pin assignment w/o SPDIF
|
||||
auto auto-config reading BIOS (default)
|
||||
N/A
|
||||
|
||||
ALC267/268
|
||||
==========
|
||||
|
|
@ -350,7 +338,6 @@ STAC92HD83*
|
|||
mic-ref Reference board with power management for ports
|
||||
dell-s14 Dell laptop
|
||||
dell-vostro-3500 Dell Vostro 3500 laptop
|
||||
hp HP laptops with (inverted) mute-LED
|
||||
hp-dv7-4000 HP dv-7 4000
|
||||
auto BIOS setup (default)
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,188 @@
|
|||
compress_offload.txt
|
||||
=====================
|
||||
Pierre-Louis.Bossart <pierre-louis.bossart@linux.intel.com>
|
||||
Vinod Koul <vinod.koul@linux.intel.com>
|
||||
|
||||
Overview
|
||||
|
||||
Since its early days, the ALSA API was defined with PCM support or
|
||||
constant bitrates payloads such as IEC61937 in mind. Arguments and
|
||||
returned values in frames are the norm, making it a challenge to
|
||||
extend the existing API to compressed data streams.
|
||||
|
||||
In recent years, audio digital signal processors (DSP) were integrated
|
||||
in system-on-chip designs, and DSPs are also integrated in audio
|
||||
codecs. Processing compressed data on such DSPs results in a dramatic
|
||||
reduction of power consumption compared to host-based
|
||||
processing. Support for such hardware has not been very good in Linux,
|
||||
mostly because of a lack of a generic API available in the mainline
|
||||
kernel.
|
||||
|
||||
Rather than requiring a compability break with an API change of the
|
||||
ALSA PCM interface, a new 'Compressed Data' API is introduced to
|
||||
provide a control and data-streaming interface for audio DSPs.
|
||||
|
||||
The design of this API was inspired by the 2-year experience with the
|
||||
Intel Moorestown SOC, with many corrections required to upstream the
|
||||
API in the mainline kernel instead of the staging tree and make it
|
||||
usable by others.
|
||||
|
||||
Requirements
|
||||
|
||||
The main requirements are:
|
||||
|
||||
- separation between byte counts and time. Compressed formats may have
|
||||
a header per file, per frame, or no header at all. The payload size
|
||||
may vary from frame-to-frame. As a result, it is not possible to
|
||||
estimate reliably the duration of audio buffers when handling
|
||||
compressed data. Dedicated mechanisms are required to allow for
|
||||
reliable audio-video synchronization, which requires precise
|
||||
reporting of the number of samples rendered at any given time.
|
||||
|
||||
- Handling of multiple formats. PCM data only requires a specification
|
||||
of the sampling rate, number of channels and bits per sample. In
|
||||
contrast, compressed data comes in a variety of formats. Audio DSPs
|
||||
may also provide support for a limited number of audio encoders and
|
||||
decoders embedded in firmware, or may support more choices through
|
||||
dynamic download of libraries.
|
||||
|
||||
- Focus on main formats. This API provides support for the most
|
||||
popular formats used for audio and video capture and playback. It is
|
||||
likely that as audio compression technology advances, new formats
|
||||
will be added.
|
||||
|
||||
- Handling of multiple configurations. Even for a given format like
|
||||
AAC, some implementations may support AAC multichannel but HE-AAC
|
||||
stereo. Likewise WMA10 level M3 may require too much memory and cpu
|
||||
cycles. The new API needs to provide a generic way of listing these
|
||||
formats.
|
||||
|
||||
- Rendering/Grabbing only. This API does not provide any means of
|
||||
hardware acceleration, where PCM samples are provided back to
|
||||
user-space for additional processing. This API focuses instead on
|
||||
streaming compressed data to a DSP, with the assumption that the
|
||||
decoded samples are routed to a physical output or logical back-end.
|
||||
|
||||
- Complexity hiding. Existing user-space multimedia frameworks all
|
||||
have existing enums/structures for each compressed format. This new
|
||||
API assumes the existence of a platform-specific compatibility layer
|
||||
to expose, translate and make use of the capabilities of the audio
|
||||
DSP, eg. Android HAL or PulseAudio sinks. By construction, regular
|
||||
applications are not supposed to make use of this API.
|
||||
|
||||
|
||||
Design
|
||||
|
||||
The new API shares a number of concepts with with the PCM API for flow
|
||||
control. Start, pause, resume, drain and stop commands have the same
|
||||
semantics no matter what the content is.
|
||||
|
||||
The concept of memory ring buffer divided in a set of fragments is
|
||||
borrowed from the ALSA PCM API. However, only sizes in bytes can be
|
||||
specified.
|
||||
|
||||
Seeks/trick modes are assumed to be handled by the host.
|
||||
|
||||
The notion of rewinds/forwards is not supported. Data committed to the
|
||||
ring buffer cannot be invalidated, except when dropping all buffers.
|
||||
|
||||
The Compressed Data API does not make any assumptions on how the data
|
||||
is transmitted to the audio DSP. DMA transfers from main memory to an
|
||||
embedded audio cluster or to a SPI interface for external DSPs are
|
||||
possible. As in the ALSA PCM case, a core set of routines is exposed;
|
||||
each driver implementer will have to write support for a set of
|
||||
mandatory routines and possibly make use of optional ones.
|
||||
|
||||
The main additions are
|
||||
|
||||
- get_caps
|
||||
This routine returns the list of audio formats supported. Querying the
|
||||
codecs on a capture stream will return encoders, decoders will be
|
||||
listed for playback streams.
|
||||
|
||||
- get_codec_caps For each codec, this routine returns a list of
|
||||
capabilities. The intent is to make sure all the capabilities
|
||||
correspond to valid settings, and to minimize the risks of
|
||||
configuration failures. For example, for a complex codec such as AAC,
|
||||
the number of channels supported may depend on a specific profile. If
|
||||
the capabilities were exposed with a single descriptor, it may happen
|
||||
that a specific combination of profiles/channels/formats may not be
|
||||
supported. Likewise, embedded DSPs have limited memory and cpu cycles,
|
||||
it is likely that some implementations make the list of capabilities
|
||||
dynamic and dependent on existing workloads. In addition to codec
|
||||
settings, this routine returns the minimum buffer size handled by the
|
||||
implementation. This information can be a function of the DMA buffer
|
||||
sizes, the number of bytes required to synchronize, etc, and can be
|
||||
used by userspace to define how much needs to be written in the ring
|
||||
buffer before playback can start.
|
||||
|
||||
- set_params
|
||||
This routine sets the configuration chosen for a specific codec. The
|
||||
most important field in the parameters is the codec type; in most
|
||||
cases decoders will ignore other fields, while encoders will strictly
|
||||
comply to the settings
|
||||
|
||||
- get_params
|
||||
This routines returns the actual settings used by the DSP. Changes to
|
||||
the settings should remain the exception.
|
||||
|
||||
- get_timestamp
|
||||
The timestamp becomes a multiple field structure. It lists the number
|
||||
of bytes transferred, the number of samples processed and the number
|
||||
of samples rendered/grabbed. All these values can be used to determine
|
||||
the avarage bitrate, figure out if the ring buffer needs to be
|
||||
refilled or the delay due to decoding/encoding/io on the DSP.
|
||||
|
||||
Note that the list of codecs/profiles/modes was derived from the
|
||||
OpenMAX AL specification instead of reinventing the wheel.
|
||||
Modifications include:
|
||||
- Addition of FLAC and IEC formats
|
||||
- Merge of encoder/decoder capabilities
|
||||
- Profiles/modes listed as bitmasks to make descriptors more compact
|
||||
- Addition of set_params for decoders (missing in OpenMAX AL)
|
||||
- Addition of AMR/AMR-WB encoding modes (missing in OpenMAX AL)
|
||||
- Addition of format information for WMA
|
||||
- Addition of encoding options when required (derived from OpenMAX IL)
|
||||
- Addition of rateControlSupported (missing in OpenMAX AL)
|
||||
|
||||
Not supported:
|
||||
|
||||
- Support for VoIP/circuit-switched calls is not the target of this
|
||||
API. Support for dynamic bit-rate changes would require a tight
|
||||
coupling between the DSP and the host stack, limiting power savings.
|
||||
|
||||
- Packet-loss concealment is not supported. This would require an
|
||||
additional interface to let the decoder synthesize data when frames
|
||||
are lost during transmission. This may be added in the future.
|
||||
|
||||
- Volume control/routing is not handled by this API. Devices exposing a
|
||||
compressed data interface will be considered as regular ALSA devices;
|
||||
volume changes and routing information will be provided with regular
|
||||
ALSA kcontrols.
|
||||
|
||||
- Embedded audio effects. Such effects should be enabled in the same
|
||||
manner, no matter if the input was PCM or compressed.
|
||||
|
||||
- multichannel IEC encoding. Unclear if this is required.
|
||||
|
||||
- Encoding/decoding acceleration is not supported as mentioned
|
||||
above. It is possible to route the output of a decoder to a capture
|
||||
stream, or even implement transcoding capabilities. This routing
|
||||
would be enabled with ALSA kcontrols.
|
||||
|
||||
- Audio policy/resource management. This API does not provide any
|
||||
hooks to query the utilization of the audio DSP, nor any premption
|
||||
mechanisms.
|
||||
|
||||
- No notion of underun/overrun. Since the bytes written are compressed
|
||||
in nature and data written/read doesn't translate directly to
|
||||
rendered output in time, this does not deal with underrun/overun and
|
||||
maybe dealt in user-library
|
||||
|
||||
Credits:
|
||||
- Mark Brown and Liam Girdwood for discussions on the need for this API
|
||||
- Harsha Priya for her work on intel_sst compressed API
|
||||
- Rakesh Ughreja for valuable feedback
|
||||
- Sing Nallasellan, Sikkandar Madar and Prasanna Samaga for
|
||||
demonstrating and quantifying the benefits of audio offload on a
|
||||
real platform.
|
||||
|
|
@ -49,6 +49,7 @@ show up in /proc/sys/kernel:
|
|||
- panic
|
||||
- panic_on_oops
|
||||
- panic_on_unrecovered_nmi
|
||||
- panic_on_stackoverflow
|
||||
- pid_max
|
||||
- powersave-nap [ PPC only ]
|
||||
- printk
|
||||
|
|
@ -393,6 +394,19 @@ Controls the kernel's behaviour when an oops or BUG is encountered.
|
|||
|
||||
==============================================================
|
||||
|
||||
panic_on_stackoverflow:
|
||||
|
||||
Controls the kernel's behavior when detecting the overflows of
|
||||
kernel, IRQ and exception stacks except a user stack.
|
||||
This file shows up if CONFIG_DEBUG_STACKOVERFLOW is enabled.
|
||||
|
||||
0: try to continue operation.
|
||||
|
||||
1: panic immediately.
|
||||
|
||||
==============================================================
|
||||
|
||||
|
||||
pid_max:
|
||||
|
||||
PID allocation wrap value. When the kernel's next PID value
|
||||
|
|
@ -401,6 +415,14 @@ PIDs of value pid_max or larger are not allocated.
|
|||
|
||||
==============================================================
|
||||
|
||||
ns_last_pid:
|
||||
|
||||
The last pid allocated in the current (the one task using this sysctl
|
||||
lives in) pid namespace. When selecting a pid for a next task on fork
|
||||
kernel tries to allocate a number starting from this one.
|
||||
|
||||
==============================================================
|
||||
|
||||
powersave-nap: (PPC only)
|
||||
|
||||
If set, Linux-PPC will use the 'nap' mode of powersaving,
|
||||
|
|
|
|||
|
|
@ -40,8 +40,8 @@ but the call_site can usually be used to extrapolate that information.
|
|||
==================
|
||||
mm_page_alloc page=%p pfn=%lu order=%d migratetype=%d gfp_flags=%s
|
||||
mm_page_alloc_zone_locked page=%p pfn=%lu order=%u migratetype=%d cpu=%d percpu_refill=%d
|
||||
mm_page_free_direct page=%p pfn=%lu order=%d
|
||||
mm_pagevec_free page=%p pfn=%lu order=%d cold=%d
|
||||
mm_page_free page=%p pfn=%lu order=%d
|
||||
mm_page_free_batched page=%p pfn=%lu order=%d cold=%d
|
||||
|
||||
These four events deal with page allocation and freeing. mm_page_alloc is
|
||||
a simple indicator of page allocator activity. Pages may be allocated from
|
||||
|
|
@ -53,13 +53,13 @@ amounts of activity imply high activity on the zone->lock. Taking this lock
|
|||
impairs performance by disabling interrupts, dirtying cache lines between
|
||||
CPUs and serialising many CPUs.
|
||||
|
||||
When a page is freed directly by the caller, the mm_page_free_direct event
|
||||
When a page is freed directly by the caller, the only mm_page_free event
|
||||
is triggered. Significant amounts of activity here could indicate that the
|
||||
callers should be batching their activities.
|
||||
|
||||
When pages are freed using a pagevec, the mm_pagevec_free is
|
||||
triggered. Broadly speaking, pages are taken off the LRU lock in bulk and
|
||||
freed in batch with a pagevec. Significant amounts of activity here could
|
||||
When pages are freed in batch, the also mm_page_free_batched is triggered.
|
||||
Broadly speaking, pages are taken off the LRU lock in bulk and
|
||||
freed in batch with a page list. Significant amounts of activity here could
|
||||
indicate that the system is under memory pressure and can also indicate
|
||||
contention on the zone->lru_lock.
|
||||
|
||||
|
|
|
|||
|
|
@ -17,8 +17,8 @@ use Getopt::Long;
|
|||
|
||||
# Tracepoint events
|
||||
use constant MM_PAGE_ALLOC => 1;
|
||||
use constant MM_PAGE_FREE_DIRECT => 2;
|
||||
use constant MM_PAGEVEC_FREE => 3;
|
||||
use constant MM_PAGE_FREE => 2;
|
||||
use constant MM_PAGE_FREE_BATCHED => 3;
|
||||
use constant MM_PAGE_PCPU_DRAIN => 4;
|
||||
use constant MM_PAGE_ALLOC_ZONE_LOCKED => 5;
|
||||
use constant MM_PAGE_ALLOC_EXTFRAG => 6;
|
||||
|
|
@ -223,10 +223,10 @@ EVENT_PROCESS:
|
|||
# Perl Switch() sucks majorly
|
||||
if ($tracepoint eq "mm_page_alloc") {
|
||||
$perprocesspid{$process_pid}->{MM_PAGE_ALLOC}++;
|
||||
} elsif ($tracepoint eq "mm_page_free_direct") {
|
||||
$perprocesspid{$process_pid}->{MM_PAGE_FREE_DIRECT}++;
|
||||
} elsif ($tracepoint eq "mm_pagevec_free") {
|
||||
$perprocesspid{$process_pid}->{MM_PAGEVEC_FREE}++;
|
||||
} elsif ($tracepoint eq "mm_page_free") {
|
||||
$perprocesspid{$process_pid}->{MM_PAGE_FREE}++
|
||||
} elsif ($tracepoint eq "mm_page_free_batched") {
|
||||
$perprocesspid{$process_pid}->{MM_PAGE_FREE_BATCHED}++;
|
||||
} elsif ($tracepoint eq "mm_page_pcpu_drain") {
|
||||
$perprocesspid{$process_pid}->{MM_PAGE_PCPU_DRAIN}++;
|
||||
$perprocesspid{$process_pid}->{STATE_PCPU_PAGES_DRAINED}++;
|
||||
|
|
@ -336,8 +336,8 @@ sub dump_stats {
|
|||
$process_pid,
|
||||
$stats{$process_pid}->{MM_PAGE_ALLOC},
|
||||
$stats{$process_pid}->{MM_PAGE_ALLOC_ZONE_LOCKED},
|
||||
$stats{$process_pid}->{MM_PAGE_FREE_DIRECT},
|
||||
$stats{$process_pid}->{MM_PAGEVEC_FREE},
|
||||
$stats{$process_pid}->{MM_PAGE_FREE},
|
||||
$stats{$process_pid}->{MM_PAGE_FREE_BATCHED},
|
||||
$stats{$process_pid}->{MM_PAGE_PCPU_DRAIN},
|
||||
$stats{$process_pid}->{HIGH_PCPU_DRAINS},
|
||||
$stats{$process_pid}->{HIGH_PCPU_REFILLS},
|
||||
|
|
@ -364,8 +364,8 @@ sub aggregate_perprocesspid() {
|
|||
|
||||
$perprocess{$process}->{MM_PAGE_ALLOC} += $perprocesspid{$process_pid}->{MM_PAGE_ALLOC};
|
||||
$perprocess{$process}->{MM_PAGE_ALLOC_ZONE_LOCKED} += $perprocesspid{$process_pid}->{MM_PAGE_ALLOC_ZONE_LOCKED};
|
||||
$perprocess{$process}->{MM_PAGE_FREE_DIRECT} += $perprocesspid{$process_pid}->{MM_PAGE_FREE_DIRECT};
|
||||
$perprocess{$process}->{MM_PAGEVEC_FREE} += $perprocesspid{$process_pid}->{MM_PAGEVEC_FREE};
|
||||
$perprocess{$process}->{MM_PAGE_FREE} += $perprocesspid{$process_pid}->{MM_PAGE_FREE};
|
||||
$perprocess{$process}->{MM_PAGE_FREE_BATCHED} += $perprocesspid{$process_pid}->{MM_PAGE_FREE_BATCHED};
|
||||
$perprocess{$process}->{MM_PAGE_PCPU_DRAIN} += $perprocesspid{$process_pid}->{MM_PAGE_PCPU_DRAIN};
|
||||
$perprocess{$process}->{HIGH_PCPU_DRAINS} += $perprocesspid{$process_pid}->{HIGH_PCPU_DRAINS};
|
||||
$perprocess{$process}->{HIGH_PCPU_REFILLS} += $perprocesspid{$process_pid}->{HIGH_PCPU_REFILLS};
|
||||
|
|
|
|||
|
|
@ -93,14 +93,14 @@ By specifying the -a switch and analysing sleep, the system-wide events
|
|||
for a duration of time can be examined.
|
||||
|
||||
$ perf stat -a \
|
||||
-e kmem:mm_page_alloc -e kmem:mm_page_free_direct \
|
||||
-e kmem:mm_pagevec_free \
|
||||
-e kmem:mm_page_alloc -e kmem:mm_page_free \
|
||||
-e kmem:mm_page_free_batched \
|
||||
sleep 10
|
||||
Performance counter stats for 'sleep 10':
|
||||
|
||||
9630 kmem:mm_page_alloc
|
||||
2143 kmem:mm_page_free_direct
|
||||
7424 kmem:mm_pagevec_free
|
||||
2143 kmem:mm_page_free
|
||||
7424 kmem:mm_page_free_batched
|
||||
|
||||
10.002577764 seconds time elapsed
|
||||
|
||||
|
|
@ -119,15 +119,15 @@ basis using set_ftrace_pid.
|
|||
Events can be activated and tracked for the duration of a process on a local
|
||||
basis using PCL such as follows.
|
||||
|
||||
$ perf stat -e kmem:mm_page_alloc -e kmem:mm_page_free_direct \
|
||||
-e kmem:mm_pagevec_free ./hackbench 10
|
||||
$ perf stat -e kmem:mm_page_alloc -e kmem:mm_page_free \
|
||||
-e kmem:mm_page_free_batched ./hackbench 10
|
||||
Time: 0.909
|
||||
|
||||
Performance counter stats for './hackbench 10':
|
||||
|
||||
17803 kmem:mm_page_alloc
|
||||
12398 kmem:mm_page_free_direct
|
||||
4827 kmem:mm_pagevec_free
|
||||
12398 kmem:mm_page_free
|
||||
4827 kmem:mm_page_free_batched
|
||||
|
||||
0.973913387 seconds time elapsed
|
||||
|
||||
|
|
@ -146,8 +146,8 @@ to know what the standard deviation is. By and large, this is left to the
|
|||
performance analyst to do it by hand. In the event that the discrete event
|
||||
occurrences are useful to the performance analyst, then perf can be used.
|
||||
|
||||
$ perf stat --repeat 5 -e kmem:mm_page_alloc -e kmem:mm_page_free_direct
|
||||
-e kmem:mm_pagevec_free ./hackbench 10
|
||||
$ perf stat --repeat 5 -e kmem:mm_page_alloc -e kmem:mm_page_free
|
||||
-e kmem:mm_page_free_batched ./hackbench 10
|
||||
Time: 0.890
|
||||
Time: 0.895
|
||||
Time: 0.915
|
||||
|
|
@ -157,8 +157,8 @@ occurrences are useful to the performance analyst, then perf can be used.
|
|||
Performance counter stats for './hackbench 10' (5 runs):
|
||||
|
||||
16630 kmem:mm_page_alloc ( +- 3.542% )
|
||||
11486 kmem:mm_page_free_direct ( +- 4.771% )
|
||||
4730 kmem:mm_pagevec_free ( +- 2.325% )
|
||||
11486 kmem:mm_page_free ( +- 4.771% )
|
||||
4730 kmem:mm_page_free_batched ( +- 2.325% )
|
||||
|
||||
0.982653002 seconds time elapsed ( +- 1.448% )
|
||||
|
||||
|
|
@ -168,15 +168,15 @@ aggregation of discrete events, then a script would need to be developed.
|
|||
Using --repeat, it is also possible to view how events are fluctuating over
|
||||
time on a system-wide basis using -a and sleep.
|
||||
|
||||
$ perf stat -e kmem:mm_page_alloc -e kmem:mm_page_free_direct \
|
||||
-e kmem:mm_pagevec_free \
|
||||
$ perf stat -e kmem:mm_page_alloc -e kmem:mm_page_free \
|
||||
-e kmem:mm_page_free_batched \
|
||||
-a --repeat 10 \
|
||||
sleep 1
|
||||
Performance counter stats for 'sleep 1' (10 runs):
|
||||
|
||||
1066 kmem:mm_page_alloc ( +- 26.148% )
|
||||
182 kmem:mm_page_free_direct ( +- 5.464% )
|
||||
890 kmem:mm_pagevec_free ( +- 30.079% )
|
||||
182 kmem:mm_page_free ( +- 5.464% )
|
||||
890 kmem:mm_page_free_batched ( +- 30.079% )
|
||||
|
||||
1.002251757 seconds time elapsed ( +- 0.005% )
|
||||
|
||||
|
|
@ -220,8 +220,8 @@ were generating events within the kernel. To begin this sort of analysis, the
|
|||
data must be recorded. At the time of writing, this required root:
|
||||
|
||||
$ perf record -c 1 \
|
||||
-e kmem:mm_page_alloc -e kmem:mm_page_free_direct \
|
||||
-e kmem:mm_pagevec_free \
|
||||
-e kmem:mm_page_alloc -e kmem:mm_page_free \
|
||||
-e kmem:mm_page_free_batched \
|
||||
./hackbench 10
|
||||
Time: 0.894
|
||||
[ perf record: Captured and wrote 0.733 MB perf.data (~32010 samples) ]
|
||||
|
|
@ -260,8 +260,8 @@ noticed that X was generating an insane amount of page allocations so let's look
|
|||
at it:
|
||||
|
||||
$ perf record -c 1 -f \
|
||||
-e kmem:mm_page_alloc -e kmem:mm_page_free_direct \
|
||||
-e kmem:mm_pagevec_free \
|
||||
-e kmem:mm_page_alloc -e kmem:mm_page_free \
|
||||
-e kmem:mm_page_free_batched \
|
||||
-p `pidof X`
|
||||
|
||||
This was interrupted after a few seconds and
|
||||
|
|
|
|||
|
|
@ -47,10 +47,11 @@ This allows to filter away annoying devices that talk continuously.
|
|||
|
||||
2. Find which bus connects to the desired device
|
||||
|
||||
Run "cat /proc/bus/usb/devices", and find the T-line which corresponds to
|
||||
the device. Usually you do it by looking for the vendor string. If you have
|
||||
many similar devices, unplug one and compare two /proc/bus/usb/devices outputs.
|
||||
The T-line will have a bus number. Example:
|
||||
Run "cat /sys/kernel/debug/usb/devices", and find the T-line which corresponds
|
||||
to the device. Usually you do it by looking for the vendor string. If you have
|
||||
many similar devices, unplug one and compare the two
|
||||
/sys/kernel/debug/usb/devices outputs. The T-line will have a bus number.
|
||||
Example:
|
||||
|
||||
T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
|
||||
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
|
||||
|
|
@ -58,7 +59,10 @@ P: Vendor=0557 ProdID=2004 Rev= 1.00
|
|||
S: Manufacturer=ATEN
|
||||
S: Product=UC100KM V2.00
|
||||
|
||||
Bus=03 means it's bus 3.
|
||||
"Bus=03" means it's bus 3. Alternatively, you can look at the output from
|
||||
"lsusb" and get the bus number from the appropriate line. Example:
|
||||
|
||||
Bus 003 Device 002: ID 0557:2004 ATEN UC100KM V2.00
|
||||
|
||||
3. Start 'cat'
|
||||
|
||||
|
|
|
|||
|
|
@ -177,7 +177,7 @@ II. Credits
|
|||
|
||||
Benjamin Herrenschmidt (IBM?) started this work when he discussed such design
|
||||
with the Xorg community in 2005 [1, 2]. In the end of 2007, Paulo Zanoni and
|
||||
Tiago Vignatti (both of C3SL/Federal University of Paraná) proceeded his work
|
||||
Tiago Vignatti (both of C3SL/Federal University of Paraná) proceeded his work
|
||||
enhancing the kernel code to adapt as a kernel module and also did the
|
||||
implementation of the user space side [3]. Now (2009) Tiago Vignatti and Dave
|
||||
Airlie finally put this work in shape and queued to Jesse Barnes' PCI tree.
|
||||
|
|
|
|||
|
|
@ -1466,6 +1466,31 @@ is supported; 2 if the processor requires all virtual machines to have
|
|||
an RMA, or 1 if the processor can use an RMA but doesn't require it,
|
||||
because it supports the Virtual RMA (VRMA) facility.
|
||||
|
||||
4.64 KVM_NMI
|
||||
|
||||
Capability: KVM_CAP_USER_NMI
|
||||
Architectures: x86
|
||||
Type: vcpu ioctl
|
||||
Parameters: none
|
||||
Returns: 0 on success, -1 on error
|
||||
|
||||
Queues an NMI on the thread's vcpu. Note this is well defined only
|
||||
when KVM_CREATE_IRQCHIP has not been called, since this is an interface
|
||||
between the virtual cpu core and virtual local APIC. After KVM_CREATE_IRQCHIP
|
||||
has been called, this interface is completely emulated within the kernel.
|
||||
|
||||
To use this to emulate the LINT1 input with KVM_CREATE_IRQCHIP, use the
|
||||
following algorithm:
|
||||
|
||||
- pause the vpcu
|
||||
- read the local APIC's state (KVM_GET_LAPIC)
|
||||
- check whether changing LINT1 will queue an NMI (see the LVT entry for LINT1)
|
||||
- if so, issue KVM_NMI
|
||||
- resume the vcpu
|
||||
|
||||
Some guests configure the LINT1 NMI input to cause a panic, aiding in
|
||||
debugging.
|
||||
|
||||
5. The kvm_run structure
|
||||
|
||||
Application code obtains a pointer to the kvm_run structure by
|
||||
|
|
|
|||
|
|
@ -117,7 +117,7 @@ can be influenced by kernel parameters:
|
|||
|
||||
slub_min_objects=x (default 4)
|
||||
slub_min_order=x (default 0)
|
||||
slub_max_order=x (default 1)
|
||||
slub_max_order=x (default 3 (PAGE_ALLOC_COSTLY_ORDER))
|
||||
|
||||
slub_min_objects allows to specify how many objects must at least fit
|
||||
into one slab in order for the allocation order to be acceptable.
|
||||
|
|
@ -131,7 +131,10 @@ slub_min_objects.
|
|||
slub_max_order specified the order at which slub_min_objects should no
|
||||
longer be checked. This is useful to avoid SLUB trying to generate
|
||||
super large order pages to fit slub_min_objects of a slab cache with
|
||||
large object sizes into one high order page.
|
||||
large object sizes into one high order page. Setting command line
|
||||
parameter debug_guardpage_minorder=N (N > 0), forces setting
|
||||
slub_max_order to 0, what cause minimum possible order of slabs
|
||||
allocation.
|
||||
|
||||
SLUB Debug output
|
||||
-----------------
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
00-INDEX
|
||||
- this file.
|
||||
convert_drivers_to_kernel_api.txt
|
||||
- how-to for converting old watchdog drivers to the new kernel API.
|
||||
hpwdt.txt
|
||||
- information on the HP iLO2 NMI watchdog
|
||||
pcwd-watchdog.txt
|
||||
|
|
|
|||
|
|
@ -163,6 +163,25 @@ Here is a simple example for a watchdog device:
|
|||
+};
|
||||
|
||||
|
||||
Handle the 'nowayout' feature
|
||||
-----------------------------
|
||||
|
||||
A few drivers use nowayout statically, i.e. there is no module parameter for it
|
||||
and only CONFIG_WATCHDOG_NOWAYOUT determines if the feature is going to be
|
||||
used. This needs to be converted by initializing the status variable of the
|
||||
watchdog_device like this:
|
||||
|
||||
.status = WATCHDOG_NOWAYOUT_INIT_STATUS,
|
||||
|
||||
Most drivers, however, also allow runtime configuration of nowayout, usually
|
||||
by adding a module parameter. The conversion for this would be something like:
|
||||
|
||||
watchdog_set_nowayout(&s3c2410_wdd, nowayout);
|
||||
|
||||
The module parameter itself needs to stay, everything else related to nowayout
|
||||
can go, though. This will likely be some code in open(), close() or write().
|
||||
|
||||
|
||||
Register the watchdog device
|
||||
----------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
The Linux WatchDog Timer Driver Core kernel API.
|
||||
===============================================
|
||||
Last reviewed: 22-Jul-2011
|
||||
Last reviewed: 29-Nov-2011
|
||||
|
||||
Wim Van Sebroeck <wim@iguana.be>
|
||||
|
||||
|
|
@ -142,6 +142,14 @@ bit-operations. The status bits that are defined are:
|
|||
* WDOG_NO_WAY_OUT: this bit stores the nowayout setting for the watchdog.
|
||||
If this bit is set then the watchdog timer will not be able to stop.
|
||||
|
||||
To set the WDOG_NO_WAY_OUT status bit (before registering your watchdog
|
||||
timer device) you can either:
|
||||
* set it statically in your watchdog_device struct with
|
||||
.status = WATCHDOG_NOWAYOUT_INIT_STATUS,
|
||||
(this will set the value the same as CONFIG_WATCHDOG_NOWAYOUT) or
|
||||
* use the following helper function:
|
||||
static inline void watchdog_set_nowayout(struct watchdog_device *wdd, int nowayout)
|
||||
|
||||
Note: The WatchDog Timer Driver Core supports the magic close feature and
|
||||
the nowayout feature. To use the magic close feature you must set the
|
||||
WDIOF_MAGICCLOSE bit in the options field of the watchdog's info structure.
|
||||
|
|
|
|||
152
MAINTAINERS
152
MAINTAINERS
|
|
@ -184,11 +184,6 @@ S: Maintained
|
|||
F: Documentation/filesystems/9p.txt
|
||||
F: fs/9p/
|
||||
|
||||
A2232 SERIAL BOARD DRIVER
|
||||
L: linux-m68k@lists.linux-m68k.org
|
||||
S: Orphan
|
||||
F: drivers/staging/generic_serial/ser_a2232*
|
||||
|
||||
AACRAID SCSI RAID DRIVER
|
||||
M: Adaptec OEM Raid Solutions <aacraid@adaptec.com>
|
||||
L: linux-scsi@vger.kernel.org
|
||||
|
|
@ -347,7 +342,7 @@ S: Supported
|
|||
F: drivers/mfd/adp5520.c
|
||||
F: drivers/video/backlight/adp5520_bl.c
|
||||
F: drivers/leds/leds-adp5520.c
|
||||
F: drivers/gpio/adp5520-gpio.c
|
||||
F: drivers/gpio/gpio-adp5520.c
|
||||
F: drivers/input/keyboard/adp5520-keys.c
|
||||
|
||||
ADP5588 QWERTY KEYPAD AND IO EXPANDER DRIVER (ADP5588/ADP5587)
|
||||
|
|
@ -356,7 +351,7 @@ L: device-drivers-devel@blackfin.uclinux.org
|
|||
W: http://wiki.analog.com/ADP5588
|
||||
S: Supported
|
||||
F: drivers/input/keyboard/adp5588-keys.c
|
||||
F: drivers/gpio/adp5588-gpio.c
|
||||
F: drivers/gpio/gpio-adp5588.c
|
||||
|
||||
ADP8860 BACKLIGHT DRIVER (ADP8860/ADP8861/ADP8863)
|
||||
M: Michael Hennerich <michael.hennerich@analog.com>
|
||||
|
|
@ -542,6 +537,7 @@ F: sound/soc/codecs/adau*
|
|||
F: sound/soc/codecs/adav*
|
||||
F: sound/soc/codecs/ad1*
|
||||
F: sound/soc/codecs/ssm*
|
||||
F: sound/soc/codecs/sigmadsp.*
|
||||
|
||||
ANALOG DEVICES INC ASOC DRIVERS
|
||||
L: uclinux-dist-devel@blackfin.uclinux.org
|
||||
|
|
@ -919,7 +915,6 @@ M: Lennert Buytenhek <kernel@wantstofly.org>
|
|||
M: Nicolas Pitre <nico@fluxnic.net>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Odd Fixes
|
||||
F: arch/arm/mach-loki/
|
||||
F: arch/arm/mach-kirkwood/
|
||||
F: arch/arm/mach-mv78xx0/
|
||||
F: arch/arm/mach-orion5x/
|
||||
|
|
@ -1081,8 +1076,8 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
|||
S: Maintained
|
||||
F: arch/arm/mach-s5pv210/mach-aquila.c
|
||||
F: arch/arm/mach-s5pv210/mach-goni.c
|
||||
F: arch/arm/mach-exynos4/mach-universal_c210.c
|
||||
F: arch/arm/mach-exynos4/mach-nuri.c
|
||||
F: arch/arm/mach-exynos/mach-universal_c210.c
|
||||
F: arch/arm/mach-exynos/mach-nuri.c
|
||||
|
||||
ARM/SAMSUNG S5P SERIES FIMC SUPPORT
|
||||
M: Kyungmin Park <kyungmin.park@samsung.com>
|
||||
|
|
@ -1110,7 +1105,6 @@ M: Tomasz Stanislawski <t.stanislaws@samsung.com>
|
|||
L: linux-arm-kernel@lists.infradead.org
|
||||
L: linux-media@vger.kernel.org
|
||||
S: Maintained
|
||||
F: arch/arm/plat-s5p/dev-tv.c
|
||||
F: drivers/media/video/s5p-tv/
|
||||
|
||||
ARM/SHMOBILE ARM ARCHITECTURE
|
||||
|
|
@ -1145,14 +1139,13 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
|||
W: http://www.mcuos.com
|
||||
S: Maintained
|
||||
F: arch/arm/mach-w90x900/
|
||||
F: arch/arm/mach-nuc93x/
|
||||
F: drivers/input/keyboard/w90p910_keypad.c
|
||||
F: drivers/input/touchscreen/w90p910_ts.c
|
||||
F: drivers/watchdog/nuc900_wdt.c
|
||||
F: drivers/net/ethernet/nuvoton/w90p910_ether.c
|
||||
F: drivers/mtd/nand/nuc900_nand.c
|
||||
F: drivers/rtc/rtc-nuc900.c
|
||||
F: drivers/spi/spi_nuc900.c
|
||||
F: drivers/spi/spi-nuc900.c
|
||||
F: drivers/usb/host/ehci-w90x900.c
|
||||
F: drivers/video/nuc900fb.c
|
||||
|
||||
|
|
@ -1177,7 +1170,6 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
|||
S: Maintained
|
||||
F: arch/arm/mach-ux500/
|
||||
F: drivers/dma/ste_dma40*
|
||||
F: drivers/mfd/ab3550*
|
||||
F: drivers/mfd/abx500*
|
||||
F: drivers/mfd/ab8500*
|
||||
F: drivers/mfd/stmpe*
|
||||
|
|
@ -1357,7 +1349,7 @@ F: drivers/net/ethernet/cadence/
|
|||
ATMEL SPI DRIVER
|
||||
M: Nicolas Ferre <nicolas.ferre@atmel.com>
|
||||
S: Supported
|
||||
F: drivers/spi/atmel_spi.*
|
||||
F: drivers/spi/spi-atmel.*
|
||||
|
||||
ATMEL USBA UDC DRIVER
|
||||
M: Nicolas Ferre <nicolas.ferre@atmel.com>
|
||||
|
|
@ -1496,7 +1488,7 @@ M: Sonic Zhang <sonic.zhang@analog.com>
|
|||
L: uclinux-dist-devel@blackfin.uclinux.org
|
||||
W: http://blackfin.uclinux.org
|
||||
S: Supported
|
||||
F: drivers/tty/serial/bfin_5xx.c
|
||||
F: drivers/tty/serial/bfin_uart.c
|
||||
|
||||
BLACKFIN WATCHDOG DRIVER
|
||||
M: Mike Frysinger <vapier.adi@gmail.com>
|
||||
|
|
@ -1587,7 +1579,7 @@ M: Franky (Zhenhui) Lin <frankyl@broadcom.com>
|
|||
M: Kan Yan <kanyan@broadcom.com>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/staging/brcm80211/
|
||||
F: drivers/net/wireless/brcm80211/
|
||||
|
||||
BROADCOM BNX2FC 10 GIGABIT FCOE DRIVER
|
||||
M: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
|
||||
|
|
@ -1626,7 +1618,7 @@ BT8XXGPIO DRIVER
|
|||
M: Michael Buesch <m@bues.ch>
|
||||
W: http://bu3sch.de/btgpio.php
|
||||
S: Maintained
|
||||
F: drivers/gpio/bt8xxgpio.c
|
||||
F: drivers/gpio/gpio-bt8xx.c
|
||||
|
||||
BTRFS FILE SYSTEM
|
||||
M: Chris Mason <chris.mason@oracle.com>
|
||||
|
|
@ -1654,6 +1646,14 @@ T: git git://git.alsa-project.org/alsa-kernel.git
|
|||
S: Maintained
|
||||
F: sound/pci/oxygen/
|
||||
|
||||
C6X ARCHITECTURE
|
||||
M: Mark Salter <msalter@redhat.com>
|
||||
M: Aurelien Jacquiot <a-jacquiot@ti.com>
|
||||
L: linux-c6x-dev@linux-c6x.org
|
||||
W: http://www.linux-c6x.org/wiki/index.php/Main_Page
|
||||
S: Maintained
|
||||
F: arch/c6x/
|
||||
|
||||
CACHEFILES: FS-CACHE BACKEND FOR CACHING ON MOUNTED FILESYSTEMS
|
||||
M: David Howells <dhowells@redhat.com>
|
||||
L: linux-cachefs@redhat.com
|
||||
|
|
@ -1667,7 +1667,7 @@ L: linux-media@vger.kernel.org
|
|||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
S: Maintained
|
||||
F: Documentation/video4linux/cafe_ccic
|
||||
F: drivers/media/video/cafe_ccic*
|
||||
F: drivers/media/video/marvell-ccic/
|
||||
|
||||
CAIF NETWORK LAYER
|
||||
M: Sjur Braendeland <sjur.brandeland@stericsson.com>
|
||||
|
|
@ -1891,12 +1891,6 @@ L: platform-driver-x86@vger.kernel.org
|
|||
S: Maintained
|
||||
F: drivers/platform/x86/compal-laptop.c
|
||||
|
||||
COMPUTONE INTELLIPORT MULTIPORT CARD
|
||||
W: http://www.wittsend.com/computone.html
|
||||
S: Orphan
|
||||
F: Documentation/serial/computone.txt
|
||||
F: drivers/staging/tty/ip2/
|
||||
|
||||
CONEXANT ACCESSRUNNER USB DRIVER
|
||||
M: Simon Arlott <cxacru@fire.lp0.eu>
|
||||
L: accessrunner-general@lists.sourceforge.net
|
||||
|
|
@ -2111,7 +2105,7 @@ DAVICOM FAST ETHERNET (DMFE) NETWORK DRIVER
|
|||
L: netdev@vger.kernel.org
|
||||
S: Orphan
|
||||
F: Documentation/networking/dmfe.txt
|
||||
F: drivers/net/ethernet/tulip/dmfe.c
|
||||
F: drivers/net/ethernet/dec/tulip/dmfe.c
|
||||
|
||||
DC390/AM53C974 SCSI driver
|
||||
M: Kurt Garloff <garloff@suse.de>
|
||||
|
|
@ -2184,6 +2178,13 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
|
|||
S: Maintained
|
||||
F: drivers/usb/dwc3/
|
||||
|
||||
DEVICE FREQUENCY (DEVFREQ)
|
||||
M: MyungJoo Ham <myungjoo.ham@samsung.com>
|
||||
M: Kyungmin Park <kyungmin.park@samsung.com>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/devfreq/
|
||||
|
||||
DEVICE NUMBER REGISTRY
|
||||
M: Torben Mathiasen <device@lanana.org>
|
||||
W: http://lanana.org/docs/device-list/index.html
|
||||
|
|
@ -2200,15 +2201,6 @@ F: drivers/md/dm*
|
|||
F: include/linux/device-mapper.h
|
||||
F: include/linux/dm-*.h
|
||||
|
||||
DIGI INTL. EPCA DRIVER
|
||||
M: "Digi International, Inc" <Eng.Linux@digi.com>
|
||||
L: Eng.Linux@digi.com
|
||||
W: http://www.digi.com
|
||||
S: Orphan
|
||||
F: Documentation/serial/digiepca.txt
|
||||
F: drivers/staging/tty/epca*
|
||||
F: drivers/staging/tty/digi*
|
||||
|
||||
DIOLAN U2C-12 I2C DRIVER
|
||||
M: Guenter Roeck <guenter.roeck@ericsson.com>
|
||||
L: linux-i2c@vger.kernel.org
|
||||
|
|
@ -2912,6 +2904,7 @@ F: include/linux/gigaset_dev.h
|
|||
|
||||
GPIO SUBSYSTEM
|
||||
M: Grant Likely <grant.likely@secretlab.ca>
|
||||
M: Linus Walleij <linus.walleij@stericsson.com>
|
||||
S: Maintained
|
||||
T: git git://git.secretlab.ca/git/linux-2.6.git
|
||||
F: Documentation/gpio.txt
|
||||
|
|
@ -2929,7 +2922,7 @@ GRETH 10/100/1G Ethernet MAC device driver
|
|||
M: Kristoffer Glembo <kristoffer@gaisler.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/greth*
|
||||
F: drivers/net/ethernet/aeroflex/
|
||||
|
||||
GSPCA FINEPIX SUBDRIVER
|
||||
M: Frank Zago <frank@zago.net>
|
||||
|
|
@ -3181,6 +3174,16 @@ M: William Irwin <wli@holomorphy.com>
|
|||
S: Maintained
|
||||
F: fs/hugetlbfs/
|
||||
|
||||
Hyper-V CORE AND DRIVERS
|
||||
M: K. Y. Srinivasan <kys@microsoft.com>
|
||||
M: Haiyang Zhang <haiyangz@microsoft.com>
|
||||
L: devel@linuxdriverproject.org
|
||||
S: Maintained
|
||||
F: drivers/hv/
|
||||
F: drivers/hid/hid-hyperv.c
|
||||
F: drivers/net/hyperv/
|
||||
F: drivers/staging/hv/
|
||||
|
||||
I2C/SMBUS STUB DRIVER
|
||||
M: "Mark M. Hoffman" <mhoffman@lightlink.com>
|
||||
L: linux-i2c@vger.kernel.org
|
||||
|
|
@ -3576,8 +3579,7 @@ F: net/netfilter/ipvs/
|
|||
IPWIRELESS DRIVER
|
||||
M: Jiri Kosina <jkosina@suse.cz>
|
||||
M: David Sterba <dsterba@suse.cz>
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jikos/ipwireless_cs.git
|
||||
S: Odd Fixes
|
||||
F: drivers/tty/ipwireless/
|
||||
|
||||
IPX NETWORK LAYER
|
||||
|
|
@ -3870,8 +3872,7 @@ L: keyrings@linux-nfs.org
|
|||
S: Supported
|
||||
F: Documentation/security/keys-trusted-encrypted.txt
|
||||
F: include/keys/encrypted-type.h
|
||||
F: security/keys/encrypted.c
|
||||
F: security/keys/encrypted.h
|
||||
F: security/keys/encrypted-keys/
|
||||
|
||||
KGDB / KDB /debug_core
|
||||
M: Jason Wessel <jason.wessel@windriver.com>
|
||||
|
|
@ -5121,10 +5122,19 @@ L: linux-mtd@lists.infradead.org
|
|||
S: Maintained
|
||||
F: drivers/mtd/devices/phram.c
|
||||
|
||||
PICOXCELL SUPPORT
|
||||
M: Jamie Iles <jamie@jamieiles.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
T: git git://github.com/jamieiles/linux-2.6-ji.git
|
||||
S: Supported
|
||||
F: arch/arm/mach-picoxcell
|
||||
F: drivers/*/picoxcell*
|
||||
F: drivers/*/*/picoxcell*
|
||||
|
||||
PIN CONTROL SUBSYSTEM
|
||||
M: Linus Walleij <linus.walleij@linaro.org>
|
||||
S: Maintained
|
||||
F: drivers/pinmux/
|
||||
F: drivers/pinctrl/
|
||||
|
||||
PKTCDVD DRIVER
|
||||
M: Peter Osterlund <petero2@telia.com>
|
||||
|
|
@ -5307,35 +5317,27 @@ F: drivers/media/video/pvrusb2/
|
|||
PXA2xx/PXA3xx SUPPORT
|
||||
M: Eric Miao <eric.y.miao@gmail.com>
|
||||
M: Russell King <linux@arm.linux.org.uk>
|
||||
M: Haojian Zhuang <haojian.zhuang@marvell.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
T: git git://github.com/hzhuang1/linux.git
|
||||
T: git git://git.linaro.org/people/ycmiao/pxa-linux.git
|
||||
S: Maintained
|
||||
F: arch/arm/mach-pxa/
|
||||
F: drivers/pcmcia/pxa2xx*
|
||||
F: drivers/spi/pxa2xx*
|
||||
F: drivers/spi/spi-pxa2xx*
|
||||
F: drivers/usb/gadget/pxa2*
|
||||
F: include/sound/pxa2xx-lib.h
|
||||
F: sound/arm/pxa*
|
||||
F: sound/soc/pxa
|
||||
|
||||
PXA168 SUPPORT
|
||||
MMP SUPPORT
|
||||
M: Eric Miao <eric.y.miao@gmail.com>
|
||||
M: Jason Chagas <jason.chagas@marvell.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git
|
||||
S: Maintained
|
||||
|
||||
PXA910 SUPPORT
|
||||
M: Eric Miao <eric.y.miao@gmail.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git
|
||||
S: Maintained
|
||||
|
||||
MMP2 SUPPORT (aka ARMADA610)
|
||||
M: Haojian Zhuang <haojian.zhuang@marvell.com>
|
||||
M: Eric Miao <eric.y.miao@gmail.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git
|
||||
T: git git://github.com/hzhuang1/linux.git
|
||||
T: git git://git.linaro.org/people/ycmiao/pxa-linux.git
|
||||
S: Maintained
|
||||
F: arch/arm/mach-mmp/
|
||||
|
||||
PXA MMCI DRIVER
|
||||
S: Orphan
|
||||
|
|
@ -5545,11 +5547,6 @@ M: Maxim Levitsky <maximlevitsky@gmail.com>
|
|||
S: Maintained
|
||||
F: drivers/memstick/host/r592.*
|
||||
|
||||
RISCOM8 DRIVER
|
||||
S: Orphan
|
||||
F: Documentation/serial/riscom8.txt
|
||||
F: drivers/staging/tty/riscom8*
|
||||
|
||||
ROCKETPORT DRIVER
|
||||
P: Comtrol Corp.
|
||||
W: http://www.comtrol.com
|
||||
|
|
@ -5809,13 +5806,14 @@ L: linux-mmc@vger.kernel.org
|
|||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git
|
||||
S: Maintained
|
||||
F: drivers/mmc/host/sdhci.*
|
||||
F: drivers/mmc/host/sdhci-pltfm.[ch]
|
||||
|
||||
SECURE DIGITAL HOST CONTROLLER INTERFACE, OPEN FIRMWARE BINDINGS (SDHCI-OF)
|
||||
M: Anton Vorontsov <avorontsov@ru.mvista.com>
|
||||
L: linuxppc-dev@lists.ozlabs.org
|
||||
L: linux-mmc@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/mmc/host/sdhci-of.*
|
||||
F: drivers/mmc/host/sdhci-pltfm.[ch]
|
||||
|
||||
SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) SAMSUNG DRIVER
|
||||
M: Ben Dooks <ben-linux@fluff.org>
|
||||
|
|
@ -6194,9 +6192,7 @@ M: Viresh Kumar <viresh.kumar@st.com>
|
|||
W: http://www.st.com/spear
|
||||
S: Maintained
|
||||
F: arch/arm/mach-spear*/clock.c
|
||||
F: arch/arm/mach-spear*/include/mach/clkdev.h
|
||||
F: arch/arm/plat-spear/clock.c
|
||||
F: arch/arm/plat-spear/include/plat/clkdev.h
|
||||
F: arch/arm/plat-spear/include/plat/clock.h
|
||||
|
||||
SPEAR PAD MULTIPLEXING SUPPORT
|
||||
|
|
@ -6212,11 +6208,6 @@ F: arch/arm/mach-spear3xx/spear3*0_evb.c
|
|||
F: arch/arm/mach-spear6xx/spear600.c
|
||||
F: arch/arm/mach-spear6xx/spear600_evb.c
|
||||
|
||||
SPECIALIX IO8+ MULTIPORT SERIAL CARD DRIVER
|
||||
S: Orphan
|
||||
F: Documentation/serial/specialix.txt
|
||||
F: drivers/staging/tty/specialix*
|
||||
|
||||
SPI SUBSYSTEM
|
||||
M: Grant Likely <grant.likely@secretlab.ca>
|
||||
L: spi-devel-general@lists.sourceforge.net
|
||||
|
|
@ -6259,7 +6250,7 @@ F: arch/alpha/kernel/srm_env.c
|
|||
|
||||
STABLE BRANCH
|
||||
M: Greg Kroah-Hartman <greg@kroah.com>
|
||||
L: stable@kernel.org
|
||||
L: stable@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
STAGING SUBSYSTEM
|
||||
|
|
@ -6294,11 +6285,6 @@ M: Manu Abraham <abraham.manu@gmail.com>
|
|||
S: Odd Fixes
|
||||
F: drivers/staging/crystalhd/
|
||||
|
||||
STAGING - CYPRESS WESTBRIDGE SUPPORT
|
||||
M: David Cross <david.cross@cypress.com>
|
||||
S: Odd Fixes
|
||||
F: drivers/staging/westbridge/
|
||||
|
||||
STAGING - ECHO CANCELLER
|
||||
M: Steve Underwood <steveu@coppice.org>
|
||||
M: David Rowe <david@rowetel.com>
|
||||
|
|
@ -6320,12 +6306,6 @@ M: David Täht <d@teklibre.com>
|
|||
S: Odd Fixes
|
||||
F: drivers/staging/frontier/
|
||||
|
||||
STAGING - HYPER-V (MICROSOFT)
|
||||
M: Hank Janssen <hjanssen@microsoft.com>
|
||||
M: Haiyang Zhang <haiyangz@microsoft.com>
|
||||
S: Odd Fixes
|
||||
F: drivers/staging/hv/
|
||||
|
||||
STAGING - INDUSTRIAL IO
|
||||
M: Jonathan Cameron <jic23@cam.ac.uk>
|
||||
L: linux-iio@vger.kernel.org
|
||||
|
|
@ -6336,7 +6316,7 @@ STAGING - LIRC (LINUX INFRARED REMOTE CONTROL) DRIVERS
|
|||
M: Jarod Wilson <jarod@wilsonet.com>
|
||||
W: http://www.lirc.org/
|
||||
S: Odd Fixes
|
||||
F: drivers/staging/lirc/
|
||||
F: drivers/staging/media/lirc/
|
||||
|
||||
STAGING - NVIDIA COMPLIANT EMBEDDED CONTROLLER INTERFACE (nvec)
|
||||
M: Julian Andres Klode <jak@jak-linux.org>
|
||||
|
|
@ -6372,7 +6352,7 @@ F: drivers/staging/sm7xx/
|
|||
STAGING - SOFTLOGIC 6x10 MPEG CODEC
|
||||
M: Ben Collins <bcollins@bluecherry.net>
|
||||
S: Odd Fixes
|
||||
F: drivers/staging/solo6x10/
|
||||
F: drivers/staging/media/solo6x10/
|
||||
|
||||
STAGING - SPEAKUP CONSOLE SPEECH DRIVER
|
||||
M: William Hubbs <w.d.hubbs@gmail.com>
|
||||
|
|
@ -6410,7 +6390,7 @@ S: Odd Fixes
|
|||
F: drivers/staging/winbond/
|
||||
|
||||
STAGING - XGI Z7,Z9,Z11 PCI DISPLAY DRIVER
|
||||
M: Arnaud Patard <apatard@mandriva.com>
|
||||
M: Arnaud Patard <arnaud.patard@rtp-net.org>
|
||||
S: Odd Fixes
|
||||
F: drivers/staging/xgifb/
|
||||
|
||||
|
|
@ -6675,7 +6655,7 @@ TULIP NETWORK DRIVERS
|
|||
M: Grant Grundler <grundler@parisc-linux.org>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/ethernet/tulip/
|
||||
F: drivers/net/ethernet/dec/tulip/
|
||||
|
||||
TUN/TAP driver
|
||||
M: Maxim Krasnyansky <maxk@qualcomm.com>
|
||||
|
|
|
|||
14
arch/Kconfig
14
arch/Kconfig
|
|
@ -185,4 +185,18 @@ config HAVE_RCU_TABLE_FREE
|
|||
config ARCH_HAVE_NMI_SAFE_CMPXCHG
|
||||
bool
|
||||
|
||||
config HAVE_ALIGNED_STRUCT_PAGE
|
||||
bool
|
||||
help
|
||||
This makes sure that struct pages are double word aligned and that
|
||||
e.g. the SLUB allocator can perform double word atomic operations
|
||||
on a struct page for better performance. However selecting this
|
||||
might increase the size of a struct page by a word.
|
||||
|
||||
config HAVE_CMPXCHG_LOCAL
|
||||
bool
|
||||
|
||||
config HAVE_CMPXCHG_DOUBLE
|
||||
bool
|
||||
|
||||
source "kernel/gcov/Kconfig"
|
||||
|
|
|
|||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче