AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-11-24 09:00:52 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge branches 'for-4.0/upstream-fixes', 'for-4.1/genius', 'for-4.1/huion-uclogic-merge', 'for-4.1/i2c-hid', 'for-4.1/kconfig-drop-expert-dependency', 'for-4.1/logitech', 'for-4.1/multitouch', 'for-4.1/rmi', 'for-4.1/sony', 'for-4.1/upstream' and 'for-4.1/wacom' into for-linus

Browse Source
This commit is contained in:
Jiri Kosina 2015-04-13 23:41:15 +02:00
commit 05f6d02521
7668 changed files with 355416 additions and 185556 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
.gitignore vendored
View File

@ -43,6 +43,7 @@ Module.symvers
/TAGS
/linux
/vmlinux
/vmlinux-gdb.py
/vmlinuz
/System.map
/Module.markers
@ -52,6 +53,11 @@ Module.symvers
#
/debian/
#
# tar directory (make tar*-pkg)
#
/tar-install/
#
# git files that we don't want to ignore even it they are dot-files
#

28
Documentation/00-INDEX
View File

@ -29,8 +29,6 @@ DMA-ISA-LPC.txt
- How to do DMA with ISA (and LPC) devices.
DMA-attributes.txt
- listing of the various possible attributes a DMA region can have
dmatest.txt
- how to compile, configure and use the dmatest system.
DocBook/
- directory with DocBook templates etc. for kernel documentation.
EDID/
@ -163,8 +161,6 @@ digsig.txt
-info on the Digital Signature Verification API
dma-buf-sharing.txt
- the DMA Buffer Sharing API Guide
dmaengine.txt
-the DMA Engine API Guide
dontdiff
- file containing a list of files that should never be diff'ed.
driver-model/
@ -209,6 +205,8 @@ hid/
- directory with information on human interface devices
highuid.txt
- notes on the change from 16 bit to 32 bit user/group IDs.
hsi.txt
- HSI subsystem overview.
hwspinlock.txt
- hardware spinlock provides hardware assistance for synchronization
timers/
@ -277,6 +275,8 @@ kprobes.txt
- documents the kernel probes debugging feature.
kref.txt
- docs on adding reference counters (krefs) to kernel objects.
kselftest.txt
- small unittests for (some) individual codepaths in the kernel.
laptops/
- directory with laptop related info and laptop driver documentation.
ldm.txt
@ -285,22 +285,22 @@ leds/
- directory with info about LED handling under Linux.
local_ops.txt
- semantics and behavior of local atomic operations.
lockdep-design.txt
- documentation on the runtime locking correctness validator.
locking/
- directory with info about kernel locking primitives
lockstat.txt
- info on collecting statistics on locks (and contention).
lockup-watchdogs.txt
- info on soft and hard lockup detectors (aka nmi_watchdog).
logo.gif
- full colour GIF image of Linux logo (penguin - Tux).
logo.txt
- info on creator of above logo & site to get additional images from.
lzo.txt
- kernel LZO decompressor input formats
m68k/
- directory with info about Linux on Motorola 68k architecture.
magic-number.txt
- list of magic numbers used to mark/protect kernel data structures.
mailbox.txt
- How to write drivers for the common mailbox framework (IPC).
md.txt
- info on boot arguments for the multiple devices driver.
media-framework.txt
@ -327,8 +327,6 @@ mtd/
- directory with info about memory technology devices (flash)
mono.txt
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
mutex-design.txt
- info on the generic mutex subsystem.
namespaces/
- directory with various information about namespaces
netlabel/
@ -395,10 +393,6 @@ robust-futexes.txt
- a description of what robust futexes are.
rpmsg.txt
- info on the Remote Processor Messaging (rpmsg) Framework
rt-mutex-design.txt
- description of the RealTime mutex implementation design.
rt-mutex.txt
- desc. of RT-mutex subsystem with PI (Priority Inheritance) support.
rtc.txt
- notes on how to use the Real Time Clock (aka CMOS clock) driver.
s390/
@ -425,8 +419,6 @@ sparse.txt
- info on how to obtain and use the sparse tool for typechecking.
spi/
- overview of Linux kernel Serial Peripheral Interface (SPI) support.
spinlocks.txt
- info on using spinlocks to provide exclusive access in kernel.
stable_api_nonsense.txt
- info on why the kernel does not have a stable in-kernel api or abi.
stable_kernel_rules.txt
@ -483,10 +475,10 @@ wimax/
- directory with info about Intel Wireless Wimax Connections
workqueue.txt
- information on the Concurrency Managed Workqueue implementation
ww-mutex-design.txt
- Intro to Mutex wait/would deadlock handling.s
x86/x86_64/
- directory with info on Linux support for AMD x86-64 (Hammer) machines.
xillybus.txt
- Overview and basic ui of xillybus driver
xtensa/
- directory with documents relating to arch/xtensa port/implementation
xz.txt

22
Documentation/ABI/stable/sysfs-class-tpm
View File

@ -1,4 +1,4 @@
What: /sys/class/misc/tpmX/device/
What: /sys/class/tpm/tpmX/device/
Date: April 2005
KernelVersion: 2.6.12
Contact: tpmdd-devel@lists.sf.net
@ -6,7 +6,7 @@ Description: The device/ directory under a specific TPM instance exposes
the properties of that TPM chip
What: /sys/class/misc/tpmX/device/active
What: /sys/class/tpm/tpmX/device/active
Date: April 2006
KernelVersion: 2.6.17
Contact: tpmdd-devel@lists.sf.net
@ -18,7 +18,7 @@ Description: The "active" property prints a '1' if the TPM chip is accepting
section 17 for more information on which commands are
available.
What: /sys/class/misc/tpmX/device/cancel
What: /sys/class/tpm/tpmX/device/cancel
Date: June 2005
KernelVersion: 2.6.13
Contact: tpmdd-devel@lists.sf.net
@ -26,7 +26,7 @@ Description: The "cancel" property allows you to cancel the currently
pending TPM command. Writing any value to cancel will call the
TPM vendor specific cancel operation.
What: /sys/class/misc/tpmX/device/caps
What: /sys/class/tpm/tpmX/device/caps
Date: April 2005
KernelVersion: 2.6.12
Contact: tpmdd-devel@lists.sf.net
@ -43,7 +43,7 @@ Description: The "caps" property contains TPM manufacturer and version info.
the chip supports. Firmware version is that of the chip and
is manufacturer specific.
What: /sys/class/misc/tpmX/device/durations
What: /sys/class/tpm/tpmX/device/durations
Date: March 2011
KernelVersion: 3.1
Contact: tpmdd-devel@lists.sf.net
@ -66,7 +66,7 @@ Description: The "durations" property shows the 3 vendor-specific values
scaled to be displayed in usecs. In this case "[adjusted]"
will be displayed in place of "[original]".
What: /sys/class/misc/tpmX/device/enabled
What: /sys/class/tpm/tpmX/device/enabled
Date: April 2006
KernelVersion: 2.6.17
Contact: tpmdd-devel@lists.sf.net
@ -75,7 +75,7 @@ Description: The "enabled" property prints a '1' if the TPM chip is enabled,
may be visible but produce a '0' after some operation that
disables the TPM.
What: /sys/class/misc/tpmX/device/owned
What: /sys/class/tpm/tpmX/device/owned
Date: April 2006
KernelVersion: 2.6.17
Contact: tpmdd-devel@lists.sf.net
@ -83,7 +83,7 @@ Description: The "owned" property produces a '1' if the TPM_TakeOwnership
ordinal has been executed successfully in the chip. A '0'
indicates that ownership hasn't been taken.
What: /sys/class/misc/tpmX/device/pcrs
What: /sys/class/tpm/tpmX/device/pcrs
Date: April 2005
KernelVersion: 2.6.12
Contact: tpmdd-devel@lists.sf.net
@ -106,7 +106,7 @@ Description: The "pcrs" property will dump the current value of all Platform
1.2 chips, PCRs represent SHA-1 hashes, which are 20 bytes
long. Use the "caps" property to determine TPM version.
What: /sys/class/misc/tpmX/device/pubek
What: /sys/class/tpm/tpmX/device/pubek
Date: April 2005
KernelVersion: 2.6.12
Contact: tpmdd-devel@lists.sf.net
@ -158,7 +158,7 @@ Description: The "pubek" property will return the TPM's public endorsement
Modulus Length: 256 (bytes)
Modulus: The 256 byte Endorsement Key modulus
What: /sys/class/misc/tpmX/device/temp_deactivated
What: /sys/class/tpm/tpmX/device/temp_deactivated
Date: April 2006
KernelVersion: 2.6.17
Contact: tpmdd-devel@lists.sf.net
@ -167,7 +167,7 @@ Description: The "temp_deactivated" property returns a '1' if the chip has
cycle. Whether a warm boot (reboot) will clear a TPM chip
from a temp_deactivated state is platform specific.
What: /sys/class/misc/tpmX/device/timeouts
What: /sys/class/tpm/tpmX/device/timeouts
Date: March 2011
KernelVersion: 3.1
Contact: tpmdd-devel@lists.sf.net

265
Documentation/ABI/testing/configfs-usb-gadget-uvc Normal file
View File

@ -0,0 +1,265 @@
What: /config/usb-gadget/gadget/functions/uvc.name
Date: Dec 2014
KernelVersion: 3.20
Description: UVC function directory
streaming_maxburst - 0..15 (ss only)
streaming_maxpacket - 1..1023 (fs), 1..3072 (hs/ss)
streaming_interval - 1..16
What: /config/usb-gadget/gadget/functions/uvc.name/control
Date: Dec 2014
KernelVersion: 3.20
Description: Control descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/class
Date: Dec 2014
KernelVersion: 3.20
Description: Class descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/class/ss
Date: Dec 2014
KernelVersion: 3.20
Description: Super speed control class descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/class/fs
Date: Dec 2014
KernelVersion: 3.20
Description: Full speed control class descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal
Date: Dec 2014
KernelVersion: 3.20
Description: Terminal descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/output
Date: Dec 2014
KernelVersion: 3.20
Description: Output terminal descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/output/default
Date: Dec 2014
KernelVersion: 3.20
Description: Default output terminal descriptors
All attributes read only:
iTerminal - index of string descriptor
bSourceID - id of the terminal to which this terminal
is connected
bAssocTerminal - id of the input terminal to which this output
terminal is associated
wTerminalType - terminal type
bTerminalID - a non-zero id of this terminal
What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/camera
Date: Dec 2014
KernelVersion: 3.20
Description: Camera terminal descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/camera/default
Date: Dec 2014
KernelVersion: 3.20
Description: Default camera terminal descriptors
All attributes read only:
bmControls - bitmap specifying which controls are
supported for the video stream
wOcularFocalLength - the value of Locular
wObjectiveFocalLengthMax- the value of Lmin
wObjectiveFocalLengthMin- the value of Lmax
iTerminal - index of string descriptor
bAssocTerminal - id of the output terminal to which
this terminal is connected
wTerminalType - terminal type
bTerminalID - a non-zero id of this terminal
What: /config/usb-gadget/gadget/functions/uvc.name/control/processing
Date: Dec 2014
KernelVersion: 3.20
Description: Processing unit descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/processing/default
Date: Dec 2014
KernelVersion: 3.20
Description: Default processing unit descriptors
All attributes read only:
iProcessing - index of string descriptor
bmControls - bitmap specifying which controls are
supported for the video stream
wMaxMultiplier - maximum digital magnification x100
bSourceID - id of the terminal to which this unit is
connected
bUnitID - a non-zero id of this unit
What: /config/usb-gadget/gadget/functions/uvc.name/control/header
Date: Dec 2014
KernelVersion: 3.20
Description: Control header descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/header/name
Date: Dec 2014
KernelVersion: 3.20
Description: Specific control header descriptors
dwClockFrequency
bcdUVC
What: /config/usb-gadget/gadget/functions/uvc.name/streaming
Date: Dec 2014
KernelVersion: 3.20
Description: Streaming descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/class
Date: Dec 2014
KernelVersion: 3.20
Description: Streaming class descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/class/ss
Date: Dec 2014
KernelVersion: 3.20
Description: Super speed streaming class descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/class/hs
Date: Dec 2014
KernelVersion: 3.20
Description: High speed streaming class descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/class/fs
Date: Dec 2014
KernelVersion: 3.20
Description: Full speed streaming class descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/color_matching
Date: Dec 2014
KernelVersion: 3.20
Description: Color matching descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/color_matching/default
Date: Dec 2014
KernelVersion: 3.20
Description: Default color matching descriptors
All attributes read only:
bMatrixCoefficients - matrix used to compute luma and
chroma values from the color primaries
bTransferCharacteristics- optoelectronic transfer
characteristic of the source picutre,
also called the gamma function
bColorPrimaries - color primaries and the reference
white
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/mjpeg
Date: Dec 2014
KernelVersion: 3.20
Description: MJPEG format descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/mjpeg/name
Date: Dec 2014
KernelVersion: 3.20
Description: Specific MJPEG format descriptors
All attributes read only,
except bmaControls and bDefaultFrameIndex:
bmaControls - this format's data for bmaControls in
the streaming header
bmInterfaceFlags - specifies interlace information,
read-only
bAspectRatioY - the X dimension of the picture aspect
ratio, read-only
bAspectRatioX - the Y dimension of the picture aspect
ratio, read-only
bmFlags - characteristics of this format,
read-only
bDefaultFrameIndex - optimum frame index for this stream
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/mjpeg/name/name
Date: Dec 2014
KernelVersion: 3.20
Description: Specific MJPEG frame descriptors
dwFrameInterval - indicates how frame interval can be
programmed; a number of values
separated by newline can be specified
dwDefaultFrameInterval - the frame interval the device would
like to use as default
dwMaxVideoFrameBufferSize- the maximum number of bytes the
compressor will produce for a video
frame or still image
dwMaxBitRate - the maximum bit rate at the shortest
frame interval in bps
dwMinBitRate - the minimum bit rate at the longest
frame interval in bps
wHeight - height of decoded bitmap frame in px
wWidth - width of decoded bitmam frame in px
bmCapabilities - still image support, fixed frame-rate
support
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/uncompressed
Date: Dec 2014
KernelVersion: 3.20
Description: Uncompressed format descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/uncompressed/name
Date: Dec 2014
KernelVersion: 3.20
Description: Specific uncompressed format descriptors
bmaControls - this format's data for bmaControls in
the streaming header
bmInterfaceFlags - specifies interlace information,
read-only
bAspectRatioY - the X dimension of the picture aspect
ratio, read-only
bAspectRatioX - the Y dimension of the picture aspect
ratio, read-only
bDefaultFrameIndex - optimum frame index for this stream
bBitsPerPixel - number of bits per pixel used to
specify color in the decoded video
frame
guidFormat - globally unique id used to identify
stream-encoding format
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/uncompressed/name/name
Date: Dec 2014
KernelVersion: 3.20
Description: Specific uncompressed frame descriptors
dwFrameInterval - indicates how frame interval can be
programmed; a number of values
separated by newline can be specified
dwDefaultFrameInterval - the frame interval the device would
like to use as default
dwMaxVideoFrameBufferSize- the maximum number of bytes the
compressor will produce for a video
frame or still image
dwMaxBitRate - the maximum bit rate at the shortest
frame interval in bps
dwMinBitRate - the minimum bit rate at the longest
frame interval in bps
wHeight - height of decoded bitmap frame in px
wWidth - width of decoded bitmam frame in px
bmCapabilities - still image support, fixed frame-rate
support
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/header
Date: Dec 2014
KernelVersion: 3.20
Description: Streaming header descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/header/name
Date: Dec 2014
KernelVersion: 3.20
Description: Specific streaming header descriptors
All attributes read only:
bTriggerUsage - how the host software will respond to
a hardware trigger interrupt event
bTriggerSupport - flag specifying if hardware
triggering is supported
bStillCaptureMethod - method of still image caputre
supported
bTerminalLink - id of the output terminal to which
the video endpoint of this interface
is connected
bmInfo - capabilities of this video streaming
interface

20
Documentation/ABI/testing/sysfs-bus-amba Normal file
View File

@ -0,0 +1,20 @@
What: /sys/bus/amba/devices/.../driver_override
Date: September 2014
Contact: Antonios Motakis <a.motakis@virtualopensystems.com>
Description:
This file allows the driver for a device to be specified which
will override standard OF, ACPI, ID table, and name matching.
When specified, only a driver with a name matching the value
written to driver_override will have an opportunity to bind to
the device. The override is specified by writing a string to the
driver_override file (echo vfio-amba > driver_override) and may
be cleared with an empty string (echo > driver_override).
This returns the device to standard matching rules binding.
Writing to driver_override does not automatically unbind the
device from its current driver or make any attempt to
automatically load the specified driver. If no driver with a
matching name is currently loaded in the kernel, the device will
not bind to any driver. This also allows devices to opt-out of
driver binding using a driver_override name such as "none".
Only a single driver may be specified in the override, there is
no support for parsing delimiters.

22
Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
View File

@ -21,3 +21,25 @@ Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
Exposes the "version" field of the 24x7 catalog. This is also
extractable from the provided binary "catalog" sysfs entry.
What: /sys/bus/event_source/devices/hv_24x7/event_descs/<event-name>
Date: February 2014
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
Provides the description of a particular event as provided by
the firmware. If firmware does not provide a description, no
file will be created.
Note that the event-name lacks the domain suffix appended for
events in the events/ dir.
What: /sys/bus/event_source/devices/hv_24x7/event_long_descs/<event-name>
Date: February 2014
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
Provides the "long" description of a particular event as
provided by the firmware. If firmware does not provide a
description, no file will be created.
Note that the event-name lacks the domain suffix appended for
events in the events/ dir.

200
Documentation/ABI/testing/sysfs-bus-iio
View File

@ -92,6 +92,18 @@ Description:
is required is a consistent labeling. Units after application
of scale and offset are millivolts.
What: /sys/bus/iio/devices/iio:deviceX/in_currentY_raw
What: /sys/bus/iio/devices/iio:deviceX/in_currentY_supply_raw
KernelVersion: 3.17
Contact: linux-iio@vger.kernel.org
Description:
Raw (unscaled no bias removal etc.) current measurement from
channel Y. In special cases where the channel does not
correspond to externally available input one of the named
versions may be used. The number must always be specified and
unique to allow association with event codes. Units after
application of scale and offset are milliamps.
What: /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_raw
KernelVersion: 3.2
Contact: linux-iio@vger.kernel.org
@ -234,6 +246,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset
What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_offset
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_voltage_offset
What: /sys/bus/iio/devices/iio:deviceX/in_currentY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_current_offset
What: /sys/bus/iio/devices/iio:deviceX/in_tempY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_temp_offset
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_offset
@ -262,9 +276,14 @@ What: /sys/bus/iio/devices/iio:deviceX/in_voltage_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltage-voltage_scale
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_scale
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_currentY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_currentY_supply_scale
What: /sys/bus/iio/devices/iio:deviceX/in_current_scale
What: /sys/bus/iio/devices/iio:deviceX/in_accel_scale
What: /sys/bus/iio/devices/iio:deviceX/in_accel_peak_scale
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_scale
What: /sys/bus/iio/devices/iio:deviceX/in_energy_scale
What: /sys/bus/iio/devices/iio:deviceX/in_distance_scale
What: /sys/bus/iio/devices/iio:deviceX/in_magn_scale
What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_scale
What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_scale
@ -276,6 +295,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_tilt_comp_scale
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale
What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_scale
What: /sys/bus/iio/devices/iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_scale
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@ -323,6 +343,44 @@ Description:
production inaccuracies). If shared across all channels,
<type>_calibscale is used.
What: /sys/bus/iio/devices/iio:deviceX/in_activity_calibgender
What: /sys/bus/iio/devices/iio:deviceX/in_energy_calibgender
What: /sys/bus/iio/devices/iio:deviceX/in_distance_calibgender
What: /sys/bus/iio/devices/iio:deviceX/in_velocity_calibgender
KernelVersion: 3.20
Contact: linux-iio@vger.kernel.org
Description:
Gender of the user (e.g.: male, female) used by some pedometers
to compute the stride length, distance, speed and activity
type.
What: /sys/bus/iio/devices/iio:deviceX/in_activity_calibgender_available
What: /sys/bus/iio/devices/iio:deviceX/in_energy_calibgender_available
What: /sys/bus/iio/devices/iio:deviceX/in_distance_calibgender_available
What: /sys/bus/iio/devices/iio:deviceX/in_velocity_calibgender_available
KernelVersion: 3.20
Contact: linux-iio@vger.kernel.org
Description:
Lists all available gender values (e.g.: male, female).
What: /sys/bus/iio/devices/iio:deviceX/in_activity_calibheight
What: /sys/bus/iio/devices/iio:deviceX/in_energy_calibheight
What: /sys/bus/iio/devices/iio:deviceX/in_distance_calibheight
What: /sys/bus/iio/devices/iio:deviceX/in_velocity_calibheight
KernelVersion: 3.19
Contact: linux-iio@vger.kernel.org
Description:
Height of the user (in meters) used by some pedometers
to compute the stride length, distance, speed and activity
type.
What: /sys/bus/iio/devices/iio:deviceX/in_energy_calibweight
KernelVersion: 3.20
Contact: linux-iio@vger.kernel.org
Description:
Weight of the user (in kg). It is needed by some pedometers
to compute the calories burnt by the user.
What: /sys/bus/iio/devices/iio:deviceX/in_accel_scale_available
What: /sys/.../iio:deviceX/in_voltageX_scale_available
What: /sys/.../iio:deviceX/in_voltage-voltage_scale_available
@ -783,6 +841,14 @@ What: /sys/.../events/in_tempY_roc_falling_period
What: /sys/.../events/in_accel_x&y&z_mag_falling_period
What: /sys/.../events/in_intensity0_thresh_period
What: /sys/.../events/in_proximity0_thresh_period
What: /sys/.../events/in_activity_still_thresh_rising_period
What: /sys/.../events/in_activity_still_thresh_falling_period
What: /sys/.../events/in_activity_walking_thresh_rising_period
What: /sys/.../events/in_activity_walking_thresh_falling_period
What: /sys/.../events/in_activity_jogging_thresh_rising_period
What: /sys/.../events/in_activity_jogging_thresh_falling_period
What: /sys/.../events/in_activity_running_thresh_rising_period
What: /sys/.../events/in_activity_running_thresh_falling_period
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
@ -790,6 +856,40 @@ Description:
met before an event is generated. If direction is not
specified then this period applies to both directions.
What: /sys/.../events/in_activity_still_thresh_rising_en
What: /sys/.../events/in_activity_still_thresh_falling_en
What: /sys/.../events/in_activity_walking_thresh_rising_en
What: /sys/.../events/in_activity_walking_thresh_falling_en
What: /sys/.../events/in_activity_jogging_thresh_rising_en
What: /sys/.../events/in_activity_jogging_thresh_falling_en
What: /sys/.../events/in_activity_running_thresh_rising_en
What: /sys/.../events/in_activity_running_thresh_falling_en
KernelVersion: 3.19
Contact: linux-iio@vger.kernel.org
Description:
Enables or disables activitity events. Depending on direction
an event is generated when sensor ENTERS or LEAVES a given state.
What: /sys/.../events/in_activity_still_thresh_rising_value
What: /sys/.../events/in_activity_still_thresh_falling_value
What: /sys/.../events/in_activity_walking_thresh_rising_value
What: /sys/.../events/in_activity_walking_thresh_falling_value
What: /sys/.../events/in_activity_jogging_thresh_rising_value
What: /sys/.../events/in_activity_jogging_thresh_falling_value
What: /sys/.../events/in_activity_running_thresh_rising_value
What: /sys/.../events/in_activity_running_thresh_falling_value
KernelVersion: 3.19
Contact: linux-iio@vger.kernel.org
Description:
Confidence value (in units as percentage) to be used
for deciding when an event should be generated. E.g for
running: If the confidence value reported by the sensor
is greater than in_activity_running_thresh_rising_value
then the sensor ENTERS running state. Conversely, if the
confidence value reported by the sensor is lower than
in_activity_running_thresh_falling_value then the sensor
is LEAVING running state.
What: /sys/.../iio:deviceX/events/in_accel_mag_en
What: /sys/.../iio:deviceX/events/in_accel_mag_rising_en
What: /sys/.../iio:deviceX/events/in_accel_mag_falling_en
@ -822,6 +922,25 @@ Description:
number or direction is not specified, applies to all channels of
this type.
What: /sys/.../events/in_steps_change_en
KernelVersion: 3.20
Contact: linux-iio@vger.kernel.org
Description:
Event generated when channel passes a threshold on the absolute
change in value. E.g. for steps: a step change event is
generated each time the user takes N steps, where N is set using
in_steps_change_value.
What: /sys/.../events/in_steps_change_value
KernelVersion: 3.20
Contact: linux-iio@vger.kernel.org
Description:
Specifies the value of change threshold that the
device is comparing against for the events enabled by
<type>[Y][_name]_roc[_rising|falling|]_en. E.g. for steps:
if set to 3, a step change event will be generated every 3
steps.
What: /sys/bus/iio/devices/iio:deviceX/trigger/current_trigger
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
@ -956,6 +1075,16 @@ Description:
and the relevant _type attributes to establish the data storage
format.
What: /sys/.../iio:deviceX/in_activity_still_input
What: /sys/.../iio:deviceX/in_activity_walking_input
What: /sys/.../iio:deviceX/in_activity_jogging_input
What: /sys/.../iio:deviceX/in_activity_running_input
KernelVersion: 3.19
Contact: linux-iio@vger.kernel.org
Description:
This attribute is used to read the confidence for an activity
expressed in units as percentage.
What: /sys/.../iio:deviceX/in_anglvel_z_quadrature_correction_raw
KernelVersion: 2.6.38
Contact: linux-iio@vger.kernel.org
@ -973,6 +1102,24 @@ Description:
For a list of available output power modes read
in_accel_power_mode_available.
What: /sys/.../iio:deviceX/in_energy_input
What: /sys/.../iio:deviceX/in_energy_raw
KernelVersion: 3.20
Contact: linux-iio@vger.kernel.org
Description:
This attribute is used to read the energy value reported by the
device (e.g.: human activity sensors report energy burnt by the
user). Units after application of scale are Joules.
What: /sys/.../iio:deviceX/in_distance_input
What: /sys/.../iio:deviceX/in_distance_raw
KernelVersion: 3.20
Contact: linux-iio@vger.kernel.org
Description:
This attribute is used to read the distance covered by the user
since the last reboot while activated. Units after application
of scale are meters.
What: /sys/bus/iio/devices/iio:deviceX/store_eeprom
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
@ -992,7 +1139,9 @@ Description:
reflectivity of infrared or ultrasound emitted.
Often these sensors are unit less and as such conversion
to SI units is not possible. Where it is, the units should
be meters.
be meters. If such a conversion is not possible, the reported
values should behave in the same way as a distance, i.e. lower
values indicate something is closer to the sensor.
What: /sys/.../iio:deviceX/in_illuminanceY_input
What: /sys/.../iio:deviceX/in_illuminanceY_raw
@ -1024,6 +1173,12 @@ Description:
This attribute is used to get/set the integration time in
seconds.
What: /sys/.../iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_integration_time
KernelVersion: 3.20
Contact: linux-iio@vger.kernel.org
Description:
Number of seconds in which to compute speed.
What: /sys/bus/iio/devices/iio:deviceX/in_rot_quaternion_raw
KernelVersion: 3.15
Contact: linux-iio@vger.kernel.org
@ -1051,3 +1206,46 @@ Description:
after application of scale and offset. If no offset or scale is
present, output should be considered as processed with the
unit in milliamps.
What: /sys/.../iio:deviceX/in_energy_en
What: /sys/.../iio:deviceX/in_distance_en
What: /sys/.../iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_en
What: /sys/.../iio:deviceX/in_steps_en
KernelVersion: 3.19
Contact: linux-iio@vger.kernel.org
Description:
Activates a device feature that runs in firmware/hardware.
E.g. for steps: the pedometer saves power while not used;
when activated, it will count the steps taken by the user in
firmware and export them through in_steps_input.
What: /sys/.../iio:deviceX/in_steps_input
KernelVersion: 3.19
Contact: linux-iio@vger.kernel.org
Description:
This attribute is used to read the number of steps taken by the user
since the last reboot while activated.
What: /sys/.../iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_input
What: /sys/.../iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_raw
KernelVersion: 3.19
Contact: linux-iio@vger.kernel.org
Description:
This attribute is used to read the current speed value of the
user (which is the norm or magnitude of the velocity vector).
Units after application of scale are m/s.
What: /sys/.../iio:deviceX/in_steps_debounce_count
KernelVersion: 3.20
Contact: linux-iio@vger.kernel.org
Description:
Specifies the number of steps that must occur within
in_steps_filter_debounce_time for the pedometer to decide the
consumer is making steps.
What: /sys/.../iio:deviceX/in_steps_debounce_time
KernelVersion: 3.20
Contact: linux-iio@vger.kernel.org
Description:
Specifies number of seconds in which we compute the steps
that occur in order to decide if the consumer is making steps.

67
Documentation/ABI/testing/sysfs-class-cxl
View File

@ -1,3 +1,9 @@
Note: Attributes that are shared between devices are stored in the directory
pointed to by the symlink device/.
Example: The real path of the attribute /sys/class/cxl/afu0.0s/irqs_max is
/sys/class/cxl/afu0.0s/device/irqs_max, i.e. /sys/class/cxl/afu0.0/irqs_max.
Slave contexts (eg. /sys/class/cxl/afu0.0s):
What: /sys/class/cxl/<afu>/irqs_max
@ -67,7 +73,7 @@ Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the current version of the kernel/user API.
What: /sys/class/cxl/<afu>/api_version_com
What: /sys/class/cxl/<afu>/api_version_compatible
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
@ -75,6 +81,42 @@ Description: read only
this this kernel supports.
AFU configuration records (eg. /sys/class/cxl/afu0.0/cr0):
An AFU may optionally export one or more PCIe like configuration records, known
as AFU configuration records, which will show up here (if present).
What: /sys/class/cxl/<afu>/cr<config num>/vendor
Date: February 2015
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Hexadecimal value of the vendor ID found in this AFU
configuration record.
What: /sys/class/cxl/<afu>/cr<config num>/device
Date: February 2015
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Hexadecimal value of the device ID found in this AFU
configuration record.
What: /sys/class/cxl/<afu>/cr<config num>/vendor
Date: February 2015
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Hexadecimal value of the class code found in this AFU
configuration record.
What: /sys/class/cxl/<afu>/cr<config num>/config
Date: February 2015
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
This binary file provides raw access to the AFU configuration
record. The format is expected to match the either the standard
or extended configuration space defined by the PCIe
specification.
Master contexts (eg. /sys/class/cxl/afu0.0m)
@ -106,7 +148,7 @@ Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Identifies the CAIA Version the card implements.
What: /sys/class/cxl/<card>/psl_version
What: /sys/class/cxl/<card>/psl_revision
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
@ -127,3 +169,24 @@ Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Will return "user" or "factory" depending on the image loaded
onto the card.
What: /sys/class/cxl/<card>/load_image_on_perst
Date: December 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
Valid entries are "none", "user", and "factory".
"none" means PERST will not cause image to be loaded to the
card. A power cycle is required to load the image.
"none" could be useful for debugging because the trace arrays
are preserved.
"user" and "factory" means PERST will cause either the user or
user or factory image to be loaded.
Default is to reload on PERST whichever image the card has
loaded.
What: /sys/class/cxl/<card>/reset
Date: October 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: write only
Writing 1 will issue a PERST to card which may cause the card
to reload the FPGA depending on load_image_on_perst.

42
Documentation/ABI/testing/sysfs-class-power
View File

@ -32,3 +32,45 @@ Description:
Valid values:
- 5, 6 or 7 (hours),
- 0: disabled.
What: /sys/class/power_supply/max77693-charger/device/fast_charge_timer
Date: January 2015
KernelVersion: 3.19.0
Contact: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Description:
This entry shows and sets the maximum time the max77693
charger operates in fast-charge mode. When the timer expires
the device will terminate fast-charge mode (charging current
will drop to 0 A) and will trigger interrupt.
Valid values:
- 4 - 16 (hours), step by 2 (rounded down)
- 0: disabled.
What: /sys/class/power_supply/max77693-charger/device/top_off_threshold_current
Date: January 2015
KernelVersion: 3.19.0
Contact: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Description:
This entry shows and sets the charging current threshold for
entering top-off charging mode. When charging current in fast
charge mode drops below this value, the charger will trigger
interrupt and start top-off charging mode.
Valid values:
- 100000 - 200000 (microamps), step by 25000 (rounded down)
- 200000 - 350000 (microamps), step by 50000 (rounded down)
- 0: disabled.
What: /sys/class/power_supply/max77693-charger/device/top_off_timer
Date: January 2015
KernelVersion: 3.19.0
Contact: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Description:
This entry shows and sets the maximum time the max77693
charger operates in top-off charge mode. When the timer expires
the device will terminate top-off charge mode (charging current
will drop to 0 A) and will trigger interrupt.
Valid values:
- 0 - 70 (minutes), step by 10 (rounded down)

10
Documentation/ABI/testing/sysfs-driver-hid
View File

@ -8,3 +8,13 @@ Description: When read, this file returns the device's raw binary HID
report descriptor.
This file cannot be written.
Users: HIDAPI library (http://www.signal11.us/oss/hidapi)
What: For USB devices : /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/country
For BT devices : /sys/class/bluetooth/hci<addr>/<hid-bus>:<vendor-id>:<product-id>.<num>/country
Symlink : /sys/class/hidraw/hidraw<num>/device/country
Date: February 2015
KernelVersion: 3.19
Contact: Olivier Gay <ogay@logitech.com>
Description: When read, this file returns the hex integer value in ASCII
of the device's HID country code (e.g. 21 for US).
This file cannot be written.

45
Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff
View File

@ -5,3 +5,48 @@ 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.
What: /sys/bus/hid/drivers/logitech/<dev>/alternate_modes
Date: Feb 2015
KernelVersion: 4.1
Contact: Michal Malý <madcatxster@gmail.com>
Description: Displays a set of alternate modes supported by a wheel. Each
mode is listed as follows:
Tag: Mode Name
Currently active mode is marked with an asterisk. List also
contains an abstract item "native" which always denotes the
native mode of the wheel. Echoing the mode tag switches the
wheel into the corresponding mode. Depending on the exact model
of the wheel not all listed modes might always be selectable.
If a wheel cannot be switched into the desired mode, -EINVAL
is returned accompanied with an explanatory message in the
kernel log.
This entry is not created for devices that have only one mode.
Currently supported mode switches:
Driving Force Pro:
DF-EX --> DFP
G25:
DF-EX --> DFP --> G25
G27:
DF-EX <*> DFP <-> G25 <-> G27
DF-EX <*--------> G25 <-> G27
DF-EX <*----------------> G27
DFGT:
DF-EX <*> DFP <-> DFGT
DF-EX <*--------> DFGT
* hid_logitech module must be loaded with lg4ff_no_autoswitch=1
parameter set in order for the switch to DF-EX mode to work.
What: /sys/bus/hid/drivers/logitech/<dev>/real_id
Date: Feb 2015
KernelVersion: 4.1
Contact: Michal Malý <madcatxster@gmail.com>
Description: Displays the real model of the wheel regardless of any
alternate mode the wheel might be switched to.
It is a read-only value.
This entry is not created for devices that have only one mode.

11
Documentation/ABI/testing/sysfs-driver-input-axp-pek Normal file
View File

@ -0,0 +1,11 @@
What: /sys/class/input/input(x)/device/startup
Date: March 2014
Contact: Carlo Caione <carlo@caione.org>
Description: Startup time in us. Board is powered on if the button is pressed
for more than <startup_time>
What: /sys/class/input/input(x)/device/shutdown
Date: March 2014
Contact: Carlo Caione <carlo@caione.org>
Description: Shutdown time in us. Board is powered off if the button is pressed
for more than <shutdown_time>

8
Documentation/ABI/testing/sysfs-driver-samsung-laptop
View File

@ -35,3 +35,11 @@ Contact: Corentin Chary <corentin.chary@gmail.com>
Description: Use your USB ports to charge devices, even
when your laptop is powered off.
1 means enabled, 0 means disabled.
What: /sys/devices/platform/samsung/lid_handling
Date: December 11, 2014
KernelVersion: 3.19
Contact: Julijonas Kikutis <julijonas.kikutis@gmail.com>
Description: Some Samsung laptops handle lid closing quicker and
only handle lid opening with this mode enabled.
1 means enabled, 0 means disabled.

114
Documentation/ABI/testing/sysfs-driver-toshiba_acpi Normal file
View File

@ -0,0 +1,114 @@
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_backlight_mode
Date: June 8, 2014
KernelVersion: 3.15
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file controls the keyboard backlight operation mode, valid
values are:
* 0x1 -> FN-Z
* 0x2 -> AUTO (also called TIMER)
* 0x8 -> ON
* 0x10 -> OFF
Note that the kernel 3.16 onwards this file accepts all listed
parameters, kernel 3.15 only accepts the first two (FN-Z and
AUTO).
Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_backlight_timeout
Date: June 8, 2014
KernelVersion: 3.15
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file controls the timeout of the keyboard backlight
whenever the operation mode is set to AUTO (or TIMER),
valid values range from 0-60.
Note that the kernel 3.15 only had support for the first
keyboard type, the kernel 3.16 added support for the second
type and the range accepted for type 2 is 1-60.
See the entry named "kbd_type"
Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/position
Date: June 8, 2014
KernelVersion: 3.15
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file shows the absolute position of the built-in
accelereometer.
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/touchpad
Date: June 8, 2014
KernelVersion: 3.15
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This files controls the status of the touchpad and pointing
stick (if available), valid values are:
* 0 -> OFF
* 1 -> ON
Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/available_kbd_modes
Date: August 3, 2014
KernelVersion: 3.16
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file shows the supported keyboard backlight modes
the system supports, which can be:
* 0x1 -> FN-Z
* 0x2 -> AUTO (also called TIMER)
* 0x8 -> ON
* 0x10 -> OFF
Note that not all keyboard types support the listed modes.
See the entry named "available_kbd_modes"
Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_type
Date: August 3, 2014
KernelVersion: 3.16
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file shows the current keyboard backlight type,
which can be:
* 1 -> Type 1, supporting modes FN-Z and AUTO
* 2 -> Type 2, supporting modes TIMER, ON and OFF
Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/version
Date: February, 2015
KernelVersion: 3.20
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file shows the current version of the driver
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/fan
Date: February, 2015
KernelVersion: 3.20
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file controls the state of the internal fan, valid
values are:
* 0 -> OFF
* 1 -> ON
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_function_keys
Date: February, 2015
KernelVersion: 3.20
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file controls the Special Functions (hotkeys) operation
mode, valid values are:
* 0 -> Normal Operation
* 1 -> Special Functions
In the "Normal Operation" mode, the F{1-12} keys are as usual
and the hotkeys are accessed via FN-F{1-12}.
In the "Special Functions" mode, the F{1-12} keys trigger the
hotkey and the F{1-12} keys are accessed via FN-F{1-12}.
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/panel_power_on
Date: February, 2015
KernelVersion: 3.20
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file controls whether the laptop should turn ON whenever
the LID is opened, valid values are:
* 0 -> Disabled
* 1 -> Enabled
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_three
Date: February, 2015
KernelVersion: 3.20
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file controls whether the USB 3 functionality, valid
values are:
* 0 -> Disabled (Acts as a regular USB 2)
* 1 -> Enabled (Full USB 3 functionality)

6
Documentation/ABI/testing/sysfs-fs-f2fs
View File

@ -74,3 +74,9 @@ Date: March 2014
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:
Controls the memory footprint used by f2fs.
What: /sys/fs/f2fs/<disk>/trim_sections
Date: February 2015
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description:
Controls the trimming rate in batch mode.

44
Documentation/ABI/testing/sysfs-kernel-livepatch Normal file
View File

@ -0,0 +1,44 @@
What: /sys/kernel/livepatch
Date: Nov 2014
KernelVersion: 3.19.0
Contact: live-patching@vger.kernel.org
Description:
Interface for kernel live patching
The /sys/kernel/livepatch directory contains subdirectories for
each loaded live patch module.
What: /sys/kernel/livepatch/<patch>
Date: Nov 2014
KernelVersion: 3.19.0
Contact: live-patching@vger.kernel.org
Description:
The patch directory contains subdirectories for each kernel
object (vmlinux or a module) in which it patched functions.
What: /sys/kernel/livepatch/<patch>/enabled
Date: Nov 2014
KernelVersion: 3.19.0
Contact: live-patching@vger.kernel.org
Description:
A writable attribute that indicates whether the patched
code is currently applied. Writing 0 will disable the patch
while writing 1 will re-enable the patch.
What: /sys/kernel/livepatch/<patch>/<object>
Date: Nov 2014
KernelVersion: 3.19.0
Contact: live-patching@vger.kernel.org
Description:
The object directory contains subdirectories for each function
that is patched within the object.
What: /sys/kernel/livepatch/<patch>/<object>/<function>
Date: Nov 2014
KernelVersion: 3.19.0
Contact: live-patching@vger.kernel.org
Description:
The function directory contains attributes regarding the
properties and state of the patched function.
There are currently no such attributes.

6
Documentation/Changes
View File

@ -21,8 +21,8 @@ running a Linux kernel. Also, not all tools are necessary on all
systems; obviously, if you don't have any ISDN hardware, for example,
you probably needn't concern yourself with isdn4k-utils.
o Gnu C 3.2 # gcc --version
o Gnu make 3.80 # make --version
o GNU C 3.2 # gcc --version
o GNU make 3.80 # make --version
o binutils 2.12 # ld -v
o util-linux 2.10o # fdformat --version
o module-init-tools 0.9.10 # depmod -V
@ -57,7 +57,7 @@ computer.
Make
----
You will need Gnu make 3.80 or later to build the kernel.
You will need GNU make 3.80 or later to build the kernel.
Binutils
--------

1
Documentation/CodingStyle
View File

@ -527,6 +527,7 @@ values. To do the latter, you can stick the following in your .emacs file:
(string-match (expand-file-name "~/src/linux-trees")
filename))
(setq indent-tabs-mode t)
(setq show-trailing-whitespace t)
(c-set-style "linux-tabs-only")))))
This will make emacs go better with the kernel coding style for C

5
Documentation/DocBook/80211.tmpl
View File

@ -113,7 +113,6 @@
!Finclude/net/cfg80211.h cfg80211_beacon_data
!Finclude/net/cfg80211.h cfg80211_ap_settings
!Finclude/net/cfg80211.h station_parameters
!Finclude/net/cfg80211.h station_info_flags
!Finclude/net/cfg80211.h rate_info_flags
!Finclude/net/cfg80211.h rate_info
!Finclude/net/cfg80211.h station_info
@ -435,7 +434,6 @@
<section id="ps-client">
<title>support for powersaving clients</title>
!Pinclude/net/mac80211.h AP support for powersaving clients
</section>
!Finclude/net/mac80211.h ieee80211_get_buffered_bc
!Finclude/net/mac80211.h ieee80211_beacon_get
!Finclude/net/mac80211.h ieee80211_sta_eosp
@ -444,6 +442,7 @@
!Finclude/net/mac80211.h ieee80211_sta_ps_transition_ni
!Finclude/net/mac80211.h ieee80211_sta_set_buffered
!Finclude/net/mac80211.h ieee80211_sta_block_awake
</section>
</chapter>
<chapter id="multi-iface">
@ -488,8 +487,8 @@
<title>RX A-MPDU aggregation</title>
!Pnet/mac80211/agg-rx.c RX A-MPDU aggregation
!Cnet/mac80211/agg-rx.c
</sect1>
!Finclude/net/mac80211.h ieee80211_ampdu_mlme_action
</sect1>
</chapter>
<chapter id="smps">

2
Documentation/DocBook/Makefile
View File

@ -56,7 +56,7 @@ htmldocs: $(HTML)
MAN := $(patsubst %.xml, %.9, $(BOOKS))
mandocs: $(MAN)
$(if $(wildcard $(obj)/man/*.9),gzip -f $(obj)/man/*.9)
find $(obj)/man -name '*.9' | xargs gzip -f
installmandocs: mandocs
mkdir -p /usr/local/man/man9/

2
Documentation/DocBook/crypto-API.tmpl
View File

@ -111,7 +111,7 @@
<para>
This specification is intended for consumers of the kernel crypto
API as well as for developers implementing ciphers. This API
specification, however, does not discusses all API calls available
specification, however, does not discuss all API calls available
to data transformation implementations (i.e. implementations of
ciphers and other transformations (such as CRC or even compression
algorithms) that can register with the kernel crypto API).

17
Documentation/DocBook/device-drivers.tmpl
View File

@ -190,23 +190,6 @@ X!Edrivers/pnp/system.c
!Idrivers/message/fusion/mptfc.c
!Idrivers/message/fusion/mptlan.c
</sect1>
<sect1><title>I2O message devices</title>
!Iinclude/linux/i2o.h
!Idrivers/message/i2o/core.h
!Edrivers/message/i2o/iop.c
!Idrivers/message/i2o/iop.c
!Idrivers/message/i2o/config-osm.c
!Edrivers/message/i2o/exec-osm.c
!Idrivers/message/i2o/exec-osm.c
!Idrivers/message/i2o/bus-osm.c
!Edrivers/message/i2o/device.c
!Idrivers/message/i2o/device.c
!Idrivers/message/i2o/driver.c
!Idrivers/message/i2o/pci.c
!Idrivers/message/i2o/i2o_block.c
!Idrivers/message/i2o/i2o_scsi.c
!Idrivers/message/i2o/i2o_proc.c
</sect1>
</chapter>
<chapter id="snddev">

126
Documentation/DocBook/drm.tmpl
View File

@ -239,6 +239,14 @@
Driver supports dedicated render nodes.
</para></listitem>
</varlistentry>
<varlistentry>
<term>DRIVER_ATOMIC</term>
<listitem><para>
Driver supports atomic properties. In this case the driver
must implement appropriate obj->atomic_get_property() vfuncs
for any modeset objects with driver specific properties.
</para></listitem>
</varlistentry>
</variablelist>
</sect3>
<sect3>
@ -1377,7 +1385,7 @@ int max_width, max_height;</synopsis>
<itemizedlist>
<listitem>
DRM_PLANE_TYPE_PRIMARY represents a "main" plane for a CRTC. Primary
planes are the planes operated upon by by CRTC modesetting and flipping
planes are the planes operated upon by CRTC modesetting and flipping
operations described in <xref linkend="drm-kms-crtcops"/>.
</listitem>
<listitem>
@ -2362,6 +2370,7 @@ void intel_crt_init(struct drm_device *dev)
</sect2>
<sect2>
<title>Modeset Helper Functions Reference</title>
!Iinclude/drm/drm_crtc_helper.h
!Edrivers/gpu/drm/drm_crtc_helper.c
!Pdrivers/gpu/drm/drm_crtc_helper.c overview
</sect2>
@ -2564,8 +2573,8 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >Description/Restrictions</td>
</tr>
<tr>
<td rowspan="25" valign="top" >DRM</td>
<td rowspan="4" valign="top" >Generic</td>
<td rowspan="36" valign="top" >DRM</td>
<td rowspan="5" valign="top" >Connector</td>
<td valign="top" >“EDID”</td>
<td valign="top" >BLOB | IMMUTABLE</td>
<td valign="top" >0</td>
@ -2594,7 +2603,14 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >Contains tiling information for a connector.</td>
</tr>
<tr>
<td rowspan="1" valign="top" >Plane</td>
<td valign="top" >“CRTC_ID”</td>
<td valign="top" >OBJECT</td>
<td valign="top" >DRM_MODE_OBJECT_CRTC</td>
<td valign="top" >Connector</td>
<td valign="top" >CRTC that connector is attached to (atomic)</td>
</tr>
<tr>
<td rowspan="11" valign="top" >Plane</td>
<td valign="top" >“type”</td>
<td valign="top" >ENUM | IMMUTABLE</td>
<td valign="top" >{ "Overlay", "Primary", "Cursor" }</td>
@ -2602,6 +2618,76 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >Plane type</td>
</tr>
<tr>
<td valign="top" >“SRC_X”</td>
<td valign="top" >RANGE</td>
<td valign="top" >Min=0, Max=UINT_MAX</td>
<td valign="top" >Plane</td>
<td valign="top" >Scanout source x coordinate in 16.16 fixed point (atomic)</td>
</tr>
<tr>
<td valign="top" >“SRC_Y”</td>
<td valign="top" >RANGE</td>
<td valign="top" >Min=0, Max=UINT_MAX</td>
<td valign="top" >Plane</td>
<td valign="top" >Scanout source y coordinate in 16.16 fixed point (atomic)</td>
</tr>
<tr>
<td valign="top" >“SRC_W”</td>
<td valign="top" >RANGE</td>
<td valign="top" >Min=0, Max=UINT_MAX</td>
<td valign="top" >Plane</td>
<td valign="top" >Scanout source width in 16.16 fixed point (atomic)</td>
</tr>
<tr>
<td valign="top" >“SRC_H”</td>
<td valign="top" >RANGE</td>
<td valign="top" >Min=0, Max=UINT_MAX</td>
<td valign="top" >Plane</td>
<td valign="top" >Scanout source height in 16.16 fixed point (atomic)</td>
</tr>
<tr>
<td valign="top" >“CRTC_X”</td>
<td valign="top" >SIGNED_RANGE</td>
<td valign="top" >Min=INT_MIN, Max=INT_MAX</td>
<td valign="top" >Plane</td>
<td valign="top" >Scanout CRTC (destination) x coordinate (atomic)</td>
</tr>
<tr>
<td valign="top" >“CRTC_Y”</td>
<td valign="top" >SIGNED_RANGE</td>
<td valign="top" >Min=INT_MIN, Max=INT_MAX</td>
<td valign="top" >Plane</td>
<td valign="top" >Scanout CRTC (destination) y coordinate (atomic)</td>
</tr>
<tr>
<td valign="top" >“CRTC_W”</td>
<td valign="top" >RANGE</td>
<td valign="top" >Min=0, Max=UINT_MAX</td>
<td valign="top" >Plane</td>
<td valign="top" >Scanout CRTC (destination) width (atomic)</td>
</tr>
<tr>
<td valign="top" >“CRTC_H”</td>
<td valign="top" >RANGE</td>
<td valign="top" >Min=0, Max=UINT_MAX</td>
<td valign="top" >Plane</td>
<td valign="top" >Scanout CRTC (destination) height (atomic)</td>
</tr>
<tr>
<td valign="top" >“FB_ID”</td>
<td valign="top" >OBJECT</td>
<td valign="top" >DRM_MODE_OBJECT_FB</td>
<td valign="top" >Plane</td>
<td valign="top" >Scanout framebuffer (atomic)</td>
</tr>
<tr>
<td valign="top" >“CRTC_ID”</td>
<td valign="top" >OBJECT</td>
<td valign="top" >DRM_MODE_OBJECT_CRTC</td>
<td valign="top" >Plane</td>
<td valign="top" >CRTC that plane is attached to (atomic)</td>
</tr>
<tr>
<td rowspan="2" valign="top" >DVI-I</td>
<td valign="top" >“subconnector”</td>
<td valign="top" >ENUM</td>
@ -3883,6 +3969,7 @@ int num_ioctls;</synopsis>
<title>Runtime Power Management</title>
!Pdrivers/gpu/drm/i915/intel_runtime_pm.c runtime pm
!Idrivers/gpu/drm/i915/intel_runtime_pm.c
!Idrivers/gpu/drm/i915/intel_uncore.c
</sect2>
<sect2>
<title>Interrupt Handling</title>
@ -3931,6 +4018,11 @@ int num_ioctls;</synopsis>
framebuffer compression and panel self refresh.
</para>
</sect2>
<sect2>
<title>Atomic Plane Helpers</title>
!Pdrivers/gpu/drm/i915/intel_atomic_plane.c atomic plane helpers
!Idrivers/gpu/drm/i915/intel_atomic_plane.c
</sect2>
<sect2>
<title>Output Probing</title>
<para>
@ -3949,6 +4041,11 @@ int num_ioctls;</synopsis>
<title>Panel Self Refresh PSR (PSR/SRD)</title>
!Pdrivers/gpu/drm/i915/intel_psr.c Panel Self Refresh (PSR/SRD)
!Idrivers/gpu/drm/i915/intel_psr.c
</sect2>
<sect2>
<title>Frame Buffer Compression (FBC)</title>
!Pdrivers/gpu/drm/i915/intel_fbc.c Frame Buffer Compression (FBC)
!Idrivers/gpu/drm/i915/intel_fbc.c
</sect2>
<sect2>
<title>DPIO</title>
@ -4052,12 +4149,33 @@ int num_ioctls;</synopsis>
<title>Batchbuffer Parsing</title>
!Pdrivers/gpu/drm/i915/i915_cmd_parser.c batch buffer command parser
!Idrivers/gpu/drm/i915/i915_cmd_parser.c
</sect2>
<sect2>
<title>Batchbuffer Pools</title>
!Pdrivers/gpu/drm/i915/i915_gem_batch_pool.c batch pool
!Idrivers/gpu/drm/i915/i915_gem_batch_pool.c
</sect2>
<sect2>
<title>Logical Rings, Logical Ring Contexts and Execlists</title>
!Pdrivers/gpu/drm/i915/intel_lrc.c Logical Rings, Logical Ring Contexts and Execlists
!Idrivers/gpu/drm/i915/intel_lrc.c
</sect2>
<sect2>
<title>Global GTT views</title>
!Pdrivers/gpu/drm/i915/i915_gem_gtt.c Global GTT views
!Idrivers/gpu/drm/i915/i915_gem_gtt.c
</sect2>
<sect2>
<title>Buffer Object Eviction</title>
<para>
This section documents the interface function for evicting buffer
objects to make space available in the virtual gpu address spaces.
Note that this is mostly orthogonal to shrinking buffer objects
caches, which has the goal to make main memory (shared with the gpu
through the unified memory architecture) available.
</para>
!Idrivers/gpu/drm/i915/i915_gem_evict.c
</sect2>
</sect1>
<sect1>

87
Documentation/DocBook/kgdb.tmpl
View File

@ -75,7 +75,7 @@
a development machine and the other is the target machine. The
kernel to be debugged runs on the target machine. The development
machine runs an instance of gdb against the vmlinux file which
contains the symbols (not boot image such as bzImage, zImage,
contains the symbols (not a boot image such as bzImage, zImage,
uImage...). In gdb the developer specifies the connection
parameters and connects to kgdb. The type of connection a
developer makes with gdb depends on the availability of kgdb I/O
@ -95,7 +95,7 @@
<title>Kernel config options for kgdb</title>
<para>
To enable <symbol>CONFIG_KGDB</symbol> you should look under
"Kernel debugging" and select "KGDB: kernel debugger".
"Kernel hacking" / "Kernel debugging" and select "KGDB: kernel debugger".
</para>
<para>
While it is not a hard requirement that you have symbols in your
@ -105,7 +105,7 @@
kernel with debug info" in the config menu.
</para>
<para>
It is advised, but not required that you turn on the
It is advised, but not required, that you turn on the
<symbol>CONFIG_FRAME_POINTER</symbol> kernel option which is called "Compile the
kernel with frame pointers" in the config menu. This option
inserts code to into the compiled executable which saves the frame
@ -181,7 +181,7 @@
<para>This section describes the various runtime kernel
parameters that affect the configuration of the kernel debugger.
The following chapter covers using kdb and kgdb as well as
provides some examples of the configuration parameters.</para>
providing some examples of the configuration parameters.</para>
<sect1 id="kgdboc">
<title>Kernel parameter: kgdboc</title>
<para>The kgdboc driver was originally an abbreviation meant to
@ -197,6 +197,7 @@
may be configured as a kernel built-in or a kernel loadable module.
You can only make use of <constant>kgdbwait</constant> and early
debugging if you build kgdboc into the kernel as a built-in.
</para>
<para>Optionally you can elect to activate kms (Kernel Mode
Setting) integration. When you use kms with kgdboc and you have a
video driver that has atomic mode setting hooks, it is possible to
@ -206,7 +207,6 @@
crashes or doing analysis of memory with kdb while allowing the
full graphics console applications to run.
</para>
</para>
<sect2 id="kgdbocArgs">
<title>kgdboc arguments</title>
<para>Usage: <constant>kgdboc=[kms][[,]kbd][[,]serial_device][,baud]</constant></para>
@ -219,8 +219,8 @@
<listitem><para>kbd = Keyboard</para></listitem>
</itemizedlist>
</para>
<para>You can configure kgdboc to use the keyboard, and or a serial
device depending on if you are using kdb and or kgdb, in one of the
<para>You can configure kgdboc to use the keyboard, and/or a serial
device depending on if you are using kdb and/or kgdb, in one of the
following scenarios. The order listed above must be observed if
you use any of the optional configurations together. Using kms +
only gdb is generally not a useful combination.</para>
@ -261,11 +261,8 @@
</sect3>
<sect3 id="kgdbocArgs3">
<title>More examples</title>
<para>You can configure kgdboc to use the keyboard, and or a serial
device depending on if you are using kdb and or kgdb, in one of the
following scenarios.</para>
<para>You can configure kgdboc to use the keyboard, and or a serial device
depending on if you are using kdb and or kgdb, in one of the
<para>You can configure kgdboc to use the keyboard, and/or a serial device
depending on if you are using kdb and/or kgdb, in one of the
following scenarios.
<orderedlist>
<listitem><para>kdb and kgdb over only a serial port</para>
@ -287,7 +284,6 @@
</listitem>
</orderedlist>
</para>
</sect3>
<para>NOTE: Kgdboc does not support interrupting the target via the
gdb remote protocol. You must manually send a sysrq-g unless you
have a proxy that splits console output to a terminal program.
@ -308,6 +304,7 @@
as well as on the initial connect, or to use a debugger proxy that
allows an unmodified gdb to do the debugging.
</para>
</sect3>
</sect2>
</sect1>
<sect1 id="kgdbwait">
@ -315,7 +312,7 @@
<para>
The Kernel command line option <constant>kgdbwait</constant> makes
kgdb wait for a debugger connection during booting of a kernel. You
can only use this option you compiled a kgdb I/O driver into the
can only use this option if you compiled a kgdb I/O driver into the
kernel and you specified the I/O driver configuration as a kernel
command line option. The kgdbwait parameter should always follow the
configuration parameter for the kgdb I/O driver in the kernel
@ -353,12 +350,12 @@
</para>
</listitem>
</orderedlist>
</para>
<para>IMPORTANT NOTE: You cannot use kgdboc + kgdbcon on a tty that is an
active system console. An example incorrect usage is <constant>console=ttyS0,115200 kgdboc=ttyS0 kgdbcon</constant>
active system console. An example of incorrect usage is <constant>console=ttyS0,115200 kgdboc=ttyS0 kgdbcon</constant>
</para>
<para>It is possible to use this option with kgdboc on a tty that is not a system console.
</para>
</para>
</sect1>
<sect1 id="kgdbreboot">
<title>Run time parameter: kgdbreboot</title>
@ -386,12 +383,12 @@
<title>Quick start for kdb on a serial port</title>
<para>This is a quick example of how to use kdb.</para>
<para><orderedlist>
<listitem><para>Boot kernel with arguments:
<listitem><para>Configure kgdboc at boot using kernel parameters:
<itemizedlist>
<listitem><para><constant>console=ttyS0,115200 kgdboc=ttyS0,115200</constant></para></listitem>
</itemizedlist></para>
<para>OR</para>
<para>Configure kgdboc after the kernel booted; assuming you are using a serial port console:
<para>Configure kgdboc after the kernel has booted; assuming you are using a serial port console:
<itemizedlist>
<listitem><para><constant>echo ttyS0 &gt; /sys/module/kgdboc/parameters/kgdboc</constant></para></listitem>
</itemizedlist>
@ -442,12 +439,12 @@
<title>Quick start for kdb using a keyboard connected console</title>
<para>This is a quick example of how to use kdb with a keyboard.</para>
<para><orderedlist>
<listitem><para>Boot kernel with arguments:
<listitem><para>Configure kgdboc at boot using kernel parameters:
<itemizedlist>
<listitem><para><constant>kgdboc=kbd</constant></para></listitem>
</itemizedlist></para>
<para>OR</para>
<para>Configure kgdboc after the kernel booted:
<para>Configure kgdboc after the kernel has booted:
<itemizedlist>
<listitem><para><constant>echo kbd &gt; /sys/module/kgdboc/parameters/kgdboc</constant></para></listitem>
</itemizedlist>
@ -501,12 +498,12 @@
<title>Connecting with gdb to a serial port</title>
<orderedlist>
<listitem><para>Configure kgdboc</para>
<para>Boot kernel with arguments:
<para>Configure kgdboc at boot using kernel parameters:
<itemizedlist>
<listitem><para><constant>kgdboc=ttyS0,115200</constant></para></listitem>
</itemizedlist></para>
<para>OR</para>
<para>Configure kgdboc after the kernel booted:
<para>Configure kgdboc after the kernel has booted:
<itemizedlist>
<listitem><para><constant>echo ttyS0 &gt; /sys/module/kgdboc/parameters/kgdboc</constant></para></listitem>
</itemizedlist></para>
@ -536,7 +533,7 @@
</para>
</listitem>
<listitem>
<para>Connect from from gdb</para>
<para>Connect from gdb</para>
<para>
Example (using a directly connected port):
</para>
@ -584,7 +581,7 @@
<para>
There are two ways to switch from kgdb to kdb: you can use gdb to
issue a maintenance packet, or you can blindly type the command $3#33.
Whenever kernel debugger stops in kgdb mode it will print the
Whenever the kernel debugger stops in kgdb mode it will print the
message <constant>KGDB or $3#33 for KDB</constant>. It is important
to note that you have to type the sequence correctly in one pass.
You cannot type a backspace or delete because kgdb will interpret
@ -704,7 +701,7 @@ Task Addr Pid Parent [*] cpu State Thread Command
<listitem><para>Registration and unregistration of architecture specific trap hooks</para></listitem>
<listitem><para>Any special exception handling and cleanup</para></listitem>
<listitem><para>NMI exception handling and cleanup</para></listitem>
<listitem><para>(optional)HW breakpoints</para></listitem>
<listitem><para>(optional) HW breakpoints</para></listitem>
</itemizedlist>
</para>
</listitem>
@ -760,7 +757,7 @@ Task Addr Pid Parent [*] cpu State Thread Command
a kgdb I/O driver for characters when it needs input. The I/O
driver is expected to return immediately if there is no data
available. Doing so allows for the future possibility to touch
watch dog hardware in such a way as to have a target system not
watchdog hardware in such a way as to have a target system not
reset when these are enabled.
</para>
</listitem>
@ -779,21 +776,25 @@ Task Addr Pid Parent [*] cpu State Thread Command
their &lt;asm/kgdb.h&gt; file. These are:
<itemizedlist>
<listitem>
<para>
NUMREGBYTES: The size in bytes of all of the registers, so
that we can ensure they will all fit into a packet.
</para>
<para>
BUFMAX: The size in bytes of the buffer GDB will read into.
This must be larger than NUMREGBYTES.
</para>
<para>
CACHE_FLUSH_IS_SAFE: Set to 1 if it is always safe to call
flush_cache_range or flush_icache_range. On some architectures,
these functions may not be safe to call on SMP since we keep other
CPUs in a holding pattern.
</para>
</listitem>
<para>
NUMREGBYTES: The size in bytes of all of the registers, so
that we can ensure they will all fit into a packet.
</para>
</listitem>
<listitem>
<para>
BUFMAX: The size in bytes of the buffer GDB will read into.
This must be larger than NUMREGBYTES.
</para>
</listitem>
<listitem>
<para>
CACHE_FLUSH_IS_SAFE: Set to 1 if it is always safe to call
flush_cache_range or flush_icache_range. On some architectures,
these functions may not be safe to call on SMP since we keep other
CPUs in a holding pattern.
</para>
</listitem>
</itemizedlist>
</para>
<para>
@ -812,8 +813,8 @@ Task Addr Pid Parent [*] cpu State Thread Command
<para>
The kgdboc driver is actually a very thin driver that relies on the
underlying low level to the hardware driver having "polling hooks"
which the to which the tty driver is attached. In the initial
implementation of kgdboc it the serial_core was changed to expose a
to which the tty driver is attached. In the initial
implementation of kgdboc the serial_core was changed to expose a
low level UART hook for doing polled mode reading and writing of a
single character while in an atomic context. When kgdb makes an I/O
request to the debugger, kgdboc invokes a callback in the serial

11
Documentation/DocBook/media/v4l/controls.xml
View File

@ -2692,12 +2692,11 @@ in the S5P family of SoCs by Samsung.
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_MFC51_VIDEO_DECODER_H264_DISPLAY_DELAY_ENABLE</constant>&nbsp;</entry>
<entry>integer</entry>
</row><row><entry spanname="descr">If the display delay is enabled then the decoder has to return a
CAPTURE buffer after processing a certain number of OUTPUT buffers. If this number is low, then it may result in
buffers not being dequeued in display order. In addition hardware may still use those buffers as reference, thus
application should not write to those buffers. This feature can be used for example for generating thumbnails of videos.
Applicable to the H264 decoder.
<entry>boolean</entry>
</row><row><entry spanname="descr">If the display delay is enabled then the decoder is forced to return a
CAPTURE buffer (decoded frame) after processing a certain number of OUTPUT buffers. The delay can be set through
<constant>V4L2_CID_MPEG_MFC51_VIDEO_DECODER_H264_DISPLAY_DELAY</constant>. This feature can be used for example
for generating thumbnails of videos. Applicable to the H264 decoder.
</entry>
</row>
<row><entry></entry></row>

2
Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
View File

@ -17,7 +17,7 @@
<refsect1>
<title>Description</title>
<para>The following four pixel formats are raw sRGB / Bayer formats with
<para>These four pixel formats are raw sRGB / Bayer formats with
10 bits per colour. Each colour component is stored in a 16-bit word, with 6
unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
and n/2 blue or red samples, with alternating red and blue rows. Bytes are

2
Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
View File

@ -25,7 +25,7 @@
</refnamediv>
<refsect1>
<title>Description</title>
<para>The following four pixel formats are raw sRGB / Bayer
<para>These four pixel formats are raw sRGB / Bayer
formats with 10 bits per color compressed to 8 bits each,
using the A-LAW algorithm. Each color component consumes 8
bits of memory. In other respects this format is similar to

2
Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
View File

@ -18,7 +18,7 @@
<refsect1>
<title>Description</title>
<para>The following four pixel formats are raw sRGB / Bayer formats
<para>These four pixel formats are raw sRGB / Bayer formats
with 10 bits per colour compressed to 8 bits each, using DPCM
compression. DPCM, differential pulse-code modulation, is lossy.
Each colour component consumes 8 bits of memory. In other respects

99
Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml Normal file
View File

@ -0,0 +1,99 @@
<refentry id="pixfmt-srggb10p">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_SRGGB10P ('pRAA'),
V4L2_PIX_FMT_SGRBG10P ('pgAA'),
V4L2_PIX_FMT_SGBRG10P ('pGAA'),
V4L2_PIX_FMT_SBGGR10P ('pBAA'),
</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-SRGGB10P"><constant>V4L2_PIX_FMT_SRGGB10P</constant></refname>
<refname id="V4L2-PIX-FMT-SGRBG10P"><constant>V4L2_PIX_FMT_SGRBG10P</constant></refname>
<refname id="V4L2-PIX-FMT-SGBRG10P"><constant>V4L2_PIX_FMT_SGBRG10P</constant></refname>
<refname id="V4L2-PIX-FMT-SBGGR10P"><constant>V4L2_PIX_FMT_SBGGR10P</constant></refname>
<refpurpose>10-bit packed Bayer formats</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>These four pixel formats are packed raw sRGB /
Bayer formats with 10 bits per colour. Every four consecutive
colour components are packed into 5 bytes. Each of the first 4
bytes contain the 8 high order bits of the pixels, and the
fifth byte contains the two least significants bits of each
pixel, in the same order.</para>
<para>Each n-pixel row contains n/2 green samples and n/2 blue
or red samples, with alternating green-red and green-blue
rows. They are conventionally described as GRGR... BGBG...,
RGRG... GBGB..., etc. Below is an example of one of these
formats:</para>
<example>
<title><constant>V4L2_PIX_FMT_SBGGR10P</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="topbot" colsep="1" rowsep="1">
<tgroup cols="5" align="center" border="1">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>B<subscript>00high</subscript></entry>
<entry>G<subscript>01high</subscript></entry>
<entry>B<subscript>02high</subscript></entry>
<entry>G<subscript>03high</subscript></entry>
<entry>B<subscript>00low</subscript>(bits 7--6)
G<subscript>01low</subscript>(bits 5--4)
B<subscript>02low</subscript>(bits 3--2)
G<subscript>03low</subscript>(bits 1--0)
</entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;5:</entry>
<entry>G<subscript>10high</subscript></entry>
<entry>R<subscript>11high</subscript></entry>
<entry>G<subscript>12high</subscript></entry>
<entry>R<subscript>13high</subscript></entry>
<entry>G<subscript>10low</subscript>(bits 7--6)
R<subscript>11low</subscript>(bits 5--4)
G<subscript>12low</subscript>(bits 3--2)
R<subscript>13low</subscript>(bits 1--0)
</entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;10:</entry>
<entry>B<subscript>20high</subscript></entry>
<entry>G<subscript>21high</subscript></entry>
<entry>B<subscript>22high</subscript></entry>
<entry>G<subscript>23high</subscript></entry>
<entry>B<subscript>20low</subscript>(bits 7--6)
G<subscript>21low</subscript>(bits 5--4)
B<subscript>22low</subscript>(bits 3--2)
G<subscript>23low</subscript>(bits 1--0)
</entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;15:</entry>
<entry>G<subscript>30high</subscript></entry>
<entry>R<subscript>31high</subscript></entry>
<entry>G<subscript>32high</subscript></entry>
<entry>R<subscript>33high</subscript></entry>
<entry>G<subscript>30low</subscript>(bits 7--6)
R<subscript>31low</subscript>(bits 5--4)
G<subscript>32low</subscript>(bits 3--2)
R<subscript>33low</subscript>(bits 1--0)
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

2
Documentation/DocBook/media/v4l/pixfmt-srggb12.xml
View File

@ -17,7 +17,7 @@
<refsect1>
<title>Description</title>
<para>The following four pixel formats are raw sRGB / Bayer formats with
<para>These four pixel formats are raw sRGB / Bayer formats with
12 bits per colour. Each colour component is stored in a 16-bit word, with 4
unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
and n/2 blue or red samples, with alternating red and blue rows. Bytes are

1
Documentation/DocBook/media/v4l/pixfmt.xml
View File

@ -1405,6 +1405,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.<
&sub-srggb8;
&sub-sbggr16;
&sub-srggb10;
&sub-srggb10p;
&sub-srggb10alaw8;
&sub-srggb10dpcm8;
&sub-srggb12;

8
Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml
View File

@ -212,11 +212,3 @@ standards set in the <structfield>standards</structfield> field.
&return-value;
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

8
Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml
View File

@ -131,11 +131,3 @@ is out of bounds or the <structfield>pad</structfield> number is invalid.</para>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

14
Documentation/DocBook/uio-howto.tmpl
View File

@ -719,7 +719,7 @@ framework to set up sysfs files for this region. Simply leave it alone.
</para>
</sect1>
<sect1 id="using uio_dmem_genirq">
<sect1 id="using-uio_dmem_genirq">
<title>Using uio_dmem_genirq for platform devices</title>
<para>
In addition to statically allocated memory ranges, they may also be
@ -746,16 +746,16 @@ framework to set up sysfs files for this region. Simply leave it alone.
following elements:
</para>
<itemizedlist>
<listitem><varname>struct uio_info uioinfo</varname>: The same
<listitem><para><varname>struct uio_info uioinfo</varname>: The same
structure used as the <varname>uio_pdrv_genirq</varname> platform
data</listitem>
<listitem><varname>unsigned int *dynamic_region_sizes</varname>:
data</para></listitem>
<listitem><para><varname>unsigned int *dynamic_region_sizes</varname>:
Pointer to list of sizes of dynamic memory regions to be mapped into
user space.
</listitem>
<listitem><varname>unsigned int num_dynamic_regions</varname>:
</para></listitem>
<listitem><para><varname>unsigned int num_dynamic_regions</varname>:
Number of elements in <varname>dynamic_region_sizes</varname> array.
</listitem>
</para></listitem>
</itemizedlist>
<para>
The dynamic regions defined in the platform data will be appended to

460
Documentation/SubmittingPatches
View File

@ -10,27 +10,49 @@ kernel, the process can sometimes be daunting if you're not familiar
with "the system." This text is a collection of suggestions which
can greatly increase the chances of your change being accepted.
Read Documentation/SubmitChecklist for a list of items to check
before submitting code. If you are submitting a driver, also read
Documentation/SubmittingDrivers.
This document contains a large number of suggestions in a relatively terse
format. For detailed information on how the kernel development process
works, see Documentation/development-process. Also, read
Documentation/SubmitChecklist for a list of items to check before
submitting code. If you are submitting a driver, also read
Documentation/SubmittingDrivers; for device tree binding patches, read
Documentation/devicetree/bindings/submitting-patches.txt.
Many of these steps describe the default behavior of the git version
control system; if you use git to prepare your patches, you'll find much
of the mechanical work done for you, though you'll still need to prepare
and document a sensible set of patches.
and document a sensible set of patches. In general, use of git will make
your life as a kernel developer easier.
--------------------------------------------
SECTION 1 - CREATING AND SENDING YOUR CHANGE
--------------------------------------------
0) Obtain a current source tree
-------------------------------
If you do not have a repository with the current kernel source handy, use
git to obtain one. You'll want to start with the mainline repository,
which can be grabbed with:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Note, however, that you may not want to develop against the mainline tree
directly. Most subsystem maintainers run their own trees and want to see
patches prepared against those trees. See the "T:" entry for the subsystem
in the MAINTAINERS file to find that tree, or simply ask the maintainer if
the tree is not listed there.
It is still possible to download kernel releases via tarballs (as described
in the next section), but that is the hard way to do kernel development.
1) "diff -up"
------------
Use "diff -up" or "diff -uprN" to create patches. git generates patches
in this form by default; if you're using git, you can skip this section
entirely.
If you must generate your patches by hand, use "diff -up" or "diff -uprN"
to create patches. Git generates patches in this form by default; if
you're using git, you can skip this section entirely.
All changes to the Linux kernel occur in the form of patches, as
generated by diff(1). When creating your patch, make sure to create it
@ -42,7 +64,7 @@ not in any lower subdirectory.
To create a patch for a single file, it is often sufficient to do:
SRCTREE= linux-2.6
SRCTREE= linux
MYFILE= drivers/net/mydriver.c
cd $SRCTREE
@ -55,17 +77,16 @@ To create a patch for multiple files, you should unpack a "vanilla",
or unmodified kernel source tree, and generate a diff against your
own source tree. For example:
MYSRC= /devel/linux-2.6
MYSRC= /devel/linux
tar xvfz linux-2.6.12.tar.gz
mv linux-2.6.12 linux-2.6.12-vanilla
diff -uprN -X linux-2.6.12-vanilla/Documentation/dontdiff \
linux-2.6.12-vanilla $MYSRC > /tmp/patch
tar xvfz linux-3.19.tar.gz
mv linux-3.19 linux-3.19-vanilla
diff -uprN -X linux-3.19-vanilla/Documentation/dontdiff \
linux-3.19-vanilla $MYSRC > /tmp/patch
"dontdiff" is a list of files which are generated by the kernel during
the build process, and should be ignored in any diff(1)-generated
patch. The "dontdiff" file is included in the kernel tree in
2.6.12 and later.
patch.
Make sure your patch does not include any extra files which do not
belong in a patch submission. Make sure to review your patch -after-
@ -83,6 +104,7 @@ is another popular alternative.
2) Describe your changes.
-------------------------
Describe your problem. Whether your patch is a one-line bug fix or
5000 lines of a new feature, there must be an underlying problem that
@ -124,10 +146,10 @@ See #3, next.
When you submit or resubmit a patch or patch series, include the
complete patch description and justification for it. Don't just
say that this is version N of the patch (series). Don't expect the
patch merger to refer back to earlier patch versions or referenced
subsystem maintainer to refer back to earlier patch versions or referenced
URLs to find the patch description and put that into the patch.
I.e., the patch (series) and its description should be self-contained.
This benefits both the patch merger(s) and reviewers. Some reviewers
This benefits both the maintainers and reviewers. Some reviewers
probably didn't even receive earlier versions of the patch.
Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
@ -156,10 +178,15 @@ Example:
platform_set_drvdata(), but left the variable "dev" unused,
delete it.
You should also be sure to use at least the first twelve characters of the
SHA-1 ID. The kernel repository holds a *lot* of objects, making
collisions with shorter IDs a real possibility. Bear in mind that, even if
there is no collision with your six-character ID now, that condition may
change five years from now.
If your patch fixes a bug in a specific commit, e.g. you found an issue using
git-bisect, please use the 'Fixes:' tag with the first 12 characters of the
SHA-1 ID, and the one line summary.
Example:
SHA-1 ID, and the one line summary. For example:
Fixes: e21d2170f366 ("video: remove unnecessary platform_set_drvdata()")
@ -172,8 +199,9 @@ outputting the above style in the git log or git show commands
fixes = Fixes: %h (\"%s\")
3) Separate your changes.
-------------------------
Separate _logical changes_ into a single patch file.
Separate each _logical change_ into a separate patch.
For example, if your changes include both bug fixes and performance
enhancements for a single driver, separate those changes into two
@ -184,90 +212,116 @@ On the other hand, if you make a single change to numerous files,
group those changes into a single patch. Thus a single logical change
is contained within a single patch.
The point to remember is that each patch should make an easily understood
change that can be verified by reviewers. Each patch should be justifiable
on its own merits.
If one patch depends on another patch in order for a change to be
complete, that is OK. Simply note "this patch depends on patch X"
in your patch description.
When dividing your change into a series of patches, take special care to
ensure that the kernel builds and runs properly after each patch in the
series. Developers using "git bisect" to track down a problem can end up
splitting your patch series at any point; they will not thank you if you
introduce bugs in the middle.
If you cannot condense your patch set into a smaller set of patches,
then only post say 15 or so at a time and wait for review and integration.
4) Style check your changes.
4) Style-check your changes.
----------------------------
Check your patch for basic style violations, details of which can be
found in Documentation/CodingStyle. Failure to do so simply wastes
the reviewers time and will get your patch rejected, probably
without even being read.
At a minimum you should check your patches with the patch style
checker prior to submission (scripts/checkpatch.pl). You should
be able to justify all violations that remain in your patch.
One significant exception is when moving code from one file to
another -- in this case you should not modify the moved code at all in
the same patch which moves it. This clearly delineates the act of
moving the code and your changes. This greatly aids review of the
actual differences and allows tools to better track the history of
the code itself.
Check your patches with the patch style checker prior to submission
(scripts/checkpatch.pl). Note, though, that the style checker should be
viewed as a guide, not as a replacement for human judgment. If your code
looks better with a violation then its probably best left alone.
The checker reports at three levels:
- ERROR: things that are very likely to be wrong
- WARNING: things requiring careful review
- CHECK: things requiring thought
You should be able to justify all violations that remain in your
patch.
5) Select the recipients for your patch.
----------------------------------------
5) Select e-mail destination.
You should always copy the appropriate subsystem maintainer(s) on any patch
to code that they maintain; look through the MAINTAINERS file and the
source code revision history to see who those maintainers are. The
script scripts/get_maintainer.pl can be very useful at this step. If you
cannot find a maintainer for the subsystem your are working on, Andrew
Morton (akpm@linux-foundation.org) serves as a maintainer of last resort.
Look through the MAINTAINERS file and the source code, and determine
if your change applies to a specific subsystem of the kernel, with
an assigned maintainer. If so, e-mail that person. The script
scripts/get_maintainer.pl can be very useful at this step.
If no maintainer is listed, or the maintainer does not respond, send
your patch to the primary Linux kernel developer's mailing list,
linux-kernel@vger.kernel.org. Most kernel developers monitor this
e-mail list, and can comment on your changes.
You should also normally choose at least one mailing list to receive a copy
of your patch set. linux-kernel@vger.kernel.org functions as a list of
last resort, but the volume on that list has caused a number of developers
to tune it out. Look in the MAINTAINERS file for a subsystem-specific
list; your patch will probably get more attention there. Please do not
spam unrelated lists, though.
Many kernel-related lists are hosted on vger.kernel.org; you can find a
list of them at http://vger.kernel.org/vger-lists.html. There are
kernel-related lists hosted elsewhere as well, though.
Do not send more than 15 patches at once to the vger mailing lists!!!
Linus Torvalds is the final arbiter of all changes accepted into the
Linux kernel. His e-mail address is <torvalds@linux-foundation.org>.
He gets a lot of e-mail, so typically you should do your best to -avoid-
sending him e-mail.
Linux kernel. His e-mail address is <torvalds@linux-foundation.org>.
He gets a lot of e-mail, and, at this point, very few patches go through
Linus directly, so typically you should do your best to -avoid-
sending him e-mail.
Patches which are bug fixes, are "obvious" changes, or similarly
require little discussion should be sent or CC'd to Linus. Patches
which require discussion or do not have a clear advantage should
usually be sent first to linux-kernel. Only after the patch is
discussed should the patch then be submitted to Linus.
If you have a patch that fixes an exploitable security bug, send that patch
to security@kernel.org. For severe bugs, a short embargo may be considered
to allow distrbutors to get the patch out to users; in such cases,
obviously, the patch should not be sent to any public lists.
Patches that fix a severe bug in a released kernel should be directed
toward the stable maintainers by putting a line like this:
Cc: stable@vger.kernel.org
6) Select your CC (e-mail carbon copy) list.
into your patch.
Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org.
Note, however, that some subsystem maintainers want to come to their own
conclusions on which patches should go to the stable trees. The networking
maintainer, in particular, would rather not see individual developers
adding lines like the above to their patches.
Other kernel developers besides Linus need to be aware of your change,
so that they may comment on it and offer code review and suggestions.
linux-kernel is the primary Linux kernel developer mailing list.
Other mailing lists are available for specific subsystems, such as
USB, framebuffer devices, the VFS, the SCSI subsystem, etc. See the
MAINTAINERS file for a mailing list that relates specifically to
your change.
Majordomo lists of VGER.KERNEL.ORG at:
<http://vger.kernel.org/vger-lists.html>
If changes affect userland-kernel interfaces, please send
the MAN-PAGES maintainer (as listed in the MAINTAINERS file)
a man-pages patch, or at least a notification of the change,
so that some information makes its way into the manual pages.
Even if the maintainer did not respond in step #5, make sure to ALWAYS
copy the maintainer when you change their code.
If changes affect userland-kernel interfaces, please send the MAN-PAGES
maintainer (as listed in the MAINTAINERS file) a man-pages patch, or at
least a notification of the change, so that some information makes its way
into the manual pages. User-space API changes should also be copied to
linux-api@vger.kernel.org.
For small patches you may want to CC the Trivial Patch Monkey
trivial@kernel.org which collects "trivial" patches. Have a look
into the MAINTAINERS file for its current manager.
Trivial patches must qualify for one of the following rules:
Spelling fixes in documentation
Spelling fixes which could break grep(1)
Spelling fixes for errors which could break grep(1)
Warning fixes (cluttering with useless warnings is bad)
Compilation fixes (only if they are actually correct)
Runtime fixes (only if they actually fix things)
Removing use of deprecated functions/macros (eg. check_region)
Removing use of deprecated functions/macros
Contact detail and documentation fixes
Non-portable code replaced by portable code (even in arch-specific,
since people copy, as long as it's trivial)
@ -276,7 +330,8 @@ Trivial patches must qualify for one of the following rules:
7) No MIME, no links, no compression, no attachments. Just plain text.
6) No MIME, no links, no compression, no attachments. Just plain text.
-----------------------------------------------------------------------
Linus and other kernel developers need to be able to read and comment
on the changes you are submitting. It is important for a kernel
@ -299,54 +354,48 @@ you to re-send them using MIME.
See Documentation/email-clients.txt for hints about configuring
your e-mail client so that it sends your patches untouched.
8) E-mail size.
When sending patches to Linus, always follow step #7.
7) E-mail size.
---------------
Large changes are not appropriate for mailing lists, and some
maintainers. If your patch, uncompressed, exceeds 300 kB in size,
it is preferred that you store your patch on an Internet-accessible
server, and provide instead a URL (link) pointing to your patch.
server, and provide instead a URL (link) pointing to your patch. But note
that if your patch exceeds 300 kB, it almost certainly needs to be broken up
anyway.
8) Respond to review comments.
------------------------------
Your patch will almost certainly get comments from reviewers on ways in
which the patch can be improved. You must respond to those comments;
ignoring reviewers is a good way to get ignored in return. Review comments
or questions that do not lead to a code change should almost certainly
bring about a comment or changelog entry so that the next reviewer better
understands what is going on.
Be sure to tell the reviewers what changes you are making and to thank them
for their time. Code review is a tiring and time-consuming process, and
reviewers sometimes get grumpy. Even in that case, though, respond
politely and address the problems they have pointed out.
9) Don't get discouraged - or impatient.
----------------------------------------
9) Name your kernel version.
After you have submitted your change, be patient and wait. Reviewers are
busy people and may not get to your patch right away.
It is important to note, either in the subject line or in the patch
description, the kernel version to which this patch applies.
If the patch does not apply cleanly to the latest kernel version,
Linus will not apply it.
Once upon a time, patches used to disappear into the void without comment,
but the development process works more smoothly than that now. You should
receive comments within a week or so; if that does not happen, make sure
that you have sent your patches to the right place. Wait for a minimum of
one week before resubmitting or pinging reviewers - possibly longer during
busy times like merge windows.
10) Don't get discouraged. Re-submit.
After you have submitted your change, be patient and wait. If Linus
likes your change and applies it, it will appear in the next version
of the kernel that he releases.
However, if your change doesn't appear in the next version of the
kernel, there could be any number of reasons. It's YOUR job to
narrow down those reasons, correct what was wrong, and submit your
updated change.
It is quite common for Linus to "drop" your patch without comment.
That's the nature of the system. If he drops your patch, it could be
due to
* Your patch did not apply cleanly to the latest kernel version.
* Your patch was not sufficiently discussed on linux-kernel.
* A style issue (see section 2).
* An e-mail formatting issue (re-read this section).
* A technical problem with your change.
* He gets tons of e-mail, and yours got lost in the shuffle.
* You are being annoying.
When in doubt, solicit comments on linux-kernel mailing list.
11) Include PATCH in the subject
10) Include PATCH in the subject
--------------------------------
Due to high e-mail traffic to Linus, and to linux-kernel, it is common
convention to prefix your subject line with [PATCH]. This lets Linus
@ -355,7 +404,8 @@ e-mail discussions.
12) Sign your work
11) Sign your work
------------------
To improve tracking of who did what, especially with patches that can
percolate to their final resting place in the kernel through several
@ -387,11 +437,11 @@ can certify the below:
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
then you just add a line saying
@ -401,7 +451,7 @@ using your real name (sorry, no pseudonyms or anonymous contributions.)
Some people also put extra tags at the end. They'll just be ignored for
now, but you can do this to mark internal company procedures or just
point out some special detail about the sign-off.
point out some special detail about the sign-off.
If you are a subsystem or branch maintainer, sometimes you need to slightly
modify patches you receive in order to merge them, because the code is not
@ -429,15 +479,15 @@ which appears in the changelog.
Special note to back-porters: It seems to be a common and useful practice
to insert an indication of the origin of a patch at the top of the commit
message (just after the subject line) to facilitate tracking. For instance,
here's what we see in 2.6-stable :
here's what we see in a 3.x-stable release:
Date: Tue May 13 19:10:30 2008 +0000
Date: Tue Oct 7 07:26:38 2014 -0400
SCSI: libiscsi regression in 2.6.25: fix nop timer handling
libata: Un-break ATA blacklist
commit 4cf1043593db6a337f10e006c23c69e5fc93e722 upstream
commit 1c40279960bcd7d52dbdf1d466b20d24b99176c8 upstream.
And here's what appears in 2.4 :
And here's what might appear in an older kernel once a patch is backported:
Date: Tue May 13 22:12:27 2008 +0200
@ -446,18 +496,19 @@ And here's what appears in 2.4 :
[backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]
Whatever the format, this information provides a valuable help to people
tracking your trees, and to people trying to trouble-shoot bugs in your
tracking your trees, and to people trying to troubleshoot bugs in your
tree.
13) When to use Acked-by: and Cc:
12) When to use Acked-by: and Cc:
---------------------------------
The Signed-off-by: tag indicates that the signer was involved in the
development of the patch, or that he/she was in the patch's delivery path.
If a person was not directly involved in the preparation or handling of a
patch but wishes to signify and record their approval of it then they can
arrange to have an Acked-by: line added to the patch's changelog.
ask to have an Acked-by: line added to the patch's changelog.
Acked-by: is often used by the maintainer of the affected code when that
maintainer neither contributed to nor forwarded the patch.
@ -465,7 +516,8 @@ maintainer neither contributed to nor forwarded the patch.
Acked-by: is not as formal as Signed-off-by:. It is a record that the acker
has at least reviewed the patch and has indicated acceptance. Hence patch
mergers will sometimes manually convert an acker's "yep, looks good to me"
into an Acked-by:.
into an Acked-by: (but note that it is usually better to ask for an
explicit ack).
Acked-by: does not necessarily indicate acknowledgement of the entire patch.
For example, if a patch affects multiple subsystems and has an Acked-by: from
@ -477,11 +529,13 @@ list archives.
If a person has had the opportunity to comment on a patch, but has not
provided such comments, you may optionally add a "Cc:" tag to the patch.
This is the only tag which might be added without an explicit action by the
person it names. This tag documents that potentially interested parties
have been included in the discussion
person it names - but it should indicate that this person was copied on the
patch. This tag documents that potentially interested parties
have been included in the discussion.
14) Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes:
13) Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes:
--------------------------------------------------------------------------
The Reported-by tag gives credit to people who find bugs and report them and it
hopefully inspires them to help us again in the future. Please note that if
@ -541,7 +595,13 @@ which stable kernel versions should receive your fix. This is the preferred
method for indicating a bug fixed by the patch. See #2 above for more details.
15) The canonical patch format
14) The canonical patch format
------------------------------
This section describes how the patch itself should be formatted. Note
that, if you have your patches stored in a git repository, proper patch
formatting can be had with "git format-patch". The tools cannot create
the necessary text, though, so read the instructions below anyway.
The canonical patch subject line is:
@ -549,7 +609,8 @@ The canonical patch subject line is:
The canonical patch message body contains the following:
- A "from" line specifying the patch author.
- A "from" line specifying the patch author (only needed if the person
sending the patch is not the author).
- An empty line.
@ -656,128 +717,63 @@ See more details on the proper patch format in the following
references.
16) Sending "git pull" requests (from Linus emails)
15) Sending "git pull" requests
-------------------------------
Please write the git repo address and branch name alone on the same line
so that I can't even by mistake pull from the wrong branch, and so
that a triple-click just selects the whole thing.
If you have a series of patches, it may be most convenient to have the
maintainer pull them directly into the subsystem repository with a
"git pull" operation. Note, however, that pulling patches from a developer
requires a higher degree of trust than taking patches from a mailing list.
As a result, many subsystem maintainers are reluctant to take pull
requests, especially from new, unknown developers. If in doubt you can use
the pull request as the cover letter for a normal posting of the patch
series, giving the maintainer the option of using either.
So the proper format is something along the lines of:
A pull request should have [GIT] or [PULL] in the subject line. The
request itself should include the repository name and the branch of
interest on a single line; it should look something like:
"Please pull from
Please pull from
git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
to get these changes:"
to get these changes:"
so that I don't have to hunt-and-peck for the address and inevitably
get it wrong (actually, I've only gotten it wrong a few times, and
checking against the diffstat tells me when I get it wrong, but I'm
just a lot more comfortable when I don't have to "look for" the right
thing to pull, and double-check that I have the right branch-name).
A pull request should also include an overall message saying what will be
included in the request, a "git shortlog" listing of the patches
themselves, and a diffstat showing the overall effect of the patch series.
The easiest way to get all this information together is, of course, to let
git do it for you with the "git request-pull" command.
Some maintainers (including Linus) want to see pull requests from signed
commits; that increases their confidence that the request actually came
from you. Linus, in particular, will not pull from public hosting sites
like GitHub in the absence of a signed tag.
Please use "git diff -M --stat --summary" to generate the diffstat:
the -M enables rename detection, and the summary enables a summary of
new/deleted or renamed files.
The first step toward creating such tags is to make a GNUPG key and get it
signed by one or more core kernel developers. This step can be hard for
new developers, but there is no way around it. Attending conferences can
be a good way to find developers who can sign your key.
With rename detection, the statistics are rather different [...]
because git will notice that a fair number of the changes are renames.
Once you have prepared a patch series in git that you wish to have somebody
pull, create a signed tag with "git tag -s". This will create a new tag
identifying the last commit in the series and containing a signature
created with your private key. You will also have the opportunity to add a
changelog-style message to the tag; this is an ideal place to describe the
effects of the pull request as a whole.
-----------------------------------
SECTION 2 - HINTS, TIPS, AND TRICKS
-----------------------------------
If the tree the maintainer will be pulling from is not the repository you
are working from, don't forget to push the signed tag explicitly to the
public tree.
This section lists many of the common "rules" associated with code
submitted to the kernel. There are always exceptions... but you must
have a really good reason for doing so. You could probably call this
section Linus Computer Science 101.
1) Read Documentation/CodingStyle
Nuff said. If your code deviates too much from this, it is likely
to be rejected without further review, and without comment.
One significant exception is when moving code from one file to
another -- in this case you should not modify the moved code at all in
the same patch which moves it. This clearly delineates the act of
moving the code and your changes. This greatly aids review of the
actual differences and allows tools to better track the history of
the code itself.
Check your patches with the patch style checker prior to submission
(scripts/checkpatch.pl). The style checker should be viewed as
a guide not as the final word. If your code looks better with
a violation then its probably best left alone.
The checker reports at three levels:
- ERROR: things that are very likely to be wrong
- WARNING: things requiring careful review
- CHECK: things requiring thought
You should be able to justify all violations that remain in your
patch.
2) #ifdefs are ugly
Code cluttered with ifdefs is difficult to read and maintain. Don't do
it. Instead, put your ifdefs in a header, and conditionally define
'static inline' functions, or macros, which are used in the code.
Let the compiler optimize away the "no-op" case.
Simple example, of poor code:
dev = alloc_etherdev (sizeof(struct funky_private));
if (!dev)
return -ENODEV;
#ifdef CONFIG_NET_FUNKINESS
init_funky_net(dev);
#endif
Cleaned-up example:
(in header)
#ifndef CONFIG_NET_FUNKINESS
static inline void init_funky_net (struct net_device *d) {}
#endif
(in the code itself)
dev = alloc_etherdev (sizeof(struct funky_private));
if (!dev)
return -ENODEV;
init_funky_net(dev);
3) 'static inline' is better than a macro
Static inline functions are greatly preferred over macros.
They provide type safety, have no length limitations, no formatting
limitations, and under gcc they are as cheap as macros.
Macros should only be used for cases where a static inline is clearly
suboptimal [there are a few, isolated cases of this in fast paths],
or where it is impossible to use a static inline function [such as
string-izing].
'static inline' is preferred over 'static __inline__', 'extern inline',
and 'extern __inline__'.
4) Don't over-design.
Don't try to anticipate nebulous future cases which may or may not
be useful: "Make it as simple as you can, and no simpler."
When generating your pull request, use the signed tag as the target. A
command like this will do the trick:
git request-pull master git://my.public.tree/linux.git my-signed-tag
----------------------
SECTION 3 - REFERENCES
SECTION 2 - REFERENCES
----------------------
Andrew Morton, "The perfect patch" (tpp).

12
Documentation/arm/00-INDEX
View File

@ -2,11 +2,15 @@
- this file
Booting
- requirements for booting
CCN.txt
- Cache Coherent Network ring-bus and perf PMU driver.
Interrupts
- ARM Interrupt subsystem documentation
IXP4xx
- Intel IXP4xx Network processor.
msm
Makefile
- Build sourcefiles as part of the Documentation-build for arm
msm/
- MSM specific documentation
Netwinder
- Netwinder specific documentation
@ -18,11 +22,9 @@ README
- General ARM documentation
SA1100/
- SA1100 documentation
Samsung-S3C24XX
Samsung-S3C24XX/
- S3C24XX ARM Linux Overview
Sharp-LH
- Linux on Sharp LH79524 and LH7A40X System On a Chip (SOC)
SPEAr
SPEAr/
- ST SPEAr platform Linux Overview
VFP/
- Release notes for Linux Kernel Vector Floating Point support code

124
Documentation/arm/Atmel/README Normal file
View File

@ -0,0 +1,124 @@
ARM Atmel SoCs (aka AT91)
=========================
Introduction
------------
This document gives useful information about the ARM Atmel SoCs that are
currently supported in Linux Mainline (you know, the one on kernel.org).
It is important to note that the Atmel | SMART ARM-based MPU product line is
historically named "AT91" or "at91" throughout the Linux kernel development
process even if this product prefix has completely disappeared from the
official Atmel product name. Anyway, files, directories, git trees,
git branches/tags and email subject always contain this "at91" sub-string.
AT91 SoCs
---------
Documentation and detailled datasheet for each product are available on
the Atmel website: http://www.atmel.com.
Flavors:
* ARM 920 based SoC
- at91rm9200
+ Datasheet
http://www.atmel.com/Images/doc1768.pdf
* ARM 926 based SoCs
- at91sam9260
+ Datasheet
http://www.atmel.com/Images/doc6221.pdf
- at91sam9xe
+ Datasheet
http://www.atmel.com/Images/Atmel-6254-32-bit-ARM926EJ-S-Embedded-Microprocessor-SAM9XE_Datasheet.pdf
- at91sam9261
+ Datasheet
http://www.atmel.com/Images/doc6062.pdf
- at91sam9263
+ Datasheet
http://www.atmel.com/Images/Atmel_6249_32-bit-ARM926EJ-S-Microcontroller_SAM9263_Datasheet.pdf
- at91sam9rl
+ Datasheet
http://www.atmel.com/Images/doc6289.pdf
- at91sam9g20
+ Datasheet
http://www.atmel.com/Images/doc6384.pdf
- at91sam9g45 family
- at91sam9g45
- at91sam9g46
- at91sam9m10
- at91sam9m11 (device superset)
+ Datasheet
http://www.atmel.com/Images/Atmel-6437-32-bit-ARM926-Embedded-Microprocessor-SAM9M11_Datasheet.pdf
- at91sam9x5 family (aka "The 5 series")
- at91sam9g15
- at91sam9g25
- at91sam9g35
- at91sam9x25
- at91sam9x35
+ Datasheet (can be considered as covering the whole family)
http://www.atmel.com/Images/Atmel_11055_32-bit-ARM926EJ-S-Microcontroller_SAM9X35_Datasheet.pdf
- at91sam9n12
+ Datasheet
http://www.atmel.com/Images/Atmel_11063_32-bit-ARM926EJ-S-Microcontroller_SAM9N12CN11CN12_Datasheet.pdf
* ARM Cortex-A5 based SoCs
- sama5d3 family
- sama5d31
- sama5d33
- sama5d34
- sama5d35
- sama5d36 (device superset)
+ Datasheet
http://www.atmel.com/Images/Atmel-11121-32-bit-Cortex-A5-Microcontroller-SAMA5D3_Datasheet.pdf
* ARM Cortex-A5 + NEON based SoCs
- sama5d4 family
- sama5d41
- sama5d42
- sama5d43
- sama5d44 (device superset)
+ Datasheet
http://www.atmel.com/Images/Atmel-11238-32-bit-Cortex-A5-Microcontroller-SAMA5D4_Datasheet.pdf
Linux kernel information
------------------------
Linux kernel mach directory: arch/arm/mach-at91
MAINTAINERS entry is: "ARM/ATMEL AT91RM9200 AND AT91SAM ARM ARCHITECTURES"
Device Tree for AT91 SoCs and boards
------------------------------------
All AT91 SoCs are converted to Device Tree. Since Linux 3.19, these products
must use this method to boot the Linux kernel.
Work In Progress statement:
Device Tree files and Device Tree bindings that apply to AT91 SoCs and boards are
considered as "Unstable". To be completely clear, any at91 binding can change at
any time. So, be sure to use a Device Tree Binary and a Kernel Image generated from
the same source tree.
Please refer to the Documentation/devicetree/bindings/ABI.txt file for a
definition of a "Stable" binding/ABI.
This statement will be removed by AT91 MAINTAINERS when appropriate.
Naming conventions and best practice:
- SoCs Device Tree Source Include files are named after the official name of
the product (at91sam9g20.dtsi or sama5d33.dtsi for instance).
- Device Tree Source Include files (.dtsi) are used to collect common nodes that can be
shared across SoCs or boards (sama5d3.dtsi or at91sam9x5cm.dtsi for instance).
When collecting nodes for a particular peripheral or topic, the identifier have to
be placed at the end of the file name, separated with a "_" (at91sam9x5_can.dtsi
or sama5d3_gmac.dtsi for example).
- board Device Tree Source files (.dts) are prefixed by the string "at91-" so
that they can be identified easily. Note that some files are historical exceptions
to this rule (sama5d3[13456]ek.dts, usb_a9g20.dts or animeo_ip.dts for example).

46
Documentation/arm/Samsung-S3C24XX/DMA.txt
View File

@ -1,46 +0,0 @@
S3C2410 DMA
===========
Introduction
------------
The kernel provides an interface to manage DMA transfers
using the DMA channels in the CPU, so that the central
duty of managing channel mappings, and programming the
channel generators is in one place.
DMA Channel Ordering
--------------------
Many of the range do not have connections for the DMA
channels to all sources, which means that some devices
have a restricted number of channels that can be used.
To allow flexibility for each CPU type and board, the
DMA code can be given a DMA ordering structure which
allows the order of channel search to be specified, as
well as allowing the prohibition of certain claims.
struct s3c24xx_dma_order has a list of channels, and
each channel within has a slot for a list of DMA
channel numbers. The slots are searched in order for
the presence of a DMA channel number with DMA_CH_VALID
or-ed in.
If the order has the flag DMA_CH_NEVER set, then after
checking the channel list, the system will return no
found channel, thus denying the request.
A board support file can call s3c24xx_dma_order_set()
to register a complete ordering set. The routine will
copy the data, so the original can be discarded with
__initdata.
Authour
-------
Ben Dooks,
Copyright (c) 2007 Ben Dooks, Simtec Electronics
Licensed under the GPL v2

20
Documentation/arm/sti/stih418-overview.txt Normal file
View File

@ -0,0 +1,20 @@
STiH418 Overview
================
Introduction
------------
The STiH418 is the new generation of SoC for UHDp60 set-top boxes
and server/connected client application for satellite, cable, terrestrial
and IP-STB markets.
Features
- ARM Cortex-A9 1.5 GHz quad core CPU (28nm)
- SATA2, USB 3.0, PCIe, Gbit Ethernet
- HEVC L5.1 Main 10
- VP9
Document Author
---------------
Maxime Coquelin <maxime.coquelin@st.com>, (c) 2015 ST Microelectronics

1
Documentation/arm/sunxi/README
View File

@ -50,7 +50,6 @@ SunXi family
http://dl.linux-sunxi.org/A31/A3x_release_document/A31/IC/A31%20user%20manual%20V1.1%2020130630.pdf
- Allwinner A31s (sun6i)
+ Not Supported
+ Datasheet
http://dl.linux-sunxi.org/A31/A3x_release_document/A31s/IC/A31s%20datasheet%20V1.3%2020131106.pdf
+ User Manual

12
Documentation/arm64/legacy_instructions.txt
View File

@ -32,6 +32,9 @@ The default mode depends on the status of the instruction in the
architecture. Deprecated instructions should default to emulation
while obsolete instructions must be undefined by default.
Note: Instruction emulation may not be possible in all cases. See
individual instruction notes for further information.
Supported legacy instructions
-----------------------------
* SWP{B}
@ -43,3 +46,12 @@ Default: Undef (0)
Node: /proc/sys/abi/cp15_barrier
Status: Deprecated
Default: Emulate (1)
* SETEND
Node: /proc/sys/abi/setend
Status: Deprecated
Default: Emulate (1)*
Note: All the cpus on the system must have mixed endian support at EL0
for this feature to be enabled. If a new CPU - which doesn't support mixed
endian - is hotplugged in after this feature has been enabled, there could
be unexpected results in the application.

2
Documentation/blackfin/Makefile
View File

@ -1,3 +1,5 @@
ifneq ($(CONFIG_BLACKFIN),)
ifneq ($(CONFIG_BFIN_GPTIMERS,)
obj-m := gptimers-example.o
endif
endif

79
Documentation/cgroups/unified-hierarchy.txt
View File

@ -327,6 +327,85 @@ supported and the interface files "release_agent" and
- use_hierarchy is on by default and the cgroup file for the flag is
not created.
- The original lower boundary, the soft limit, is defined as a limit
that is per default unset. As a result, the set of cgroups that
global reclaim prefers is opt-in, rather than opt-out. The costs
for optimizing these mostly negative lookups are so high that the
implementation, despite its enormous size, does not even provide the
basic desirable behavior. First off, the soft limit has no
hierarchical meaning. All configured groups are organized in a
global rbtree and treated like equal peers, regardless where they
are located in the hierarchy. This makes subtree delegation
impossible. Second, the soft limit reclaim pass is so aggressive
that it not just introduces high allocation latencies into the
system, but also impacts system performance due to overreclaim, to
the point where the feature becomes self-defeating.
The memory.low boundary on the other hand is a top-down allocated
reserve. A cgroup enjoys reclaim protection when it and all its
ancestors are below their low boundaries, which makes delegation of
subtrees possible. Secondly, new cgroups have no reserve per
default and in the common case most cgroups are eligible for the
preferred reclaim pass. This allows the new low boundary to be
efficiently implemented with just a minor addition to the generic
reclaim code, without the need for out-of-band data structures and
reclaim passes. Because the generic reclaim code considers all
cgroups except for the ones running low in the preferred first
reclaim pass, overreclaim of individual groups is eliminated as
well, resulting in much better overall workload performance.
- The original high boundary, the hard limit, is defined as a strict
limit that can not budge, even if the OOM killer has to be called.
But this generally goes against the goal of making the most out of
the available memory. The memory consumption of workloads varies
during runtime, and that requires users to overcommit. But doing
that with a strict upper limit requires either a fairly accurate
prediction of the working set size or adding slack to the limit.
Since working set size estimation is hard and error prone, and
getting it wrong results in OOM kills, most users tend to err on the
side of a looser limit and end up wasting precious resources.
The memory.high boundary on the other hand can be set much more
conservatively. When hit, it throttles allocations by forcing them
into direct reclaim to work off the excess, but it never invokes the
OOM killer. As a result, a high boundary that is chosen too
aggressively will not terminate the processes, but instead it will
lead to gradual performance degradation. The user can monitor this
and make corrections until the minimal memory footprint that still
gives acceptable performance is found.
In extreme cases, with many concurrent allocations and a complete
breakdown of reclaim progress within the group, the high boundary
can be exceeded. But even then it's mostly better to satisfy the
allocation from the slack available in other groups or the rest of
the system than killing the group. Otherwise, memory.max is there
to limit this type of spillover and ultimately contain buggy or even
malicious applications.
- The original control file names are unwieldy and inconsistent in
many different ways. For example, the upper boundary hit count is
exported in the memory.failcnt file, but an OOM event count has to
be manually counted by listening to memory.oom_control events, and
lower boundary / soft limit events have to be counted by first
setting a threshold for that value and then counting those events.
Also, usage and limit files encode their units in the filename.
That makes the filenames very long, even though this is not
information that a user needs to be reminded of every time they type
out those names.
To address these naming issues, as well as to signal clearly that
the new interface carries a new configuration model, the naming
conventions in it necessarily differ from the old interface.
- The original limit files indicate the state of an unset limit with a
Very High Number, and a configured limit can be unset by echoing -1
into those files. But that very high number is implementation and
architecture dependent and not very descriptive. And while -1 can
be understood as an underflow into the highest possible value, -2 or
-10M etc. do not work, so it's not consistent.
memory.low, memory.high, and memory.max will use the string
"infinity" to indicate and set the highest possible value.
5. Planned Changes

2
Documentation/clk.txt
View File

@ -73,6 +73,8 @@ the operations defined in clk.h:
unsigned long *parent_rate);
long (*determine_rate)(struct clk_hw *hw,
unsigned long rate,
unsigned long min_rate,
unsigned long max_rate,
unsigned long *best_parent_rate,
struct clk_hw **best_parent_clk);
int (*set_parent)(struct clk_hw *hw, u8 index);

15
Documentation/device-mapper/dm-crypt.txt
View File

@ -51,7 +51,7 @@ Parameters: <cipher> <key> <iv_offset> <device path> \
Otherwise #opt_params is the number of following arguments.
Example of optional parameters section:
1 allow_discards
3 allow_discards same_cpu_crypt submit_from_crypt_cpus
allow_discards
Block discard requests (a.k.a. TRIM) are passed through the crypt device.
@ -63,6 +63,19 @@ allow_discards
used space etc.) if the discarded blocks can be located easily on the
device later.
same_cpu_crypt
Perform encryption using the same cpu that IO was submitted on.
The default is to use an unbound workqueue so that encryption work
is automatically balanced between available CPUs.
submit_from_crypt_cpus
Disable offloading writes to a separate thread after encryption.
There are some situations where offloading write bios from the
encryption threads to a single thread degrades performance
significantly. The default is to offload write bios to the same
thread because it benefits CFQ to have writes submitted using the
same context.
Example scripts
===============
LUKS (Linux Unified Key Setup) is now the preferred way to set up disk

7
Documentation/devicetree/bindings/arm/armada-38x.txt
View File

@ -15,6 +15,13 @@ Required root node property:
compatible: must contain "marvell,armada385"
In addition, boards using the Marvell Armada 388 SoC shall have the
following property before the previous one:
Required root node property:
compatible: must contain "marvell,armada388"
Example:
compatible = "marvell,a385-rd", "marvell,armada385", "marvell,armada380";

17
Documentation/devicetree/bindings/arm/atmel-at91.txt
View File

@ -24,6 +24,7 @@ compatible: must be one of:
o "atmel,at91sam9g45"
o "atmel,at91sam9n12"
o "atmel,at91sam9rl"
o "atmel,at91sam9xe"
* "atmel,sama5" for SoCs using a Cortex-A5, shall be extended with the specific
SoC family:
o "atmel,sama5d3" shall be extended with the specific SoC compatible:
@ -136,3 +137,19 @@ Example:
compatible = "atmel,at91sam9260-rstc";
reg = <0xfffffd00 0x10>;
};
Special Function Registers (SFR)
Special Function Registers (SFR) manage specific aspects of the integrated
memory, bridge implementations, processor and other functionality not controlled
elsewhere.
required properties:
- compatible: Should be "atmel,<chip>-sfr", "syscon".
<chip> can be "sama5d3" or "sama5d4".
- reg: Should contain registers location and length
sfr@f0038000 {
compatible = "atmel,sama5d3-sfr", "syscon";
reg = <0xf0038000 0x60>;
};

4
Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
View File

@ -79,7 +79,9 @@ reboot
Required properties
- compatible
The string property "brcm,brcmstb-reboot".
The string property "brcm,brcmstb-reboot" for 40nm/28nm chips with
the new SYS_CTRL interface, or "brcm,bcm7038-reboot" for 65nm
chips with the old SUN_TOP_CTRL interface.
- syscon
A phandle / integer array that points to the syscon node which describes

4
Documentation/devicetree/bindings/arm/coresight.txt
View File

@ -38,8 +38,6 @@ its hardware characteristcs.
AMBA markee):
- "arm,coresight-replicator"
* id: a unique number that will identify this replicator.
* port or ports: same as above.
* Optional properties for ETM/PTMs:
@ -94,8 +92,6 @@ Example:
* AMBA bus. As such no need to add "arm,primecell".
*/
compatible = "arm,coresight-replicator";
/* this will show up in debugfs as "0.replicator" */
id = <0>;
ports {
#address-cells = <1>;

1
Documentation/devicetree/bindings/arm/cpus.txt
View File

@ -175,6 +175,7 @@ nodes to be present and contain the properties described below.
"marvell,pj4a"
"marvell,pj4b"
"marvell,sheeva-v5"
"nvidia,tegra132-denver"
"qcom,krait"
"qcom,scorpion"
- enable-method

6
Documentation/devicetree/bindings/arm/digicolor.txt Normal file
View File

@ -0,0 +1,6 @@
Conexant Digicolor Platforms Device Tree Bindings
Each device tree must specify which Conexant Digicolor SoC it uses.
Must be the following compatible string:
cnxt,cx92755

2
Documentation/devicetree/bindings/arm/exynos/power_domain.txt
View File

@ -23,7 +23,7 @@ Optional Properties:
devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
are supported currently.
Node of a device using power domains must have a samsung,power-domain property
Node of a device using power domains must have a power-domains property
defined with a phandle to respective power domain.
Example:

20
Documentation/devicetree/bindings/arm/fsl.txt
View File

@ -75,6 +75,18 @@ i.MX6q generic board
Required root node properties:
- compatible = "fsl,imx6q";
Freescale Vybrid Platform Device Tree Bindings
----------------------------------------------
For the Vybrid SoC familiy all variants with DDR controller are supported,
which is the VF5xx and VF6xx series. Out of historical reasons, in most
places the kernel uses vf610 to refer to the whole familiy.
Required root node compatible property (one of them):
- compatible = "fsl,vf500";
- compatible = "fsl,vf510";
- compatible = "fsl,vf600";
- compatible = "fsl,vf610";
Freescale LS1021A Platform Device Tree Bindings
------------------------------------------------
@ -112,3 +124,11 @@ Example:
compatible = "fsl,ls1021a-dcfg";
reg = <0x0 0x1ee0000 0x0 0x10000>;
};
Freescale LS2085A SoC Device Tree Bindings
------------------------------------------
LS2085A ARMv8 based Simulator model
Required root node properties:
- compatible = "fsl,ls2085a-simu", "fsl,ls2085a";

8
Documentation/devicetree/bindings/arm/gic.txt
View File

@ -32,12 +32,16 @@ Main node required properties:
The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = low-to-high edge triggered
2 = high-to-low edge triggered
2 = high-to-low edge triggered (invalid for SPIs)
4 = active high level-sensitive
8 = active low level-sensitive
8 = active low level-sensitive (invalid for SPIs).
bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
the 8 possible cpus attached to the GIC. A bit set to '1' indicated
the interrupt is wired to that CPU. Only valid for PPI interrupts.
Also note that the configurability of PPI interrupts is IMPLEMENTATION
DEFINED and as such not guaranteed to be present (most SoC available
in 2014 seem to ignore the setting of this flag and use the hardware
default value).
- reg : Specifies base physical address(s) and size of the GIC registers. The
first region is the GIC distributor register base and size. The 2nd region is

25
Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
View File

@ -9,6 +9,10 @@ HiP04 D01 Board
Required root node properties:
- compatible = "hisilicon,hip04-d01";
HiP01 ca9x2 Board
Required root node properties:
- compatible = "hisilicon,hip01-ca9x2";
Hisilicon system controller
@ -36,6 +40,27 @@ Example:
reboot-offset = <0x4>;
};
-----------------------------------------------------------------------
Hisilicon HiP01 system controller
Required properties:
- compatible : "hisilicon,hip01-sysctrl"
- reg : Register address and size
The HiP01 system controller is mostly compatible with hisilicon
system controller,but it has some specific control registers for
HIP01 SoC family, such as slave core boot, and also some same
registers located at different offset.
Example:
/* for hip01-ca9x2 */
sysctrl: system-controller@10000000 {
compatible = "hisilicon,hip01-sysctrl", "hisilicon,sysctrl";
reg = <0x10000000 0x1000>;
reboot-offset = <0x4>;
};
-----------------------------------------------------------------------
Hisilicon CPU controller

10
Documentation/devicetree/bindings/arm/l2cc.txt
View File

@ -57,6 +57,16 @@ Optional properties:
- cache-id-part: cache id part number to be used if it is not present
on hardware
- wt-override: If present then L2 is forced to Write through mode
- arm,double-linefill : Override double linefill enable setting. Enable if
non-zero, disable if zero.
- arm,double-linefill-incr : Override double linefill on INCR read. Enable
if non-zero, disable if zero.
- arm,double-linefill-wrap : Override double linefill on WRAP read. Enable
if non-zero, disable if zero.
- arm,prefetch-drop : Override prefetch drop enable setting. Enable if non-zero,
disable if zero.
- arm,prefetch-offset : Override prefetch offset value. Valid values are
0-7, 15, 23, and 31.
Example:

4
Documentation/devicetree/bindings/arm/mediatek.txt
View File

@ -9,6 +9,7 @@ compatible: Must contain one of
"mediatek,mt6592"
"mediatek,mt8127"
"mediatek,mt8135"
"mediatek,mt8173"
Supported boards:
@ -25,3 +26,6 @@ Supported boards:
- MTK mt8135 tablet EVB:
Required root node properties:
- compatible = "mediatek,mt8135-evbp1", "mediatek,mt8135";
- MTK mt8173 tablet EVB:
Required root node properties:
- compatible = "mediatek,mt8173-evb", "mediatek,mt8173";

2
Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt
View File

@ -5,8 +5,10 @@ interrupt.
Required properties:
- compatible: should be one of:
"mediatek,mt8173-sysirq"
"mediatek,mt8135-sysirq"
"mediatek,mt8127-sysirq"
"mediatek,mt6592-sysirq"
"mediatek,mt6589-sysirq"
"mediatek,mt6582-sysirq"
"mediatek,mt6577-sysirq"

2
Documentation/devicetree/bindings/arm/msm/timer.txt
View File

@ -8,7 +8,7 @@ Properties:
"qcom,kpss-timer" - krait subsystem
"qcom,scss-timer" - scorpion subsystem
- interrupts : Interrupts for the the debug timer, the first general purpose
- interrupts : Interrupts for the debug timer, the first general purpose
timer, and optionally a second general purpose timer in that
order.

10
Documentation/devicetree/bindings/arm/rockchip.txt
View File

@ -9,6 +9,16 @@ Rockchip platforms device tree bindings
Required root node properties:
- compatible = "mundoreader,bq-curie2", "rockchip,rk3066a";
- ChipSPARK Rayeager PX2 board:
Required root node properties:
- compatible = "chipspark,rayeager-px2", "rockchip,rk3066a";
- Radxa Rock board:
Required root node properties:
- compatible = "radxa,rock", "rockchip,rk3188";
- Firefly Firefly-RK3288 board:
Required root node properties:
- compatible = "firefly,firefly-rk3288", "rockchip,rk3288";
or
- compatible = "firefly,firefly-rk3288-beta", "rockchip,rk3288";

16
Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt Normal file
View File

@ -0,0 +1,16 @@
Rockchip SRAM for pmu:
------------------------------
The sram of pmu is used to store the function of resume from maskrom(the 1st
level loader). This is a common use of the "pmu-sram" because it keeps power
even in low power states in the system.
Required node properties:
- compatible : should be "rockchip,rk3288-pmu-sram"
- reg : physical base address and the size of the registers window
Example:
sram@ff720000 {
compatible = "rockchip,rk3288-pmu-sram", "mmio-sram";
reg = <0xff720000 0x1000>;
};

12
Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt Normal file
View File

@ -0,0 +1,12 @@
SAMSUNG Exynos SoCs Chipid driver.
Required properties:
- compatible : Should at least contain "samsung,exynos4210-chipid".
- reg: offset and length of the register set
Example:
chipid@10000000 {
compatible = "samsung,exynos4210-chipid";
reg = <0x10000000 0x100>;
};

1
Documentation/devicetree/bindings/arm/samsung/pmu.txt
View File

@ -10,6 +10,7 @@ Properties:
- "samsung,exynos5260-pmu" - for Exynos5260 SoC.
- "samsung,exynos5410-pmu" - for Exynos5410 SoC,
- "samsung,exynos5420-pmu" - for Exynos5420 SoC.
- "samsung,exynos7-pmu" - for Exynos7 SoC.
second value must be always "syscon".
- reg : offset and length of the register set.

6
Documentation/devicetree/bindings/arm/sirf.txt
View File

@ -3,7 +3,9 @@ CSR SiRFprimaII and SiRFmarco device tree bindings.
Required root node properties:
- compatible:
- "sirf,atlas6-cb" : atlas6 "cb" evaluation board
- "sirf,atlas6" : atlas6 device based board
- "sirf,atlas7-cb" : atlas7 "cb" evaluation board
- "sirf,atlas7" : atlas7 device based board
- "sirf,prima2-cb" : prima2 "cb" evaluation board
- "sirf,marco-cb" : marco "cb" evaluation board
- "sirf,prima2" : prima2 device based board
- "sirf,marco" : marco device based board

11
Documentation/devicetree/bindings/arm/sprd.txt Normal file
View File

@ -0,0 +1,11 @@
Spreadtrum SoC Platforms Device Tree Bindings
----------------------------------------------------
Sharkl64 is a Spreadtrum's SoC Platform which is based
on ARM 64-bit processor.
SC9836 openphone board with SC9836 SoC based on the
Sharkl64 Platform shall have the following properties.
Required root node properties:
- compatible = "sprd,sc9836-openphone", "sprd,sc9836";

4
Documentation/devicetree/bindings/arm/sti.txt
View File

@ -13,3 +13,7 @@ Boards with the ST STiH407 SoC shall have the following properties:
Required root node property:
compatible = "st,stih407";
Boards with the ST STiH418 SoC shall have the following properties:
Required root node property:
compatible = "st,stih418";

5
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt
View File

@ -1,7 +1,10 @@
NVIDIA Tegra AHB
Required properties:
- compatible : "nvidia,tegra20-ahb" or "nvidia,tegra30-ahb"
- compatible : For Tegra20, must contain "nvidia,tegra20-ahb". For
Tegra30, must contain "nvidia,tegra30-ahb". Otherwise, must contain
'"nvidia,<chip>-ahb", "nvidia,tegra30-ahb"' where <chip> is tegra124,
tegra132, or tegra210.
- reg : Should contain 1 register ranges(address and length)
Example:

32
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
View File

@ -6,7 +6,11 @@ modes. It provides power-gating controllers for SoC and CPU power-islands.
Required properties:
- name : Should be pmc
- compatible : Should contain "nvidia,tegra<chip>-pmc".
- compatible : For Tegra20, must contain "nvidia,tegra20-pmc". For Tegra30,
must contain "nvidia,tegra30-pmc". For Tegra114, must contain
"nvidia,tegra114-pmc". For Tegra124, must contain "nvidia,tegra124-pmc".
Otherwise, must contain "nvidia,<chip>-pmc", plus at least one of the
above, where <chip> is tegra132.
- reg : Offset and length of the register set for the device
- clocks : Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
@ -47,6 +51,23 @@ Required properties when nvidia,suspend-mode=<0>:
sleep mode, the warm boot code will restore some PLLs, clocks and then
bring up CPU0 for resuming the system.
Hardware-triggered thermal reset:
On Tegra30, Tegra114 and Tegra124, if the 'i2c-thermtrip' subnode exists,
hardware-triggered thermal reset will be enabled.
Required properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'):
- nvidia,i2c-controller-id : ID of I2C controller to send poweroff command to. Valid values are
described in section 9.2.148 "APBDEV_PMC_SCRATCH53_0" of the
Tegra K1 Technical Reference Manual.
- nvidia,bus-addr : Bus address of the PMU on the I2C bus
- nvidia,reg-addr : I2C register address to write poweroff command to
- nvidia,reg-data : Poweroff command to write to PMU
Optional properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'):
- nvidia,pinmux-id : Pinmux used by the hardware when issuing poweroff command.
Defaults to 0. Valid values are described in section 12.5.2
"Pinmux Support" of the Tegra4 Technical Reference Manual.
Example:
/ SoC dts including file
@ -68,6 +89,15 @@ pmc@7000f400 {
/ Tegra board dts file
{
...
pmc@7000f400 {
i2c-thermtrip {
nvidia,i2c-controller-id = <4>;
nvidia,bus-addr = <0x40>;
nvidia,reg-addr = <0x36>;
nvidia,reg-data = <0x2>;
};
};
...
clocks {
compatible = "simple-bus";

10
Documentation/devicetree/bindings/arm/versatile-sysreg.txt Normal file
View File

@ -0,0 +1,10 @@
ARM Versatile system registers
--------------------------------------
This is a system control registers block, providing multiple low level
platform functions like board detection and identification, software
interrupt generation, MMC and NOR Flash control etc.
Required node properties:
- compatible value : = "arm,versatile-sysreg", "syscon"
- reg : physical base address and the size of the registers window

2
Documentation/devicetree/bindings/ata/cavium-compact-flash.txt
View File

@ -9,7 +9,7 @@ Properties:
Compatibility with many Cavium evaluation boards.
- reg: The base address of the the CF chip select banks. Depending on
- reg: The base address of the CF chip select banks. Depending on
the device configuration, there may be one or two banks.
- cavium,bus-width: The width of the connection to the CF devices. Valid

4
Documentation/devicetree/bindings/ata/tegra-sata.txt
View File

@ -1,7 +1,9 @@
Tegra124 SoC SATA AHCI controller
Required properties :
- compatible : "nvidia,tegra124-ahci".
- compatible : For Tegra124, must contain "nvidia,tegra124-ahci". Otherwise,
must contain '"nvidia,<chip>-ahci", "nvidia,tegra124-ahci"', where <chip>
is tegra132.
- reg : Should contain 2 entries:
- AHCI register set (SATA BAR5)
- SATA register set

4
Documentation/devicetree/bindings/bus/mvebu-mbus.txt
View File

@ -6,8 +6,8 @@ Required properties:
- compatible: Should be set to one of the following:
marvell,armada370-mbus
marvell,armadaxp-mbus
marvell,armada370-mbus
marvell,armadaxp-mbus
marvell,armada375-mbus
marvell,armada380-mbus
marvell,kirkwood-mbus
marvell,dove-mbus
marvell,orion5x-88f5281-mbus

2
Documentation/devicetree/bindings/c6x/dscr.txt
View File

@ -12,7 +12,7 @@ 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,
the DSCR block may provide registers which are used to reset peripherals,
provide device ID information, provide ethernet MAC addresses, as well as other
miscellaneous functions.

115
Documentation/devicetree/bindings/clock/alphascale,acc.txt Normal file
View File

@ -0,0 +1,115 @@
Alphascale Clock Controller
The ACC (Alphascale Clock Controller) is responsible of choising proper
clock source, setting deviders and clock gates.
Required properties for the ACC node:
- compatible: must be "alphascale,asm9260-clock-controller"
- reg: must contain the ACC register base and size
- #clock-cells : shall be set to 1.
Simple one-cell clock specifier format is used, where the only cell is used
as an index of the clock inside the provider.
It is encouraged to use dt-binding for clock index definitions. SoC specific
dt-binding should be included to the device tree descriptor. For example
Alphascale ASM9260:
#include <dt-bindings/clock/alphascale,asm9260.h>
This binding contains two types of clock providers:
_AHB_ - AHB gate;
_SYS_ - adjustable clock source. Not all peripheral have _SYS_ clock provider.
All clock specific details can be found in the SoC documentation.
CLKID_AHB_ROM 0
CLKID_AHB_RAM 1
CLKID_AHB_GPIO 2
CLKID_AHB_MAC 3
CLKID_AHB_EMI 4
CLKID_AHB_USB0 5
CLKID_AHB_USB1 6
CLKID_AHB_DMA0 7
CLKID_AHB_DMA1 8
CLKID_AHB_UART0 9
CLKID_AHB_UART1 10
CLKID_AHB_UART2 11
CLKID_AHB_UART3 12
CLKID_AHB_UART4 13
CLKID_AHB_UART5 14
CLKID_AHB_UART6 15
CLKID_AHB_UART7 16
CLKID_AHB_UART8 17
CLKID_AHB_UART9 18
CLKID_AHB_I2S0 19
CLKID_AHB_I2C0 20
CLKID_AHB_I2C1 21
CLKID_AHB_SSP0 22
CLKID_AHB_IOCONFIG 23
CLKID_AHB_WDT 24
CLKID_AHB_CAN0 25
CLKID_AHB_CAN1 26
CLKID_AHB_MPWM 27
CLKID_AHB_SPI0 28
CLKID_AHB_SPI1 29
CLKID_AHB_QEI 30
CLKID_AHB_QUADSPI0 31
CLKID_AHB_CAMIF 32
CLKID_AHB_LCDIF 33
CLKID_AHB_TIMER0 34
CLKID_AHB_TIMER1 35
CLKID_AHB_TIMER2 36
CLKID_AHB_TIMER3 37
CLKID_AHB_IRQ 38
CLKID_AHB_RTC 39
CLKID_AHB_NAND 40
CLKID_AHB_ADC0 41
CLKID_AHB_LED 42
CLKID_AHB_DAC0 43
CLKID_AHB_LCD 44
CLKID_AHB_I2S1 45
CLKID_AHB_MAC1 46
CLKID_SYS_CPU 47
CLKID_SYS_AHB 48
CLKID_SYS_I2S0M 49
CLKID_SYS_I2S0S 50
CLKID_SYS_I2S1M 51
CLKID_SYS_I2S1S 52
CLKID_SYS_UART0 53
CLKID_SYS_UART1 54
CLKID_SYS_UART2 55
CLKID_SYS_UART3 56
CLKID_SYS_UART4 56
CLKID_SYS_UART5 57
CLKID_SYS_UART6 58
CLKID_SYS_UART7 59
CLKID_SYS_UART8 60
CLKID_SYS_UART9 61
CLKID_SYS_SPI0 62
CLKID_SYS_SPI1 63
CLKID_SYS_QUADSPI 64
CLKID_SYS_SSP0 65
CLKID_SYS_NAND 66
CLKID_SYS_TRACE 67
CLKID_SYS_CAMM 68
CLKID_SYS_WDT 69
CLKID_SYS_CLKOUT 70
CLKID_SYS_MAC 71
CLKID_SYS_LCD 72
CLKID_SYS_ADCANA 73
Example of clock consumer with _SYS_ and _AHB_ sinks.
uart4: serial@80010000 {
compatible = "alphascale,asm9260-uart";
reg = <0x80010000 0x4000>;
clocks = <&acc CLKID_SYS_UART4>, <&acc CLKID_AHB_UART4>;
interrupts = <19>;
status = "disabled";
};
Clock consumer with only one, _AHB_ sink.
timer0: timer@80088000 {
compatible = "alphascale,asm9260-timer";
reg = <0x80088000 0x4000>;
clocks = <&acc CLKID_AHB_TIMER0>;
interrupts = <29>;
};

15
Documentation/devicetree/bindings/clock/exynos7-clock.txt
View File

@ -34,6 +34,8 @@ Required Properties for Clock Controller:
- "samsung,exynos7-clock-peris"
- "samsung,exynos7-clock-fsys0"
- "samsung,exynos7-clock-fsys1"
- "samsung,exynos7-clock-mscl"
- "samsung,exynos7-clock-aud"
- reg: physical base address of the controller and the length of
memory mapped region.
@ -53,6 +55,7 @@ Input clocks for top0 clock controller:
- dout_sclk_bus1_pll
- dout_sclk_cc_pll
- dout_sclk_mfc_pll
- dout_sclk_aud_pll
Input clocks for top1 clock controller:
- fin_pll
@ -76,6 +79,14 @@ Input clocks for peric1 clock controller:
- sclk_uart1
- sclk_uart2
- sclk_uart3
- sclk_spi0
- sclk_spi1
- sclk_spi2
- sclk_spi3
- sclk_spi4
- sclk_i2s1
- sclk_pcm1
- sclk_spdif
Input clocks for peris clock controller:
- fin_pll
@ -91,3 +102,7 @@ Input clocks for fsys1 clock controller:
- dout_aclk_fsys1_200
- dout_sclk_mmc0
- dout_sclk_mmc1
Input clocks for aud clock controller:
- fin_pll
- fout_aud_pll

10
Documentation/devicetree/bindings/clock/nvidia,tegra124-car.txt
View File

@ -1,4 +1,4 @@
NVIDIA Tegra124 Clock And Reset Controller
NVIDIA Tegra124 and Tegra132 Clock And Reset Controller
This binding uses the common clock binding:
Documentation/devicetree/bindings/clock/clock-bindings.txt
@ -7,14 +7,16 @@ The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
for muxing and gating Tegra's clocks, and setting their rates.
Required properties :
- compatible : Should be "nvidia,tegra124-car"
- compatible : Should be "nvidia,tegra124-car" or "nvidia,tegra132-car"
- reg : Should contain CAR registers location and length
- clocks : Should contain phandle and clock specifiers for two clocks:
the 32 KHz "32k_in", and the board-specific oscillator "osc".
- #clock-cells : Should be 1.
In clock consumers, this cell represents the clock ID exposed by the
CAR. The assignments may be found in header file
<dt-bindings/clock/tegra124-car.h>.
CAR. The assignments may be found in the header files
<dt-bindings/clock/tegra124-car-common.h> (which covers IDs common
to Tegra124 and Tegra132) and <dt-bindings/clock/tegra124-car.h>
(for Tegra124-specific clocks).
- #reset-cells : Should be 1.
In clock consumers, this cell represents the bit number in the CAR's
array of CLK_RST_CONTROLLER_RST_DEVICES_* registers.

21
Documentation/devicetree/bindings/clock/qcom,lcc.txt Normal file
View File

@ -0,0 +1,21 @@
Qualcomm LPASS Clock & Reset Controller Binding
------------------------------------------------
Required properties :
- compatible : shall contain only one of the following:
"qcom,lcc-msm8960"
"qcom,lcc-apq8064"
"qcom,lcc-ipq8064"
- reg : shall contain base register location and length
- #clock-cells : shall contain 1
- #reset-cells : shall contain 1
Example:
clock-controller@28000000 {
compatible = "qcom,lcc-ipq8064";
reg = <0x28000000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};

5
Documentation/devicetree/bindings/clock/qoriq-clock.txt
View File

@ -1,6 +1,6 @@
* Clock Block on Freescale CoreNet Platforms
* Clock Block on Freescale QorIQ Platforms
Freescale CoreNet chips take primary clocking input from the external
Freescale qoriq chips take primary clocking input from the external
SYSCLK signal. The SYSCLK input (frequency) is multiplied using
multiple phase locked loops (PLL) to create a variety of frequencies
which can then be passed to a variety of internal logic, including
@ -29,6 +29,7 @@ Required properties:
* "fsl,t4240-clockgen"
* "fsl,b4420-clockgen"
* "fsl,b4860-clockgen"
* "fsl,ls1021a-clockgen"
Chassis clock strings include:
* "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
* "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks

1
Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
View File

@ -11,6 +11,7 @@ Required Properties:
- compatible: Must be one of the following
- "renesas,r7s72100-mstp-clocks" for R7S72100 (RZ) MSTP gate clocks
- "renesas,r8a73a4-mstp-clocks" for R8A73A4 (R-Mobile APE6) MSTP gate clocks
- "renesas,r8a7740-mstp-clocks" for R8A7740 (R-Mobile A1) MSTP gate clocks
- "renesas,r8a7779-mstp-clocks" for R8A7779 (R-Car H1) MSTP gate clocks
- "renesas,r8a7790-mstp-clocks" for R8A7790 (R-Car H2) MSTP gate clocks

33
Documentation/devicetree/bindings/clock/renesas,r8a73a4-cpg-clocks.txt Normal file
View File

@ -0,0 +1,33 @@
* Renesas R8A73A4 Clock Pulse Generator (CPG)
The CPG generates core clocks for the R8A73A4 SoC. It includes five PLLs
and several fixed ratio dividers.
Required Properties:
- compatible: Must be "renesas,r8a73a4-cpg-clocks"
- reg: Base address and length of the memory resource used by the CPG
- clocks: Reference to the parent clocks ("extal1" and "extal2")
- #clock-cells: Must be 1
- clock-output-names: The names of the clocks. Supported clocks are "main",
"pll0", "pll1", "pll2", "pll2s", "pll2h", "z", "z2", "i", "m3", "b",
"m1", "m2", "zx", "zs", and "hp".
Example
-------
cpg_clocks: cpg_clocks@e6150000 {
compatible = "renesas,r8a73a4-cpg-clocks";
reg = <0 0xe6150000 0 0x10000>;
clocks = <&extal1_clk>, <&extal2_clk>;
#clock-cells = <1>;
clock-output-names = "main", "pll0", "pll1", "pll2",
"pll2s", "pll2h", "z", "z2",
"i", "m3", "b", "m1", "m2",
"zx", "zs", "hp";
};

12
Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
View File

@ -8,15 +8,18 @@ Required Properties:
- compatible: Must be one of
- "renesas,r8a7790-cpg-clocks" for the r8a7790 CPG
- "renesas,r8a7791-cpg-clocks" for the r8a7791 CPG
- "renesas,r8a7793-cpg-clocks" for the r8a7793 CPG
- "renesas,r8a7794-cpg-clocks" for the r8a7794 CPG
- "renesas,rcar-gen2-cpg-clocks" for the generic R-Car Gen2 CPG
- reg: Base address and length of the memory resource used by the CPG
- clocks: Reference to the parent clock
- clocks: References to the parent clocks: first to the EXTAL clock, second
to the USB_EXTAL clock
- #clock-cells: Must be 1
- clock-output-names: The names of the clocks. Supported clocks are "main",
"pll0", "pll1", "pll3", "lb", "qspi", "sdh", "sd0", "sd1" and "z"
"pll0", "pll1", "pll3", "lb", "qspi", "sdh", "sd0", "sd1", "z", "rcan", and
"adsp"
Example
@ -26,8 +29,9 @@ Example
compatible = "renesas,r8a7790-cpg-clocks",
"renesas,rcar-gen2-cpg-clocks";
reg = <0 0xe6150000 0 0x1000>;
clocks = <&extal_clk>;
clocks = <&extal_clk &usb_extal_clk>;
#clock-cells = <1>;
clock-output-names = "main", "pll0, "pll1", "pll3",
"lb", "qspi", "sdh", "sd0", "sd1", "z";
"lb", "qspi", "sdh", "sd0", "sd1", "z",
"rcan", "adsp";
};

35
Documentation/devicetree/bindings/clock/renesas,sh73a0-cpg-clocks.txt Normal file
View File

@ -0,0 +1,35 @@
These bindings should be considered EXPERIMENTAL for now.
* Renesas SH73A0 Clock Pulse Generator (CPG)
The CPG generates core clocks for the SH73A0 SoC. It includes four PLLs
and several fixed ratio dividers.
Required Properties:
- compatible: Must be "renesas,sh73a0-cpg-clocks"
- reg: Base address and length of the memory resource used by the CPG
- clocks: Reference to the parent clocks ("extal1" and "extal2")
- #clock-cells: Must be 1
- clock-output-names: The names of the clocks. Supported clocks are "main",
"pll0", "pll1", "pll2", "pll3", "dsi0phy", "dsi1phy", "zg", "m3", "b",
"m1", "m2", "z", "zx", and "hp".
Example
-------
cpg_clocks: cpg_clocks@e6150000 {
compatible = "renesas,sh73a0-cpg-clocks";
reg = <0 0xe6150000 0 0x10000>;
clocks = <&extal1_clk>, <&extal2_clk>;
#clock-cells = <1>;
clock-output-names = "main", "pll0", "pll1", "pll2",
"pll3", "dsi0phy", "dsi1phy",
"zg", "m3", "b", "m1", "m2",
"z", "zx", "hp";
};

43
Documentation/devicetree/bindings/clock/sunxi.txt
View File

@ -26,7 +26,7 @@ Required properties:
"allwinner,sun5i-a10s-ahb-gates-clk" - for the AHB gates on A10s
"allwinner,sun7i-a20-ahb-gates-clk" - for the AHB gates on A20
"allwinner,sun6i-a31-ar100-clk" - for the AR100 on A31
"allwinner,sun6i-a31-ahb1-mux-clk" - for the AHB1 multiplexer on A31
"allwinner,sun6i-a31-ahb1-clk" - for the AHB1 clock on A31
"allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
"allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
"allwinner,sun9i-a80-ahb0-gates-clk" - for the AHB0 gates on A80
@ -55,9 +55,11 @@ Required properties:
"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
"allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
"allwinner,sun4i-a10-mmc-output-clk" - for the MMC output clock on A10
"allwinner,sun4i-a10-mmc-sample-clk" - for the MMC sample clock on A10
"allwinner,sun4i-a10-mmc-clk" - for the MMC clock
"allwinner,sun9i-a80-mmc-clk" - for mmc module clocks on A80
"allwinner,sun9i-a80-mmc-config-clk" - for mmc gates + resets on A80
"allwinner,sun4i-a10-mod0-clk" - for the module 0 family of clocks
"allwinner,sun9i-a80-mod0-clk" - for module 0 (storage) clocks on A80
"allwinner,sun8i-a23-mbus-clk" - for the MBUS clock on A23
"allwinner,sun7i-a20-out-clk" - for the external output clocks
"allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
@ -73,7 +75,9 @@ Required properties for all clocks:
- #clock-cells : from common clock binding; shall be set to 0 except for
the following compatibles where it shall be set to 1:
"allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk",
"allwinner,sun4i-pll6-clk", "allwinner,sun6i-a31-pll6-clk"
"allwinner,sun4i-pll6-clk", "allwinner,sun6i-a31-pll6-clk",
"allwinner,*-usb-clk", "allwinner,*-mmc-clk",
"allwinner,*-mmc-config-clk"
- clock-output-names : shall be the corresponding names of the outputs.
If the clock module only has one output, the name shall be the
module name.
@ -81,6 +85,10 @@ Required properties for all clocks:
And "allwinner,*-usb-clk" clocks also require:
- reset-cells : shall be set to 1
The "allwinner,sun9i-a80-mmc-config-clk" clock also requires:
- #reset-cells : shall be set to 1
- resets : shall be the reset control phandle for the mmc block.
For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
dummy clocks at 25 MHz and 125 MHz, respectively. See example.
@ -95,6 +103,14 @@ For "allwinner,sun6i-a31-pll6-clk", there are 2 outputs. The first output
is the normal PLL6 output, or "pll6". The second output is rate doubled
PLL6, or "pll6x2".
The "allwinner,*-mmc-clk" clocks have three different outputs: the
main clock, with the ID 0, and the output and sample clocks, with the
IDs 1 and 2, respectively.
The "allwinner,sun9i-a80-mmc-config-clk" clock has one clock/reset output
per mmc controller. The number of outputs is determined by the size of
the address block, which is related to the overall mmc block.
For example:
osc24M: clk@01c20050 {
@ -138,11 +154,11 @@ cpu: cpu@01c20054 {
};
mmc0_clk: clk@01c20088 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-mod0-clk";
#clock-cells = <1>;
compatible = "allwinner,sun4i-a10-mmc-clk";
reg = <0x01c20088 0x4>;
clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
clock-output-names = "mmc0";
clock-output-names = "mmc0", "mmc0_output", "mmc0_sample";
};
mii_phy_tx_clk: clk@2 {
@ -170,3 +186,16 @@ gmac_clk: clk@01c20164 {
clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
clock-output-names = "gmac";
};
mmc_config_clk: clk@01c13000 {
compatible = "allwinner,sun9i-a80-mmc-config-clk";
reg = <0x01c13000 0x10>;
clocks = <&ahb0_gates 8>;
clock-names = "ahb";
resets = <&ahb0_resets 8>;
reset-names = "ahb";
#clock-cells = <1>;
#reset-cells = <1>;
clock-output-names = "mmc0_config", "mmc1_config",
"mmc2_config", "mmc3_config";
};

42
Documentation/devicetree/bindings/clock/ti,cdce706.txt Normal file
View File

@ -0,0 +1,42 @@
Bindings for Texas Instruments CDCE706 programmable 3-PLL clock
synthesizer/multiplier/divider.
Reference: http://www.ti.com/lit/ds/symlink/cdce706.pdf
I2C device node required properties:
- compatible: shall be "ti,cdce706".
- reg: i2c device address, shall be in range [0x68...0x6b].
- #clock-cells: from common clock binding; shall be set to 1.
- clocks: from common clock binding; list of parent clock
handles, shall be reference clock(s) connected to CLK_IN0
and CLK_IN1 pins.
- clock-names: shall be clk_in0 and/or clk_in1. Use clk_in0
in case of crystal oscillator or differential signal input
configuration. Use clk_in0 and clk_in1 in case of independent
single-ended LVCMOS inputs configuration.
Example:
clocks {
clk54: clk54 {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <54000000>;
};
};
...
i2c0: i2c-master@0d090000 {
...
cdce706: clock-synth@69 {
compatible = "ti,cdce706";
#clock-cells = <1>;
reg = <0x69>;
clocks = <&clk54>;
clock-names = "clk_in0";
};
};
...
simple-audio-card,codec {
...
clocks = <&cdce706 4>;
};

33
Documentation/devicetree/bindings/clock/ti/fapll.txt Normal file
View File

@ -0,0 +1,33 @@
Binding for Texas Instruments FAPLL clock.
Binding status: Unstable - ABI compatibility may be broken in the future
This binding uses the common clock binding[1]. It assumes a
register-mapped FAPLL with usually two selectable input clocks
(reference clock and bypass clock), and one or more child
syntesizers.
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "ti,dm816-fapll-clock"
- #clock-cells : from common clock binding; shall be set to 0.
- clocks : link phandles of parent clocks (clk-ref and clk-bypass)
- reg : address and length of the register set for controlling the FAPLL.
Examples:
main_fapll: main_fapll {
#clock-cells = <1>;
compatible = "ti,dm816-fapll-clock";
reg = <0x400 0x40>;
clocks = <&sys_clkin_ck &sys_clkin_ck>;
clock-indices = <1>, <2>, <3>, <4>, <5>,
<6>, <7>;
clock-output-names = "main_pll_clk1",
"main_pll_clk2",
"main_pll_clk3",
"main_pll_clk4",
"main_pll_clk5",
"main_pll_clk6",
"main_pll_clk7";
};

57
Documentation/devicetree/bindings/dma/img-mdc-dma.txt Normal file
View File

@ -0,0 +1,57 @@
* IMG Multi-threaded DMA Controller (MDC)
Required properties:
- compatible: Must be "img,pistachio-mdc-dma".
- reg: Must contain the base address and length of the MDC registers.
- interrupts: Must contain all the per-channel DMA interrupts.
- clocks: Must contain an entry for each entry in clock-names.
See ../clock/clock-bindings.txt for details.
- clock-names: Must include the following entries:
- sys: MDC system interface clock.
- img,cr-periph: Must contain a phandle to the peripheral control syscon
node which contains the DMA request to channel mapping registers.
- img,max-burst-multiplier: Must be the maximum supported burst size multiplier.
The maximum burst size is this value multiplied by the hardware-reported bus
width.
- #dma-cells: Must be 3:
- The first cell is the peripheral's DMA request line.
- The second cell is a bitmap specifying to which channels the DMA request
line may be mapped (i.e. bit N set indicates channel N is usable).
- The third cell is the thread ID to be used by the channel.
Optional properties:
- dma-channels: Number of supported DMA channels, up to 32. If not specified
the number reported by the hardware is used.
Example:
mdc: dma-controller@18143000 {
compatible = "img,pistachio-mdc-dma";
reg = <0x18143000 0x1000>;
interrupts = <GIC_SHARED 27 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 28 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 29 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 30 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 31 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 32 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 33 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 34 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 35 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 36 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 37 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 38 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&system_clk>;
clock-names = "sys";
img,max-burst-multiplier = <16>;
img,cr-periph = <&cr_periph>;
#dma-cells = <3>;
};
spi@18100f00 {
...
dmas = <&mdc 9 0xffffffff 0>, <&mdc 10 0xffffffff 0>;
dma-names = "tx", "rx";
...
};

5
Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
View File

@ -1,13 +1,10 @@
* Renesas R-Car DMA Controller Device Tree bindings
Renesas R-Car Generation 2 SoCs have have multiple multi-channel DMA
Renesas R-Car Generation 2 SoCs have multiple multi-channel DMA
controller instances named DMAC capable of serving multiple clients. Channels
can be dedicated to specific clients or shared between a large number of
clients.
DMA clients are connected to the DMAC ports referenced by an 8-bit identifier
called MID/RID.
Each DMA client is connected to one dedicated port of the DMAC, identified by
an 8-bit port number called the MID/RID. A DMA controller can thus serve up to
256 clients in total. When the number of hardware channels is lower than the

2
Documentation/devicetree/bindings/dma/snps-dma.txt
View File

@ -38,7 +38,7 @@ Example:
chan_allocation_order = <1>;
chan_priority = <1>;
block_size = <0xfff>;
data_width = <3 3 0 0>;
data_width = <3 3>;
};
DMA clients connected to the Designware DMA controller must use the format

53
Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt Normal file
View File

@ -0,0 +1,53 @@
Device-Tree bindings for Atmel's HLCDC (High LCD Controller) DRM driver
The Atmel HLCDC Display Controller is subdevice of the HLCDC MFD device.
See ../mfd/atmel-hlcdc.txt for more details.
Required properties:
- compatible: value should be "atmel,hlcdc-display-controller"
- pinctrl-names: the pin control state names. Should contain "default".
- pinctrl-0: should contain the default pinctrl states.
- #address-cells: should be set to 1.
- #size-cells: should be set to 0.
Required children nodes:
Children nodes are encoding available output ports and their connections
to external devices using the OF graph reprensentation (see ../graph.txt).
At least one port node is required.
Example:
hlcdc: hlcdc@f0030000 {
compatible = "atmel,sama5d3-hlcdc";
reg = <0xf0030000 0x2000>;
interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>;
clock-names = "periph_clk","sys_clk", "slow_clk";
status = "disabled";
hlcdc-display-controller {
compatible = "atmel,hlcdc-display-controller";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb888>;
#address-cells = <1>;
#size-cells = <0>;
port@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
hlcdc_panel_output: endpoint@0 {
reg = <0>;
remote-endpoint = <&panel_input>;
};
};
};
hlcdc_pwm: hlcdc-pwm {
compatible = "atmel,hlcdc-pwm";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lcd_pwm>;
#pwm-cells = <3>;
};
};

50
Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt Normal file
View File

@ -0,0 +1,50 @@
DesignWare HDMI bridge bindings
Required properties:
- compatible: platform specific such as:
* "snps,dw-hdmi-tx"
* "fsl,imx6q-hdmi"
* "fsl,imx6dl-hdmi"
* "rockchip,rk3288-dw-hdmi"
- reg: Physical base address and length of the controller's registers.
- interrupts: The HDMI interrupt number
- clocks, clock-names : must have the phandles to the HDMI iahb and isfr clocks,
as described in Documentation/devicetree/bindings/clock/clock-bindings.txt,
the clocks are soc specific, the clock-names should be "iahb", "isfr"
-port@[X]: SoC specific port nodes with endpoint definitions as defined
in Documentation/devicetree/bindings/media/video-interfaces.txt,
please refer to the SoC specific binding document:
* Documentation/devicetree/bindings/drm/imx/hdmi.txt
* Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt
Optional properties
- reg-io-width: the width of the reg:1,4, default set to 1 if not present
- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec"
Example:
hdmi: hdmi@0120000 {
compatible = "fsl,imx6q-hdmi";
reg = <0x00120000 0x9000>;
interrupts = <0 115 0x04>;
gpr = <&gpr>;
clocks = <&clks 123>, <&clks 124>;
clock-names = "iahb", "isfr";
ddc-i2c-bus = <&i2c2>;
port@0 {
reg = <0>;
hdmi_mux_0: endpoint {
remote-endpoint = <&ipu1_di0_hdmi>;
};
};
port@1 {
reg = <1>;
hdmi_mux_1: endpoint {
remote-endpoint = <&ipu1_di1_hdmi>;
};
};
};

2
Documentation/devicetree/bindings/drm/msm/hdmi.txt
View File

@ -2,6 +2,8 @@ Qualcomm adreno/snapdragon hdmi output
Required properties:
- compatible: one of the following
* "qcom,hdmi-tx-8084"
* "qcom,hdmi-tx-8074"
* "qcom,hdmi-tx-8660"
* "qcom,hdmi-tx-8960"
- reg: Physical base address and length of the controller's registers

17
Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt Normal file
View File

@ -0,0 +1,17 @@
Altera SOCFPGA FPGA Manager
Required properties:
- compatible : should contain "altr,socfpga-fpga-mgr"
- reg : base address and size for memory mapped io.
- The first index is for FPGA manager register access.
- The second index is for writing FPGA configuration data.
- interrupts : interrupt for the FPGA Manager device.
Example:
hps_0_fpgamgr: fpgamgr@0xff706000 {
compatible = "altr,socfpga-fpga-mgr";
reg = <0xFF706000 0x1000
0xFFB90000 0x1000>;
interrupts = <0 175 4>;
};

10
Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt
View File

@ -1,11 +1,11 @@
NVIDIA Tegra20/Tegra30/Tegr114/Tegra124 fuse block.
Required properties:
- compatible : should be:
"nvidia,tegra20-efuse"
"nvidia,tegra30-efuse"
"nvidia,tegra114-efuse"
"nvidia,tegra124-efuse"
- compatible : For Tegra20, must contain "nvidia,tegra20-efuse". For Tegra30,
must contain "nvidia,tegra30-efuse". For Tegra114, must contain
"nvidia,tegra114-efuse". For Tegra124, must contain "nvidia,tegra124-efuse".
Otherwise, must contain "nvidia,<chip>-efuse", plus one of the above, where
<chip> is tegra132.
Details:
nvidia,tegra20-efuse: Tegra20 requires using APB DMA to read the fuse data
due to a hardware bug. Tegra20 also lacks certain information which is

20
Documentation/devicetree/bindings/gpio/fujitsu,mb86s70-gpio.txt Normal file
View File

@ -0,0 +1,20 @@
Fujitsu MB86S7x GPIO Controller
-------------------------------
Required properties:
- compatible: Should be "fujitsu,mb86s70-gpio"
- reg: Base address and length of register space
- clocks: Specify the clock
- gpio-controller: Marks the device node as a gpio controller.
- #gpio-cells: Should be <2>. The first cell is the pin number and the
second cell is used to specify optional parameters:
- bit 0 specifies polarity (0 for normal, 1 for inverted).
Examples:
gpio0: gpio@31000000 {
compatible = "fujitsu,mb86s70-gpio";
reg = <0 0x31000000 0x10000>;
gpio-controller;
#gpio-cells = <2>;
clocks = <&clk 0 2 1>;
};

59
Documentation/devicetree/bindings/gpio/gpio-max732x.txt Normal file
View File

@ -0,0 +1,59 @@
* MAX732x-compatible I/O expanders
Required properties:
- compatible: Should be one of the following:
- "maxim,max7319": For the Maxim MAX7319
- "maxim,max7320": For the Maxim MAX7320
- "maxim,max7321": For the Maxim MAX7321
- "maxim,max7322": For the Maxim MAX7322
- "maxim,max7323": For the Maxim MAX7323
- "maxim,max7324": For the Maxim MAX7324
- "maxim,max7325": For the Maxim MAX7325
- "maxim,max7326": For the Maxim MAX7326
- "maxim,max7327": For the Maxim MAX7327
- reg: I2C slave address for this device.
- gpio-controller: Marks the device node as a GPIO controller.
- #gpio-cells: Should be 2.
- first cell is the GPIO number
- second cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>.
Only the GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
Optional properties:
The I/O expander can detect input state changes, and thus optionally act as
an interrupt controller. When the expander interrupt line is connected all the
following properties must be set. For more information please see the
interrupt controller device tree bindings documentation available at
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
- interrupt-controller: Identifies the node as an interrupt controller.
- #interrupt-cells: Number of cells to encode an interrupt source, shall be 2.
- first cell is the pin number
- second cell is used to specify flags
- interrupt-parent: phandle of the parent interrupt controller.
- interrupts: Interrupt specifier for the controllers interrupt.
Please refer to gpio.txt in this directory for details of the common GPIO
bindings used by client devices.
Example 1. MAX7325 with interrupt support enabled (CONFIG_GPIO_MAX732X_IRQ=y):
expander: max7325@6d {
compatible = "maxim,max7325";
reg = <0x6d>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&gpio4>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
};
Example 2. MAX7325 with interrupt support disabled (CONFIG_GPIO_MAX732X_IRQ=n):
expander: max7325@6d {
compatible = "maxim,max7325";
reg = <0x6d>;
gpio-controller;
#gpio-cells = <2>;
};

2
Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
View File

@ -39,7 +39,7 @@ Optional Properties:
- lines-initial-states: Bitmask that specifies the initial state of each
line. When a bit is set to zero, the corresponding line will be initialized to
the input (pulled-up) state. When the bit is set to one, the line will be
initialized the the low-level output state. If the property is not specified
initialized the low-level output state. If the property is not specified
all lines will be initialized to the input state.
The I/O expander can detect input state changes, and thus optionally act as

40
Documentation/devicetree/bindings/gpio/gpio-sx150x.txt Normal file
View File

@ -0,0 +1,40 @@
SEMTECH SX150x GPIO expander bindings
Required properties:
- compatible: should be "semtech,sx1506q",
"semtech,sx1508q",
"semtech,sx1509q".
- reg: The I2C slave address for this device.
- interrupt-parent: phandle of the parent interrupt controller.
- interrupts: Interrupt specifier for the controllers interrupt.
- #gpio-cells: Should be 2. The first cell is the GPIO number and the
second cell is used to specify optional parameters:
bit 0: polarity (0: normal, 1: inverted)
- gpio-controller: Marks the device as a GPIO controller.
- interrupt-controller: Marks the device as a interrupt controller.
The GPIO expander can optionally be used as an interrupt controller, in
which case it uses the default two cell specifier as described in
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
Example:
i2c_gpio_expander@20{
#gpio-cells = <2>;
#interrupt-cells = <2>;
compatible = "semtech,sx1506q";
reg = <0x20>;
interrupt-parent = <&gpio_1>;
interrupts = <16 0>;
gpio-controller;
interrupt-controller;
};

32
Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt Normal file
View File

@ -0,0 +1,32 @@
APM X-Gene Standby GPIO controller bindings
This is a gpio controller in the standby domain.
There are 20 GPIO pins from 0..21. There is no GPIO_DS14 or GPIO_DS15,
only GPIO_DS8..GPIO_DS13 support interrupts. The IRQ mapping
is currently 1-to-1 on interrupts 0x28 thru 0x2d.
Required properties:
- compatible: "apm,xgene-gpio-sb" for the X-Gene Standby GPIO controller
- reg: Physical base address and size of the controller's registers
- #gpio-cells: Should be two.
- first cell is the pin number
- second cell is used to specify the gpio polarity:
0 = active high
1 = active low
- gpio-controller: Marks the device node as a GPIO controller.
- interrupts: Shall contain exactly 6 interrupts.
Example:
sbgpio: sbgpio@17001000 {
compatible = "apm,xgene-gpio-sb";
reg = <0x0 0x17001000 0x0 0x400>;
#gpio-cells = <2>;
gpio-controller;
interrupts = <0x0 0x28 0x1>,
<0x0 0x29 0x1>,
<0x0 0x2a 0x1>,
<0x0 0x2b 0x1>,
<0x0 0x2c 0x1>,
<0x0 0x2d 0x1>;
};

5
Documentation/devicetree/bindings/gpio/gpio.txt
View File

@ -69,7 +69,8 @@ GPIO pin number, and GPIO flags as accepted by the "qe_pio_e" gpio-controller.
----------------------------------
A gpio-specifier should contain a flag indicating the GPIO polarity; active-
high or active-low. If it does, the follow best practices should be followed:
high or active-low. If it does, the following best practices should be
followed:
The gpio-specifier's polarity flag should represent the physical level at the
GPIO controller that achieves (or represents, for inputs) a logically asserted
@ -147,7 +148,7 @@ contains information structures as follows:
numeric-gpio-range ::=
<pinctrl-phandle> <gpio-base> <pinctrl-base> <count>
named-gpio-range ::= <pinctrl-phandle> <gpio-base> '<0 0>'
gpio-phandle : phandle to pin controller node.
pinctrl-phandle : phandle to pin controller node
gpio-base : Base GPIO ID in the GPIO controller
pinctrl-base : Base pinctrl pin ID in the pin controller
count : The number of GPIOs/pins in this range

4
Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
View File

@ -3,8 +3,8 @@
Required properties:
- compatible : Should be "intel,pxa25x-gpio", "intel,pxa26x-gpio",
"intel,pxa27x-gpio", "intel,pxa3xx-gpio",
"marvell,pxa93x-gpio", "marvell,mmp-gpio" or
"marvell,mmp2-gpio".
"marvell,pxa93x-gpio", "marvell,mmp-gpio",
"marvell,mmp2-gpio" or marvell,pxa1928-gpio.
- reg : Address and length of the register set for the device
- interrupts : Should be the port interrupt shared by all gpio pins.
There're three gpio interrupts in arch-pxa, and they're gpio0,

Some files were not shown because too many files have changed in this diff Show More