Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 8dbcb873 authored by Ingo Molnar's avatar Ingo Molnar
Browse files

Merge tag 'v3.19-rc7' into x86/asm, to refresh the branch before pulling in new changes



Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
parents 772a9aca e36f014e
Loading
Loading
Loading
Loading
+0 −60
Original line number Original line Diff line number Diff line
What:		/sys/class/leds/dell::kbd_backlight/als_setting
Date:		December 2014
KernelVersion:	3.19
Contact:	Gabriele Mazzotta <gabriele.mzt@gmail.com>,
		Pali Rohár <pali.rohar@gmail.com>
Description:
		This file allows to control the automatic keyboard
		illumination mode on some systems that have an ambient
		light sensor. Write 1 to this file to enable the auto
		mode, 0 to disable it.

What:		/sys/class/leds/dell::kbd_backlight/start_triggers
Date:		December 2014
KernelVersion:	3.19
Contact:	Gabriele Mazzotta <gabriele.mzt@gmail.com>,
		Pali Rohár <pali.rohar@gmail.com>
Description:
		This file allows to control the input triggers that
		turn on the keyboard backlight illumination that is
		disabled because of inactivity.
		Read the file to see the triggers available. The ones
		enabled are preceded by '+', those disabled by '-'.

		To enable a trigger, write its name preceded by '+' to
		this file. To disable a trigger, write its name preceded
		by '-' instead.

		For example, to enable the keyboard as trigger run:
		    echo +keyboard > /sys/class/leds/dell::kbd_backlight/start_triggers
		To disable it:
		    echo -keyboard > /sys/class/leds/dell::kbd_backlight/start_triggers

		Note that not all the available triggers can be configured.

What:		/sys/class/leds/dell::kbd_backlight/stop_timeout
Date:		December 2014
KernelVersion:	3.19
Contact:	Gabriele Mazzotta <gabriele.mzt@gmail.com>,
		Pali Rohár <pali.rohar@gmail.com>
Description:
		This file allows to specify the interval after which the
		keyboard illumination is disabled because of inactivity.
		The timeouts are expressed in seconds, minutes, hours and
		days, for which the symbols are 's', 'm', 'h' and 'd'
		respectively.

		To configure the timeout, write to this file a value along
		with any the above units. If no unit is specified, the value
		is assumed to be expressed in seconds.

		For example, to set the timeout to 10 minutes run:
		    echo 10m > /sys/class/leds/dell::kbd_backlight/stop_timeout

		Note that when this file is read, the returned value might be
		expressed in a different unit than the one used when the timeout
		was set.

		Also note that only some timeouts are supported and that
		some systems might fall back to a specific timeout in case
		an invalid timeout is written to this file.
+1 −1
Original line number Original line Diff line number Diff line
@@ -23,7 +23,7 @@ Required nodes:
    range of 0x200 bytes.
    range of 0x200 bytes.


- syscon: the root node of the Integrator platforms must have a
- syscon: the root node of the Integrator platforms must have a
  system controller node pointong to the control registers,
  system controller node pointing to the control registers,
  with the compatible string
  with the compatible string
  "arm,integrator-ap-syscon"
  "arm,integrator-ap-syscon"
  "arm,integrator-cp-syscon"
  "arm,integrator-cp-syscon"
+72 −0
Original line number Original line Diff line number Diff line
* QEMU Firmware Configuration bindings for ARM

QEMU's arm-softmmu and aarch64-softmmu emulation / virtualization targets
provide the following Firmware Configuration interface on the "virt" machine
type:

- A write-only, 16-bit wide selector (or control) register,
- a read-write, 64-bit wide data register.

QEMU exposes the control and data register to ARM guests as memory mapped
registers; their location is communicated to the guest's UEFI firmware in the
DTB that QEMU places at the bottom of the guest's DRAM.

The guest writes a selector value (a key) to the selector register, and then
can read the corresponding data (produced by QEMU) via the data register. If
the selected entry is writable, the guest can rewrite it through the data
register.

The selector register takes keys in big endian byte order.

The data register allows accesses with 8, 16, 32 and 64-bit width (only at
offset 0 of the register). Accesses larger than a byte are interpreted as
arrays, bundled together only for better performance. The bytes constituting
such a word, in increasing address order, correspond to the bytes that would
have been transferred by byte-wide accesses in chronological order.

The interface allows guest firmware to download various parameters and blobs
that affect how the firmware works and what tables it installs for the guest
OS. For example, boot order of devices, ACPI tables, SMBIOS tables, kernel and
initrd images for direct kernel booting, virtual machine UUID, SMP information,
virtual NUMA topology, and so on.

The authoritative registry of the valid selector values and their meanings is
the QEMU source code; the structure of the data blobs corresponding to the
individual key values is also defined in the QEMU source code.

The presence of the registers can be verified by selecting the "signature" blob
with key 0x0000, and reading four bytes from the data register. The returned
signature is "QEMU".

The outermost protocol (involving the write / read sequences of the control and
data registers) is expected to be versioned, and/or described by feature bits.
The interface revision / feature bitmap can be retrieved with key 0x0001. The
blob to be read from the data register has size 4, and it is to be interpreted
as a uint32_t value in little endian byte order. The current value
(corresponding to the above outer protocol) is zero.

The guest kernel is not expected to use these registers (although it is
certainly allowed to); the device tree bindings are documented here because
this is where device tree bindings reside in general.

Required properties:

- compatible: "qemu,fw-cfg-mmio".

- reg: the MMIO region used by the device.
  * Bytes 0x0 to 0x7 cover the data register.
  * Bytes 0x8 to 0x9 cover the selector register.
  * Further registers may be appended to the region in case of future interface
    revisions / feature bits.

Example:

/ {
	#size-cells = <0x2>;
	#address-cells = <0x2>;

	fw-cfg@9020000 {
		compatible = "qemu,fw-cfg-mmio";
		reg = <0x0 0x9020000 0x0 0xa>;
	};
};
+1 −1
Original line number Original line Diff line number Diff line
@@ -19,7 +19,7 @@ type of the connections, they just map their existence. Specific properties
may be described by specialized bindings depending on the type of connection.
may be described by specialized bindings depending on the type of connection.


To see how this binding applies to video pipelines, for example, see
To see how this binding applies to video pipelines, for example, see
Documentation/device-tree/bindings/media/video-interfaces.txt.
Documentation/devicetree/bindings/media/video-interfaces.txt.
Here the ports describe data interfaces, and the links between them are
Here the ports describe data interfaces, and the links between them are
the connecting data buses. A single port with multiple connections can
the connecting data buses. A single port with multiple connections can
correspond to multiple devices being connected to the same physical bus.
correspond to multiple devices being connected to the same physical bus.
+1 −1
Original line number Original line Diff line number Diff line
@@ -31,7 +31,7 @@ i2c0: i2c@fed40000 {
	compatible	= "st,comms-ssc4-i2c";
	compatible	= "st,comms-ssc4-i2c";
	reg		= <0xfed40000 0x110>;
	reg		= <0xfed40000 0x110>;
	interrupts	=  <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
	interrupts	=  <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
	clocks		= <&CLK_S_ICN_REG_0>;
	clocks		= <&clk_s_a0_ls CLK_ICN_REG>;
	clock-names	= "ssc";
	clock-names	= "ssc";
	clock-frequency = <400000>;
	clock-frequency = <400000>;
	pinctrl-names	= "default";
	pinctrl-names	= "default";
Loading