Linux 4.0-rc5
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJVD1VGAAoJEHm+PkMAQRiG7yoH/juKOQ1zbxi5M+mleDEEJtA0 RxQSojqEMWIKrWi8PNZxjENn1OZB6XOLIXOhlyAZBrmgsjO34p1DyXlZMznr/R8W kQ2Xxs061hRtB3OuruMIqOApUrjuqsaCwgbgUS1qWmqZcoyZN4oELyZMP6OOlqv5 UUBZm8MfyXGyxrCcg39mjct3VEOhiuEcvL6SUxOC380CdSVAnyqHFPcz0JVqMUn9 9RUBs0T9cMdhb0mZ2bfXzt6AKArj63G2nXOum+VzFcvspSm2U+MPIDCuoE+ZbTPS jqIAgG0rj1ezRyb5oeJrvlU0Yy3u/cXoMPs9+kORvpladooYNLti8ovh6qllm0I= =d/ye -----END PGP SIGNATURE----- Merge tag 'v4.0-rc5' into x86/fpu, to prevent conflicts Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
commit
eda2360ad1
6
.gitignore
vendored
6
.gitignore
vendored
|
@ -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
|
||||
#
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
265
Documentation/ABI/testing/configfs-usb-gadget-uvc
Normal 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
20
Documentation/ABI/testing/sysfs-bus-amba
Normal 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.
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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)
|
||||
|
|
11
Documentation/ABI/testing/sysfs-driver-input-axp-pek
Normal file
11
Documentation/ABI/testing/sysfs-driver-input-axp-pek
Normal 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>
|
|
@ -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
114
Documentation/ABI/testing/sysfs-driver-toshiba_acpi
Normal 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)
|
|
@ -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
44
Documentation/ABI/testing/sysfs-kernel-livepatch
Normal 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.
|
|
@ -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
|
||||
--------
|
||||
|
|
27
Documentation/CodeOfConflict
Normal file
27
Documentation/CodeOfConflict
Normal file
|
@ -0,0 +1,27 @@
|
|||
Code of Conflict
|
||||
----------------
|
||||
|
||||
The Linux kernel development effort is a very personal process compared
|
||||
to "traditional" ways of developing software. Your code and ideas
|
||||
behind it will be carefully reviewed, often resulting in critique and
|
||||
criticism. The review will almost always require improvements to the
|
||||
code before it can be included in the kernel. Know that this happens
|
||||
because everyone involved wants to see the best possible solution for
|
||||
the overall success of Linux. This development process has been proven
|
||||
to create the most robust operating system kernel ever, and we do not
|
||||
want to do anything to cause the quality of submission and eventual
|
||||
result to ever decrease.
|
||||
|
||||
If however, anyone feels personally abused, threatened, or otherwise
|
||||
uncomfortable due to this process, that is not acceptable. If so,
|
||||
please contact the Linux Foundation's Technical Advisory Board at
|
||||
<tab@lists.linux-foundation.org>, or the individual members, and they
|
||||
will work to resolve the issue to the best of their ability. For more
|
||||
information on who is on the Technical Advisory Board and what their
|
||||
role is, please see:
|
||||
http://www.linuxfoundation.org/programs/advisory-councils/tab
|
||||
|
||||
As a reviewer of code, please strive to keep things civil and focused on
|
||||
the technical issues involved. We are all humans, and frustrations can
|
||||
be high on both sides of the process. Try to keep in mind the immortal
|
||||
words of Bill and Ted, "Be excellent to each other."
|
|
@ -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
|
||||
|
|
|
@ -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">
|
||||
|
|
|
@ -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/
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -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">
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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 > /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 > /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 > /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 <asm/kgdb.h> 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
|
||||
|
|
|
@ -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> </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>
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
99
Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml
Normal 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 × 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 + 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 + 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 + 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 + 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>
|
|
@ -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
|
||||
|
|
|
@ -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;
|
||||
|
|
|
@ -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:
|
||||
-->
|
||||
|
|
|
@ -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:
|
||||
-->
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -243,7 +243,7 @@ input driver:
|
|||
.owner = THIS_MODULE,
|
||||
.pm = &mpu3050_pm,
|
||||
.of_match_table = mpu3050_of_match,
|
||||
.acpi_match_table ACPI_PTR(mpu3050_acpi_match),
|
||||
.acpi_match_table = ACPI_PTR(mpu3050_acpi_match),
|
||||
},
|
||||
.probe = mpu3050_probe,
|
||||
.remove = mpu3050_remove,
|
||||
|
|
|
@ -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
124
Documentation/arm/Atmel/README
Normal 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).
|
|
@ -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
20
Documentation/arm/sti/stih418-overview.txt
Normal 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
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -1,3 +1,5 @@
|
|||
ifneq ($(CONFIG_BLACKFIN),)
|
||||
ifneq ($(CONFIG_BFIN_GPTIMERS,)
|
||||
obj-m := gptimers-example.o
|
||||
endif
|
||||
endif
|
||||
|
|
|
@ -317,10 +317,10 @@ maps this page at its virtual address.
|
|||
about doing this.
|
||||
|
||||
The idea is, first at flush_dcache_page() time, if
|
||||
page->mapping->i_mmap is an empty tree and ->i_mmap_nonlinear
|
||||
an empty list, just mark the architecture private page flag bit.
|
||||
Later, in update_mmu_cache(), a check is made of this flag bit,
|
||||
and if set the flush is done and the flag bit is cleared.
|
||||
page->mapping->i_mmap is an empty tree, just mark the architecture
|
||||
private page flag bit. Later, in update_mmu_cache(), a check is
|
||||
made of this flag bit, and if set the flush is done and the flag
|
||||
bit is cleared.
|
||||
|
||||
IMPORTANT NOTE: It is often important, if you defer the flush,
|
||||
that the actual flush occurs on the same CPU
|
||||
|
|
|
@ -24,3 +24,5 @@ net_prio.txt
|
|||
- Network priority cgroups details and usages.
|
||||
resource_counter.txt
|
||||
- Resource Counter API.
|
||||
unified-hierarchy.txt
|
||||
- Description the new/next cgroup interface.
|
||||
|
|
|
@ -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 "max" to
|
||||
indicate and set the highest possible value.
|
||||
|
||||
5. Planned Changes
|
||||
|
||||
|
|
|
@ -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);
|
||||
|
|
|
@ -37,6 +37,14 @@ controlling P state selection. These files have been added to
|
|||
no_turbo: limits the driver to selecting P states below the turbo
|
||||
frequency range.
|
||||
|
||||
turbo_pct: displays the percentage of the total performance that
|
||||
is supported by hardware that is in the turbo range. This number
|
||||
is independent of whether turbo has been disabled or not.
|
||||
|
||||
num_pstates: displays the number of pstates that are supported
|
||||
by hardware. This number is independent of whether turbo has
|
||||
been disabled or not.
|
||||
|
||||
For contemporary Intel processors, the frequency is controlled by the
|
||||
processor itself and the P-states exposed to software are related to
|
||||
performance levels. The idea that frequency can be set to a single
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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";
|
||||
|
|
|
@ -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>;
|
||||
};
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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>;
|
||||
|
|
|
@ -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
6
Documentation/devicetree/bindings/arm/digicolor.txt
Normal 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
|
|
@ -22,8 +22,10 @@ Optional Properties:
|
|||
- pclkN, clkN: Pairs of parent of input clock and input clock to the
|
||||
devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
|
||||
are supported currently.
|
||||
- power-domains: phandle pointing to the parent power domain, for more details
|
||||
see Documentation/devicetree/bindings/power/power_domain.txt
|
||||
|
||||
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:
|
||||
|
|
|
@ -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";
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
|
|
@ -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";
|
||||
|
|
|
@ -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"
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
16
Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
Normal 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>;
|
||||
};
|
|
@ -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>;
|
||||
};
|
|
@ -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.
|
||||
|
|
|
@ -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
11
Documentation/devicetree/bindings/arm/sprd.txt
Normal 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";
|
|
@ -13,3 +13,11 @@ Boards with the ST STiH407 SoC shall have the following properties:
|
|||
Required root node property:
|
||||
compatible = "st,stih407";
|
||||
|
||||
Boards with the ST STiH410 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,stih410";
|
||||
|
||||
Boards with the ST STiH418 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,stih418";
|
||||
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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
10
Documentation/devicetree/bindings/arm/versatile-sysreg.txt
Normal 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
|
|
@ -37,9 +37,10 @@ Required properties when using sub-nodes:
|
|||
|
||||
|
||||
Sub-nodes required properties:
|
||||
- reg : the port number
|
||||
- phys : reference to the SATA PHY node
|
||||
|
||||
- reg : the port number
|
||||
And at least one of the following properties:
|
||||
- phys : reference to the SATA PHY node
|
||||
- target-supply : regulator for SATA target power
|
||||
|
||||
Examples:
|
||||
sata@ffe08000 {
|
||||
|
@ -68,10 +69,12 @@ With sub-nodes:
|
|||
sata0: sata-port@0 {
|
||||
reg = <0>;
|
||||
phys = <&sata_phy 0>;
|
||||
target-supply = <®_sata0>;
|
||||
};
|
||||
|
||||
sata1: sata-port@1 {
|
||||
reg = <1>;
|
||||
phys = <&sata_phy 1>;
|
||||
target-supply = <®_sata1>;;
|
||||
};
|
||||
};
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
115
Documentation/devicetree/bindings/clock/alphascale,acc.txt
Normal 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>;
|
||||
};
|
||||
|
|
@ -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
|
||||
|
|
|
@ -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
21
Documentation/devicetree/bindings/clock/qcom,lcc.txt
Normal 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>;
|
||||
};
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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";
|
||||
};
|
|
@ -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";
|
||||
};
|
||||
|
|
|
@ -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";
|
||||
};
|
|
@ -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
42
Documentation/devicetree/bindings/clock/ti,cdce706.txt
Normal 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
33
Documentation/devicetree/bindings/clock/ti/fapll.txt
Normal 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";
|
||||
};
|
110
Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
Normal file
110
Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
Normal file
|
@ -0,0 +1,110 @@
|
|||
|
||||
* Samsung Exynos PPMU (Platform Performance Monitoring Unit) device
|
||||
|
||||
The Samsung Exynos SoC has PPMU (Platform Performance Monitoring Unit) for
|
||||
each IP. PPMU provides the primitive values to get performance data. These
|
||||
PPMU events provide information of the SoC's behaviors so that you may
|
||||
use to analyze system performance, to make behaviors visible and to count
|
||||
usages of each IP (DMC, CPU, RIGHTBUS, LEFTBUS, CAM interface, LCD, G3D, MFC).
|
||||
The Exynos PPMU driver uses the devfreq-event class to provide event data
|
||||
to various devfreq devices. The devfreq devices would use the event data when
|
||||
derterming the current state of each IP.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "samsung,exynos-ppmu".
|
||||
- reg: physical base address of each PPMU and length of memory mapped region.
|
||||
|
||||
Optional properties:
|
||||
- clock-names : the name of clock used by the PPMU, "ppmu"
|
||||
- clocks : phandles for clock specified in "clock-names" property
|
||||
- #clock-cells: should be 1.
|
||||
|
||||
Example1 : PPMU nodes in exynos3250.dtsi are listed below.
|
||||
|
||||
ppmu_dmc0: ppmu_dmc0@106a0000 {
|
||||
compatible = "samsung,exynos-ppmu";
|
||||
reg = <0x106a0000 0x2000>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
ppmu_dmc1: ppmu_dmc1@106b0000 {
|
||||
compatible = "samsung,exynos-ppmu";
|
||||
reg = <0x106b0000 0x2000>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
ppmu_cpu: ppmu_cpu@106c0000 {
|
||||
compatible = "samsung,exynos-ppmu";
|
||||
reg = <0x106c0000 0x2000>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
ppmu_rightbus: ppmu_rightbus@112a0000 {
|
||||
compatible = "samsung,exynos-ppmu";
|
||||
reg = <0x112a0000 0x2000>;
|
||||
clocks = <&cmu CLK_PPMURIGHT>;
|
||||
clock-names = "ppmu";
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
ppmu_leftbus: ppmu_leftbus0@116a0000 {
|
||||
compatible = "samsung,exynos-ppmu";
|
||||
reg = <0x116a0000 0x2000>;
|
||||
clocks = <&cmu CLK_PPMULEFT>;
|
||||
clock-names = "ppmu";
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
Example2 : Events of each PPMU node in exynos3250-rinato.dts are listed below.
|
||||
|
||||
&ppmu_dmc0 {
|
||||
status = "okay";
|
||||
|
||||
events {
|
||||
ppmu_dmc0_3: ppmu-event3-dmc0 {
|
||||
event-name = "ppmu-event3-dmc0";
|
||||
};
|
||||
|
||||
ppmu_dmc0_2: ppmu-event2-dmc0 {
|
||||
event-name = "ppmu-event2-dmc0";
|
||||
};
|
||||
|
||||
ppmu_dmc0_1: ppmu-event1-dmc0 {
|
||||
event-name = "ppmu-event1-dmc0";
|
||||
};
|
||||
|
||||
ppmu_dmc0_0: ppmu-event0-dmc0 {
|
||||
event-name = "ppmu-event0-dmc0";
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
&ppmu_dmc1 {
|
||||
status = "okay";
|
||||
|
||||
events {
|
||||
ppmu_dmc1_3: ppmu-event3-dmc1 {
|
||||
event-name = "ppmu-event3-dmc1";
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
&ppmu_leftbus {
|
||||
status = "okay";
|
||||
|
||||
events {
|
||||
ppmu_leftbus_3: ppmu-event3-leftbus {
|
||||
event-name = "ppmu-event3-leftbus";
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
&ppmu_rightbus {
|
||||
status = "okay";
|
||||
|
||||
events {
|
||||
ppmu_rightbus_3: ppmu-event3-rightbus {
|
||||
event-name = "ppmu-event3-rightbus";
|
||||
};
|
||||
};
|
||||
};
|
57
Documentation/devicetree/bindings/dma/img-mdc-dma.txt
Normal file
57
Documentation/devicetree/bindings/dma/img-mdc-dma.txt
Normal 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";
|
||||
...
|
||||
};
|
|
@ -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
|
||||
|
|
|
@ -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
53
Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt
Normal 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
50
Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
Normal 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,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
|
||||
|
|
|
@ -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>;
|
||||
};
|
|
@ -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
|
||||
|
|
|
@ -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
59
Documentation/devicetree/bindings/gpio/gpio-max732x.txt
Normal 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>;
|
||||
};
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue