Merge branch 'cleanups'
Merge cleanups requested by Linus. * cleanups: (3 commits) pnfs: Refactor the *_layout_mark_request_commit to use pnfs_layout_mark_request_commit nfs: Can call nfs_clear_page_commit() instead nfs: Provide and use helper functions for marking a page as unstable
This commit is contained in:
Trond Myklebust
Коммит
65d2918e71
1
.mailmap
1
.mailmap
|
|
@ -73,6 +73,7 @@ Juha Yrjola <juha.yrjola@nokia.com>
|
|||
Juha Yrjola <juha.yrjola@solidboot.com>
|
||||
Kay Sievers <kay.sievers@vrfy.org>
|
||||
Kenneth W Chen <kenneth.w.chen@intel.com>
|
||||
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
|
||||
Koushik <raghavendra.koushik@neterion.com>
|
||||
Kuninori Morimoto <kuninori.morimoto.gx@renesas.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.
|
||||
DMA-attributes.txt
|
||||
- listing of the various possible attributes a DMA region can have
|
||||
dmatest.txt
|
||||
- how to compile, configure and use the dmatest system.
|
||||
DocBook/
|
||||
- directory with DocBook templates etc. for kernel documentation.
|
||||
EDID/
|
||||
|
|
@ -163,8 +161,6 @@ digsig.txt
|
|||
-info on the Digital Signature Verification API
|
||||
dma-buf-sharing.txt
|
||||
- the DMA Buffer Sharing API Guide
|
||||
dmaengine.txt
|
||||
-the DMA Engine API Guide
|
||||
dontdiff
|
||||
- file containing a list of files that should never be diff'ed.
|
||||
driver-model/
|
||||
|
|
@ -209,6 +205,8 @@ hid/
|
|||
- directory with information on human interface devices
|
||||
highuid.txt
|
||||
- notes on the change from 16 bit to 32 bit user/group IDs.
|
||||
hsi.txt
|
||||
- HSI subsystem overview.
|
||||
hwspinlock.txt
|
||||
- hardware spinlock provides hardware assistance for synchronization
|
||||
timers/
|
||||
|
|
@ -277,6 +275,8 @@ kprobes.txt
|
|||
- documents the kernel probes debugging feature.
|
||||
kref.txt
|
||||
- docs on adding reference counters (krefs) to kernel objects.
|
||||
kselftest.txt
|
||||
- small unittests for (some) individual codepaths in the kernel.
|
||||
laptops/
|
||||
- directory with laptop related info and laptop driver documentation.
|
||||
ldm.txt
|
||||
|
|
@ -285,22 +285,22 @@ leds/
|
|||
- directory with info about LED handling under Linux.
|
||||
local_ops.txt
|
||||
- semantics and behavior of local atomic operations.
|
||||
lockdep-design.txt
|
||||
- documentation on the runtime locking correctness validator.
|
||||
locking/
|
||||
- directory with info about kernel locking primitives
|
||||
lockstat.txt
|
||||
- info on collecting statistics on locks (and contention).
|
||||
lockup-watchdogs.txt
|
||||
- info on soft and hard lockup detectors (aka nmi_watchdog).
|
||||
logo.gif
|
||||
- full colour GIF image of Linux logo (penguin - Tux).
|
||||
logo.txt
|
||||
- info on creator of above logo & site to get additional images from.
|
||||
lzo.txt
|
||||
- kernel LZO decompressor input formats
|
||||
m68k/
|
||||
- directory with info about Linux on Motorola 68k architecture.
|
||||
magic-number.txt
|
||||
- list of magic numbers used to mark/protect kernel data structures.
|
||||
mailbox.txt
|
||||
- How to write drivers for the common mailbox framework (IPC).
|
||||
md.txt
|
||||
- info on boot arguments for the multiple devices driver.
|
||||
media-framework.txt
|
||||
|
|
@ -327,8 +327,6 @@ mtd/
|
|||
- directory with info about memory technology devices (flash)
|
||||
mono.txt
|
||||
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
|
||||
mutex-design.txt
|
||||
- info on the generic mutex subsystem.
|
||||
namespaces/
|
||||
- directory with various information about namespaces
|
||||
netlabel/
|
||||
|
|
@ -395,10 +393,6 @@ robust-futexes.txt
|
|||
- a description of what robust futexes are.
|
||||
rpmsg.txt
|
||||
- info on the Remote Processor Messaging (rpmsg) Framework
|
||||
rt-mutex-design.txt
|
||||
- description of the RealTime mutex implementation design.
|
||||
rt-mutex.txt
|
||||
- desc. of RT-mutex subsystem with PI (Priority Inheritance) support.
|
||||
rtc.txt
|
||||
- notes on how to use the Real Time Clock (aka CMOS clock) driver.
|
||||
s390/
|
||||
|
|
@ -425,8 +419,6 @@ sparse.txt
|
|||
- info on how to obtain and use the sparse tool for typechecking.
|
||||
spi/
|
||||
- overview of Linux kernel Serial Peripheral Interface (SPI) support.
|
||||
spinlocks.txt
|
||||
- info on using spinlocks to provide exclusive access in kernel.
|
||||
stable_api_nonsense.txt
|
||||
- info on why the kernel does not have a stable in-kernel api or abi.
|
||||
stable_kernel_rules.txt
|
||||
|
|
@ -483,10 +475,10 @@ wimax/
|
|||
- directory with info about Intel Wireless Wimax Connections
|
||||
workqueue.txt
|
||||
- information on the Concurrency Managed Workqueue implementation
|
||||
ww-mutex-design.txt
|
||||
- Intro to Mutex wait/would deadlock handling.s
|
||||
x86/x86_64/
|
||||
- directory with info on Linux support for AMD x86-64 (Hammer) machines.
|
||||
xillybus.txt
|
||||
- Overview and basic ui of xillybus driver
|
||||
xtensa/
|
||||
- directory with documents relating to arch/xtensa port/implementation
|
||||
xz.txt
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
What: /sys/class/misc/tpmX/device/
|
||||
What: /sys/class/tpm/tpmX/device/
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: tpmdd-devel@lists.sf.net
|
||||
|
|
@ -6,7 +6,7 @@ Description: The device/ directory under a specific TPM instance exposes
|
|||
the properties of that TPM chip
|
||||
|
||||
|
||||
What: /sys/class/misc/tpmX/device/active
|
||||
What: /sys/class/tpm/tpmX/device/active
|
||||
Date: April 2006
|
||||
KernelVersion: 2.6.17
|
||||
Contact: tpmdd-devel@lists.sf.net
|
||||
|
|
@ -18,7 +18,7 @@ Description: The "active" property prints a '1' if the TPM chip is accepting
|
|||
section 17 for more information on which commands are
|
||||
available.
|
||||
|
||||
What: /sys/class/misc/tpmX/device/cancel
|
||||
What: /sys/class/tpm/tpmX/device/cancel
|
||||
Date: June 2005
|
||||
KernelVersion: 2.6.13
|
||||
Contact: tpmdd-devel@lists.sf.net
|
||||
|
|
@ -26,7 +26,7 @@ Description: The "cancel" property allows you to cancel the currently
|
|||
pending TPM command. Writing any value to cancel will call the
|
||||
TPM vendor specific cancel operation.
|
||||
|
||||
What: /sys/class/misc/tpmX/device/caps
|
||||
What: /sys/class/tpm/tpmX/device/caps
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: tpmdd-devel@lists.sf.net
|
||||
|
|
@ -43,7 +43,7 @@ Description: The "caps" property contains TPM manufacturer and version info.
|
|||
the chip supports. Firmware version is that of the chip and
|
||||
is manufacturer specific.
|
||||
|
||||
What: /sys/class/misc/tpmX/device/durations
|
||||
What: /sys/class/tpm/tpmX/device/durations
|
||||
Date: March 2011
|
||||
KernelVersion: 3.1
|
||||
Contact: tpmdd-devel@lists.sf.net
|
||||
|
|
@ -66,7 +66,7 @@ Description: The "durations" property shows the 3 vendor-specific values
|
|||
scaled to be displayed in usecs. In this case "[adjusted]"
|
||||
will be displayed in place of "[original]".
|
||||
|
||||
What: /sys/class/misc/tpmX/device/enabled
|
||||
What: /sys/class/tpm/tpmX/device/enabled
|
||||
Date: April 2006
|
||||
KernelVersion: 2.6.17
|
||||
Contact: tpmdd-devel@lists.sf.net
|
||||
|
|
@ -75,7 +75,7 @@ Description: The "enabled" property prints a '1' if the TPM chip is enabled,
|
|||
may be visible but produce a '0' after some operation that
|
||||
disables the TPM.
|
||||
|
||||
What: /sys/class/misc/tpmX/device/owned
|
||||
What: /sys/class/tpm/tpmX/device/owned
|
||||
Date: April 2006
|
||||
KernelVersion: 2.6.17
|
||||
Contact: tpmdd-devel@lists.sf.net
|
||||
|
|
@ -83,7 +83,7 @@ Description: The "owned" property produces a '1' if the TPM_TakeOwnership
|
|||
ordinal has been executed successfully in the chip. A '0'
|
||||
indicates that ownership hasn't been taken.
|
||||
|
||||
What: /sys/class/misc/tpmX/device/pcrs
|
||||
What: /sys/class/tpm/tpmX/device/pcrs
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: tpmdd-devel@lists.sf.net
|
||||
|
|
@ -106,7 +106,7 @@ Description: The "pcrs" property will dump the current value of all Platform
|
|||
1.2 chips, PCRs represent SHA-1 hashes, which are 20 bytes
|
||||
long. Use the "caps" property to determine TPM version.
|
||||
|
||||
What: /sys/class/misc/tpmX/device/pubek
|
||||
What: /sys/class/tpm/tpmX/device/pubek
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: tpmdd-devel@lists.sf.net
|
||||
|
|
@ -158,7 +158,7 @@ Description: The "pubek" property will return the TPM's public endorsement
|
|||
Modulus Length: 256 (bytes)
|
||||
Modulus: The 256 byte Endorsement Key modulus
|
||||
|
||||
What: /sys/class/misc/tpmX/device/temp_deactivated
|
||||
What: /sys/class/tpm/tpmX/device/temp_deactivated
|
||||
Date: April 2006
|
||||
KernelVersion: 2.6.17
|
||||
Contact: tpmdd-devel@lists.sf.net
|
||||
|
|
@ -167,7 +167,7 @@ Description: The "temp_deactivated" property returns a '1' if the chip has
|
|||
cycle. Whether a warm boot (reboot) will clear a TPM chip
|
||||
from a temp_deactivated state is platform specific.
|
||||
|
||||
What: /sys/class/misc/tpmX/device/timeouts
|
||||
What: /sys/class/tpm/tpmX/device/timeouts
|
||||
Date: March 2011
|
||||
KernelVersion: 3.1
|
||||
Contact: tpmdd-devel@lists.sf.net
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -52,12 +52,18 @@ Description: Per-pmu performance monitoring events specific to the running syste
|
|||
event=0x2abc
|
||||
event=0x423,inv,cmask=0x3
|
||||
domain=0x1,offset=0x8,starting_index=0xffff
|
||||
domain=0x1,offset=0x8,core=?
|
||||
|
||||
Each of the assignments indicates a value to be assigned to a
|
||||
particular set of bits (as defined by the format file
|
||||
corresponding to the <term>) in the perf_event structure passed
|
||||
to the perf_open syscall.
|
||||
|
||||
In the case of the last example, a value replacing "?" would
|
||||
need to be provided by the user selecting the particular event.
|
||||
This is referred to as "event parameterization". Event
|
||||
parameters have the format 'param=?'.
|
||||
|
||||
What: /sys/bus/event_source/devices/<pmu>/events/<event>.unit
|
||||
Date: 2014/02/24
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
|
|
|
|||
|
|
@ -21,3 +21,25 @@ Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
|
|||
Description:
|
||||
Exposes the "version" field of the 24x7 catalog. This is also
|
||||
extractable from the provided binary "catalog" sysfs entry.
|
||||
|
||||
What: /sys/bus/event_source/devices/hv_24x7/event_descs/<event-name>
|
||||
Date: February 2014
|
||||
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
|
||||
Description:
|
||||
Provides the description of a particular event as provided by
|
||||
the firmware. If firmware does not provide a description, no
|
||||
file will be created.
|
||||
|
||||
Note that the event-name lacks the domain suffix appended for
|
||||
events in the events/ dir.
|
||||
|
||||
What: /sys/bus/event_source/devices/hv_24x7/event_long_descs/<event-name>
|
||||
Date: February 2014
|
||||
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
|
||||
Description:
|
||||
Provides the "long" description of a particular event as
|
||||
provided by the firmware. If firmware does not provide a
|
||||
description, no file will be created.
|
||||
|
||||
Note that the event-name lacks the domain suffix appended for
|
||||
events in the events/ dir.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,9 @@
|
|||
Note: Attributes that are shared between devices are stored in the directory
|
||||
pointed to by the symlink device/.
|
||||
Example: The real path of the attribute /sys/class/cxl/afu0.0s/irqs_max is
|
||||
/sys/class/cxl/afu0.0s/device/irqs_max, i.e. /sys/class/cxl/afu0.0/irqs_max.
|
||||
|
||||
|
||||
Slave contexts (eg. /sys/class/cxl/afu0.0s):
|
||||
|
||||
What: /sys/class/cxl/<afu>/irqs_max
|
||||
|
|
@ -67,7 +73,7 @@ Contact: linuxppc-dev@lists.ozlabs.org
|
|||
Description: read only
|
||||
Decimal value of the current version of the kernel/user API.
|
||||
|
||||
What: /sys/class/cxl/<afu>/api_version_com
|
||||
What: /sys/class/cxl/<afu>/api_version_compatible
|
||||
Date: September 2014
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read only
|
||||
|
|
@ -75,6 +81,42 @@ Description: read only
|
|||
this this kernel supports.
|
||||
|
||||
|
||||
AFU configuration records (eg. /sys/class/cxl/afu0.0/cr0):
|
||||
|
||||
An AFU may optionally export one or more PCIe like configuration records, known
|
||||
as AFU configuration records, which will show up here (if present).
|
||||
|
||||
What: /sys/class/cxl/<afu>/cr<config num>/vendor
|
||||
Date: February 2015
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read only
|
||||
Hexadecimal value of the vendor ID found in this AFU
|
||||
configuration record.
|
||||
|
||||
What: /sys/class/cxl/<afu>/cr<config num>/device
|
||||
Date: February 2015
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read only
|
||||
Hexadecimal value of the device ID found in this AFU
|
||||
configuration record.
|
||||
|
||||
What: /sys/class/cxl/<afu>/cr<config num>/vendor
|
||||
Date: February 2015
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read only
|
||||
Hexadecimal value of the class code found in this AFU
|
||||
configuration record.
|
||||
|
||||
What: /sys/class/cxl/<afu>/cr<config num>/config
|
||||
Date: February 2015
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read only
|
||||
This binary file provides raw access to the AFU configuration
|
||||
record. The format is expected to match the either the standard
|
||||
or extended configuration space defined by the PCIe
|
||||
specification.
|
||||
|
||||
|
||||
|
||||
Master contexts (eg. /sys/class/cxl/afu0.0m)
|
||||
|
||||
|
|
@ -106,7 +148,7 @@ Contact: linuxppc-dev@lists.ozlabs.org
|
|||
Description: read only
|
||||
Identifies the CAIA Version the card implements.
|
||||
|
||||
What: /sys/class/cxl/<card>/psl_version
|
||||
What: /sys/class/cxl/<card>/psl_revision
|
||||
Date: September 2014
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read only
|
||||
|
|
@ -127,3 +169,24 @@ Contact: linuxppc-dev@lists.ozlabs.org
|
|||
Description: read only
|
||||
Will return "user" or "factory" depending on the image loaded
|
||||
onto the card.
|
||||
|
||||
What: /sys/class/cxl/<card>/load_image_on_perst
|
||||
Date: December 2014
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read/write
|
||||
Valid entries are "none", "user", and "factory".
|
||||
"none" means PERST will not cause image to be loaded to the
|
||||
card. A power cycle is required to load the image.
|
||||
"none" could be useful for debugging because the trace arrays
|
||||
are preserved.
|
||||
"user" and "factory" means PERST will cause either the user or
|
||||
user or factory image to be loaded.
|
||||
Default is to reload on PERST whichever image the card has
|
||||
loaded.
|
||||
|
||||
What: /sys/class/cxl/<card>/reset
|
||||
Date: October 2014
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: write only
|
||||
Writing 1 will issue a PERST to card which may cause the card
|
||||
to reload the FPGA depending on load_image_on_perst.
|
||||
|
|
|
|||
|
|
@ -32,3 +32,45 @@ Description:
|
|||
Valid values:
|
||||
- 5, 6 or 7 (hours),
|
||||
- 0: disabled.
|
||||
|
||||
What: /sys/class/power_supply/max77693-charger/device/fast_charge_timer
|
||||
Date: January 2015
|
||||
KernelVersion: 3.19.0
|
||||
Contact: Krzysztof Kozlowski <k.kozlowski@samsung.com>
|
||||
Description:
|
||||
This entry shows and sets the maximum time the max77693
|
||||
charger operates in fast-charge mode. When the timer expires
|
||||
the device will terminate fast-charge mode (charging current
|
||||
will drop to 0 A) and will trigger interrupt.
|
||||
|
||||
Valid values:
|
||||
- 4 - 16 (hours), step by 2 (rounded down)
|
||||
- 0: disabled.
|
||||
|
||||
What: /sys/class/power_supply/max77693-charger/device/top_off_threshold_current
|
||||
Date: January 2015
|
||||
KernelVersion: 3.19.0
|
||||
Contact: Krzysztof Kozlowski <k.kozlowski@samsung.com>
|
||||
Description:
|
||||
This entry shows and sets the charging current threshold for
|
||||
entering top-off charging mode. When charging current in fast
|
||||
charge mode drops below this value, the charger will trigger
|
||||
interrupt and start top-off charging mode.
|
||||
|
||||
Valid values:
|
||||
- 100000 - 200000 (microamps), step by 25000 (rounded down)
|
||||
- 200000 - 350000 (microamps), step by 50000 (rounded down)
|
||||
- 0: disabled.
|
||||
|
||||
What: /sys/class/power_supply/max77693-charger/device/top_off_timer
|
||||
Date: January 2015
|
||||
KernelVersion: 3.19.0
|
||||
Contact: Krzysztof Kozlowski <k.kozlowski@samsung.com>
|
||||
Description:
|
||||
This entry shows and sets the maximum time the max77693
|
||||
charger operates in top-off charge mode. When the timer expires
|
||||
the device will terminate top-off charge mode (charging current
|
||||
will drop to 0 A) and will trigger interrupt.
|
||||
|
||||
Valid values:
|
||||
- 0 - 70 (minutes), step by 10 (rounded down)
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
@ -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.
|
||||
|
|
@ -1,60 +0,0 @@
|
|||
What: /sys/class/leds/dell::kbd_backlight/als_setting
|
||||
Date: December 2014
|
||||
KernelVersion: 3.19
|
||||
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
|
||||
Pali Rohár <pali.rohar@gmail.com>
|
||||
Description:
|
||||
This file allows to control the automatic keyboard
|
||||
illumination mode on some systems that have an ambient
|
||||
light sensor. Write 1 to this file to enable the auto
|
||||
mode, 0 to disable it.
|
||||
|
||||
What: /sys/class/leds/dell::kbd_backlight/start_triggers
|
||||
Date: December 2014
|
||||
KernelVersion: 3.19
|
||||
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
|
||||
Pali Rohár <pali.rohar@gmail.com>
|
||||
Description:
|
||||
This file allows to control the input triggers that
|
||||
turn on the keyboard backlight illumination that is
|
||||
disabled because of inactivity.
|
||||
Read the file to see the triggers available. The ones
|
||||
enabled are preceded by '+', those disabled by '-'.
|
||||
|
||||
To enable a trigger, write its name preceded by '+' to
|
||||
this file. To disable a trigger, write its name preceded
|
||||
by '-' instead.
|
||||
|
||||
For example, to enable the keyboard as trigger run:
|
||||
echo +keyboard > /sys/class/leds/dell::kbd_backlight/start_triggers
|
||||
To disable it:
|
||||
echo -keyboard > /sys/class/leds/dell::kbd_backlight/start_triggers
|
||||
|
||||
Note that not all the available triggers can be configured.
|
||||
|
||||
What: /sys/class/leds/dell::kbd_backlight/stop_timeout
|
||||
Date: December 2014
|
||||
KernelVersion: 3.19
|
||||
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
|
||||
Pali Rohár <pali.rohar@gmail.com>
|
||||
Description:
|
||||
This file allows to specify the interval after which the
|
||||
keyboard illumination is disabled because of inactivity.
|
||||
The timeouts are expressed in seconds, minutes, hours and
|
||||
days, for which the symbols are 's', 'm', 'h' and 'd'
|
||||
respectively.
|
||||
|
||||
To configure the timeout, write to this file a value along
|
||||
with any the above units. If no unit is specified, the value
|
||||
is assumed to be expressed in seconds.
|
||||
|
||||
For example, to set the timeout to 10 minutes run:
|
||||
echo 10m > /sys/class/leds/dell::kbd_backlight/stop_timeout
|
||||
|
||||
Note that when this file is read, the returned value might be
|
||||
expressed in a different unit than the one used when the timeout
|
||||
was set.
|
||||
|
||||
Also note that only some timeouts are supported and that
|
||||
some systems might fall back to a specific timeout in case
|
||||
an invalid timeout is written to this file.
|
||||
|
|
@ -21,8 +21,8 @@ running a Linux kernel. Also, not all tools are necessary on all
|
|||
systems; obviously, if you don't have any ISDN hardware, for example,
|
||||
you probably needn't concern yourself with isdn4k-utils.
|
||||
|
||||
o Gnu C 3.2 # gcc --version
|
||||
o Gnu make 3.80 # make --version
|
||||
o GNU C 3.2 # gcc --version
|
||||
o GNU make 3.80 # make --version
|
||||
o binutils 2.12 # ld -v
|
||||
o util-linux 2.10o # fdformat --version
|
||||
o module-init-tools 0.9.10 # depmod -V
|
||||
|
|
@ -57,7 +57,7 @@ computer.
|
|||
Make
|
||||
----
|
||||
|
||||
You will need Gnu make 3.80 or later to build the kernel.
|
||||
You will need GNU make 3.80 or later to build the kernel.
|
||||
|
||||
Binutils
|
||||
--------
|
||||
|
|
|
|||
|
|
@ -527,6 +527,7 @@ values. To do the latter, you can stick the following in your .emacs file:
|
|||
(string-match (expand-file-name "~/src/linux-trees")
|
||||
filename))
|
||||
(setq indent-tabs-mode t)
|
||||
(setq show-trailing-whitespace t)
|
||||
(c-set-style "linux-tabs-only")))))
|
||||
|
||||
This will make emacs go better with the kernel coding style for C
|
||||
|
|
|
|||
|
|
@ -113,7 +113,6 @@
|
|||
!Finclude/net/cfg80211.h cfg80211_beacon_data
|
||||
!Finclude/net/cfg80211.h cfg80211_ap_settings
|
||||
!Finclude/net/cfg80211.h station_parameters
|
||||
!Finclude/net/cfg80211.h station_info_flags
|
||||
!Finclude/net/cfg80211.h rate_info_flags
|
||||
!Finclude/net/cfg80211.h rate_info
|
||||
!Finclude/net/cfg80211.h station_info
|
||||
|
|
@ -435,7 +434,6 @@
|
|||
<section id="ps-client">
|
||||
<title>support for powersaving clients</title>
|
||||
!Pinclude/net/mac80211.h AP support for powersaving clients
|
||||
</section>
|
||||
!Finclude/net/mac80211.h ieee80211_get_buffered_bc
|
||||
!Finclude/net/mac80211.h ieee80211_beacon_get
|
||||
!Finclude/net/mac80211.h ieee80211_sta_eosp
|
||||
|
|
@ -444,6 +442,7 @@
|
|||
!Finclude/net/mac80211.h ieee80211_sta_ps_transition_ni
|
||||
!Finclude/net/mac80211.h ieee80211_sta_set_buffered
|
||||
!Finclude/net/mac80211.h ieee80211_sta_block_awake
|
||||
</section>
|
||||
</chapter>
|
||||
|
||||
<chapter id="multi-iface">
|
||||
|
|
@ -488,8 +487,8 @@
|
|||
<title>RX A-MPDU aggregation</title>
|
||||
!Pnet/mac80211/agg-rx.c RX A-MPDU aggregation
|
||||
!Cnet/mac80211/agg-rx.c
|
||||
</sect1>
|
||||
!Finclude/net/mac80211.h ieee80211_ampdu_mlme_action
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="smps">
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ htmldocs: $(HTML)
|
|||
|
||||
MAN := $(patsubst %.xml, %.9, $(BOOKS))
|
||||
mandocs: $(MAN)
|
||||
$(if $(wildcard $(obj)/man/*.9),gzip -f $(obj)/man/*.9)
|
||||
find $(obj)/man -name '*.9' | xargs gzip -f
|
||||
|
||||
installmandocs: mandocs
|
||||
mkdir -p /usr/local/man/man9/
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@
|
|||
<para>
|
||||
This specification is intended for consumers of the kernel crypto
|
||||
API as well as for developers implementing ciphers. This API
|
||||
specification, however, does not discusses all API calls available
|
||||
specification, however, does not discuss all API calls available
|
||||
to data transformation implementations (i.e. implementations of
|
||||
ciphers and other transformations (such as CRC or even compression
|
||||
algorithms) that can register with the kernel crypto API).
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@
|
|||
a development machine and the other is the target machine. The
|
||||
kernel to be debugged runs on the target machine. The development
|
||||
machine runs an instance of gdb against the vmlinux file which
|
||||
contains the symbols (not boot image such as bzImage, zImage,
|
||||
contains the symbols (not a boot image such as bzImage, zImage,
|
||||
uImage...). In gdb the developer specifies the connection
|
||||
parameters and connects to kgdb. The type of connection a
|
||||
developer makes with gdb depends on the availability of kgdb I/O
|
||||
|
|
@ -95,7 +95,7 @@
|
|||
<title>Kernel config options for kgdb</title>
|
||||
<para>
|
||||
To enable <symbol>CONFIG_KGDB</symbol> you should look under
|
||||
"Kernel debugging" and select "KGDB: kernel debugger".
|
||||
"Kernel hacking" / "Kernel debugging" and select "KGDB: kernel debugger".
|
||||
</para>
|
||||
<para>
|
||||
While it is not a hard requirement that you have symbols in your
|
||||
|
|
@ -105,7 +105,7 @@
|
|||
kernel with debug info" in the config menu.
|
||||
</para>
|
||||
<para>
|
||||
It is advised, but not required that you turn on the
|
||||
It is advised, but not required, that you turn on the
|
||||
<symbol>CONFIG_FRAME_POINTER</symbol> kernel option which is called "Compile the
|
||||
kernel with frame pointers" in the config menu. This option
|
||||
inserts code to into the compiled executable which saves the frame
|
||||
|
|
@ -181,7 +181,7 @@
|
|||
<para>This section describes the various runtime kernel
|
||||
parameters that affect the configuration of the kernel debugger.
|
||||
The following chapter covers using kdb and kgdb as well as
|
||||
provides some examples of the configuration parameters.</para>
|
||||
providing some examples of the configuration parameters.</para>
|
||||
<sect1 id="kgdboc">
|
||||
<title>Kernel parameter: kgdboc</title>
|
||||
<para>The kgdboc driver was originally an abbreviation meant to
|
||||
|
|
@ -219,8 +219,8 @@
|
|||
<listitem><para>kbd = Keyboard</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<para>You can configure kgdboc to use the keyboard, and or a serial
|
||||
device depending on if you are using kdb and or kgdb, in one of the
|
||||
<para>You can configure kgdboc to use the keyboard, and/or a serial
|
||||
device depending on if you are using kdb and/or kgdb, in one of the
|
||||
following scenarios. The order listed above must be observed if
|
||||
you use any of the optional configurations together. Using kms +
|
||||
only gdb is generally not a useful combination.</para>
|
||||
|
|
@ -261,11 +261,8 @@
|
|||
</sect3>
|
||||
<sect3 id="kgdbocArgs3">
|
||||
<title>More examples</title>
|
||||
<para>You can configure kgdboc to use the keyboard, and or a serial
|
||||
device depending on if you are using kdb and or kgdb, in one of the
|
||||
following scenarios.</para>
|
||||
<para>You can configure kgdboc to use the keyboard, and or a serial device
|
||||
depending on if you are using kdb and or kgdb, in one of the
|
||||
<para>You can configure kgdboc to use the keyboard, and/or a serial device
|
||||
depending on if you are using kdb and/or kgdb, in one of the
|
||||
following scenarios.
|
||||
<orderedlist>
|
||||
<listitem><para>kdb and kgdb over only a serial port</para>
|
||||
|
|
@ -315,7 +312,7 @@
|
|||
<para>
|
||||
The Kernel command line option <constant>kgdbwait</constant> makes
|
||||
kgdb wait for a debugger connection during booting of a kernel. You
|
||||
can only use this option you compiled a kgdb I/O driver into the
|
||||
can only use this option if you compiled a kgdb I/O driver into the
|
||||
kernel and you specified the I/O driver configuration as a kernel
|
||||
command line option. The kgdbwait parameter should always follow the
|
||||
configuration parameter for the kgdb I/O driver in the kernel
|
||||
|
|
@ -354,7 +351,7 @@
|
|||
</listitem>
|
||||
</orderedlist>
|
||||
<para>IMPORTANT NOTE: You cannot use kgdboc + kgdbcon on a tty that is an
|
||||
active system console. An example incorrect usage is <constant>console=ttyS0,115200 kgdboc=ttyS0 kgdbcon</constant>
|
||||
active system console. An example of incorrect usage is <constant>console=ttyS0,115200 kgdboc=ttyS0 kgdbcon</constant>
|
||||
</para>
|
||||
<para>It is possible to use this option with kgdboc on a tty that is not a system console.
|
||||
</para>
|
||||
|
|
@ -386,12 +383,12 @@
|
|||
<title>Quick start for kdb on a serial port</title>
|
||||
<para>This is a quick example of how to use kdb.</para>
|
||||
<para><orderedlist>
|
||||
<listitem><para>Boot kernel with arguments:
|
||||
<listitem><para>Configure kgdboc at boot using kernel parameters:
|
||||
<itemizedlist>
|
||||
<listitem><para><constant>console=ttyS0,115200 kgdboc=ttyS0,115200</constant></para></listitem>
|
||||
</itemizedlist></para>
|
||||
<para>OR</para>
|
||||
<para>Configure kgdboc after the kernel booted; assuming you are using a serial port console:
|
||||
<para>Configure kgdboc after the kernel has booted; assuming you are using a serial port console:
|
||||
<itemizedlist>
|
||||
<listitem><para><constant>echo ttyS0 > /sys/module/kgdboc/parameters/kgdboc</constant></para></listitem>
|
||||
</itemizedlist>
|
||||
|
|
@ -442,12 +439,12 @@
|
|||
<title>Quick start for kdb using a keyboard connected console</title>
|
||||
<para>This is a quick example of how to use kdb with a keyboard.</para>
|
||||
<para><orderedlist>
|
||||
<listitem><para>Boot kernel with arguments:
|
||||
<listitem><para>Configure kgdboc at boot using kernel parameters:
|
||||
<itemizedlist>
|
||||
<listitem><para><constant>kgdboc=kbd</constant></para></listitem>
|
||||
</itemizedlist></para>
|
||||
<para>OR</para>
|
||||
<para>Configure kgdboc after the kernel booted:
|
||||
<para>Configure kgdboc after the kernel has booted:
|
||||
<itemizedlist>
|
||||
<listitem><para><constant>echo kbd > /sys/module/kgdboc/parameters/kgdboc</constant></para></listitem>
|
||||
</itemizedlist>
|
||||
|
|
@ -501,12 +498,12 @@
|
|||
<title>Connecting with gdb to a serial port</title>
|
||||
<orderedlist>
|
||||
<listitem><para>Configure kgdboc</para>
|
||||
<para>Boot kernel with arguments:
|
||||
<para>Configure kgdboc at boot using kernel parameters:
|
||||
<itemizedlist>
|
||||
<listitem><para><constant>kgdboc=ttyS0,115200</constant></para></listitem>
|
||||
</itemizedlist></para>
|
||||
<para>OR</para>
|
||||
<para>Configure kgdboc after the kernel booted:
|
||||
<para>Configure kgdboc after the kernel has booted:
|
||||
<itemizedlist>
|
||||
<listitem><para><constant>echo ttyS0 > /sys/module/kgdboc/parameters/kgdboc</constant></para></listitem>
|
||||
</itemizedlist></para>
|
||||
|
|
@ -536,7 +533,7 @@
|
|||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Connect from from gdb</para>
|
||||
<para>Connect from gdb</para>
|
||||
<para>
|
||||
Example (using a directly connected port):
|
||||
</para>
|
||||
|
|
@ -584,7 +581,7 @@
|
|||
<para>
|
||||
There are two ways to switch from kgdb to kdb: you can use gdb to
|
||||
issue a maintenance packet, or you can blindly type the command $3#33.
|
||||
Whenever kernel debugger stops in kgdb mode it will print the
|
||||
Whenever the kernel debugger stops in kgdb mode it will print the
|
||||
message <constant>KGDB or $3#33 for KDB</constant>. It is important
|
||||
to note that you have to type the sequence correctly in one pass.
|
||||
You cannot type a backspace or delete because kgdb will interpret
|
||||
|
|
@ -704,7 +701,7 @@ Task Addr Pid Parent [*] cpu State Thread Command
|
|||
<listitem><para>Registration and unregistration of architecture specific trap hooks</para></listitem>
|
||||
<listitem><para>Any special exception handling and cleanup</para></listitem>
|
||||
<listitem><para>NMI exception handling and cleanup</para></listitem>
|
||||
<listitem><para>(optional)HW breakpoints</para></listitem>
|
||||
<listitem><para>(optional) HW breakpoints</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
|
|
@ -760,7 +757,7 @@ Task Addr Pid Parent [*] cpu State Thread Command
|
|||
a kgdb I/O driver for characters when it needs input. The I/O
|
||||
driver is expected to return immediately if there is no data
|
||||
available. Doing so allows for the future possibility to touch
|
||||
watch dog hardware in such a way as to have a target system not
|
||||
watchdog hardware in such a way as to have a target system not
|
||||
reset when these are enabled.
|
||||
</para>
|
||||
</listitem>
|
||||
|
|
@ -779,21 +776,25 @@ Task Addr Pid Parent [*] cpu State Thread Command
|
|||
their <asm/kgdb.h> file. These are:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
NUMREGBYTES: The size in bytes of all of the registers, so
|
||||
that we can ensure they will all fit into a packet.
|
||||
</para>
|
||||
<para>
|
||||
BUFMAX: The size in bytes of the buffer GDB will read into.
|
||||
This must be larger than NUMREGBYTES.
|
||||
</para>
|
||||
<para>
|
||||
CACHE_FLUSH_IS_SAFE: Set to 1 if it is always safe to call
|
||||
flush_cache_range or flush_icache_range. On some architectures,
|
||||
these functions may not be safe to call on SMP since we keep other
|
||||
CPUs in a holding pattern.
|
||||
</para>
|
||||
</listitem>
|
||||
<para>
|
||||
NUMREGBYTES: The size in bytes of all of the registers, so
|
||||
that we can ensure they will all fit into a packet.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
BUFMAX: The size in bytes of the buffer GDB will read into.
|
||||
This must be larger than NUMREGBYTES.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
CACHE_FLUSH_IS_SAFE: Set to 1 if it is always safe to call
|
||||
flush_cache_range or flush_icache_range. On some architectures,
|
||||
these functions may not be safe to call on SMP since we keep other
|
||||
CPUs in a holding pattern.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<para>
|
||||
|
|
@ -812,8 +813,8 @@ Task Addr Pid Parent [*] cpu State Thread Command
|
|||
<para>
|
||||
The kgdboc driver is actually a very thin driver that relies on the
|
||||
underlying low level to the hardware driver having "polling hooks"
|
||||
which the to which the tty driver is attached. In the initial
|
||||
implementation of kgdboc it the serial_core was changed to expose a
|
||||
to which the tty driver is attached. In the initial
|
||||
implementation of kgdboc the serial_core was changed to expose a
|
||||
low level UART hook for doing polled mode reading and writing of a
|
||||
single character while in an atomic context. When kgdb makes an I/O
|
||||
request to the debugger, kgdboc invokes a callback in the serial
|
||||
|
|
|
|||
|
|
@ -2692,12 +2692,11 @@ in the S5P family of SoCs by Samsung.
|
|||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_MFC51_VIDEO_DECODER_H264_DISPLAY_DELAY_ENABLE</constant> </entry>
|
||||
<entry>integer</entry>
|
||||
</row><row><entry spanname="descr">If the display delay is enabled then the decoder has to return a
|
||||
CAPTURE buffer after processing a certain number of OUTPUT buffers. If this number is low, then it may result in
|
||||
buffers not being dequeued in display order. In addition hardware may still use those buffers as reference, thus
|
||||
application should not write to those buffers. This feature can be used for example for generating thumbnails of videos.
|
||||
Applicable to the H264 decoder.
|
||||
<entry>boolean</entry>
|
||||
</row><row><entry spanname="descr">If the display delay is enabled then the decoder is forced to return a
|
||||
CAPTURE buffer (decoded frame) after processing a certain number of OUTPUT buffers. The delay can be set through
|
||||
<constant>V4L2_CID_MPEG_MFC51_VIDEO_DECODER_H264_DISPLAY_DELAY</constant>. This feature can be used for example
|
||||
for generating thumbnails of videos. Applicable to the H264 decoder.
|
||||
</entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@
|
|||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>The following four pixel formats are raw sRGB / Bayer formats with
|
||||
<para>These four pixel formats are raw sRGB / Bayer formats with
|
||||
10 bits per colour. Each colour component is stored in a 16-bit word, with 6
|
||||
unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
|
||||
and n/2 blue or red samples, with alternating red and blue rows. Bytes are
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@
|
|||
</refnamediv>
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
<para>The following four pixel formats are raw sRGB / Bayer
|
||||
<para>These four pixel formats are raw sRGB / Bayer
|
||||
formats with 10 bits per color compressed to 8 bits each,
|
||||
using the A-LAW algorithm. Each color component consumes 8
|
||||
bits of memory. In other respects this format is similar to
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@
|
|||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>The following four pixel formats are raw sRGB / Bayer formats
|
||||
<para>These four pixel formats are raw sRGB / Bayer formats
|
||||
with 10 bits per colour compressed to 8 bits each, using DPCM
|
||||
compression. DPCM, differential pulse-code modulation, is lossy.
|
||||
Each colour component consumes 8 bits of memory. In other respects
|
||||
|
|
|
|||
|
|
@ -0,0 +1,99 @@
|
|||
<refentry id="pixfmt-srggb10p">
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_PIX_FMT_SRGGB10P ('pRAA'),
|
||||
V4L2_PIX_FMT_SGRBG10P ('pgAA'),
|
||||
V4L2_PIX_FMT_SGBRG10P ('pGAA'),
|
||||
V4L2_PIX_FMT_SBGGR10P ('pBAA'),
|
||||
</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname id="V4L2-PIX-FMT-SRGGB10P"><constant>V4L2_PIX_FMT_SRGGB10P</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-SGRBG10P"><constant>V4L2_PIX_FMT_SGRBG10P</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-SGBRG10P"><constant>V4L2_PIX_FMT_SGBRG10P</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-SBGGR10P"><constant>V4L2_PIX_FMT_SBGGR10P</constant></refname>
|
||||
<refpurpose>10-bit packed Bayer formats</refpurpose>
|
||||
</refnamediv>
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>These four pixel formats are packed raw sRGB /
|
||||
Bayer formats with 10 bits per colour. Every four consecutive
|
||||
colour components are packed into 5 bytes. Each of the first 4
|
||||
bytes contain the 8 high order bits of the pixels, and the
|
||||
fifth byte contains the two least significants bits of each
|
||||
pixel, in the same order.</para>
|
||||
|
||||
<para>Each n-pixel row contains n/2 green samples and n/2 blue
|
||||
or red samples, with alternating green-red and green-blue
|
||||
rows. They are conventionally described as GRGR... BGBG...,
|
||||
RGRG... GBGB..., etc. Below is an example of one of these
|
||||
formats:</para>
|
||||
|
||||
<example>
|
||||
<title><constant>V4L2_PIX_FMT_SBGGR10P</constant> 4 × 4
|
||||
pixel image</title>
|
||||
|
||||
<formalpara>
|
||||
<title>Byte Order.</title>
|
||||
<para>Each cell is one byte.
|
||||
<informaltable frame="topbot" colsep="1" rowsep="1">
|
||||
<tgroup cols="5" align="center" border="1">
|
||||
<colspec align="left" colwidth="2*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>start + 0:</entry>
|
||||
<entry>B<subscript>00high</subscript></entry>
|
||||
<entry>G<subscript>01high</subscript></entry>
|
||||
<entry>B<subscript>02high</subscript></entry>
|
||||
<entry>G<subscript>03high</subscript></entry>
|
||||
<entry>B<subscript>00low</subscript>(bits 7--6)
|
||||
G<subscript>01low</subscript>(bits 5--4)
|
||||
B<subscript>02low</subscript>(bits 3--2)
|
||||
G<subscript>03low</subscript>(bits 1--0)
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 5:</entry>
|
||||
<entry>G<subscript>10high</subscript></entry>
|
||||
<entry>R<subscript>11high</subscript></entry>
|
||||
<entry>G<subscript>12high</subscript></entry>
|
||||
<entry>R<subscript>13high</subscript></entry>
|
||||
<entry>G<subscript>10low</subscript>(bits 7--6)
|
||||
R<subscript>11low</subscript>(bits 5--4)
|
||||
G<subscript>12low</subscript>(bits 3--2)
|
||||
R<subscript>13low</subscript>(bits 1--0)
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 10:</entry>
|
||||
<entry>B<subscript>20high</subscript></entry>
|
||||
<entry>G<subscript>21high</subscript></entry>
|
||||
<entry>B<subscript>22high</subscript></entry>
|
||||
<entry>G<subscript>23high</subscript></entry>
|
||||
<entry>B<subscript>20low</subscript>(bits 7--6)
|
||||
G<subscript>21low</subscript>(bits 5--4)
|
||||
B<subscript>22low</subscript>(bits 3--2)
|
||||
G<subscript>23low</subscript>(bits 1--0)
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 15:</entry>
|
||||
<entry>G<subscript>30high</subscript></entry>
|
||||
<entry>R<subscript>31high</subscript></entry>
|
||||
<entry>G<subscript>32high</subscript></entry>
|
||||
<entry>R<subscript>33high</subscript></entry>
|
||||
<entry>G<subscript>30low</subscript>(bits 7--6)
|
||||
R<subscript>31low</subscript>(bits 5--4)
|
||||
G<subscript>32low</subscript>(bits 3--2)
|
||||
R<subscript>33low</subscript>(bits 1--0)
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
</example>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -17,7 +17,7 @@
|
|||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>The following four pixel formats are raw sRGB / Bayer formats with
|
||||
<para>These four pixel formats are raw sRGB / Bayer formats with
|
||||
12 bits per colour. Each colour component is stored in a 16-bit word, with 4
|
||||
unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
|
||||
and n/2 blue or red samples, with alternating red and blue rows. Bytes are
|
||||
|
|
|
|||
|
|
@ -1405,6 +1405,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.<
|
|||
&sub-srggb8;
|
||||
&sub-sbggr16;
|
||||
&sub-srggb10;
|
||||
&sub-srggb10p;
|
||||
&sub-srggb10alaw8;
|
||||
&sub-srggb10dpcm8;
|
||||
&sub-srggb12;
|
||||
|
|
|
|||
|
|
@ -212,11 +212,3 @@ standards set in the <structfield>standards</structfield> field.
|
|||
&return-value;
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-parent-document: "v4l2.sgml"
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
-->
|
||||
|
|
|
|||
|
|
@ -131,11 +131,3 @@ is out of bounds or the <structfield>pad</structfield> number is invalid.</para>
|
|||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-parent-document: "v4l2.sgml"
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
-->
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
|
|||
21 seconds.
|
||||
|
||||
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.
|
||||
So if you are 10 seconds into a 40-second stall, setting this
|
||||
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
|
||||
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
|
||||
|
||||
|
|
@ -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()
|
||||
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
|
||||
happen to preempt a low-priority task in the middle of an RCU
|
||||
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:
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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/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/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/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/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/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/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/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.
|
||||
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
|
||||
/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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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/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/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/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/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/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/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/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
|
||||
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
|
||||
can greatly increase the chances of your change being accepted.
|
||||
|
||||
Read Documentation/SubmitChecklist for a list of items to check
|
||||
before submitting code. If you are submitting a driver, also read
|
||||
Documentation/SubmittingDrivers.
|
||||
This document contains a large number of suggestions in a relatively terse
|
||||
format. For detailed information on how the kernel development process
|
||||
works, see Documentation/development-process. Also, read
|
||||
Documentation/SubmitChecklist for a list of items to check before
|
||||
submitting code. If you are submitting a driver, also read
|
||||
Documentation/SubmittingDrivers; for device tree binding patches, read
|
||||
Documentation/devicetree/bindings/submitting-patches.txt.
|
||||
|
||||
Many of these steps describe the default behavior of the git version
|
||||
control system; if you use git to prepare your patches, you'll find much
|
||||
of the mechanical work done for you, though you'll still need to prepare
|
||||
and document a sensible set of patches.
|
||||
and document a sensible set of patches. In general, use of git will make
|
||||
your life as a kernel developer easier.
|
||||
|
||||
--------------------------------------------
|
||||
SECTION 1 - CREATING AND SENDING YOUR CHANGE
|
||||
--------------------------------------------
|
||||
|
||||
|
||||
0) Obtain a current source tree
|
||||
-------------------------------
|
||||
|
||||
If you do not have a repository with the current kernel source handy, use
|
||||
git to obtain one. You'll want to start with the mainline repository,
|
||||
which can be grabbed with:
|
||||
|
||||
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
|
||||
|
||||
Note, however, that you may not want to develop against the mainline tree
|
||||
directly. Most subsystem maintainers run their own trees and want to see
|
||||
patches prepared against those trees. See the "T:" entry for the subsystem
|
||||
in the MAINTAINERS file to find that tree, or simply ask the maintainer if
|
||||
the tree is not listed there.
|
||||
|
||||
It is still possible to download kernel releases via tarballs (as described
|
||||
in the next section), but that is the hard way to do kernel development.
|
||||
|
||||
1) "diff -up"
|
||||
------------
|
||||
|
||||
Use "diff -up" or "diff -uprN" to create patches. git generates patches
|
||||
in this form by default; if you're using git, you can skip this section
|
||||
entirely.
|
||||
If you must generate your patches by hand, use "diff -up" or "diff -uprN"
|
||||
to create patches. Git generates patches in this form by default; if
|
||||
you're using git, you can skip this section entirely.
|
||||
|
||||
All changes to the Linux kernel occur in the form of patches, as
|
||||
generated by diff(1). When creating your patch, make sure to create it
|
||||
|
|
@ -42,7 +64,7 @@ not in any lower subdirectory.
|
|||
|
||||
To create a patch for a single file, it is often sufficient to do:
|
||||
|
||||
SRCTREE= linux-2.6
|
||||
SRCTREE= linux
|
||||
MYFILE= drivers/net/mydriver.c
|
||||
|
||||
cd $SRCTREE
|
||||
|
|
@ -55,17 +77,16 @@ To create a patch for multiple files, you should unpack a "vanilla",
|
|||
or unmodified kernel source tree, and generate a diff against your
|
||||
own source tree. For example:
|
||||
|
||||
MYSRC= /devel/linux-2.6
|
||||
MYSRC= /devel/linux
|
||||
|
||||
tar xvfz linux-2.6.12.tar.gz
|
||||
mv linux-2.6.12 linux-2.6.12-vanilla
|
||||
diff -uprN -X linux-2.6.12-vanilla/Documentation/dontdiff \
|
||||
linux-2.6.12-vanilla $MYSRC > /tmp/patch
|
||||
tar xvfz linux-3.19.tar.gz
|
||||
mv linux-3.19 linux-3.19-vanilla
|
||||
diff -uprN -X linux-3.19-vanilla/Documentation/dontdiff \
|
||||
linux-3.19-vanilla $MYSRC > /tmp/patch
|
||||
|
||||
"dontdiff" is a list of files which are generated by the kernel during
|
||||
the build process, and should be ignored in any diff(1)-generated
|
||||
patch. The "dontdiff" file is included in the kernel tree in
|
||||
2.6.12 and later.
|
||||
patch.
|
||||
|
||||
Make sure your patch does not include any extra files which do not
|
||||
belong in a patch submission. Make sure to review your patch -after-
|
||||
|
|
@ -83,6 +104,7 @@ is another popular alternative.
|
|||
|
||||
|
||||
2) Describe your changes.
|
||||
-------------------------
|
||||
|
||||
Describe your problem. Whether your patch is a one-line bug fix or
|
||||
5000 lines of a new feature, there must be an underlying problem that
|
||||
|
|
@ -124,10 +146,10 @@ See #3, next.
|
|||
When you submit or resubmit a patch or patch series, include the
|
||||
complete patch description and justification for it. Don't just
|
||||
say that this is version N of the patch (series). Don't expect the
|
||||
patch merger to refer back to earlier patch versions or referenced
|
||||
subsystem maintainer to refer back to earlier patch versions or referenced
|
||||
URLs to find the patch description and put that into the patch.
|
||||
I.e., the patch (series) and its description should be self-contained.
|
||||
This benefits both the patch merger(s) and reviewers. Some reviewers
|
||||
This benefits both the maintainers and reviewers. Some reviewers
|
||||
probably didn't even receive earlier versions of the patch.
|
||||
|
||||
Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
|
||||
|
|
@ -156,10 +178,15 @@ Example:
|
|||
platform_set_drvdata(), but left the variable "dev" unused,
|
||||
delete it.
|
||||
|
||||
You should also be sure to use at least the first twelve characters of the
|
||||
SHA-1 ID. The kernel repository holds a *lot* of objects, making
|
||||
collisions with shorter IDs a real possibility. Bear in mind that, even if
|
||||
there is no collision with your six-character ID now, that condition may
|
||||
change five years from now.
|
||||
|
||||
If your patch fixes a bug in a specific commit, e.g. you found an issue using
|
||||
git-bisect, please use the 'Fixes:' tag with the first 12 characters of the
|
||||
SHA-1 ID, and the one line summary.
|
||||
Example:
|
||||
SHA-1 ID, and the one line summary. For example:
|
||||
|
||||
Fixes: e21d2170f366 ("video: remove unnecessary platform_set_drvdata()")
|
||||
|
||||
|
|
@ -172,8 +199,9 @@ outputting the above style in the git log or git show commands
|
|||
fixes = Fixes: %h (\"%s\")
|
||||
|
||||
3) Separate your changes.
|
||||
-------------------------
|
||||
|
||||
Separate _logical changes_ into a single patch file.
|
||||
Separate each _logical change_ into a separate patch.
|
||||
|
||||
For example, if your changes include both bug fixes and performance
|
||||
enhancements for a single driver, separate those changes into two
|
||||
|
|
@ -184,90 +212,116 @@ On the other hand, if you make a single change to numerous files,
|
|||
group those changes into a single patch. Thus a single logical change
|
||||
is contained within a single patch.
|
||||
|
||||
The point to remember is that each patch should make an easily understood
|
||||
change that can be verified by reviewers. Each patch should be justifiable
|
||||
on its own merits.
|
||||
|
||||
If one patch depends on another patch in order for a change to be
|
||||
complete, that is OK. Simply note "this patch depends on patch X"
|
||||
in your patch description.
|
||||
|
||||
When dividing your change into a series of patches, take special care to
|
||||
ensure that the kernel builds and runs properly after each patch in the
|
||||
series. Developers using "git bisect" to track down a problem can end up
|
||||
splitting your patch series at any point; they will not thank you if you
|
||||
introduce bugs in the middle.
|
||||
|
||||
If you cannot condense your patch set into a smaller set of patches,
|
||||
then only post say 15 or so at a time and wait for review and integration.
|
||||
|
||||
|
||||
|
||||
4) Style check your changes.
|
||||
4) Style-check your changes.
|
||||
----------------------------
|
||||
|
||||
Check your patch for basic style violations, details of which can be
|
||||
found in Documentation/CodingStyle. Failure to do so simply wastes
|
||||
the reviewers time and will get your patch rejected, probably
|
||||
without even being read.
|
||||
|
||||
At a minimum you should check your patches with the patch style
|
||||
checker prior to submission (scripts/checkpatch.pl). You should
|
||||
be able to justify all violations that remain in your patch.
|
||||
One significant exception is when moving code from one file to
|
||||
another -- in this case you should not modify the moved code at all in
|
||||
the same patch which moves it. This clearly delineates the act of
|
||||
moving the code and your changes. This greatly aids review of the
|
||||
actual differences and allows tools to better track the history of
|
||||
the code itself.
|
||||
|
||||
Check your patches with the patch style checker prior to submission
|
||||
(scripts/checkpatch.pl). Note, though, that the style checker should be
|
||||
viewed as a guide, not as a replacement for human judgment. If your code
|
||||
looks better with a violation then its probably best left alone.
|
||||
|
||||
The checker reports at three levels:
|
||||
- ERROR: things that are very likely to be wrong
|
||||
- WARNING: things requiring careful review
|
||||
- CHECK: things requiring thought
|
||||
|
||||
You should be able to justify all violations that remain in your
|
||||
patch.
|
||||
|
||||
|
||||
5) Select the recipients for your patch.
|
||||
----------------------------------------
|
||||
|
||||
5) Select e-mail destination.
|
||||
You should always copy the appropriate subsystem maintainer(s) on any patch
|
||||
to code that they maintain; look through the MAINTAINERS file and the
|
||||
source code revision history to see who those maintainers are. The
|
||||
script scripts/get_maintainer.pl can be very useful at this step. If you
|
||||
cannot find a maintainer for the subsystem your are working on, Andrew
|
||||
Morton (akpm@linux-foundation.org) serves as a maintainer of last resort.
|
||||
|
||||
Look through the MAINTAINERS file and the source code, and determine
|
||||
if your change applies to a specific subsystem of the kernel, with
|
||||
an assigned maintainer. If so, e-mail that person. The script
|
||||
scripts/get_maintainer.pl can be very useful at this step.
|
||||
|
||||
If no maintainer is listed, or the maintainer does not respond, send
|
||||
your patch to the primary Linux kernel developer's mailing list,
|
||||
linux-kernel@vger.kernel.org. Most kernel developers monitor this
|
||||
e-mail list, and can comment on your changes.
|
||||
You should also normally choose at least one mailing list to receive a copy
|
||||
of your patch set. linux-kernel@vger.kernel.org functions as a list of
|
||||
last resort, but the volume on that list has caused a number of developers
|
||||
to tune it out. Look in the MAINTAINERS file for a subsystem-specific
|
||||
list; your patch will probably get more attention there. Please do not
|
||||
spam unrelated lists, though.
|
||||
|
||||
Many kernel-related lists are hosted on vger.kernel.org; you can find a
|
||||
list of them at http://vger.kernel.org/vger-lists.html. There are
|
||||
kernel-related lists hosted elsewhere as well, though.
|
||||
|
||||
Do not send more than 15 patches at once to the vger mailing lists!!!
|
||||
|
||||
|
||||
Linus Torvalds is the final arbiter of all changes accepted into the
|
||||
Linux kernel. His e-mail address is <torvalds@linux-foundation.org>.
|
||||
He gets a lot of e-mail, so typically you should do your best to -avoid-
|
||||
sending him e-mail.
|
||||
Linux kernel. His e-mail address is <torvalds@linux-foundation.org>.
|
||||
He gets a lot of e-mail, and, at this point, very few patches go through
|
||||
Linus directly, so typically you should do your best to -avoid-
|
||||
sending him e-mail.
|
||||
|
||||
Patches which are bug fixes, are "obvious" changes, or similarly
|
||||
require little discussion should be sent or CC'd to Linus. Patches
|
||||
which require discussion or do not have a clear advantage should
|
||||
usually be sent first to linux-kernel. Only after the patch is
|
||||
discussed should the patch then be submitted to Linus.
|
||||
If you have a patch that fixes an exploitable security bug, send that patch
|
||||
to security@kernel.org. For severe bugs, a short embargo may be considered
|
||||
to allow distrbutors to get the patch out to users; in such cases,
|
||||
obviously, the patch should not be sent to any public lists.
|
||||
|
||||
Patches that fix a severe bug in a released kernel should be directed
|
||||
toward the stable maintainers by putting a line like this:
|
||||
|
||||
Cc: stable@vger.kernel.org
|
||||
|
||||
6) Select your CC (e-mail carbon copy) list.
|
||||
into your patch.
|
||||
|
||||
Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org.
|
||||
Note, however, that some subsystem maintainers want to come to their own
|
||||
conclusions on which patches should go to the stable trees. The networking
|
||||
maintainer, in particular, would rather not see individual developers
|
||||
adding lines like the above to their patches.
|
||||
|
||||
Other kernel developers besides Linus need to be aware of your change,
|
||||
so that they may comment on it and offer code review and suggestions.
|
||||
linux-kernel is the primary Linux kernel developer mailing list.
|
||||
Other mailing lists are available for specific subsystems, such as
|
||||
USB, framebuffer devices, the VFS, the SCSI subsystem, etc. See the
|
||||
MAINTAINERS file for a mailing list that relates specifically to
|
||||
your change.
|
||||
|
||||
Majordomo lists of VGER.KERNEL.ORG at:
|
||||
<http://vger.kernel.org/vger-lists.html>
|
||||
|
||||
If changes affect userland-kernel interfaces, please send
|
||||
the MAN-PAGES maintainer (as listed in the MAINTAINERS file)
|
||||
a man-pages patch, or at least a notification of the change,
|
||||
so that some information makes its way into the manual pages.
|
||||
|
||||
Even if the maintainer did not respond in step #5, make sure to ALWAYS
|
||||
copy the maintainer when you change their code.
|
||||
If changes affect userland-kernel interfaces, please send the MAN-PAGES
|
||||
maintainer (as listed in the MAINTAINERS file) a man-pages patch, or at
|
||||
least a notification of the change, so that some information makes its way
|
||||
into the manual pages. User-space API changes should also be copied to
|
||||
linux-api@vger.kernel.org.
|
||||
|
||||
For small patches you may want to CC the Trivial Patch Monkey
|
||||
trivial@kernel.org which collects "trivial" patches. Have a look
|
||||
into the MAINTAINERS file for its current manager.
|
||||
Trivial patches must qualify for one of the following rules:
|
||||
Spelling fixes in documentation
|
||||
Spelling fixes which could break grep(1)
|
||||
Spelling fixes for errors which could break grep(1)
|
||||
Warning fixes (cluttering with useless warnings is bad)
|
||||
Compilation fixes (only if they are actually correct)
|
||||
Runtime fixes (only if they actually fix things)
|
||||
Removing use of deprecated functions/macros (eg. check_region)
|
||||
Removing use of deprecated functions/macros
|
||||
Contact detail and documentation fixes
|
||||
Non-portable code replaced by portable code (even in arch-specific,
|
||||
since people copy, as long as it's trivial)
|
||||
|
|
@ -276,7 +330,8 @@ Trivial patches must qualify for one of the following rules:
|
|||
|
||||
|
||||
|
||||
7) No MIME, no links, no compression, no attachments. Just plain text.
|
||||
6) No MIME, no links, no compression, no attachments. Just plain text.
|
||||
-----------------------------------------------------------------------
|
||||
|
||||
Linus and other kernel developers need to be able to read and comment
|
||||
on the changes you are submitting. It is important for a kernel
|
||||
|
|
@ -299,54 +354,48 @@ you to re-send them using MIME.
|
|||
See Documentation/email-clients.txt for hints about configuring
|
||||
your e-mail client so that it sends your patches untouched.
|
||||
|
||||
8) E-mail size.
|
||||
|
||||
When sending patches to Linus, always follow step #7.
|
||||
7) E-mail size.
|
||||
---------------
|
||||
|
||||
Large changes are not appropriate for mailing lists, and some
|
||||
maintainers. If your patch, uncompressed, exceeds 300 kB in size,
|
||||
it is preferred that you store your patch on an Internet-accessible
|
||||
server, and provide instead a URL (link) pointing to your patch.
|
||||
server, and provide instead a URL (link) pointing to your patch. But note
|
||||
that if your patch exceeds 300 kB, it almost certainly needs to be broken up
|
||||
anyway.
|
||||
|
||||
8) Respond to review comments.
|
||||
------------------------------
|
||||
|
||||
Your patch will almost certainly get comments from reviewers on ways in
|
||||
which the patch can be improved. You must respond to those comments;
|
||||
ignoring reviewers is a good way to get ignored in return. Review comments
|
||||
or questions that do not lead to a code change should almost certainly
|
||||
bring about a comment or changelog entry so that the next reviewer better
|
||||
understands what is going on.
|
||||
|
||||
Be sure to tell the reviewers what changes you are making and to thank them
|
||||
for their time. Code review is a tiring and time-consuming process, and
|
||||
reviewers sometimes get grumpy. Even in that case, though, respond
|
||||
politely and address the problems they have pointed out.
|
||||
|
||||
|
||||
9) Don't get discouraged - or impatient.
|
||||
----------------------------------------
|
||||
|
||||
9) Name your kernel version.
|
||||
After you have submitted your change, be patient and wait. Reviewers are
|
||||
busy people and may not get to your patch right away.
|
||||
|
||||
It is important to note, either in the subject line or in the patch
|
||||
description, the kernel version to which this patch applies.
|
||||
|
||||
If the patch does not apply cleanly to the latest kernel version,
|
||||
Linus will not apply it.
|
||||
Once upon a time, patches used to disappear into the void without comment,
|
||||
but the development process works more smoothly than that now. You should
|
||||
receive comments within a week or so; if that does not happen, make sure
|
||||
that you have sent your patches to the right place. Wait for a minimum of
|
||||
one week before resubmitting or pinging reviewers - possibly longer during
|
||||
busy times like merge windows.
|
||||
|
||||
|
||||
|
||||
10) Don't get discouraged. Re-submit.
|
||||
|
||||
After you have submitted your change, be patient and wait. If Linus
|
||||
likes your change and applies it, it will appear in the next version
|
||||
of the kernel that he releases.
|
||||
|
||||
However, if your change doesn't appear in the next version of the
|
||||
kernel, there could be any number of reasons. It's YOUR job to
|
||||
narrow down those reasons, correct what was wrong, and submit your
|
||||
updated change.
|
||||
|
||||
It is quite common for Linus to "drop" your patch without comment.
|
||||
That's the nature of the system. If he drops your patch, it could be
|
||||
due to
|
||||
* Your patch did not apply cleanly to the latest kernel version.
|
||||
* Your patch was not sufficiently discussed on linux-kernel.
|
||||
* A style issue (see section 2).
|
||||
* An e-mail formatting issue (re-read this section).
|
||||
* A technical problem with your change.
|
||||
* He gets tons of e-mail, and yours got lost in the shuffle.
|
||||
* You are being annoying.
|
||||
|
||||
When in doubt, solicit comments on linux-kernel mailing list.
|
||||
|
||||
|
||||
|
||||
11) Include PATCH in the subject
|
||||
10) Include PATCH in the subject
|
||||
--------------------------------
|
||||
|
||||
Due to high e-mail traffic to Linus, and to linux-kernel, it is common
|
||||
convention to prefix your subject line with [PATCH]. This lets Linus
|
||||
|
|
@ -355,7 +404,8 @@ e-mail discussions.
|
|||
|
||||
|
||||
|
||||
12) Sign your work
|
||||
11) Sign your work
|
||||
------------------
|
||||
|
||||
To improve tracking of who did what, especially with patches that can
|
||||
percolate to their final resting place in the kernel through several
|
||||
|
|
@ -387,11 +437,11 @@ can certify the below:
|
|||
person who certified (a), (b) or (c) and I have not modified
|
||||
it.
|
||||
|
||||
(d) I understand and agree that this project and the contribution
|
||||
are public and that a record of the contribution (including all
|
||||
personal information I submit with it, including my sign-off) is
|
||||
maintained indefinitely and may be redistributed consistent with
|
||||
this project or the open source license(s) involved.
|
||||
(d) I understand and agree that this project and the contribution
|
||||
are public and that a record of the contribution (including all
|
||||
personal information I submit with it, including my sign-off) is
|
||||
maintained indefinitely and may be redistributed consistent with
|
||||
this project or the open source license(s) involved.
|
||||
|
||||
then you just add a line saying
|
||||
|
||||
|
|
@ -401,7 +451,7 @@ using your real name (sorry, no pseudonyms or anonymous contributions.)
|
|||
|
||||
Some people also put extra tags at the end. They'll just be ignored for
|
||||
now, but you can do this to mark internal company procedures or just
|
||||
point out some special detail about the sign-off.
|
||||
point out some special detail about the sign-off.
|
||||
|
||||
If you are a subsystem or branch maintainer, sometimes you need to slightly
|
||||
modify patches you receive in order to merge them, because the code is not
|
||||
|
|
@ -429,15 +479,15 @@ which appears in the changelog.
|
|||
Special note to back-porters: It seems to be a common and useful practice
|
||||
to insert an indication of the origin of a patch at the top of the commit
|
||||
message (just after the subject line) to facilitate tracking. For instance,
|
||||
here's what we see in 2.6-stable :
|
||||
here's what we see in a 3.x-stable release:
|
||||
|
||||
Date: Tue May 13 19:10:30 2008 +0000
|
||||
Date: Tue Oct 7 07:26:38 2014 -0400
|
||||
|
||||
SCSI: libiscsi regression in 2.6.25: fix nop timer handling
|
||||
libata: Un-break ATA blacklist
|
||||
|
||||
commit 4cf1043593db6a337f10e006c23c69e5fc93e722 upstream
|
||||
commit 1c40279960bcd7d52dbdf1d466b20d24b99176c8 upstream.
|
||||
|
||||
And here's what appears in 2.4 :
|
||||
And here's what might appear in an older kernel once a patch is backported:
|
||||
|
||||
Date: Tue May 13 22:12:27 2008 +0200
|
||||
|
||||
|
|
@ -446,18 +496,19 @@ And here's what appears in 2.4 :
|
|||
[backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]
|
||||
|
||||
Whatever the format, this information provides a valuable help to people
|
||||
tracking your trees, and to people trying to trouble-shoot bugs in your
|
||||
tracking your trees, and to people trying to troubleshoot bugs in your
|
||||
tree.
|
||||
|
||||
|
||||
13) When to use Acked-by: and Cc:
|
||||
12) When to use Acked-by: and Cc:
|
||||
---------------------------------
|
||||
|
||||
The Signed-off-by: tag indicates that the signer was involved in the
|
||||
development of the patch, or that he/she was in the patch's delivery path.
|
||||
|
||||
If a person was not directly involved in the preparation or handling of a
|
||||
patch but wishes to signify and record their approval of it then they can
|
||||
arrange to have an Acked-by: line added to the patch's changelog.
|
||||
ask to have an Acked-by: line added to the patch's changelog.
|
||||
|
||||
Acked-by: is often used by the maintainer of the affected code when that
|
||||
maintainer neither contributed to nor forwarded the patch.
|
||||
|
|
@ -465,7 +516,8 @@ maintainer neither contributed to nor forwarded the patch.
|
|||
Acked-by: is not as formal as Signed-off-by:. It is a record that the acker
|
||||
has at least reviewed the patch and has indicated acceptance. Hence patch
|
||||
mergers will sometimes manually convert an acker's "yep, looks good to me"
|
||||
into an Acked-by:.
|
||||
into an Acked-by: (but note that it is usually better to ask for an
|
||||
explicit ack).
|
||||
|
||||
Acked-by: does not necessarily indicate acknowledgement of the entire patch.
|
||||
For example, if a patch affects multiple subsystems and has an Acked-by: from
|
||||
|
|
@ -477,11 +529,13 @@ list archives.
|
|||
If a person has had the opportunity to comment on a patch, but has not
|
||||
provided such comments, you may optionally add a "Cc:" tag to the patch.
|
||||
This is the only tag which might be added without an explicit action by the
|
||||
person it names. This tag documents that potentially interested parties
|
||||
have been included in the discussion
|
||||
person it names - but it should indicate that this person was copied on the
|
||||
patch. This tag documents that potentially interested parties
|
||||
have been included in the discussion.
|
||||
|
||||
|
||||
14) Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes:
|
||||
13) Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes:
|
||||
--------------------------------------------------------------------------
|
||||
|
||||
The Reported-by tag gives credit to people who find bugs and report them and it
|
||||
hopefully inspires them to help us again in the future. Please note that if
|
||||
|
|
@ -541,7 +595,13 @@ which stable kernel versions should receive your fix. This is the preferred
|
|||
method for indicating a bug fixed by the patch. See #2 above for more details.
|
||||
|
||||
|
||||
15) The canonical patch format
|
||||
14) The canonical patch format
|
||||
------------------------------
|
||||
|
||||
This section describes how the patch itself should be formatted. Note
|
||||
that, if you have your patches stored in a git repository, proper patch
|
||||
formatting can be had with "git format-patch". The tools cannot create
|
||||
the necessary text, though, so read the instructions below anyway.
|
||||
|
||||
The canonical patch subject line is:
|
||||
|
||||
|
|
@ -549,7 +609,8 @@ The canonical patch subject line is:
|
|||
|
||||
The canonical patch message body contains the following:
|
||||
|
||||
- A "from" line specifying the patch author.
|
||||
- A "from" line specifying the patch author (only needed if the person
|
||||
sending the patch is not the author).
|
||||
|
||||
- An empty line.
|
||||
|
||||
|
|
@ -656,128 +717,63 @@ See more details on the proper patch format in the following
|
|||
references.
|
||||
|
||||
|
||||
16) Sending "git pull" requests (from Linus emails)
|
||||
15) Sending "git pull" requests
|
||||
-------------------------------
|
||||
|
||||
Please write the git repo address and branch name alone on the same line
|
||||
so that I can't even by mistake pull from the wrong branch, and so
|
||||
that a triple-click just selects the whole thing.
|
||||
If you have a series of patches, it may be most convenient to have the
|
||||
maintainer pull them directly into the subsystem repository with a
|
||||
"git pull" operation. Note, however, that pulling patches from a developer
|
||||
requires a higher degree of trust than taking patches from a mailing list.
|
||||
As a result, many subsystem maintainers are reluctant to take pull
|
||||
requests, especially from new, unknown developers. If in doubt you can use
|
||||
the pull request as the cover letter for a normal posting of the patch
|
||||
series, giving the maintainer the option of using either.
|
||||
|
||||
So the proper format is something along the lines of:
|
||||
A pull request should have [GIT] or [PULL] in the subject line. The
|
||||
request itself should include the repository name and the branch of
|
||||
interest on a single line; it should look something like:
|
||||
|
||||
"Please pull from
|
||||
Please pull from
|
||||
|
||||
git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
|
||||
git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
|
||||
|
||||
to get these changes:"
|
||||
to get these changes:"
|
||||
|
||||
so that I don't have to hunt-and-peck for the address and inevitably
|
||||
get it wrong (actually, I've only gotten it wrong a few times, and
|
||||
checking against the diffstat tells me when I get it wrong, but I'm
|
||||
just a lot more comfortable when I don't have to "look for" the right
|
||||
thing to pull, and double-check that I have the right branch-name).
|
||||
A pull request should also include an overall message saying what will be
|
||||
included in the request, a "git shortlog" listing of the patches
|
||||
themselves, and a diffstat showing the overall effect of the patch series.
|
||||
The easiest way to get all this information together is, of course, to let
|
||||
git do it for you with the "git request-pull" command.
|
||||
|
||||
Some maintainers (including Linus) want to see pull requests from signed
|
||||
commits; that increases their confidence that the request actually came
|
||||
from you. Linus, in particular, will not pull from public hosting sites
|
||||
like GitHub in the absence of a signed tag.
|
||||
|
||||
Please use "git diff -M --stat --summary" to generate the diffstat:
|
||||
the -M enables rename detection, and the summary enables a summary of
|
||||
new/deleted or renamed files.
|
||||
The first step toward creating such tags is to make a GNUPG key and get it
|
||||
signed by one or more core kernel developers. This step can be hard for
|
||||
new developers, but there is no way around it. Attending conferences can
|
||||
be a good way to find developers who can sign your key.
|
||||
|
||||
With rename detection, the statistics are rather different [...]
|
||||
because git will notice that a fair number of the changes are renames.
|
||||
Once you have prepared a patch series in git that you wish to have somebody
|
||||
pull, create a signed tag with "git tag -s". This will create a new tag
|
||||
identifying the last commit in the series and containing a signature
|
||||
created with your private key. You will also have the opportunity to add a
|
||||
changelog-style message to the tag; this is an ideal place to describe the
|
||||
effects of the pull request as a whole.
|
||||
|
||||
-----------------------------------
|
||||
SECTION 2 - HINTS, TIPS, AND TRICKS
|
||||
-----------------------------------
|
||||
If the tree the maintainer will be pulling from is not the repository you
|
||||
are working from, don't forget to push the signed tag explicitly to the
|
||||
public tree.
|
||||
|
||||
This section lists many of the common "rules" associated with code
|
||||
submitted to the kernel. There are always exceptions... but you must
|
||||
have a really good reason for doing so. You could probably call this
|
||||
section Linus Computer Science 101.
|
||||
|
||||
|
||||
|
||||
1) Read Documentation/CodingStyle
|
||||
|
||||
Nuff said. If your code deviates too much from this, it is likely
|
||||
to be rejected without further review, and without comment.
|
||||
|
||||
One significant exception is when moving code from one file to
|
||||
another -- in this case you should not modify the moved code at all in
|
||||
the same patch which moves it. This clearly delineates the act of
|
||||
moving the code and your changes. This greatly aids review of the
|
||||
actual differences and allows tools to better track the history of
|
||||
the code itself.
|
||||
|
||||
Check your patches with the patch style checker prior to submission
|
||||
(scripts/checkpatch.pl). The style checker should be viewed as
|
||||
a guide not as the final word. If your code looks better with
|
||||
a violation then its probably best left alone.
|
||||
|
||||
The checker reports at three levels:
|
||||
- ERROR: things that are very likely to be wrong
|
||||
- WARNING: things requiring careful review
|
||||
- CHECK: things requiring thought
|
||||
|
||||
You should be able to justify all violations that remain in your
|
||||
patch.
|
||||
|
||||
|
||||
|
||||
2) #ifdefs are ugly
|
||||
|
||||
Code cluttered with ifdefs is difficult to read and maintain. Don't do
|
||||
it. Instead, put your ifdefs in a header, and conditionally define
|
||||
'static inline' functions, or macros, which are used in the code.
|
||||
Let the compiler optimize away the "no-op" case.
|
||||
|
||||
Simple example, of poor code:
|
||||
|
||||
dev = alloc_etherdev (sizeof(struct funky_private));
|
||||
if (!dev)
|
||||
return -ENODEV;
|
||||
#ifdef CONFIG_NET_FUNKINESS
|
||||
init_funky_net(dev);
|
||||
#endif
|
||||
|
||||
Cleaned-up example:
|
||||
|
||||
(in header)
|
||||
#ifndef CONFIG_NET_FUNKINESS
|
||||
static inline void init_funky_net (struct net_device *d) {}
|
||||
#endif
|
||||
|
||||
(in the code itself)
|
||||
dev = alloc_etherdev (sizeof(struct funky_private));
|
||||
if (!dev)
|
||||
return -ENODEV;
|
||||
init_funky_net(dev);
|
||||
|
||||
|
||||
|
||||
3) 'static inline' is better than a macro
|
||||
|
||||
Static inline functions are greatly preferred over macros.
|
||||
They provide type safety, have no length limitations, no formatting
|
||||
limitations, and under gcc they are as cheap as macros.
|
||||
|
||||
Macros should only be used for cases where a static inline is clearly
|
||||
suboptimal [there are a few, isolated cases of this in fast paths],
|
||||
or where it is impossible to use a static inline function [such as
|
||||
string-izing].
|
||||
|
||||
'static inline' is preferred over 'static __inline__', 'extern inline',
|
||||
and 'extern __inline__'.
|
||||
|
||||
|
||||
|
||||
4) Don't over-design.
|
||||
|
||||
Don't try to anticipate nebulous future cases which may or may not
|
||||
be useful: "Make it as simple as you can, and no simpler."
|
||||
When generating your pull request, use the signed tag as the target. A
|
||||
command like this will do the trick:
|
||||
|
||||
git request-pull master git://my.public.tree/linux.git my-signed-tag
|
||||
|
||||
|
||||
----------------------
|
||||
SECTION 3 - REFERENCES
|
||||
SECTION 2 - REFERENCES
|
||||
----------------------
|
||||
|
||||
Andrew Morton, "The perfect patch" (tpp).
|
||||
|
|
|
|||
|
|
@ -243,7 +243,7 @@ input driver:
|
|||
.owner = THIS_MODULE,
|
||||
.pm = &mpu3050_pm,
|
||||
.of_match_table = mpu3050_of_match,
|
||||
.acpi_match_table ACPI_PTR(mpu3050_acpi_match),
|
||||
.acpi_match_table = ACPI_PTR(mpu3050_acpi_match),
|
||||
},
|
||||
.probe = mpu3050_probe,
|
||||
.remove = mpu3050_remove,
|
||||
|
|
|
|||
|
|
@ -2,11 +2,15 @@
|
|||
- this file
|
||||
Booting
|
||||
- requirements for booting
|
||||
CCN.txt
|
||||
- Cache Coherent Network ring-bus and perf PMU driver.
|
||||
Interrupts
|
||||
- ARM Interrupt subsystem documentation
|
||||
IXP4xx
|
||||
- Intel IXP4xx Network processor.
|
||||
msm
|
||||
Makefile
|
||||
- Build sourcefiles as part of the Documentation-build for arm
|
||||
msm/
|
||||
- MSM specific documentation
|
||||
Netwinder
|
||||
- Netwinder specific documentation
|
||||
|
|
@ -18,11 +22,9 @@ README
|
|||
- General ARM documentation
|
||||
SA1100/
|
||||
- SA1100 documentation
|
||||
Samsung-S3C24XX
|
||||
Samsung-S3C24XX/
|
||||
- S3C24XX ARM Linux Overview
|
||||
Sharp-LH
|
||||
- Linux on Sharp LH79524 and LH7A40X System On a Chip (SOC)
|
||||
SPEAr
|
||||
SPEAr/
|
||||
- ST SPEAr platform Linux Overview
|
||||
VFP/
|
||||
- Release notes for Linux Kernel Vector Floating Point support code
|
||||
|
|
|
|||
|
|
@ -32,6 +32,9 @@ The default mode depends on the status of the instruction in the
|
|||
architecture. Deprecated instructions should default to emulation
|
||||
while obsolete instructions must be undefined by default.
|
||||
|
||||
Note: Instruction emulation may not be possible in all cases. See
|
||||
individual instruction notes for further information.
|
||||
|
||||
Supported legacy instructions
|
||||
-----------------------------
|
||||
* SWP{B}
|
||||
|
|
@ -43,3 +46,12 @@ Default: Undef (0)
|
|||
Node: /proc/sys/abi/cp15_barrier
|
||||
Status: Deprecated
|
||||
Default: Emulate (1)
|
||||
|
||||
* SETEND
|
||||
Node: /proc/sys/abi/setend
|
||||
Status: Deprecated
|
||||
Default: Emulate (1)*
|
||||
Note: All the cpus on the system must have mixed endian support at EL0
|
||||
for this feature to be enabled. If a new CPU - which doesn't support mixed
|
||||
endian - is hotplugged in after this feature has been enabled, there could
|
||||
be unexpected results in the application.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
ifneq ($(CONFIG_BLACKFIN),)
|
||||
ifneq ($(CONFIG_BFIN_GPTIMERS,)
|
||||
obj-m := gptimers-example.o
|
||||
endif
|
||||
endif
|
||||
|
|
|
|||
|
|
@ -317,10 +317,10 @@ maps this page at its virtual address.
|
|||
about doing this.
|
||||
|
||||
The idea is, first at flush_dcache_page() time, if
|
||||
page->mapping->i_mmap is an empty tree and ->i_mmap_nonlinear
|
||||
an empty list, just mark the architecture private page flag bit.
|
||||
Later, in update_mmu_cache(), a check is made of this flag bit,
|
||||
and if set the flush is done and the flag bit is cleared.
|
||||
page->mapping->i_mmap is an empty tree, just mark the architecture
|
||||
private page flag bit. Later, in update_mmu_cache(), a check is
|
||||
made of this flag bit, and if set the flush is done and the flag
|
||||
bit is cleared.
|
||||
|
||||
IMPORTANT NOTE: It is often important, if you defer the flush,
|
||||
that the actual flush occurs on the same CPU
|
||||
|
|
|
|||
|
|
@ -24,3 +24,5 @@ net_prio.txt
|
|||
- Network priority cgroups details and usages.
|
||||
resource_counter.txt
|
||||
- Resource Counter API.
|
||||
unified-hierarchy.txt
|
||||
- Description the new/next cgroup interface.
|
||||
|
|
|
|||
|
|
@ -327,6 +327,85 @@ supported and the interface files "release_agent" and
|
|||
- use_hierarchy is on by default and the cgroup file for the flag is
|
||||
not created.
|
||||
|
||||
- The original lower boundary, the soft limit, is defined as a limit
|
||||
that is per default unset. As a result, the set of cgroups that
|
||||
global reclaim prefers is opt-in, rather than opt-out. The costs
|
||||
for optimizing these mostly negative lookups are so high that the
|
||||
implementation, despite its enormous size, does not even provide the
|
||||
basic desirable behavior. First off, the soft limit has no
|
||||
hierarchical meaning. All configured groups are organized in a
|
||||
global rbtree and treated like equal peers, regardless where they
|
||||
are located in the hierarchy. This makes subtree delegation
|
||||
impossible. Second, the soft limit reclaim pass is so aggressive
|
||||
that it not just introduces high allocation latencies into the
|
||||
system, but also impacts system performance due to overreclaim, to
|
||||
the point where the feature becomes self-defeating.
|
||||
|
||||
The memory.low boundary on the other hand is a top-down allocated
|
||||
reserve. A cgroup enjoys reclaim protection when it and all its
|
||||
ancestors are below their low boundaries, which makes delegation of
|
||||
subtrees possible. Secondly, new cgroups have no reserve per
|
||||
default and in the common case most cgroups are eligible for the
|
||||
preferred reclaim pass. This allows the new low boundary to be
|
||||
efficiently implemented with just a minor addition to the generic
|
||||
reclaim code, without the need for out-of-band data structures and
|
||||
reclaim passes. Because the generic reclaim code considers all
|
||||
cgroups except for the ones running low in the preferred first
|
||||
reclaim pass, overreclaim of individual groups is eliminated as
|
||||
well, resulting in much better overall workload performance.
|
||||
|
||||
- The original high boundary, the hard limit, is defined as a strict
|
||||
limit that can not budge, even if the OOM killer has to be called.
|
||||
But this generally goes against the goal of making the most out of
|
||||
the available memory. The memory consumption of workloads varies
|
||||
during runtime, and that requires users to overcommit. But doing
|
||||
that with a strict upper limit requires either a fairly accurate
|
||||
prediction of the working set size or adding slack to the limit.
|
||||
Since working set size estimation is hard and error prone, and
|
||||
getting it wrong results in OOM kills, most users tend to err on the
|
||||
side of a looser limit and end up wasting precious resources.
|
||||
|
||||
The memory.high boundary on the other hand can be set much more
|
||||
conservatively. When hit, it throttles allocations by forcing them
|
||||
into direct reclaim to work off the excess, but it never invokes the
|
||||
OOM killer. As a result, a high boundary that is chosen too
|
||||
aggressively will not terminate the processes, but instead it will
|
||||
lead to gradual performance degradation. The user can monitor this
|
||||
and make corrections until the minimal memory footprint that still
|
||||
gives acceptable performance is found.
|
||||
|
||||
In extreme cases, with many concurrent allocations and a complete
|
||||
breakdown of reclaim progress within the group, the high boundary
|
||||
can be exceeded. But even then it's mostly better to satisfy the
|
||||
allocation from the slack available in other groups or the rest of
|
||||
the system than killing the group. Otherwise, memory.max is there
|
||||
to limit this type of spillover and ultimately contain buggy or even
|
||||
malicious applications.
|
||||
|
||||
- The original control file names are unwieldy and inconsistent in
|
||||
many different ways. For example, the upper boundary hit count is
|
||||
exported in the memory.failcnt file, but an OOM event count has to
|
||||
be manually counted by listening to memory.oom_control events, and
|
||||
lower boundary / soft limit events have to be counted by first
|
||||
setting a threshold for that value and then counting those events.
|
||||
Also, usage and limit files encode their units in the filename.
|
||||
That makes the filenames very long, even though this is not
|
||||
information that a user needs to be reminded of every time they type
|
||||
out those names.
|
||||
|
||||
To address these naming issues, as well as to signal clearly that
|
||||
the new interface carries a new configuration model, the naming
|
||||
conventions in it necessarily differ from the old interface.
|
||||
|
||||
- The original limit files indicate the state of an unset limit with a
|
||||
Very High Number, and a configured limit can be unset by echoing -1
|
||||
into those files. But that very high number is implementation and
|
||||
architecture dependent and not very descriptive. And while -1 can
|
||||
be understood as an underflow into the highest possible value, -2 or
|
||||
-10M etc. do not work, so it's not consistent.
|
||||
|
||||
memory.low, memory.high, and memory.max will use the string
|
||||
"infinity" to indicate and set the highest possible value.
|
||||
|
||||
5. Planned Changes
|
||||
|
||||
|
|
|
|||
|
|
@ -37,6 +37,14 @@ controlling P state selection. These files have been added to
|
|||
no_turbo: limits the driver to selecting P states below the turbo
|
||||
frequency range.
|
||||
|
||||
turbo_pct: displays the percentage of the total performance that
|
||||
is supported by hardware that is in the turbo range. This number
|
||||
is independent of whether turbo has been disabled or not.
|
||||
|
||||
num_pstates: displays the number of pstates that are supported
|
||||
by hardware. This number is independent of whether turbo has
|
||||
been disabled or not.
|
||||
|
||||
For contemporary Intel processors, the frequency is controlled by the
|
||||
processor itself and the P-states exposed to software are related to
|
||||
performance levels. The idea that frequency can be set to a single
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ Required nodes:
|
|||
range of 0x200 bytes.
|
||||
|
||||
- syscon: the root node of the Integrator platforms must have a
|
||||
system controller node pointong to the control registers,
|
||||
system controller node pointing to the control registers,
|
||||
with the compatible string
|
||||
"arm,integrator-ap-syscon"
|
||||
"arm,integrator-cp-syscon"
|
||||
|
|
|
|||
|
|
@ -79,7 +79,9 @@ reboot
|
|||
Required properties
|
||||
|
||||
- compatible
|
||||
The string property "brcm,brcmstb-reboot".
|
||||
The string property "brcm,brcmstb-reboot" for 40nm/28nm chips with
|
||||
the new SYS_CTRL interface, or "brcm,bcm7038-reboot" for 65nm
|
||||
chips with the old SUN_TOP_CTRL interface.
|
||||
|
||||
- syscon
|
||||
A phandle / integer array that points to the syscon node which describes
|
||||
|
|
|
|||
|
|
@ -175,6 +175,7 @@ nodes to be present and contain the properties described below.
|
|||
"marvell,pj4a"
|
||||
"marvell,pj4b"
|
||||
"marvell,sheeva-v5"
|
||||
"nvidia,tegra132-denver"
|
||||
"qcom,krait"
|
||||
"qcom,scorpion"
|
||||
- enable-method
|
||||
|
|
|
|||
|
|
@ -0,0 +1,72 @@
|
|||
* QEMU Firmware Configuration bindings for ARM
|
||||
|
||||
QEMU's arm-softmmu and aarch64-softmmu emulation / virtualization targets
|
||||
provide the following Firmware Configuration interface on the "virt" machine
|
||||
type:
|
||||
|
||||
- A write-only, 16-bit wide selector (or control) register,
|
||||
- a read-write, 64-bit wide data register.
|
||||
|
||||
QEMU exposes the control and data register to ARM guests as memory mapped
|
||||
registers; their location is communicated to the guest's UEFI firmware in the
|
||||
DTB that QEMU places at the bottom of the guest's DRAM.
|
||||
|
||||
The guest writes a selector value (a key) to the selector register, and then
|
||||
can read the corresponding data (produced by QEMU) via the data register. If
|
||||
the selected entry is writable, the guest can rewrite it through the data
|
||||
register.
|
||||
|
||||
The selector register takes keys in big endian byte order.
|
||||
|
||||
The data register allows accesses with 8, 16, 32 and 64-bit width (only at
|
||||
offset 0 of the register). Accesses larger than a byte are interpreted as
|
||||
arrays, bundled together only for better performance. The bytes constituting
|
||||
such a word, in increasing address order, correspond to the bytes that would
|
||||
have been transferred by byte-wide accesses in chronological order.
|
||||
|
||||
The interface allows guest firmware to download various parameters and blobs
|
||||
that affect how the firmware works and what tables it installs for the guest
|
||||
OS. For example, boot order of devices, ACPI tables, SMBIOS tables, kernel and
|
||||
initrd images for direct kernel booting, virtual machine UUID, SMP information,
|
||||
virtual NUMA topology, and so on.
|
||||
|
||||
The authoritative registry of the valid selector values and their meanings is
|
||||
the QEMU source code; the structure of the data blobs corresponding to the
|
||||
individual key values is also defined in the QEMU source code.
|
||||
|
||||
The presence of the registers can be verified by selecting the "signature" blob
|
||||
with key 0x0000, and reading four bytes from the data register. The returned
|
||||
signature is "QEMU".
|
||||
|
||||
The outermost protocol (involving the write / read sequences of the control and
|
||||
data registers) is expected to be versioned, and/or described by feature bits.
|
||||
The interface revision / feature bitmap can be retrieved with key 0x0001. The
|
||||
blob to be read from the data register has size 4, and it is to be interpreted
|
||||
as a uint32_t value in little endian byte order. The current value
|
||||
(corresponding to the above outer protocol) is zero.
|
||||
|
||||
The guest kernel is not expected to use these registers (although it is
|
||||
certainly allowed to); the device tree bindings are documented here because
|
||||
this is where device tree bindings reside in general.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: "qemu,fw-cfg-mmio".
|
||||
|
||||
- reg: the MMIO region used by the device.
|
||||
* Bytes 0x0 to 0x7 cover the data register.
|
||||
* Bytes 0x8 to 0x9 cover the selector register.
|
||||
* Further registers may be appended to the region in case of future interface
|
||||
revisions / feature bits.
|
||||
|
||||
Example:
|
||||
|
||||
/ {
|
||||
#size-cells = <0x2>;
|
||||
#address-cells = <0x2>;
|
||||
|
||||
fw-cfg@9020000 {
|
||||
compatible = "qemu,fw-cfg-mmio";
|
||||
reg = <0x0 0x9020000 0x0 0xa>;
|
||||
};
|
||||
};
|
||||
|
|
@ -57,6 +57,16 @@ Optional properties:
|
|||
- cache-id-part: cache id part number to be used if it is not present
|
||||
on hardware
|
||||
- wt-override: If present then L2 is forced to Write through mode
|
||||
- arm,double-linefill : Override double linefill enable setting. Enable if
|
||||
non-zero, disable if zero.
|
||||
- arm,double-linefill-incr : Override double linefill on INCR read. Enable
|
||||
if non-zero, disable if zero.
|
||||
- arm,double-linefill-wrap : Override double linefill on WRAP read. Enable
|
||||
if non-zero, disable if zero.
|
||||
- arm,prefetch-drop : Override prefetch drop enable setting. Enable if non-zero,
|
||||
disable if zero.
|
||||
- arm,prefetch-offset : Override prefetch offset value. Valid values are
|
||||
0-7, 15, 23, and 31.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Properties:
|
|||
"qcom,kpss-timer" - krait subsystem
|
||||
"qcom,scss-timer" - scorpion subsystem
|
||||
|
||||
- interrupts : Interrupts for the the debug timer, the first general purpose
|
||||
- interrupts : Interrupts for the debug timer, the first general purpose
|
||||
timer, and optionally a second general purpose timer in that
|
||||
order.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,10 @@
|
|||
NVIDIA Tegra AHB
|
||||
|
||||
Required properties:
|
||||
- compatible : "nvidia,tegra20-ahb" or "nvidia,tegra30-ahb"
|
||||
- compatible : For Tegra20, must contain "nvidia,tegra20-ahb". For
|
||||
Tegra30, must contain "nvidia,tegra30-ahb". Otherwise, must contain
|
||||
'"nvidia,<chip>-ahb", "nvidia,tegra30-ahb"' where <chip> is tegra124,
|
||||
tegra132, or tegra210.
|
||||
- reg : Should contain 1 register ranges(address and length)
|
||||
|
||||
Example:
|
||||
|
|
|
|||
|
|
@ -6,7 +6,11 @@ modes. It provides power-gating controllers for SoC and CPU power-islands.
|
|||
|
||||
Required properties:
|
||||
- name : Should be pmc
|
||||
- compatible : Should contain "nvidia,tegra<chip>-pmc".
|
||||
- compatible : For Tegra20, must contain "nvidia,tegra20-pmc". For Tegra30,
|
||||
must contain "nvidia,tegra30-pmc". For Tegra114, must contain
|
||||
"nvidia,tegra114-pmc". For Tegra124, must contain "nvidia,tegra124-pmc".
|
||||
Otherwise, must contain "nvidia,<chip>-pmc", plus at least one of the
|
||||
above, where <chip> is tegra132.
|
||||
- reg : Offset and length of the register set for the device
|
||||
- clocks : Must contain an entry for each entry in clock-names.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
|
|
|
|||
|
|
@ -37,9 +37,10 @@ Required properties when using sub-nodes:
|
|||
|
||||
|
||||
Sub-nodes required properties:
|
||||
- reg : the port number
|
||||
- phys : reference to the SATA PHY node
|
||||
|
||||
- reg : the port number
|
||||
And at least one of the following properties:
|
||||
- phys : reference to the SATA PHY node
|
||||
- target-supply : regulator for SATA target power
|
||||
|
||||
Examples:
|
||||
sata@ffe08000 {
|
||||
|
|
@ -68,10 +69,12 @@ With sub-nodes:
|
|||
sata0: sata-port@0 {
|
||||
reg = <0>;
|
||||
phys = <&sata_phy 0>;
|
||||
target-supply = <®_sata0>;
|
||||
};
|
||||
|
||||
sata1: sata-port@1 {
|
||||
reg = <1>;
|
||||
phys = <&sata_phy 1>;
|
||||
target-supply = <®_sata1>;;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ Properties:
|
|||
|
||||
Compatibility with many Cavium evaluation boards.
|
||||
|
||||
- reg: The base address of the the CF chip select banks. Depending on
|
||||
- reg: The base address of the CF chip select banks. Depending on
|
||||
the device configuration, there may be one or two banks.
|
||||
|
||||
- cavium,bus-width: The width of the connection to the CF devices. Valid
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
Tegra124 SoC SATA AHCI controller
|
||||
|
||||
Required properties :
|
||||
- compatible : "nvidia,tegra124-ahci".
|
||||
- compatible : For Tegra124, must contain "nvidia,tegra124-ahci". Otherwise,
|
||||
must contain '"nvidia,<chip>-ahci", "nvidia,tegra124-ahci"', where <chip>
|
||||
is tegra132.
|
||||
- reg : Should contain 2 entries:
|
||||
- AHCI register set (SATA BAR5)
|
||||
- SATA register set
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ configuration register for writes. These configuration register may be used to
|
|||
enable (and disable in some cases) SoC pin drivers, select peripheral clock
|
||||
sources (internal or pin), etc. In some cases, a configuration register is
|
||||
write once or the individual bits are write once. In addition to device config,
|
||||
the DSCR block may provide registers which which are used to reset peripherals,
|
||||
the DSCR block may provide registers which are used to reset peripherals,
|
||||
provide device ID information, provide ethernet MAC addresses, as well as other
|
||||
miscellaneous functions.
|
||||
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
* Renesas R-Car DMA Controller Device Tree bindings
|
||||
|
||||
Renesas R-Car Generation 2 SoCs have have multiple multi-channel DMA
|
||||
Renesas R-Car Generation 2 SoCs have multiple multi-channel DMA
|
||||
controller instances named DMAC capable of serving multiple clients. Channels
|
||||
can be dedicated to specific clients or shared between a large number of
|
||||
clients.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
Altera SOCFPGA FPGA Manager
|
||||
|
||||
Required properties:
|
||||
- compatible : should contain "altr,socfpga-fpga-mgr"
|
||||
- reg : base address and size for memory mapped io.
|
||||
- The first index is for FPGA manager register access.
|
||||
- The second index is for writing FPGA configuration data.
|
||||
- interrupts : interrupt for the FPGA Manager device.
|
||||
|
||||
Example:
|
||||
|
||||
hps_0_fpgamgr: fpgamgr@0xff706000 {
|
||||
compatible = "altr,socfpga-fpga-mgr";
|
||||
reg = <0xFF706000 0x1000
|
||||
0xFFB90000 0x1000>;
|
||||
interrupts = <0 175 4>;
|
||||
};
|
||||
|
|
@ -1,11 +1,11 @@
|
|||
NVIDIA Tegra20/Tegra30/Tegr114/Tegra124 fuse block.
|
||||
|
||||
Required properties:
|
||||
- compatible : should be:
|
||||
"nvidia,tegra20-efuse"
|
||||
"nvidia,tegra30-efuse"
|
||||
"nvidia,tegra114-efuse"
|
||||
"nvidia,tegra124-efuse"
|
||||
- compatible : For Tegra20, must contain "nvidia,tegra20-efuse". For Tegra30,
|
||||
must contain "nvidia,tegra30-efuse". For Tegra114, must contain
|
||||
"nvidia,tegra114-efuse". For Tegra124, must contain "nvidia,tegra124-efuse".
|
||||
Otherwise, must contain "nvidia,<chip>-efuse", plus one of the above, where
|
||||
<chip> is tegra132.
|
||||
Details:
|
||||
nvidia,tegra20-efuse: Tegra20 requires using APB DMA to read the fuse data
|
||||
due to a hardware bug. Tegra20 also lacks certain information which is
|
||||
|
|
|
|||
|
|
@ -0,0 +1,20 @@
|
|||
Fujitsu MB86S7x GPIO Controller
|
||||
-------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fujitsu,mb86s70-gpio"
|
||||
- reg: Base address and length of register space
|
||||
- clocks: Specify the clock
|
||||
- gpio-controller: Marks the device node as a gpio controller.
|
||||
- #gpio-cells: Should be <2>. The first cell is the pin number and the
|
||||
second cell is used to specify optional parameters:
|
||||
- bit 0 specifies polarity (0 for normal, 1 for inverted).
|
||||
|
||||
Examples:
|
||||
gpio0: gpio@31000000 {
|
||||
compatible = "fujitsu,mb86s70-gpio";
|
||||
reg = <0 0x31000000 0x10000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
clocks = <&clk 0 2 1>;
|
||||
};
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
* MAX732x-compatible I/O expanders
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be one of the following:
|
||||
- "maxim,max7319": For the Maxim MAX7319
|
||||
- "maxim,max7320": For the Maxim MAX7320
|
||||
- "maxim,max7321": For the Maxim MAX7321
|
||||
- "maxim,max7322": For the Maxim MAX7322
|
||||
- "maxim,max7323": For the Maxim MAX7323
|
||||
- "maxim,max7324": For the Maxim MAX7324
|
||||
- "maxim,max7325": For the Maxim MAX7325
|
||||
- "maxim,max7326": For the Maxim MAX7326
|
||||
- "maxim,max7327": For the Maxim MAX7327
|
||||
- reg: I2C slave address for this device.
|
||||
- gpio-controller: Marks the device node as a GPIO controller.
|
||||
- #gpio-cells: Should be 2.
|
||||
- first cell is the GPIO number
|
||||
- second cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>.
|
||||
Only the GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
|
||||
|
||||
Optional properties:
|
||||
|
||||
The I/O expander can detect input state changes, and thus optionally act as
|
||||
an interrupt controller. When the expander interrupt line is connected all the
|
||||
following properties must be set. For more information please see the
|
||||
interrupt controller device tree bindings documentation available at
|
||||
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
|
||||
|
||||
- interrupt-controller: Identifies the node as an interrupt controller.
|
||||
- #interrupt-cells: Number of cells to encode an interrupt source, shall be 2.
|
||||
- first cell is the pin number
|
||||
- second cell is used to specify flags
|
||||
- interrupt-parent: phandle of the parent interrupt controller.
|
||||
- interrupts: Interrupt specifier for the controllers interrupt.
|
||||
|
||||
Please refer to gpio.txt in this directory for details of the common GPIO
|
||||
bindings used by client devices.
|
||||
|
||||
Example 1. MAX7325 with interrupt support enabled (CONFIG_GPIO_MAX732X_IRQ=y):
|
||||
|
||||
expander: max7325@6d {
|
||||
compatible = "maxim,max7325";
|
||||
reg = <0x6d>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-parent = <&gpio4>;
|
||||
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
|
||||
};
|
||||
|
||||
Example 2. MAX7325 with interrupt support disabled (CONFIG_GPIO_MAX732X_IRQ=n):
|
||||
|
||||
expander: max7325@6d {
|
||||
compatible = "maxim,max7325";
|
||||
reg = <0x6d>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
};
|
||||
|
|
@ -39,7 +39,7 @@ Optional Properties:
|
|||
- lines-initial-states: Bitmask that specifies the initial state of each
|
||||
line. When a bit is set to zero, the corresponding line will be initialized to
|
||||
the input (pulled-up) state. When the bit is set to one, the line will be
|
||||
initialized the the low-level output state. If the property is not specified
|
||||
initialized the low-level output state. If the property is not specified
|
||||
all lines will be initialized to the input state.
|
||||
|
||||
The I/O expander can detect input state changes, and thus optionally act as
|
||||
|
|
|
|||
|
|
@ -0,0 +1,40 @@
|
|||
SEMTECH SX150x GPIO expander bindings
|
||||
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: should be "semtech,sx1506q",
|
||||
"semtech,sx1508q",
|
||||
"semtech,sx1509q".
|
||||
|
||||
- reg: The I2C slave address for this device.
|
||||
|
||||
- interrupt-parent: phandle of the parent interrupt controller.
|
||||
|
||||
- interrupts: Interrupt specifier for the controllers interrupt.
|
||||
|
||||
- #gpio-cells: Should be 2. The first cell is the GPIO number and the
|
||||
second cell is used to specify optional parameters:
|
||||
bit 0: polarity (0: normal, 1: inverted)
|
||||
|
||||
- gpio-controller: Marks the device as a GPIO controller.
|
||||
|
||||
- interrupt-controller: Marks the device as a interrupt controller.
|
||||
|
||||
The GPIO expander can optionally be used as an interrupt controller, in
|
||||
which case it uses the default two cell specifier as described in
|
||||
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
|
||||
|
||||
Example:
|
||||
|
||||
i2c_gpio_expander@20{
|
||||
#gpio-cells = <2>;
|
||||
#interrupt-cells = <2>;
|
||||
compatible = "semtech,sx1506q";
|
||||
reg = <0x20>;
|
||||
interrupt-parent = <&gpio_1>;
|
||||
interrupts = <16 0>;
|
||||
|
||||
gpio-controller;
|
||||
interrupt-controller;
|
||||
};
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
APM X-Gene Standby GPIO controller bindings
|
||||
|
||||
This is a gpio controller in the standby domain.
|
||||
|
||||
There are 20 GPIO pins from 0..21. There is no GPIO_DS14 or GPIO_DS15,
|
||||
only GPIO_DS8..GPIO_DS13 support interrupts. The IRQ mapping
|
||||
is currently 1-to-1 on interrupts 0x28 thru 0x2d.
|
||||
|
||||
Required properties:
|
||||
- compatible: "apm,xgene-gpio-sb" for the X-Gene Standby GPIO controller
|
||||
- reg: Physical base address and size of the controller's registers
|
||||
- #gpio-cells: Should be two.
|
||||
- first cell is the pin number
|
||||
- second cell is used to specify the gpio polarity:
|
||||
0 = active high
|
||||
1 = active low
|
||||
- gpio-controller: Marks the device node as a GPIO controller.
|
||||
- interrupts: Shall contain exactly 6 interrupts.
|
||||
|
||||
Example:
|
||||
sbgpio: sbgpio@17001000 {
|
||||
compatible = "apm,xgene-gpio-sb";
|
||||
reg = <0x0 0x17001000 0x0 0x400>;
|
||||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
interrupts = <0x0 0x28 0x1>,
|
||||
<0x0 0x29 0x1>,
|
||||
<0x0 0x2a 0x1>,
|
||||
<0x0 0x2b 0x1>,
|
||||
<0x0 0x2c 0x1>,
|
||||
<0x0 0x2d 0x1>;
|
||||
};
|
||||
|
|
@ -69,7 +69,8 @@ GPIO pin number, and GPIO flags as accepted by the "qe_pio_e" gpio-controller.
|
|||
----------------------------------
|
||||
|
||||
A gpio-specifier should contain a flag indicating the GPIO polarity; active-
|
||||
high or active-low. If it does, the follow best practices should be followed:
|
||||
high or active-low. If it does, the following best practices should be
|
||||
followed:
|
||||
|
||||
The gpio-specifier's polarity flag should represent the physical level at the
|
||||
GPIO controller that achieves (or represents, for inputs) a logically asserted
|
||||
|
|
@ -147,7 +148,7 @@ contains information structures as follows:
|
|||
numeric-gpio-range ::=
|
||||
<pinctrl-phandle> <gpio-base> <pinctrl-base> <count>
|
||||
named-gpio-range ::= <pinctrl-phandle> <gpio-base> '<0 0>'
|
||||
gpio-phandle : phandle to pin controller node.
|
||||
pinctrl-phandle : phandle to pin controller node
|
||||
gpio-base : Base GPIO ID in the GPIO controller
|
||||
pinctrl-base : Base pinctrl pin ID in the pin controller
|
||||
count : The number of GPIOs/pins in this range
|
||||
|
|
|
|||
|
|
@ -3,8 +3,8 @@
|
|||
Required properties:
|
||||
- compatible : Should be "intel,pxa25x-gpio", "intel,pxa26x-gpio",
|
||||
"intel,pxa27x-gpio", "intel,pxa3xx-gpio",
|
||||
"marvell,pxa93x-gpio", "marvell,mmp-gpio" or
|
||||
"marvell,mmp2-gpio".
|
||||
"marvell,pxa93x-gpio", "marvell,mmp-gpio",
|
||||
"marvell,mmp2-gpio" or marvell,pxa1928-gpio.
|
||||
- reg : Address and length of the register set for the device
|
||||
- interrupts : Should be the port interrupt shared by all gpio pins.
|
||||
There're three gpio interrupts in arch-pxa, and they're gpio0,
|
||||
|
|
|
|||
|
|
@ -197,7 +197,9 @@ of the following host1x client modules:
|
|||
- sor: serial output resource
|
||||
|
||||
Required properties:
|
||||
- compatible: "nvidia,tegra124-sor"
|
||||
- compatible: For Tegra124, must contain "nvidia,tegra124-sor". Otherwise,
|
||||
must contain '"nvidia,<chip>-sor", "nvidia,tegra124-sor"', where <chip>
|
||||
is tegra132.
|
||||
- reg: Physical base address and length of the controller's registers.
|
||||
- interrupts: The interrupt outputs from the controller.
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
|
|
@ -222,7 +224,9 @@ of the following host1x client modules:
|
|||
- nvidia,dpaux: phandle to a DispayPort AUX interface
|
||||
|
||||
- dpaux: DisplayPort AUX interface
|
||||
- compatible: "nvidia,tegra124-dpaux"
|
||||
- compatible: For Tegra124, must contain "nvidia,tegra124-dpaux". Otherwise,
|
||||
must contain '"nvidia,<chip>-dpaux", "nvidia,tegra124-dpaux"', where
|
||||
<chip> is tegra132.
|
||||
- reg: Physical base address and length of the controller's registers.
|
||||
- interrupts: The interrupt outputs from the controller.
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ type of the connections, they just map their existence. Specific properties
|
|||
may be described by specialized bindings depending on the type of connection.
|
||||
|
||||
To see how this binding applies to video pipelines, for example, see
|
||||
Documentation/device-tree/bindings/media/video-interfaces.txt.
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt.
|
||||
Here the ports describe data interfaces, and the links between them are
|
||||
the connecting data buses. A single port with multiple connections can
|
||||
correspond to multiple devices being connected to the same physical bus.
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ i2c0: i2c@fed40000 {
|
|||
compatible = "st,comms-ssc4-i2c";
|
||||
reg = <0xfed40000 0x110>;
|
||||
interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&CLK_S_ICN_REG_0>;
|
||||
clocks = <&clk_s_a0_ls CLK_ICN_REG>;
|
||||
clock-names = "ssc";
|
||||
clock-frequency = <400000>;
|
||||
pinctrl-names = "default";
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
NVIDIA Tegra20/Tegra30/Tegra114 I2C controller driver.
|
||||
|
||||
Required properties:
|
||||
- compatible : should be:
|
||||
"nvidia,tegra114-i2c"
|
||||
"nvidia,tegra30-i2c"
|
||||
"nvidia,tegra20-i2c"
|
||||
"nvidia,tegra20-i2c-dvc"
|
||||
- compatible : For Tegra20, must be one of "nvidia,tegra20-i2c-dvc" or
|
||||
"nvidia,tegra20-i2c". For Tegra30, must be "nvidia,tegra30-i2c".
|
||||
For Tegra114, must be "nvidia,tegra114-i2c". Otherwise, must be
|
||||
"nvidia,<chip>-i2c", plus at least one of the above, where <chip> is
|
||||
tegra124, tegra132, or tegra210.
|
||||
Details of compatible are as follows:
|
||||
nvidia,tegra20-i2c-dvc: Tegra20 has specific I2C controller called as DVC I2C
|
||||
controller. This only support master mode of I2C communication. Register
|
||||
|
|
|
|||
|
|
@ -47,6 +47,7 @@ dallas,ds3232 Extremely Accurate I²C RTC with Integrated Crystal and SRAM
|
|||
dallas,ds4510 CPU Supervisor with Nonvolatile Memory and Programmable I/O
|
||||
dallas,ds75 Digital Thermometer and Thermostat
|
||||
dlg,da9053 DA9053: flexible system level PMIC with multicore support
|
||||
dlg,da9063 DA9063: system PMIC for quad-core application processors
|
||||
epson,rx8025 High-Stability. I2C-Bus INTERFACE REAL TIME CLOCK MODULE
|
||||
epson,rx8581 I2C-BUS INTERFACE REAL TIME CLOCK MODULE
|
||||
fsl,mag3110 MAG3110: Xtrinsic High Accuracy, 3D Magnetometer
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ Optional properties:
|
|||
Each child node represents one channel and has the following
|
||||
properties:
|
||||
Required properties:
|
||||
* reg: Pair of pins the the channel is connected to.
|
||||
* reg: Pair of pins the channel is connected to.
|
||||
0: VP/VN
|
||||
1: VAUXP[0]/VAUXN[0]
|
||||
2: VAUXP[1]/VAUXN[1]
|
||||
|
|
|
|||
|
|
@ -0,0 +1,25 @@
|
|||
National Instruments Ettus Research USRP E3x0 button driver
|
||||
|
||||
This module is part of the NI Ettus Research USRP E3x0 SDR.
|
||||
|
||||
This module provides a simple power button event via two interrupts.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be one of the following
|
||||
- "ettus,e3x0-button": For devices such as the NI Ettus Research USRP E3x0
|
||||
- interrupt-parent:
|
||||
- a phandle to the interrupt controller that it is attached to.
|
||||
- interrupts: should be one of the following
|
||||
- <0 30 1>, <0 31 1>: For devices such as the NI Ettus Research USRP E3x0
|
||||
- interrupt-names: should be one of the following
|
||||
- "press", "release": For devices such as the NI Ettus Research USRP E3x0
|
||||
|
||||
Note: Interrupt numbers might vary depending on the FPGA configuration.
|
||||
|
||||
Example:
|
||||
button {
|
||||
compatible = "ettus,e3x0-button";
|
||||
interrupt-parent = <&intc>;
|
||||
interrupts = <0 30 1>, <0 31 1>;
|
||||
interrupt-names = "press", "release";
|
||||
}
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
* Regulator Haptic Device Tree Bindings
|
||||
|
||||
Required Properties:
|
||||
- compatible : Should be "regulator-haptic"
|
||||
- haptic-supply : Power supply to the haptic motor.
|
||||
[*] refer Documentation/devicetree/bindings/regulator/regulator.txt
|
||||
|
||||
- max-microvolt : The maximum voltage value supplied to the haptic motor.
|
||||
[The unit of the voltage is a micro]
|
||||
|
||||
- min-microvolt : The minimum voltage value supplied to the haptic motor.
|
||||
[The unit of the voltage is a micro]
|
||||
|
||||
Example:
|
||||
|
||||
haptics {
|
||||
compatible = "regulator-haptic";
|
||||
haptic-supply = <&motor_regulator>;
|
||||
max-microvolt = <2700000>;
|
||||
min-microvolt = <1100000>;
|
||||
};
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
Allwinner sun4i low res adc attached tablet keys
|
||||
------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible: "allwinner,sun4i-a10-lradc-keys"
|
||||
- reg: mmio address range of the chip
|
||||
- interrupts: interrupt to which the chip is connected
|
||||
- vref-supply: powersupply for the lradc reference voltage
|
||||
|
||||
Each key is represented as a sub-node of "allwinner,sun4i-a10-lradc-keys":
|
||||
|
||||
Required subnode-properties:
|
||||
- label: Descriptive name of the key.
|
||||
- linux,code: Keycode to emit.
|
||||
- channel: Channel this key is attached to, mut be 0 or 1.
|
||||
- voltage: Voltage in µV at lradc input when this key is pressed.
|
||||
|
||||
Example:
|
||||
|
||||
#include <dt-bindings/input/input.h>
|
||||
|
||||
lradc: lradc@01c22800 {
|
||||
compatible = "allwinner,sun4i-a10-lradc-keys";
|
||||
reg = <0x01c22800 0x100>;
|
||||
interrupts = <31>;
|
||||
vref-supply = <®_vcc3v0>;
|
||||
|
||||
button@191 {
|
||||
label = "Volume Up";
|
||||
linux,code = <KEY_VOLUMEUP>;
|
||||
channel = <0>;
|
||||
voltage = <191274>;
|
||||
};
|
||||
|
||||
button@392 {
|
||||
label = "Volume Down";
|
||||
linux,code = <KEY_VOLUMEDOWN>;
|
||||
channel = <0>;
|
||||
voltage = <392644>;
|
||||
};
|
||||
|
||||
button@601 {
|
||||
label = "Menu";
|
||||
linux,code = <KEY_MENU>;
|
||||
channel = <0>;
|
||||
voltage = <601151>;
|
||||
};
|
||||
|
||||
button@795 {
|
||||
label = "Enter";
|
||||
linux,code = <KEY_ENTER>;
|
||||
channel = <0>;
|
||||
voltage = <795090>;
|
||||
};
|
||||
|
||||
button@987 {
|
||||
label = "Home";
|
||||
linux,code = <KEY_HOMEPAGE>;
|
||||
channel = <0>;
|
||||
voltage = <987387>;
|
||||
};
|
||||
};
|
||||
|
|
@ -2,9 +2,10 @@ sun4i resistive touchscreen controller
|
|||
--------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible: "allwinner,sun4i-a10-ts"
|
||||
- compatible: "allwinner,sun4i-a10-ts" or "allwinner,sun6i-a31-ts"
|
||||
- reg: mmio address range of the chip
|
||||
- interrupts: interrupt to which the chip is connected
|
||||
- #thermal-sensor-cells: shall be 0
|
||||
|
||||
Optional properties:
|
||||
- allwinner,ts-attached: boolean indicating that an actual touchscreen is
|
||||
|
|
@ -17,4 +18,5 @@ Example:
|
|||
reg = <0x01c25000 0x100>;
|
||||
interrupts = <29>;
|
||||
allwinner,ts-attached;
|
||||
#thermal-sensor-cells = <0>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -28,6 +28,20 @@ Required properties:
|
|||
ti,adc-channels: List of analog inputs available for ADC.
|
||||
AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
|
||||
|
||||
Optional properties:
|
||||
- child "tsc"
|
||||
ti,charge-delay: Length of touch screen charge delay step in terms of
|
||||
ADC clock cycles. Charge delay value should be large
|
||||
in order to avoid false pen-up events. This value
|
||||
effects the overall sampling speed, hence need to be
|
||||
kept as low as possible, while avoiding false pen-up
|
||||
event. Start from a lower value, say 0x400, and
|
||||
increase value until false pen-up events are avoided.
|
||||
The pen-up detection happens immediately after the
|
||||
charge step, so this does in fact function as a
|
||||
hardware knob for adjusting the amount of "settling
|
||||
time".
|
||||
|
||||
Example:
|
||||
tscadc: tscadc@44e0d000 {
|
||||
compatible = "ti,am3359-tscadc";
|
||||
|
|
@ -36,6 +50,7 @@ Example:
|
|||
ti,x-plate-resistance = <200>;
|
||||
ti,coordiante-readouts = <5>;
|
||||
ti,wire-config = <0x00 0x11 0x22 0x33>;
|
||||
ti,charge-delay = <0x400>;
|
||||
};
|
||||
|
||||
adc {
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
Texas Instruments TPS65218 power button
|
||||
|
||||
This driver provides a simple power button event via an Interrupt.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "ti,tps65218-pwrbutton"
|
||||
- interrupts: should be one of the following
|
||||
- <3 IRQ_TYPE_EDGE_BOTH>: For controllers compatible with tps65218
|
||||
|
||||
Example:
|
||||
|
||||
&tps {
|
||||
power-button {
|
||||
compatible = "ti,tps65218-pwrbutton";
|
||||
interrupts = <3 IRQ_TYPE_EDGE_BOTH>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
* Renesas VMSA-Compatible IOMMU
|
||||
|
||||
The IPMMU is an IOMMU implementation compatible with the ARM VMSA page tables.
|
||||
It provides address translation for bus masters outside of the CPU, each
|
||||
connected to the IPMMU through a port called micro-TLB.
|
||||
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: Must contain "renesas,ipmmu-vmsa".
|
||||
- reg: Base address and size of the IPMMU registers.
|
||||
- interrupts: Specifiers for the MMU fault interrupts. For instances that
|
||||
support secure mode two interrupts must be specified, for non-secure and
|
||||
secure mode, in that order. For instances that don't support secure mode a
|
||||
single interrupt must be specified.
|
||||
|
||||
- #iommu-cells: Must be 1.
|
||||
|
||||
Each bus master connected to an IPMMU must reference the IPMMU in its device
|
||||
node with the following property:
|
||||
|
||||
- iommus: A reference to the IPMMU in two cells. The first cell is a phandle
|
||||
to the IPMMU and the second cell the number of the micro-TLB that the
|
||||
device is connected to.
|
||||
|
||||
|
||||
Example: R8A7791 IPMMU-MX and VSP1-D0 bus master
|
||||
|
||||
ipmmu_mx: mmu@fe951000 {
|
||||
compatible = "renasas,ipmmu-vmsa";
|
||||
reg = <0 0xfe951000 0 0x1000>;
|
||||
interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<0 221 IRQ_TYPE_LEVEL_HIGH>;
|
||||
#iommu-cells = <1>;
|
||||
};
|
||||
|
||||
vsp1@fe928000 {
|
||||
...
|
||||
iommus = <&ipmmu_mx 13>;
|
||||
...
|
||||
};
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
Altera Mailbox Driver
|
||||
=====================
|
||||
|
||||
Required properties:
|
||||
- compatible : "altr,mailbox-1.0".
|
||||
- reg : physical base address of the mailbox and length of
|
||||
memory mapped region.
|
||||
- #mbox-cells: Common mailbox binding property to identify the number
|
||||
of cells required for the mailbox specifier. Should be 1.
|
||||
|
||||
Optional properties:
|
||||
- interrupt-parent : interrupt source phandle.
|
||||
- interrupts : interrupt number. The interrupt specifier format
|
||||
depends on the interrupt controller parent.
|
||||
|
||||
Example:
|
||||
mbox_tx: mailbox@0x100 {
|
||||
compatible = "altr,mailbox-1.0";
|
||||
reg = <0x100 0x8>;
|
||||
interrupt-parent = < &gic_0 >;
|
||||
interrupts = <5>;
|
||||
#mbox-cells = <1>;
|
||||
};
|
||||
|
||||
mbox_rx: mailbox@0x200 {
|
||||
compatible = "altr,mailbox-1.0";
|
||||
reg = <0x200 0x8>;
|
||||
interrupt-parent = < &gic_0 >;
|
||||
interrupts = <6>;
|
||||
#mbox-cells = <1>;
|
||||
};
|
||||
|
||||
Mailbox client
|
||||
===============
|
||||
"mboxes" and the optional "mbox-names" (please see
|
||||
Documentation/devicetree/bindings/mailbox/mailbox.txt for details). Each value
|
||||
of the mboxes property should contain a phandle to the mailbox controller
|
||||
device node and second argument is the channel index. It must be 0 (hardware
|
||||
support only one channel).The equivalent "mbox-names" property value can be
|
||||
used to give a name to the communication channel to be used by the client user.
|
||||
|
||||
Example:
|
||||
mclient0: mclient0@0x400 {
|
||||
compatible = "client-1.0";
|
||||
reg = <0x400 0x10>;
|
||||
mbox-names = "mbox-tx", "mbox-rx";
|
||||
mboxes = <&mbox_tx 0>,
|
||||
<&mbox_rx 0>;
|
||||
};
|
||||
|
|
@ -38,7 +38,7 @@ Example:
|
|||
|
||||
i2c1: i2c@f0018000 {
|
||||
ov2640: camera@0x30 {
|
||||
compatible = "omnivision,ov2640";
|
||||
compatible = "ovti,ov2640";
|
||||
reg = <0x30>;
|
||||
|
||||
port {
|
||||
|
|
|
|||
|
|
@ -0,0 +1,63 @@
|
|||
SMIA/SMIA++ sensor
|
||||
|
||||
SMIA (Standard Mobile Imaging Architecture) is an image sensor standard
|
||||
defined jointly by Nokia and ST. SMIA++, defined by Nokia, is an extension
|
||||
of that. These definitions are valid for both types of sensors.
|
||||
|
||||
More detailed documentation can be found in
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt .
|
||||
|
||||
|
||||
Mandatory properties
|
||||
--------------------
|
||||
|
||||
- compatible: "nokia,smia"
|
||||
- reg: I2C address (0x10, or an alternative address)
|
||||
- vana-supply: Analogue voltage supply (VANA), typically 2,8 volts (sensor
|
||||
dependent).
|
||||
- clocks: External clock to the sensor
|
||||
- clock-frequency: Frequency of the external clock to the sensor
|
||||
- link-frequencies: List of allowed data link frequencies. An array of
|
||||
64-bit elements.
|
||||
|
||||
|
||||
Optional properties
|
||||
-------------------
|
||||
|
||||
- nokia,nvm-size: The size of the NVM, in bytes. If the size is not given,
|
||||
the NVM contents will not be read.
|
||||
- reset-gpios: XSHUTDOWN GPIO
|
||||
|
||||
|
||||
Endpoint node mandatory properties
|
||||
----------------------------------
|
||||
|
||||
- clock-lanes: <0>
|
||||
- data-lanes: <1..n>
|
||||
- remote-endpoint: A phandle to the bus receiver's endpoint node.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
&i2c2 {
|
||||
clock-frequency = <400000>;
|
||||
|
||||
smiapp_1: camera@10 {
|
||||
compatible = "nokia,smia";
|
||||
reg = <0x10>;
|
||||
reset-gpios = <&gpio3 20 0>;
|
||||
vana-supply = <&vaux3>;
|
||||
clocks = <&omap3_isp 0>;
|
||||
clock-frequency = <9600000>;
|
||||
nokia,nvm-size = <512>; /* 8 * 64 */
|
||||
link-frequencies = /bits/ 64 <199200000 210000000 499200000>;
|
||||
port {
|
||||
smiapp_1_1: endpoint {
|
||||
clock-lanes = <0>;
|
||||
data-lanes = <1 2>;
|
||||
remote-endpoint = <&csi2a_ep>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
Device-Tree bindings for SUNXI IR controller found in sunXi SoC family
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "allwinner,sun4i-a10-ir";
|
||||
- compatible : "allwinner,sun4i-a10-ir" or "allwinner,sun5i-a13-ir"
|
||||
- clocks : list of clock specifiers, corresponding to
|
||||
entries in clock-names property;
|
||||
- clock-names : should contain "apb" and "ir" entries;
|
||||
|
|
@ -10,6 +10,7 @@ Required properties:
|
|||
|
||||
Optional properties:
|
||||
- linux,rc-map-name : Remote control map name.
|
||||
- resets : phandle + reset specifier pair
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -17,6 +18,7 @@ ir0: ir@01c21800 {
|
|||
compatible = "allwinner,sun4i-a10-ir";
|
||||
clocks = <&apb0_gates 6>, <&ir0_clk>;
|
||||
clock-names = "apb", "ir";
|
||||
resets = <&apb0_rst 1>;
|
||||
interrupts = <0 5 1>;
|
||||
reg = <0x01C21800 0x40>;
|
||||
linux,rc-map-name = "rc-rc6-mce";
|
||||
|
|
|
|||
|
|
@ -0,0 +1,61 @@
|
|||
Texas Instruments AM437x CAMERA (VPFE)
|
||||
--------------------------------------
|
||||
|
||||
The Video Processing Front End (VPFE) is a key component for image capture
|
||||
applications. The capture module provides the system interface and the
|
||||
processing capability to connect RAW image-sensor modules and video decoders
|
||||
to the AM437x device.
|
||||
|
||||
Required properties:
|
||||
- compatible: must be "ti,am437x-vpfe"
|
||||
- reg: physical base address and length of the registers set for the device;
|
||||
- interrupts: should contain IRQ line for the VPFE;
|
||||
- ti,am437x-vpfe-interface: can be one of the following,
|
||||
0 - Raw Bayer Interface.
|
||||
1 - 8 Bit BT656 Interface.
|
||||
2 - 10 Bit BT656 Interface.
|
||||
3 - YCbCr 8 Bit Interface.
|
||||
4 - YCbCr 16 Bit Interface.
|
||||
|
||||
VPFE supports a single port node with parallel bus. It should contain one
|
||||
'port' child node with child 'endpoint' node. Please refer to the bindings
|
||||
defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
|
||||
|
||||
Example:
|
||||
vpfe: vpfe@f0034000 {
|
||||
compatible = "ti,am437x-vpfe";
|
||||
reg = <0x48328000 0x2000>;
|
||||
interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
|
||||
|
||||
pinctrl-names = "default", "sleep";
|
||||
pinctrl-0 = <&vpfe_pins_default>;
|
||||
pinctrl-1 = <&vpfe_pins_sleep>;
|
||||
|
||||
port {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
vpfe0_ep: endpoint {
|
||||
remote-endpoint = <&ov2659_1>;
|
||||
ti,am437x-vpfe-interface = <0>;
|
||||
bus-width = <8>;
|
||||
hsync-active = <0>;
|
||||
vsync-active = <0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
i2c1: i2c@4802a000 {
|
||||
|
||||
ov2659@30 {
|
||||
compatible = "ti,ov2659";
|
||||
reg = <0x30>;
|
||||
|
||||
port {
|
||||
ov2659_1: endpoint {
|
||||
remote-endpoint = <&vpfe0_ep>;
|
||||
bus-width = <8>;
|
||||
mclk-frequency = <12000000>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -103,6 +103,9 @@ Optional endpoint properties
|
|||
array contains only one entry.
|
||||
- clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous
|
||||
clock mode.
|
||||
- link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for
|
||||
instance, this is the actual frequency of the bus, not bits per clock per
|
||||
lane value. An array of 64-bit unsigned integers.
|
||||
|
||||
|
||||
Example
|
||||
|
|
@ -159,7 +162,7 @@ pipelines can be active: ov772x -> ceu0 or imx074 -> csi2 -> ceu0.
|
|||
i2c0: i2c@0xfff20000 {
|
||||
...
|
||||
ov772x_1: camera@0x21 {
|
||||
compatible = "omnivision,ov772x";
|
||||
compatible = "ovti,ov772x";
|
||||
reg = <0x21>;
|
||||
vddio-supply = <®ulator1>;
|
||||
vddcore-supply = <®ulator2>;
|
||||
|
|
|
|||
|
|
@ -39,6 +39,12 @@ to get matched with their hardware counterparts as follow:
|
|||
-BUCKn : 1-4.
|
||||
Use standard regulator bindings for it ('regulator-off-in-suspend').
|
||||
|
||||
LDO20, LDO21, LDO22, BUCK8 and BUCK9 can be configured to GPIO enable
|
||||
control. To turn this feature on this property must be added to the regulator
|
||||
sub-node:
|
||||
- maxim,ena-gpios : one GPIO specifier enable control (the gpio
|
||||
flags are actually ignored and always
|
||||
ACTIVE_HIGH is used)
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -65,4 +71,12 @@ Example:
|
|||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
};
|
||||
|
||||
buck9_reg {
|
||||
regulator-compatible = "BUCK9";
|
||||
regulator-name = "CAM_ISP_CORE_1.2V";
|
||||
regulator-min-microvolt = <1000000>;
|
||||
regulator-max-microvolt = <1200000>;
|
||||
maxim,ena-gpios = <&gpm0 3 GPIO_ACTIVE_HIGH>;
|
||||
};
|
||||
}
|
||||
|
|
|
|||
|
|
@ -41,6 +41,41 @@ Optional properties:
|
|||
To get more informations, please refer to documentaion.
|
||||
[*] refer Documentation/devicetree/bindings/pwm/pwm.txt
|
||||
|
||||
- charger : Node configuring the charger driver.
|
||||
If present, required properties:
|
||||
- compatible : Must be "maxim,max77693-charger".
|
||||
|
||||
Optional properties (if not set, defaults will be used):
|
||||
- maxim,constant-microvolt : Battery constant voltage in uV. The charger
|
||||
will operate in fast charge constant current mode till battery voltage
|
||||
reaches this level. Then the charger will switch to fast charge constant
|
||||
voltage mode. Also vsys (system voltage) will be set to this value when
|
||||
DC power is supplied but charger is not enabled.
|
||||
Valid values: 3650000 - 4400000, step by 25000 (rounded down)
|
||||
Default: 4200000
|
||||
|
||||
- maxim,min-system-microvolt : Minimal system voltage in uV.
|
||||
Valid values: 3000000 - 3700000, step by 100000 (rounded down)
|
||||
Default: 3600000
|
||||
|
||||
- maxim,thermal-regulation-celsius : Temperature in Celsius for entering
|
||||
high temperature charging mode. If die temperature exceeds this value
|
||||
the charging current will be reduced by 105 mA/Celsius.
|
||||
Valid values: 70, 85, 100, 115
|
||||
Default: 100
|
||||
|
||||
- maxim,battery-overcurrent-microamp : Overcurrent protection threshold
|
||||
in uA (current from battery to system).
|
||||
Valid values: 2000000 - 3500000, step by 250000 (rounded down)
|
||||
Default: 3500000
|
||||
|
||||
- maxim,charge-input-threshold-microvolt : Threshold voltage in uV for
|
||||
triggering input voltage regulation loop. If input voltage decreases
|
||||
below this value, the input current will be reduced to reach the
|
||||
threshold voltage.
|
||||
Valid values: 4300000, 4700000, 4800000, 4900000
|
||||
Default: 4300000
|
||||
|
||||
Example:
|
||||
max77693@66 {
|
||||
compatible = "maxim,max77693";
|
||||
|
|
@ -73,4 +108,14 @@ Example:
|
|||
pwms = <&pwm 0 40000 0>;
|
||||
pwm-names = "haptic";
|
||||
};
|
||||
|
||||
charger {
|
||||
compatible = "maxim,max77693-charger";
|
||||
|
||||
maxim,constant-microvolt = <4200000>;
|
||||
maxim,min-system-microvolt = <3600000>;
|
||||
maxim,thermal-regulation-celsius = <75>;
|
||||
maxim,battery-overcurrent-microamp = <3000000>;
|
||||
maxim,charge-input-threshold-microvolt = <4300000>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,11 +1,10 @@
|
|||
NVIDIA Tegra20/Tegra30/Tegr114/Tegra124 apbmisc block
|
||||
|
||||
Required properties:
|
||||
- compatible : should be:
|
||||
"nvidia,tegra20-apbmisc"
|
||||
"nvidia,tegra30-apbmisc"
|
||||
"nvidia,tegra114-apbmisc"
|
||||
"nvidia,tegra124-apbmisc"
|
||||
- compatible : For Tegra20, must be "nvidia,tegra20-apbmisc". For Tegra30,
|
||||
must be "nvidia,tegra30-apbmisc". Otherwise, must contain
|
||||
"nvidia,<chip>-apbmisc", plus one of the above, where <chip> is tegra114,
|
||||
tegra124, tegra132.
|
||||
- reg: Should contain 2 entries: the first entry gives the physical address
|
||||
and length of the registers which contain revision and debug features.
|
||||
The second entry gives the physical address and length of the
|
||||
|
|
|
|||
|
|
@ -0,0 +1,25 @@
|
|||
* The simple eMMC hardware reset provider
|
||||
|
||||
The purpose of this driver is to perform standard eMMC hw reset
|
||||
procedure, as descibed by Jedec 4.4 specification. This procedure is
|
||||
performed just after MMC core enabled power to the given mmc host (to
|
||||
fix possible issues if bootloader has left eMMC card in initialized or
|
||||
unknown state), and before performing complete system reboot (also in
|
||||
case of emergency reboot call). The latter is needed on boards, which
|
||||
doesn't have hardware reset logic connected to emmc card and (limited or
|
||||
broken) ROM bootloaders are unable to read second stage from the emmc
|
||||
card if the card is left in unknown or already initialized state.
|
||||
|
||||
Required properties:
|
||||
- compatible : contains "mmc-pwrseq-emmc".
|
||||
- reset-gpios : contains a GPIO specifier. The reset GPIO is asserted
|
||||
and then deasserted to perform eMMC card reset. To perform
|
||||
reset procedure as described in Jedec 4.4 specification, the
|
||||
gpio line should be defined as GPIO_ACTIVE_LOW.
|
||||
|
||||
Example:
|
||||
|
||||
sdhci0_pwrseq {
|
||||
compatible = "mmc-pwrseq-emmc";
|
||||
reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
|
||||
}
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
* The simple MMC power sequence provider
|
||||
|
||||
The purpose of the simple MMC power sequence provider is to supports a set of
|
||||
common properties between various SOC designs. It thus enables us to use the
|
||||
same provider for several SOC designs.
|
||||
|
||||
Required properties:
|
||||
- compatible : contains "mmc-pwrseq-simple".
|
||||
|
||||
Optional properties:
|
||||
- reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted
|
||||
at initialization and prior we start the power up procedure of the card.
|
||||
They will be de-asserted right after the power has been provided to the
|
||||
card.
|
||||
- clocks : Must contain an entry for the entry in clock-names.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- clock-names : Must include the following entry:
|
||||
"ext_clock" (External clock provided to the card).
|
||||
|
||||
Example:
|
||||
|
||||
sdhci0_pwrseq {
|
||||
compatible = "mmc-pwrseq-simple";
|
||||
reset-gpios = <&gpio1 12 0>;
|
||||
}
|
||||
|
|
@ -64,7 +64,43 @@ Optional SDIO properties:
|
|||
- keep-power-in-suspend: Preserves card power during a suspend/resume cycle
|
||||
- enable-sdio-wakeup: Enables wake up of host system on SDIO IRQ assertion
|
||||
|
||||
Example:
|
||||
|
||||
MMC power sequences:
|
||||
--------------------
|
||||
|
||||
System on chip designs may specify a specific MMC power sequence. To
|
||||
successfully detect an (e)MMC/SD/SDIO card, that power sequence must be
|
||||
maintained while initializing the card.
|
||||
|
||||
Optional property:
|
||||
- mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
|
||||
for documentation of MMC power sequence bindings.
|
||||
|
||||
|
||||
Use of Function subnodes
|
||||
------------------------
|
||||
|
||||
On embedded systems the cards connected to a host may need additional
|
||||
properties. These can be specified in subnodes to the host controller node.
|
||||
The subnodes are identified by the standard 'reg' property.
|
||||
Which information exactly can be specified depends on the bindings for the
|
||||
SDIO function driver for the subnode, as specified by the compatible string.
|
||||
|
||||
Required host node properties when using function subnodes:
|
||||
- #address-cells: should be one. The cell is the slot id.
|
||||
- #size-cells: should be zero.
|
||||
|
||||
Required function subnode properties:
|
||||
- compatible: name of SDIO function following generic names recommended practice
|
||||
- reg: Must contain the SDIO function number of the function this subnode
|
||||
describes. A value of 0 denotes the memory SD function, values from
|
||||
1 to 7 denote the SDIO functions.
|
||||
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
Basic example:
|
||||
|
||||
sdhci@ab000000 {
|
||||
compatible = "sdhci";
|
||||
|
|
@ -77,4 +113,28 @@ sdhci@ab000000 {
|
|||
max-frequency = <50000000>;
|
||||
keep-power-in-suspend;
|
||||
enable-sdio-wakeup;
|
||||
mmc-pwrseq = <&sdhci0_pwrseq>
|
||||
}
|
||||
|
||||
Example with sdio function subnode:
|
||||
|
||||
mmc3: mmc@01c12000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&mmc3_pins_a>;
|
||||
vmmc-supply = <®_vmmc3>;
|
||||
bus-width = <4>;
|
||||
non-removable;
|
||||
mmc-pwrseq = <&sdhci0_pwrseq>
|
||||
status = "okay";
|
||||
|
||||
brcmf: bcrmf@1 {
|
||||
reg = <1>;
|
||||
compatible = "brcm,bcm43xx-fmac";
|
||||
interrupt-parent = <&pio>;
|
||||
interrupts = <10 8>; /* PH10 / EINT10 */
|
||||
interrupt-names = "host-wake";
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -7,7 +7,11 @@ This file documents differences between the core properties described
|
|||
by mmc.txt and the properties used by the sdhci-tegra driver.
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "nvidia,<chip>-sdhci"
|
||||
- compatible : For Tegra20, must contain "nvidia,tegra20-sdhci".
|
||||
For Tegra30, must contain "nvidia,tegra30-sdhci". For Tegra114,
|
||||
must contain "nvidia,tegra114-sdhci". For Tegra124, must contain
|
||||
"nvidia,tegra124-sdhci". Otherwise, must contain "nvidia,<chip>-sdhci",
|
||||
plus one of the above, where <chip> is tegra132 or tegra210.
|
||||
- clocks : Must contain one entry, for the module clock.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- resets : Must contain an entry for each entry in reset-names.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,30 @@
|
|||
* Fujitsu SDHCI controller
|
||||
|
||||
This file documents differences between the core properties in mmc.txt
|
||||
and the properties used by the sdhci_f_sdh30 driver.
|
||||
|
||||
Required properties:
|
||||
- compatible: "fujitsu,mb86s70-sdhci-3.0"
|
||||
- clocks: Must contain an entry for each entry in clock-names. It is a
|
||||
list of phandles and clock-specifier pairs.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- clock-names: Should contain the following two entries:
|
||||
"iface" - clock used for sdhci interface
|
||||
"core" - core clock for sdhci controller
|
||||
|
||||
Optional properties:
|
||||
- vqmmc-supply: phandle to the regulator device tree node, mentioned
|
||||
as the VCCQ/VDD_IO supply in the eMMC/SD specs.
|
||||
|
||||
Example:
|
||||
|
||||
sdhci1: mmc@36600000 {
|
||||
compatible = "fujitsu,mb86s70-sdhci-3.0";
|
||||
reg = <0 0x36600000 0x1000>;
|
||||
interrupts = <0 172 0x4>,
|
||||
<0 173 0x4>;
|
||||
bus-width = <4>;
|
||||
vqmmc-supply = <&vccq_sdhci1>;
|
||||
clocks = <&clock 2 2 0>, <&clock 2 3 0>;
|
||||
clock-names = "iface", "core";
|
||||
};
|
||||
|
|
@ -9,9 +9,13 @@ Required properties:
|
|||
- reg:
|
||||
* for "mrvl,pxav2-mmc" and "mrvl,pxav3-mmc", one register area for
|
||||
the SDHCI registers.
|
||||
* for "marvell,armada-380-sdhci", two register areas. The first one
|
||||
for the SDHCI registers themselves, and the second one for the
|
||||
AXI/Mbus bridge registers of the SDHCI unit.
|
||||
|
||||
* for "marvell,armada-380-sdhci", three register areas. The first
|
||||
one for the SDHCI registers themselves, the second one for the
|
||||
AXI/Mbus bridge registers of the SDHCI unit, the third one for the
|
||||
SDIO3 Configuration register
|
||||
- reg names: should be "sdhci", "mbus", "conf-sdio3". only mandatory
|
||||
for "marvell,armada-380-sdhci"
|
||||
- clocks: Array of clocks required for SDHCI; requires at least one for
|
||||
I/O clock.
|
||||
- clock-names: Array of names corresponding to clocks property; shall be
|
||||
|
|
@ -35,7 +39,10 @@ sdhci@d4280800 {
|
|||
|
||||
sdhci@d8000 {
|
||||
compatible = "marvell,armada-380-sdhci";
|
||||
reg = <0xd8000 0x1000>, <0xdc000 0x100>;
|
||||
reg-names = "sdhci", "mbus", "conf-sdio3";
|
||||
reg = <0xd8000 0x1000>,
|
||||
<0xdc000 0x100>;
|
||||
<0x18454 0x4>;
|
||||
interrupts = <0 25 0x4>;
|
||||
clocks = <&gateclk 17>;
|
||||
clock-names = "io";
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ Required properties:
|
|||
Optional properties:
|
||||
- bank-width : Width (in bytes) of the device. If not present, the width
|
||||
defaults to 1 byte
|
||||
- nand-skip-bbtscan: Indicates the the BBT scanning should be skipped
|
||||
- nand-skip-bbtscan: Indicates the BBT scanning should be skipped
|
||||
- timings: array of 6 bytes for NAND timings. The meanings of these bytes
|
||||
are:
|
||||
byte 0 TCLR : CLE to RE delay in number of AHB clock cycles, only 4 bits
|
||||
|
|
|
|||
|
|
@ -7,17 +7,38 @@ Required properties:
|
|||
- SerDes Rx/Tx registers
|
||||
- SerDes integration registers (1/2)
|
||||
- SerDes integration registers (2/2)
|
||||
- interrupt-parent: Should be the phandle for the interrupt controller
|
||||
that services interrupts for this device
|
||||
- interrupts: Should contain the amd-xgbe-phy interrupt.
|
||||
|
||||
Optional properties:
|
||||
- amd,speed-set: Speed capabilities of the device
|
||||
0 - 1GbE and 10GbE (default)
|
||||
1 - 2.5GbE and 10GbE
|
||||
|
||||
The following optional properties are represented by an array with each
|
||||
value corresponding to a particular speed. The first array value represents
|
||||
the setting for the 1GbE speed, the second value for the 2.5GbE speed and
|
||||
the third value for the 10GbE speed. All three values are required if the
|
||||
property is used.
|
||||
- amd,serdes-blwc: Baseline wandering correction enablement
|
||||
0 - Off
|
||||
1 - On
|
||||
- amd,serdes-cdr-rate: CDR rate speed selection
|
||||
- amd,serdes-pq-skew: PQ (data sampling) skew
|
||||
- amd,serdes-tx-amp: TX amplitude boost
|
||||
|
||||
Example:
|
||||
xgbe_phy@e1240800 {
|
||||
compatible = "amd,xgbe-phy-seattle-v1a", "ethernet-phy-ieee802.3-c45";
|
||||
reg = <0 0xe1240800 0 0x00400>,
|
||||
<0 0xe1250000 0 0x00060>,
|
||||
<0 0xe1250080 0 0x00004>;
|
||||
interrupt-parent = <&gic>;
|
||||
interrupts = <0 323 4>;
|
||||
amd,speed-set = <0>;
|
||||
amd,serdes-blwc = <1>, <1>, <0>;
|
||||
amd,serdes-cdr-rate = <2>, <2>, <7>;
|
||||
amd,serdes-pq-skew = <10>, <10>, <30>;
|
||||
amd,serdes-tx-amp = <15>, <15>, <10>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Required properties:
|
||||
- compatible: should be one of "brcm,systemport-v1.00" or "brcm,systemport"
|
||||
- reg: address and length of the register set for the device.
|
||||
- interrupts: interrupts for the device, first cell must be for the the rx
|
||||
- interrupts: interrupts for the device, first cell must be for the rx
|
||||
interrupts, and the second cell should be for the transmit queues. An
|
||||
optional third interrupt cell for Wake-on-LAN can be specified
|
||||
- local-mac-address: Ethernet MAC address (48 bits) of this adapter
|
||||
|
|
|
|||
|
|
@ -11,6 +11,8 @@ Required properties:
|
|||
Optional properties:
|
||||
- davicom,no-eeprom : Configuration EEPROM is not available
|
||||
- davicom,ext-phy : Use external PHY
|
||||
- reset-gpios : phandle of gpio that will be used to reset chip during probe
|
||||
- vcc-supply : phandle of regulator that will be used to enable power to chip
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -21,4 +23,6 @@ Example:
|
|||
interrupts = <7 4>;
|
||||
local-mac-address = [00 00 de ad be ef];
|
||||
davicom,no-eeprom;
|
||||
reset-gpios = <&gpf 12 GPIO_ACTIVE_LOW>;
|
||||
vcc-supply = <ð0_power>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -4,7 +4,8 @@ This file provides information, what the device node
|
|||
for the davinci_emac interface contains.
|
||||
|
||||
Required properties:
|
||||
- compatible: "ti,davinci-dm6467-emac" or "ti,am3517-emac"
|
||||
- compatible: "ti,davinci-dm6467-emac", "ti,am3517-emac" or
|
||||
"ti,dm816-emac"
|
||||
- reg: Offset and length of the register set for the device
|
||||
- ti,davinci-ctrl-reg-offset: offset to control register
|
||||
- ti,davinci-ctrl-mod-reg-offset: offset to control module register
|
||||
|
|
|
|||
|
|
@ -22,6 +22,8 @@ Optional properties:
|
|||
- fsl,num-rx-queues : The property is valid for enet-avb IP, which supports
|
||||
hw multi queues. Should specify the rx queue number, otherwise set rx queue
|
||||
number to 1.
|
||||
- fsl,magic-packet : If present, indicates that the hardware supports waking
|
||||
up via magic packet.
|
||||
|
||||
Optional subnodes:
|
||||
- mdio : specifies the mdio bus in the FEC, used as a container for phy nodes
|
||||
|
|
|
|||
|
|
@ -8,7 +8,16 @@ of how to define a PHY.
|
|||
Required properties:
|
||||
- reg : Offset and length of the register set for the device
|
||||
- compatible : Should define the compatible device type for the
|
||||
mdio. Currently, this is most likely to be "fsl,gianfar-mdio"
|
||||
mdio. Currently supported strings/devices are:
|
||||
- "fsl,gianfar-tbi"
|
||||
- "fsl,gianfar-mdio"
|
||||
- "fsl,etsec2-tbi"
|
||||
- "fsl,etsec2-mdio"
|
||||
- "fsl,ucc-mdio"
|
||||
- "fsl,fman-mdio"
|
||||
When device_type is "mdio", the following strings are also considered:
|
||||
- "gianfar"
|
||||
- "ucc_geth_phy"
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,88 @@
|
|||
Hisilicon hip04 Ethernet Controller
|
||||
|
||||
* Ethernet controller node
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "hisilicon,hip04-mac".
|
||||
- reg: address and length of the register set for the device.
|
||||
- interrupts: interrupt for the device.
|
||||
- port-handle: <phandle port channel>
|
||||
phandle, specifies a reference to the syscon ppe node
|
||||
port, port number connected to the controller
|
||||
channel, recv channel start from channel * number (RX_DESC_NUM)
|
||||
- phy-mode: see ethernet.txt [1].
|
||||
|
||||
Optional properties:
|
||||
- phy-handle: see ethernet.txt [1].
|
||||
|
||||
[1] Documentation/devicetree/bindings/net/ethernet.txt
|
||||
|
||||
|
||||
* Ethernet ppe node:
|
||||
Control rx & tx fifos of all ethernet controllers.
|
||||
Have 2048 recv channels shared by all ethernet controllers, only if no overlap.
|
||||
Each controller's recv channel start from channel * number (RX_DESC_NUM).
|
||||
|
||||
Required properties:
|
||||
- compatible: "hisilicon,hip04-ppe", "syscon".
|
||||
- reg: address and length of the register set for the device.
|
||||
|
||||
|
||||
* MDIO bus node:
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: should be "hisilicon,hip04-mdio".
|
||||
- Inherits from MDIO bus node binding [2]
|
||||
[2] Documentation/devicetree/bindings/net/phy.txt
|
||||
|
||||
Example:
|
||||
mdio {
|
||||
compatible = "hisilicon,hip04-mdio";
|
||||
reg = <0x28f1000 0x1000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
phy0: ethernet-phy@0 {
|
||||
compatible = "ethernet-phy-ieee802.3-c22";
|
||||
reg = <0>;
|
||||
marvell,reg-init = <18 0x14 0 0x8001>;
|
||||
};
|
||||
|
||||
phy1: ethernet-phy@1 {
|
||||
compatible = "ethernet-phy-ieee802.3-c22";
|
||||
reg = <1>;
|
||||
marvell,reg-init = <18 0x14 0 0x8001>;
|
||||
};
|
||||
};
|
||||
|
||||
ppe: ppe@28c0000 {
|
||||
compatible = "hisilicon,hip04-ppe", "syscon";
|
||||
reg = <0x28c0000 0x10000>;
|
||||
};
|
||||
|
||||
fe: ethernet@28b0000 {
|
||||
compatible = "hisilicon,hip04-mac";
|
||||
reg = <0x28b0000 0x10000>;
|
||||
interrupts = <0 413 4>;
|
||||
phy-mode = "mii";
|
||||
port-handle = <&ppe 31 0>;
|
||||
};
|
||||
|
||||
ge0: ethernet@2800000 {
|
||||
compatible = "hisilicon,hip04-mac";
|
||||
reg = <0x2800000 0x10000>;
|
||||
interrupts = <0 402 4>;
|
||||
phy-mode = "sgmii";
|
||||
port-handle = <&ppe 0 1>;
|
||||
phy-handle = <&phy0>;
|
||||
};
|
||||
|
||||
ge8: ethernet@2880000 {
|
||||
compatible = "hisilicon,hip04-mac";
|
||||
reg = <0x2880000 0x10000>;
|
||||
interrupts = <0 410 4>;
|
||||
phy-mode = "sgmii";
|
||||
port-handle = <&ppe 8 2>;
|
||||
phy-handle = <&phy1>;
|
||||
};
|
||||
|
|
@ -0,0 +1,197 @@
|
|||
This document describes the device tree bindings associated with the
|
||||
keystone network coprocessor(NetCP) driver support.
|
||||
|
||||
The network coprocessor (NetCP) is a hardware accelerator that processes
|
||||
Ethernet packets. NetCP has a gigabit Ethernet (GbE) subsytem with a ethernet
|
||||
switch sub-module to send and receive packets. NetCP also includes a packet
|
||||
accelerator (PA) module to perform packet classification operations such as
|
||||
header matching, and packet modification operations such as checksum
|
||||
generation. NetCP can also optionally include a Security Accelerator (SA)
|
||||
capable of performing IPSec operations on ingress/egress packets.
|
||||
|
||||
Keystone II SoC's also have a 10 Gigabit Ethernet Subsystem (XGbE) which
|
||||
includes a 3-port Ethernet switch sub-module capable of 10Gb/s and 1Gb/s rates
|
||||
per Ethernet port.
|
||||
|
||||
Keystone NetCP driver has a plug-in module architecture where each of the NetCP
|
||||
sub-modules exist as a loadable kernel module which plug in to the netcp core.
|
||||
These sub-modules are represented as "netcp-devices" in the dts bindings. It is
|
||||
mandatory to have the ethernet switch sub-module for the ethernet interface to
|
||||
be operational. Any other sub-module like the PA is optional.
|
||||
|
||||
NetCP Ethernet SubSystem Layout:
|
||||
|
||||
-----------------------------
|
||||
NetCP subsystem(10G or 1G)
|
||||
-----------------------------
|
||||
|
|
||||
|-> NetCP Devices -> |
|
||||
| |-> GBE/XGBE Switch
|
||||
| |
|
||||
| |-> Packet Accelerator
|
||||
| |
|
||||
| |-> Security Accelerator
|
||||
|
|
||||
|
|
||||
|
|
||||
|-> NetCP Interfaces -> |
|
||||
|-> Ethernet Port 0
|
||||
|
|
||||
|-> Ethernet Port 1
|
||||
|
|
||||
|-> Ethernet Port 2
|
||||
|
|
||||
|-> Ethernet Port 3
|
||||
|
||||
|
||||
NetCP subsystem properties:
|
||||
Required properties:
|
||||
- compatible: Should be "ti,netcp-1.0"
|
||||
- clocks: phandle to the reference clocks for the subsystem.
|
||||
- dma-id: Navigator packet dma instance id.
|
||||
|
||||
Optional properties:
|
||||
- reg: register location and the size for the following register
|
||||
regions in the specified order.
|
||||
- Efuse MAC address register
|
||||
- dma-coherent: Present if dma operations are coherent
|
||||
- big-endian: Keystone devices can be operated in a mode where the DSP is in
|
||||
the big endian mode. In such cases enable this option. This
|
||||
option should also be enabled if the ARM is operated in
|
||||
big endian mode with the DSP in little endian.
|
||||
|
||||
NetCP device properties: Device specification for NetCP sub-modules.
|
||||
1Gb/10Gb (gbe/xgbe) ethernet switch sub-module specifications.
|
||||
Required properties:
|
||||
- label: Must be "netcp-gbe" for 1Gb & "netcp-xgbe" for 10Gb.
|
||||
- reg: register location and the size for the following register
|
||||
regions in the specified order.
|
||||
- subsystem registers
|
||||
- serdes registers
|
||||
- tx-channel: the navigator packet dma channel name for tx.
|
||||
- tx-queue: the navigator queue number associated with the tx dma channel.
|
||||
- interfaces: specification for each of the switch port to be registered as a
|
||||
network interface in the stack.
|
||||
-- slave-port: Switch port number, 0 based numbering.
|
||||
-- link-interface: type of link interface, supported options are
|
||||
- mac<->mac auto negotiate mode: 0
|
||||
- mac<->phy mode: 1
|
||||
- mac<->mac forced mode: 2
|
||||
- mac<->fiber mode: 3
|
||||
- mac<->phy mode with no mdio: 4
|
||||
- 10Gb mac<->phy mode : 10
|
||||
- 10Gb mac<->mac forced mode : 11
|
||||
----phy-handle: phandle to PHY device
|
||||
|
||||
Optional properties:
|
||||
- enable-ale: NetCP driver keeps the address learning feature in the ethernet
|
||||
switch module disabled. This attribute is to enable the address
|
||||
learning.
|
||||
- secondary-slave-ports: specification for each of the switch port not be
|
||||
registered as a network interface. NetCP driver
|
||||
will only initialize these ports and attach PHY
|
||||
driver to them if needed.
|
||||
|
||||
NetCP interface properties: Interface specification for NetCP sub-modules.
|
||||
Required properties:
|
||||
- rx-channel: the navigator packet dma channel name for rx.
|
||||
- rx-queue: the navigator queue number associated with rx dma channel.
|
||||
- rx-pool: specifies the number of descriptors to be used & the region-id
|
||||
for creating the rx descriptor pool.
|
||||
- tx-pool: specifies the number of descriptors to be used & the region-id
|
||||
for creating the tx descriptor pool.
|
||||
- rx-queue-depth: number of descriptors in each of the free descriptor
|
||||
queue (FDQ) for the pktdma Rx flow. There can be at
|
||||
present a maximum of 4 queues per Rx flow.
|
||||
- rx-buffer-size: the buffer size for each of the Rx flow FDQ.
|
||||
- tx-completion-queue: the navigator queue number where the descriptors are
|
||||
recycled after Tx DMA completion.
|
||||
|
||||
Optional properties:
|
||||
- efuse-mac: If this is 1, then the MAC address for the interface is
|
||||
obtained from the device efuse mac address register
|
||||
- local-mac-address: the driver is designed to use the of_get_mac_address api
|
||||
only if efuse-mac is 0. When efuse-mac is 0, the MAC
|
||||
address is obtained from local-mac-address. If this
|
||||
attribute is not present, then the driver will use a
|
||||
random MAC address.
|
||||
- "netcp-device label": phandle to the device specification for each of NetCP
|
||||
sub-module attached to this interface.
|
||||
|
||||
Example binding:
|
||||
|
||||
netcp: netcp@2090000 {
|
||||
reg = <0x2620110 0x8>;
|
||||
reg-names = "efuse";
|
||||
compatible = "ti,netcp-1.0";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges;
|
||||
|
||||
clocks = <&papllclk>, <&clkcpgmac>, <&chipclk12>;
|
||||
dma-coherent;
|
||||
/* big-endian; */
|
||||
dma-id = <0>;
|
||||
|
||||
netcp-devices {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges;
|
||||
gbe@0x2090000 {
|
||||
label = "netcp-gbe";
|
||||
reg = <0x2090000 0xf00>;
|
||||
/* enable-ale; */
|
||||
tx-queue = <648>;
|
||||
tx-channel = <8>;
|
||||
|
||||
interfaces {
|
||||
gbe0: interface-0 {
|
||||
slave-port = <0>;
|
||||
link-interface = <4>;
|
||||
};
|
||||
gbe1: interface-1 {
|
||||
slave-port = <1>;
|
||||
link-interface = <4>;
|
||||
};
|
||||
};
|
||||
|
||||
secondary-slave-ports {
|
||||
port-2 {
|
||||
slave-port = <2>;
|
||||
link-interface = <2>;
|
||||
};
|
||||
port-3 {
|
||||
slave-port = <3>;
|
||||
link-interface = <2>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
netcp-interfaces {
|
||||
interface-0 {
|
||||
rx-channel = <22>;
|
||||
rx-pool = <1024 12>;
|
||||
tx-pool = <1024 12>;
|
||||
rx-queue-depth = <128 128 0 0>;
|
||||
rx-buffer-size = <1518 4096 0 0>;
|
||||
rx-queue = <8704>;
|
||||
tx-completion-queue = <8706>;
|
||||
efuse-mac = <1>;
|
||||
netcp-gbe = <&gbe0>;
|
||||
|
||||
};
|
||||
interface-1 {
|
||||
rx-channel = <23>;
|
||||
rx-pool = <1024 12>;
|
||||
tx-pool = <1024 12>;
|
||||
rx-queue-depth = <128 128 0 0>;
|
||||
rx-buffer-size = <1518 4096 0 0>;
|
||||
rx-queue = <8705>;
|
||||
tx-completion-queue = <8707>;
|
||||
efuse-mac = <0>;
|
||||
local-mac-address = [02 18 31 7e 3e 6f];
|
||||
netcp-gbe = <&gbe1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
* STMicroelectronics SAS. ST21NFCA NFC Controller
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "st,st21nfca_i2c".
|
||||
- compatible: Should be "st,st21nfca-i2c".
|
||||
- clock-frequency: I²C work frequency.
|
||||
- reg: address on the bus
|
||||
- interrupt-parent: phandle for the interrupt gpio controller
|
||||
|
|
@ -11,6 +11,10 @@ Required properties:
|
|||
Optional SoC Specific Properties:
|
||||
- pinctrl-names: Contains only one value - "default".
|
||||
- pintctrl-0: Specifies the pin control groups used for this controller.
|
||||
- ese-present: Specifies that an ese is physically connected to the nfc
|
||||
controller.
|
||||
- uicc-present: Specifies that the uicc swp signal can be physically
|
||||
connected to the nfc controller.
|
||||
|
||||
Example (for ARM-based BeagleBoard xM with ST21NFCA on I2C2):
|
||||
|
||||
|
|
@ -20,7 +24,7 @@ Example (for ARM-based BeagleBoard xM with ST21NFCA on I2C2):
|
|||
|
||||
st21nfca: st21nfca@1 {
|
||||
|
||||
compatible = "st,st21nfca_i2c";
|
||||
compatible = "st,st21nfca-i2c";
|
||||
|
||||
reg = <0x01>;
|
||||
clock-frequency = <400000>;
|
||||
|
|
@ -29,5 +33,8 @@ Example (for ARM-based BeagleBoard xM with ST21NFCA on I2C2):
|
|||
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
|
||||
|
||||
enable-gpios = <&gpio5 29 GPIO_ACTIVE_HIGH>;
|
||||
|
||||
ese-present;
|
||||
uicc-present;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
* STMicroelectronics SAS. ST21NFCB NFC Controller
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "st,st21nfcb_i2c".
|
||||
- compatible: Should be "st,st21nfcb-i2c".
|
||||
- clock-frequency: I²C work frequency.
|
||||
- reg: address on the bus
|
||||
- interrupt-parent: phandle for the interrupt gpio controller
|
||||
|
|
@ -20,7 +20,7 @@ Example (for ARM-based BeagleBoard xM with ST21NFCB on I2C2):
|
|||
|
||||
st21nfcb: st21nfcb@8 {
|
||||
|
||||
compatible = "st,st21nfcb_i2c";
|
||||
compatible = "st,st21nfcb-i2c";
|
||||
|
||||
reg = <0x08>;
|
||||
clock-frequency = <400000>;
|
||||
|
|
|
|||
|
|
@ -0,0 +1,68 @@
|
|||
Rockchip SoC RK3288 10/100/1000 Ethernet driver(GMAC)
|
||||
|
||||
The device node has following properties.
|
||||
|
||||
Required properties:
|
||||
- compatible: Can be "rockchip,rk3288-gmac".
|
||||
- reg: addresses and length of the register sets for the device.
|
||||
- interrupts: Should contain the GMAC interrupts.
|
||||
- interrupt-names: Should contain the interrupt names "macirq".
|
||||
- rockchip,grf: phandle to the syscon grf used to control speed and mode.
|
||||
- clocks: <&cru SCLK_MAC>: clock selector for main clock, from PLL or PHY.
|
||||
<&cru SCLK_MAC_PLL>: PLL clock for SCLK_MAC
|
||||
<&cru SCLK_MAC_RX>: clock gate for RX
|
||||
<&cru SCLK_MAC_TX>: clock gate for TX
|
||||
<&cru SCLK_MACREF>: clock gate for RMII referce clock
|
||||
<&cru SCLK_MACREF_OUT> clock gate for RMII reference clock output
|
||||
<&cru ACLK_GMAC>: AXI clock gate for GMAC
|
||||
<&cru PCLK_GMAC>: APB clock gate for GMAC
|
||||
- clock-names: One name for each entry in the clocks property.
|
||||
- phy-mode: See ethernet.txt file in the same directory.
|
||||
- pinctrl-names: Names corresponding to the numbered pinctrl states.
|
||||
- pinctrl-0: pin-control mode. can be <&rgmii_pins> or <&rmii_pins>.
|
||||
- clock_in_out: For RGMII, it must be "input", means main clock(125MHz)
|
||||
is not sourced from SoC's PLL, but input from PHY; For RMII, "input" means
|
||||
PHY provides the reference clock(50MHz), "output" means GMAC provides the
|
||||
reference clock.
|
||||
- snps,reset-gpio gpio number for phy reset.
|
||||
- snps,reset-active-low boolean flag to indicate if phy reset is active low.
|
||||
- assigned-clocks: main clock, should be <&cru SCLK_MAC>;
|
||||
- assigned-clock-parents = parent of main clock.
|
||||
can be <&ext_gmac> or <&cru SCLK_MAC_PLL>.
|
||||
|
||||
Optional properties:
|
||||
- tx_delay: Delay value for TXD timing. Range value is 0~0x7F, 0x30 as default.
|
||||
- rx_delay: Delay value for RXD timing. Range value is 0~0x7F, 0x10 as default.
|
||||
- phy-supply: phandle to a regulator if the PHY needs one
|
||||
|
||||
Example:
|
||||
|
||||
gmac: ethernet@ff290000 {
|
||||
compatible = "rockchip,rk3288-gmac";
|
||||
reg = <0xff290000 0x10000>;
|
||||
interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "macirq";
|
||||
rockchip,grf = <&grf>;
|
||||
clocks = <&cru SCLK_MAC>,
|
||||
<&cru SCLK_MAC_RX>, <&cru SCLK_MAC_TX>,
|
||||
<&cru SCLK_MACREF>, <&cru SCLK_MACREF_OUT>,
|
||||
<&cru ACLK_GMAC>, <&cru PCLK_GMAC>;
|
||||
clock-names = "stmmaceth",
|
||||
"mac_clk_rx", "mac_clk_tx",
|
||||
"clk_mac_ref", "clk_mac_refout",
|
||||
"aclk_mac", "pclk_mac";
|
||||
phy-mode = "rgmii";
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&rgmii_pins /*&rmii_pins*/>;
|
||||
|
||||
clock_in_out = "input";
|
||||
snps,reset-gpio = <&gpio4 7 0>;
|
||||
snps,reset-active-low;
|
||||
|
||||
assigned-clocks = <&cru SCLK_MAC>;
|
||||
assigned-clock-parents = <&ext_gmac>;
|
||||
tx_delay = <0x30>;
|
||||
rx_delay = <0x10>;
|
||||
|
||||
status = "ok";
|
||||
};
|
||||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче