Merge branch 'fixes-base' into fixes
James Bottomley
commit
6ea7e3873e
1
CREDITS
1
CREDITS
|
|
@ -3054,6 +3054,7 @@ D: PLX USB338x driver
|
|||
D: PCA9634 driver
|
||||
D: Option GTM671WFS
|
||||
D: Fintek F81216A
|
||||
D: AD5761 iio driver
|
||||
D: Various kernel hacks
|
||||
S: Qtechnology A/S
|
||||
S: Valby Langgade 142
|
||||
|
|
|
|||
|
|
@ -1,29 +0,0 @@
|
|||
rfkill - radio frequency (RF) connector kill switch support
|
||||
|
||||
For details to this subsystem look at Documentation/rfkill.txt.
|
||||
|
||||
What: /sys/class/rfkill/rfkill[0-9]+/state
|
||||
Date: 09-Jul-2007
|
||||
KernelVersion v2.6.22
|
||||
Contact: linux-wireless@vger.kernel.org
|
||||
Description: Current state of the transmitter.
|
||||
This file is deprecated and scheduled to be removed in 2014,
|
||||
because its not possible to express the 'soft and hard block'
|
||||
state of the rfkill driver.
|
||||
Values: A numeric value.
|
||||
0: RFKILL_STATE_SOFT_BLOCKED
|
||||
transmitter is turned off by software
|
||||
1: RFKILL_STATE_UNBLOCKED
|
||||
transmitter is (potentially) active
|
||||
2: RFKILL_STATE_HARD_BLOCKED
|
||||
transmitter is forced off by something outside of
|
||||
the driver's control.
|
||||
|
||||
What: /sys/class/rfkill/rfkill[0-9]+/claim
|
||||
Date: 09-Jul-2007
|
||||
KernelVersion v2.6.22
|
||||
Contact: linux-wireless@vger.kernel.org
|
||||
Description: This file is deprecated because there no longer is a way to
|
||||
claim just control over a single rfkill instance.
|
||||
This file is scheduled to be removed in 2012.
|
||||
Values: 0: Kernel handles events
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
What: /sys/class/gpio/
|
||||
Date: July 2008
|
||||
KernelVersion: 2.6.27
|
||||
Contact: David Brownell <dbrownell@users.sourceforge.net>
|
||||
Contact: Linus Walleij <linusw@kernel.org>
|
||||
Description:
|
||||
|
||||
As a Kconfig option, individual GPIO signals may be accessed from
|
||||
|
|
@ -26,3 +26,5 @@ Description:
|
|||
/label ... (r/o) descriptive, not necessarily unique
|
||||
/ngpio ... (r/o) number of GPIOs; numbered N to N + (ngpio - 1)
|
||||
|
||||
This ABI is deprecated and will be removed after 2020. It is
|
||||
replaced with the GPIO character device.
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
rfkill - radio frequency (RF) connector kill switch support
|
||||
|
||||
For details to this subsystem look at Documentation/rfkill.txt.
|
||||
|
||||
What: /sys/class/rfkill/rfkill[0-9]+/claim
|
||||
Date: 09-Jul-2007
|
||||
KernelVersion v2.6.22
|
||||
Contact: linux-wireless@vger.kernel.org
|
||||
Description: This file was deprecated because there no longer was a way to
|
||||
claim just control over a single rfkill instance.
|
||||
This file was scheduled to be removed in 2012, and was removed
|
||||
in 2016.
|
||||
Values: 0: Kernel handles events
|
||||
|
|
@ -100,4 +100,5 @@ Description:
|
|||
|
||||
Users: libraw1394
|
||||
libdc1394
|
||||
tools like jujuutils, fwhack, ...
|
||||
libhinawa
|
||||
tools like linux-firewire-utils, fwhack, ...
|
||||
|
|
|
|||
|
|
@ -27,3 +27,17 @@ Description: The mapping of which primary/sub channels are bound to which
|
|||
Virtual Processors.
|
||||
Format: <channel's child_relid:the bound cpu's number>
|
||||
Users: tools/hv/lsvmbus
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/device
|
||||
Date: Dec. 2015
|
||||
KernelVersion: 4.5
|
||||
Contact: K. Y. Srinivasan <kys@microsoft.com>
|
||||
Description: The 16 bit device ID of the device
|
||||
Users: tools/hv/lsvmbus and user level RDMA libraries
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/vendor
|
||||
Date: Dec. 2015
|
||||
KernelVersion: 4.5
|
||||
Contact: K. Y. Srinivasan <kys@microsoft.com>
|
||||
Description: The 16 bit vendor ID of the device
|
||||
Users: tools/hv/lsvmbus and user level RDMA libraries
|
||||
|
|
|
|||
|
|
@ -2,9 +2,8 @@ rfkill - radio frequency (RF) connector kill switch support
|
|||
|
||||
For details to this subsystem look at Documentation/rfkill.txt.
|
||||
|
||||
For the deprecated /sys/class/rfkill/*/state and
|
||||
/sys/class/rfkill/*/claim knobs of this interface look in
|
||||
Documentation/ABI/obsolete/sysfs-class-rfkill.
|
||||
For the deprecated /sys/class/rfkill/*/claim knobs of this interface look in
|
||||
Documentation/ABI/removed/sysfs-class-rfkill.
|
||||
|
||||
What: /sys/class/rfkill
|
||||
Date: 09-Jul-2007
|
||||
|
|
@ -42,6 +41,28 @@ Values: A numeric value.
|
|||
1: true
|
||||
|
||||
|
||||
What: /sys/class/rfkill/rfkill[0-9]+/state
|
||||
Date: 09-Jul-2007
|
||||
KernelVersion v2.6.22
|
||||
Contact: linux-wireless@vger.kernel.org
|
||||
Description: Current state of the transmitter.
|
||||
This file was scheduled to be removed in 2014, but due to its
|
||||
large number of users it will be sticking around for a bit
|
||||
longer. Despite it being marked as stabe, the newer "hard" and
|
||||
"soft" interfaces should be preffered, since it is not possible
|
||||
to express the 'soft and hard block' state of the rfkill driver
|
||||
through this interface. There will likely be another attempt to
|
||||
remove it in the future.
|
||||
Values: A numeric value.
|
||||
0: RFKILL_STATE_SOFT_BLOCKED
|
||||
transmitter is turned off by software
|
||||
1: RFKILL_STATE_UNBLOCKED
|
||||
transmitter is (potentially) active
|
||||
2: RFKILL_STATE_HARD_BLOCKED
|
||||
transmitter is forced off by something outside of
|
||||
the driver's control.
|
||||
|
||||
|
||||
What: /sys/class/rfkill/rfkill[0-9]+/hard
|
||||
Date: 12-March-2010
|
||||
KernelVersion v2.6.34
|
||||
|
|
|
|||
|
|
@ -0,0 +1,87 @@
|
|||
What: /sys/fs/orangefs/perf_counters/*
|
||||
Date: Jun 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
Counters and settings for various caches.
|
||||
Read only.
|
||||
|
||||
|
||||
What: /sys/fs/orangefs/perf_counter_reset
|
||||
Date: June 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
echo a 0 or a 1 into perf_counter_reset to
|
||||
reset all the counters in
|
||||
/sys/fs/orangefs/perf_counters
|
||||
except ones with PINT_PERF_PRESERVE set.
|
||||
|
||||
|
||||
What: /sys/fs/orangefs/perf_time_interval_secs
|
||||
Date: Jun 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
Length of perf counter intervals in
|
||||
seconds.
|
||||
|
||||
|
||||
What: /sys/fs/orangefs/perf_history_size
|
||||
Date: Jun 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
The perf_counters cache statistics have N, or
|
||||
perf_history_size, samples. The default is
|
||||
one.
|
||||
|
||||
Every perf_time_interval_secs the (first)
|
||||
samples are reset.
|
||||
|
||||
If N is greater than one, the "current" set
|
||||
of samples is reset, and the samples from the
|
||||
other N-1 intervals remain available.
|
||||
|
||||
|
||||
What: /sys/fs/orangefs/op_timeout_secs
|
||||
Date: Jun 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
Service operation timeout in seconds.
|
||||
|
||||
|
||||
What: /sys/fs/orangefs/slot_timeout_secs
|
||||
Date: Jun 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
"Slot" timeout in seconds. A "slot"
|
||||
is an indexed buffer in the shared
|
||||
memory segment used for communication
|
||||
between the kernel module and userspace.
|
||||
Slots are requested and waited for,
|
||||
the wait times out after slot_timeout_secs.
|
||||
|
||||
|
||||
What: /sys/fs/orangefs/acache/*
|
||||
Date: Jun 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
Attribute cache configurable settings.
|
||||
|
||||
|
||||
What: /sys/fs/orangefs/ncache/*
|
||||
Date: Jun 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
Name cache configurable settings.
|
||||
|
||||
|
||||
What: /sys/fs/orangefs/capcache/*
|
||||
Date: Jun 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
Capability cache configurable settings.
|
||||
|
||||
|
||||
What: /sys/fs/orangefs/ccache/*
|
||||
Date: Jun 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
Credential cache configurable settings.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
What: /dev/gpiochip[0-9]+
|
||||
Date: November 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: linux-gpio@vger.kernel.org
|
||||
Description:
|
||||
The character device files /dev/gpiochip* are the interface
|
||||
between GPIO chips and userspace.
|
||||
|
||||
The ioctl(2)-based ABI is defined and documented in
|
||||
[include/uapi]<linux/gpio.h>.
|
||||
|
||||
The following file operations are supported:
|
||||
|
||||
open(2)
|
||||
Currently the only useful flags are O_RDWR.
|
||||
|
||||
ioctl(2)
|
||||
Initiate various actions.
|
||||
See the inline documentation in [include/uapi]<linux/gpio.h>
|
||||
for descriptions of all ioctls.
|
||||
|
||||
close(2)
|
||||
Stops and free up the I/O contexts that was associated
|
||||
with the file descriptor.
|
||||
|
||||
Users: TBD
|
||||
|
|
@ -27,6 +27,7 @@ Description:
|
|||
|
||||
base: func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
|
||||
[FIRMWARE_CHECK]
|
||||
[KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
|
||||
mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
|
||||
[[^]MAY_EXEC]
|
||||
fsmagic:= hex value
|
||||
|
|
|
|||
|
|
@ -496,8 +496,11 @@ Description:
|
|||
1kohm_to_gnd: connected to ground via an 1kOhm resistor,
|
||||
6kohm_to_gnd: connected to ground via a 6kOhm resistor,
|
||||
20kohm_to_gnd: connected to ground via a 20kOhm resistor,
|
||||
90kohm_to_gnd: connected to ground via a 90kOhm resistor,
|
||||
100kohm_to_gnd: connected to ground via an 100kOhm resistor,
|
||||
125kohm_to_gnd: connected to ground via an 125kOhm resistor,
|
||||
500kohm_to_gnd: connected to ground via a 500kOhm resistor,
|
||||
640kohm_to_gnd: connected to ground via a 640kOhm resistor,
|
||||
three_state: left floating.
|
||||
For a list of available output power down options read
|
||||
outX_powerdown_mode_available. If Y is not present the
|
||||
|
|
@ -1491,3 +1494,10 @@ Description:
|
|||
This ABI is especially applicable for humidity sensors
|
||||
to heatup the device and get rid of any condensation
|
||||
in some humidity environment
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_ph_raw
|
||||
KernelVersion: 4.5
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Raw (unscaled no offset etc.) pH reading of a substance as a negative
|
||||
base-10 logarithm of hydrodium ions in a litre of water.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,54 @@
|
|||
What: /sys/bus/iio/devices/iio:deviceX/tia_resistanceY
|
||||
/sys/bus/iio/devices/iio:deviceX/tia_capacitanceY
|
||||
Date: December 2015
|
||||
KernelVersion:
|
||||
Contact: Andrew F. Davis <afd@ti.com>
|
||||
Description:
|
||||
Get and set the resistance and the capacitance settings for the
|
||||
Transimpedance Amplifier. Y is 1 for Rf1 and Cf1, Y is 2 for
|
||||
Rf2 and Cf2 values.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/tia_separate_en
|
||||
Date: December 2015
|
||||
KernelVersion:
|
||||
Contact: Andrew F. Davis <afd@ti.com>
|
||||
Description:
|
||||
Enable or disable separate settings for the TransImpedance
|
||||
Amplifier above, when disabled both values are set by the
|
||||
first channel.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_ledY_raw
|
||||
/sys/bus/iio/devices/iio:deviceX/in_intensity_ledY_ambient_raw
|
||||
Date: December 2015
|
||||
KernelVersion:
|
||||
Contact: Andrew F. Davis <afd@ti.com>
|
||||
Description:
|
||||
Get measured values from the ADC for these stages. Y is the
|
||||
specific LED number. The values are expressed in 24-bit twos
|
||||
complement.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_ledY-ledY_ambient_raw
|
||||
Date: December 2015
|
||||
KernelVersion:
|
||||
Contact: Andrew F. Davis <afd@ti.com>
|
||||
Description:
|
||||
Get differential values from the ADC for these stages. Y is the
|
||||
specific LED number. The values are expressed in 24-bit twos
|
||||
complement for the specified LEDs.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_current_ledY_offset
|
||||
/sys/bus/iio/devices/iio:deviceX/out_current_ledY_ambient_offset
|
||||
Date: December 2015
|
||||
KernelVersion:
|
||||
Contact: Andrew F. Davis <afd@ti.com>
|
||||
Description:
|
||||
Get and set the offset cancellation DAC setting for these
|
||||
stages. The values are expressed in 5-bit sign-magnitude.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_current_ledY_raw
|
||||
Date: December 2015
|
||||
KernelVersion:
|
||||
Contact: Andrew F. Davis <afd@ti.com>
|
||||
Description:
|
||||
Get and set the LED current for the specified LED. Y is the
|
||||
specific LED number.
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
What: /sys/bus/iio/devices/iio:deviceX/meas_conf
|
||||
What: /sys/bus/iio/devices/iio:deviceX/meas_conf_available
|
||||
KernelVersion: 4.5
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Current configuration and available configurations
|
||||
for the bias current.
|
||||
normal - Normal measurement configurations (default)
|
||||
positivebias - Positive bias configuration
|
||||
negativebias - Negative bias configuration
|
||||
disabled - Only available on HMC5983. Disables magnetic
|
||||
sensor and enables temperature sensor.
|
||||
Note: The effect of this configuration may vary
|
||||
according to the device. For exact documentation
|
||||
check the device's datasheet.
|
||||
|
|
@ -5,3 +5,12 @@ Description:
|
|||
Specifies the hardware conversion mode used. The three
|
||||
available modes are "normal", "high-speed" and "low-power",
|
||||
where the last is the default mode.
|
||||
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_conversion_mode
|
||||
KernelVersion: 4.6
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Specifies the hardware conversion mode used within DAC.
|
||||
The two available modes are "high-power" and "low-power",
|
||||
where "low-power" mode is the default mode.
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ Description: read only
|
|||
Decimal value of the Per Process MMIO space length.
|
||||
Users: https://github.com/ibm-capi/libcxl
|
||||
|
||||
What: /sys/class/cxl/<afu>m/pp_mmio_off
|
||||
What: /sys/class/cxl/<afu>m/pp_mmio_off (not in a guest)
|
||||
Date: September 2014
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read only
|
||||
|
|
@ -183,7 +183,7 @@ Description: read only
|
|||
Identifies the revision level of the PSL.
|
||||
Users: https://github.com/ibm-capi/libcxl
|
||||
|
||||
What: /sys/class/cxl/<card>/base_image
|
||||
What: /sys/class/cxl/<card>/base_image (not in a guest)
|
||||
Date: September 2014
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read only
|
||||
|
|
@ -193,7 +193,7 @@ Description: read only
|
|||
during the initial program load.
|
||||
Users: https://github.com/ibm-capi/libcxl
|
||||
|
||||
What: /sys/class/cxl/<card>/image_loaded
|
||||
What: /sys/class/cxl/<card>/image_loaded (not in a guest)
|
||||
Date: September 2014
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read only
|
||||
|
|
@ -201,7 +201,7 @@ Description: read only
|
|||
onto the card.
|
||||
Users: https://github.com/ibm-capi/libcxl
|
||||
|
||||
What: /sys/class/cxl/<card>/load_image_on_perst
|
||||
What: /sys/class/cxl/<card>/load_image_on_perst (not in a guest)
|
||||
Date: December 2014
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read/write
|
||||
|
|
@ -224,7 +224,7 @@ Description: write only
|
|||
to reload the FPGA depending on load_image_on_perst.
|
||||
Users: https://github.com/ibm-capi/libcxl
|
||||
|
||||
What: /sys/class/cxl/<card>/perst_reloads_same_image
|
||||
What: /sys/class/cxl/<card>/perst_reloads_same_image (not in a guest)
|
||||
Date: July 2015
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read/write
|
||||
|
|
|
|||
|
|
@ -1,4 +1,20 @@
|
|||
|
||||
What: /sys/class/net/<iface>/batman-adv/throughput_override
|
||||
Date: Feb 2014
|
||||
Contact: Antonio Quartulli <antonio@meshcoding.com>
|
||||
description:
|
||||
Defines the throughput value to be used by B.A.T.M.A.N. V
|
||||
when estimating the link throughput using this interface.
|
||||
If the value is set to 0 then batman-adv will try to
|
||||
estimate the throughput by itself.
|
||||
|
||||
What: /sys/class/net/<iface>/batman-adv/elp_interval
|
||||
Date: Feb 2014
|
||||
Contact: Linus Lüssing <linus.luessing@web.de>
|
||||
Description:
|
||||
Defines the interval in milliseconds in which batman
|
||||
sends its probing packets for link quality measurements.
|
||||
|
||||
What: /sys/class/net/<iface>/batman-adv/iface_status
|
||||
Date: May 2010
|
||||
Contact: Marek Lindner <mareklindner@neomailbox.ch>
|
||||
|
|
@ -12,4 +28,3 @@ Description:
|
|||
The /sys/class/net/<iface>/batman-adv/mesh_iface file
|
||||
displays the batman mesh interface this <iface>
|
||||
currently is associated with.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,15 @@
|
|||
What: /sys/class/rc/rcN/wakeup_data
|
||||
Date: Mar 2016
|
||||
KernelVersion: 4.6
|
||||
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
Description:
|
||||
Reading this file returns the stored CIR wakeup sequence.
|
||||
It starts with a pulse, followed by a space, pulse etc.
|
||||
All values are in microseconds.
|
||||
The same format can be used to store a wakeup sequence
|
||||
in the Nuvoton chip by writing to this file.
|
||||
|
||||
Note: Some systems reset the stored wakeup sequence to a
|
||||
factory default on each boot. On such systems store the
|
||||
wakeup sequence in a file and set it on boot using e.g.
|
||||
a udev rule.
|
||||
|
|
@ -271,3 +271,72 @@ Description: Parameters for the CPU cache attributes
|
|||
- WriteBack: data is written only to the cache line and
|
||||
the modified cache line is written to main
|
||||
memory only when it is replaced
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats
|
||||
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/turbo_stat
|
||||
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/sub_turbo_stat
|
||||
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/unthrottle
|
||||
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/powercap
|
||||
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/overtemp
|
||||
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/supply_fault
|
||||
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/overcurrent
|
||||
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/occ_reset
|
||||
Date: March 2016
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
|
||||
Description: POWERNV CPUFreq driver's frequency throttle stats directory and
|
||||
attributes
|
||||
|
||||
'cpuX/cpufreq/throttle_stats' directory contains the CPU frequency
|
||||
throttle stat attributes for the chip. The throttle stats of a cpu
|
||||
is common across all the cpus belonging to a chip. Below are the
|
||||
throttle attributes exported in the 'throttle_stats' directory:
|
||||
|
||||
- turbo_stat : This file gives the total number of times the max
|
||||
frequency is throttled to lower frequency in turbo (at and above
|
||||
nominal frequency) range of frequencies.
|
||||
|
||||
- sub_turbo_stat : This file gives the total number of times the
|
||||
max frequency is throttled to lower frequency in sub-turbo(below
|
||||
nominal frequency) range of frequencies.
|
||||
|
||||
- unthrottle : This file gives the total number of times the max
|
||||
frequency is unthrottled after being throttled.
|
||||
|
||||
- powercap : This file gives the total number of times the max
|
||||
frequency is throttled due to 'Power Capping'.
|
||||
|
||||
- overtemp : This file gives the total number of times the max
|
||||
frequency is throttled due to 'CPU Over Temperature'.
|
||||
|
||||
- supply_fault : This file gives the total number of times the
|
||||
max frequency is throttled due to 'Power Supply Failure'.
|
||||
|
||||
- overcurrent : This file gives the total number of times the
|
||||
max frequency is throttled due to 'Overcurrent'.
|
||||
|
||||
- occ_reset : This file gives the total number of times the max
|
||||
frequency is throttled due to 'OCC Reset'.
|
||||
|
||||
The sysfs attributes representing different throttle reasons like
|
||||
powercap, overtemp, supply_fault, overcurrent and occ_reset map to
|
||||
the reasons provided by OCC firmware for throttling the frequency.
|
||||
|
||||
What: /sys/devices/system/cpu/cpufreq/policyX/throttle_stats
|
||||
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/turbo_stat
|
||||
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/sub_turbo_stat
|
||||
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/unthrottle
|
||||
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/powercap
|
||||
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/overtemp
|
||||
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/supply_fault
|
||||
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/overcurrent
|
||||
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/occ_reset
|
||||
Date: March 2016
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
|
||||
Description: POWERNV CPUFreq driver's frequency throttle stats directory and
|
||||
attributes
|
||||
|
||||
'policyX/throttle_stats' directory and all the attributes are same as
|
||||
the /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats directory and
|
||||
attributes which give the frequency throttle information of the chip.
|
||||
|
|
|
|||
|
|
@ -179,3 +179,19 @@ Description: This file controls the USB 3 functionality, valid values are:
|
|||
Note that toggling this value requires a reboot for changes to
|
||||
take effect.
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/cooling_method
|
||||
Date: 2016
|
||||
KernelVersion: 4.6
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file controls the Cooling Method feature.
|
||||
Reading this file prints two values, the first is the actual cooling method
|
||||
and the second is the maximum cooling method supported.
|
||||
When the maximum cooling method is ONE, valid values are:
|
||||
* 0 -> Maximum Performance
|
||||
* 1 -> Battery Optimized
|
||||
When the maximum cooling method is TWO, valid values are:
|
||||
* 0 -> Maximum Performance
|
||||
* 1 -> Performance
|
||||
* 2 -> Battery Optimized
|
||||
Users: KToshiba
|
||||
|
|
|
|||
|
|
@ -0,0 +1,100 @@
|
|||
What: /sys/firmware/qemu_fw_cfg/
|
||||
Date: August 2015
|
||||
Contact: Gabriel Somlo <somlo@cmu.edu>
|
||||
Description:
|
||||
Several different architectures supported by QEMU (x86, arm,
|
||||
sun4*, ppc/mac) are provisioned with a firmware configuration
|
||||
(fw_cfg) device, originally intended as a way for the host to
|
||||
provide configuration data to the guest firmware. Starting
|
||||
with QEMU v2.4, arbitrary fw_cfg file entries may be specified
|
||||
by the user on the command line, which makes fw_cfg additionally
|
||||
useful as an out-of-band, asynchronous mechanism for providing
|
||||
configuration data to the guest userspace.
|
||||
|
||||
The authoritative guest-side hardware interface documentation
|
||||
to the fw_cfg device can be found in "docs/specs/fw_cfg.txt"
|
||||
in the QEMU source tree.
|
||||
|
||||
=== SysFS fw_cfg Interface ===
|
||||
|
||||
The fw_cfg sysfs interface described in this document is only
|
||||
intended to display discoverable blobs (i.e., those registered
|
||||
with the file directory), as there is no way to determine the
|
||||
presence or size of "legacy" blobs (with selector keys between
|
||||
0x0002 and 0x0018) programmatically.
|
||||
|
||||
All fw_cfg information is shown under:
|
||||
|
||||
/sys/firmware/qemu_fw_cfg/
|
||||
|
||||
The only legacy blob displayed is the fw_cfg device revision:
|
||||
|
||||
/sys/firmware/qemu_fw_cfg/rev
|
||||
|
||||
--- Discoverable fw_cfg blobs by selector key ---
|
||||
|
||||
All discoverable blobs listed in the fw_cfg file directory are
|
||||
displayed as entries named after their unique selector key
|
||||
value, e.g.:
|
||||
|
||||
/sys/firmware/qemu_fw_cfg/by_key/32
|
||||
/sys/firmware/qemu_fw_cfg/by_key/33
|
||||
/sys/firmware/qemu_fw_cfg/by_key/34
|
||||
...
|
||||
|
||||
Each such fw_cfg sysfs entry has the following values exported
|
||||
as attributes:
|
||||
|
||||
name : The 56-byte nul-terminated ASCII string used as the
|
||||
blob's 'file name' in the fw_cfg directory.
|
||||
size : The length of the blob, as given in the fw_cfg
|
||||
directory.
|
||||
key : The value of the blob's selector key as given in the
|
||||
fw_cfg directory. This value is the same as used in
|
||||
the parent directory name.
|
||||
raw : The raw bytes of the blob, obtained by selecting the
|
||||
entry via the control register, and reading a number
|
||||
of bytes equal to the blob size from the data
|
||||
register.
|
||||
|
||||
--- Listing fw_cfg blobs by file name ---
|
||||
|
||||
While the fw_cfg device does not impose any specific naming
|
||||
convention on the blobs registered in the file directory,
|
||||
QEMU developers have traditionally used path name semantics
|
||||
to give each blob a descriptive name. For example:
|
||||
|
||||
"bootorder"
|
||||
"genroms/kvmvapic.bin"
|
||||
"etc/e820"
|
||||
"etc/boot-fail-wait"
|
||||
"etc/system-states"
|
||||
"etc/table-loader"
|
||||
"etc/acpi/rsdp"
|
||||
"etc/acpi/tables"
|
||||
"etc/smbios/smbios-tables"
|
||||
"etc/smbios/smbios-anchor"
|
||||
...
|
||||
|
||||
In addition to the listing by unique selector key described
|
||||
above, the fw_cfg sysfs driver also attempts to build a tree
|
||||
of directories matching the path name components of fw_cfg
|
||||
blob names, ending in symlinks to the by_key entry for each
|
||||
"basename", as illustrated below (assume current directory is
|
||||
/sys/firmware):
|
||||
|
||||
qemu_fw_cfg/by_name/bootorder -> ../by_key/38
|
||||
qemu_fw_cfg/by_name/etc/e820 -> ../../by_key/35
|
||||
qemu_fw_cfg/by_name/etc/acpi/rsdp -> ../../../by_key/41
|
||||
...
|
||||
|
||||
Construction of the directory tree and symlinks is done on a
|
||||
"best-effort" basis, as there is no guarantee that components
|
||||
of fw_cfg blob names are always "well behaved". I.e., there is
|
||||
the possibility that a symlink (basename) will conflict with
|
||||
a dirname component of another fw_cfg blob, in which case the
|
||||
creation of the offending /sys/firmware/qemu_fw_cfg/by_name
|
||||
entry will be skipped.
|
||||
|
||||
The authoritative list of entries will continue to be found
|
||||
under the /sys/firmware/qemu_fw_cfg/by_key directory.
|
||||
|
|
@ -98,3 +98,17 @@ Date: October 2015
|
|||
Contact: "Chao Yu" <chao2.yu@samsung.com>
|
||||
Description:
|
||||
Controls the count of nid pages to be readaheaded.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/dirty_nats_ratio
|
||||
Date: January 2016
|
||||
Contact: "Chao Yu" <chao2.yu@samsung.com>
|
||||
Description:
|
||||
Controls dirty nat entries ratio threshold, if current
|
||||
ratio exceeds configured threshold, checkpoint will
|
||||
be triggered for flushing dirty nat entries.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/lifetime_write_kbytes
|
||||
Date: January 2016
|
||||
Contact: "Shuoran Liu" <liushuoran@huawei.com>
|
||||
Description:
|
||||
Shows total written kbytes issued to disk.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,97 @@
|
|||
What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority
|
||||
/sys/devices/platform/QCOM8060:*/chanops/chan*/priority
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
|
||||
Description:
|
||||
Contains either 0 or 1 and indicates if the DMA channel is a
|
||||
low priority (0) or high priority (1) channel.
|
||||
|
||||
What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/weight
|
||||
/sys/devices/platform/QCOM8060:*/chanops/chan*/weight
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
|
||||
Description:
|
||||
Contains 0..15 and indicates the weight of the channel among
|
||||
equal priority channels during round robin scheduling.
|
||||
|
||||
What: /sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles
|
||||
/sys/devices/platform/QCOM8060:*/chreset_timeout_cycles
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
|
||||
Description:
|
||||
Contains the platform specific cycle value to wait after a
|
||||
reset command is issued. If the value is chosen too short,
|
||||
then the HW will issue a reset failure interrupt. The value
|
||||
is platform specific and should not be changed without
|
||||
consultance.
|
||||
|
||||
What: /sys/devices/platform/hidma-mgmt*/dma_channels
|
||||
/sys/devices/platform/QCOM8060:*/dma_channels
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
|
||||
Description:
|
||||
Contains the number of dma channels supported by one instance
|
||||
of HIDMA hardware. The value may change from chip to chip.
|
||||
|
||||
What: /sys/devices/platform/hidma-mgmt*/hw_version_major
|
||||
/sys/devices/platform/QCOM8060:*/hw_version_major
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
|
||||
Description:
|
||||
Version number major for the hardware.
|
||||
|
||||
What: /sys/devices/platform/hidma-mgmt*/hw_version_minor
|
||||
/sys/devices/platform/QCOM8060:*/hw_version_minor
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
|
||||
Description:
|
||||
Version number minor for the hardware.
|
||||
|
||||
What: /sys/devices/platform/hidma-mgmt*/max_rd_xactions
|
||||
/sys/devices/platform/QCOM8060:*/max_rd_xactions
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
|
||||
Description:
|
||||
Contains a value between 0 and 31. Maximum number of
|
||||
read transactions that can be issued back to back.
|
||||
Choosing a higher number gives better performance but
|
||||
can also cause performance reduction to other peripherals
|
||||
sharing the same bus.
|
||||
|
||||
What: /sys/devices/platform/hidma-mgmt*/max_read_request
|
||||
/sys/devices/platform/QCOM8060:*/max_read_request
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
|
||||
Description:
|
||||
Size of each read request. The value needs to be a power
|
||||
of two and can be between 128 and 1024.
|
||||
|
||||
What: /sys/devices/platform/hidma-mgmt*/max_wr_xactions
|
||||
/sys/devices/platform/QCOM8060:*/max_wr_xactions
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
|
||||
Description:
|
||||
Contains a value between 0 and 31. Maximum number of
|
||||
write transactions that can be issued back to back.
|
||||
Choosing a higher number gives better performance but
|
||||
can also cause performance reduction to other peripherals
|
||||
sharing the same bus.
|
||||
|
||||
|
||||
What: /sys/devices/platform/hidma-mgmt*/max_write_request
|
||||
/sys/devices/platform/QCOM8060:*/max_write_request
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
|
||||
Description:
|
||||
Size of each write request. The value needs to be a power
|
||||
of two and can be between 128 and 1024.
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
What: /sys/devices/platform/<i2c-demux-name>/cur_master
|
||||
Date: January 2016
|
||||
KernelVersion: 4.6
|
||||
Contact: Wolfram Sang <wsa@the-dreams.de>
|
||||
Description:
|
||||
|
||||
This file selects the active I2C master for a demultiplexed bus.
|
||||
|
||||
Write 0 there for the first master, 1 for the second etc. Reading the file will
|
||||
give you a list with the active master marked. Example from a Renesas Lager
|
||||
board:
|
||||
|
||||
root@Lager:~# cat /sys/devices/platform/i2c@8/cur_master
|
||||
* 0 - /i2c@9
|
||||
1 - /i2c@e6520000
|
||||
2 - /i2c@e6530000
|
||||
|
||||
root@Lager:~# echo 2 > /sys/devices/platform/i2c@8/cur_master
|
||||
|
||||
root@Lager:~# cat /sys/devices/platform/i2c@8/cur_master
|
||||
0 - /i2c@9
|
||||
1 - /i2c@e6520000
|
||||
* 2 - /i2c@e6530000
|
||||
|
|
@ -640,7 +640,7 @@ Things to avoid when using macros:
|
|||
do { \
|
||||
if (blah(x) < 0) \
|
||||
return -EBUGGERED; \
|
||||
} while(0)
|
||||
} while (0)
|
||||
|
||||
is a _very_ bad idea. It looks like a function call but exits the "calling"
|
||||
function; don't break the internal parsers of those who will read the code.
|
||||
|
|
|
|||
|
|
@ -100,3 +100,29 @@ allocated by dma_alloc_attrs() function from individual pages if it can
|
|||
be mapped as contiguous chunk into device dma address space. By
|
||||
specifying this attribute the allocated buffer is forced to be contiguous
|
||||
also in physical memory.
|
||||
|
||||
DMA_ATTR_ALLOC_SINGLE_PAGES
|
||||
---------------------------
|
||||
|
||||
This is a hint to the DMA-mapping subsystem that it's probably not worth
|
||||
the time to try to allocate memory to in a way that gives better TLB
|
||||
efficiency (AKA it's not worth trying to build the mapping out of larger
|
||||
pages). You might want to specify this if:
|
||||
- You know that the accesses to this memory won't thrash the TLB.
|
||||
You might know that the accesses are likely to be sequential or
|
||||
that they aren't sequential but it's unlikely you'll ping-pong
|
||||
between many addresses that are likely to be in different physical
|
||||
pages.
|
||||
- You know that the penalty of TLB misses while accessing the
|
||||
memory will be small enough to be inconsequential. If you are
|
||||
doing a heavy operation like decryption or decompression this
|
||||
might be the case.
|
||||
- You know that the DMA mapping is fairly transitory. If you expect
|
||||
the mapping to have a short lifetime then it may be worth it to
|
||||
optimize allocation (avoid coming up with large pages) instead of
|
||||
getting the slight performance win of larger pages.
|
||||
Setting this hint doesn't guarantee that you won't get huge pages, but it
|
||||
means that we won't try quite as hard to get them.
|
||||
|
||||
NOTE: At the moment DMA_ATTR_ALLOC_SINGLE_PAGES is only implemented on ARM,
|
||||
though ARM64 patches will likely be posted soon.
|
||||
|
|
|
|||
|
|
@ -348,10 +348,7 @@
|
|||
<para>type:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>blkcipher for synchronous block ciphers</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>ablkcipher for asynchronous block ciphers</para>
|
||||
<para>skcipher for symmetric key ciphers</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>cipher for single block ciphers that may be used with
|
||||
|
|
@ -484,6 +481,9 @@
|
|||
<listitem>
|
||||
<para>CRYPTO_ALG_TYPE_RNG Random Number Generation</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>CRYPTO_ALG_TYPE_AKCIPHER Asymmetric cipher</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>CRYPTO_ALG_TYPE_PCOMPRESS Enhanced version of
|
||||
CRYPTO_ALG_TYPE_COMPRESS allowing for segmented compression /
|
||||
|
|
@ -597,7 +597,7 @@ kernel crypto API | IPSEC Layer
|
|||
v v
|
||||
+-----------+ +-----------+
|
||||
| | | |
|
||||
| ablkcipher| | ahash |
|
||||
| skcipher | | ahash |
|
||||
| (ctr) | ---+ | (ghash) |
|
||||
+-----------+ | +-----------+
|
||||
|
|
||||
|
|
@ -658,7 +658,7 @@ kernel crypto API | IPSEC Layer
|
|||
|
||||
<listitem>
|
||||
<para>
|
||||
The GCM AEAD cipher type implementation now invokes the ABLKCIPHER API
|
||||
The GCM AEAD cipher type implementation now invokes the SKCIPHER API
|
||||
with the instantiated CTR(AES) cipher handle.
|
||||
</para>
|
||||
|
||||
|
|
@ -669,7 +669,7 @@ kernel crypto API | IPSEC Layer
|
|||
</para>
|
||||
|
||||
<para>
|
||||
That means that the ABLKCIPHER implementation of CTR(AES) only
|
||||
That means that the SKCIPHER implementation of CTR(AES) only
|
||||
implements the CTR block chaining mode. After performing the block
|
||||
chaining operation, the CIPHER implementation of AES is invoked.
|
||||
</para>
|
||||
|
|
@ -677,7 +677,7 @@ kernel crypto API | IPSEC Layer
|
|||
|
||||
<listitem>
|
||||
<para>
|
||||
The ABLKCIPHER of CTR(AES) now invokes the CIPHER API with the AES
|
||||
The SKCIPHER of CTR(AES) now invokes the CIPHER API with the AES
|
||||
cipher handle to encrypt one block.
|
||||
</para>
|
||||
</listitem>
|
||||
|
|
@ -706,7 +706,7 @@ kernel crypto API | IPSEC Layer
|
|||
<para>
|
||||
For example, CBC(AES) is implemented with cbc.c, and aes-generic.c. The
|
||||
ASCII art picture above applies as well with the difference that only
|
||||
step (4) is used and the ABLKCIPHER block chaining mode is CBC.
|
||||
step (4) is used and the SKCIPHER block chaining mode is CBC.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
|
|
@ -904,15 +904,14 @@ kernel crypto API | Caller
|
|||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Multi-Block Ciphers [BLKCIPHER] [ABLKCIPHER]</title>
|
||||
<sect1><title>Multi-Block Ciphers</title>
|
||||
<para>
|
||||
Example of transformations: cbc(aes), ecb(arc4), ...
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This section describes the multi-block cipher transformation
|
||||
implementations for both synchronous [BLKCIPHER] and
|
||||
asynchronous [ABLKCIPHER] case. The multi-block ciphers are
|
||||
implementations. The multi-block ciphers are
|
||||
used for transformations which operate on scatterlists of
|
||||
data supplied to the transformation functions. They output
|
||||
the result into a scatterlist of data as well.
|
||||
|
|
@ -921,16 +920,15 @@ kernel crypto API | Caller
|
|||
<sect2><title>Registration Specifics</title>
|
||||
|
||||
<para>
|
||||
The registration of [BLKCIPHER] or [ABLKCIPHER] algorithms
|
||||
The registration of multi-block cipher algorithms
|
||||
is one of the most standard procedures throughout the crypto API.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Note, if a cipher implementation requires a proper alignment
|
||||
of data, the caller should use the functions of
|
||||
crypto_blkcipher_alignmask() or crypto_ablkcipher_alignmask()
|
||||
respectively to identify a memory alignment mask. The kernel
|
||||
crypto API is able to process requests that are unaligned.
|
||||
crypto_skcipher_alignmask() to identify a memory alignment mask.
|
||||
The kernel crypto API is able to process requests that are unaligned.
|
||||
This implies, however, additional overhead as the kernel
|
||||
crypto API needs to perform the realignment of the data which
|
||||
may imply moving of data.
|
||||
|
|
@ -945,14 +943,13 @@ kernel crypto API | Caller
|
|||
|
||||
<para>
|
||||
Please refer to the single block cipher description for schematics
|
||||
of the block cipher usage. The usage patterns are exactly the same
|
||||
for [ABLKCIPHER] and [BLKCIPHER] as they are for plain [CIPHER].
|
||||
of the block cipher usage.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2><title>Specifics Of Asynchronous Multi-Block Cipher</title>
|
||||
<para>
|
||||
There are a couple of specifics to the [ABLKCIPHER] interface.
|
||||
There are a couple of specifics to the asynchronous interface.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -1692,7 +1689,28 @@ read(opfd, out, outlen);
|
|||
!Finclude/linux/crypto.h cipher_alg
|
||||
!Finclude/crypto/rng.h rng_alg
|
||||
</sect1>
|
||||
<sect1><title>Asynchronous Block Cipher API</title>
|
||||
<sect1><title>Symmetric Key Cipher API</title>
|
||||
!Pinclude/crypto/skcipher.h Symmetric Key Cipher API
|
||||
!Finclude/crypto/skcipher.h crypto_alloc_skcipher
|
||||
!Finclude/crypto/skcipher.h crypto_free_skcipher
|
||||
!Finclude/crypto/skcipher.h crypto_has_skcipher
|
||||
!Finclude/crypto/skcipher.h crypto_skcipher_ivsize
|
||||
!Finclude/crypto/skcipher.h crypto_skcipher_blocksize
|
||||
!Finclude/crypto/skcipher.h crypto_skcipher_setkey
|
||||
!Finclude/crypto/skcipher.h crypto_skcipher_reqtfm
|
||||
!Finclude/crypto/skcipher.h crypto_skcipher_encrypt
|
||||
!Finclude/crypto/skcipher.h crypto_skcipher_decrypt
|
||||
</sect1>
|
||||
<sect1><title>Symmetric Key Cipher Request Handle</title>
|
||||
!Pinclude/crypto/skcipher.h Symmetric Key Cipher Request Handle
|
||||
!Finclude/crypto/skcipher.h crypto_skcipher_reqsize
|
||||
!Finclude/crypto/skcipher.h skcipher_request_set_tfm
|
||||
!Finclude/crypto/skcipher.h skcipher_request_alloc
|
||||
!Finclude/crypto/skcipher.h skcipher_request_free
|
||||
!Finclude/crypto/skcipher.h skcipher_request_set_callback
|
||||
!Finclude/crypto/skcipher.h skcipher_request_set_crypt
|
||||
</sect1>
|
||||
<sect1><title>Asynchronous Block Cipher API - Deprecated</title>
|
||||
!Pinclude/linux/crypto.h Asynchronous Block Cipher API
|
||||
!Finclude/linux/crypto.h crypto_alloc_ablkcipher
|
||||
!Finclude/linux/crypto.h crypto_free_ablkcipher
|
||||
|
|
@ -1704,7 +1722,7 @@ read(opfd, out, outlen);
|
|||
!Finclude/linux/crypto.h crypto_ablkcipher_encrypt
|
||||
!Finclude/linux/crypto.h crypto_ablkcipher_decrypt
|
||||
</sect1>
|
||||
<sect1><title>Asynchronous Cipher Request Handle</title>
|
||||
<sect1><title>Asynchronous Cipher Request Handle - Deprecated</title>
|
||||
!Pinclude/linux/crypto.h Asynchronous Cipher Request Handle
|
||||
!Finclude/linux/crypto.h crypto_ablkcipher_reqsize
|
||||
!Finclude/linux/crypto.h ablkcipher_request_set_tfm
|
||||
|
|
@ -1733,10 +1751,9 @@ read(opfd, out, outlen);
|
|||
!Finclude/crypto/aead.h aead_request_free
|
||||
!Finclude/crypto/aead.h aead_request_set_callback
|
||||
!Finclude/crypto/aead.h aead_request_set_crypt
|
||||
!Finclude/crypto/aead.h aead_request_set_assoc
|
||||
!Finclude/crypto/aead.h aead_request_set_ad
|
||||
</sect1>
|
||||
<sect1><title>Synchronous Block Cipher API</title>
|
||||
<sect1><title>Synchronous Block Cipher API - Deprecated</title>
|
||||
!Pinclude/linux/crypto.h Synchronous Block Cipher API
|
||||
!Finclude/linux/crypto.h crypto_alloc_blkcipher
|
||||
!Finclude/linux/crypto.h crypto_free_blkcipher
|
||||
|
|
@ -1761,19 +1778,6 @@ read(opfd, out, outlen);
|
|||
!Finclude/linux/crypto.h crypto_cipher_setkey
|
||||
!Finclude/linux/crypto.h crypto_cipher_encrypt_one
|
||||
!Finclude/linux/crypto.h crypto_cipher_decrypt_one
|
||||
</sect1>
|
||||
<sect1><title>Synchronous Message Digest API</title>
|
||||
!Pinclude/linux/crypto.h Synchronous Message Digest API
|
||||
!Finclude/linux/crypto.h crypto_alloc_hash
|
||||
!Finclude/linux/crypto.h crypto_free_hash
|
||||
!Finclude/linux/crypto.h crypto_has_hash
|
||||
!Finclude/linux/crypto.h crypto_hash_blocksize
|
||||
!Finclude/linux/crypto.h crypto_hash_digestsize
|
||||
!Finclude/linux/crypto.h crypto_hash_init
|
||||
!Finclude/linux/crypto.h crypto_hash_update
|
||||
!Finclude/linux/crypto.h crypto_hash_final
|
||||
!Finclude/linux/crypto.h crypto_hash_digest
|
||||
!Finclude/linux/crypto.h crypto_hash_setkey
|
||||
</sect1>
|
||||
<sect1><title>Message Digest Algorithm Definitions</title>
|
||||
!Pinclude/crypto/hash.h Message Digest Algorithm Definitions
|
||||
|
|
@ -1825,15 +1829,36 @@ read(opfd, out, outlen);
|
|||
!Finclude/crypto/rng.h crypto_alloc_rng
|
||||
!Finclude/crypto/rng.h crypto_rng_alg
|
||||
!Finclude/crypto/rng.h crypto_free_rng
|
||||
!Finclude/crypto/rng.h crypto_rng_generate
|
||||
!Finclude/crypto/rng.h crypto_rng_get_bytes
|
||||
!Finclude/crypto/rng.h crypto_rng_reset
|
||||
!Finclude/crypto/rng.h crypto_rng_seedsize
|
||||
!Cinclude/crypto/rng.h
|
||||
</sect1>
|
||||
<sect1><title>Asymmetric Cipher API</title>
|
||||
!Pinclude/crypto/akcipher.h Generic Public Key API
|
||||
!Finclude/crypto/akcipher.h akcipher_alg
|
||||
!Finclude/crypto/akcipher.h akcipher_request
|
||||
!Finclude/crypto/akcipher.h crypto_alloc_akcipher
|
||||
!Finclude/crypto/akcipher.h crypto_free_akcipher
|
||||
!Finclude/crypto/akcipher.h crypto_akcipher_set_pub_key
|
||||
!Finclude/crypto/akcipher.h crypto_akcipher_set_priv_key
|
||||
</sect1>
|
||||
<sect1><title>Asymmetric Cipher Request Handle</title>
|
||||
!Finclude/crypto/akcipher.h akcipher_request_alloc
|
||||
!Finclude/crypto/akcipher.h akcipher_request_free
|
||||
!Finclude/crypto/akcipher.h akcipher_request_set_callback
|
||||
!Finclude/crypto/akcipher.h akcipher_request_set_crypt
|
||||
!Finclude/crypto/akcipher.h crypto_akcipher_maxsize
|
||||
!Finclude/crypto/akcipher.h crypto_akcipher_encrypt
|
||||
!Finclude/crypto/akcipher.h crypto_akcipher_decrypt
|
||||
!Finclude/crypto/akcipher.h crypto_akcipher_sign
|
||||
!Finclude/crypto/akcipher.h crypto_akcipher_verify
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="Code"><title>Code Examples</title>
|
||||
<sect1><title>Code Example For Asynchronous Block Cipher Operation</title>
|
||||
<sect1><title>Code Example For Symmetric Key Cipher Operation</title>
|
||||
<programlisting>
|
||||
|
||||
struct tcrypt_result {
|
||||
|
|
@ -1842,15 +1867,15 @@ struct tcrypt_result {
|
|||
};
|
||||
|
||||
/* tie all data structures together */
|
||||
struct ablkcipher_def {
|
||||
struct skcipher_def {
|
||||
struct scatterlist sg;
|
||||
struct crypto_ablkcipher *tfm;
|
||||
struct ablkcipher_request *req;
|
||||
struct crypto_skcipher *tfm;
|
||||
struct skcipher_request *req;
|
||||
struct tcrypt_result result;
|
||||
};
|
||||
|
||||
/* Callback function */
|
||||
static void test_ablkcipher_cb(struct crypto_async_request *req, int error)
|
||||
static void test_skcipher_cb(struct crypto_async_request *req, int error)
|
||||
{
|
||||
struct tcrypt_result *result = req->data;
|
||||
|
||||
|
|
@ -1862,15 +1887,15 @@ static void test_ablkcipher_cb(struct crypto_async_request *req, int error)
|
|||
}
|
||||
|
||||
/* Perform cipher operation */
|
||||
static unsigned int test_ablkcipher_encdec(struct ablkcipher_def *ablk,
|
||||
int enc)
|
||||
static unsigned int test_skcipher_encdec(struct skcipher_def *sk,
|
||||
int enc)
|
||||
{
|
||||
int rc = 0;
|
||||
|
||||
if (enc)
|
||||
rc = crypto_ablkcipher_encrypt(ablk->req);
|
||||
rc = crypto_skcipher_encrypt(sk->req);
|
||||
else
|
||||
rc = crypto_ablkcipher_decrypt(ablk->req);
|
||||
rc = crypto_skcipher_decrypt(sk->req);
|
||||
|
||||
switch (rc) {
|
||||
case 0:
|
||||
|
|
@ -1878,52 +1903,52 @@ static unsigned int test_ablkcipher_encdec(struct ablkcipher_def *ablk,
|
|||
case -EINPROGRESS:
|
||||
case -EBUSY:
|
||||
rc = wait_for_completion_interruptible(
|
||||
&ablk->result.completion);
|
||||
if (!rc && !ablk->result.err) {
|
||||
reinit_completion(&ablk->result.completion);
|
||||
&sk->result.completion);
|
||||
if (!rc && !sk->result.err) {
|
||||
reinit_completion(&sk->result.completion);
|
||||
break;
|
||||
}
|
||||
default:
|
||||
pr_info("ablkcipher encrypt returned with %d result %d\n",
|
||||
rc, ablk->result.err);
|
||||
pr_info("skcipher encrypt returned with %d result %d\n",
|
||||
rc, sk->result.err);
|
||||
break;
|
||||
}
|
||||
init_completion(&ablk->result.completion);
|
||||
init_completion(&sk->result.completion);
|
||||
|
||||
return rc;
|
||||
}
|
||||
|
||||
/* Initialize and trigger cipher operation */
|
||||
static int test_ablkcipher(void)
|
||||
static int test_skcipher(void)
|
||||
{
|
||||
struct ablkcipher_def ablk;
|
||||
struct crypto_ablkcipher *ablkcipher = NULL;
|
||||
struct ablkcipher_request *req = NULL;
|
||||
struct skcipher_def sk;
|
||||
struct crypto_skcipher *skcipher = NULL;
|
||||
struct skcipher_request *req = NULL;
|
||||
char *scratchpad = NULL;
|
||||
char *ivdata = NULL;
|
||||
unsigned char key[32];
|
||||
int ret = -EFAULT;
|
||||
|
||||
ablkcipher = crypto_alloc_ablkcipher("cbc-aes-aesni", 0, 0);
|
||||
if (IS_ERR(ablkcipher)) {
|
||||
pr_info("could not allocate ablkcipher handle\n");
|
||||
return PTR_ERR(ablkcipher);
|
||||
skcipher = crypto_alloc_skcipher("cbc-aes-aesni", 0, 0);
|
||||
if (IS_ERR(skcipher)) {
|
||||
pr_info("could not allocate skcipher handle\n");
|
||||
return PTR_ERR(skcipher);
|
||||
}
|
||||
|
||||
req = ablkcipher_request_alloc(ablkcipher, GFP_KERNEL);
|
||||
req = skcipher_request_alloc(skcipher, GFP_KERNEL);
|
||||
if (IS_ERR(req)) {
|
||||
pr_info("could not allocate request queue\n");
|
||||
ret = PTR_ERR(req);
|
||||
goto out;
|
||||
}
|
||||
|
||||
ablkcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
|
||||
test_ablkcipher_cb,
|
||||
&ablk.result);
|
||||
skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
|
||||
test_skcipher_cb,
|
||||
&sk.result);
|
||||
|
||||
/* AES 256 with random key */
|
||||
get_random_bytes(&key, 32);
|
||||
if (crypto_ablkcipher_setkey(ablkcipher, key, 32)) {
|
||||
if (crypto_skcipher_setkey(skcipher, key, 32)) {
|
||||
pr_info("key could not be set\n");
|
||||
ret = -EAGAIN;
|
||||
goto out;
|
||||
|
|
@ -1945,26 +1970,26 @@ static int test_ablkcipher(void)
|
|||
}
|
||||
get_random_bytes(scratchpad, 16);
|
||||
|
||||
ablk.tfm = ablkcipher;
|
||||
ablk.req = req;
|
||||
sk.tfm = skcipher;
|
||||
sk.req = req;
|
||||
|
||||
/* We encrypt one block */
|
||||
sg_init_one(&ablk.sg, scratchpad, 16);
|
||||
ablkcipher_request_set_crypt(req, &ablk.sg, &ablk.sg, 16, ivdata);
|
||||
init_completion(&ablk.result.completion);
|
||||
sg_init_one(&sk.sg, scratchpad, 16);
|
||||
skcipher_request_set_crypt(req, &sk.sg, &sk.sg, 16, ivdata);
|
||||
init_completion(&sk.result.completion);
|
||||
|
||||
/* encrypt data */
|
||||
ret = test_ablkcipher_encdec(&ablk, 1);
|
||||
ret = test_skcipher_encdec(&sk, 1);
|
||||
if (ret)
|
||||
goto out;
|
||||
|
||||
pr_info("Encryption triggered successfully\n");
|
||||
|
||||
out:
|
||||
if (ablkcipher)
|
||||
crypto_free_ablkcipher(ablkcipher);
|
||||
if (skcipher)
|
||||
crypto_free_skcipher(skcipher);
|
||||
if (req)
|
||||
ablkcipher_request_free(req);
|
||||
skcipher_request_free(req);
|
||||
if (ivdata)
|
||||
kfree(ivdata);
|
||||
if (scratchpad)
|
||||
|
|
@ -1974,77 +1999,6 @@ out:
|
|||
</programlisting>
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Code Example For Synchronous Block Cipher Operation</title>
|
||||
<programlisting>
|
||||
|
||||
static int test_blkcipher(void)
|
||||
{
|
||||
struct crypto_blkcipher *blkcipher = NULL;
|
||||
char *cipher = "cbc(aes)";
|
||||
// AES 128
|
||||
charkey =
|
||||
"\x12\x34\x56\x78\x90\xab\xcd\xef\x12\x34\x56\x78\x90\xab\xcd\xef";
|
||||
chariv =
|
||||
"\x12\x34\x56\x78\x90\xab\xcd\xef\x12\x34\x56\x78\x90\xab\xcd\xef";
|
||||
unsigned int ivsize = 0;
|
||||
char *scratchpad = NULL; // holds plaintext and ciphertext
|
||||
struct scatterlist sg;
|
||||
struct blkcipher_desc desc;
|
||||
int ret = -EFAULT;
|
||||
|
||||
blkcipher = crypto_alloc_blkcipher(cipher, 0, 0);
|
||||
if (IS_ERR(blkcipher)) {
|
||||
printk("could not allocate blkcipher handle for %s\n", cipher);
|
||||
return -PTR_ERR(blkcipher);
|
||||
}
|
||||
|
||||
if (crypto_blkcipher_setkey(blkcipher, key, strlen(key))) {
|
||||
printk("key could not be set\n");
|
||||
ret = -EAGAIN;
|
||||
goto out;
|
||||
}
|
||||
|
||||
ivsize = crypto_blkcipher_ivsize(blkcipher);
|
||||
if (ivsize) {
|
||||
if (ivsize != strlen(iv))
|
||||
printk("IV length differs from expected length\n");
|
||||
crypto_blkcipher_set_iv(blkcipher, iv, ivsize);
|
||||
}
|
||||
|
||||
scratchpad = kmalloc(crypto_blkcipher_blocksize(blkcipher), GFP_KERNEL);
|
||||
if (!scratchpad) {
|
||||
printk("could not allocate scratchpad for %s\n", cipher);
|
||||
goto out;
|
||||
}
|
||||
/* get some random data that we want to encrypt */
|
||||
get_random_bytes(scratchpad, crypto_blkcipher_blocksize(blkcipher));
|
||||
|
||||
desc.flags = 0;
|
||||
desc.tfm = blkcipher;
|
||||
sg_init_one(&sg, scratchpad, crypto_blkcipher_blocksize(blkcipher));
|
||||
|
||||
/* encrypt data in place */
|
||||
crypto_blkcipher_encrypt(&desc, &sg, &sg,
|
||||
crypto_blkcipher_blocksize(blkcipher));
|
||||
|
||||
/* decrypt data in place
|
||||
* crypto_blkcipher_decrypt(&desc, &sg, &sg,
|
||||
*/ crypto_blkcipher_blocksize(blkcipher));
|
||||
|
||||
|
||||
printk("Cipher operation completed\n");
|
||||
return 0;
|
||||
|
||||
out:
|
||||
if (blkcipher)
|
||||
crypto_free_blkcipher(blkcipher);
|
||||
if (scratchpad)
|
||||
kzfree(scratchpad);
|
||||
return ret;
|
||||
}
|
||||
</programlisting>
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Code Example For Use of Operational State Memory With SHASH</title>
|
||||
<programlisting>
|
||||
|
||||
|
|
|
|||
|
|
@ -229,6 +229,7 @@ X!Isound/sound_firmware.c
|
|||
!Iinclude/media/v4l2-dv-timings.h
|
||||
!Iinclude/media/v4l2-event.h
|
||||
!Iinclude/media/v4l2-flash-led-class.h
|
||||
!Iinclude/media/v4l2-mc.h
|
||||
!Iinclude/media/v4l2-mediabus.h
|
||||
!Iinclude/media/v4l2-mem2mem.h
|
||||
!Iinclude/media/v4l2-of.h
|
||||
|
|
@ -368,7 +369,7 @@ X!Ilib/fonts/fonts.c
|
|||
!Iinclude/linux/input-polldev.h
|
||||
!Edrivers/input/input-polldev.c
|
||||
</sect1>
|
||||
<sect1><title>Matrix keyboars/keypads</title>
|
||||
<sect1><title>Matrix keyboards/keypads</title>
|
||||
!Iinclude/linux/input/matrix_keypad.h
|
||||
</sect1>
|
||||
<sect1><title>Sparse keymap support</title>
|
||||
|
|
|
|||
|
|
@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >Description/Restrictions</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="37" valign="top" >DRM</td>
|
||||
<td rowspan="42" valign="top" >DRM</td>
|
||||
<td valign="top" >Generic</td>
|
||||
<td valign="top" >“rotation”</td>
|
||||
<td valign="top" >BITMASK</td>
|
||||
|
|
@ -2068,7 +2068,7 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >property to suggest an Y offset for a connector</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="3" valign="top" >Optional</td>
|
||||
<td rowspan="8" valign="top" >Optional</td>
|
||||
<td valign="top" >“scaling mode”</td>
|
||||
<td valign="top" >ENUM</td>
|
||||
<td valign="top" >{ "None", "Full", "Center", "Full aspect" }</td>
|
||||
|
|
@ -2092,6 +2092,61 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >“DEGAMMA_LUT”</td>
|
||||
<td valign="top" >BLOB</td>
|
||||
<td valign="top" >0</td>
|
||||
<td valign="top" >CRTC</td>
|
||||
<td valign="top" >DRM property to set the degamma lookup table
|
||||
(LUT) mapping pixel data from the framebuffer before it is
|
||||
given to the transformation matrix. The data is an interpreted
|
||||
as an array of struct drm_color_lut elements. Hardware might
|
||||
choose not to use the full precision of the LUT elements nor
|
||||
use all the elements of the LUT (for example the hardware
|
||||
might choose to interpolate between LUT[0] and LUT[4]). </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >“DEGAMMA_LUT_SIZE”</td>
|
||||
<td valign="top" >RANGE | IMMUTABLE</td>
|
||||
<td valign="top" >Min=0, Max=UINT_MAX</td>
|
||||
<td valign="top" >CRTC</td>
|
||||
<td valign="top" >DRM property to gives the size of the lookup
|
||||
table to be set on the DEGAMMA_LUT property (the size depends
|
||||
on the underlying hardware).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >“CTM”</td>
|
||||
<td valign="top" >BLOB</td>
|
||||
<td valign="top" >0</td>
|
||||
<td valign="top" >CRTC</td>
|
||||
<td valign="top" >DRM property to set the current
|
||||
transformation matrix (CTM) apply to pixel data after the
|
||||
lookup through the degamma LUT and before the lookup through
|
||||
the gamma LUT. The data is an interpreted as a struct
|
||||
drm_color_ctm.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >“GAMMA_LUT”</td>
|
||||
<td valign="top" >BLOB</td>
|
||||
<td valign="top" >0</td>
|
||||
<td valign="top" >CRTC</td>
|
||||
<td valign="top" >DRM property to set the gamma lookup table
|
||||
(LUT) mapping pixel data after to the transformation matrix to
|
||||
data sent to the connector. The data is an interpreted as an
|
||||
array of struct drm_color_lut elements. Hardware might choose
|
||||
not to use the full precision of the LUT elements nor use all
|
||||
the elements of the LUT (for example the hardware might choose
|
||||
to interpolate between LUT[0] and LUT[4]).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >“GAMMA_LUT_SIZE”</td>
|
||||
<td valign="top" >RANGE | IMMUTABLE</td>
|
||||
<td valign="top" >Min=0, Max=UINT_MAX</td>
|
||||
<td valign="top" >CRTC</td>
|
||||
<td valign="top" >DRM property to gives the size of the lookup
|
||||
table to be set on the GAMMA_LUT property (the size depends on
|
||||
the underlying hardware).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="20" valign="top" >i915</td>
|
||||
<td rowspan="2" valign="top" >Generic</td>
|
||||
<td valign="top" >"Broadcast RGB"</td>
|
||||
|
|
@ -2886,52 +2941,8 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis>
|
|||
</sect2>
|
||||
<sect2>
|
||||
<title>File Operations</title>
|
||||
<synopsis>const struct file_operations *fops</synopsis>
|
||||
<abstract>File operations for the DRM device node.</abstract>
|
||||
<para>
|
||||
Drivers must define the file operations structure that forms the DRM
|
||||
userspace API entry point, even though most of those operations are
|
||||
implemented in the DRM core. The <methodname>open</methodname>,
|
||||
<methodname>release</methodname> and <methodname>ioctl</methodname>
|
||||
operations are handled by
|
||||
<programlisting>
|
||||
.owner = THIS_MODULE,
|
||||
.open = drm_open,
|
||||
.release = drm_release,
|
||||
.unlocked_ioctl = drm_ioctl,
|
||||
#ifdef CONFIG_COMPAT
|
||||
.compat_ioctl = drm_compat_ioctl,
|
||||
#endif
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
Drivers that implement private ioctls that requires 32/64bit
|
||||
compatibility support must provide their own
|
||||
<methodname>compat_ioctl</methodname> handler that processes private
|
||||
ioctls and calls <function>drm_compat_ioctl</function> for core ioctls.
|
||||
</para>
|
||||
<para>
|
||||
The <methodname>read</methodname> and <methodname>poll</methodname>
|
||||
operations provide support for reading DRM events and polling them. They
|
||||
are implemented by
|
||||
<programlisting>
|
||||
.poll = drm_poll,
|
||||
.read = drm_read,
|
||||
.llseek = no_llseek,
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
The memory mapping implementation varies depending on how the driver
|
||||
manages memory. Pre-GEM drivers will use <function>drm_mmap</function>,
|
||||
while GEM-aware drivers will use <function>drm_gem_mmap</function>. See
|
||||
<xref linkend="drm-gem"/>.
|
||||
<programlisting>
|
||||
.mmap = drm_gem_mmap,
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
No other file operation is supported by the DRM API.
|
||||
</para>
|
||||
!Pdrivers/gpu/drm/drm_fops.c file operations
|
||||
!Edrivers/gpu/drm/drm_fops.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>IOCTLs</title>
|
||||
|
|
@ -3319,6 +3330,12 @@ int num_ioctls;</synopsis>
|
|||
!Pdrivers/gpu/drm/i915/intel_csr.c csr support for dmc
|
||||
!Idrivers/gpu/drm/i915/intel_csr.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Video BIOS Table (VBT)</title>
|
||||
!Pdrivers/gpu/drm/i915/intel_bios.c Video BIOS Table (VBT)
|
||||
!Idrivers/gpu/drm/i915/intel_bios.c
|
||||
!Idrivers/gpu/drm/i915/intel_bios.h
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
|
|
@ -3460,6 +3477,7 @@ int num_ioctls;</synopsis>
|
|||
</sect1>
|
||||
<sect1>
|
||||
<title>Public constants</title>
|
||||
!Finclude/linux/vga_switcheroo.h vga_switcheroo_handler_flags_t
|
||||
!Finclude/linux/vga_switcheroo.h vga_switcheroo_client_id
|
||||
!Finclude/linux/vga_switcheroo.h vga_switcheroo_state
|
||||
</sect1>
|
||||
|
|
@ -3488,6 +3506,10 @@ int num_ioctls;</synopsis>
|
|||
<title>Backlight control</title>
|
||||
!Pdrivers/platform/x86/apple-gmux.c Backlight control
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Public functions</title>
|
||||
!Iinclude/linux/apple-gmux.h
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
|
|
|
|||
|
|
@ -2329,6 +2329,14 @@ to search and match for the present Macroblock (MB) in the reference picture. Th
|
|||
vertical search range for motion estimation module in video encoder.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row id="v4l2-mpeg-video-force-key-frame">
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME</constant> </entry>
|
||||
<entry>button</entry>
|
||||
</row><row><entry spanname="descr">Force a key frame for the next queued buffer. Applicable to encoders.
|
||||
This is a general, codec-agnostic keyframe control.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant> </entry>
|
||||
|
|
@ -5069,6 +5077,46 @@ interface and may change in the future.</para>
|
|||
This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_DV_TX_IT_CONTENT_TYPE</constant></entry>
|
||||
<entry id="v4l2-dv-content-type">enum v4l2_dv_it_content_type</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Configures the IT Content Type
|
||||
of the transmitted video. This information is sent over HDMI and DisplayPort connectors
|
||||
as part of the AVI InfoFrame. The term 'IT Content' is used for content that originates
|
||||
from a computer as opposed to content from a TV broadcast or an analog source. The
|
||||
enum v4l2_dv_it_content_type defines the possible content types:</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entrytbl spanname="descr" cols="2">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_GRAPHICS</constant> </entry>
|
||||
<entry>Graphics content. Pixel data should be passed unfiltered and without
|
||||
analog reconstruction.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_PHOTO</constant> </entry>
|
||||
<entry>Photo content. The content is derived from digital still pictures.
|
||||
The content should be passed through with minimal scaling and picture
|
||||
enhancements.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_CINEMA</constant> </entry>
|
||||
<entry>Cinema content.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_GAME</constant> </entry>
|
||||
<entry>Game content. Audio and video latency should be minimized.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_NO_ITC</constant> </entry>
|
||||
<entry>No IT Content information is available and the ITC bit in the AVI
|
||||
InfoFrame is set to 0.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</entrytbl>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_DV_RX_POWER_PRESENT</constant></entry>
|
||||
<entry>bitmask</entry>
|
||||
|
|
@ -5098,6 +5146,16 @@ interface and may change in the future.</para>
|
|||
This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_DV_RX_IT_CONTENT_TYPE</constant></entry>
|
||||
<entry>enum v4l2_dv_it_content_type</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Reads the IT Content Type
|
||||
of the received video. This information is sent over HDMI and DisplayPort connectors
|
||||
as part of the AVI InfoFrame. The term 'IT Content' is used for content that originates
|
||||
from a computer as opposed to content from a TV broadcast or an analog source. See
|
||||
<constant>V4L2_CID_DV_TX_IT_CONTENT_TYPE</constant> for the available content types.</entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
|
|
|||
|
|
@ -48,9 +48,6 @@
|
|||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para><emphasis role="bold">NOTE:</emphasis> This new ioctl is programmed to be added on Kernel 4.6. Its definition/arguments may change until its final version.</para>
|
||||
|
||||
<para>The typical usage of this ioctl is to call it twice.
|
||||
On the first call, the structure defined at &media-v2-topology; should
|
||||
be zeroed. At return, if no errors happen, this ioctl will return the
|
||||
|
|
|
|||
|
|
@ -56,10 +56,6 @@
|
|||
<entry><constant>MEDIA_ENT_F_CONN_COMPOSITE</constant></entry>
|
||||
<entry>Connector for a RGB composite signal.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_F_CONN_TEST</constant></entry>
|
||||
<entry>Connector for a test generator.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_F_CAM_SENSOR</constant></entry>
|
||||
<entry>Camera video sensor entity.</entry>
|
||||
|
|
@ -84,7 +80,46 @@
|
|||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_F_TUNER</constant></entry>
|
||||
<entry>Digital TV, analog TV, radio and/or software radio tuner.</entry>
|
||||
<entry>Digital TV, analog TV, radio and/or software radio tuner,
|
||||
with consists on a PLL tuning stage that converts radio
|
||||
frequency (RF) signal into an Intermediate Frequency (IF).
|
||||
Modern tuners have internally IF-PLL decoders for audio
|
||||
and video, but older models have those stages implemented
|
||||
on separate entities.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_F_IF_VID_DECODER</constant></entry>
|
||||
<entry>IF-PLL video decoder. It receives the IF from a PLL
|
||||
and decodes the analog TV video signal. This is commonly
|
||||
found on some very old analog tuners, like Philips MK3
|
||||
designs. They all contain a tda9887 (or some software
|
||||
compatible similar chip, like tda9885). Those devices
|
||||
use a different I2C address than the tuner PLL.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_F_IF_AUD_DECODER</constant></entry>
|
||||
<entry>IF-PLL sound decoder. It receives the IF from a PLL
|
||||
and decodes the analog TV audio signal. This is commonly
|
||||
found on some very old analog hardware, like Micronas
|
||||
msp3400, Philips tda9840, tda985x, etc. Those devices
|
||||
use a different I2C address than the tuner PLL and
|
||||
should be controlled together with the IF-PLL video
|
||||
decoder.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_F_AUDIO_CAPTURE</constant></entry>
|
||||
<entry>Audio Capture Function Entity.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_F_AUDIO_PLAYBACK</constant></entry>
|
||||
<entry>Audio Playback Function Entity.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_F_AUDIO_MIXER</constant></entry>
|
||||
<entry>Audio Mixer Function Entity.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
|
@ -166,6 +201,46 @@
|
|||
<entry>Device node interface for Software Defined Radio (V4L)</entry>
|
||||
<entry>typically, /dev/swradio?</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_INTF_T_ALSA_PCM_CAPTURE</constant></entry>
|
||||
<entry>Device node interface for ALSA PCM Capture</entry>
|
||||
<entry>typically, /dev/snd/pcmC?D?c</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_INTF_T_ALSA_PCM_PLAYBACK</constant></entry>
|
||||
<entry>Device node interface for ALSA PCM Playback</entry>
|
||||
<entry>typically, /dev/snd/pcmC?D?p</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_INTF_T_ALSA_CONTROL</constant></entry>
|
||||
<entry>Device node interface for ALSA Control</entry>
|
||||
<entry>typically, /dev/snd/controlC?</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_INTF_T_ALSA_COMPRESS</constant></entry>
|
||||
<entry>Device node interface for ALSA Compress</entry>
|
||||
<entry>typically, /dev/snd/compr?</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_INTF_T_ALSA_RAWMIDI</constant></entry>
|
||||
<entry>Device node interface for ALSA Raw MIDI</entry>
|
||||
<entry>typically, /dev/snd/midi?</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_INTF_T_ALSA_HWDEP</constant></entry>
|
||||
<entry>Device node interface for ALSA Hardware Dependent</entry>
|
||||
<entry>typically, /dev/snd/hwC?D?</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_INTF_T_ALSA_SEQUENCER</constant></entry>
|
||||
<entry>Device node interface for ALSA Sequencer</entry>
|
||||
<entry>typically, /dev/snd/seq</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_INTF_T_ALSA_TIMER</constant></entry>
|
||||
<entry>Device node interface for ALSA Timer</entry>
|
||||
<entry>typically, /dev/snd/timer</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,49 @@
|
|||
<refentry id="V4L2-PIX-FMT-Y12I">
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_PIX_FMT_Y12I ('Y12I')</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname><constant>V4L2_PIX_FMT_Y12I</constant></refname>
|
||||
<refpurpose>Interleaved grey-scale image, e.g. from a stereo-pair</refpurpose>
|
||||
</refnamediv>
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>This is a grey-scale image with a depth of 12 bits per pixel, but with
|
||||
pixels from 2 sources interleaved and bit-packed. Each pixel is stored in a
|
||||
24-bit word in the little-endian order. On a little-endian machine these pixels
|
||||
can be deinterlaced using</para>
|
||||
|
||||
<para>
|
||||
<programlisting>
|
||||
__u8 *buf;
|
||||
left0 = 0xfff & *(__u16 *)buf;
|
||||
right0 = *(__u16 *)(buf + 1) >> 4;
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<example>
|
||||
<title><constant>V4L2_PIX_FMT_Y12I</constant> 2 pixel data stream taking 3 bytes</title>
|
||||
|
||||
<formalpara>
|
||||
<title>Bit-packed representation</title>
|
||||
<para>pixels cross the byte boundary and have a ratio of 3 bytes for each
|
||||
interleaved pixel.
|
||||
<informaltable frame="all">
|
||||
<tgroup cols="3" align="center">
|
||||
<colspec align="left" colwidth="2*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>Y'<subscript>0left[7:0]</subscript></entry>
|
||||
<entry>Y'<subscript>0right[3:0]</subscript>Y'<subscript>0left[11:8]</subscript></entry>
|
||||
<entry>Y'<subscript>0right[11:4]</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
</example>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
<refentry id="V4L2-PIX-FMT-Y8I">
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_PIX_FMT_Y8I ('Y8I ')</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname><constant>V4L2_PIX_FMT_Y8I</constant></refname>
|
||||
<refpurpose>Interleaved grey-scale image, e.g. from a stereo-pair</refpurpose>
|
||||
</refnamediv>
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>This is a grey-scale image with a depth of 8 bits per pixel, but with
|
||||
pixels from 2 sources interleaved. Each pixel is stored in a 16-bit word. E.g.
|
||||
the R200 RealSense camera stores pixel from the left sensor in lower and from
|
||||
the right sensor in the higher 8 bits.</para>
|
||||
|
||||
<example>
|
||||
<title><constant>V4L2_PIX_FMT_Y8I</constant> 4 × 4
|
||||
pixel image</title>
|
||||
|
||||
<formalpara>
|
||||
<title>Byte Order.</title>
|
||||
<para>Each cell is one byte.
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="9" align="center">
|
||||
<colspec align="left" colwidth="2*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>start + 0:</entry>
|
||||
<entry>Y'<subscript>00left</subscript></entry>
|
||||
<entry>Y'<subscript>00right</subscript></entry>
|
||||
<entry>Y'<subscript>01left</subscript></entry>
|
||||
<entry>Y'<subscript>01right</subscript></entry>
|
||||
<entry>Y'<subscript>02left</subscript></entry>
|
||||
<entry>Y'<subscript>02right</subscript></entry>
|
||||
<entry>Y'<subscript>03left</subscript></entry>
|
||||
<entry>Y'<subscript>03right</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 8:</entry>
|
||||
<entry>Y'<subscript>10left</subscript></entry>
|
||||
<entry>Y'<subscript>10right</subscript></entry>
|
||||
<entry>Y'<subscript>11left</subscript></entry>
|
||||
<entry>Y'<subscript>11right</subscript></entry>
|
||||
<entry>Y'<subscript>12left</subscript></entry>
|
||||
<entry>Y'<subscript>12right</subscript></entry>
|
||||
<entry>Y'<subscript>13left</subscript></entry>
|
||||
<entry>Y'<subscript>13right</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 16:</entry>
|
||||
<entry>Y'<subscript>20left</subscript></entry>
|
||||
<entry>Y'<subscript>20right</subscript></entry>
|
||||
<entry>Y'<subscript>21left</subscript></entry>
|
||||
<entry>Y'<subscript>21right</subscript></entry>
|
||||
<entry>Y'<subscript>22left</subscript></entry>
|
||||
<entry>Y'<subscript>22right</subscript></entry>
|
||||
<entry>Y'<subscript>23left</subscript></entry>
|
||||
<entry>Y'<subscript>23right</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 24:</entry>
|
||||
<entry>Y'<subscript>30left</subscript></entry>
|
||||
<entry>Y'<subscript>30right</subscript></entry>
|
||||
<entry>Y'<subscript>31left</subscript></entry>
|
||||
<entry>Y'<subscript>31right</subscript></entry>
|
||||
<entry>Y'<subscript>32left</subscript></entry>
|
||||
<entry>Y'<subscript>32right</subscript></entry>
|
||||
<entry>Y'<subscript>33left</subscript></entry>
|
||||
<entry>Y'<subscript>33right</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
</example>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -1,35 +1,43 @@
|
|||
<refentry id="V4L2-PIX-FMT-YUV420M">
|
||||
<refentry>
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_PIX_FMT_YUV420M ('YM12')</refentrytitle>
|
||||
<refentrytitle>V4L2_PIX_FMT_YUV420M ('YM12'), V4L2_PIX_FMT_YVU420M ('YM21')</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname> <constant>V4L2_PIX_FMT_YUV420M</constant></refname>
|
||||
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YUV420</constant>
|
||||
with planes non contiguous in memory. </refpurpose>
|
||||
<refname id="V4L2-PIX-FMT-YUV420M"><constant>V4L2_PIX_FMT_YUV420M</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-YVU420M"><constant>V4L2_PIX_FMT_YVU420M</constant></refname>
|
||||
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YUV420</constant> and
|
||||
<constant>V4L2_PIX_FMT_YVU420</constant> with planes non contiguous
|
||||
in memory.</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>This is a multi-planar format, as opposed to a packed format.
|
||||
The three components are separated into three sub- images or planes.
|
||||
The three components are separated into three sub-images or planes.</para>
|
||||
|
||||
The Y plane is first. The Y plane has one byte per pixel. The Cb data
|
||||
<para>The Y plane is first. The Y plane has one byte per pixel.
|
||||
For <constant>V4L2_PIX_FMT_YUV420M</constant> the Cb data
|
||||
constitutes the second plane which is half the width and half
|
||||
the height of the Y plane (and of the image). Each Cb belongs to four
|
||||
pixels, a two-by-two square of the image. For example,
|
||||
Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
|
||||
Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and
|
||||
Y'<subscript>11</subscript>. The Cr data, just like the Cb plane, is
|
||||
in the third plane. </para>
|
||||
in the third plane.</para>
|
||||
|
||||
<para><constant>V4L2_PIX_FMT_YVU420M</constant> is the same except
|
||||
the Cr data is stored in the second plane and the Cb data in the third plane.
|
||||
</para>
|
||||
|
||||
<para>If the Y plane has pad bytes after each row, then the Cb
|
||||
and Cr planes have half as many pad bytes after their rows. In other
|
||||
words, two Cx rows (including padding) is exactly as long as one Y row
|
||||
(including padding).</para>
|
||||
|
||||
<para><constant>V4L2_PIX_FMT_YUV420M</constant> is intended to be
|
||||
<para><constant>V4L2_PIX_FMT_YUV420M</constant> and
|
||||
<constant>V4L2_PIX_FMT_YVU420M</constant> are intended to be
|
||||
used only in drivers and applications that support the multi-planar API,
|
||||
described in <xref linkend="planar-apis"/>. </para>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,40 +1,45 @@
|
|||
<refentry id="V4L2-PIX-FMT-YVU420M">
|
||||
<refentry>
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_PIX_FMT_YVU420M ('YM21')</refentrytitle>
|
||||
<refentrytitle>V4L2_PIX_FMT_YUV422M ('YM16'), V4L2_PIX_FMT_YVU422M ('YM61')</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname> <constant>V4L2_PIX_FMT_YVU420M</constant></refname>
|
||||
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YVU420</constant>
|
||||
with planes non contiguous in memory. </refpurpose>
|
||||
<refname id="V4L2-PIX-FMT-YUV422M"><constant>V4L2_PIX_FMT_YUV422M</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-YVU422M"><constant>V4L2_PIX_FMT_YVU422M</constant></refname>
|
||||
<refpurpose>Planar formats with ½ horizontal resolution, also
|
||||
known as YUV and YVU 4:2:2</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>This is a multi-planar format, as opposed to a packed format.
|
||||
The three components are separated into three sub-images or planes.
|
||||
The three components are separated into three sub-images or planes.</para>
|
||||
|
||||
The Y plane is first. The Y plane has one byte per pixel. The Cr data
|
||||
constitutes the second plane which is half the width and half
|
||||
the height of the Y plane (and of the image). Each Cr belongs to four
|
||||
pixels, a two-by-two square of the image. For example,
|
||||
Cr<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
|
||||
Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and
|
||||
Y'<subscript>11</subscript>. The Cb data, just like the Cr plane, constitutes
|
||||
the third plane. </para>
|
||||
<para>The Y plane is first. The Y plane has one byte per pixel.
|
||||
For <constant>V4L2_PIX_FMT_YUV422M</constant> the Cb data
|
||||
constitutes the second plane which is half the width of the Y plane (and of the
|
||||
image). Each Cb belongs to two pixels. For example,
|
||||
Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
|
||||
Y'<subscript>01</subscript>. The Cr data, just like the Cb plane, is
|
||||
in the third plane. </para>
|
||||
|
||||
<para>If the Y plane has pad bytes after each row, then the Cr
|
||||
and Cb planes have half as many pad bytes after their rows. In other
|
||||
<para><constant>V4L2_PIX_FMT_YVU422M</constant> is the same except
|
||||
the Cr data is stored in the second plane and the Cb data in the third plane.
|
||||
</para>
|
||||
|
||||
<para>If the Y plane has pad bytes after each row, then the Cb
|
||||
and Cr planes have half as many pad bytes after their rows. In other
|
||||
words, two Cx rows (including padding) is exactly as long as one Y row
|
||||
(including padding).</para>
|
||||
|
||||
<para><constant>V4L2_PIX_FMT_YVU420M</constant> is intended to be
|
||||
<para><constant>V4L2_PIX_FMT_YUV422M</constant> and
|
||||
<constant>V4L2_PIX_FMT_YVU422M</constant> are intended to be
|
||||
used only in drivers and applications that support the multi-planar API,
|
||||
described in <xref linkend="planar-apis"/>. </para>
|
||||
|
||||
<example>
|
||||
<title><constant>V4L2_PIX_FMT_YVU420M</constant> 4 × 4
|
||||
<title><constant>V4L2_PIX_FMT_YUV422M</constant> 4 × 4
|
||||
pixel image</title>
|
||||
|
||||
<formalpara>
|
||||
|
|
@ -75,25 +80,45 @@ pixel image</title>
|
|||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry>start1 + 0:</entry>
|
||||
<entry>Cr<subscript>00</subscript></entry>
|
||||
<entry>Cr<subscript>01</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start1 + 2:</entry>
|
||||
<entry>Cr<subscript>10</subscript></entry>
|
||||
<entry>Cr<subscript>11</subscript></entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry>start2 + 0:</entry>
|
||||
<entry>Cb<subscript>00</subscript></entry>
|
||||
<entry>Cb<subscript>01</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start2 + 2:</entry>
|
||||
<entry>start1 + 2:</entry>
|
||||
<entry>Cb<subscript>10</subscript></entry>
|
||||
<entry>Cb<subscript>11</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start1 + 4:</entry>
|
||||
<entry>Cb<subscript>20</subscript></entry>
|
||||
<entry>Cb<subscript>21</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start1 + 6:</entry>
|
||||
<entry>Cb<subscript>30</subscript></entry>
|
||||
<entry>Cb<subscript>31</subscript></entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry>start2 + 0:</entry>
|
||||
<entry>Cr<subscript>00</subscript></entry>
|
||||
<entry>Cr<subscript>01</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start2 + 2:</entry>
|
||||
<entry>Cr<subscript>10</subscript></entry>
|
||||
<entry>Cr<subscript>11</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start2 + 4:</entry>
|
||||
<entry>Cr<subscript>20</subscript></entry>
|
||||
<entry>Cr<subscript>21</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start2 + 6:</entry>
|
||||
<entry>Cr<subscript>30</subscript></entry>
|
||||
<entry>Cr<subscript>31</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
|
@ -113,36 +138,23 @@ pixel image</title>
|
|||
</row>
|
||||
<row>
|
||||
<entry>0</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry><entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry>
|
||||
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry>C</entry><entry>Y</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>1</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry>C</entry><entry>Y</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>2</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry><entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry>
|
||||
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry>C</entry><entry>Y</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>3</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry>C</entry><entry>Y</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
|
@ -0,0 +1,177 @@
|
|||
<refentry>
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_PIX_FMT_YUV444M ('YM24'), V4L2_PIX_FMT_YVU444M ('YM42')</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname id="V4L2-PIX-FMT-YUV444M"><constant>V4L2_PIX_FMT_YUV444M</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-YVU444M"><constant>V4L2_PIX_FMT_YVU444M</constant></refname>
|
||||
<refpurpose>Planar formats with full horizontal resolution, also
|
||||
known as YUV and YVU 4:4:4</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>This is a multi-planar format, as opposed to a packed format.
|
||||
The three components are separated into three sub-images or planes.</para>
|
||||
|
||||
<para>The Y plane is first. The Y plane has one byte per pixel.
|
||||
For <constant>V4L2_PIX_FMT_YUV444M</constant> the Cb data
|
||||
constitutes the second plane which is the same width and height as the Y plane
|
||||
(and as the image). The Cr data, just like the Cb plane, is in the third plane.
|
||||
</para>
|
||||
|
||||
<para><constant>V4L2_PIX_FMT_YVU444M</constant> is the same except
|
||||
the Cr data is stored in the second plane and the Cb data in the third plane.
|
||||
</para>
|
||||
<para>If the Y plane has pad bytes after each row, then the Cb
|
||||
and Cr planes have the same number of pad bytes after their rows.</para>
|
||||
|
||||
<para><constant>V4L2_PIX_FMT_YUV444M</constant> and
|
||||
<constant>V4L2_PIX_FMT_YUV444M</constant> are intended to be
|
||||
used only in drivers and applications that support the multi-planar API,
|
||||
described in <xref linkend="planar-apis"/>. </para>
|
||||
|
||||
<example>
|
||||
<title><constant>V4L2_PIX_FMT_YUV444M</constant> 4 × 4
|
||||
pixel image</title>
|
||||
|
||||
<formalpara>
|
||||
<title>Byte Order.</title>
|
||||
<para>Each cell is one byte.
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="5" align="center">
|
||||
<colspec align="left" colwidth="2*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>start0 + 0:</entry>
|
||||
<entry>Y'<subscript>00</subscript></entry>
|
||||
<entry>Y'<subscript>01</subscript></entry>
|
||||
<entry>Y'<subscript>02</subscript></entry>
|
||||
<entry>Y'<subscript>03</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start0 + 4:</entry>
|
||||
<entry>Y'<subscript>10</subscript></entry>
|
||||
<entry>Y'<subscript>11</subscript></entry>
|
||||
<entry>Y'<subscript>12</subscript></entry>
|
||||
<entry>Y'<subscript>13</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start0 + 8:</entry>
|
||||
<entry>Y'<subscript>20</subscript></entry>
|
||||
<entry>Y'<subscript>21</subscript></entry>
|
||||
<entry>Y'<subscript>22</subscript></entry>
|
||||
<entry>Y'<subscript>23</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start0 + 12:</entry>
|
||||
<entry>Y'<subscript>30</subscript></entry>
|
||||
<entry>Y'<subscript>31</subscript></entry>
|
||||
<entry>Y'<subscript>32</subscript></entry>
|
||||
<entry>Y'<subscript>33</subscript></entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry>start1 + 0:</entry>
|
||||
<entry>Cb<subscript>00</subscript></entry>
|
||||
<entry>Cb<subscript>01</subscript></entry>
|
||||
<entry>Cb<subscript>02</subscript></entry>
|
||||
<entry>Cb<subscript>03</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start1 + 4:</entry>
|
||||
<entry>Cb<subscript>10</subscript></entry>
|
||||
<entry>Cb<subscript>11</subscript></entry>
|
||||
<entry>Cb<subscript>12</subscript></entry>
|
||||
<entry>Cb<subscript>13</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start1 + 8:</entry>
|
||||
<entry>Cb<subscript>20</subscript></entry>
|
||||
<entry>Cb<subscript>21</subscript></entry>
|
||||
<entry>Cb<subscript>22</subscript></entry>
|
||||
<entry>Cb<subscript>23</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start1 + 12:</entry>
|
||||
<entry>Cb<subscript>20</subscript></entry>
|
||||
<entry>Cb<subscript>21</subscript></entry>
|
||||
<entry>Cb<subscript>32</subscript></entry>
|
||||
<entry>Cb<subscript>33</subscript></entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry>start2 + 0:</entry>
|
||||
<entry>Cr<subscript>00</subscript></entry>
|
||||
<entry>Cr<subscript>01</subscript></entry>
|
||||
<entry>Cr<subscript>02</subscript></entry>
|
||||
<entry>Cr<subscript>03</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start2 + 4:</entry>
|
||||
<entry>Cr<subscript>10</subscript></entry>
|
||||
<entry>Cr<subscript>11</subscript></entry>
|
||||
<entry>Cr<subscript>12</subscript></entry>
|
||||
<entry>Cr<subscript>13</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start2 + 8:</entry>
|
||||
<entry>Cr<subscript>20</subscript></entry>
|
||||
<entry>Cr<subscript>21</subscript></entry>
|
||||
<entry>Cr<subscript>22</subscript></entry>
|
||||
<entry>Cr<subscript>23</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start2 + 12:</entry>
|
||||
<entry>Cr<subscript>30</subscript></entry>
|
||||
<entry>Cr<subscript>31</subscript></entry>
|
||||
<entry>Cr<subscript>32</subscript></entry>
|
||||
<entry>Cr<subscript>33</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
|
||||
<formalpara>
|
||||
<title>Color Sample Location.</title>
|
||||
<para>
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="7" align="center">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
|
||||
<entry>2</entry><entry></entry><entry>3</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>0</entry>
|
||||
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
|
||||
<entry>YC</entry><entry></entry><entry>YC</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>1</entry>
|
||||
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
|
||||
<entry>YC</entry><entry></entry><entry>YC</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>2</entry>
|
||||
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
|
||||
<entry>YC</entry><entry></entry><entry>YC</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>3</entry>
|
||||
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
|
||||
<entry>YC</entry><entry></entry><entry>YC</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
</example>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
<refentry id="V4L2-PIX-FMT-Z16">
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_PIX_FMT_Z16 ('Z16 ')</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname><constant>V4L2_PIX_FMT_Z16</constant></refname>
|
||||
<refpurpose>Interleaved grey-scale image, e.g. from a stereo-pair</refpurpose>
|
||||
</refnamediv>
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>This is a 16-bit format, representing depth data. Each pixel is a
|
||||
distance to the respective point in the image coordinates. Distance unit can
|
||||
vary and has to be negotiated with the device separately. Each pixel is stored
|
||||
in a 16-bit word in the little endian byte order.
|
||||
</para>
|
||||
|
||||
<example>
|
||||
<title><constant>V4L2_PIX_FMT_Z16</constant> 4 × 4
|
||||
pixel image</title>
|
||||
|
||||
<formalpara>
|
||||
<title>Byte Order.</title>
|
||||
<para>Each cell is one byte.
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="9" align="center">
|
||||
<colspec align="left" colwidth="2*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>start + 0:</entry>
|
||||
<entry>Z<subscript>00low</subscript></entry>
|
||||
<entry>Z<subscript>00high</subscript></entry>
|
||||
<entry>Z<subscript>01low</subscript></entry>
|
||||
<entry>Z<subscript>01high</subscript></entry>
|
||||
<entry>Z<subscript>02low</subscript></entry>
|
||||
<entry>Z<subscript>02high</subscript></entry>
|
||||
<entry>Z<subscript>03low</subscript></entry>
|
||||
<entry>Z<subscript>03high</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 8:</entry>
|
||||
<entry>Z<subscript>10low</subscript></entry>
|
||||
<entry>Z<subscript>10high</subscript></entry>
|
||||
<entry>Z<subscript>11low</subscript></entry>
|
||||
<entry>Z<subscript>11high</subscript></entry>
|
||||
<entry>Z<subscript>12low</subscript></entry>
|
||||
<entry>Z<subscript>12high</subscript></entry>
|
||||
<entry>Z<subscript>13low</subscript></entry>
|
||||
<entry>Z<subscript>13high</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 16:</entry>
|
||||
<entry>Z<subscript>20low</subscript></entry>
|
||||
<entry>Z<subscript>20high</subscript></entry>
|
||||
<entry>Z<subscript>21low</subscript></entry>
|
||||
<entry>Z<subscript>21high</subscript></entry>
|
||||
<entry>Z<subscript>22low</subscript></entry>
|
||||
<entry>Z<subscript>22high</subscript></entry>
|
||||
<entry>Z<subscript>23low</subscript></entry>
|
||||
<entry>Z<subscript>23high</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 24:</entry>
|
||||
<entry>Z<subscript>30low</subscript></entry>
|
||||
<entry>Z<subscript>30high</subscript></entry>
|
||||
<entry>Z<subscript>31low</subscript></entry>
|
||||
<entry>Z<subscript>31high</subscript></entry>
|
||||
<entry>Z<subscript>32low</subscript></entry>
|
||||
<entry>Z<subscript>32high</subscript></entry>
|
||||
<entry>Z<subscript>33low</subscript></entry>
|
||||
<entry>Z<subscript>33high</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
</example>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -1620,6 +1620,8 @@ information.</para>
|
|||
&sub-y10b;
|
||||
&sub-y16;
|
||||
&sub-y16-be;
|
||||
&sub-y8i;
|
||||
&sub-y12i;
|
||||
&sub-uv8;
|
||||
&sub-yuyv;
|
||||
&sub-uyvy;
|
||||
|
|
@ -1628,7 +1630,8 @@ information.</para>
|
|||
&sub-y41p;
|
||||
&sub-yuv420;
|
||||
&sub-yuv420m;
|
||||
&sub-yvu420m;
|
||||
&sub-yuv422m;
|
||||
&sub-yuv444m;
|
||||
&sub-yuv410;
|
||||
&sub-yuv422p;
|
||||
&sub-yuv411p;
|
||||
|
|
@ -1641,6 +1644,14 @@ information.</para>
|
|||
&sub-m420;
|
||||
</section>
|
||||
|
||||
<section id="depth-formats">
|
||||
<title>Depth Formats</title>
|
||||
<para>Depth data provides distance to points, mapped onto the image plane
|
||||
</para>
|
||||
|
||||
&sub-z16;
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Compressed Formats</title>
|
||||
|
||||
|
|
|
|||
|
|
@ -60,9 +60,19 @@ input</refpurpose>
|
|||
automatically, similar to sensing the video standard. To do so, applications
|
||||
call <constant>VIDIOC_QUERY_DV_TIMINGS</constant> with a pointer to a
|
||||
&v4l2-dv-timings;. Once the hardware detects the timings, it will fill in the
|
||||
timings structure.
|
||||
timings structure.</para>
|
||||
|
||||
If the timings could not be detected because there was no signal, then
|
||||
<para>Please note that drivers shall <emphasis>not</emphasis> switch timings automatically
|
||||
if new timings are detected. Instead, drivers should send the
|
||||
<constant>V4L2_EVENT_SOURCE_CHANGE</constant> event (if they support this) and expect
|
||||
that userspace will take action by calling <constant>VIDIOC_QUERY_DV_TIMINGS</constant>.
|
||||
The reason is that new timings usually mean different buffer sizes as well, and you
|
||||
cannot change buffer sizes on the fly. In general, applications that receive the
|
||||
Source Change event will have to call <constant>VIDIOC_QUERY_DV_TIMINGS</constant>,
|
||||
and if the detected timings are valid they will have to stop streaming, set the new
|
||||
timings, allocate new buffers and start streaming again.</para>
|
||||
|
||||
<para>If the timings could not be detected because there was no signal, then
|
||||
<errorcode>ENOLINK</errorcode> is returned. If a signal was detected, but
|
||||
it was unstable and the receiver could not lock to the signal, then
|
||||
<errorcode>ENOLCK</errorcode> is returned. If the receiver could lock to the signal,
|
||||
|
|
|
|||
|
|
@ -59,6 +59,16 @@ then the driver will return V4L2_STD_UNKNOWN. When detection is not
|
|||
possible or fails, the set must contain all standards supported by the
|
||||
current video input or output.</para>
|
||||
|
||||
<para>Please note that drivers shall <emphasis>not</emphasis> switch the video standard
|
||||
automatically if a new video standard is detected. Instead, drivers should send the
|
||||
<constant>V4L2_EVENT_SOURCE_CHANGE</constant> event (if they support this) and expect
|
||||
that userspace will take action by calling <constant>VIDIOC_QUERYSTD</constant>.
|
||||
The reason is that a new video standard can mean different buffer sizes as well, and you
|
||||
cannot change buffer sizes on the fly. In general, applications that receive the
|
||||
Source Change event will have to call <constant>VIDIOC_QUERYSTD</constant>,
|
||||
and if the detected video standard is valid they will have to stop streaming, set the new
|
||||
standard, allocate new buffers and start streaming again.</para>
|
||||
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
|
|
|||
|
|
@ -732,6 +732,18 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param)
|
|||
or SET_INTERFACE.
|
||||
</para></warning></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term>USBDEVFS_DROP_PRIVILEGES</term>
|
||||
<listitem><para>This is used to relinquish the ability
|
||||
to do certain operations which are considered to be
|
||||
privileged on a usbfs file descriptor.
|
||||
This includes claiming arbitrary interfaces, resetting
|
||||
a device on which there are currently claimed interfaces
|
||||
from other users, and issuing USBDEVFS_IOCTL calls.
|
||||
The ioctl parameter is a 32 bit mask of interfaces
|
||||
the user is allowed to claim on this file descriptor.
|
||||
You may issue this ioctl more than one time to narrow
|
||||
said mask.
|
||||
</para></listitem></varlistentry>
|
||||
</variablelist>
|
||||
|
||||
</sect2>
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ For common questions and answers about the GPL, please see:
|
|||
|
||||
|
||||
Documentation
|
||||
------------
|
||||
-------------
|
||||
|
||||
The Linux kernel source tree has a large range of documents that are
|
||||
invaluable for learning how to interact with the kernel community. When
|
||||
|
|
@ -187,7 +187,7 @@ apply a patch.
|
|||
If you do not know where you want to start, but you want to look for
|
||||
some task to start doing to join into the kernel development community,
|
||||
go to the Linux Kernel Janitor's project:
|
||||
http://kernelnewbies.org/KernelJanitors
|
||||
http://kernelnewbies.org/KernelJanitors
|
||||
It is a great place to start. It describes a list of relatively simple
|
||||
problems that need to be cleaned up and fixed within the Linux kernel
|
||||
source tree. Working with the developers in charge of this project, you
|
||||
|
|
@ -250,11 +250,6 @@ process is as follows:
|
|||
release a new -rc kernel every week.
|
||||
- Process continues until the kernel is considered "ready", the
|
||||
process should last around 6 weeks.
|
||||
- Known regressions in each release are periodically posted to the
|
||||
linux-kernel mailing list. The goal is to reduce the length of
|
||||
that list to zero before declaring the kernel to be "ready," but, in
|
||||
the real world, a small number of regressions often remain at
|
||||
release time.
|
||||
|
||||
It is worth mentioning what Andrew Morton wrote on the linux-kernel
|
||||
mailing list about kernel releases:
|
||||
|
|
@ -263,7 +258,7 @@ mailing list about kernel releases:
|
|||
preconceived timeline."
|
||||
|
||||
4.x.y -stable kernel tree
|
||||
---------------------------
|
||||
-------------------------
|
||||
Kernels with 3-part versions are -stable kernels. They contain
|
||||
relatively small and critical fixes for security problems or significant
|
||||
regressions discovered in a given 4.x kernel.
|
||||
|
|
@ -286,7 +281,7 @@ documents what kinds of changes are acceptable for the -stable tree, and
|
|||
how the release process works.
|
||||
|
||||
4.x -git patches
|
||||
------------------
|
||||
----------------
|
||||
These are daily snapshots of Linus' kernel tree which are managed in a
|
||||
git repository (hence the name.) These patches are usually released
|
||||
daily and represent the current state of Linus' tree. They are more
|
||||
|
|
@ -318,7 +313,7 @@ accepted, or rejected. Most of these patchwork sites are listed at
|
|||
http://patchwork.kernel.org/.
|
||||
|
||||
4.x -next kernel tree for integration tests
|
||||
---------------------------------------------
|
||||
-------------------------------------------
|
||||
Before updates from subsystem trees are merged into the mainline 4.x
|
||||
tree, they need to be integration-tested. For this purpose, a special
|
||||
testing repository exists into which virtually all subsystem trees are
|
||||
|
|
|
|||
|
|
@ -722,7 +722,7 @@ references.
|
|||
--------------------------------
|
||||
|
||||
It can be helpful to manually add In-Reply-To: headers to a patch
|
||||
(e.g., when using "git send email") to associate the patch with
|
||||
(e.g., when using "git send-email") to associate the patch with
|
||||
previous relevant discussion, e.g. to link a bug fix to the email with
|
||||
the bug report. However, for a multi-patch series, it is generally
|
||||
best to avoid using In-Reply-To: to link to older versions of the
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Orion family
|
|||
88F5281
|
||||
Datasheet : http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf
|
||||
88F6183
|
||||
Core: Feroceon ARMv5 compatible
|
||||
Core: Feroceon 88fr331 (88f51xx) or 88fr531-vd (88f52xx) ARMv5 compatible
|
||||
Linux kernel mach directory: arch/arm/mach-orion5x
|
||||
Linux kernel plat directory: arch/arm/plat-orion
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ Kirkwood family
|
|||
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
|
||||
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
|
||||
Homepage: http://www.marvell.com/embedded-processors/kirkwood/
|
||||
Core: Feroceon ARMv5 compatible
|
||||
Core: Feroceon 88fr131 ARMv5 compatible
|
||||
Linux kernel mach directory: arch/arm/mach-mvebu
|
||||
Linux kernel plat directory: none
|
||||
|
||||
|
|
@ -71,7 +71,7 @@ Discovery family
|
|||
MV76100
|
||||
Not supported by the Linux kernel.
|
||||
|
||||
Core: Feroceon ARMv5 compatible
|
||||
Core: Feroceon 88fr571-vd ARMv5 compatible
|
||||
|
||||
Linux kernel mach directory: arch/arm/mach-mv78xx0
|
||||
Linux kernel plat directory: arch/arm/plat-orion
|
||||
|
|
@ -86,20 +86,26 @@ EBU Armada family
|
|||
Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
|
||||
Hardware Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf
|
||||
Functional Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf
|
||||
Core: Sheeva ARMv7 compatible PJ4B
|
||||
|
||||
Armada 375 Flavors:
|
||||
88F6720
|
||||
Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf
|
||||
Core: ARM Cortex-A9
|
||||
|
||||
Armada 380/385 Flavors:
|
||||
88F6810
|
||||
88F6820
|
||||
88F6828
|
||||
Armada 38x Flavors:
|
||||
88F6810 Armada 380
|
||||
88F6820 Armada 385
|
||||
88F6828 Armada 388
|
||||
Product infos: http://www.marvell.com/embedded-processors/armada-38x/
|
||||
Functional Spec: https://marvellcorp.wufoo.com/forms/marvell-armada-38x-functional-specifications/
|
||||
Core: ARM Cortex-A9
|
||||
|
||||
Armada 390/398 Flavors:
|
||||
88F6920
|
||||
88F6928
|
||||
Armada 39x Flavors:
|
||||
88F6920 Armada 390
|
||||
88F6928 Armada 398
|
||||
Product infos: http://www.marvell.com/embedded-processors/armada-39x/
|
||||
Core: ARM Cortex-A9
|
||||
|
||||
Armada XP Flavors:
|
||||
MV78230
|
||||
|
|
@ -112,12 +118,43 @@ EBU Armada family
|
|||
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF
|
||||
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF
|
||||
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF
|
||||
|
||||
Core: Sheeva ARMv7 compatible
|
||||
Core: Sheeva ARMv7 compatible Dual-core or Quad-core PJ4B-MP
|
||||
|
||||
Linux kernel mach directory: arch/arm/mach-mvebu
|
||||
Linux kernel plat directory: none
|
||||
|
||||
EBU Armada family ARMv8
|
||||
-----------------------
|
||||
|
||||
Armada 3710/3720 Flavors:
|
||||
88F3710
|
||||
88F3720
|
||||
Core: ARM Cortex A53 (ARMv8)
|
||||
|
||||
Homepage: http://www.marvell.com/embedded-processors/armada-3700/
|
||||
Product Brief: http://www.marvell.com/embedded-processors/assets/PB-88F3700-FNL.pdf
|
||||
Device tree files: arch/arm64/boot/dts/marvell/armada-37*
|
||||
|
||||
Armada 7K Flavors:
|
||||
88F7020 (AP806 Dual + one CP110)
|
||||
88F7040 (AP806 Quad + one CP110)
|
||||
Core: ARM Cortex A72
|
||||
|
||||
Homepage: http://www.marvell.com/embedded-processors/armada-70xx/
|
||||
Product Brief: http://www.marvell.com/embedded-processors/assets/Armada7020PB-Jan2016.pdf
|
||||
http://www.marvell.com/embedded-processors/assets/Armada7040PB-Jan2016.pdf
|
||||
Device tree files: arch/arm64/boot/dts/marvell/armada-70*
|
||||
|
||||
Armada 8K Flavors:
|
||||
88F8020 (AP806 Dual + two CP110)
|
||||
88F8040 (AP806 Quad + two CP110)
|
||||
Core: ARM Cortex A72
|
||||
|
||||
Homepage: http://www.marvell.com/embedded-processors/armada-80xx/
|
||||
Product Brief: http://www.marvell.com/embedded-processors/assets/Armada8020PB-Jan2016.pdf
|
||||
http://www.marvell.com/embedded-processors/assets/Armada8040PB-Jan2016.pdf
|
||||
Device tree files: arch/arm64/boot/dts/marvell/armada-80*
|
||||
|
||||
Avanta family
|
||||
-------------
|
||||
|
||||
|
|
@ -135,6 +172,15 @@ Avanta family
|
|||
Linux kernel mach directory: no code in mainline yet, planned for the future
|
||||
Linux kernel plat directory: no code in mainline yet, planned for the future
|
||||
|
||||
Storage family
|
||||
--------------
|
||||
|
||||
Armada SP:
|
||||
88RC1580
|
||||
Product infos: http://www.marvell.com/storage/armada-sp/
|
||||
Core: Sheeva ARMv7 comatible Quad-core PJ4C
|
||||
(not supported in upstream Linux kernel)
|
||||
|
||||
Dove family (application processor)
|
||||
-----------------------------------
|
||||
|
||||
|
|
@ -155,7 +201,7 @@ PXA 2xx/3xx/93x/95x family
|
|||
Flavors:
|
||||
PXA21x, PXA25x, PXA26x
|
||||
Application processor only
|
||||
Core: ARMv5 XScale core
|
||||
Core: ARMv5 XScale1 core
|
||||
PXA270, PXA271, PXA272
|
||||
Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_pb.pdf
|
||||
Design guide : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_design_guide.pdf
|
||||
|
|
@ -163,7 +209,7 @@ PXA 2xx/3xx/93x/95x family
|
|||
Specification : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_emts.pdf
|
||||
Specification update : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_spec_update.pdf
|
||||
Application processor only
|
||||
Core: ARMv5 XScale core
|
||||
Core: ARMv5 XScale2 core
|
||||
PXA300, PXA310, PXA320
|
||||
PXA 300 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA300_PB_R4.pdf
|
||||
PXA 310 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA310_PB_R4.pdf
|
||||
|
|
@ -174,10 +220,10 @@ PXA 2xx/3xx/93x/95x family
|
|||
Specification Update : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Spec_Update.zip
|
||||
Reference Manual : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_TavorP_BootROM_Ref_Manual.pdf
|
||||
Application processor only
|
||||
Core: ARMv5 XScale core
|
||||
Core: ARMv5 XScale3 core
|
||||
PXA930, PXA935
|
||||
Application processor with Communication processor
|
||||
Core: ARMv5 XScale core
|
||||
Core: ARMv5 XScale3 core
|
||||
PXA955
|
||||
Application processor with Communication processor
|
||||
Core: ARMv7 compatible Sheeva PJ4 core
|
||||
|
|
@ -196,7 +242,7 @@ PXA 2xx/3xx/93x/95x family
|
|||
Linux kernel mach directory: arch/arm/mach-pxa
|
||||
Linux kernel plat directory: arch/arm/plat-pxa
|
||||
|
||||
MMP/MMP2 family (communication processor)
|
||||
MMP/MMP2/MMP3 family (communication processor)
|
||||
-----------------------------------------
|
||||
|
||||
Flavors:
|
||||
|
|
@ -209,16 +255,32 @@ MMP/MMP2 family (communication processor)
|
|||
Boot ROM manual : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_ref_manual.pdf
|
||||
App node package : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_app_note_package.pdf
|
||||
Application processor only
|
||||
Core: ARMv5 compatible Marvell PJ1 (Mohawk)
|
||||
PXA910
|
||||
Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk)
|
||||
PXA910/PXA920
|
||||
Homepage : http://www.marvell.com/communication-processors/pxa910/
|
||||
Product Brief : http://www.marvell.com/communication-processors/pxa910/assets/Marvell_PXA910_Platform-001_PB_final.pdf
|
||||
Application processor with Communication processor
|
||||
Core: ARMv5 compatible Marvell PJ1 (Mohawk)
|
||||
MMP2, a.k.a Armada 610
|
||||
Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk)
|
||||
PXA688, a.k.a. MMP2, a.k.a Armada 610
|
||||
Product Brief : http://www.marvell.com/application-processors/armada-600/assets/armada610_pb.pdf
|
||||
Application processor only
|
||||
Core: ARMv7 compatible Sheeva PJ4 core
|
||||
Core: ARMv7 compatible Sheeva PJ4 88sv581x core
|
||||
PXA2128, a.k.a. MMP3 (OLPC XO4, Linux support not upstream)
|
||||
Product Brief : http://www.marvell.com/application-processors/armada/pxa2128/assets/Marvell-ARMADA-PXA2128-SoC-PB.pdf
|
||||
Application processor only
|
||||
Core: Dual-core ARMv7 compatible Sheeva PJ4C core
|
||||
PXA960/PXA968/PXA978 (Linux support not upstream)
|
||||
Application processor with Communication Processor
|
||||
Core: ARMv7 compatible Sheeva PJ4 core
|
||||
PXA986/PXA988 (Linux support not upstream)
|
||||
Application processor with Communication Processor
|
||||
Core: Dual-core ARMv7 compatible Sheeva PJ4B-MP core
|
||||
PXA1088/PXA1920 (Linux support not upstream)
|
||||
Application processor with Communication Processor
|
||||
Core: quad-core ARMv7 Cortex-A7
|
||||
PXA1908/PXA1928/PXA1936
|
||||
Application processor with Communication Processor
|
||||
Core: multi-core ARMv8 Cortex-A53
|
||||
|
||||
Comments:
|
||||
|
||||
|
|
@ -237,6 +299,10 @@ Berlin family (Multimedia Solutions)
|
|||
-------------------------------------
|
||||
|
||||
Flavors:
|
||||
88DE3010, Armada 1000 (no Linux support)
|
||||
Core: Marvell PJ1 (ARMv5TE), Dual-core
|
||||
Product Brief: http://www.marvell.com.cn/digital-entertainment/assets/armada_1000_pb.pdf
|
||||
88DE3005, Armada 1500-mini
|
||||
88DE3005, Armada 1500 Mini
|
||||
Design name: BG2CD
|
||||
Core: ARM Cortex-A9, PL310 L2CC
|
||||
|
|
@ -247,14 +313,16 @@ Berlin family (Multimedia Solutions)
|
|||
Homepage: http://www.marvell.com/multimedia-solutions/armada-1500-mini-plus/
|
||||
88DE3100, Armada 1500
|
||||
Design name: BG2
|
||||
Core: Marvell PJ4B (ARMv7), Tauros3 L2CC
|
||||
Product Brief: http://www.marvell.com/multimedia-solutions/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
|
||||
Core: Marvell PJ4B-MP (ARMv7), Tauros3 L2CC
|
||||
Product Brief: http://www.marvell.com/digital-entertainment/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
|
||||
88DE3114, Armada 1500 Pro
|
||||
Design name: BG2Q
|
||||
Core: Quad Core ARM Cortex-A9, PL310 L2CC
|
||||
88DE????
|
||||
88DE3214, Armada 1500 Pro 4K
|
||||
Design name: BG3
|
||||
Core: ARM Cortex-A15, CA15 integrated L2CC
|
||||
88DE3218, ARMADA 1500 Ultra
|
||||
Core: ARM Cortex-A53
|
||||
|
||||
Homepage: http://www.marvell.com/multimedia-solutions/
|
||||
Directory: arch/arm/mach-berlin
|
||||
|
|
@ -263,6 +331,49 @@ Berlin family (Multimedia Solutions)
|
|||
* This line of SoCs is based on Marvell Sheeva or ARM Cortex CPUs
|
||||
with Synopsys DesignWare (IRQ, GPIO, Timers, ...) and PXA IP (SDHCI, USB, ETH, ...).
|
||||
|
||||
CPU Cores
|
||||
---------
|
||||
|
||||
The XScale cores were designed by Intel, and shipped by Marvell in the older
|
||||
PXA processors. Feroceon is a Marvell designed core that developed in-house,
|
||||
and that evolved into Sheeva. The XScale and Feroceon cores were phased out
|
||||
over time and replaced with Sheeva cores in later products, which subsequently
|
||||
got replaced with licensed ARM Cortex-A cores.
|
||||
|
||||
XScale 1
|
||||
CPUID 0x69052xxx
|
||||
ARMv5, iWMMXt
|
||||
XScale 2
|
||||
CPUID 0x69054xxx
|
||||
ARMv5, iWMMXt
|
||||
XScale 3
|
||||
CPUID 0x69056xxx or 0x69056xxx
|
||||
ARMv5, iWMMXt
|
||||
Feroceon-1850 88fr331 "Mohawk"
|
||||
CPUID 0x5615331x or 0x41xx926x
|
||||
ARMv5TE, single issue
|
||||
Feroceon-2850 88fr531-vd "Jolteon"
|
||||
CPUID 0x5605531x or 0x41xx926x
|
||||
ARMv5TE, VFP, dual-issue
|
||||
Feroceon 88fr571-vd "Jolteon"
|
||||
CPUID 0x5615571x
|
||||
ARMv5TE, VFP, dual-issue
|
||||
Feroceon 88fr131 "Mohawk-D"
|
||||
CPUID 0x5625131x
|
||||
ARMv5TE, single-issue in-order
|
||||
Sheeva PJ1 88sv331 "Mohawk"
|
||||
CPUID 0x561584xx
|
||||
ARMv5, single-issue iWMMXt v2
|
||||
Sheeva PJ4 88sv581x "Flareon"
|
||||
CPUID 0x560f581x
|
||||
ARMv7, idivt, optional iWMMXt v2
|
||||
Sheeva PJ4B 88sv581x
|
||||
CPUID 0x561f581x
|
||||
ARMv7, idivt, optional iWMMXt v2
|
||||
Sheeva PJ4B-MP / PJ4C
|
||||
CPUID 0x562f584x
|
||||
ARMv7, idivt/idiva, LPAE, optional iWMMXt v2 and/or NEON
|
||||
|
||||
Long-term plans
|
||||
---------------
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ function find_length(f)
|
|||
else if (f ~ /0xf/)
|
||||
return 4
|
||||
|
||||
printf "unknown legnth " f "\n" > "/dev/stderr"
|
||||
printf "unknown length " f "\n" > "/dev/stderr"
|
||||
exit
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -72,6 +72,5 @@ SunXi family
|
|||
|
||||
* Octa ARM Cortex-A7 based SoCs
|
||||
- Allwinner A83T
|
||||
+ Not Supported
|
||||
+ Datasheet
|
||||
http://dl.linux-sunxi.org/A83T/A83T_datasheet_Revision_1.1.pdf
|
||||
|
|
|
|||
|
|
@ -109,7 +109,13 @@ Header notes:
|
|||
1 - 4K
|
||||
2 - 16K
|
||||
3 - 64K
|
||||
Bits 3-63: Reserved.
|
||||
Bit 3: Kernel physical placement
|
||||
0 - 2MB aligned base should be as close as possible
|
||||
to the base of DRAM, since memory below it is not
|
||||
accessible via the linear mapping
|
||||
1 - 2MB aligned base may be anywhere in physical
|
||||
memory
|
||||
Bits 4-63: Reserved.
|
||||
|
||||
- When image_size is zero, a bootloader should attempt to keep as much
|
||||
memory as possible free for use by the kernel immediately after the
|
||||
|
|
@ -117,14 +123,14 @@ Header notes:
|
|||
depending on selected features, and is effectively unbound.
|
||||
|
||||
The Image must be placed text_offset bytes from a 2MB aligned base
|
||||
address near the start of usable system RAM and called there. Memory
|
||||
below that base address is currently unusable by Linux, and therefore it
|
||||
is strongly recommended that this location is the start of system RAM.
|
||||
The region between the 2 MB aligned base address and the start of the
|
||||
image has no special significance to the kernel, and may be used for
|
||||
other purposes.
|
||||
address anywhere in usable system RAM and called there. The region
|
||||
between the 2 MB aligned base address and the start of the image has no
|
||||
special significance to the kernel, and may be used for other purposes.
|
||||
At least image_size bytes from the start of the image must be free for
|
||||
use by the kernel.
|
||||
NOTE: versions prior to v4.6 cannot make use of memory below the
|
||||
physical offset of the Image so it is recommended that the Image be
|
||||
placed as close as possible to the start of system RAM.
|
||||
|
||||
Any memory described to the kernel (even that below the start of the
|
||||
image) which is not marked as reserved from the kernel (e.g., with a
|
||||
|
|
|
|||
|
|
@ -56,3 +56,4 @@ stable kernels.
|
|||
| | | | |
|
||||
| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
|
||||
| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
|
||||
| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
|
||||
|
|
|
|||
|
|
@ -1,93 +0,0 @@
|
|||
This driver is for Compaq's SMART2 Intelligent Disk Array Controllers.
|
||||
|
||||
Supported Cards:
|
||||
----------------
|
||||
|
||||
This driver is known to work with the following cards:
|
||||
|
||||
* SMART (EISA)
|
||||
* SMART-2/E (EISA)
|
||||
* SMART-2/P
|
||||
* SMART-2DH
|
||||
* SMART-2SL
|
||||
* SMART-221
|
||||
* SMART-3100ES
|
||||
* SMART-3200
|
||||
* Integrated Smart Array Controller
|
||||
* SA 4200
|
||||
* SA 4250ES
|
||||
* SA 431
|
||||
* RAID LC2 Controller
|
||||
|
||||
It should also work with some really old Disk array adapters, but I am
|
||||
unable to test against these cards:
|
||||
|
||||
* IDA
|
||||
* IDA-2
|
||||
* IAES
|
||||
|
||||
|
||||
EISA Controllers:
|
||||
-----------------
|
||||
|
||||
If you want to use an EISA controller you'll have to supply some
|
||||
modprobe/lilo parameters. If the driver is compiled into the kernel, must
|
||||
give it the controller's IO port address at boot time (it is not
|
||||
necessary to specify the IRQ). For example, if you had two SMART-2/E
|
||||
controllers, in EISA slots 1 and 2 you'd give it a boot argument like
|
||||
this:
|
||||
|
||||
smart2=0x1000,0x2000
|
||||
|
||||
If you were loading the driver as a module, you'd give load it like this:
|
||||
|
||||
modprobe cpqarray eisa=0x1000,0x2000
|
||||
|
||||
You can use EISA and PCI adapters at the same time.
|
||||
|
||||
|
||||
Device Naming:
|
||||
--------------
|
||||
|
||||
You need some entries in /dev for the ida device. MAKEDEV in the /dev
|
||||
directory can make device nodes for you automatically. The device setup is
|
||||
as follows:
|
||||
|
||||
Major numbers:
|
||||
72 ida0
|
||||
73 ida1
|
||||
74 ida2
|
||||
75 ida3
|
||||
76 ida4
|
||||
77 ida5
|
||||
78 ida6
|
||||
79 ida7
|
||||
|
||||
Minor numbers:
|
||||
b7 b6 b5 b4 b3 b2 b1 b0
|
||||
|----+----| |----+----|
|
||||
| |
|
||||
| +-------- Partition ID (0=wholedev, 1-15 partition)
|
||||
|
|
||||
+-------------------- Logical Volume number
|
||||
|
||||
The device naming scheme is:
|
||||
/dev/ida/c0d0 Controller 0, disk 0, whole device
|
||||
/dev/ida/c0d0p1 Controller 0, disk 0, partition 1
|
||||
/dev/ida/c0d0p2 Controller 0, disk 0, partition 2
|
||||
/dev/ida/c0d0p3 Controller 0, disk 0, partition 3
|
||||
|
||||
/dev/ida/c1d1 Controller 1, disk 1, whole device
|
||||
/dev/ida/c1d1p1 Controller 1, disk 1, partition 1
|
||||
/dev/ida/c1d1p2 Controller 1, disk 1, partition 2
|
||||
/dev/ida/c1d1p3 Controller 1, disk 1, partition 3
|
||||
|
||||
|
||||
Changelog:
|
||||
==========
|
||||
|
||||
10-28-2004 : General cleanup, syntax fixes for in-kernel driver version.
|
||||
James Nelson <james4765@gmail.com>
|
||||
|
||||
|
||||
1999 : Original Document
|
||||
|
|
@ -24,5 +24,3 @@ net_prio.txt
|
|||
- Network priority cgroups details and usages.
|
||||
pids.txt
|
||||
- Process number cgroups details and usages.
|
||||
unified-hierarchy.txt
|
||||
- Description the new/next cgroup interface.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Original copyright statements from cpusets.txt:
|
|||
Portions Copyright (C) 2004 BULL SA.
|
||||
Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
|
||||
Modified by Paul Jackson <pj@sgi.com>
|
||||
Modified by Christoph Lameter <clameter@sgi.com>
|
||||
Modified by Christoph Lameter <cl@linux.com>
|
||||
|
||||
CONTENTS:
|
||||
=========
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Written by Simon.Derr@bull.net
|
|||
|
||||
Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
|
||||
Modified by Paul Jackson <pj@sgi.com>
|
||||
Modified by Christoph Lameter <clameter@sgi.com>
|
||||
Modified by Christoph Lameter <cl@linux.com>
|
||||
Modified by Paul Menage <menage@google.com>
|
||||
Modified by Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
|
||||
|
||||
|
|
|
|||
|
|
@ -47,6 +47,11 @@ CONTENTS
|
|||
5-3. IO
|
||||
5-3-1. IO Interface Files
|
||||
5-3-2. Writeback
|
||||
6. Namespace
|
||||
6-1. Basics
|
||||
6-2. The Root and Views
|
||||
6-3. Migration and setns(2)
|
||||
6-4. Interaction with Other Namespaces
|
||||
P. Information on Kernel Programming
|
||||
P-1. Filesystem Support for Writeback
|
||||
D. Deprecated v1 Core Features
|
||||
|
|
@ -132,6 +137,12 @@ strongly discouraged for production use. It is recommended to decide
|
|||
the hierarchies and controller associations before starting using the
|
||||
controllers after system boot.
|
||||
|
||||
During transition to v2, system management software might still
|
||||
automount the v1 cgroup filesystem and so hijack all controllers
|
||||
during boot, before manual intervention is possible. To make testing
|
||||
and experimenting easier, the kernel parameter cgroup_no_v1= allows
|
||||
disabling controllers in v1 and make them always available in v2.
|
||||
|
||||
|
||||
2-2. Organizing Processes
|
||||
|
||||
|
|
@ -843,6 +854,15 @@ PAGE_SIZE multiple when read back.
|
|||
Amount of memory used to cache filesystem data,
|
||||
including tmpfs and shared memory.
|
||||
|
||||
kernel_stack
|
||||
|
||||
Amount of memory allocated to kernel stacks.
|
||||
|
||||
slab
|
||||
|
||||
Amount of memory used for storing in-kernel data
|
||||
structures.
|
||||
|
||||
sock
|
||||
|
||||
Amount of memory used in network transmission buffers
|
||||
|
|
@ -871,6 +891,16 @@ PAGE_SIZE multiple when read back.
|
|||
on the internal memory management lists used by the
|
||||
page reclaim algorithm
|
||||
|
||||
slab_reclaimable
|
||||
|
||||
Part of "slab" that might be reclaimed, such as
|
||||
dentries and inodes.
|
||||
|
||||
slab_unreclaimable
|
||||
|
||||
Part of "slab" that cannot be reclaimed on memory
|
||||
pressure.
|
||||
|
||||
pgfault
|
||||
|
||||
Total number of page faults incurred
|
||||
|
|
@ -896,7 +926,7 @@ PAGE_SIZE multiple when read back.
|
|||
limit, anonymous meomry of the cgroup will not be swapped out.
|
||||
|
||||
|
||||
5-2-2. General Usage
|
||||
5-2-2. Usage Guidelines
|
||||
|
||||
"memory.high" is the main mechanism to control memory usage.
|
||||
Over-committing on high limit (sum of high limits > available memory)
|
||||
|
|
@ -1089,6 +1119,148 @@ writeback as follows.
|
|||
vm.dirty[_background]_ratio.
|
||||
|
||||
|
||||
6. Namespace
|
||||
|
||||
6-1. Basics
|
||||
|
||||
cgroup namespace provides a mechanism to virtualize the view of the
|
||||
"/proc/$PID/cgroup" file and cgroup mounts. The CLONE_NEWCGROUP clone
|
||||
flag can be used with clone(2) and unshare(2) to create a new cgroup
|
||||
namespace. The process running inside the cgroup namespace will have
|
||||
its "/proc/$PID/cgroup" output restricted to cgroupns root. The
|
||||
cgroupns root is the cgroup of the process at the time of creation of
|
||||
the cgroup namespace.
|
||||
|
||||
Without cgroup namespace, the "/proc/$PID/cgroup" file shows the
|
||||
complete path of the cgroup of a process. In a container setup where
|
||||
a set of cgroups and namespaces are intended to isolate processes the
|
||||
"/proc/$PID/cgroup" file may leak potential system level information
|
||||
to the isolated processes. For Example:
|
||||
|
||||
# cat /proc/self/cgroup
|
||||
0::/batchjobs/container_id1
|
||||
|
||||
The path '/batchjobs/container_id1' can be considered as system-data
|
||||
and undesirable to expose to the isolated processes. cgroup namespace
|
||||
can be used to restrict visibility of this path. For example, before
|
||||
creating a cgroup namespace, one would see:
|
||||
|
||||
# ls -l /proc/self/ns/cgroup
|
||||
lrwxrwxrwx 1 root root 0 2014-07-15 10:37 /proc/self/ns/cgroup -> cgroup:[4026531835]
|
||||
# cat /proc/self/cgroup
|
||||
0::/batchjobs/container_id1
|
||||
|
||||
After unsharing a new namespace, the view changes.
|
||||
|
||||
# ls -l /proc/self/ns/cgroup
|
||||
lrwxrwxrwx 1 root root 0 2014-07-15 10:35 /proc/self/ns/cgroup -> cgroup:[4026532183]
|
||||
# cat /proc/self/cgroup
|
||||
0::/
|
||||
|
||||
When some thread from a multi-threaded process unshares its cgroup
|
||||
namespace, the new cgroupns gets applied to the entire process (all
|
||||
the threads). This is natural for the v2 hierarchy; however, for the
|
||||
legacy hierarchies, this may be unexpected.
|
||||
|
||||
A cgroup namespace is alive as long as there are processes inside or
|
||||
mounts pinning it. When the last usage goes away, the cgroup
|
||||
namespace is destroyed. The cgroupns root and the actual cgroups
|
||||
remain.
|
||||
|
||||
|
||||
6-2. The Root and Views
|
||||
|
||||
The 'cgroupns root' for a cgroup namespace is the cgroup in which the
|
||||
process calling unshare(2) is running. For example, if a process in
|
||||
/batchjobs/container_id1 cgroup calls unshare, cgroup
|
||||
/batchjobs/container_id1 becomes the cgroupns root. For the
|
||||
init_cgroup_ns, this is the real root ('/') cgroup.
|
||||
|
||||
The cgroupns root cgroup does not change even if the namespace creator
|
||||
process later moves to a different cgroup.
|
||||
|
||||
# ~/unshare -c # unshare cgroupns in some cgroup
|
||||
# cat /proc/self/cgroup
|
||||
0::/
|
||||
# mkdir sub_cgrp_1
|
||||
# echo 0 > sub_cgrp_1/cgroup.procs
|
||||
# cat /proc/self/cgroup
|
||||
0::/sub_cgrp_1
|
||||
|
||||
Each process gets its namespace-specific view of "/proc/$PID/cgroup"
|
||||
|
||||
Processes running inside the cgroup namespace will be able to see
|
||||
cgroup paths (in /proc/self/cgroup) only inside their root cgroup.
|
||||
From within an unshared cgroupns:
|
||||
|
||||
# sleep 100000 &
|
||||
[1] 7353
|
||||
# echo 7353 > sub_cgrp_1/cgroup.procs
|
||||
# cat /proc/7353/cgroup
|
||||
0::/sub_cgrp_1
|
||||
|
||||
From the initial cgroup namespace, the real cgroup path will be
|
||||
visible:
|
||||
|
||||
$ cat /proc/7353/cgroup
|
||||
0::/batchjobs/container_id1/sub_cgrp_1
|
||||
|
||||
From a sibling cgroup namespace (that is, a namespace rooted at a
|
||||
different cgroup), the cgroup path relative to its own cgroup
|
||||
namespace root will be shown. For instance, if PID 7353's cgroup
|
||||
namespace root is at '/batchjobs/container_id2', then it will see
|
||||
|
||||
# cat /proc/7353/cgroup
|
||||
0::/../container_id2/sub_cgrp_1
|
||||
|
||||
Note that the relative path always starts with '/' to indicate that
|
||||
its relative to the cgroup namespace root of the caller.
|
||||
|
||||
|
||||
6-3. Migration and setns(2)
|
||||
|
||||
Processes inside a cgroup namespace can move into and out of the
|
||||
namespace root if they have proper access to external cgroups. For
|
||||
example, from inside a namespace with cgroupns root at
|
||||
/batchjobs/container_id1, and assuming that the global hierarchy is
|
||||
still accessible inside cgroupns:
|
||||
|
||||
# cat /proc/7353/cgroup
|
||||
0::/sub_cgrp_1
|
||||
# echo 7353 > batchjobs/container_id2/cgroup.procs
|
||||
# cat /proc/7353/cgroup
|
||||
0::/../container_id2
|
||||
|
||||
Note that this kind of setup is not encouraged. A task inside cgroup
|
||||
namespace should only be exposed to its own cgroupns hierarchy.
|
||||
|
||||
setns(2) to another cgroup namespace is allowed when:
|
||||
|
||||
(a) the process has CAP_SYS_ADMIN against its current user namespace
|
||||
(b) the process has CAP_SYS_ADMIN against the target cgroup
|
||||
namespace's userns
|
||||
|
||||
No implicit cgroup changes happen with attaching to another cgroup
|
||||
namespace. It is expected that the someone moves the attaching
|
||||
process under the target cgroup namespace root.
|
||||
|
||||
|
||||
6-4. Interaction with Other Namespaces
|
||||
|
||||
Namespace specific cgroup hierarchy can be mounted by a process
|
||||
running inside a non-init cgroup namespace.
|
||||
|
||||
# mount -t cgroup2 none $MOUNT_POINT
|
||||
|
||||
This will mount the unified cgroup hierarchy with cgroupns root as the
|
||||
filesystem root. The process needs CAP_SYS_ADMIN against its user and
|
||||
mount namespaces.
|
||||
|
||||
The virtualization of /proc/self/cgroup file combined with restricting
|
||||
the view of cgroup hierarchy by namespace-private cgroupfs mount
|
||||
provides a properly isolated cgroup view inside the container.
|
||||
|
||||
|
||||
P. Information on Kernel Programming
|
||||
|
||||
This section contains kernel programming information in the areas
|
||||
|
|
@ -1368,6 +1540,12 @@ system than killing the group. Otherwise, memory.max is there to
|
|||
limit this type of spillover and ultimately contain buggy or even
|
||||
malicious applications.
|
||||
|
||||
Setting the original memory.limit_in_bytes below the current usage was
|
||||
subject to a race condition, where concurrent charges could cause the
|
||||
limit setting to fail. memory.max on the other hand will first set the
|
||||
limit to prevent new charges, and then reclaim and OOM kill until the
|
||||
new limit is met - or the task writing to memory.max is killed.
|
||||
|
||||
The combined memory+swap accounting and limiting is replaced by real
|
||||
control over swap space.
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ callback, so cpufreq core can't request a transition to a specific frequency.
|
|||
The driver provides minimum and maximum frequency limits and callbacks to set a
|
||||
policy. The policy in cpufreq sysfs is referred to as the "scaling governor".
|
||||
The cpufreq core can request the driver to operate in any of the two policies:
|
||||
"performance: and "powersave". The driver decides which frequency to use based
|
||||
"performance" and "powersave". The driver decides which frequency to use based
|
||||
on the above policy selection considering minimum and maximum frequency limits.
|
||||
|
||||
The Intel P-State driver falls under the latter category, which implements the
|
||||
|
|
|
|||
|
|
@ -49,28 +49,33 @@ under development.
|
|||
|
||||
Here's an example of how to use the API:
|
||||
|
||||
#include <linux/crypto.h>
|
||||
#include <crypto/ahash.h>
|
||||
#include <linux/err.h>
|
||||
#include <linux/scatterlist.h>
|
||||
|
||||
struct scatterlist sg[2];
|
||||
char result[128];
|
||||
struct crypto_hash *tfm;
|
||||
struct hash_desc desc;
|
||||
struct crypto_ahash *tfm;
|
||||
struct ahash_request *req;
|
||||
|
||||
tfm = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
|
||||
tfm = crypto_alloc_ahash("md5", 0, CRYPTO_ALG_ASYNC);
|
||||
if (IS_ERR(tfm))
|
||||
fail();
|
||||
|
||||
/* ... set up the scatterlists ... */
|
||||
|
||||
desc.tfm = tfm;
|
||||
desc.flags = 0;
|
||||
|
||||
if (crypto_hash_digest(&desc, sg, 2, result))
|
||||
req = ahash_request_alloc(tfm, GFP_ATOMIC);
|
||||
if (!req)
|
||||
fail();
|
||||
|
||||
ahash_request_set_callback(req, 0, NULL, NULL);
|
||||
ahash_request_set_crypt(req, sg, result, 2);
|
||||
|
||||
crypto_free_hash(tfm);
|
||||
if (crypto_ahash_digest(req))
|
||||
fail();
|
||||
|
||||
ahash_request_free(req);
|
||||
crypto_free_ahash(tfm);
|
||||
|
||||
|
||||
Many real examples are available in the regression test module (tcrypt.c).
|
||||
|
|
|
|||
|
|
@ -28,51 +28,16 @@ Overview of supplied cache replacement policies
|
|||
multiqueue (mq)
|
||||
---------------
|
||||
|
||||
This policy has been deprecated in favor of the smq policy (see below).
|
||||
This policy is now an alias for smq (see below).
|
||||
|
||||
The multiqueue policy has three sets of 16 queues: one set for entries
|
||||
waiting for the cache and another two for those in the cache (a set for
|
||||
clean entries and a set for dirty entries).
|
||||
The following tunables are accepted, but have no effect:
|
||||
|
||||
Cache entries in the queues are aged based on logical time. Entry into
|
||||
the cache is based on variable thresholds and queue selection is based
|
||||
on hit count on entry. The policy aims to take different cache miss
|
||||
costs into account and to adjust to varying load patterns automatically.
|
||||
|
||||
Message and constructor argument pairs are:
|
||||
'sequential_threshold <#nr_sequential_ios>'
|
||||
'random_threshold <#nr_random_ios>'
|
||||
'read_promote_adjustment <value>'
|
||||
'write_promote_adjustment <value>'
|
||||
'discard_promote_adjustment <value>'
|
||||
|
||||
The sequential threshold indicates the number of contiguous I/Os
|
||||
required before a stream is treated as sequential. Once a stream is
|
||||
considered sequential it will bypass the cache. The random threshold
|
||||
is the number of intervening non-contiguous I/Os that must be seen
|
||||
before the stream is treated as random again.
|
||||
|
||||
The sequential and random thresholds default to 512 and 4 respectively.
|
||||
|
||||
Large, sequential I/Os are probably better left on the origin device
|
||||
since spindles tend to have good sequential I/O bandwidth. The
|
||||
io_tracker counts contiguous I/Os to try to spot when the I/O is in one
|
||||
of these sequential modes. But there are use-cases for wanting to
|
||||
promote sequential blocks to the cache (e.g. fast application startup).
|
||||
If sequential threshold is set to 0 the sequential I/O detection is
|
||||
disabled and sequential I/O will no longer implicitly bypass the cache.
|
||||
Setting the random threshold to 0 does _not_ disable the random I/O
|
||||
stream detection.
|
||||
|
||||
Internally the mq policy determines a promotion threshold. If the hit
|
||||
count of a block not in the cache goes above this threshold it gets
|
||||
promoted to the cache. The read, write and discard promote adjustment
|
||||
tunables allow you to tweak the promotion threshold by adding a small
|
||||
value based on the io type. They default to 4, 8 and 1 respectively.
|
||||
If you're trying to quickly warm a new cache device you may wish to
|
||||
reduce these to encourage promotion. Remember to switch them back to
|
||||
their defaults after the cache fills though.
|
||||
|
||||
Stochastic multiqueue (smq)
|
||||
---------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,49 @@
|
|||
Altera SoCFPGA ECC Manager
|
||||
This driver uses the EDAC framework to implement the SOCFPGA ECC Manager.
|
||||
The ECC Manager counts and corrects single bit errors and counts/handles
|
||||
double bit errors which are uncorrectable.
|
||||
|
||||
Required Properties:
|
||||
- compatible : Should be "altr,socfpga-ecc-manager"
|
||||
- #address-cells: must be 1
|
||||
- #size-cells: must be 1
|
||||
- ranges : standard definition, should translate from local addresses
|
||||
|
||||
Subcomponents:
|
||||
|
||||
L2 Cache ECC
|
||||
Required Properties:
|
||||
- compatible : Should be "altr,socfpga-l2-ecc"
|
||||
- reg : Address and size for ECC error interrupt clear registers.
|
||||
- interrupts : Should be single bit error interrupt, then double bit error
|
||||
interrupt. Note the rising edge type.
|
||||
|
||||
On Chip RAM ECC
|
||||
Required Properties:
|
||||
- compatible : Should be "altr,socfpga-ocram-ecc"
|
||||
- reg : Address and size for ECC error interrupt clear registers.
|
||||
- iram : phandle to On-Chip RAM definition.
|
||||
- interrupts : Should be single bit error interrupt, then double bit error
|
||||
interrupt. Note the rising edge type.
|
||||
|
||||
Example:
|
||||
|
||||
eccmgr: eccmgr@ffd08140 {
|
||||
compatible = "altr,socfpga-ecc-manager";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges;
|
||||
|
||||
l2-ecc@ffd08140 {
|
||||
compatible = "altr,socfpga-l2-ecc";
|
||||
reg = <0xffd08140 0x4>;
|
||||
interrupts = <0 36 1>, <0 37 1>;
|
||||
};
|
||||
|
||||
ocram-ecc@ffd08144 {
|
||||
compatible = "altr,socfpga-ocram-ecc";
|
||||
reg = <0xffd08144 0x4>;
|
||||
iram = <&ocram>;
|
||||
interrupts = <0 178 1>, <0 179 1>;
|
||||
};
|
||||
};
|
||||
|
|
@ -13,8 +13,15 @@ Boards with the Amlogic Meson8b SoC shall have the following properties:
|
|||
Required root node property:
|
||||
compatible: "amlogic,meson8b";
|
||||
|
||||
Boards with the Amlogic Meson GXBaby SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible: "amlogic,meson-gxbb";
|
||||
|
||||
Board compatible values:
|
||||
- "geniatech,atv1200" (Meson6)
|
||||
- "minix,neo-x8" (Meson8)
|
||||
- "tronfy,mxq" (Meson8b)
|
||||
- "hardkernel,odroid-c1" (Meson8b)
|
||||
- "tronsmart,vega-s95-pro", "tronsmart,vega-s95" (Meson gxbb)
|
||||
- "tronsmart,vega-s95-meta", "tronsmart,vega-s95" (Meson gxbb)
|
||||
- "tronsmart,vega-s95-telos", "tronsmart,vega-s95" (Meson gxbb)
|
||||
|
|
|
|||
|
|
@ -123,7 +123,9 @@ Required nodes:
|
|||
|
||||
- syscon: some subnode of the RealView SoC node must be a
|
||||
system controller node pointing to the control registers,
|
||||
with the compatible string set to one of these tuples:
|
||||
with the compatible string set to one of these:
|
||||
"arm,realview-eb11mp-revb-syscon", "arm,realview-eb-syscon", "syscon"
|
||||
"arm,realview-eb11mp-revc-syscon", "arm,realview-eb-syscon", "syscon"
|
||||
"arm,realview-eb-syscon", "syscon"
|
||||
"arm,realview-pb1176-syscon", "syscon"
|
||||
"arm,realview-pb11mp-syscon", "syscon"
|
||||
|
|
@ -180,6 +182,7 @@ described under the RS1 memory mapping.
|
|||
Required properties (in root node):
|
||||
compatible = "arm,juno"; /* For Juno r0 board */
|
||||
compatible = "arm,juno-r1"; /* For Juno r1 board */
|
||||
compatible = "arm,juno-r2"; /* For Juno r2 board */
|
||||
|
||||
Required nodes:
|
||||
The description for the board must include:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,29 @@
|
|||
Axis Communications AB
|
||||
ARTPEC series SoC Device Tree Bindings
|
||||
|
||||
ARTPEC-6 ARM SoC
|
||||
================
|
||||
|
||||
Required root node properties:
|
||||
- compatible = "axis,artpec6";
|
||||
|
||||
ARTPEC-6 System Controller
|
||||
--------------------------
|
||||
|
||||
The ARTPEC-6 has a system controller with mixed functions controlling DMA, PCIe
|
||||
and resets.
|
||||
|
||||
Required properties:
|
||||
- compatible: "axis,artpec6-syscon", "syscon"
|
||||
- reg: Address and length of the register bank.
|
||||
|
||||
Example:
|
||||
syscon {
|
||||
compatible = "axis,artpec6-syscon", "syscon";
|
||||
reg = <0xf8000000 0x48>;
|
||||
};
|
||||
|
||||
ARTPEC-6 Development board:
|
||||
---------------------------
|
||||
Required root node properties:
|
||||
- compatible = "axis,artpec6-dev-board", "axis,artpec6";
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
Broadcom Vulcan device tree bindings
|
||||
------------------------------------
|
||||
|
||||
Boards with Broadcom Vulcan shall have the following root property:
|
||||
|
||||
Broadcom Vulcan Evaluation Board:
|
||||
compatible = "brcm,vulcan-eval", "brcm,vulcan-soc";
|
||||
|
||||
Generic Vulcan board:
|
||||
compatible = "brcm,vulcan-soc";
|
||||
|
|
@ -34,6 +34,7 @@ specific to ARM.
|
|||
Definition: must contain one of the following:
|
||||
"arm,cci-400"
|
||||
"arm,cci-500"
|
||||
"arm,cci-550"
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
|
|
@ -101,6 +102,7 @@ specific to ARM.
|
|||
"arm,cci-400-pmu" - DEPRECATED, permitted only where OS has
|
||||
secure acces to CCI registers
|
||||
"arm,cci-500-pmu,r0"
|
||||
"arm,cci-550-pmu,r0"
|
||||
- reg:
|
||||
Usage: required
|
||||
Value type: Integer cells. A register entry, expressed
|
||||
|
|
|
|||
|
|
@ -167,6 +167,7 @@ nodes to be present and contain the properties described below.
|
|||
"arm,cortex-r5"
|
||||
"arm,cortex-r7"
|
||||
"brcm,brahma-b15"
|
||||
"brcm,vulcan"
|
||||
"cavium,thunder"
|
||||
"faraday,fa526"
|
||||
"intel,sa110"
|
||||
|
|
@ -178,6 +179,7 @@ nodes to be present and contain the properties described below.
|
|||
"marvell,sheeva-v5"
|
||||
"nvidia,tegra132-denver"
|
||||
"qcom,krait"
|
||||
"qcom,kryo"
|
||||
"qcom,scorpion"
|
||||
- enable-method
|
||||
Value type: <stringlist>
|
||||
|
|
@ -250,7 +252,7 @@ nodes to be present and contain the properties described below.
|
|||
Usage: optional
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A u32 value that represents the running time dynamic
|
||||
power coefficient in units of mW/MHz/uVolt^2. The
|
||||
power coefficient in units of mW/MHz/uV^2. The
|
||||
coefficient can either be calculated from power
|
||||
measurements or derived by analysis.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,43 +11,9 @@ 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 authoritative guest-side hardware interface documentation to the fw_cfg
|
||||
device can be found in "docs/specs/fw_cfg.txt" in the QEMU source tree.
|
||||
|
||||
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:
|
||||
|
||||
|
|
|
|||
|
|
@ -22,6 +22,8 @@ SoCs:
|
|||
compatible = "ti,k2l", "ti,keystone"
|
||||
- Keystone 2 Edison
|
||||
compatible = "ti,k2e", "ti,keystone"
|
||||
- K2G
|
||||
compatible = "ti,k2g", "ti,keystone"
|
||||
|
||||
Boards:
|
||||
- Keystone 2 Hawking/Kepler EVM
|
||||
|
|
@ -32,3 +34,6 @@ Boards:
|
|||
|
||||
- Keystone 2 Edison EVM
|
||||
compatible = "ti,k2e-evm", "ti,k2e", "ti,keystone"
|
||||
|
||||
- K2G EVM
|
||||
compatible = "ti,k2g-evm", "ti,k2g", "ti-keystone"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,16 @@
|
|||
Marvell Armada 37xx Platforms Device Tree Bindings
|
||||
--------------------------------------------------
|
||||
|
||||
Boards using a SoC of the Marvell Armada 37xx family must carry the
|
||||
following root node property:
|
||||
|
||||
- compatible: must contain "marvell,armada3710"
|
||||
|
||||
In addition, boards using the Marvell Armada 3720 SoC shall have the
|
||||
following property before the previous one:
|
||||
|
||||
- compatible: must contain "marvell,armada3720"
|
||||
|
||||
Example:
|
||||
|
||||
compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3710";
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
Marvell Armada 7K/8K Platforms Device Tree Bindings
|
||||
---------------------------------------------------
|
||||
|
||||
Boards using a SoC of the Marvell Armada 7K or 8K families must carry
|
||||
the following root node property:
|
||||
|
||||
- compatible, with one of the following values:
|
||||
|
||||
- "marvell,armada7020", "marvell,armada-ap806-dual", "marvell,armada-ap806"
|
||||
when the SoC being used is the Armada 7020
|
||||
|
||||
- "marvell,armada7040", "marvell,armada-ap806-quad", "marvell,armada-ap806"
|
||||
when the SoC being used is the Armada 7040
|
||||
|
||||
- "marvell,armada8020", "marvell,armada-ap806-dual", "marvell,armada-ap806"
|
||||
when the SoC being used is the Armada 8020
|
||||
|
||||
- "marvell,armada8040", "marvell,armada-ap806-quad", "marvell,armada-ap806"
|
||||
when the SoC being used is the Armada 8040
|
||||
|
||||
Example:
|
||||
|
||||
compatible = "marvell,armada7040-db", "marvell,armada7040",
|
||||
"marvell,armada-ap806-quad", "marvell,armada-ap806";
|
||||
|
|
@ -19,9 +19,12 @@ SoC. Currently known SoC compatibles are:
|
|||
And in addition, the compatible shall be extended with the specific
|
||||
board. Currently known boards are:
|
||||
|
||||
"buffalo,linkstation-lsqvl"
|
||||
"buffalo,linkstation-lsvl"
|
||||
"buffalo,linkstation-lswsxl"
|
||||
"buffalo,linkstation-lswxl"
|
||||
"buffalo,linkstation-lswvl"
|
||||
"buffalo,lschlv2"
|
||||
"buffalo,lswvl"
|
||||
"buffalo,lswxl"
|
||||
"buffalo,lsxhl"
|
||||
"buffalo,lsxl"
|
||||
"cloudengines,pogo02"
|
||||
|
|
@ -11,6 +11,7 @@ compatible: Must contain one of
|
|||
"mediatek,mt6589"
|
||||
"mediatek,mt6592"
|
||||
"mediatek,mt6795"
|
||||
"mediatek,mt7623"
|
||||
"mediatek,mt8127"
|
||||
"mediatek,mt8135"
|
||||
"mediatek,mt8173"
|
||||
|
|
@ -33,6 +34,9 @@ Supported boards:
|
|||
- Evaluation board for MT6795(Helio X10):
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt6795-evb", "mediatek,mt6795";
|
||||
- Evaluation board for MT7623:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt7623-evb", "mediatek,mt7623";
|
||||
- MTK mt8127 tablet moose EVB:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt8127-moose", "mediatek,mt8127";
|
||||
|
|
|
|||
|
|
@ -23,6 +23,7 @@ Optional properties:
|
|||
during suspend.
|
||||
- ti,no-reset-on-init: When present, the module should not be reset at init
|
||||
- ti,no-idle-on-init: When present, the module should not be idled at init
|
||||
- ti,no-idle: When present, the module is never allowed to idle.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -154,7 +155,7 @@ Boards:
|
|||
compatible = "compulab,am437x-sbc-t43", "compulab,am437x-cm-t43", "ti,am4372", "ti,am43"
|
||||
|
||||
- AM43x EPOS EVM
|
||||
compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
|
||||
compatible = "ti,am43x-epos-evm", "ti,am43", "ti,am438x"
|
||||
|
||||
- AM437x GP EVM
|
||||
compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
|
||||
|
|
|
|||
|
|
@ -25,6 +25,7 @@ Required properties:
|
|||
"qcom,scorpion-pmu"
|
||||
"qcom,scorpion-mp-pmu"
|
||||
"qcom,krait-pmu"
|
||||
"cavium,thunder-pmu"
|
||||
- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu
|
||||
interrupt (PPI) then 1 interrupt should be specified.
|
||||
|
||||
|
|
@ -46,6 +47,16 @@ Optional properties:
|
|||
- qcom,no-pc-write : Indicates that this PMU doesn't support the 0xc and 0xd
|
||||
events.
|
||||
|
||||
- secure-reg-access : Indicates that the ARMv7 Secure Debug Enable Register
|
||||
(SDER) is accessible. This will cause the driver to do
|
||||
any setup required that is only possible in ARMv7 secure
|
||||
state. If not present the ARMv7 SDER will not be touched,
|
||||
which means the PMU may fail to operate unless external
|
||||
code (bootloader or security monitor) has performed the
|
||||
appropriate initialisation. Note that this property is
|
||||
not valid for non-ARMv7 CPUs or ARMv7 CPUs booting Linux
|
||||
in Non-secure state.
|
||||
|
||||
Example:
|
||||
|
||||
pmu {
|
||||
|
|
|
|||
|
|
@ -0,0 +1,51 @@
|
|||
QCOM device tree bindings
|
||||
-------------------------
|
||||
|
||||
Some qcom based bootloaders identify the dtb blob based on a set of
|
||||
device properties like SoC and platform and revisions of those components.
|
||||
To support this scheme, we encode this information into the board compatible
|
||||
string.
|
||||
|
||||
Each board must specify a top-level board compatible string with the following
|
||||
format:
|
||||
|
||||
compatible = "qcom,<SoC>[-<soc_version>][-<foundry_id>]-<board>[/<subtype>][-<board_version>]"
|
||||
|
||||
The 'SoC' and 'board' elements are required. All other elements are optional.
|
||||
|
||||
The 'SoC' element must be one of the following strings:
|
||||
|
||||
apq8016
|
||||
apq8074
|
||||
apq8084
|
||||
apq8096
|
||||
msm8916
|
||||
msm8974
|
||||
msm8996
|
||||
|
||||
The 'board' element must be one of the following strings:
|
||||
|
||||
cdp
|
||||
liquid
|
||||
dragonboard
|
||||
mtp
|
||||
sbc
|
||||
|
||||
The 'soc_version' and 'board_version' elements take the form of v<Major>.<Minor>
|
||||
where the minor number may be omitted when it's zero, i.e. v1.0 is the same
|
||||
as v1. If all versions of the 'board_version' elements match, then a
|
||||
wildcard '*' should be used, e.g. 'v*'.
|
||||
|
||||
The 'foundry_id' and 'subtype' elements are one or more digits from 0 to 9.
|
||||
|
||||
Examples:
|
||||
|
||||
"qcom,msm8916-v1-cdp-pm8916-v2.1"
|
||||
|
||||
A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of version
|
||||
2.1.
|
||||
|
||||
"qcom,apq8074-v2.0-2-dragonboard/1-v0.1"
|
||||
|
||||
A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in
|
||||
foundry 2.
|
||||
|
|
@ -11,5 +11,6 @@ using one of the following compatible strings:
|
|||
allwinner,sun7i-a20
|
||||
allwinner,sun8i-a23
|
||||
allwinner,sun8i-a33
|
||||
allwinner,sun8i-a83t
|
||||
allwinner,sun8i-h3
|
||||
allwinner,sun9i-a80
|
||||
|
|
|
|||
|
|
@ -11,8 +11,10 @@ Required properties:
|
|||
- compatible : compatible string, one of:
|
||||
- "allwinner,sun4i-a10-ahci"
|
||||
- "hisilicon,hisi-ahci"
|
||||
- "cavium,octeon-7130-ahci"
|
||||
- "ibm,476gtr-ahci"
|
||||
- "marvell,armada-380-ahci"
|
||||
- "marvell,armada-3700-ahci"
|
||||
- "snps,dwc-ahci"
|
||||
- "snps,exynos5440-ahci"
|
||||
- "snps,spear-ahci"
|
||||
|
|
|
|||
|
|
@ -46,6 +46,9 @@ Timing properties for child nodes. All are optional and default to 0.
|
|||
- gpmc,adv-on-ns: Assertion time
|
||||
- gpmc,adv-rd-off-ns: Read deassertion time
|
||||
- gpmc,adv-wr-off-ns: Write deassertion time
|
||||
- gpmc,adv-aad-mux-on-ns: Assertion time for AAD
|
||||
- gpmc,adv-aad-mux-rd-off-ns: Read deassertion time for AAD
|
||||
- gpmc,adv-aad-mux-wr-off-ns: Write deassertion time for AAD
|
||||
|
||||
WE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4:
|
||||
- gpmc,we-on-ns Assertion time
|
||||
|
|
@ -54,6 +57,8 @@ Timing properties for child nodes. All are optional and default to 0.
|
|||
OE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4:
|
||||
- gpmc,oe-on-ns: Assertion time
|
||||
- gpmc,oe-off-ns: Deassertion time
|
||||
- gpmc,oe-aad-mux-on-ns: Assertion time for AAD
|
||||
- gpmc,oe-aad-mux-off-ns: Deassertion time for AAD
|
||||
|
||||
Access time and cycle time timings (in nanoseconds) corresponding to
|
||||
GPMC_CONFIG5:
|
||||
|
|
|
|||
|
|
@ -8,7 +8,10 @@ Required properties:
|
|||
- compatible : shall be "adi,axi-clkgen-1.00.a" or "adi,axi-clkgen-2.00.a".
|
||||
- #clock-cells : from common clock binding; Should always be set to 0.
|
||||
- reg : Address and length of the axi-clkgen register set.
|
||||
- clocks : Phandle and clock specifier for the parent clock.
|
||||
- clocks : Phandle and clock specifier for the parent clock(s). This must
|
||||
either reference one clock if only the first clock input is connected or two
|
||||
if both clock inputs are connected. For the later case the clock connected
|
||||
to the first input must be specified first.
|
||||
|
||||
Optional properties:
|
||||
- clock-output-names : From common clock binding.
|
||||
|
|
|
|||
|
|
@ -92,6 +92,7 @@ PLL and leaf clock compatible strings for Cygnus are:
|
|||
"brcm,cygnus-lcpll0"
|
||||
"brcm,cygnus-mipipll"
|
||||
"brcm,cygnus-asiu-clk"
|
||||
"brcm,cygnus-audiopll"
|
||||
|
||||
The following table defines the set of PLL/clock index and ID for Cygnus.
|
||||
These clock IDs are defined in:
|
||||
|
|
@ -131,6 +132,11 @@ These clock IDs are defined in:
|
|||
ch4_unused mipipll 5 BCM_CYGNUS_MIPIPLL_CH4_UNUSED
|
||||
ch5_unused mipipll 6 BCM_CYGNUS_MIPIPLL_CH5_UNUSED
|
||||
|
||||
audiopll crystal 0 BCM_CYGNUS_AUDIOPLL
|
||||
ch0_audio audiopll 1 BCM_CYGNUS_AUDIOPLL_CH0
|
||||
ch1_audio audiopll 2 BCM_CYGNUS_AUDIOPLL_CH1
|
||||
ch2_audio audiopll 3 BCM_CYGNUS_AUDIOPLL_CH2
|
||||
|
||||
Northstar and Northstar Plus
|
||||
------
|
||||
PLL and leaf clock compatible strings for Northstar and Northstar Plus are:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,52 @@
|
|||
* NXP LPC1850 CREG clocks
|
||||
|
||||
The NXP LPC18xx/43xx CREG (Configuration Registers) block contains
|
||||
control registers for two low speed clocks. One of the clocks is a
|
||||
32 kHz oscillator driver with power up/down and clock gating. Next
|
||||
is a fixed divider that creates a 1 kHz clock from the 32 kHz osc.
|
||||
|
||||
These clocks are used by the RTC and the Event Router peripherials.
|
||||
The 32 kHz can also be routed to other peripherials to enable low
|
||||
power modes.
|
||||
|
||||
This binding uses the common clock binding:
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Required properties:
|
||||
- compatible:
|
||||
Should be "nxp,lpc1850-creg-clk"
|
||||
- #clock-cells:
|
||||
Shall have value <1>.
|
||||
- clocks:
|
||||
Shall contain a phandle to the fixed 32 kHz crystal.
|
||||
|
||||
The creg-clk node must be a child of the creg syscon node.
|
||||
|
||||
The following clocks are available from the clock node.
|
||||
|
||||
Clock ID Name
|
||||
0 1 kHz clock
|
||||
1 32 kHz Oscillator
|
||||
|
||||
Example:
|
||||
soc {
|
||||
creg: syscon@40043000 {
|
||||
compatible = "nxp,lpc1850-creg", "syscon", "simple-mfd";
|
||||
reg = <0x40043000 0x1000>;
|
||||
|
||||
creg_clk: clock-controller {
|
||||
compatible = "nxp,lpc1850-creg-clk";
|
||||
clocks = <&xtal32>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
...
|
||||
};
|
||||
|
||||
rtc: rtc@40046000 {
|
||||
...
|
||||
clocks = <&creg_clk 0>, <&ccu1 CLK_CPU_BUS>;
|
||||
clock-names = "rtc", "reg";
|
||||
...
|
||||
};
|
||||
};
|
||||
|
|
@ -7,6 +7,7 @@ Required properties :
|
|||
"qcom,gcc-apq8064"
|
||||
"qcom,gcc-apq8084"
|
||||
"qcom,gcc-ipq8064"
|
||||
"qcom,gcc-ipq4019"
|
||||
"qcom,gcc-msm8660"
|
||||
"qcom,gcc-msm8916"
|
||||
"qcom,gcc-msm8960"
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ Examples
|
|||
reg = <0 0xe6e88000 0 64>;
|
||||
interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cpg CPG_MOD 310>;
|
||||
clock-names = "sci_ick";
|
||||
clock-names = "fck";
|
||||
dmas = <&dmac1 0x13>, <&dmac1 0x12>;
|
||||
dma-names = "tx", "rx";
|
||||
power-domains = <&cpg>;
|
||||
|
|
|
|||
|
|
@ -18,6 +18,7 @@ Required properties:
|
|||
"allwinner,sun4i-a10-cpu-clk" - for the CPU multiplexer clock
|
||||
"allwinner,sun4i-a10-axi-clk" - for the AXI clock
|
||||
"allwinner,sun8i-a23-axi-clk" - for the AXI clock on A23
|
||||
"allwinner,sun4i-a10-gates-clk" - for generic gates on all compatible SoCs
|
||||
"allwinner,sun4i-a10-axi-gates-clk" - for the AXI gates
|
||||
"allwinner,sun4i-a10-ahb-clk" - for the AHB clock
|
||||
"allwinner,sun5i-a13-ahb-clk" - for the AHB clock on A13
|
||||
|
|
@ -39,12 +40,14 @@ Required properties:
|
|||
"allwinner,sun6i-a31-apb0-clk" - for the APB0 clock on A31
|
||||
"allwinner,sun8i-a23-apb0-clk" - for the APB0 clock on A23
|
||||
"allwinner,sun9i-a80-apb0-clk" - for the APB0 bus clock on A80
|
||||
"allwinner,sun8i-a83t-apb0-gates-clk" - for the APB0 gates on A83T
|
||||
"allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10
|
||||
"allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
|
||||
"allwinner,sun5i-a10s-apb0-gates-clk" - for the APB0 gates on A10s
|
||||
"allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31
|
||||
"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
|
||||
"allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
|
||||
"allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3
|
||||
"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
|
||||
"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
|
||||
"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
|
||||
|
|
@ -57,6 +60,7 @@ Required properties:
|
|||
"allwinner,sun9i-a80-apb1-gates-clk" - for the APB1 gates on A80
|
||||
"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
|
||||
"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
|
||||
"allwinner,sun8i-a83t-bus-gates-clk" - for the bus gates on A83T
|
||||
"allwinner,sun8i-h3-bus-gates-clk" - for the bus gates on H3
|
||||
"allwinner,sun9i-a80-apbs-gates-clk" - for the APBS gates on A80
|
||||
"allwinner,sun4i-a10-dram-gates-clk" - for the DRAM gates on A10
|
||||
|
|
|
|||
|
|
@ -0,0 +1,41 @@
|
|||
Binding for Texas Instruments ADPLL clock.
|
||||
|
||||
Binding status: Unstable - ABI compatibility may be broken in the future
|
||||
|
||||
This binding uses the common clock binding[1]. It assumes a
|
||||
register-mapped ADPLL with two to three selectable input clocks
|
||||
and three to four children.
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Required properties:
|
||||
- compatible : shall be one of "ti,dm814-adpll-s-clock" or
|
||||
"ti,dm814-adpll-lj-clock" depending on the type of the ADPLL
|
||||
- #clock-cells : from common clock binding; shall be set to 1.
|
||||
- clocks : link phandles of parent clocks clkinp and clkinpulow, note
|
||||
that the adpll-s-clock also has an optional clkinphif
|
||||
- reg : address and length of the register set for controlling the ADPLL.
|
||||
|
||||
Examples:
|
||||
adpll_mpu_ck: adpll@40 {
|
||||
#clock-cells = <1>;
|
||||
compatible = "ti,dm814-adpll-s-clock";
|
||||
reg = <0x40 0x40>;
|
||||
clocks = <&devosc_ck &devosc_ck &devosc_ck>;
|
||||
clock-names = "clkinp", "clkinpulow", "clkinphif";
|
||||
clock-output-names = "481c5040.adpll.dcoclkldo",
|
||||
"481c5040.adpll.clkout",
|
||||
"481c5040.adpll.clkoutx2",
|
||||
"481c5040.adpll.clkouthif";
|
||||
};
|
||||
|
||||
adpll_dsp_ck: adpll@80 {
|
||||
#clock-cells = <1>;
|
||||
compatible = "ti,dm814-adpll-lj-clock";
|
||||
reg = <0x80 0x30>;
|
||||
clocks = <&devosc_ck &devosc_ck>;
|
||||
clock-names = "clkinp", "clkinpulow";
|
||||
clock-output-names = "481c5080.adpll.dcoclkldo",
|
||||
"481c5080.adpll.clkout",
|
||||
"481c5080.adpll.clkoutldo";
|
||||
};
|
||||
|
|
@ -9,6 +9,8 @@ Required properties:
|
|||
"apm,xgene-socpll-clock" - for a X-Gene SoC PLL clock
|
||||
"apm,xgene-pcppll-clock" - for a X-Gene PCP PLL clock
|
||||
"apm,xgene-device-clock" - for a X-Gene device clock
|
||||
"apm,xgene-socpll-v2-clock" - for a X-Gene SoC PLL v2 clock
|
||||
"apm,xgene-pcppll-v2-clock" - for a X-Gene PCP PLL v2 clock
|
||||
|
||||
Required properties for SoC or PCP PLL clocks:
|
||||
- reg : shall be the physical PLL register address for the pll clock.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,79 @@
|
|||
ARM HDLCD
|
||||
|
||||
This is a display controller found on several development platforms produced
|
||||
by ARM Ltd and in more modern of its' Fast Models. The HDLCD is an RGB
|
||||
streamer that reads the data from a framebuffer and sends it to a single
|
||||
digital encoder (DVI or HDMI).
|
||||
|
||||
Required properties:
|
||||
- compatible: "arm,hdlcd"
|
||||
- reg: Physical base address and length of the controller's registers.
|
||||
- interrupts: One interrupt used by the display controller to notify the
|
||||
interrupt controller when any of the interrupt sources programmed in
|
||||
the interrupt mask register have activated.
|
||||
- clocks: A list of phandle + clock-specifier pairs, one for each
|
||||
entry in 'clock-names'.
|
||||
- clock-names: A list of clock names. For HDLCD it should contain:
|
||||
- "pxlclk" for the clock feeding the output PLL of the controller.
|
||||
|
||||
Required sub-nodes:
|
||||
- port: The HDLCD connection to an encoder chip. The connection is modeled
|
||||
using the OF graph bindings specified in
|
||||
Documentation/devicetree/bindings/graph.txt.
|
||||
|
||||
Optional properties:
|
||||
- memory-region: phandle to a node describing memory (see
|
||||
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt) to be
|
||||
used for the framebuffer; if not present, the framebuffer may be located
|
||||
anywhere in memory.
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
/ {
|
||||
...
|
||||
|
||||
hdlcd@2b000000 {
|
||||
compatible = "arm,hdlcd";
|
||||
reg = <0 0x2b000000 0 0x1000>;
|
||||
interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&oscclk5>;
|
||||
clock-names = "pxlclk";
|
||||
port {
|
||||
hdlcd_output: endpoint@0 {
|
||||
remote-endpoint = <&hdmi_enc_input>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
/* HDMI encoder on I2C bus */
|
||||
i2c@7ffa0000 {
|
||||
....
|
||||
hdmi-transmitter@70 {
|
||||
compatible = ".....";
|
||||
reg = <0x70>;
|
||||
port@0 {
|
||||
hdmi_enc_input: endpoint {
|
||||
remote-endpoint = <&hdlcd_output>;
|
||||
};
|
||||
|
||||
hdmi_enc_output: endpoint {
|
||||
remote-endpoint = <&hdmi_1_port>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
};
|
||||
|
||||
hdmi1: connector@1 {
|
||||
compatible = "hdmi-connector";
|
||||
type = "a";
|
||||
port {
|
||||
hdmi_1_port: endpoint {
|
||||
remote-endpoint = <&hdmi_enc_output>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
};
|
||||
|
|
@ -35,6 +35,12 @@ Optional properties for HDMI:
|
|||
as an interrupt/status bit in the HDMI controller
|
||||
itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt
|
||||
|
||||
Required properties for V3D:
|
||||
- compatible: Should be "brcm,bcm2835-v3d"
|
||||
- reg: Physical base address and length of the V3D's registers
|
||||
- interrupts: The interrupt number
|
||||
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
|
||||
|
||||
Example:
|
||||
pixelvalve@7e807000 {
|
||||
compatible = "brcm,bcm2835-pixelvalve2";
|
||||
|
|
@ -60,6 +66,12 @@ hdmi: hdmi@7e902000 {
|
|||
clock-names = "pixel", "hdmi";
|
||||
};
|
||||
|
||||
v3d: v3d@7ec00000 {
|
||||
compatible = "brcm,bcm2835-v3d";
|
||||
reg = <0x7ec00000 0x1000>;
|
||||
interrupts = <1 10>;
|
||||
};
|
||||
|
||||
vc4: gpu {
|
||||
compatible = "brcm,bcm2835-vc4";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ Required properties:
|
|||
"samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */
|
||||
"samsung,exynos4415-mipi-dsi" /* for Exynos4415 SoC */
|
||||
"samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs */
|
||||
"samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */
|
||||
"samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
|
||||
- reg: physical base address and length of the registers set for the device
|
||||
- interrupts: should contain DSI interrupt
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue