Linux 34.0-rc1
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJU6pFJAAoJEHm+PkMAQRiG2OwH/24nDK+l9zkaRs0xJsVh+qiW 8A2N1od0ickz43iMk48jfeWGkFOkd4izyvan/daJshJOE1Y5lCdSs7jq/OXVOv9L G0+KQUoC5NL0hqYKn1XJPFluNQ1yqMvrDwQt99grDGzruNGBbwHuBhAQmgzpj1nU do8KrGjr7ft1Rzm4mOAdET/ExWiF+mRSJSxxOv598HbsIRdM5wgn0hHjPlqDxmLN KH4r3YYEm0cHyjf4Krse0+YdhqdamRGJlmYxJgEsYNwCoMwkmHlLTc71diseUhrg r/VYIYQvpAA6Yvgw8rJ0N5gk/sJJig+WyyPhfQuc2bD5sbL9eO7mPnz2UP7z7ss= =vXB6 -----END PGP SIGNATURE----- Merge tag 'v4.0-rc1' into perf/core, to refresh the tree Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
commit
e9e4e44309
6
.gitignore
vendored
6
.gitignore
vendored
|
@ -43,6 +43,7 @@ Module.symvers
|
||||||
/TAGS
|
/TAGS
|
||||||
/linux
|
/linux
|
||||||
/vmlinux
|
/vmlinux
|
||||||
|
/vmlinux-gdb.py
|
||||||
/vmlinuz
|
/vmlinuz
|
||||||
/System.map
|
/System.map
|
||||||
/Module.markers
|
/Module.markers
|
||||||
|
@ -52,6 +53,11 @@ Module.symvers
|
||||||
#
|
#
|
||||||
/debian/
|
/debian/
|
||||||
|
|
||||||
|
#
|
||||||
|
# tar directory (make tar*-pkg)
|
||||||
|
#
|
||||||
|
/tar-install/
|
||||||
|
|
||||||
#
|
#
|
||||||
# git files that we don't want to ignore even it they are dot-files
|
# git files that we don't want to ignore even it they are dot-files
|
||||||
#
|
#
|
||||||
|
|
1
.mailmap
1
.mailmap
|
@ -73,6 +73,7 @@ Juha Yrjola <juha.yrjola@nokia.com>
|
||||||
Juha Yrjola <juha.yrjola@solidboot.com>
|
Juha Yrjola <juha.yrjola@solidboot.com>
|
||||||
Kay Sievers <kay.sievers@vrfy.org>
|
Kay Sievers <kay.sievers@vrfy.org>
|
||||||
Kenneth W Chen <kenneth.w.chen@intel.com>
|
Kenneth W Chen <kenneth.w.chen@intel.com>
|
||||||
|
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
|
||||||
Koushik <raghavendra.koushik@neterion.com>
|
Koushik <raghavendra.koushik@neterion.com>
|
||||||
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
|
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
|
||||||
Leonid I Ananiev <leonid.i.ananiev@intel.com>
|
Leonid I Ananiev <leonid.i.ananiev@intel.com>
|
||||||
|
|
|
@ -29,8 +29,6 @@ DMA-ISA-LPC.txt
|
||||||
- How to do DMA with ISA (and LPC) devices.
|
- How to do DMA with ISA (and LPC) devices.
|
||||||
DMA-attributes.txt
|
DMA-attributes.txt
|
||||||
- listing of the various possible attributes a DMA region can have
|
- listing of the various possible attributes a DMA region can have
|
||||||
dmatest.txt
|
|
||||||
- how to compile, configure and use the dmatest system.
|
|
||||||
DocBook/
|
DocBook/
|
||||||
- directory with DocBook templates etc. for kernel documentation.
|
- directory with DocBook templates etc. for kernel documentation.
|
||||||
EDID/
|
EDID/
|
||||||
|
@ -163,8 +161,6 @@ digsig.txt
|
||||||
-info on the Digital Signature Verification API
|
-info on the Digital Signature Verification API
|
||||||
dma-buf-sharing.txt
|
dma-buf-sharing.txt
|
||||||
- the DMA Buffer Sharing API Guide
|
- the DMA Buffer Sharing API Guide
|
||||||
dmaengine.txt
|
|
||||||
-the DMA Engine API Guide
|
|
||||||
dontdiff
|
dontdiff
|
||||||
- file containing a list of files that should never be diff'ed.
|
- file containing a list of files that should never be diff'ed.
|
||||||
driver-model/
|
driver-model/
|
||||||
|
@ -209,6 +205,8 @@ hid/
|
||||||
- directory with information on human interface devices
|
- directory with information on human interface devices
|
||||||
highuid.txt
|
highuid.txt
|
||||||
- notes on the change from 16 bit to 32 bit user/group IDs.
|
- notes on the change from 16 bit to 32 bit user/group IDs.
|
||||||
|
hsi.txt
|
||||||
|
- HSI subsystem overview.
|
||||||
hwspinlock.txt
|
hwspinlock.txt
|
||||||
- hardware spinlock provides hardware assistance for synchronization
|
- hardware spinlock provides hardware assistance for synchronization
|
||||||
timers/
|
timers/
|
||||||
|
@ -277,6 +275,8 @@ kprobes.txt
|
||||||
- documents the kernel probes debugging feature.
|
- documents the kernel probes debugging feature.
|
||||||
kref.txt
|
kref.txt
|
||||||
- docs on adding reference counters (krefs) to kernel objects.
|
- docs on adding reference counters (krefs) to kernel objects.
|
||||||
|
kselftest.txt
|
||||||
|
- small unittests for (some) individual codepaths in the kernel.
|
||||||
laptops/
|
laptops/
|
||||||
- directory with laptop related info and laptop driver documentation.
|
- directory with laptop related info and laptop driver documentation.
|
||||||
ldm.txt
|
ldm.txt
|
||||||
|
@ -285,22 +285,22 @@ leds/
|
||||||
- directory with info about LED handling under Linux.
|
- directory with info about LED handling under Linux.
|
||||||
local_ops.txt
|
local_ops.txt
|
||||||
- semantics and behavior of local atomic operations.
|
- semantics and behavior of local atomic operations.
|
||||||
lockdep-design.txt
|
|
||||||
- documentation on the runtime locking correctness validator.
|
|
||||||
locking/
|
locking/
|
||||||
- directory with info about kernel locking primitives
|
- directory with info about kernel locking primitives
|
||||||
lockstat.txt
|
|
||||||
- info on collecting statistics on locks (and contention).
|
|
||||||
lockup-watchdogs.txt
|
lockup-watchdogs.txt
|
||||||
- info on soft and hard lockup detectors (aka nmi_watchdog).
|
- info on soft and hard lockup detectors (aka nmi_watchdog).
|
||||||
logo.gif
|
logo.gif
|
||||||
- full colour GIF image of Linux logo (penguin - Tux).
|
- full colour GIF image of Linux logo (penguin - Tux).
|
||||||
logo.txt
|
logo.txt
|
||||||
- info on creator of above logo & site to get additional images from.
|
- info on creator of above logo & site to get additional images from.
|
||||||
|
lzo.txt
|
||||||
|
- kernel LZO decompressor input formats
|
||||||
m68k/
|
m68k/
|
||||||
- directory with info about Linux on Motorola 68k architecture.
|
- directory with info about Linux on Motorola 68k architecture.
|
||||||
magic-number.txt
|
magic-number.txt
|
||||||
- list of magic numbers used to mark/protect kernel data structures.
|
- 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
|
md.txt
|
||||||
- info on boot arguments for the multiple devices driver.
|
- info on boot arguments for the multiple devices driver.
|
||||||
media-framework.txt
|
media-framework.txt
|
||||||
|
@ -327,8 +327,6 @@ mtd/
|
||||||
- directory with info about memory technology devices (flash)
|
- directory with info about memory technology devices (flash)
|
||||||
mono.txt
|
mono.txt
|
||||||
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
|
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
|
||||||
mutex-design.txt
|
|
||||||
- info on the generic mutex subsystem.
|
|
||||||
namespaces/
|
namespaces/
|
||||||
- directory with various information about namespaces
|
- directory with various information about namespaces
|
||||||
netlabel/
|
netlabel/
|
||||||
|
@ -395,10 +393,6 @@ robust-futexes.txt
|
||||||
- a description of what robust futexes are.
|
- a description of what robust futexes are.
|
||||||
rpmsg.txt
|
rpmsg.txt
|
||||||
- info on the Remote Processor Messaging (rpmsg) Framework
|
- 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
|
rtc.txt
|
||||||
- notes on how to use the Real Time Clock (aka CMOS clock) driver.
|
- notes on how to use the Real Time Clock (aka CMOS clock) driver.
|
||||||
s390/
|
s390/
|
||||||
|
@ -425,8 +419,6 @@ sparse.txt
|
||||||
- info on how to obtain and use the sparse tool for typechecking.
|
- info on how to obtain and use the sparse tool for typechecking.
|
||||||
spi/
|
spi/
|
||||||
- overview of Linux kernel Serial Peripheral Interface (SPI) support.
|
- 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
|
stable_api_nonsense.txt
|
||||||
- info on why the kernel does not have a stable in-kernel api or abi.
|
- info on why the kernel does not have a stable in-kernel api or abi.
|
||||||
stable_kernel_rules.txt
|
stable_kernel_rules.txt
|
||||||
|
@ -483,10 +475,10 @@ wimax/
|
||||||
- directory with info about Intel Wireless Wimax Connections
|
- directory with info about Intel Wireless Wimax Connections
|
||||||
workqueue.txt
|
workqueue.txt
|
||||||
- information on the Concurrency Managed Workqueue implementation
|
- information on the Concurrency Managed Workqueue implementation
|
||||||
ww-mutex-design.txt
|
|
||||||
- Intro to Mutex wait/would deadlock handling.s
|
|
||||||
x86/x86_64/
|
x86/x86_64/
|
||||||
- directory with info on Linux support for AMD x86-64 (Hammer) machines.
|
- directory with info on Linux support for AMD x86-64 (Hammer) machines.
|
||||||
|
xillybus.txt
|
||||||
|
- Overview and basic ui of xillybus driver
|
||||||
xtensa/
|
xtensa/
|
||||||
- directory with documents relating to arch/xtensa port/implementation
|
- directory with documents relating to arch/xtensa port/implementation
|
||||||
xz.txt
|
xz.txt
|
||||||
|
|
|
@ -1,4 +1,4 @@
|
||||||
What: /sys/class/misc/tpmX/device/
|
What: /sys/class/tpm/tpmX/device/
|
||||||
Date: April 2005
|
Date: April 2005
|
||||||
KernelVersion: 2.6.12
|
KernelVersion: 2.6.12
|
||||||
Contact: tpmdd-devel@lists.sf.net
|
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
|
the properties of that TPM chip
|
||||||
|
|
||||||
|
|
||||||
What: /sys/class/misc/tpmX/device/active
|
What: /sys/class/tpm/tpmX/device/active
|
||||||
Date: April 2006
|
Date: April 2006
|
||||||
KernelVersion: 2.6.17
|
KernelVersion: 2.6.17
|
||||||
Contact: tpmdd-devel@lists.sf.net
|
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
|
section 17 for more information on which commands are
|
||||||
available.
|
available.
|
||||||
|
|
||||||
What: /sys/class/misc/tpmX/device/cancel
|
What: /sys/class/tpm/tpmX/device/cancel
|
||||||
Date: June 2005
|
Date: June 2005
|
||||||
KernelVersion: 2.6.13
|
KernelVersion: 2.6.13
|
||||||
Contact: tpmdd-devel@lists.sf.net
|
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
|
pending TPM command. Writing any value to cancel will call the
|
||||||
TPM vendor specific cancel operation.
|
TPM vendor specific cancel operation.
|
||||||
|
|
||||||
What: /sys/class/misc/tpmX/device/caps
|
What: /sys/class/tpm/tpmX/device/caps
|
||||||
Date: April 2005
|
Date: April 2005
|
||||||
KernelVersion: 2.6.12
|
KernelVersion: 2.6.12
|
||||||
Contact: tpmdd-devel@lists.sf.net
|
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
|
the chip supports. Firmware version is that of the chip and
|
||||||
is manufacturer specific.
|
is manufacturer specific.
|
||||||
|
|
||||||
What: /sys/class/misc/tpmX/device/durations
|
What: /sys/class/tpm/tpmX/device/durations
|
||||||
Date: March 2011
|
Date: March 2011
|
||||||
KernelVersion: 3.1
|
KernelVersion: 3.1
|
||||||
Contact: tpmdd-devel@lists.sf.net
|
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]"
|
scaled to be displayed in usecs. In this case "[adjusted]"
|
||||||
will be displayed in place of "[original]".
|
will be displayed in place of "[original]".
|
||||||
|
|
||||||
What: /sys/class/misc/tpmX/device/enabled
|
What: /sys/class/tpm/tpmX/device/enabled
|
||||||
Date: April 2006
|
Date: April 2006
|
||||||
KernelVersion: 2.6.17
|
KernelVersion: 2.6.17
|
||||||
Contact: tpmdd-devel@lists.sf.net
|
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
|
may be visible but produce a '0' after some operation that
|
||||||
disables the TPM.
|
disables the TPM.
|
||||||
|
|
||||||
What: /sys/class/misc/tpmX/device/owned
|
What: /sys/class/tpm/tpmX/device/owned
|
||||||
Date: April 2006
|
Date: April 2006
|
||||||
KernelVersion: 2.6.17
|
KernelVersion: 2.6.17
|
||||||
Contact: tpmdd-devel@lists.sf.net
|
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'
|
ordinal has been executed successfully in the chip. A '0'
|
||||||
indicates that ownership hasn't been taken.
|
indicates that ownership hasn't been taken.
|
||||||
|
|
||||||
What: /sys/class/misc/tpmX/device/pcrs
|
What: /sys/class/tpm/tpmX/device/pcrs
|
||||||
Date: April 2005
|
Date: April 2005
|
||||||
KernelVersion: 2.6.12
|
KernelVersion: 2.6.12
|
||||||
Contact: tpmdd-devel@lists.sf.net
|
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
|
1.2 chips, PCRs represent SHA-1 hashes, which are 20 bytes
|
||||||
long. Use the "caps" property to determine TPM version.
|
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
|
Date: April 2005
|
||||||
KernelVersion: 2.6.12
|
KernelVersion: 2.6.12
|
||||||
Contact: tpmdd-devel@lists.sf.net
|
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 Length: 256 (bytes)
|
||||||
Modulus: The 256 byte Endorsement Key modulus
|
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
|
Date: April 2006
|
||||||
KernelVersion: 2.6.17
|
KernelVersion: 2.6.17
|
||||||
Contact: tpmdd-devel@lists.sf.net
|
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
|
cycle. Whether a warm boot (reboot) will clear a TPM chip
|
||||||
from a temp_deactivated state is platform specific.
|
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
|
Date: March 2011
|
||||||
KernelVersion: 3.1
|
KernelVersion: 3.1
|
||||||
Contact: tpmdd-devel@lists.sf.net
|
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:
|
Description:
|
||||||
Exposes the "version" field of the 24x7 catalog. This is also
|
Exposes the "version" field of the 24x7 catalog. This is also
|
||||||
extractable from the provided binary "catalog" sysfs entry.
|
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
|
is required is a consistent labeling. Units after application
|
||||||
of scale and offset are millivolts.
|
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
|
What: /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_raw
|
||||||
KernelVersion: 3.2
|
KernelVersion: 3.2
|
||||||
Contact: linux-iio@vger.kernel.org
|
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_accel_z_offset
|
||||||
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_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_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_tempY_offset
|
||||||
What: /sys/bus/iio/devices/iio:deviceX/in_temp_offset
|
What: /sys/bus/iio/devices/iio:deviceX/in_temp_offset
|
||||||
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_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/in_voltage-voltage_scale
|
||||||
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_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/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_scale
|
||||||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_peak_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_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_scale
|
||||||
What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_scale
|
What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_scale
|
||||||
What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_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_pressureY_scale
|
||||||
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_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_humidityrelative_scale
|
||||||
|
What: /sys/bus/iio/devices/iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_scale
|
||||||
KernelVersion: 2.6.35
|
KernelVersion: 2.6.35
|
||||||
Contact: linux-iio@vger.kernel.org
|
Contact: linux-iio@vger.kernel.org
|
||||||
Description:
|
Description:
|
||||||
|
@ -323,6 +343,44 @@ Description:
|
||||||
production inaccuracies). If shared across all channels,
|
production inaccuracies). If shared across all channels,
|
||||||
<type>_calibscale is used.
|
<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/bus/iio/devices/iio:deviceX/in_accel_scale_available
|
||||||
What: /sys/.../iio:deviceX/in_voltageX_scale_available
|
What: /sys/.../iio:deviceX/in_voltageX_scale_available
|
||||||
What: /sys/.../iio:deviceX/in_voltage-voltage_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_accel_x&y&z_mag_falling_period
|
||||||
What: /sys/.../events/in_intensity0_thresh_period
|
What: /sys/.../events/in_intensity0_thresh_period
|
||||||
What: /sys/.../events/in_proximity0_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
|
KernelVersion: 2.6.37
|
||||||
Contact: linux-iio@vger.kernel.org
|
Contact: linux-iio@vger.kernel.org
|
||||||
Description:
|
Description:
|
||||||
|
@ -790,6 +856,40 @@ Description:
|
||||||
met before an event is generated. If direction is not
|
met before an event is generated. If direction is not
|
||||||
specified then this period applies to both directions.
|
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_en
|
||||||
What: /sys/.../iio:deviceX/events/in_accel_mag_rising_en
|
What: /sys/.../iio:deviceX/events/in_accel_mag_rising_en
|
||||||
What: /sys/.../iio:deviceX/events/in_accel_mag_falling_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
|
number or direction is not specified, applies to all channels of
|
||||||
this type.
|
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
|
What: /sys/bus/iio/devices/iio:deviceX/trigger/current_trigger
|
||||||
KernelVersion: 2.6.35
|
KernelVersion: 2.6.35
|
||||||
Contact: linux-iio@vger.kernel.org
|
Contact: linux-iio@vger.kernel.org
|
||||||
|
@ -956,6 +1075,16 @@ Description:
|
||||||
and the relevant _type attributes to establish the data storage
|
and the relevant _type attributes to establish the data storage
|
||||||
format.
|
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
|
What: /sys/.../iio:deviceX/in_anglvel_z_quadrature_correction_raw
|
||||||
KernelVersion: 2.6.38
|
KernelVersion: 2.6.38
|
||||||
Contact: linux-iio@vger.kernel.org
|
Contact: linux-iio@vger.kernel.org
|
||||||
|
@ -973,6 +1102,24 @@ Description:
|
||||||
For a list of available output power modes read
|
For a list of available output power modes read
|
||||||
in_accel_power_mode_available.
|
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
|
What: /sys/bus/iio/devices/iio:deviceX/store_eeprom
|
||||||
KernelVersion: 3.4.0
|
KernelVersion: 3.4.0
|
||||||
Contact: linux-iio@vger.kernel.org
|
Contact: linux-iio@vger.kernel.org
|
||||||
|
@ -992,7 +1139,9 @@ Description:
|
||||||
reflectivity of infrared or ultrasound emitted.
|
reflectivity of infrared or ultrasound emitted.
|
||||||
Often these sensors are unit less and as such conversion
|
Often these sensors are unit less and as such conversion
|
||||||
to SI units is not possible. Where it is, the units should
|
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_input
|
||||||
What: /sys/.../iio:deviceX/in_illuminanceY_raw
|
What: /sys/.../iio:deviceX/in_illuminanceY_raw
|
||||||
|
@ -1024,6 +1173,12 @@ Description:
|
||||||
This attribute is used to get/set the integration time in
|
This attribute is used to get/set the integration time in
|
||||||
seconds.
|
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
|
What: /sys/bus/iio/devices/iio:deviceX/in_rot_quaternion_raw
|
||||||
KernelVersion: 3.15
|
KernelVersion: 3.15
|
||||||
Contact: linux-iio@vger.kernel.org
|
Contact: linux-iio@vger.kernel.org
|
||||||
|
@ -1051,3 +1206,46 @@ Description:
|
||||||
after application of scale and offset. If no offset or scale is
|
after application of scale and offset. If no offset or scale is
|
||||||
present, output should be considered as processed with the
|
present, output should be considered as processed with the
|
||||||
unit in milliamps.
|
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):
|
Slave contexts (eg. /sys/class/cxl/afu0.0s):
|
||||||
|
|
||||||
What: /sys/class/cxl/<afu>/irqs_max
|
What: /sys/class/cxl/<afu>/irqs_max
|
||||||
|
@ -67,7 +73,7 @@ Contact: linuxppc-dev@lists.ozlabs.org
|
||||||
Description: read only
|
Description: read only
|
||||||
Decimal value of the current version of the kernel/user API.
|
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
|
Date: September 2014
|
||||||
Contact: linuxppc-dev@lists.ozlabs.org
|
Contact: linuxppc-dev@lists.ozlabs.org
|
||||||
Description: read only
|
Description: read only
|
||||||
|
@ -75,6 +81,42 @@ Description: read only
|
||||||
this this kernel supports.
|
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)
|
Master contexts (eg. /sys/class/cxl/afu0.0m)
|
||||||
|
|
||||||
|
@ -106,7 +148,7 @@ Contact: linuxppc-dev@lists.ozlabs.org
|
||||||
Description: read only
|
Description: read only
|
||||||
Identifies the CAIA Version the card implements.
|
Identifies the CAIA Version the card implements.
|
||||||
|
|
||||||
What: /sys/class/cxl/<card>/psl_version
|
What: /sys/class/cxl/<card>/psl_revision
|
||||||
Date: September 2014
|
Date: September 2014
|
||||||
Contact: linuxppc-dev@lists.ozlabs.org
|
Contact: linuxppc-dev@lists.ozlabs.org
|
||||||
Description: read only
|
Description: read only
|
||||||
|
@ -127,3 +169,24 @@ Contact: linuxppc-dev@lists.ozlabs.org
|
||||||
Description: read only
|
Description: read only
|
||||||
Will return "user" or "factory" depending on the image loaded
|
Will return "user" or "factory" depending on the image loaded
|
||||||
onto the card.
|
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:
|
Valid values:
|
||||||
- 5, 6 or 7 (hours),
|
- 5, 6 or 7 (hours),
|
||||||
- 0: disabled.
|
- 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
|
Description: Use your USB ports to charge devices, even
|
||||||
when your laptop is powered off.
|
when your laptop is powered off.
|
||||||
1 means enabled, 0 means disabled.
|
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>
|
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
|
||||||
Description:
|
Description:
|
||||||
Controls the memory footprint used by f2fs.
|
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,
|
systems; obviously, if you don't have any ISDN hardware, for example,
|
||||||
you probably needn't concern yourself with isdn4k-utils.
|
you probably needn't concern yourself with isdn4k-utils.
|
||||||
|
|
||||||
o Gnu C 3.2 # gcc --version
|
o GNU C 3.2 # gcc --version
|
||||||
o Gnu make 3.80 # make --version
|
o GNU make 3.80 # make --version
|
||||||
o binutils 2.12 # ld -v
|
o binutils 2.12 # ld -v
|
||||||
o util-linux 2.10o # fdformat --version
|
o util-linux 2.10o # fdformat --version
|
||||||
o module-init-tools 0.9.10 # depmod -V
|
o module-init-tools 0.9.10 # depmod -V
|
||||||
|
@ -57,7 +57,7 @@ computer.
|
||||||
Make
|
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
|
Binutils
|
||||||
--------
|
--------
|
||||||
|
|
|
@ -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")
|
(string-match (expand-file-name "~/src/linux-trees")
|
||||||
filename))
|
filename))
|
||||||
(setq indent-tabs-mode t)
|
(setq indent-tabs-mode t)
|
||||||
|
(setq show-trailing-whitespace t)
|
||||||
(c-set-style "linux-tabs-only")))))
|
(c-set-style "linux-tabs-only")))))
|
||||||
|
|
||||||
This will make emacs go better with the kernel coding style for C
|
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_beacon_data
|
||||||
!Finclude/net/cfg80211.h cfg80211_ap_settings
|
!Finclude/net/cfg80211.h cfg80211_ap_settings
|
||||||
!Finclude/net/cfg80211.h station_parameters
|
!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_flags
|
||||||
!Finclude/net/cfg80211.h rate_info
|
!Finclude/net/cfg80211.h rate_info
|
||||||
!Finclude/net/cfg80211.h station_info
|
!Finclude/net/cfg80211.h station_info
|
||||||
|
@ -435,7 +434,6 @@
|
||||||
<section id="ps-client">
|
<section id="ps-client">
|
||||||
<title>support for powersaving clients</title>
|
<title>support for powersaving clients</title>
|
||||||
!Pinclude/net/mac80211.h AP support for powersaving clients
|
!Pinclude/net/mac80211.h AP support for powersaving clients
|
||||||
</section>
|
|
||||||
!Finclude/net/mac80211.h ieee80211_get_buffered_bc
|
!Finclude/net/mac80211.h ieee80211_get_buffered_bc
|
||||||
!Finclude/net/mac80211.h ieee80211_beacon_get
|
!Finclude/net/mac80211.h ieee80211_beacon_get
|
||||||
!Finclude/net/mac80211.h ieee80211_sta_eosp
|
!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_ps_transition_ni
|
||||||
!Finclude/net/mac80211.h ieee80211_sta_set_buffered
|
!Finclude/net/mac80211.h ieee80211_sta_set_buffered
|
||||||
!Finclude/net/mac80211.h ieee80211_sta_block_awake
|
!Finclude/net/mac80211.h ieee80211_sta_block_awake
|
||||||
|
</section>
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
<chapter id="multi-iface">
|
<chapter id="multi-iface">
|
||||||
|
@ -488,8 +487,8 @@
|
||||||
<title>RX A-MPDU aggregation</title>
|
<title>RX A-MPDU aggregation</title>
|
||||||
!Pnet/mac80211/agg-rx.c RX A-MPDU aggregation
|
!Pnet/mac80211/agg-rx.c RX A-MPDU aggregation
|
||||||
!Cnet/mac80211/agg-rx.c
|
!Cnet/mac80211/agg-rx.c
|
||||||
</sect1>
|
|
||||||
!Finclude/net/mac80211.h ieee80211_ampdu_mlme_action
|
!Finclude/net/mac80211.h ieee80211_ampdu_mlme_action
|
||||||
|
</sect1>
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
<chapter id="smps">
|
<chapter id="smps">
|
||||||
|
|
|
@ -56,7 +56,7 @@ htmldocs: $(HTML)
|
||||||
|
|
||||||
MAN := $(patsubst %.xml, %.9, $(BOOKS))
|
MAN := $(patsubst %.xml, %.9, $(BOOKS))
|
||||||
mandocs: $(MAN)
|
mandocs: $(MAN)
|
||||||
$(if $(wildcard $(obj)/man/*.9),gzip -f $(obj)/man/*.9)
|
find $(obj)/man -name '*.9' | xargs gzip -f
|
||||||
|
|
||||||
installmandocs: mandocs
|
installmandocs: mandocs
|
||||||
mkdir -p /usr/local/man/man9/
|
mkdir -p /usr/local/man/man9/
|
||||||
|
|
|
@ -111,7 +111,7 @@
|
||||||
<para>
|
<para>
|
||||||
This specification is intended for consumers of the kernel crypto
|
This specification is intended for consumers of the kernel crypto
|
||||||
API as well as for developers implementing ciphers. This API
|
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
|
to data transformation implementations (i.e. implementations of
|
||||||
ciphers and other transformations (such as CRC or even compression
|
ciphers and other transformations (such as CRC or even compression
|
||||||
algorithms) that can register with the kernel crypto API).
|
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/mptfc.c
|
||||||
!Idrivers/message/fusion/mptlan.c
|
!Idrivers/message/fusion/mptlan.c
|
||||||
</sect1>
|
</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>
|
||||||
|
|
||||||
<chapter id="snddev">
|
<chapter id="snddev">
|
||||||
|
|
|
@ -239,6 +239,14 @@
|
||||||
Driver supports dedicated render nodes.
|
Driver supports dedicated render nodes.
|
||||||
</para></listitem>
|
</para></listitem>
|
||||||
</varlistentry>
|
</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>
|
</variablelist>
|
||||||
</sect3>
|
</sect3>
|
||||||
<sect3>
|
<sect3>
|
||||||
|
@ -1377,7 +1385,7 @@ int max_width, max_height;</synopsis>
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
DRM_PLANE_TYPE_PRIMARY represents a "main" plane for a CRTC. Primary
|
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"/>.
|
operations described in <xref linkend="drm-kms-crtcops"/>.
|
||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
|
@ -2362,6 +2370,7 @@ void intel_crt_init(struct drm_device *dev)
|
||||||
</sect2>
|
</sect2>
|
||||||
<sect2>
|
<sect2>
|
||||||
<title>Modeset Helper Functions Reference</title>
|
<title>Modeset Helper Functions Reference</title>
|
||||||
|
!Iinclude/drm/drm_crtc_helper.h
|
||||||
!Edrivers/gpu/drm/drm_crtc_helper.c
|
!Edrivers/gpu/drm/drm_crtc_helper.c
|
||||||
!Pdrivers/gpu/drm/drm_crtc_helper.c overview
|
!Pdrivers/gpu/drm/drm_crtc_helper.c overview
|
||||||
</sect2>
|
</sect2>
|
||||||
|
@ -2564,8 +2573,8 @@ void intel_crt_init(struct drm_device *dev)
|
||||||
<td valign="top" >Description/Restrictions</td>
|
<td valign="top" >Description/Restrictions</td>
|
||||||
</tr>
|
</tr>
|
||||||
<tr>
|
<tr>
|
||||||
<td rowspan="25" valign="top" >DRM</td>
|
<td rowspan="36" valign="top" >DRM</td>
|
||||||
<td rowspan="4" valign="top" >Generic</td>
|
<td rowspan="5" valign="top" >Connector</td>
|
||||||
<td valign="top" >“EDID”</td>
|
<td valign="top" >“EDID”</td>
|
||||||
<td valign="top" >BLOB | IMMUTABLE</td>
|
<td valign="top" >BLOB | IMMUTABLE</td>
|
||||||
<td valign="top" >0</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>
|
<td valign="top" >Contains tiling information for a connector.</td>
|
||||||
</tr>
|
</tr>
|
||||||
<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" >“type”</td>
|
||||||
<td valign="top" >ENUM | IMMUTABLE</td>
|
<td valign="top" >ENUM | IMMUTABLE</td>
|
||||||
<td valign="top" >{ "Overlay", "Primary", "Cursor" }</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>
|
<td valign="top" >Plane type</td>
|
||||||
</tr>
|
</tr>
|
||||||
<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 rowspan="2" valign="top" >DVI-I</td>
|
||||||
<td valign="top" >“subconnector”</td>
|
<td valign="top" >“subconnector”</td>
|
||||||
<td valign="top" >ENUM</td>
|
<td valign="top" >ENUM</td>
|
||||||
|
@ -3883,6 +3969,7 @@ int num_ioctls;</synopsis>
|
||||||
<title>Runtime Power Management</title>
|
<title>Runtime Power Management</title>
|
||||||
!Pdrivers/gpu/drm/i915/intel_runtime_pm.c runtime pm
|
!Pdrivers/gpu/drm/i915/intel_runtime_pm.c runtime pm
|
||||||
!Idrivers/gpu/drm/i915/intel_runtime_pm.c
|
!Idrivers/gpu/drm/i915/intel_runtime_pm.c
|
||||||
|
!Idrivers/gpu/drm/i915/intel_uncore.c
|
||||||
</sect2>
|
</sect2>
|
||||||
<sect2>
|
<sect2>
|
||||||
<title>Interrupt Handling</title>
|
<title>Interrupt Handling</title>
|
||||||
|
@ -3931,6 +4018,11 @@ int num_ioctls;</synopsis>
|
||||||
framebuffer compression and panel self refresh.
|
framebuffer compression and panel self refresh.
|
||||||
</para>
|
</para>
|
||||||
</sect2>
|
</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>
|
<sect2>
|
||||||
<title>Output Probing</title>
|
<title>Output Probing</title>
|
||||||
<para>
|
<para>
|
||||||
|
@ -3949,6 +4041,11 @@ int num_ioctls;</synopsis>
|
||||||
<title>Panel Self Refresh PSR (PSR/SRD)</title>
|
<title>Panel Self Refresh PSR (PSR/SRD)</title>
|
||||||
!Pdrivers/gpu/drm/i915/intel_psr.c Panel Self Refresh (PSR/SRD)
|
!Pdrivers/gpu/drm/i915/intel_psr.c Panel Self Refresh (PSR/SRD)
|
||||||
!Idrivers/gpu/drm/i915/intel_psr.c
|
!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>
|
||||||
<sect2>
|
<sect2>
|
||||||
<title>DPIO</title>
|
<title>DPIO</title>
|
||||||
|
@ -4052,12 +4149,33 @@ int num_ioctls;</synopsis>
|
||||||
<title>Batchbuffer Parsing</title>
|
<title>Batchbuffer Parsing</title>
|
||||||
!Pdrivers/gpu/drm/i915/i915_cmd_parser.c batch buffer command parser
|
!Pdrivers/gpu/drm/i915/i915_cmd_parser.c batch buffer command parser
|
||||||
!Idrivers/gpu/drm/i915/i915_cmd_parser.c
|
!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>
|
||||||
<sect2>
|
<sect2>
|
||||||
<title>Logical Rings, Logical Ring Contexts and Execlists</title>
|
<title>Logical Rings, Logical Ring Contexts and Execlists</title>
|
||||||
!Pdrivers/gpu/drm/i915/intel_lrc.c Logical Rings, Logical Ring Contexts and Execlists
|
!Pdrivers/gpu/drm/i915/intel_lrc.c Logical Rings, Logical Ring Contexts and Execlists
|
||||||
!Idrivers/gpu/drm/i915/intel_lrc.c
|
!Idrivers/gpu/drm/i915/intel_lrc.c
|
||||||
</sect2>
|
</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>
|
||||||
|
|
||||||
<sect1>
|
<sect1>
|
||||||
|
|
|
@ -75,7 +75,7 @@
|
||||||
a development machine and the other is the target machine. The
|
a development machine and the other is the target machine. The
|
||||||
kernel to be debugged runs on the target machine. The development
|
kernel to be debugged runs on the target machine. The development
|
||||||
machine runs an instance of gdb against the vmlinux file which
|
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
|
uImage...). In gdb the developer specifies the connection
|
||||||
parameters and connects to kgdb. The type of connection a
|
parameters and connects to kgdb. The type of connection a
|
||||||
developer makes with gdb depends on the availability of kgdb I/O
|
developer makes with gdb depends on the availability of kgdb I/O
|
||||||
|
@ -95,7 +95,7 @@
|
||||||
<title>Kernel config options for kgdb</title>
|
<title>Kernel config options for kgdb</title>
|
||||||
<para>
|
<para>
|
||||||
To enable <symbol>CONFIG_KGDB</symbol> you should look under
|
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>
|
||||||
<para>
|
<para>
|
||||||
While it is not a hard requirement that you have symbols in your
|
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.
|
kernel with debug info" in the config menu.
|
||||||
</para>
|
</para>
|
||||||
<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
|
<symbol>CONFIG_FRAME_POINTER</symbol> kernel option which is called "Compile the
|
||||||
kernel with frame pointers" in the config menu. This option
|
kernel with frame pointers" in the config menu. This option
|
||||||
inserts code to into the compiled executable which saves the frame
|
inserts code to into the compiled executable which saves the frame
|
||||||
|
@ -181,7 +181,7 @@
|
||||||
<para>This section describes the various runtime kernel
|
<para>This section describes the various runtime kernel
|
||||||
parameters that affect the configuration of the kernel debugger.
|
parameters that affect the configuration of the kernel debugger.
|
||||||
The following chapter covers using kdb and kgdb as well as
|
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">
|
<sect1 id="kgdboc">
|
||||||
<title>Kernel parameter: kgdboc</title>
|
<title>Kernel parameter: kgdboc</title>
|
||||||
<para>The kgdboc driver was originally an abbreviation meant to
|
<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.
|
may be configured as a kernel built-in or a kernel loadable module.
|
||||||
You can only make use of <constant>kgdbwait</constant> and early
|
You can only make use of <constant>kgdbwait</constant> and early
|
||||||
debugging if you build kgdboc into the kernel as a built-in.
|
debugging if you build kgdboc into the kernel as a built-in.
|
||||||
|
</para>
|
||||||
<para>Optionally you can elect to activate kms (Kernel Mode
|
<para>Optionally you can elect to activate kms (Kernel Mode
|
||||||
Setting) integration. When you use kms with kgdboc and you have a
|
Setting) integration. When you use kms with kgdboc and you have a
|
||||||
video driver that has atomic mode setting hooks, it is possible to
|
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
|
crashes or doing analysis of memory with kdb while allowing the
|
||||||
full graphics console applications to run.
|
full graphics console applications to run.
|
||||||
</para>
|
</para>
|
||||||
</para>
|
|
||||||
<sect2 id="kgdbocArgs">
|
<sect2 id="kgdbocArgs">
|
||||||
<title>kgdboc arguments</title>
|
<title>kgdboc arguments</title>
|
||||||
<para>Usage: <constant>kgdboc=[kms][[,]kbd][[,]serial_device][,baud]</constant></para>
|
<para>Usage: <constant>kgdboc=[kms][[,]kbd][[,]serial_device][,baud]</constant></para>
|
||||||
|
@ -219,8 +219,8 @@
|
||||||
<listitem><para>kbd = Keyboard</para></listitem>
|
<listitem><para>kbd = Keyboard</para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</para>
|
</para>
|
||||||
<para>You can configure kgdboc to use the keyboard, and or a serial
|
<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
|
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
|
following scenarios. The order listed above must be observed if
|
||||||
you use any of the optional configurations together. Using kms +
|
you use any of the optional configurations together. Using kms +
|
||||||
only gdb is generally not a useful combination.</para>
|
only gdb is generally not a useful combination.</para>
|
||||||
|
@ -261,11 +261,8 @@
|
||||||
</sect3>
|
</sect3>
|
||||||
<sect3 id="kgdbocArgs3">
|
<sect3 id="kgdbocArgs3">
|
||||||
<title>More examples</title>
|
<title>More examples</title>
|
||||||
<para>You can configure kgdboc to use the keyboard, and or a serial
|
<para>You can configure kgdboc to use the keyboard, and/or a serial device
|
||||||
device depending on if you are using kdb and or kgdb, in one of the
|
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
|
|
||||||
following scenarios.
|
following scenarios.
|
||||||
<orderedlist>
|
<orderedlist>
|
||||||
<listitem><para>kdb and kgdb over only a serial port</para>
|
<listitem><para>kdb and kgdb over only a serial port</para>
|
||||||
|
@ -287,7 +284,6 @@
|
||||||
</listitem>
|
</listitem>
|
||||||
</orderedlist>
|
</orderedlist>
|
||||||
</para>
|
</para>
|
||||||
</sect3>
|
|
||||||
<para>NOTE: Kgdboc does not support interrupting the target via the
|
<para>NOTE: Kgdboc does not support interrupting the target via the
|
||||||
gdb remote protocol. You must manually send a sysrq-g unless you
|
gdb remote protocol. You must manually send a sysrq-g unless you
|
||||||
have a proxy that splits console output to a terminal program.
|
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
|
as well as on the initial connect, or to use a debugger proxy that
|
||||||
allows an unmodified gdb to do the debugging.
|
allows an unmodified gdb to do the debugging.
|
||||||
</para>
|
</para>
|
||||||
|
</sect3>
|
||||||
</sect2>
|
</sect2>
|
||||||
</sect1>
|
</sect1>
|
||||||
<sect1 id="kgdbwait">
|
<sect1 id="kgdbwait">
|
||||||
|
@ -315,7 +312,7 @@
|
||||||
<para>
|
<para>
|
||||||
The Kernel command line option <constant>kgdbwait</constant> makes
|
The Kernel command line option <constant>kgdbwait</constant> makes
|
||||||
kgdb wait for a debugger connection during booting of a kernel. You
|
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
|
kernel and you specified the I/O driver configuration as a kernel
|
||||||
command line option. The kgdbwait parameter should always follow the
|
command line option. The kgdbwait parameter should always follow the
|
||||||
configuration parameter for the kgdb I/O driver in the kernel
|
configuration parameter for the kgdb I/O driver in the kernel
|
||||||
|
@ -353,12 +350,12 @@
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</orderedlist>
|
</orderedlist>
|
||||||
|
</para>
|
||||||
<para>IMPORTANT NOTE: You cannot use kgdboc + kgdbcon on a tty that is an
|
<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>
|
||||||
<para>It is possible to use this option with kgdboc on a tty that is not a system console.
|
<para>It is possible to use this option with kgdboc on a tty that is not a system console.
|
||||||
</para>
|
</para>
|
||||||
</para>
|
|
||||||
</sect1>
|
</sect1>
|
||||||
<sect1 id="kgdbreboot">
|
<sect1 id="kgdbreboot">
|
||||||
<title>Run time parameter: kgdbreboot</title>
|
<title>Run time parameter: kgdbreboot</title>
|
||||||
|
@ -386,12 +383,12 @@
|
||||||
<title>Quick start for kdb on a serial port</title>
|
<title>Quick start for kdb on a serial port</title>
|
||||||
<para>This is a quick example of how to use kdb.</para>
|
<para>This is a quick example of how to use kdb.</para>
|
||||||
<para><orderedlist>
|
<para><orderedlist>
|
||||||
<listitem><para>Boot kernel with arguments:
|
<listitem><para>Configure kgdboc at boot using kernel parameters:
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem><para><constant>console=ttyS0,115200 kgdboc=ttyS0,115200</constant></para></listitem>
|
<listitem><para><constant>console=ttyS0,115200 kgdboc=ttyS0,115200</constant></para></listitem>
|
||||||
</itemizedlist></para>
|
</itemizedlist></para>
|
||||||
<para>OR</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>
|
<itemizedlist>
|
||||||
<listitem><para><constant>echo ttyS0 > /sys/module/kgdboc/parameters/kgdboc</constant></para></listitem>
|
<listitem><para><constant>echo ttyS0 > /sys/module/kgdboc/parameters/kgdboc</constant></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
@ -442,12 +439,12 @@
|
||||||
<title>Quick start for kdb using a keyboard connected console</title>
|
<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>This is a quick example of how to use kdb with a keyboard.</para>
|
||||||
<para><orderedlist>
|
<para><orderedlist>
|
||||||
<listitem><para>Boot kernel with arguments:
|
<listitem><para>Configure kgdboc at boot using kernel parameters:
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem><para><constant>kgdboc=kbd</constant></para></listitem>
|
<listitem><para><constant>kgdboc=kbd</constant></para></listitem>
|
||||||
</itemizedlist></para>
|
</itemizedlist></para>
|
||||||
<para>OR</para>
|
<para>OR</para>
|
||||||
<para>Configure kgdboc after the kernel booted:
|
<para>Configure kgdboc after the kernel has booted:
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem><para><constant>echo kbd > /sys/module/kgdboc/parameters/kgdboc</constant></para></listitem>
|
<listitem><para><constant>echo kbd > /sys/module/kgdboc/parameters/kgdboc</constant></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
@ -501,12 +498,12 @@
|
||||||
<title>Connecting with gdb to a serial port</title>
|
<title>Connecting with gdb to a serial port</title>
|
||||||
<orderedlist>
|
<orderedlist>
|
||||||
<listitem><para>Configure kgdboc</para>
|
<listitem><para>Configure kgdboc</para>
|
||||||
<para>Boot kernel with arguments:
|
<para>Configure kgdboc at boot using kernel parameters:
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem><para><constant>kgdboc=ttyS0,115200</constant></para></listitem>
|
<listitem><para><constant>kgdboc=ttyS0,115200</constant></para></listitem>
|
||||||
</itemizedlist></para>
|
</itemizedlist></para>
|
||||||
<para>OR</para>
|
<para>OR</para>
|
||||||
<para>Configure kgdboc after the kernel booted:
|
<para>Configure kgdboc after the kernel has booted:
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem><para><constant>echo ttyS0 > /sys/module/kgdboc/parameters/kgdboc</constant></para></listitem>
|
<listitem><para><constant>echo ttyS0 > /sys/module/kgdboc/parameters/kgdboc</constant></para></listitem>
|
||||||
</itemizedlist></para>
|
</itemizedlist></para>
|
||||||
|
@ -536,7 +533,7 @@
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Connect from from gdb</para>
|
<para>Connect from gdb</para>
|
||||||
<para>
|
<para>
|
||||||
Example (using a directly connected port):
|
Example (using a directly connected port):
|
||||||
</para>
|
</para>
|
||||||
|
@ -584,7 +581,7 @@
|
||||||
<para>
|
<para>
|
||||||
There are two ways to switch from kgdb to kdb: you can use gdb to
|
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.
|
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
|
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.
|
to note that you have to type the sequence correctly in one pass.
|
||||||
You cannot type a backspace or delete because kgdb will interpret
|
You cannot type a backspace or delete because kgdb will interpret
|
||||||
|
@ -783,10 +780,14 @@ Task Addr Pid Parent [*] cpu State Thread Command
|
||||||
NUMREGBYTES: The size in bytes of all of the registers, so
|
NUMREGBYTES: The size in bytes of all of the registers, so
|
||||||
that we can ensure they will all fit into a packet.
|
that we can ensure they will all fit into a packet.
|
||||||
</para>
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
BUFMAX: The size in bytes of the buffer GDB will read into.
|
BUFMAX: The size in bytes of the buffer GDB will read into.
|
||||||
This must be larger than NUMREGBYTES.
|
This must be larger than NUMREGBYTES.
|
||||||
</para>
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
CACHE_FLUSH_IS_SAFE: Set to 1 if it is always safe to call
|
CACHE_FLUSH_IS_SAFE: Set to 1 if it is always safe to call
|
||||||
flush_cache_range or flush_icache_range. On some architectures,
|
flush_cache_range or flush_icache_range. On some architectures,
|
||||||
|
@ -812,8 +813,8 @@ Task Addr Pid Parent [*] cpu State Thread Command
|
||||||
<para>
|
<para>
|
||||||
The kgdboc driver is actually a very thin driver that relies on the
|
The kgdboc driver is actually a very thin driver that relies on the
|
||||||
underlying low level to the hardware driver having "polling hooks"
|
underlying low level to the hardware driver having "polling hooks"
|
||||||
which the to which the tty driver is attached. In the initial
|
to which the tty driver is attached. In the initial
|
||||||
implementation of kgdboc it the serial_core was changed to expose a
|
implementation of kgdboc the serial_core was changed to expose a
|
||||||
low level UART hook for doing polled mode reading and writing of 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
|
single character while in an atomic context. When kgdb makes an I/O
|
||||||
request to the debugger, kgdboc invokes a callback in the serial
|
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></entry></row>
|
||||||
<row>
|
<row>
|
||||||
<entry spanname="id"><constant>V4L2_CID_MPEG_MFC51_VIDEO_DECODER_H264_DISPLAY_DELAY_ENABLE</constant> </entry>
|
<entry spanname="id"><constant>V4L2_CID_MPEG_MFC51_VIDEO_DECODER_H264_DISPLAY_DELAY_ENABLE</constant> </entry>
|
||||||
<entry>integer</entry>
|
<entry>boolean</entry>
|
||||||
</row><row><entry spanname="descr">If the display delay is enabled then the decoder has to return a
|
</row><row><entry spanname="descr">If the display delay is enabled then the decoder is forced to return a
|
||||||
CAPTURE buffer after processing a certain number of OUTPUT buffers. If this number is low, then it may result in
|
CAPTURE buffer (decoded frame) after processing a certain number of OUTPUT buffers. The delay can be set through
|
||||||
buffers not being dequeued in display order. In addition hardware may still use those buffers as reference, thus
|
<constant>V4L2_CID_MPEG_MFC51_VIDEO_DECODER_H264_DISPLAY_DELAY</constant>. This feature can be used for example
|
||||||
application should not write to those buffers. This feature can be used for example for generating thumbnails of videos.
|
for generating thumbnails of videos. Applicable to the H264 decoder.
|
||||||
Applicable to the H264 decoder.
|
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
<row><entry></entry></row>
|
<row><entry></entry></row>
|
||||||
|
|
|
@ -17,7 +17,7 @@
|
||||||
<refsect1>
|
<refsect1>
|
||||||
<title>Description</title>
|
<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
|
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
|
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
|
and n/2 blue or red samples, with alternating red and blue rows. Bytes are
|
||||||
|
|
|
@ -25,7 +25,7 @@
|
||||||
</refnamediv>
|
</refnamediv>
|
||||||
<refsect1>
|
<refsect1>
|
||||||
<title>Description</title>
|
<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,
|
formats with 10 bits per color compressed to 8 bits each,
|
||||||
using the A-LAW algorithm. Each color component consumes 8
|
using the A-LAW algorithm. Each color component consumes 8
|
||||||
bits of memory. In other respects this format is similar to
|
bits of memory. In other respects this format is similar to
|
||||||
|
|
|
@ -18,7 +18,7 @@
|
||||||
<refsect1>
|
<refsect1>
|
||||||
<title>Description</title>
|
<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
|
with 10 bits per colour compressed to 8 bits each, using DPCM
|
||||||
compression. DPCM, differential pulse-code modulation, is lossy.
|
compression. DPCM, differential pulse-code modulation, is lossy.
|
||||||
Each colour component consumes 8 bits of memory. In other respects
|
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>
|
<refsect1>
|
||||||
<title>Description</title>
|
<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
|
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
|
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
|
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-srggb8;
|
||||||
&sub-sbggr16;
|
&sub-sbggr16;
|
||||||
&sub-srggb10;
|
&sub-srggb10;
|
||||||
|
&sub-srggb10p;
|
||||||
&sub-srggb10alaw8;
|
&sub-srggb10alaw8;
|
||||||
&sub-srggb10dpcm8;
|
&sub-srggb10dpcm8;
|
||||||
&sub-srggb12;
|
&sub-srggb12;
|
||||||
|
|
|
@ -212,11 +212,3 @@ standards set in the <structfield>standards</structfield> field.
|
||||||
&return-value;
|
&return-value;
|
||||||
</refsect1>
|
</refsect1>
|
||||||
</refentry>
|
</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>
|
</variablelist>
|
||||||
</refsect1>
|
</refsect1>
|
||||||
</refentry>
|
</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>
|
</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="using uio_dmem_genirq">
|
<sect1 id="using-uio_dmem_genirq">
|
||||||
<title>Using uio_dmem_genirq for platform devices</title>
|
<title>Using uio_dmem_genirq for platform devices</title>
|
||||||
<para>
|
<para>
|
||||||
In addition to statically allocated memory ranges, they may also be
|
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:
|
following elements:
|
||||||
</para>
|
</para>
|
||||||
<itemizedlist>
|
<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
|
structure used as the <varname>uio_pdrv_genirq</varname> platform
|
||||||
data</listitem>
|
data</para></listitem>
|
||||||
<listitem><varname>unsigned int *dynamic_region_sizes</varname>:
|
<listitem><para><varname>unsigned int *dynamic_region_sizes</varname>:
|
||||||
Pointer to list of sizes of dynamic memory regions to be mapped into
|
Pointer to list of sizes of dynamic memory regions to be mapped into
|
||||||
user space.
|
user space.
|
||||||
</listitem>
|
</para></listitem>
|
||||||
<listitem><varname>unsigned int num_dynamic_regions</varname>:
|
<listitem><para><varname>unsigned int num_dynamic_regions</varname>:
|
||||||
Number of elements in <varname>dynamic_region_sizes</varname> array.
|
Number of elements in <varname>dynamic_region_sizes</varname> array.
|
||||||
</listitem>
|
</para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
<para>
|
<para>
|
||||||
The dynamic regions defined in the platform data will be appended to
|
The dynamic regions defined in the platform data will be appended to
|
||||||
|
|
|
@ -15,7 +15,7 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
|
||||||
21 seconds.
|
21 seconds.
|
||||||
|
|
||||||
This configuration parameter may be changed at runtime via the
|
This configuration parameter may be changed at runtime via the
|
||||||
/sys/module/rcutree/parameters/rcu_cpu_stall_timeout, however
|
/sys/module/rcupdate/parameters/rcu_cpu_stall_timeout, however
|
||||||
this parameter is checked only at the beginning of a cycle.
|
this parameter is checked only at the beginning of a cycle.
|
||||||
So if you are 10 seconds into a 40-second stall, setting this
|
So if you are 10 seconds into a 40-second stall, setting this
|
||||||
sysfs parameter to (say) five will shorten the timeout for the
|
sysfs parameter to (say) five will shorten the timeout for the
|
||||||
|
@ -152,6 +152,15 @@ no non-lazy callbacks ("." is printed otherwise, as shown above) and
|
||||||
"D" indicates that dyntick-idle processing is enabled ("." is printed
|
"D" indicates that dyntick-idle processing is enabled ("." is printed
|
||||||
otherwise, for example, if disabled via the "nohz=" kernel boot parameter).
|
otherwise, for example, if disabled via the "nohz=" kernel boot parameter).
|
||||||
|
|
||||||
|
If the relevant grace-period kthread has been unable to run prior to
|
||||||
|
the stall warning, the following additional line is printed:
|
||||||
|
|
||||||
|
rcu_preempt kthread starved for 2023 jiffies!
|
||||||
|
|
||||||
|
Starving the grace-period kthreads of CPU time can of course result in
|
||||||
|
RCU CPU stall warnings even when all CPUs and tasks have passed through
|
||||||
|
the required quiescent states.
|
||||||
|
|
||||||
|
|
||||||
Multiple Warnings From One Stall
|
Multiple Warnings From One Stall
|
||||||
|
|
||||||
|
@ -187,6 +196,11 @@ o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the
|
||||||
behavior, you might need to replace some of the cond_resched()
|
behavior, you might need to replace some of the cond_resched()
|
||||||
calls with calls to cond_resched_rcu_qs().
|
calls with calls to cond_resched_rcu_qs().
|
||||||
|
|
||||||
|
o Anything that prevents RCU's grace-period kthreads from running.
|
||||||
|
This can result in the "All QSes seen" console-log message.
|
||||||
|
This message will include information on when the kthread last
|
||||||
|
ran and how often it should be expected to run.
|
||||||
|
|
||||||
o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might
|
o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might
|
||||||
happen to preempt a low-priority task in the middle of an RCU
|
happen to preempt a low-priority task in the middle of an RCU
|
||||||
read-side critical section. This is especially damaging if
|
read-side critical section. This is especially damaging if
|
||||||
|
|
|
@ -56,14 +56,14 @@ rcuboost:
|
||||||
|
|
||||||
The output of "cat rcu/rcu_preempt/rcudata" looks as follows:
|
The output of "cat rcu/rcu_preempt/rcudata" looks as follows:
|
||||||
|
|
||||||
0!c=30455 g=30456 pq=1 qp=1 dt=126535/140000000000000/0 df=2002 of=4 ql=0/0 qs=N... b=10 ci=74572 nci=0 co=1131 ca=716
|
0!c=30455 g=30456 pq=1/0 qp=1 dt=126535/140000000000000/0 df=2002 of=4 ql=0/0 qs=N... b=10 ci=74572 nci=0 co=1131 ca=716
|
||||||
1!c=30719 g=30720 pq=1 qp=0 dt=132007/140000000000000/0 df=1874 of=10 ql=0/0 qs=N... b=10 ci=123209 nci=0 co=685 ca=982
|
1!c=30719 g=30720 pq=1/0 qp=0 dt=132007/140000000000000/0 df=1874 of=10 ql=0/0 qs=N... b=10 ci=123209 nci=0 co=685 ca=982
|
||||||
2!c=30150 g=30151 pq=1 qp=1 dt=138537/140000000000000/0 df=1707 of=8 ql=0/0 qs=N... b=10 ci=80132 nci=0 co=1328 ca=1458
|
2!c=30150 g=30151 pq=1/1 qp=1 dt=138537/140000000000000/0 df=1707 of=8 ql=0/0 qs=N... b=10 ci=80132 nci=0 co=1328 ca=1458
|
||||||
3 c=31249 g=31250 pq=1 qp=0 dt=107255/140000000000000/0 df=1749 of=6 ql=0/450 qs=NRW. b=10 ci=151700 nci=0 co=509 ca=622
|
3 c=31249 g=31250 pq=1/1 qp=0 dt=107255/140000000000000/0 df=1749 of=6 ql=0/450 qs=NRW. b=10 ci=151700 nci=0 co=509 ca=622
|
||||||
4!c=29502 g=29503 pq=1 qp=1 dt=83647/140000000000000/0 df=965 of=5 ql=0/0 qs=N... b=10 ci=65643 nci=0 co=1373 ca=1521
|
4!c=29502 g=29503 pq=1/0 qp=1 dt=83647/140000000000000/0 df=965 of=5 ql=0/0 qs=N... b=10 ci=65643 nci=0 co=1373 ca=1521
|
||||||
5 c=31201 g=31202 pq=1 qp=1 dt=70422/0/0 df=535 of=7 ql=0/0 qs=.... b=10 ci=58500 nci=0 co=764 ca=698
|
5 c=31201 g=31202 pq=1/0 qp=1 dt=70422/0/0 df=535 of=7 ql=0/0 qs=.... b=10 ci=58500 nci=0 co=764 ca=698
|
||||||
6!c=30253 g=30254 pq=1 qp=1 dt=95363/140000000000000/0 df=780 of=5 ql=0/0 qs=N... b=10 ci=100607 nci=0 co=1414 ca=1353
|
6!c=30253 g=30254 pq=1/0 qp=1 dt=95363/140000000000000/0 df=780 of=5 ql=0/0 qs=N... b=10 ci=100607 nci=0 co=1414 ca=1353
|
||||||
7 c=31178 g=31178 pq=1 qp=0 dt=91536/0/0 df=547 of=4 ql=0/0 qs=.... b=10 ci=109819 nci=0 co=1115 ca=969
|
7 c=31178 g=31178 pq=1/0 qp=0 dt=91536/0/0 df=547 of=4 ql=0/0 qs=.... b=10 ci=109819 nci=0 co=1115 ca=969
|
||||||
|
|
||||||
This file has one line per CPU, or eight for this 8-CPU system.
|
This file has one line per CPU, or eight for this 8-CPU system.
|
||||||
The fields are as follows:
|
The fields are as follows:
|
||||||
|
@ -188,14 +188,14 @@ o "ca" is the number of RCU callbacks that have been adopted by this
|
||||||
Kernels compiled with CONFIG_RCU_BOOST=y display the following from
|
Kernels compiled with CONFIG_RCU_BOOST=y display the following from
|
||||||
/debug/rcu/rcu_preempt/rcudata:
|
/debug/rcu/rcu_preempt/rcudata:
|
||||||
|
|
||||||
0!c=12865 g=12866 pq=1 qp=1 dt=83113/140000000000000/0 df=288 of=11 ql=0/0 qs=N... kt=0/O ktl=944 b=10 ci=60709 nci=0 co=748 ca=871
|
0!c=12865 g=12866 pq=1/0 qp=1 dt=83113/140000000000000/0 df=288 of=11 ql=0/0 qs=N... kt=0/O ktl=944 b=10 ci=60709 nci=0 co=748 ca=871
|
||||||
1 c=14407 g=14408 pq=1 qp=0 dt=100679/140000000000000/0 df=378 of=7 ql=0/119 qs=NRW. kt=0/W ktl=9b6 b=10 ci=109740 nci=0 co=589 ca=485
|
1 c=14407 g=14408 pq=1/0 qp=0 dt=100679/140000000000000/0 df=378 of=7 ql=0/119 qs=NRW. kt=0/W ktl=9b6 b=10 ci=109740 nci=0 co=589 ca=485
|
||||||
2 c=14407 g=14408 pq=1 qp=0 dt=105486/0/0 df=90 of=9 ql=0/89 qs=NRW. kt=0/W ktl=c0c b=10 ci=83113 nci=0 co=533 ca=490
|
2 c=14407 g=14408 pq=1/0 qp=0 dt=105486/0/0 df=90 of=9 ql=0/89 qs=NRW. kt=0/W ktl=c0c b=10 ci=83113 nci=0 co=533 ca=490
|
||||||
3 c=14407 g=14408 pq=1 qp=0 dt=107138/0/0 df=142 of=8 ql=0/188 qs=NRW. kt=0/W ktl=b96 b=10 ci=121114 nci=0 co=426 ca=290
|
3 c=14407 g=14408 pq=1/0 qp=0 dt=107138/0/0 df=142 of=8 ql=0/188 qs=NRW. kt=0/W ktl=b96 b=10 ci=121114 nci=0 co=426 ca=290
|
||||||
4 c=14405 g=14406 pq=1 qp=1 dt=50238/0/0 df=706 of=7 ql=0/0 qs=.... kt=0/W ktl=812 b=10 ci=34929 nci=0 co=643 ca=114
|
4 c=14405 g=14406 pq=1/0 qp=1 dt=50238/0/0 df=706 of=7 ql=0/0 qs=.... kt=0/W ktl=812 b=10 ci=34929 nci=0 co=643 ca=114
|
||||||
5!c=14168 g=14169 pq=1 qp=0 dt=45465/140000000000000/0 df=161 of=11 ql=0/0 qs=N... kt=0/O ktl=b4d b=10 ci=47712 nci=0 co=677 ca=722
|
5!c=14168 g=14169 pq=1/0 qp=0 dt=45465/140000000000000/0 df=161 of=11 ql=0/0 qs=N... kt=0/O ktl=b4d b=10 ci=47712 nci=0 co=677 ca=722
|
||||||
6 c=14404 g=14405 pq=1 qp=0 dt=59454/0/0 df=94 of=6 ql=0/0 qs=.... kt=0/W ktl=e57 b=10 ci=55597 nci=0 co=701 ca=811
|
6 c=14404 g=14405 pq=1/0 qp=0 dt=59454/0/0 df=94 of=6 ql=0/0 qs=.... kt=0/W ktl=e57 b=10 ci=55597 nci=0 co=701 ca=811
|
||||||
7 c=14407 g=14408 pq=1 qp=1 dt=68850/0/0 df=31 of=8 ql=0/0 qs=.... kt=0/W ktl=14bd b=10 ci=77475 nci=0 co=508 ca=1042
|
7 c=14407 g=14408 pq=1/0 qp=1 dt=68850/0/0 df=31 of=8 ql=0/0 qs=.... kt=0/W ktl=14bd b=10 ci=77475 nci=0 co=508 ca=1042
|
||||||
|
|
||||||
This is similar to the output discussed above, but contains the following
|
This is similar to the output discussed above, but contains the following
|
||||||
additional fields:
|
additional fields:
|
||||||
|
|
|
@ -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
|
with "the system." This text is a collection of suggestions which
|
||||||
can greatly increase the chances of your change being accepted.
|
can greatly increase the chances of your change being accepted.
|
||||||
|
|
||||||
Read Documentation/SubmitChecklist for a list of items to check
|
This document contains a large number of suggestions in a relatively terse
|
||||||
before submitting code. If you are submitting a driver, also read
|
format. For detailed information on how the kernel development process
|
||||||
Documentation/SubmittingDrivers.
|
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
|
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
|
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
|
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
|
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"
|
1) "diff -up"
|
||||||
------------
|
------------
|
||||||
|
|
||||||
Use "diff -up" or "diff -uprN" to create patches. git generates patches
|
If you must generate your patches by hand, use "diff -up" or "diff -uprN"
|
||||||
in this form by default; if you're using git, you can skip this section
|
to create patches. Git generates patches in this form by default; if
|
||||||
entirely.
|
you're using git, you can skip this section entirely.
|
||||||
|
|
||||||
All changes to the Linux kernel occur in the form of patches, as
|
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
|
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:
|
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
|
MYFILE= drivers/net/mydriver.c
|
||||||
|
|
||||||
cd $SRCTREE
|
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
|
or unmodified kernel source tree, and generate a diff against your
|
||||||
own source tree. For example:
|
own source tree. For example:
|
||||||
|
|
||||||
MYSRC= /devel/linux-2.6
|
MYSRC= /devel/linux
|
||||||
|
|
||||||
tar xvfz linux-2.6.12.tar.gz
|
tar xvfz linux-3.19.tar.gz
|
||||||
mv linux-2.6.12 linux-2.6.12-vanilla
|
mv linux-3.19 linux-3.19-vanilla
|
||||||
diff -uprN -X linux-2.6.12-vanilla/Documentation/dontdiff \
|
diff -uprN -X linux-3.19-vanilla/Documentation/dontdiff \
|
||||||
linux-2.6.12-vanilla $MYSRC > /tmp/patch
|
linux-3.19-vanilla $MYSRC > /tmp/patch
|
||||||
|
|
||||||
"dontdiff" is a list of files which are generated by the kernel during
|
"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
|
the build process, and should be ignored in any diff(1)-generated
|
||||||
patch. The "dontdiff" file is included in the kernel tree in
|
patch.
|
||||||
2.6.12 and later.
|
|
||||||
|
|
||||||
Make sure your patch does not include any extra files which do not
|
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-
|
belong in a patch submission. Make sure to review your patch -after-
|
||||||
|
@ -83,6 +104,7 @@ is another popular alternative.
|
||||||
|
|
||||||
|
|
||||||
2) Describe your changes.
|
2) Describe your changes.
|
||||||
|
-------------------------
|
||||||
|
|
||||||
Describe your problem. Whether your patch is a one-line bug fix or
|
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
|
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
|
When you submit or resubmit a patch or patch series, include the
|
||||||
complete patch description and justification for it. Don't just
|
complete patch description and justification for it. Don't just
|
||||||
say that this is version N of the patch (series). Don't expect the
|
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.
|
URLs to find the patch description and put that into the patch.
|
||||||
I.e., the patch (series) and its description should be self-contained.
|
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.
|
probably didn't even receive earlier versions of the patch.
|
||||||
|
|
||||||
Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
|
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,
|
platform_set_drvdata(), but left the variable "dev" unused,
|
||||||
delete it.
|
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
|
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
|
git-bisect, please use the 'Fixes:' tag with the first 12 characters of the
|
||||||
SHA-1 ID, and the one line summary.
|
SHA-1 ID, and the one line summary. For example:
|
||||||
Example:
|
|
||||||
|
|
||||||
Fixes: e21d2170f366 ("video: remove unnecessary platform_set_drvdata()")
|
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\")
|
fixes = Fixes: %h (\"%s\")
|
||||||
|
|
||||||
3) Separate your changes.
|
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
|
For example, if your changes include both bug fixes and performance
|
||||||
enhancements for a single driver, separate those changes into two
|
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
|
group those changes into a single patch. Thus a single logical change
|
||||||
is contained within a single patch.
|
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
|
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"
|
complete, that is OK. Simply note "this patch depends on patch X"
|
||||||
in your patch description.
|
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,
|
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.
|
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
|
Check your patch for basic style violations, details of which can be
|
||||||
found in Documentation/CodingStyle. Failure to do so simply wastes
|
found in Documentation/CodingStyle. Failure to do so simply wastes
|
||||||
the reviewers time and will get your patch rejected, probably
|
the reviewers time and will get your patch rejected, probably
|
||||||
without even being read.
|
without even being read.
|
||||||
|
|
||||||
At a minimum you should check your patches with the patch style
|
One significant exception is when moving code from one file to
|
||||||
checker prior to submission (scripts/checkpatch.pl). You should
|
another -- in this case you should not modify the moved code at all in
|
||||||
be able to justify all violations that remain in your patch.
|
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
|
You should also normally choose at least one mailing list to receive a copy
|
||||||
if your change applies to a specific subsystem of the kernel, with
|
of your patch set. linux-kernel@vger.kernel.org functions as a list of
|
||||||
an assigned maintainer. If so, e-mail that person. The script
|
last resort, but the volume on that list has caused a number of developers
|
||||||
scripts/get_maintainer.pl can be very useful at this step.
|
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
|
||||||
If no maintainer is listed, or the maintainer does not respond, send
|
spam unrelated lists, though.
|
||||||
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.
|
|
||||||
|
|
||||||
|
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!!!
|
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
|
Linus Torvalds is the final arbiter of all changes accepted into the
|
||||||
Linux kernel. His e-mail address is <torvalds@linux-foundation.org>.
|
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-
|
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.
|
sending him e-mail.
|
||||||
|
|
||||||
Patches which are bug fixes, are "obvious" changes, or similarly
|
If you have a patch that fixes an exploitable security bug, send that patch
|
||||||
require little discussion should be sent or CC'd to Linus. Patches
|
to security@kernel.org. For severe bugs, a short embargo may be considered
|
||||||
which require discussion or do not have a clear advantage should
|
to allow distrbutors to get the patch out to users; in such cases,
|
||||||
usually be sent first to linux-kernel. Only after the patch is
|
obviously, the patch should not be sent to any public lists.
|
||||||
discussed should the patch then be submitted to Linus.
|
|
||||||
|
|
||||||
|
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,
|
If changes affect userland-kernel interfaces, please send the MAN-PAGES
|
||||||
so that they may comment on it and offer code review and suggestions.
|
maintainer (as listed in the MAINTAINERS file) a man-pages patch, or at
|
||||||
linux-kernel is the primary Linux kernel developer mailing list.
|
least a notification of the change, so that some information makes its way
|
||||||
Other mailing lists are available for specific subsystems, such as
|
into the manual pages. User-space API changes should also be copied to
|
||||||
USB, framebuffer devices, the VFS, the SCSI subsystem, etc. See the
|
linux-api@vger.kernel.org.
|
||||||
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.
|
|
||||||
|
|
||||||
For small patches you may want to CC the Trivial Patch Monkey
|
For small patches you may want to CC the Trivial Patch Monkey
|
||||||
trivial@kernel.org which collects "trivial" patches. Have a look
|
trivial@kernel.org which collects "trivial" patches. Have a look
|
||||||
into the MAINTAINERS file for its current manager.
|
into the MAINTAINERS file for its current manager.
|
||||||
Trivial patches must qualify for one of the following rules:
|
Trivial patches must qualify for one of the following rules:
|
||||||
Spelling fixes in documentation
|
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)
|
Warning fixes (cluttering with useless warnings is bad)
|
||||||
Compilation fixes (only if they are actually correct)
|
Compilation fixes (only if they are actually correct)
|
||||||
Runtime fixes (only if they actually fix things)
|
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
|
Contact detail and documentation fixes
|
||||||
Non-portable code replaced by portable code (even in arch-specific,
|
Non-portable code replaced by portable code (even in arch-specific,
|
||||||
since people copy, as long as it's trivial)
|
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
|
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
|
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
|
See Documentation/email-clients.txt for hints about configuring
|
||||||
your e-mail client so that it sends your patches untouched.
|
your e-mail client so that it sends your patches untouched.
|
||||||
|
|
||||||
8) E-mail size.
|
7) E-mail size.
|
||||||
|
---------------
|
||||||
When sending patches to Linus, always follow step #7.
|
|
||||||
|
|
||||||
Large changes are not appropriate for mailing lists, and some
|
Large changes are not appropriate for mailing lists, and some
|
||||||
maintainers. If your patch, uncompressed, exceeds 300 kB in size,
|
maintainers. If your patch, uncompressed, exceeds 300 kB in size,
|
||||||
it is preferred that you store your patch on an Internet-accessible
|
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
|
Once upon a time, patches used to disappear into the void without comment,
|
||||||
description, the kernel version to which this patch applies.
|
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
|
||||||
If the patch does not apply cleanly to the latest kernel version,
|
that you have sent your patches to the right place. Wait for a minimum of
|
||||||
Linus will not apply it.
|
one week before resubmitting or pinging reviewers - possibly longer during
|
||||||
|
busy times like merge windows.
|
||||||
|
|
||||||
|
|
||||||
|
10) Include PATCH in the subject
|
||||||
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
|
|
||||||
|
|
||||||
Due to high e-mail traffic to Linus, and to linux-kernel, it is common
|
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
|
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
|
To improve tracking of who did what, especially with patches that can
|
||||||
percolate to their final resting place in the kernel through several
|
percolate to their final resting place in the kernel through several
|
||||||
|
@ -429,15 +479,15 @@ which appears in the changelog.
|
||||||
Special note to back-porters: It seems to be a common and useful practice
|
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
|
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,
|
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
|
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]
|
[backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]
|
||||||
|
|
||||||
Whatever the format, this information provides a valuable help to people
|
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.
|
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
|
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.
|
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
|
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
|
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
|
Acked-by: is often used by the maintainer of the affected code when that
|
||||||
maintainer neither contributed to nor forwarded the patch.
|
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
|
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
|
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"
|
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.
|
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
|
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
|
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.
|
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
|
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
|
person it names - but it should indicate that this person was copied on the
|
||||||
have been included in the discussion
|
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
|
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
|
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.
|
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:
|
The canonical patch subject line is:
|
||||||
|
|
||||||
|
@ -549,7 +609,8 @@ The canonical patch subject line is:
|
||||||
|
|
||||||
The canonical patch message body contains the following:
|
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.
|
- An empty line.
|
||||||
|
|
||||||
|
@ -656,128 +717,63 @@ See more details on the proper patch format in the following
|
||||||
references.
|
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
|
If you have a series of patches, it may be most convenient to have the
|
||||||
so that I can't even by mistake pull from the wrong branch, and so
|
maintainer pull them directly into the subsystem repository with a
|
||||||
that a triple-click just selects the whole thing.
|
"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
|
A pull request should also include an overall message saying what will be
|
||||||
get it wrong (actually, I've only gotten it wrong a few times, and
|
included in the request, a "git shortlog" listing of the patches
|
||||||
checking against the diffstat tells me when I get it wrong, but I'm
|
themselves, and a diffstat showing the overall effect of the patch series.
|
||||||
just a lot more comfortable when I don't have to "look for" the right
|
The easiest way to get all this information together is, of course, to let
|
||||||
thing to pull, and double-check that I have the right branch-name).
|
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 first step toward creating such tags is to make a GNUPG key and get it
|
||||||
the -M enables rename detection, and the summary enables a summary of
|
signed by one or more core kernel developers. This step can be hard for
|
||||||
new/deleted or renamed files.
|
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 [...]
|
Once you have prepared a patch series in git that you wish to have somebody
|
||||||
because git will notice that a fair number of the changes are renames.
|
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.
|
||||||
|
|
||||||
-----------------------------------
|
If the tree the maintainer will be pulling from is not the repository you
|
||||||
SECTION 2 - HINTS, TIPS, AND TRICKS
|
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
|
When generating your pull request, use the signed tag as the target. A
|
||||||
submitted to the kernel. There are always exceptions... but you must
|
command like this will do the trick:
|
||||||
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."
|
|
||||||
|
|
||||||
|
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).
|
Andrew Morton, "The perfect patch" (tpp).
|
||||||
|
|
|
@ -243,7 +243,7 @@ input driver:
|
||||||
.owner = THIS_MODULE,
|
.owner = THIS_MODULE,
|
||||||
.pm = &mpu3050_pm,
|
.pm = &mpu3050_pm,
|
||||||
.of_match_table = mpu3050_of_match,
|
.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,
|
.probe = mpu3050_probe,
|
||||||
.remove = mpu3050_remove,
|
.remove = mpu3050_remove,
|
||||||
|
|
|
@ -2,11 +2,15 @@
|
||||||
- this file
|
- this file
|
||||||
Booting
|
Booting
|
||||||
- requirements for booting
|
- requirements for booting
|
||||||
|
CCN.txt
|
||||||
|
- Cache Coherent Network ring-bus and perf PMU driver.
|
||||||
Interrupts
|
Interrupts
|
||||||
- ARM Interrupt subsystem documentation
|
- ARM Interrupt subsystem documentation
|
||||||
IXP4xx
|
IXP4xx
|
||||||
- Intel IXP4xx Network processor.
|
- Intel IXP4xx Network processor.
|
||||||
msm
|
Makefile
|
||||||
|
- Build sourcefiles as part of the Documentation-build for arm
|
||||||
|
msm/
|
||||||
- MSM specific documentation
|
- MSM specific documentation
|
||||||
Netwinder
|
Netwinder
|
||||||
- Netwinder specific documentation
|
- Netwinder specific documentation
|
||||||
|
@ -18,11 +22,9 @@ README
|
||||||
- General ARM documentation
|
- General ARM documentation
|
||||||
SA1100/
|
SA1100/
|
||||||
- SA1100 documentation
|
- SA1100 documentation
|
||||||
Samsung-S3C24XX
|
Samsung-S3C24XX/
|
||||||
- S3C24XX ARM Linux Overview
|
- S3C24XX ARM Linux Overview
|
||||||
Sharp-LH
|
SPEAr/
|
||||||
- Linux on Sharp LH79524 and LH7A40X System On a Chip (SOC)
|
|
||||||
SPEAr
|
|
||||||
- ST SPEAr platform Linux Overview
|
- ST SPEAr platform Linux Overview
|
||||||
VFP/
|
VFP/
|
||||||
- Release notes for Linux Kernel Vector Floating Point support code
|
- 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
|
http://dl.linux-sunxi.org/A31/A3x_release_document/A31/IC/A31%20user%20manual%20V1.1%2020130630.pdf
|
||||||
|
|
||||||
- Allwinner A31s (sun6i)
|
- Allwinner A31s (sun6i)
|
||||||
+ Not Supported
|
|
||||||
+ Datasheet
|
+ Datasheet
|
||||||
http://dl.linux-sunxi.org/A31/A3x_release_document/A31s/IC/A31s%20datasheet%20V1.3%2020131106.pdf
|
http://dl.linux-sunxi.org/A31/A3x_release_document/A31s/IC/A31s%20datasheet%20V1.3%2020131106.pdf
|
||||||
+ User Manual
|
+ 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
|
architecture. Deprecated instructions should default to emulation
|
||||||
while obsolete instructions must be undefined by default.
|
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
|
Supported legacy instructions
|
||||||
-----------------------------
|
-----------------------------
|
||||||
* SWP{B}
|
* SWP{B}
|
||||||
|
@ -43,3 +46,12 @@ Default: Undef (0)
|
||||||
Node: /proc/sys/abi/cp15_barrier
|
Node: /proc/sys/abi/cp15_barrier
|
||||||
Status: Deprecated
|
Status: Deprecated
|
||||||
Default: Emulate (1)
|
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_BLACKFIN),)
|
||||||
|
ifneq ($(CONFIG_BFIN_GPTIMERS,)
|
||||||
obj-m := gptimers-example.o
|
obj-m := gptimers-example.o
|
||||||
endif
|
endif
|
||||||
|
endif
|
||||||
|
|
|
@ -317,10 +317,10 @@ maps this page at its virtual address.
|
||||||
about doing this.
|
about doing this.
|
||||||
|
|
||||||
The idea is, first at flush_dcache_page() time, if
|
The idea is, first at flush_dcache_page() time, if
|
||||||
page->mapping->i_mmap is an empty tree and ->i_mmap_nonlinear
|
page->mapping->i_mmap is an empty tree, just mark the architecture
|
||||||
an empty list, just mark the architecture private page flag bit.
|
private page flag bit. Later, in update_mmu_cache(), a check is
|
||||||
Later, in update_mmu_cache(), a check is made of this flag bit,
|
made of this flag bit, and if set the flush is done and the flag
|
||||||
and if set the flush is done and the flag bit is cleared.
|
bit is cleared.
|
||||||
|
|
||||||
IMPORTANT NOTE: It is often important, if you defer the flush,
|
IMPORTANT NOTE: It is often important, if you defer the flush,
|
||||||
that the actual flush occurs on the same CPU
|
that the actual flush occurs on the same CPU
|
||||||
|
|
|
@ -24,3 +24,5 @@ net_prio.txt
|
||||||
- Network priority cgroups details and usages.
|
- Network priority cgroups details and usages.
|
||||||
resource_counter.txt
|
resource_counter.txt
|
||||||
- Resource Counter API.
|
- 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
|
- use_hierarchy is on by default and the cgroup file for the flag is
|
||||||
not created.
|
not created.
|
||||||
|
|
||||||
|
- The original lower boundary, the soft limit, is defined as a limit
|
||||||
|
that is per default unset. As a result, the set of cgroups that
|
||||||
|
global reclaim prefers is opt-in, rather than opt-out. The costs
|
||||||
|
for optimizing these mostly negative lookups are so high that the
|
||||||
|
implementation, despite its enormous size, does not even provide the
|
||||||
|
basic desirable behavior. First off, the soft limit has no
|
||||||
|
hierarchical meaning. All configured groups are organized in a
|
||||||
|
global rbtree and treated like equal peers, regardless where they
|
||||||
|
are located in the hierarchy. This makes subtree delegation
|
||||||
|
impossible. Second, the soft limit reclaim pass is so aggressive
|
||||||
|
that it not just introduces high allocation latencies into the
|
||||||
|
system, but also impacts system performance due to overreclaim, to
|
||||||
|
the point where the feature becomes self-defeating.
|
||||||
|
|
||||||
|
The memory.low boundary on the other hand is a top-down allocated
|
||||||
|
reserve. A cgroup enjoys reclaim protection when it and all its
|
||||||
|
ancestors are below their low boundaries, which makes delegation of
|
||||||
|
subtrees possible. Secondly, new cgroups have no reserve per
|
||||||
|
default and in the common case most cgroups are eligible for the
|
||||||
|
preferred reclaim pass. This allows the new low boundary to be
|
||||||
|
efficiently implemented with just a minor addition to the generic
|
||||||
|
reclaim code, without the need for out-of-band data structures and
|
||||||
|
reclaim passes. Because the generic reclaim code considers all
|
||||||
|
cgroups except for the ones running low in the preferred first
|
||||||
|
reclaim pass, overreclaim of individual groups is eliminated as
|
||||||
|
well, resulting in much better overall workload performance.
|
||||||
|
|
||||||
|
- The original high boundary, the hard limit, is defined as a strict
|
||||||
|
limit that can not budge, even if the OOM killer has to be called.
|
||||||
|
But this generally goes against the goal of making the most out of
|
||||||
|
the available memory. The memory consumption of workloads varies
|
||||||
|
during runtime, and that requires users to overcommit. But doing
|
||||||
|
that with a strict upper limit requires either a fairly accurate
|
||||||
|
prediction of the working set size or adding slack to the limit.
|
||||||
|
Since working set size estimation is hard and error prone, and
|
||||||
|
getting it wrong results in OOM kills, most users tend to err on the
|
||||||
|
side of a looser limit and end up wasting precious resources.
|
||||||
|
|
||||||
|
The memory.high boundary on the other hand can be set much more
|
||||||
|
conservatively. When hit, it throttles allocations by forcing them
|
||||||
|
into direct reclaim to work off the excess, but it never invokes the
|
||||||
|
OOM killer. As a result, a high boundary that is chosen too
|
||||||
|
aggressively will not terminate the processes, but instead it will
|
||||||
|
lead to gradual performance degradation. The user can monitor this
|
||||||
|
and make corrections until the minimal memory footprint that still
|
||||||
|
gives acceptable performance is found.
|
||||||
|
|
||||||
|
In extreme cases, with many concurrent allocations and a complete
|
||||||
|
breakdown of reclaim progress within the group, the high boundary
|
||||||
|
can be exceeded. But even then it's mostly better to satisfy the
|
||||||
|
allocation from the slack available in other groups or the rest of
|
||||||
|
the system than killing the group. Otherwise, memory.max is there
|
||||||
|
to limit this type of spillover and ultimately contain buggy or even
|
||||||
|
malicious applications.
|
||||||
|
|
||||||
|
- The original control file names are unwieldy and inconsistent in
|
||||||
|
many different ways. For example, the upper boundary hit count is
|
||||||
|
exported in the memory.failcnt file, but an OOM event count has to
|
||||||
|
be manually counted by listening to memory.oom_control events, and
|
||||||
|
lower boundary / soft limit events have to be counted by first
|
||||||
|
setting a threshold for that value and then counting those events.
|
||||||
|
Also, usage and limit files encode their units in the filename.
|
||||||
|
That makes the filenames very long, even though this is not
|
||||||
|
information that a user needs to be reminded of every time they type
|
||||||
|
out those names.
|
||||||
|
|
||||||
|
To address these naming issues, as well as to signal clearly that
|
||||||
|
the new interface carries a new configuration model, the naming
|
||||||
|
conventions in it necessarily differ from the old interface.
|
||||||
|
|
||||||
|
- The original limit files indicate the state of an unset limit with a
|
||||||
|
Very High Number, and a configured limit can be unset by echoing -1
|
||||||
|
into those files. But that very high number is implementation and
|
||||||
|
architecture dependent and not very descriptive. And while -1 can
|
||||||
|
be understood as an underflow into the highest possible value, -2 or
|
||||||
|
-10M etc. do not work, so it's not consistent.
|
||||||
|
|
||||||
|
memory.low, memory.high, and memory.max will use the string
|
||||||
|
"infinity" to indicate and set the highest possible value.
|
||||||
|
|
||||||
5. Planned Changes
|
5. Planned Changes
|
||||||
|
|
||||||
|
|
|
@ -73,6 +73,8 @@ the operations defined in clk.h:
|
||||||
unsigned long *parent_rate);
|
unsigned long *parent_rate);
|
||||||
long (*determine_rate)(struct clk_hw *hw,
|
long (*determine_rate)(struct clk_hw *hw,
|
||||||
unsigned long rate,
|
unsigned long rate,
|
||||||
|
unsigned long min_rate,
|
||||||
|
unsigned long max_rate,
|
||||||
unsigned long *best_parent_rate,
|
unsigned long *best_parent_rate,
|
||||||
struct clk_hw **best_parent_clk);
|
struct clk_hw **best_parent_clk);
|
||||||
int (*set_parent)(struct clk_hw *hw, u8 index);
|
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
|
no_turbo: limits the driver to selecting P states below the turbo
|
||||||
frequency range.
|
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
|
For contemporary Intel processors, the frequency is controlled by the
|
||||||
processor itself and the P-states exposed to software are related to
|
processor itself and the P-states exposed to software are related to
|
||||||
performance levels. The idea that frequency can be set to a single
|
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.
|
Otherwise #opt_params is the number of following arguments.
|
||||||
|
|
||||||
Example of optional parameters section:
|
Example of optional parameters section:
|
||||||
1 allow_discards
|
3 allow_discards same_cpu_crypt submit_from_crypt_cpus
|
||||||
|
|
||||||
allow_discards
|
allow_discards
|
||||||
Block discard requests (a.k.a. TRIM) are passed through the crypt device.
|
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
|
used space etc.) if the discarded blocks can be located easily on the
|
||||||
device later.
|
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
|
Example scripts
|
||||||
===============
|
===============
|
||||||
LUKS (Linux Unified Key Setup) is now the preferred way to set up disk
|
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"
|
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:
|
Example:
|
||||||
|
|
||||||
compatible = "marvell,a385-rd", "marvell,armada385", "marvell,armada380";
|
compatible = "marvell,a385-rd", "marvell,armada385", "marvell,armada380";
|
||||||
|
|
|
@ -24,6 +24,7 @@ compatible: must be one of:
|
||||||
o "atmel,at91sam9g45"
|
o "atmel,at91sam9g45"
|
||||||
o "atmel,at91sam9n12"
|
o "atmel,at91sam9n12"
|
||||||
o "atmel,at91sam9rl"
|
o "atmel,at91sam9rl"
|
||||||
|
o "atmel,at91sam9xe"
|
||||||
* "atmel,sama5" for SoCs using a Cortex-A5, shall be extended with the specific
|
* "atmel,sama5" for SoCs using a Cortex-A5, shall be extended with the specific
|
||||||
SoC family:
|
SoC family:
|
||||||
o "atmel,sama5d3" shall be extended with the specific SoC compatible:
|
o "atmel,sama5d3" shall be extended with the specific SoC compatible:
|
||||||
|
@ -136,3 +137,19 @@ Example:
|
||||||
compatible = "atmel,at91sam9260-rstc";
|
compatible = "atmel,at91sam9260-rstc";
|
||||||
reg = <0xfffffd00 0x10>;
|
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
|
Required properties
|
||||||
|
|
||||||
- compatible
|
- 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
|
- syscon
|
||||||
A phandle / integer array that points to the syscon node which describes
|
A phandle / integer array that points to the syscon node which describes
|
||||||
|
|
|
@ -38,8 +38,6 @@ its hardware characteristcs.
|
||||||
AMBA markee):
|
AMBA markee):
|
||||||
- "arm,coresight-replicator"
|
- "arm,coresight-replicator"
|
||||||
|
|
||||||
* id: a unique number that will identify this replicator.
|
|
||||||
|
|
||||||
* port or ports: same as above.
|
* port or ports: same as above.
|
||||||
|
|
||||||
* Optional properties for ETM/PTMs:
|
* Optional properties for ETM/PTMs:
|
||||||
|
@ -94,8 +92,6 @@ Example:
|
||||||
* AMBA bus. As such no need to add "arm,primecell".
|
* AMBA bus. As such no need to add "arm,primecell".
|
||||||
*/
|
*/
|
||||||
compatible = "arm,coresight-replicator";
|
compatible = "arm,coresight-replicator";
|
||||||
/* this will show up in debugfs as "0.replicator" */
|
|
||||||
id = <0>;
|
|
||||||
|
|
||||||
ports {
|
ports {
|
||||||
#address-cells = <1>;
|
#address-cells = <1>;
|
||||||
|
|
|
@ -175,6 +175,7 @@ nodes to be present and contain the properties described below.
|
||||||
"marvell,pj4a"
|
"marvell,pj4a"
|
||||||
"marvell,pj4b"
|
"marvell,pj4b"
|
||||||
"marvell,sheeva-v5"
|
"marvell,sheeva-v5"
|
||||||
|
"nvidia,tegra132-denver"
|
||||||
"qcom,krait"
|
"qcom,krait"
|
||||||
"qcom,scorpion"
|
"qcom,scorpion"
|
||||||
- enable-method
|
- 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
|
|
@ -23,7 +23,7 @@ Optional Properties:
|
||||||
devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
|
devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
|
||||||
are supported currently.
|
are supported currently.
|
||||||
|
|
||||||
Node of a device using power domains must have a samsung,power-domain property
|
Node of a device using power domains must have a power-domains property
|
||||||
defined with a phandle to respective power domain.
|
defined with a phandle to respective power domain.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
|
@ -75,6 +75,18 @@ i.MX6q generic board
|
||||||
Required root node properties:
|
Required root node properties:
|
||||||
- compatible = "fsl,imx6q";
|
- 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
|
Freescale LS1021A Platform Device Tree Bindings
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
|
@ -112,3 +124,11 @@ Example:
|
||||||
compatible = "fsl,ls1021a-dcfg";
|
compatible = "fsl,ls1021a-dcfg";
|
||||||
reg = <0x0 0x1ee0000 0x0 0x10000>;
|
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:
|
The 3rd cell is the flags, encoded as follows:
|
||||||
bits[3:0] trigger type and level flags.
|
bits[3:0] trigger type and level flags.
|
||||||
1 = low-to-high edge triggered
|
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
|
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
|
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 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.
|
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
|
- 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
|
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:
|
Required root node properties:
|
||||||
- compatible = "hisilicon,hip04-d01";
|
- compatible = "hisilicon,hip04-d01";
|
||||||
|
|
||||||
|
HiP01 ca9x2 Board
|
||||||
|
Required root node properties:
|
||||||
|
- compatible = "hisilicon,hip01-ca9x2";
|
||||||
|
|
||||||
|
|
||||||
Hisilicon system controller
|
Hisilicon system controller
|
||||||
|
|
||||||
|
@ -36,6 +40,27 @@ Example:
|
||||||
reboot-offset = <0x4>;
|
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
|
Hisilicon CPU controller
|
||||||
|
|
||||||
|
|
|
@ -57,6 +57,16 @@ Optional properties:
|
||||||
- cache-id-part: cache id part number to be used if it is not present
|
- cache-id-part: cache id part number to be used if it is not present
|
||||||
on hardware
|
on hardware
|
||||||
- wt-override: If present then L2 is forced to Write through mode
|
- 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:
|
Example:
|
||||||
|
|
||||||
|
|
|
@ -9,6 +9,7 @@ compatible: Must contain one of
|
||||||
"mediatek,mt6592"
|
"mediatek,mt6592"
|
||||||
"mediatek,mt8127"
|
"mediatek,mt8127"
|
||||||
"mediatek,mt8135"
|
"mediatek,mt8135"
|
||||||
|
"mediatek,mt8173"
|
||||||
|
|
||||||
|
|
||||||
Supported boards:
|
Supported boards:
|
||||||
|
@ -25,3 +26,6 @@ Supported boards:
|
||||||
- MTK mt8135 tablet EVB:
|
- MTK mt8135 tablet EVB:
|
||||||
Required root node properties:
|
Required root node properties:
|
||||||
- compatible = "mediatek,mt8135-evbp1", "mediatek,mt8135";
|
- 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:
|
Required properties:
|
||||||
- compatible: should be one of:
|
- compatible: should be one of:
|
||||||
|
"mediatek,mt8173-sysirq"
|
||||||
"mediatek,mt8135-sysirq"
|
"mediatek,mt8135-sysirq"
|
||||||
"mediatek,mt8127-sysirq"
|
"mediatek,mt8127-sysirq"
|
||||||
|
"mediatek,mt6592-sysirq"
|
||||||
"mediatek,mt6589-sysirq"
|
"mediatek,mt6589-sysirq"
|
||||||
"mediatek,mt6582-sysirq"
|
"mediatek,mt6582-sysirq"
|
||||||
"mediatek,mt6577-sysirq"
|
"mediatek,mt6577-sysirq"
|
||||||
|
|
|
@ -8,7 +8,7 @@ Properties:
|
||||||
"qcom,kpss-timer" - krait subsystem
|
"qcom,kpss-timer" - krait subsystem
|
||||||
"qcom,scss-timer" - scorpion 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
|
timer, and optionally a second general purpose timer in that
|
||||||
order.
|
order.
|
||||||
|
|
||||||
|
|
|
@ -9,6 +9,16 @@ Rockchip platforms device tree bindings
|
||||||
Required root node properties:
|
Required root node properties:
|
||||||
- compatible = "mundoreader,bq-curie2", "rockchip,rk3066a";
|
- compatible = "mundoreader,bq-curie2", "rockchip,rk3066a";
|
||||||
|
|
||||||
|
- ChipSPARK Rayeager PX2 board:
|
||||||
|
Required root node properties:
|
||||||
|
- compatible = "chipspark,rayeager-px2", "rockchip,rk3066a";
|
||||||
|
|
||||||
- Radxa Rock board:
|
- Radxa Rock board:
|
||||||
Required root node properties:
|
Required root node properties:
|
||||||
- compatible = "radxa,rock", "rockchip,rk3188";
|
- 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,exynos5260-pmu" - for Exynos5260 SoC.
|
||||||
- "samsung,exynos5410-pmu" - for Exynos5410 SoC,
|
- "samsung,exynos5410-pmu" - for Exynos5410 SoC,
|
||||||
- "samsung,exynos5420-pmu" - for Exynos5420 SoC.
|
- "samsung,exynos5420-pmu" - for Exynos5420 SoC.
|
||||||
|
- "samsung,exynos7-pmu" - for Exynos7 SoC.
|
||||||
second value must be always "syscon".
|
second value must be always "syscon".
|
||||||
|
|
||||||
- reg : offset and length of the register set.
|
- reg : offset and length of the register set.
|
||||||
|
|
|
@ -3,7 +3,9 @@ CSR SiRFprimaII and SiRFmarco device tree bindings.
|
||||||
|
|
||||||
Required root node properties:
|
Required root node properties:
|
||||||
- compatible:
|
- 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,prima2-cb" : prima2 "cb" evaluation board
|
||||||
- "sirf,marco-cb" : marco "cb" evaluation board
|
|
||||||
- "sirf,prima2" : prima2 device based 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,7 @@ Boards with the ST STiH407 SoC shall have the following properties:
|
||||||
Required root node property:
|
Required root node property:
|
||||||
compatible = "st,stih407";
|
compatible = "st,stih407";
|
||||||
|
|
||||||
|
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
|
NVIDIA Tegra AHB
|
||||||
|
|
||||||
Required properties:
|
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)
|
- reg : Should contain 1 register ranges(address and length)
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
|
@ -6,7 +6,11 @@ modes. It provides power-gating controllers for SoC and CPU power-islands.
|
||||||
|
|
||||||
Required properties:
|
Required properties:
|
||||||
- name : Should be pmc
|
- 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
|
- reg : Offset and length of the register set for the device
|
||||||
- clocks : Must contain an entry for each entry in clock-names.
|
- clocks : Must contain an entry for each entry in clock-names.
|
||||||
See ../clocks/clock-bindings.txt for details.
|
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
|
sleep mode, the warm boot code will restore some PLLs, clocks and then
|
||||||
bring up CPU0 for resuming the system.
|
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:
|
Example:
|
||||||
|
|
||||||
/ SoC dts including file
|
/ SoC dts including file
|
||||||
|
@ -68,6 +89,15 @@ pmc@7000f400 {
|
||||||
|
|
||||||
/ Tegra board dts file
|
/ 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 {
|
clocks {
|
||||||
compatible = "simple-bus";
|
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
|
|
@ -38,8 +38,9 @@ Required properties when using sub-nodes:
|
||||||
|
|
||||||
Sub-nodes required properties:
|
Sub-nodes required properties:
|
||||||
- reg : the port number
|
- reg : the port number
|
||||||
|
And at least one of the following properties:
|
||||||
- phys : reference to the SATA PHY node
|
- phys : reference to the SATA PHY node
|
||||||
|
- target-supply : regulator for SATA target power
|
||||||
|
|
||||||
Examples:
|
Examples:
|
||||||
sata@ffe08000 {
|
sata@ffe08000 {
|
||||||
|
@ -68,10 +69,12 @@ With sub-nodes:
|
||||||
sata0: sata-port@0 {
|
sata0: sata-port@0 {
|
||||||
reg = <0>;
|
reg = <0>;
|
||||||
phys = <&sata_phy 0>;
|
phys = <&sata_phy 0>;
|
||||||
|
target-supply = <®_sata0>;
|
||||||
};
|
};
|
||||||
|
|
||||||
sata1: sata-port@1 {
|
sata1: sata-port@1 {
|
||||||
reg = <1>;
|
reg = <1>;
|
||||||
phys = <&sata_phy 1>;
|
phys = <&sata_phy 1>;
|
||||||
|
target-supply = <®_sata1>;;
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
|
@ -9,7 +9,7 @@ Properties:
|
||||||
|
|
||||||
Compatibility with many Cavium evaluation boards.
|
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.
|
the device configuration, there may be one or two banks.
|
||||||
|
|
||||||
- cavium,bus-width: The width of the connection to the CF devices. Valid
|
- cavium,bus-width: The width of the connection to the CF devices. Valid
|
||||||
|
|
|
@ -1,7 +1,9 @@
|
||||||
Tegra124 SoC SATA AHCI controller
|
Tegra124 SoC SATA AHCI controller
|
||||||
|
|
||||||
Required properties :
|
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:
|
- reg : Should contain 2 entries:
|
||||||
- AHCI register set (SATA BAR5)
|
- AHCI register set (SATA BAR5)
|
||||||
- SATA register set
|
- SATA register set
|
||||||
|
|
|
@ -6,8 +6,8 @@ Required properties:
|
||||||
- compatible: Should be set to one of the following:
|
- compatible: Should be set to one of the following:
|
||||||
marvell,armada370-mbus
|
marvell,armada370-mbus
|
||||||
marvell,armadaxp-mbus
|
marvell,armadaxp-mbus
|
||||||
marvell,armada370-mbus
|
marvell,armada375-mbus
|
||||||
marvell,armadaxp-mbus
|
marvell,armada380-mbus
|
||||||
marvell,kirkwood-mbus
|
marvell,kirkwood-mbus
|
||||||
marvell,dove-mbus
|
marvell,dove-mbus
|
||||||
marvell,orion5x-88f5281-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
|
enable (and disable in some cases) SoC pin drivers, select peripheral clock
|
||||||
sources (internal or pin), etc. In some cases, a configuration register is
|
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,
|
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
|
provide device ID information, provide ethernet MAC addresses, as well as other
|
||||||
miscellaneous functions.
|
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-peris"
|
||||||
- "samsung,exynos7-clock-fsys0"
|
- "samsung,exynos7-clock-fsys0"
|
||||||
- "samsung,exynos7-clock-fsys1"
|
- "samsung,exynos7-clock-fsys1"
|
||||||
|
- "samsung,exynos7-clock-mscl"
|
||||||
|
- "samsung,exynos7-clock-aud"
|
||||||
|
|
||||||
- reg: physical base address of the controller and the length of
|
- reg: physical base address of the controller and the length of
|
||||||
memory mapped region.
|
memory mapped region.
|
||||||
|
@ -53,6 +55,7 @@ Input clocks for top0 clock controller:
|
||||||
- dout_sclk_bus1_pll
|
- dout_sclk_bus1_pll
|
||||||
- dout_sclk_cc_pll
|
- dout_sclk_cc_pll
|
||||||
- dout_sclk_mfc_pll
|
- dout_sclk_mfc_pll
|
||||||
|
- dout_sclk_aud_pll
|
||||||
|
|
||||||
Input clocks for top1 clock controller:
|
Input clocks for top1 clock controller:
|
||||||
- fin_pll
|
- fin_pll
|
||||||
|
@ -76,6 +79,14 @@ Input clocks for peric1 clock controller:
|
||||||
- sclk_uart1
|
- sclk_uart1
|
||||||
- sclk_uart2
|
- sclk_uart2
|
||||||
- sclk_uart3
|
- sclk_uart3
|
||||||
|
- sclk_spi0
|
||||||
|
- sclk_spi1
|
||||||
|
- sclk_spi2
|
||||||
|
- sclk_spi3
|
||||||
|
- sclk_spi4
|
||||||
|
- sclk_i2s1
|
||||||
|
- sclk_pcm1
|
||||||
|
- sclk_spdif
|
||||||
|
|
||||||
Input clocks for peris clock controller:
|
Input clocks for peris clock controller:
|
||||||
- fin_pll
|
- fin_pll
|
||||||
|
@ -91,3 +102,7 @@ Input clocks for fsys1 clock controller:
|
||||||
- dout_aclk_fsys1_200
|
- dout_aclk_fsys1_200
|
||||||
- dout_sclk_mmc0
|
- dout_sclk_mmc0
|
||||||
- dout_sclk_mmc1
|
- 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:
|
This binding uses the common clock binding:
|
||||||
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
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.
|
for muxing and gating Tegra's clocks, and setting their rates.
|
||||||
|
|
||||||
Required properties :
|
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
|
- reg : Should contain CAR registers location and length
|
||||||
- clocks : Should contain phandle and clock specifiers for two clocks:
|
- clocks : Should contain phandle and clock specifiers for two clocks:
|
||||||
the 32 KHz "32k_in", and the board-specific oscillator "osc".
|
the 32 KHz "32k_in", and the board-specific oscillator "osc".
|
||||||
- #clock-cells : Should be 1.
|
- #clock-cells : Should be 1.
|
||||||
In clock consumers, this cell represents the clock ID exposed by the
|
In clock consumers, this cell represents the clock ID exposed by the
|
||||||
CAR. The assignments may be found in header file
|
CAR. The assignments may be found in the header files
|
||||||
<dt-bindings/clock/tegra124-car.h>.
|
<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.
|
- #reset-cells : Should be 1.
|
||||||
In clock consumers, this cell represents the bit number in the CAR's
|
In clock consumers, this cell represents the bit number in the CAR's
|
||||||
array of CLK_RST_CONTROLLER_RST_DEVICES_* registers.
|
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
|
SYSCLK signal. The SYSCLK input (frequency) is multiplied using
|
||||||
multiple phase locked loops (PLL) to create a variety of frequencies
|
multiple phase locked loops (PLL) to create a variety of frequencies
|
||||||
which can then be passed to a variety of internal logic, including
|
which can then be passed to a variety of internal logic, including
|
||||||
|
@ -29,6 +29,7 @@ Required properties:
|
||||||
* "fsl,t4240-clockgen"
|
* "fsl,t4240-clockgen"
|
||||||
* "fsl,b4420-clockgen"
|
* "fsl,b4420-clockgen"
|
||||||
* "fsl,b4860-clockgen"
|
* "fsl,b4860-clockgen"
|
||||||
|
* "fsl,ls1021a-clockgen"
|
||||||
Chassis clock strings include:
|
Chassis clock strings include:
|
||||||
* "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
|
* "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
|
||||||
* "fsl,qoriq-clockgen-2.0": for chassis 2.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
|
- compatible: Must be one of the following
|
||||||
- "renesas,r7s72100-mstp-clocks" for R7S72100 (RZ) MSTP gate clocks
|
- "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,r8a7740-mstp-clocks" for R8A7740 (R-Mobile A1) MSTP gate clocks
|
||||||
- "renesas,r8a7779-mstp-clocks" for R8A7779 (R-Car H1) 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
|
- "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
|
- compatible: Must be one of
|
||||||
- "renesas,r8a7790-cpg-clocks" for the r8a7790 CPG
|
- "renesas,r8a7790-cpg-clocks" for the r8a7790 CPG
|
||||||
- "renesas,r8a7791-cpg-clocks" for the r8a7791 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,r8a7794-cpg-clocks" for the r8a7794 CPG
|
||||||
- "renesas,rcar-gen2-cpg-clocks" for the generic R-Car Gen2 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
|
- 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-cells: Must be 1
|
||||||
- clock-output-names: The names of the clocks. Supported clocks are "main",
|
- 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
|
Example
|
||||||
|
@ -26,8 +29,9 @@ Example
|
||||||
compatible = "renesas,r8a7790-cpg-clocks",
|
compatible = "renesas,r8a7790-cpg-clocks",
|
||||||
"renesas,rcar-gen2-cpg-clocks";
|
"renesas,rcar-gen2-cpg-clocks";
|
||||||
reg = <0 0xe6150000 0 0x1000>;
|
reg = <0 0xe6150000 0 0x1000>;
|
||||||
clocks = <&extal_clk>;
|
clocks = <&extal_clk &usb_extal_clk>;
|
||||||
#clock-cells = <1>;
|
#clock-cells = <1>;
|
||||||
clock-output-names = "main", "pll0, "pll1", "pll3",
|
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,sun5i-a10s-ahb-gates-clk" - for the AHB gates on A10s
|
||||||
"allwinner,sun7i-a20-ahb-gates-clk" - for the AHB gates on A20
|
"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-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,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
|
||||||
"allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
|
"allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
|
||||||
"allwinner,sun9i-a80-ahb0-gates-clk" - for the AHB0 gates on A80
|
"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,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
|
||||||
"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
|
"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
|
||||||
"allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
|
"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-clk" - for the MMC clock
|
||||||
"allwinner,sun4i-a10-mmc-sample-clk" - for the MMC sample clock on A10
|
"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,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,sun8i-a23-mbus-clk" - for the MBUS clock on A23
|
||||||
"allwinner,sun7i-a20-out-clk" - for the external output clocks
|
"allwinner,sun7i-a20-out-clk" - for the external output clocks
|
||||||
"allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
|
"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
|
- #clock-cells : from common clock binding; shall be set to 0 except for
|
||||||
the following compatibles where it shall be set to 1:
|
the following compatibles where it shall be set to 1:
|
||||||
"allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk",
|
"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.
|
- clock-output-names : shall be the corresponding names of the outputs.
|
||||||
If the clock module only has one output, the name shall be the
|
If the clock module only has one output, the name shall be the
|
||||||
module name.
|
module name.
|
||||||
|
@ -81,6 +85,10 @@ Required properties for all clocks:
|
||||||
And "allwinner,*-usb-clk" clocks also require:
|
And "allwinner,*-usb-clk" clocks also require:
|
||||||
- reset-cells : shall be set to 1
|
- 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
|
For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
|
||||||
dummy clocks at 25 MHz and 125 MHz, respectively. See example.
|
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
|
is the normal PLL6 output, or "pll6". The second output is rate doubled
|
||||||
PLL6, or "pll6x2".
|
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:
|
For example:
|
||||||
|
|
||||||
osc24M: clk@01c20050 {
|
osc24M: clk@01c20050 {
|
||||||
|
@ -138,11 +154,11 @@ cpu: cpu@01c20054 {
|
||||||
};
|
};
|
||||||
|
|
||||||
mmc0_clk: clk@01c20088 {
|
mmc0_clk: clk@01c20088 {
|
||||||
#clock-cells = <0>;
|
#clock-cells = <1>;
|
||||||
compatible = "allwinner,sun4i-mod0-clk";
|
compatible = "allwinner,sun4i-a10-mmc-clk";
|
||||||
reg = <0x01c20088 0x4>;
|
reg = <0x01c20088 0x4>;
|
||||||
clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
|
clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
|
||||||
clock-output-names = "mmc0";
|
clock-output-names = "mmc0", "mmc0_output", "mmc0_sample";
|
||||||
};
|
};
|
||||||
|
|
||||||
mii_phy_tx_clk: clk@2 {
|
mii_phy_tx_clk: clk@2 {
|
||||||
|
@ -170,3 +186,16 @@ gmac_clk: clk@01c20164 {
|
||||||
clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
|
clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
|
||||||
clock-output-names = "gmac";
|
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 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
|
controller instances named DMAC capable of serving multiple clients. Channels
|
||||||
can be dedicated to specific clients or shared between a large number of
|
can be dedicated to specific clients or shared between a large number of
|
||||||
clients.
|
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
|
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
|
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
|
256 clients in total. When the number of hardware channels is lower than the
|
||||||
|
|
|
@ -38,7 +38,7 @@ Example:
|
||||||
chan_allocation_order = <1>;
|
chan_allocation_order = <1>;
|
||||||
chan_priority = <1>;
|
chan_priority = <1>;
|
||||||
block_size = <0xfff>;
|
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
|
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:
|
Required properties:
|
||||||
- compatible: one of the following
|
- compatible: one of the following
|
||||||
|
* "qcom,hdmi-tx-8084"
|
||||||
|
* "qcom,hdmi-tx-8074"
|
||||||
* "qcom,hdmi-tx-8660"
|
* "qcom,hdmi-tx-8660"
|
||||||
* "qcom,hdmi-tx-8960"
|
* "qcom,hdmi-tx-8960"
|
||||||
- reg: Physical base address and length of the controller's registers
|
- 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.
|
NVIDIA Tegra20/Tegra30/Tegr114/Tegra124 fuse block.
|
||||||
|
|
||||||
Required properties:
|
Required properties:
|
||||||
- compatible : should be:
|
- compatible : For Tegra20, must contain "nvidia,tegra20-efuse". For Tegra30,
|
||||||
"nvidia,tegra20-efuse"
|
must contain "nvidia,tegra30-efuse". For Tegra114, must contain
|
||||||
"nvidia,tegra30-efuse"
|
"nvidia,tegra114-efuse". For Tegra124, must contain "nvidia,tegra124-efuse".
|
||||||
"nvidia,tegra114-efuse"
|
Otherwise, must contain "nvidia,<chip>-efuse", plus one of the above, where
|
||||||
"nvidia,tegra124-efuse"
|
<chip> is tegra132.
|
||||||
Details:
|
Details:
|
||||||
nvidia,tegra20-efuse: Tegra20 requires using APB DMA to read the fuse data
|
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
|
due to a hardware bug. Tegra20 also lacks certain information which is
|
||||||
|
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue