hollalinux
/
linux-sg2042
mirror of https://github.com/sophgo/linux-riscv.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge drm/drm-next into drm-intel-next-queued 

Sync with drm-next to get the new logging macros, among other things.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This commit is contained in:
Jani Nikula 2020-01-09 17:19:12 +02:00
parent 6251215fe5 a566696cf9
commit ec027b33c8
1334 changed files with 33550 additions and 16003 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.mailmap
View File

@ -276,3 +276,5 @@ Gustavo Padovan <gustavo@las.ic.unicamp.br>
Gustavo Padovan <padovan@profusion.mobi>
Changbin Du <changbin.du@intel.com> <changbin.du@intel.com>
Changbin Du <changbin.du@intel.com> <changbin.du@gmail.com>
Steve Wise <larrystevenwise@gmail.com> <swise@chelsio.com>
Steve Wise <larrystevenwise@gmail.com> <swise@opengridcomputing.com>

2
Documentation/admin-guide/device-mapper/dm-integrity.rst
View File

@ -144,7 +144,7 @@ journal_crypt:algorithm(:key) (the key is optional)
Encrypt the journal using given algorithm to make sure that the
attacker can't read the journal. You can use a block cipher here
(such as "cbc(aes)") or a stream cipher (for example "chacha20",
"salsa20", "ctr(aes)" or "ecb(arc4)").
"salsa20" or "ctr(aes)").
The journal contains history of last writes to the block device,
an attacker reading the journal could see the last sector nubmers

1
Documentation/admin-guide/device-mapper/index.rst
View File

@ -8,6 +8,7 @@ Device Mapper
cache-policies
cache
delay
dm-clone
dm-crypt
dm-dust
dm-flakey

2
Documentation/devicetree/bindings/arm/sunxi.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner platforms device tree bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
$nodename:

2
Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A64 Display Engine Bus Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
$nodename:

2
Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A23 RSB Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
"#address-cells":

2
Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner Clock Control Unit Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
"#clock-cells":

2
Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A10 Security System Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:

35
Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
View File

@ -8,14 +8,16 @@ title: Allwinner A31 MIPI-DSI Controller Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
"#address-cells": true
"#size-cells": true
compatible:
const: allwinner,sun6i-a31-mipi-dsi
enum:
- allwinner,sun6i-a31-mipi-dsi
- allwinner,sun50i-a64-mipi-dsi
reg:
maxItems: 1
@ -24,6 +26,8 @@ properties:
maxItems: 1
clocks:
minItems: 1
maxItems: 2
items:
- description: Bus Clock
- description: Module Clock
@ -63,13 +67,38 @@ required:
- reg
- interrupts
- clocks
- clock-names
- phys
- phy-names
- resets
- vcc-dsi-supply
- port
allOf:
- if:
properties:
compatible:
contains:
const: allwinner,sun6i-a31-mipi-dsi
then:
properties:
clocks:
minItems: 2
required:
- clock-names
- if:
properties:
compatible:
contains:
const: allwinner,sun50i-a64-mipi-dsi
then:
properties:
clocks:
minItems: 1
additionalProperties: false
examples:

131
Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml Normal file
View File

@ -0,0 +1,131 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/lvds-codec.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Transparent LVDS encoders and decoders
maintainers:
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
description: |
This binding supports transparent LVDS encoders and decoders that don't
require any configuration.
LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
incompatible data link layers have been used over time to transmit image data
to LVDS panels. This binding targets devices compatible with the following
specifications only.
[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
Semiconductor
[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
Electronics Standards Association (VESA)
Those devices have been marketed under the FPD-Link and FlatLink brand names
among others.
properties:
compatible:
oneOf:
- items:
- enum:
- ti,ds90c185 # For the TI DS90C185 FPD-Link Serializer
- ti,ds90c187 # For the TI DS90C187 FPD-Link Serializer
- ti,sn75lvds83 # For the TI SN75LVDS83 FlatLink transmitter
- const: lvds-encoder # Generic LVDS encoder compatible fallback
- items:
- enum:
- ti,ds90cf384a # For the DS90CF384A FPD-Link LVDS Receiver
- const: lvds-decoder # Generic LVDS decoders compatible fallback
- enum:
- thine,thc63lvdm83d # For the THC63LVDM83D LVDS serializer
ports:
type: object
description: |
This device has two video ports. Their connections are modeled using the
OF graph bindings specified in Documentation/devicetree/bindings/graph.txt
properties:
port@0:
type: object
description: |
For LVDS encoders, port 0 is the parallel input
For LVDS decoders, port 0 is the LVDS input
port@1:
type: object
description: |
For LVDS encoders, port 1 is the LVDS output
For LVDS decoders, port 1 is the parallel output
required:
- port@0
- port@1
powerdown-gpios:
description:
The GPIO used to control the power down line of this device.
maxItems: 1
required:
- compatible
- ports
examples:
- |
lvds-encoder {
compatible = "ti,ds90c185", "lvds-encoder";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
lvds_enc_in: endpoint {
remote-endpoint = <&display_out_rgb>;
};
};
port@1 {
reg = <1>;
lvds_enc_out: endpoint {
remote-endpoint = <&lvds_panel_in>;
};
};
};
};
- |
lvds-decoder {
compatible = "ti,ds90cf384a", "lvds-decoder";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
lvds_dec_in: endpoint {
remote-endpoint = <&display_out_lvds>;
};
};
port@1 {
reg = <1>;
lvds_dec_out: endpoint {
remote-endpoint = <&rgb_panel_in>;
};
};
};
};
...

66
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
View File

@ -1,66 +0,0 @@
Parallel to LVDS Encoder
------------------------
This binding supports the parallel to LVDS encoders that don't require any
configuration.
LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
incompatible data link layers have been used over time to transmit image data
to LVDS panels. This binding targets devices compatible with the following
specifications only.
[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
Semiconductor
[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
Electronics Standards Association (VESA)
Those devices have been marketed under the FPD-Link and FlatLink brand names
among others.
Required properties:
- compatible: Must be "lvds-encoder"
Any encoder compatible with this generic binding, but with additional
properties not listed here, must list a device specific compatible first
followed by this generic compatible.
Required nodes:
This device has two video ports. Their connections are modeled using the OF
graph bindings specified in Documentation/devicetree/bindings/graph.txt.
- Video port 0 for parallel input
- Video port 1 for LVDS output
Example
-------
lvds-encoder {
compatible = "lvds-encoder";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
lvds_enc_in: endpoint {
remote-endpoint = <&display_out_rgb>;
};
};
port@1 {
reg = <1>;
lvds_enc_out: endpoint {
remote-endpoint = <&lvds_panel_in>;
};
};
};
};

50
Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt
View File

@ -1,50 +0,0 @@
THine Electronics THC63LVDM83D LVDS serializer
----------------------------------------------
The THC63LVDM83D is an LVDS serializer designed to support pixel data
transmission between a host and a flat panel.
Required properties:
- compatible: Should be "thine,thc63lvdm83d"
Optional properties:
- powerdown-gpios: Power down control GPIO (the /PWDN pin, active low).
Required nodes:
The THC63LVDM83D has two video ports. Their connections are modeled using the
OFgraph bindings specified in Documentation/devicetree/bindings/graph.txt.
- Video port 0 for CMOS/TTL input
- Video port 1 for LVDS output
Example
-------
lvds_enc: encoder@0 {
compatible = "thine,thc63lvdm83d";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
lvds_enc_in: endpoint@0 {
remote-endpoint = <&rgb_out>;
};
};
port@1 {
reg = <1>;
lvds_enc_out: endpoint@0 {
remote-endpoint = <&panel_in>;
};
};
};
};

55
Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
View File

@ -1,55 +0,0 @@
Texas Instruments FPD-Link (LVDS) Serializer
--------------------------------------------
The DS90C185 and DS90C187 are low-power serializers for portable
battery-powered applications that reduces the size of the RGB
interface between the host GPU and the display.
Required properties:
- compatible: Should be
"ti,ds90c185", "lvds-encoder" for the TI DS90C185 FPD-Link Serializer
"ti,ds90c187", "lvds-encoder" for the TI DS90C187 FPD-Link Serializer
Optional properties:
- powerdown-gpios: Power down control GPIO (the PDB pin, active-low)
Required nodes:
The devices have two video ports. Their connections are modeled using the OF
graph bindings specified in Documentation/devicetree/bindings/graph.txt.
- Video port 0 for parallel input
- Video port 1 for LVDS output
Example
-------
lvds-encoder {
compatible = "ti,ds90c185", "lvds-encoder";
powerdown-gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
lvds_enc_in: endpoint {
remote-endpoint = <&lcdc_out_rgb>;
};
};
port@1 {
reg = <1>;
lvds_enc_out: endpoint {
remote-endpoint = <&lvds_panel_in>;
};
};
};
};

91
Documentation/devicetree/bindings/display/dsi-controller.yaml Normal file
View File

@ -0,0 +1,91 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/dsi-controller.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Common Properties for DSI Display Panels
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |
This document defines device tree properties common to DSI, Display
Serial Interface controllers and attached panels. It doesn't constitute
a device tree binding specification by itself but is meant to be referenced
by device tree bindings.
When referenced from panel device tree bindings the properties defined in
this document are defined as follows. The panel device tree bindings are
responsible for defining whether each property is required or optional.
Notice: this binding concerns DSI panels connected directly to a master
without any intermediate port graph to the panel. Each DSI master
can control one to four virtual channels to one panel. Each virtual
channel should have a node "panel" for their virtual channel with their
reg-property set to the virtual channel number, usually there is just
one virtual channel, number 0.
properties:
$nodename:
pattern: "^dsi-controller(@.*)?$"
"#address-cells":
const: 1
"#size-cells":
const: 0
patternProperties:
"^panel@[0-3]$":
description: Panels connected to the DSI link
type: object
properties:
reg:
minimum: 0
maximum: 3
description:
The virtual channel number of a DSI peripheral. Must be in the range
from 0 to 3, as DSI uses a 2-bit addressing scheme. Some DSI
peripherals respond to more than a single virtual channel. In that
case the reg property can take multiple entries, one for each virtual
channel that the peripheral responds to.
clock-master:
type: boolean
description:
Should be enabled if the host is being used in conjunction with
another DSI host to drive the same peripheral. Hardware supporting
such a configuration generally requires the data on both the busses
to be driven by the same clock. Only the DSI host instance
controlling this clock should contain this property.
enforce-video-mode:
type: boolean
description:
The best option is usually to run a panel in command mode, as this
gives better control over the panel hardware. However for different
reasons like broken hardware, missing features or testing, it may be
useful to be able to force a command mode-capable panel into video
mode.
required:
- reg
examples:
- |
#include <dt-bindings/gpio/gpio.h>
dsi-controller@a0351000 {
reg = <0xa0351000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
panel@0 {
compatible = "sony,acx424akp";
reg = <0>;
vddi-supply = <&ab8500_ldo_aux1_reg>;
reset-gpios = <&gpio2 1 GPIO_ACTIVE_LOW>;
};
};
...

1
Documentation/devicetree/bindings/display/ingenic,lcd.txt
View File

@ -4,6 +4,7 @@ Required properties:
- compatible: one of:
* ingenic,jz4740-lcd
* ingenic,jz4725b-lcd
* ingenic,jz4770-lcd
- reg: LCD registers location and length
- clocks: LCD pixclock and device clock specifiers.
The device clock is only required on the JZ4740.

49
Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml Normal file
View File

@ -0,0 +1,49 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/leadtek,ltk500hd1829.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Leadtek LTK500HD1829 5.0in 720x1280 DSI panel
maintainers:
- Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
const: leadtek,ltk500hd1829
reg: true
backlight: true
reset-gpios: true
iovcc-supply:
description: regulator that supplies the iovcc voltage
vcc-supply:
description: regulator that supplies the vcc voltage
required:
- compatible
- reg
- backlight
- iovcc-supply
- vcc-supply
additionalProperties: false
examples:
- |
dsi@ff450000 {
#address-cells = <1>;
#size-cells = <0>;
panel@0 {
compatible = "leadtek,ltk500hd1829";
reg = <0>;
backlight = <&backlight>;
iovcc-supply = <&vcc_1v8>;
vcc-supply = <&vcc_2v8>;
};
};
...

42
Documentation/devicetree/bindings/display/panel/logicpd,type28.yaml Normal file
View File

@ -0,0 +1,42 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/logicpd,type28.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Logic PD Type 28 4.3" WQVGA TFT LCD panel
maintainers:
- Adam Ford <aford173@gmail.com>
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
const: logicpd,type28
power-supply: true
enable-gpios: true
backlight: true
port: true
required:
- compatible
additionalProperties: false
examples:
- |
lcd0: display {
compatible = "logicpd,type28";
enable-gpios = <&gpio5 27 0>;
backlight = <&backlight>;
port {
lcd_in: endpoint {
remote-endpoint = <&dpi_out>;
};
};
};
...

2
Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml
View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Ronbo RB070D30 DSI Display Panel
maintainers:
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:

49
Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml Normal file
View File

@ -0,0 +1,49 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/sony,acx424akp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Sony ACX424AKP 4" 480x864 AMOLED panel
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
const: sony,acx424akp
reg: true
reset-gpios: true
vddi-supply:
description: regulator that supplies the vddi voltage
enforce-video-mode: true
required:
- compatible
- reg
- reset-gpios
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
dsi-controller@a0351000 {
compatible = "ste,mcde-dsi";
reg = <0xa0351000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
panel@0 {
compatible = "sony,acx424akp";
reg = <0>;
vddi-supply = <&foo>;
reset-gpios = <&foo_gpio 0 GPIO_ACTIVE_LOW>;
};
};
...

49
Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml Normal file
View File

@ -0,0 +1,49 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/xinpeng,xpp055c272.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xinpeng XPP055C272 5.5in 720x1280 DSI panel
maintainers:
- Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
const: xinpeng,xpp055c272
reg: true
backlight: true
reset-gpios: true
iovcc-supply:
description: regulator that supplies the iovcc voltage
vci-supply:
description: regulator that supplies the vci voltage
required:
- compatible
- reg
- backlight
- iovcc-supply
- vci-supply
additionalProperties: false
examples:
- |
dsi@ff450000 {
#address-cells = <1>;
#size-cells = <0>;
panel@0 {
compatible = "xinpeng,xpp055c272";
reg = <0>;
backlight = <&backlight>;
iovcc-supply = <&vcc_1v8>;
vci-supply = <&vcc3v3_lcd>;
};
};
...

67
Documentation/devicetree/bindings/display/renesas,cmm.yaml Normal file
View File

@ -0,0 +1,67 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/renesas,cmm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas R-Car Color Management Module (CMM)
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
- Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
- Jacopo Mondi <jacopo+renesas@jmondi.org>
description: |+
Renesas R-Car color management module connected to R-Car DU video channels.
It provides image enhancement functions such as 1-D look-up tables (LUT),
3-D look-up tables (CLU), 1D-histogram generation (HGO), and color
space conversion (CSC).
properties:
compatible:
oneOf:
- items:
- enum:
- renesas,r8a7795-cmm
- renesas,r8a7796-cmm
- renesas,r8a77965-cmm
- renesas,r8a77990-cmm
- renesas,r8a77995-cmm
- const: renesas,rcar-gen3-cmm
- items:
- const: renesas,rcar-gen2-cmm
reg:
maxItems: 1
clocks:
maxItems: 1
resets:
maxItems: 1
power-domains:
maxItems: 1
required:
- compatible
- reg
- clocks
- resets
- power-domains
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/r8a7796-cpg-mssr.h>
#include <dt-bindings/power/r8a7796-sysc.h>
cmm0: cmm@fea40000 {
compatible = "renesas,r8a7796-cmm",
"renesas,rcar-gen3-cmm";
reg = <0 0xfea40000 0 0x1000>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
clocks = <&cpg CPG_MOD 711>;
resets = <&cpg 711>;
};

15
Documentation/devicetree/bindings/display/renesas,du.txt
View File

@ -41,10 +41,14 @@ Required Properties:
supplied they must be named "dclkin.x" with "x" being the input clock
numerical index.
- vsps: A list of phandle and channel index tuples to the VSPs that handle
the memory interfaces for the DU channels. The phandle identifies the VSP
instance that serves the DU channel, and the channel index identifies the
LIF instance in that VSP.
- renesas,cmms: A list of phandles to the CMM instances present in the SoC,
one for each available DU channel. The property shall not be specified for
SoCs that do not provide any CMM (such as V3M and V3H).
- renesas,vsps: A list of phandle and channel index tuples to the VSPs that
handle the memory interfaces for the DU channels. The phandle identifies the
VSP instance that serves the DU channel, and the channel index identifies
the LIF instance in that VSP.
Required nodes:
@ -92,7 +96,8 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
<&cpg CPG_MOD 722>,
<&cpg CPG_MOD 721>;
clock-names = "du.0", "du.1", "du.2", "du.3";
vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>;
renesas,cmms = <&cmm0>, <&cmm1>, <&cmm2>, <&cmm3>;
renesas,vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>;
ports {
#address-cells = <1>;

13
Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
View File

@ -4,13 +4,16 @@ Rockchip specific extensions to the Synopsys Designware MIPI DSI
Required properties:
- #address-cells: Should be <1>.
- #size-cells: Should be <0>.
- compatible: "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi".
"rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi".
- compatible: one of
"rockchip,px30-mipi-dsi", "snps,dw-mipi-dsi"
"rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi"
"rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi"
- reg: Represent the physical address range of the controller.
- interrupts: Represent the controller's interrupt to the CPU(s).
- clocks, clock-names: Phandles to the controller's pll reference
clock(ref) and APB clock(pclk). For RK3399, a phy config clock
(phy_cfg) and a grf clock(grf) are required. As described in [1].
clock(ref) when using an internal dphy and APB clock(pclk).
For RK3399, a phy config clock (phy_cfg) and a grf clock(grf)
are required. As described in [1].
- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
- ports: contain a port node with endpoint definitions as defined in [2].
For vopb,set the reg = <0> and set the reg = <1> for vopl.
@ -18,6 +21,8 @@ Required properties:
- video port 1 for either a panel or subsequent encoder
Optional properties:
- phys: from general PHY binding: the phandle for the PHY device.
- phy-names: Should be "dphy" if phys references an external phy.
- power-domains: a phandle to mipi dsi power domain node.
- resets: list of phandle + reset specifier pairs, as described in [3].
- reset-names: string reset name, must be "apb".

4
Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
View File

@ -4,6 +4,7 @@ Rockchip RK3288 LVDS interface
Required properties:
- compatible: matching the soc type, one of
- "rockchip,rk3288-lvds";
- "rockchip,px30-lvds";
- reg: physical base address of the controller and length
of memory mapped region.
@ -18,6 +19,9 @@ Required properties:
- rockchip,grf: phandle to the general register files syscon
- rockchip,output: "rgb", "lvds" or "duallvds", This describes the output interface
- phys: LVDS/DSI DPHY (px30 only)
- phy-names: name of the PHY, must be "dphy" (px30 only)
Optional properties:
- pinctrl-names: must contain a "lcdc" entry.
- pinctrl-0: pin control group to be used for this controller.

21
Documentation/devicetree/bindings/display/tilcdc/tfp410.txt
View File

@ -1,21 +0,0 @@
Device-Tree bindings for tilcdc DRM TFP410 output driver
Required properties:
- compatible: value should be "ti,tilcdc,tfp410".
- i2c: the phandle for the i2c device to use for DDC
Recommended properties:
- pinctrl-names, pinctrl-0: the pincontrol settings to configure
muxing properly for pins that connect to TFP410 device
- powerdn-gpio: the powerdown GPIO, pulled low to power down the
TFP410 device (for DPMS_OFF)
Example:
dvicape {
compatible = "ti,tilcdc,tfp410";
i2c = <&i2c2>;
pinctrl-names = "default";
pinctrl-0 = <&bone_dvi_cape_dvi_00A1_pins>;
powerdn-gpio = <&gpio2 31 0>;
};

2
Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A10 DMA Controller Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
allOf:
- $ref: "dma-controller.yaml#"

2
Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A64 DMA Controller Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
allOf:
- $ref: "dma-controller.yaml#"

2
Documentation/devicetree/bindings/dma/allwinner,sun6i-a31-dma.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A31 DMA Controller Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
allOf:
- $ref: "dma-controller.yaml#"

2
Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A31 P2WI (Push/Pull 2 Wires Interface) Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#

5
Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml
View File

@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/adc/adi,ad7292.yaml#
@ -53,7 +53,8 @@ patternProperties:
description: |
The channel number. It can have up to 8 channels numbered from 0 to 7.
items:
maximum: 7
- minimum: 0
maximum: 7
diff-channels:
description: see Documentation/devicetree/bindings/iio/adc/adc.txt

2
Documentation/devicetree/bindings/iio/adc/allwinner,sun8i-a33-ths.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A33 Thermal Sensor Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
"#io-channel-cells":

2
Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A10 LRADC Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:

2
Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-a10-ic.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A10 Interrupt Controller Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
allOf:
- $ref: /schemas/interrupt-controller.yaml#

2
Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A20 Non-Maskable Interrupt Controller Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
allOf:
- $ref: /schemas/interrupt-controller.yaml#

2
Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A10 CMOS Sensor Interface (CSI) Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
description: |-
The Allwinner A10 and later has a CMOS Sensor Interface to retrieve

2
Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A10 Infrared Controller Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
allOf:
- $ref: "rc.yaml#"

3
Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml
View File

@ -60,7 +60,8 @@ patternProperties:
maximum: 1066000000
nvidia,emem-configuration:
$ref: /schemas/types.yaml#/definitions/uint32-array
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
description: |
Values to be written to the EMEM register block. See section
"15.6.1 MC Registers" in the TRM.

9
Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
View File

@ -56,7 +56,8 @@ patternProperties:
maximum: 900000000
nvidia,emc-auto-cal-interval:
$ref: /schemas/types.yaml#/definitions/uint32
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
description:
Pad calibration interval in microseconds.
minimum: 0
@ -78,7 +79,8 @@ patternProperties:
Mode Register 0.
nvidia,emc-zcal-cnt-long:
$ref: /schemas/types.yaml#/definitions/uint32
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
description:
Number of EMC clocks to wait before issuing any commands after
sending ZCAL_MRW_CMD.
@ -96,7 +98,8 @@ patternProperties:
FBIO "read" FIFO periodic resetting enabled.
nvidia,emc-configuration:
$ref: /schemas/types.yaml#/definitions/uint32-array
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
description:
EMC timing characterization data. These are the registers
(see section "18.13.2 EMC Registers" in the TRM) whose values

3
Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml
View File

@ -77,7 +77,8 @@ patternProperties:
maximum: 900000000
nvidia,emem-configuration:
$ref: /schemas/types.yaml#/definitions/uint32-array
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
description: |
Values to be written to the EMEM register block. See section
"18.13.1 MC Registers" in the TRM.

2
Documentation/devicetree/bindings/mfd/allwinner,sun4i-a10-ts.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A10 Resistive Touchscreen Controller Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
"#thermal-sensor-cells":

2
Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
View File

@ -11,7 +11,7 @@ allOf:
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
"#address-cells": true

2
Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml
View File

@ -11,7 +11,7 @@ allOf:
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
"#address-cells": true

2
Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml
View File

@ -11,7 +11,7 @@ allOf:
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:

2
Documentation/devicetree/bindings/net/allwinner,sun4i-a10-mdio.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A10 MDIO Controller Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
allOf:
- $ref: "mdio.yaml#"

2
Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
View File

@ -11,7 +11,7 @@ allOf:
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:

2
Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A83t EMAC Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:

2
Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A10 CAN Controller Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:

22
Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml
View File

@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/ti,cpsw-switch.yaml#
@ -44,7 +44,6 @@ properties:
description: CPSW functional clock
clock-names:
maxItems: 1
items:
- const: fck
@ -70,7 +69,6 @@ properties:
Phandle to the system control device node which provides access to
efuse IO range with MAC addresses
ethernet-ports:
type: object
properties:
@ -82,8 +80,6 @@ properties:
patternProperties:
"^port@[0-9]+$":
type: object
minItems: 1
maxItems: 2
description: CPSW external ports
allOf:
@ -91,23 +87,20 @@ properties:
properties:
reg:
maxItems: 1
enum: [1, 2]
items:
- enum: [1, 2]
description: CPSW port number
phys:
$ref: /schemas/types.yaml#definitions/phandle-array
maxItems: 1
description: phandle on phy-gmii-sel PHY
label:
$ref: /schemas/types.yaml#/definitions/string-array
maxItems: 1
description: label associated with this port
ti,dual-emac-pvid:
$ref: /schemas/types.yaml#/definitions/uint32
maxItems: 1
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 1024
description:
@ -136,7 +129,6 @@ properties:
description: CPTS reference clock
clock-names:
maxItems: 1
items:
- const: cpts
@ -201,7 +193,7 @@ examples:
phys = <&phy_gmii_sel 1>;
phy-handle = <&ethphy0_sw>;
phy-mode = "rgmii";
ti,dual_emac_pvid = <1>;
ti,dual-emac-pvid = <1>;
};
cpsw_port2: port@2 {
@ -211,7 +203,7 @@ examples:
phys = <&phy_gmii_sel 2>;
phy-handle = <&ethphy1_sw>;
phy-mode = "rgmii";
ti,dual_emac_pvid = <2>;
ti,dual-emac-pvid = <2>;
};
};

2
Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A10 Security ID Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
allOf:
- $ref: "nvmem.yaml#"

8
Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml
View File

@ -8,14 +8,18 @@ title: Allwinner A31 MIPI D-PHY Controller Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
"#phy-cells":
const: 0
compatible:
const: allwinner,sun6i-a31-mipi-dphy
oneOf:
- const: allwinner,sun6i-a31-mipi-dphy
- items:
- const: allwinner,sun50i-a64-mipi-dphy
- const: allwinner,sun6i-a31-mipi-dphy
reg:
maxItems: 1

2
Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A10 Pin Controller Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
"#gpio-cells":

2
Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A10 PWM Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
"#pwm-cells":

2
Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
View File

@ -50,6 +50,8 @@ properties:
description: Should contain the WWDG1 watchdog reset interrupt
maxItems: 1
wakeup-source: true
mboxes:
description:
This property is required only if the rpmsg/virtio functionality is used.

2
Documentation/devicetree/bindings/rtc/allwinner,sun4i-a10-rtc.yaml
View File

@ -11,7 +11,7 @@ allOf:
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:

2
Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A31 RTC Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
"#clock-cells":

2
Documentation/devicetree/bindings/serio/allwinner,sun4i-a10-ps2.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A10 PS2 Host Controller Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
description:
A20 PS2 is dual role controller (PS2 host and PS2 device). These

2
Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A10 Codec Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
"#sound-dai-cells":

2
Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A10 I2S Controller Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
"#sound-dai-cells":

2
Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml
View File

@ -10,7 +10,7 @@ maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Liam Girdwood <lgirdwood@gmail.com>
- Mark Brown <broonie@kernel.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
"#sound-dai-cells":

2
Documentation/devicetree/bindings/sound/allwinner,sun50i-a64-codec-analog.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A64 Analog Codec Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:

2
Documentation/devicetree/bindings/sound/allwinner,sun8i-a23-codec-analog.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A23 Analog Codec Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:

2
Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A33 Codec Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
"#sound-dai-cells":

2
Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml
View File

@ -11,7 +11,7 @@ allOf:
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
"#address-cells": true

2
Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml
View File

@ -11,7 +11,7 @@ allOf:
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
"#address-cells": true

2
Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A10 Timer Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:

2
Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A13 High-Speed Timer Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:

2
Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
View File

@ -8,7 +8,7 @@ title: Allwinner A10 mUSB OTG Controller Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:

4
Documentation/devicetree/bindings/vendor-prefixes.yaml
View File

@ -513,6 +513,8 @@ patternProperties:
description: Lantiq Semiconductor
"^lattice,.*":
description: Lattice Semiconductor
"^leadtek,.*":
description: Shenzhen Leadtek Technology Co., Ltd.
"^leez,.*":
description: Leez
"^lego,.*":
@ -1056,6 +1058,8 @@ patternProperties:
description: Extreme Engineering Solutions (X-ES)
"^xillybus,.*":
description: Xillybus Ltd.
"^xinpeng,.*":
description: Shenzhen Xinpeng Technology Co., Ltd
"^xlnx,.*":
description: Xilinx
"^xunlong,.*":

2
Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
View File

@ -11,7 +11,7 @@ allOf:
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:

13
Documentation/fb/fbcon.rst
View File

@ -127,7 +127,7 @@ C. Boot options
is typically located on the same video card. Thus, the consoles that
are controlled by the VGA console will be garbled.
4. fbcon=rotate:<n>
5. fbcon=rotate:<n>
This option changes the orientation angle of the console display. The
value 'n' accepts the following:
@ -152,21 +152,21 @@ C. Boot options
Actually, the underlying fb driver is totally ignorant of console
rotation.
5. fbcon=margin:<color>
6. fbcon=margin:<color>
This option specifies the color of the margins. The margins are the
leftover area at the right and the bottom of the screen that are not
used by text. By default, this area will be black. The 'color' value
is an integer number that depends on the framebuffer driver being used.
6. fbcon=nodefer
7. fbcon=nodefer
If the kernel is compiled with deferred fbcon takeover support, normally
the framebuffer contents, left in place by the firmware/bootloader, will
be preserved until there actually is some text is output to the console.
This option causes fbcon to bind immediately to the fbdev device.
7. fbcon=logo-pos:<location>
8. fbcon=logo-pos:<location>
The only possible 'location' is 'center' (without quotes), and when
given, the bootup logo is moved from the default top-left corner
@ -174,6 +174,11 @@ C. Boot options
displayed due to multiple CPUs, the collected line of logos is moved
as a whole.
9. fbcon=logo-count:<n>
The value 'n' overrides the number of bootup logos. 0 disables the
logo, and -1 gives the default which is the number of online CPUs.
C. Attaching, Detaching and Unloading
Before going on to how to attach, detach and unload the framebuffer console, an

3
Documentation/fb/modedb.rst
View File

@ -65,6 +65,9 @@ Valid options are::
- reflect_y (boolean): Perform an axial symmetry on the Y axis
- rotate (integer): Rotate the initial framebuffer by x
degrees. Valid values are 0, 90, 180 and 270.
- panel_orientation, one of "normal", "upside_down", "left_side_up", or
"right_side_up". For KMS drivers only, this sets the "panel orientation"
property on the kms connector as hint for kms users.
-----------------------------------------------------------------------------

27
Documentation/filesystems/erofs.txt
View File

@ -24,11 +24,11 @@ Here is the main features of EROFS:
- Metadata & data could be mixed by design;
- 2 inode versions for different requirements:
v1 v2
compact (v1) extended (v2)
Inode metadata size: 32 bytes 64 bytes
Max file size: 4 GB 16 EB (also limited by max. vol size)
Max uids/gids: 65536 4294967296
File creation time: no yes (64 + 32-bit timestamp)
File change time: no yes (64 + 32-bit timestamp)
Max hardlinks: 65536 4294967296
Metadata reserved: 4 bytes 14 bytes
@ -39,7 +39,7 @@ Here is the main features of EROFS:
- Support POSIX.1e ACLs by using xattrs;
- Support transparent file compression as an option:
LZ4 algorithm with 4 KB fixed-output compression for high performance;
LZ4 algorithm with 4 KB fixed-sized output compression for high performance.
The following git tree provides the file system user-space tools under
development (ex, formatting tool mkfs.erofs):
@ -85,7 +85,7 @@ All data areas should be aligned with the block size, but metadata areas
may not. All metadatas can be now observed in two different spaces (views):
1. Inode metadata space
Each valid inode should be aligned with an inode slot, which is a fixed
value (32 bytes) and designed to be kept in line with v1 inode size.
value (32 bytes) and designed to be kept in line with compact inode size.
Each inode can be directly found with the following formula:
inode offset = meta_blkaddr * block_size + 32 * nid
@ -117,10 +117,10 @@ may not. All metadatas can be now observed in two different spaces (views):
|-> aligned with 4B
Inode could be 32 or 64 bytes, which can be distinguished from a common
field which all inode versions have -- i_advise:
field which all inode versions have -- i_format:
__________________ __________________
| i_advise | | i_advise |
| i_format | | i_format |
|__________________| |__________________|
| ... | | ... |
| | | |
@ -129,12 +129,13 @@ may not. All metadatas can be now observed in two different spaces (views):
|__________________| 64 bytes
Xattrs, extents, data inline are followed by the corresponding inode with
proper alignes, and they could be optional for different data mappings,
_currently_ there are totally 3 valid data mappings supported:
proper alignment, and they could be optional for different data mappings.
_currently_ total 4 valid data mappings are supported:
1) flat file data without data inline (no extent);
2) fixed-output size data compression (must have extents);
3) flat file data with tail-end data inline (no extent);
0 flat file data without data inline (no extent);
1 fixed-sized output data compression (with non-compacted indexes);
2 flat file data with tail packing data inline (no extent);
3 fixed-sized output data compression (with compacted indexes, v5.3+).
The size of the optional xattrs is indicated by i_xattr_count in inode
header. Large xattrs or xattrs shared by many different files can be
@ -182,8 +183,8 @@ introduce another on-disk field at all.
Compression
-----------
Currently, EROFS supports 4KB fixed-output clustersize transparent file
compression, as illustrated below:
Currently, EROFS supports 4KB fixed-sized output transparent file compression,
as illustrated below:
|---- Variant-Length Extent ----|-------- VLE --------|----- VLE -----
clusterofs clusterofs clusterofs

10
Documentation/filesystems/overlayfs.txt → Documentation/filesystems/overlayfs.rst
View File

@ -1,3 +1,5 @@
.. SPDX-License-Identifier: GPL-2.0
Written by: Neil Brown
Please see MAINTAINERS file for where to send questions.
@ -181,7 +183,7 @@ Kernel config options:
worried about backward compatibility with kernels that have the redirect_dir
feature and follow redirects even if turned off.
Module options (can also be changed through /sys/module/overlay/parameters/*):
Module options (can also be changed through /sys/module/overlay/parameters/):
- "redirect_dir=BOOL":
See OVERLAY_FS_REDIRECT_DIR kernel config option above.
@ -263,7 +265,7 @@ top, lower2 the middle and lower3 the bottom layer.
Metadata only copy up
--------------------
---------------------
When metadata only copy up feature is enabled, overlayfs will only copy
up metadata (as opposed to whole file), when a metadata specific operation
@ -286,10 +288,10 @@ pointed by REDIRECT. This should not be possible on local system as setting
"trusted." xattrs will require CAP_SYS_ADMIN. But it should be possible
for untrusted layers like from a pen drive.
Note: redirect_dir={off|nofollow|follow(*)} conflicts with metacopy=on, and
Note: redirect_dir={off|nofollow|follow[*]} conflicts with metacopy=on, and
results in an error.
(*) redirect_dir=follow only conflicts with metacopy=on if upperdir=... is
[*] redirect_dir=follow only conflicts with metacopy=on if upperdir=... is
given.
Sharing and copying layers

4
Documentation/gpu/drm-internals.rst
View File

@ -24,9 +24,9 @@ Driver Initialization
At the core of every DRM driver is a :c:type:`struct drm_driver
<drm_driver>` structure. Drivers typically statically initialize
a drm_driver structure, and then pass it to
:c:func:`drm_dev_alloc()` to allocate a device instance. After the
drm_dev_alloc() to allocate a device instance. After the
device instance is fully initialized it can be registered (which makes
it accessible from userspace) using :c:func:`drm_dev_register()`.
it accessible from userspace) using drm_dev_register().
The :c:type:`struct drm_driver <drm_driver>` structure
contains static information that describes the driver and features it

19
Documentation/gpu/drm-kms.rst
View File

@ -3,7 +3,7 @@ Kernel Mode Setting (KMS)
=========================
Drivers must initialize the mode setting core by calling
:c:func:`drm_mode_config_init()` on the DRM device. The function
drm_mode_config_init() on the DRM device. The function
initializes the :c:type:`struct drm_device <drm_device>`
mode_config field and never fails. Once done, mode configuration must
be setup by initializing the following fields.
@ -181,8 +181,7 @@ Setting`_). The somewhat surprising part here is that properties are not
directly instantiated on each object, but free-standing mode objects themselves,
represented by :c:type:`struct drm_property <drm_property>`, which only specify
the type and value range of a property. Any given property can be attached
multiple times to different objects using :c:func:`drm_object_attach_property()
<drm_object_attach_property>`.
multiple times to different objects using drm_object_attach_property().
.. kernel-doc:: include/drm/drm_mode_object.h
:internal:
@ -260,7 +259,8 @@ Taken all together there's two consequences for the atomic design:
drm_connector_state <drm_connector_state>` for connectors. These are the only
objects with userspace-visible and settable state. For internal state drivers
can subclass these structures through embeddeding, or add entirely new state
structures for their globally shared hardware functions.
structures for their globally shared hardware functions, see :c:type:`struct
drm_private_state<drm_private_state>`.
- An atomic update is assembled and validated as an entirely free-standing pile
of structures within the :c:type:`drm_atomic_state <drm_atomic_state>`
@ -269,6 +269,14 @@ Taken all together there's two consequences for the atomic design:
to the driver and modeset objects. This way rolling back an update boils down
to releasing memory and unreferencing objects like framebuffers.
Locking of atomic state structures is internally using :c:type:`struct
drm_modeset_lock <drm_modeset_lock>`. As a general rule the locking shouldn't be
exposed to drivers, instead the right locks should be automatically acquired by
any function that duplicates or peeks into a state, like e.g.
drm_atomic_get_crtc_state(). Locking only protects the software data
structure, ordering of committing state changes to hardware is sequenced using
:c:type:`struct drm_crtc_commit <drm_crtc_commit>`.
Read on in this chapter, and also in :ref:`drm_atomic_helper` for more detailed
coverage of specific topics.
@ -479,6 +487,9 @@ Color Management Properties
.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
:export:
.. kernel-doc:: include/drm/drm_color_mgmt.h
:internal:
Tile Group Property
-------------------

68
Documentation/gpu/drm-mm.rst
View File

@ -149,19 +149,19 @@ struct :c:type:`struct drm_gem_object <drm_gem_object>`.
To create a GEM object, a driver allocates memory for an instance of its
specific GEM object type and initializes the embedded struct
:c:type:`struct drm_gem_object <drm_gem_object>` with a call
to :c:func:`drm_gem_object_init()`. The function takes a pointer
to drm_gem_object_init(). The function takes a pointer
to the DRM device, a pointer to the GEM object and the buffer object
size in bytes.
GEM uses shmem to allocate anonymous pageable memory.
:c:func:`drm_gem_object_init()` will create an shmfs file of the
drm_gem_object_init() will create an shmfs file of the
requested size and store it into the struct :c:type:`struct
drm_gem_object <drm_gem_object>` filp field. The memory is
used as either main storage for the object when the graphics hardware
uses system memory directly or as a backing store otherwise.
Drivers are responsible for the actual physical pages allocation by
calling :c:func:`shmem_read_mapping_page_gfp()` for each page.
calling shmem_read_mapping_page_gfp() for each page.
Note that they can decide to allocate pages when initializing the GEM
object, or to delay allocation until the memory is needed (for instance
when a page fault occurs as a result of a userspace memory access or
@ -170,20 +170,18 @@ when the driver needs to start a DMA transfer involving the memory).
Anonymous pageable memory allocation is not always desired, for instance
when the hardware requires physically contiguous system memory as is
often the case in embedded devices. Drivers can create GEM objects with
no shmfs backing (called private GEM objects) by initializing them with
a call to :c:func:`drm_gem_private_object_init()` instead of
:c:func:`drm_gem_object_init()`. Storage for private GEM objects
must be managed by drivers.
no shmfs backing (called private GEM objects) by initializing them with a call
to drm_gem_private_object_init() instead of drm_gem_object_init(). Storage for
private GEM objects must be managed by drivers.
GEM Objects Lifetime
--------------------
All GEM objects are reference-counted by the GEM core. References can be
acquired and release by :c:func:`calling drm_gem_object_get()` and
:c:func:`drm_gem_object_put()` respectively. The caller must hold the
:c:type:`struct drm_device <drm_device>` struct_mutex lock when calling
:c:func:`drm_gem_object_get()`. As a convenience, GEM provides
:c:func:`drm_gem_object_put_unlocked()` functions that can be called without
acquired and release by calling drm_gem_object_get() and drm_gem_object_put()
respectively. The caller must hold the :c:type:`struct drm_device <drm_device>`
struct_mutex lock when calling drm_gem_object_get(). As a convenience, GEM
provides drm_gem_object_put_unlocked() functions that can be called without
holding the lock.
When the last reference to a GEM object is released the GEM core calls
@ -194,7 +192,7 @@ free the GEM object and all associated resources.
void (\*gem_free_object) (struct drm_gem_object \*obj); Drivers are
responsible for freeing all GEM object resources. This includes the
resources created by the GEM core, which need to be released with
:c:func:`drm_gem_object_release()`.
drm_gem_object_release().
GEM Objects Naming
------------------
@ -210,13 +208,11 @@ to the GEM object in other standard or driver-specific ioctls. Closing a
DRM file handle frees all its GEM handles and dereferences the
associated GEM objects.
To create a handle for a GEM object drivers call
:c:func:`drm_gem_handle_create()`. The function takes a pointer
to the DRM file and the GEM object and returns a locally unique handle.
When the handle is no longer needed drivers delete it with a call to
:c:func:`drm_gem_handle_delete()`. Finally the GEM object
associated with a handle can be retrieved by a call to
:c:func:`drm_gem_object_lookup()`.
To create a handle for a GEM object drivers call drm_gem_handle_create(). The
function takes a pointer to the DRM file and the GEM object and returns a
locally unique handle. When the handle is no longer needed drivers delete it
with a call to drm_gem_handle_delete(). Finally the GEM object associated with a
handle can be retrieved by a call to drm_gem_object_lookup().
Handles don't take ownership of GEM objects, they only take a reference
to the object that will be dropped when the handle is destroyed. To
@ -258,7 +254,7 @@ The mmap system call can't be used directly to map GEM objects, as they
don't have their own file handle. Two alternative methods currently
co-exist to map GEM objects to userspace. The first method uses a
driver-specific ioctl to perform the mapping operation, calling
:c:func:`do_mmap()` under the hood. This is often considered
do_mmap() under the hood. This is often considered
dubious, seems to be discouraged for new GEM-enabled drivers, and will
thus not be described here.
@ -267,23 +263,22 @@ The second method uses the mmap system call on the DRM file handle. void
offset); DRM identifies the GEM object to be mapped by a fake offset
passed through the mmap offset argument. Prior to being mapped, a GEM
object must thus be associated with a fake offset. To do so, drivers
must call :c:func:`drm_gem_create_mmap_offset()` on the object.
must call drm_gem_create_mmap_offset() on the object.
Once allocated, the fake offset value must be passed to the application
in a driver-specific way and can then be used as the mmap offset
argument.
The GEM core provides a helper method :c:func:`drm_gem_mmap()` to
The GEM core provides a helper method drm_gem_mmap() to
handle object mapping. The method can be set directly as the mmap file
operation handler. It will look up the GEM object based on the offset
value and set the VMA operations to the :c:type:`struct drm_driver
<drm_driver>` gem_vm_ops field. Note that
:c:func:`drm_gem_mmap()` doesn't map memory to userspace, but
relies on the driver-provided fault handler to map pages individually.
<drm_driver>` gem_vm_ops field. Note that drm_gem_mmap() doesn't map memory to
userspace, but relies on the driver-provided fault handler to map pages
individually.
To use :c:func:`drm_gem_mmap()`, drivers must fill the struct
:c:type:`struct drm_driver <drm_driver>` gem_vm_ops field
with a pointer to VM operations.
To use drm_gem_mmap(), drivers must fill the struct :c:type:`struct drm_driver
<drm_driver>` gem_vm_ops field with a pointer to VM operations.
The VM operations is a :c:type:`struct vm_operations_struct <vm_operations_struct>`
made up of several fields, the more interesting ones being:
@ -298,9 +293,8 @@ made up of several fields, the more interesting ones being:
The open and close operations must update the GEM object reference
count. Drivers can use the :c:func:`drm_gem_vm_open()` and
:c:func:`drm_gem_vm_close()` helper functions directly as open
and close handlers.
count. Drivers can use the drm_gem_vm_open() and drm_gem_vm_close() helper
functions directly as open and close handlers.
The fault operation handler is responsible for mapping individual pages
to userspace when a page fault occurs. Depending on the memory
@ -312,12 +306,12 @@ Drivers that want to map the GEM object upfront instead of handling page
faults can implement their own mmap file operation handler.
For platforms without MMU the GEM core provides a helper method
:c:func:`drm_gem_cma_get_unmapped_area`. The mmap() routines will call
this to get a proposed address for the mapping.
drm_gem_cma_get_unmapped_area(). The mmap() routines will call this to get a
proposed address for the mapping.
To use :c:func:`drm_gem_cma_get_unmapped_area`, drivers must fill the
struct :c:type:`struct file_operations <file_operations>` get_unmapped_area
field with a pointer on :c:func:`drm_gem_cma_get_unmapped_area`.
To use drm_gem_cma_get_unmapped_area(), drivers must fill the struct
:c:type:`struct file_operations <file_operations>` get_unmapped_area field with
a pointer on drm_gem_cma_get_unmapped_area().
More detailed information about get_unmapped_area can be found in
Documentation/nommu-mmap.txt

49
Documentation/gpu/drm-uapi.rst
View File

@ -254,36 +254,45 @@ Validating changes with IGT
There's a collection of tests that aims to cover the whole functionality of
DRM drivers and that can be used to check that changes to DRM drivers or the
core don't regress existing functionality. This test suite is called IGT and
its code can be found in https://cgit.freedesktop.org/drm/igt-gpu-tools/.
its code and instructions to build and run can be found in
https://gitlab.freedesktop.org/drm/igt-gpu-tools/.
To build IGT, start by installing its build dependencies. In Debian-based
systems::
Using VKMS to test DRM API
--------------------------
# apt-get build-dep intel-gpu-tools
VKMS is a software-only model of a KMS driver that is useful for testing
and for running compositors. VKMS aims to enable a virtual display without
the need for a hardware display capability. These characteristics made VKMS
a perfect tool for validating the DRM core behavior and also support the
compositor developer. VKMS makes it possible to test DRM functions in a
virtual machine without display, simplifying the validation of some of the
core changes.
And in Fedora-based systems::
To Validate changes in DRM API with VKMS, start setting the kernel: make
sure to enable VKMS module; compile the kernel with the VKMS enabled and
install it in the target machine. VKMS can be run in a Virtual Machine
(QEMU, virtme or similar). It's recommended the use of KVM with the minimum
of 1GB of RAM and four cores.
# dnf builddep intel-gpu-tools
It's possible to run the IGT-tests in a VM in two ways:
Then clone the repository::
1. Use IGT inside a VM
2. Use IGT from the host machine and write the results in a shared directory.
$ git clone git://anongit.freedesktop.org/drm/igt-gpu-tools
As follow, there is an example of using a VM with a shared directory with
the host machine to run igt-tests. As an example it's used virtme::
Configure the build system and start the build::
$ virtme-run --rwdir /path/for/shared_dir --kdir=path/for/kernel/directory --mods=auto
$ cd igt-gpu-tools && ./autogen.sh && make -j6
Run the igt-tests in the guest machine, as example it's ran the 'kms_flip'
tests::
Download the piglit dependency::
$ /path/for/igt-gpu-tools/scripts/run-tests.sh -p -s -t "kms_flip.*" -v
$ ./scripts/run-tests.sh -d
And run the tests::
$ ./scripts/run-tests.sh -t kms -t core -s
run-tests.sh is a wrapper around piglit that will execute the tests matching
the -t options. A report in HTML format will be available in
./results/html/index.html. Results can be compared with piglit.
In this example, instead of build the igt_runner, Piglit is used
(-p option); it's created html summary of the tests results and it's saved
in the folder "igt-gpu-tools/results"; it's executed only the igt-tests
matching the -t option.
Display CRC Support
-------------------

74
Documentation/gpu/todo.rst
View File

@ -142,14 +142,14 @@ Contact: Daniel Vetter, respective driver maintainers
Level: Advanced
Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent
----------------------------------------------------------------------------
Convert logging to drm_* functions with drm_device paramater
------------------------------------------------------------
For drivers which could have multiple instances, it is necessary to
differentiate between which is which in the logs. Since DRM_INFO/WARN/ERROR
don't do this, drivers used dev_info/warn/err to make this differentiation. We
now have DRM_DEV_* variants of the drm print macros, so we can start to convert
those drivers back to using drm-formwatted specific log messages.
now have drm_* variants of the drm print functions, so we can start to convert
those drivers back to using drm-formatted specific log messages.
Before you start this conversion please contact the relevant maintainers to make
sure your work will be merged - not everyone agrees that the DRM dmesg macros
@ -171,26 +171,43 @@ Contact: Maintainer of the driver you plan to convert
Level: Intermediate
Convert drivers to use drm_fb_helper_fbdev_setup/teardown()
-----------------------------------------------------------
Convert drivers to use drm_fbdev_generic_setup()
------------------------------------------------
Most drivers can use drm_fb_helper_fbdev_setup() except maybe:
- amdgpu which has special logic to decide whether to call
drm_helper_disable_unused_functions()
- armada which isn't atomic and doesn't call
drm_helper_disable_unused_functions()
- i915 which calls drm_fb_helper_initial_config() in a worker
Drivers that use drm_framebuffer_remove() to clean up the fbdev framebuffer can
probably use drm_fb_helper_fbdev_teardown().
Most drivers can use drm_fbdev_generic_setup(). Driver have to implement
atomic modesetting and GEM vmap support. Current generic fbdev emulation
expects the framebuffer in system memory (or system-like memory).
Contact: Maintainer of the driver you plan to convert
Level: Intermediate
drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
-----------------------------------------------------------------
A lot more drivers could be switched over to the drm_gem_framebuffer helpers.
Various hold-ups:
- Need to switch over to the generic dirty tracking code using
drm_atomic_helper_dirtyfb first (e.g. qxl).
- Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb
setup code can't be deleted.
- Many drivers wrap drm_gem_fb_create() only to check for valid formats. For
atomic drivers we could check for valid formats by calling
drm_plane_check_pixel_format() against all planes, and pass if any plane
supports the format. For non-atomic that's not possible since like the format
list for the primary plane is fake and we'd therefor reject valid formats.
- Many drivers subclass drm_framebuffer, we'd need a embedding compatible
version of the varios drm_gem_fb_create functions. Maybe called
drm_gem_fb_create/_with_dirty/_with_funcs as needed.
Contact: Daniel Vetter
Level: Intermediate
Clean up mmap forwarding
------------------------
@ -328,8 +345,8 @@ drm_fb_helper tasks
these igt tests need to be fixed: kms_fbcon_fbt@psr and
kms_fbcon_fbt@psr-suspend.
- The max connector argument for drm_fb_helper_init() and
drm_fb_helper_fbdev_setup() isn't used anymore and can be removed.
- The max connector argument for drm_fb_helper_init() isn't used anymore and
can be removed.
- The helper doesn't keep an array of connectors anymore so these can be
removed: drm_fb_helper_single_add_all_connectors(),
@ -351,6 +368,23 @@ connector register/unregister fixes
Level: Intermediate
Remove load/unload callbacks from all non-DRIVER_LEGACY drivers
---------------------------------------------------------------
The load/unload callbacks in struct &drm_driver are very much midlayers, plus
for historical reasons they get the ordering wrong (and we can't fix that)
between setting up the &drm_driver structure and calling drm_dev_register().
- Rework drivers to no longer use the load/unload callbacks, directly coding the
load/unload sequence into the driver's probe function.
- Once all non-DRIVER_LEGACY drivers are converted, disallow the load/unload
callbacks for all modern drivers.
Contact: Daniel Vetter
Level: Intermediate
Core refactorings
=================

2
Documentation/process/coding-style.rst
View File

@ -988,7 +988,7 @@ Similarly, if you need to calculate the size of some structure member, use
.. code-block:: c
#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
#define sizeof_field(t, f) (sizeof(((t*)0)->f))
There are also min() and max() macros that do strict type checking if you
need them. Feel free to peruse that header file to see what else is already

2
Documentation/scsi/smartpqi.txt
View File

@ -29,7 +29,7 @@ smartpqi specific entries in /sys
smartpqi host attributes:
-------------------------
/sys/class/scsi_host/host*/rescan
/sys/class/scsi_host/host*/version
/sys/class/scsi_host/host*/driver_version
The host rescan attribute is a write only attribute. Writing to this
attribute will trigger the driver to scan for new, changed, or removed

2
Documentation/translations/it_IT/process/coding-style.rst
View File

@ -1005,7 +1005,7 @@ struttura, usate
.. code-block:: c
#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
#define sizeof_field(t, f) (sizeof(((t*)0)->f))
Ci sono anche le macro min() e max() che, se vi serve, effettuano un controllo
rigido sui tipi. Sentitevi liberi di leggere attentamente questo file

2
Documentation/translations/zh_CN/process/coding-style.rst
View File

@ -826,7 +826,7 @@ inline gcc 也可以自动使其内联。而且其他用户可能会要求移除
.. code-block:: c
#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
#define sizeof_field(t, f) (sizeof(((t*)0)->f))
还有可以做严格的类型检查的 min() 和 max() 宏，如果你需要可以使用它们。你可以
自己看看那个头文件里还定义了什么你可以拿来用的东西，如果有定义的话，你就不应

34
MAINTAINERS
View File

@ -4970,6 +4970,25 @@ F: include/linux/dma-buf*
F: include/linux/reservation.h
F: include/linux/*fence.h
F: Documentation/driver-api/dma-buf.rst
K: dma_(buf|fence|resv)
T: git git://anongit.freedesktop.org/drm/drm-misc
DMA-BUF HEAPS FRAMEWORK
M: Sumit Semwal <sumit.semwal@linaro.org>
R: Andrew F. Davis <afd@ti.com>
R: Benjamin Gaignard <benjamin.gaignard@linaro.org>
R: Liam Mark <lmark@codeaurora.org>
R: Laura Abbott <labbott@redhat.com>
R: Brian Starkey <Brian.Starkey@arm.com>
R: John Stultz <john.stultz@linaro.org>
S: Maintained
L: linux-media@vger.kernel.org
L: dri-devel@lists.freedesktop.org
L: linaro-mm-sig@lists.linaro.org (moderated for non-subscribers)
F: include/uapi/linux/dma-heap.h
F: include/linux/dma-heap.h
F: drivers/dma-buf/dma-heap.c
F: drivers/dma-buf/heaps/*
T: git git://anongit.freedesktop.org/drm/drm-misc
DMA GENERIC OFFLOAD ENGINE SUBSYSTEM
@ -5177,6 +5196,12 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
S: Maintained
F: drivers/gpu/drm/bochs/
DRM DRIVER FOR BOE HIMAX8279D PANELS
M: Jerry Han <hanxu5@huaqin.corp-partner.google.com>
S: Maintained
F: drivers/gpu/drm/panel/panel-boe-himax8279d.c
F: Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
DRM DRIVER FOR FARADAY TVE200 TV ENCODER
M: Linus Walleij <linus.walleij@linaro.org>
T: git git://anongit.freedesktop.org/drm/drm-misc
@ -5404,7 +5429,6 @@ F: include/linux/vga*
DRM DRIVERS AND MISC GPU PATCHES
M: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
M: Maxime Ripard <mripard@kernel.org>
M: Sean Paul <sean@poorly.run>
W: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html
S: Maintained
T: git git://anongit.freedesktop.org/drm/drm-misc
@ -12393,7 +12417,7 @@ L: linux-unionfs@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git
S: Supported
F: fs/overlayfs/
F: Documentation/filesystems/overlayfs.txt
F: Documentation/filesystems/overlayfs.rst
P54 WIRELESS DRIVER
M: Christian Lamparter <chunkeey@googlemail.com>
@ -16314,12 +16338,10 @@ F: drivers/media/radio/radio-raremono.c
THERMAL
M: Zhang Rui <rui.zhang@intel.com>
M: Eduardo Valentin <edubezval@gmail.com>
R: Daniel Lezcano <daniel.lezcano@linaro.org>
M: Daniel Lezcano <daniel.lezcano@linaro.org>
R: Amit Kucheria <amit.kucheria@verdurent.com>
L: linux-pm@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/thermal/linux.git
Q: https://patchwork.kernel.org/project/linux-pm/list/
S: Supported
F: drivers/thermal/

2
Makefile
View File

@ -2,7 +2,7 @@
VERSION = 5
PATCHLEVEL = 5
SUBLEVEL = 0
EXTRAVERSION = -rc1
EXTRAVERSION = -rc2
NAME = Kleptomaniac Octopus
# *DOCUMENTATION*

6
arch/arc/kernel/unwind.c
View File

@ -42,10 +42,10 @@ do { \
#define EXTRA_INFO(f) { \
BUILD_BUG_ON_ZERO(offsetof(struct unwind_frame_info, f) \
% FIELD_SIZEOF(struct unwind_frame_info, f)) \
% sizeof_field(struct unwind_frame_info, f)) \
+ offsetof(struct unwind_frame_info, f) \
/ FIELD_SIZEOF(struct unwind_frame_info, f), \
FIELD_SIZEOF(struct unwind_frame_info, f) \
/ sizeof_field(struct unwind_frame_info, f), \
sizeof_field(struct unwind_frame_info, f) \
}
#define PTREGS_INFO(f) EXTRA_INFO(regs.f)

7
arch/arm/crypto/curve25519-glue.c
View File

@ -38,6 +38,13 @@ void curve25519_arch(u8 out[CURVE25519_KEY_SIZE],
}
EXPORT_SYMBOL(curve25519_arch);
void curve25519_base_arch(u8 pub[CURVE25519_KEY_SIZE],
const u8 secret[CURVE25519_KEY_SIZE])
{
return curve25519_arch(pub, secret, curve25519_base_point);
}
EXPORT_SYMBOL(curve25519_base_arch);
static int curve25519_set_secret(struct crypto_kpp *tfm, const void *buf,
unsigned int len)
{

9
arch/mips/cavium-octeon/executive/cvmx-bootmem.c
View File

@ -44,13 +44,6 @@ static struct cvmx_bootmem_desc *cvmx_bootmem_desc;
/* See header file for descriptions of functions */
/**
* This macro returns the size of a member of a structure.
* Logically it is the same as "sizeof(s::field)" in C++, but
* C lacks the "::" operator.
*/
#define SIZEOF_FIELD(s, field) sizeof(((s *)NULL)->field)
/**
* This macro returns a member of the
* cvmx_bootmem_named_block_desc_t structure. These members can't
@ -65,7 +58,7 @@ static struct cvmx_bootmem_desc *cvmx_bootmem_desc;
#define CVMX_BOOTMEM_NAMED_GET_FIELD(addr, field) \
__cvmx_bootmem_desc_get(addr, \
offsetof(struct cvmx_bootmem_named_block_desc, field), \
SIZEOF_FIELD(struct cvmx_bootmem_named_block_desc, field))
sizeof_field(struct cvmx_bootmem_named_block_desc, field))
/**
* This function is the implementation of the get macros defined

8
arch/nios2/mm/ioremap.c
View File

@ -138,6 +138,14 @@ void __iomem *ioremap(unsigned long phys_addr, unsigned long size)
return NULL;
}
/*
* Map uncached objects in the low part of address space to
* CONFIG_NIOS2_IO_REGION_BASE
*/
if (IS_MAPPABLE_UNCACHEABLE(phys_addr) &&
IS_MAPPABLE_UNCACHEABLE(last_addr))
return (void __iomem *)(CONFIG_NIOS2_IO_REGION_BASE + phys_addr);
/* Mappings have to be page-aligned */
offset = phys_addr & ~PAGE_MASK;
phys_addr &= PAGE_MASK;

4
arch/powerpc/net/bpf_jit32.h
View File

@ -97,12 +97,12 @@ DECLARE_LOAD_FUNC(sk_load_byte_msh);
#ifdef CONFIG_SMP
#ifdef CONFIG_PPC64
#define PPC_BPF_LOAD_CPU(r) \
do { BUILD_BUG_ON(FIELD_SIZEOF(struct paca_struct, paca_index) != 2); \
do { BUILD_BUG_ON(sizeof_field(struct paca_struct, paca_index) != 2); \
PPC_LHZ_OFFS(r, 13, offsetof(struct paca_struct, paca_index)); \
} while (0)
#else
#define PPC_BPF_LOAD_CPU(r) \
do { BUILD_BUG_ON(FIELD_SIZEOF(struct task_struct, cpu) != 4); \
do { BUILD_BUG_ON(sizeof_field(struct task_struct, cpu) != 4); \
PPC_LHZ_OFFS(r, 2, offsetof(struct task_struct, cpu)); \
} while(0)
#endif

16
arch/powerpc/net/bpf_jit_comp.c
View File

@ -321,7 +321,7 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
ctx->seen |= SEEN_XREG | SEEN_MEM | (1<<(K & 0xf));
break;
case BPF_LD | BPF_W | BPF_LEN: /* A = skb->len; */
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, len) != 4);
BUILD_BUG_ON(sizeof_field(struct sk_buff, len) != 4);
PPC_LWZ_OFFS(r_A, r_skb, offsetof(struct sk_buff, len));
break;
case BPF_LDX | BPF_W | BPF_ABS: /* A = *((u32 *)(seccomp_data + K)); */
@ -333,16 +333,16 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
/*** Ancillary info loads ***/
case BPF_ANC | SKF_AD_PROTOCOL: /* A = ntohs(skb->protocol); */
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff,
BUILD_BUG_ON(sizeof_field(struct sk_buff,
protocol) != 2);
PPC_NTOHS_OFFS(r_A, r_skb, offsetof(struct sk_buff,
protocol));
break;
case BPF_ANC | SKF_AD_IFINDEX:
case BPF_ANC | SKF_AD_HATYPE:
BUILD_BUG_ON(FIELD_SIZEOF(struct net_device,
BUILD_BUG_ON(sizeof_field(struct net_device,
ifindex) != 4);
BUILD_BUG_ON(FIELD_SIZEOF(struct net_device,
BUILD_BUG_ON(sizeof_field(struct net_device,
type) != 2);
PPC_LL_OFFS(r_scratch1, r_skb, offsetof(struct sk_buff,
dev));
@ -365,17 +365,17 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
break;
case BPF_ANC | SKF_AD_MARK:
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, mark) != 4);
BUILD_BUG_ON(sizeof_field(struct sk_buff, mark) != 4);
PPC_LWZ_OFFS(r_A, r_skb, offsetof(struct sk_buff,
mark));
break;
case BPF_ANC | SKF_AD_RXHASH:
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, hash) != 4);
BUILD_BUG_ON(sizeof_field(struct sk_buff, hash) != 4);
PPC_LWZ_OFFS(r_A, r_skb, offsetof(struct sk_buff,
hash));
break;
case BPF_ANC | SKF_AD_VLAN_TAG:
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, vlan_tci) != 2);
BUILD_BUG_ON(sizeof_field(struct sk_buff, vlan_tci) != 2);
PPC_LHZ_OFFS(r_A, r_skb, offsetof(struct sk_buff,
vlan_tci));
@ -388,7 +388,7 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
PPC_ANDI(r_A, r_A, 1);
break;
case BPF_ANC | SKF_AD_QUEUE:
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff,
BUILD_BUG_ON(sizeof_field(struct sk_buff,
queue_mapping) != 2);
PPC_LHZ_OFFS(r_A, r_skb, offsetof(struct sk_buff,
queue_mapping));

4
arch/riscv/Kconfig.socs
View File

@ -2,8 +2,8 @@ menu "SoC selection"
config SOC_SIFIVE
bool "SiFive SoCs"
select SERIAL_SIFIVE
select SERIAL_SIFIVE_CONSOLE
select SERIAL_SIFIVE if TTY
select SERIAL_SIFIVE_CONSOLE if TTY
select CLK_SIFIVE
select CLK_SIFIVE_FU540_PRCI
select SIFIVE_PLIC

2
arch/riscv/boot/Makefile
View File

@ -24,7 +24,7 @@ $(obj)/Image: vmlinux FORCE
$(obj)/Image.gz: $(obj)/Image FORCE
$(call if_changed,gzip)
loader.o: $(src)/loader.S $(obj)/Image
$(obj)/loader.o: $(src)/loader.S $(obj)/Image
$(obj)/loader: $(obj)/loader.o $(obj)/Image $(obj)/loader.lds FORCE
$(Q)$(LD) -T $(obj)/loader.lds -o $@ $(obj)/loader.o

1
arch/s390/Kconfig
View File

@ -124,6 +124,7 @@ config S390
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_JUMP_LABEL_RELATIVE
select HAVE_ARCH_KASAN
select HAVE_ARCH_KASAN_VMALLOC
select CPU_NO_EFFICIENT_FFS if !HAVE_MARCH_Z9_109_FEATURES
select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_SOFT_DIRTY

2
arch/s390/include/asm/setup.h
View File

@ -27,7 +27,6 @@
#define MACHINE_FLAG_DIAG9C BIT(3)
#define MACHINE_FLAG_ESOP BIT(4)
#define MACHINE_FLAG_IDTE BIT(5)
#define MACHINE_FLAG_DIAG44 BIT(6)
#define MACHINE_FLAG_EDAT1 BIT(7)
#define MACHINE_FLAG_EDAT2 BIT(8)
#define MACHINE_FLAG_TOPOLOGY BIT(10)
@ -94,7 +93,6 @@ extern unsigned long __swsusp_reset_dma;
#define MACHINE_HAS_DIAG9C (S390_lowcore.machine_flags & MACHINE_FLAG_DIAG9C)
#define MACHINE_HAS_ESOP (S390_lowcore.machine_flags & MACHINE_FLAG_ESOP)
#define MACHINE_HAS_IDTE (S390_lowcore.machine_flags & MACHINE_FLAG_IDTE)
#define MACHINE_HAS_DIAG44 (S390_lowcore.machine_flags & MACHINE_FLAG_DIAG44)
#define MACHINE_HAS_EDAT1 (S390_lowcore.machine_flags & MACHINE_FLAG_EDAT1)
#define MACHINE_HAS_EDAT2 (S390_lowcore.machine_flags & MACHINE_FLAG_EDAT2)
#define MACHINE_HAS_TOPOLOGY (S390_lowcore.machine_flags & MACHINE_FLAG_TOPOLOGY)

2
arch/s390/include/asm/uv.h
View File

@ -86,7 +86,7 @@ static inline int share(unsigned long addr, u16 cmd)
};
if (!is_prot_virt_guest())
return -ENOTSUPP;
return -EOPNOTSUPP;
/*
* Sharing is page wise, if we encounter addresses that are
* not page aligned, we assume something went wrong. If

16
arch/s390/kernel/early.c
View File

@ -204,21 +204,6 @@ static __init void detect_diag9c(void)
S390_lowcore.machine_flags |= MACHINE_FLAG_DIAG9C;
}
static __init void detect_diag44(void)
{
int rc;
diag_stat_inc(DIAG_STAT_X044);
asm volatile(
" diag 0,0,0x44\n"
"0: la %0,0\n"
"1:\n"
EX_TABLE(0b,1b)
: "=d" (rc) : "0" (-EOPNOTSUPP) : "cc");
if (!rc)
S390_lowcore.machine_flags |= MACHINE_FLAG_DIAG44;
}
static __init void detect_machine_facilities(void)
{
if (test_facility(8)) {
@ -331,7 +316,6 @@ void __init startup_init(void)
setup_arch_string();
setup_boot_command_line();
detect_diag9c();
detect_diag44();
detect_machine_facilities();
save_vector_registers();
setup_topology();

22
arch/s390/kernel/perf_cpum_sf.c
View File

@ -1303,18 +1303,28 @@ static void hw_perf_event_update(struct perf_event *event, int flush_all)
*/
if (flush_all && done)
break;
/* If an event overflow happened, discard samples by
* processing any remaining sample-data-blocks.
*/
if (event_overflow)
flush_all = 1;
}
/* Account sample overflows in the event hardware structure */
if (sampl_overflow)
OVERFLOW_REG(hwc) = DIV_ROUND_UP(OVERFLOW_REG(hwc) +
sampl_overflow, 1 + num_sdb);
/* Perf_event_overflow() and perf_event_account_interrupt() limit
* the interrupt rate to an upper limit. Roughly 1000 samples per
* task tick.
* Hitting this limit results in a large number
* of throttled REF_REPORT_THROTTLE entries and the samples
* are dropped.
* Slightly increase the interval to avoid hitting this limit.
*/
if (event_overflow) {
SAMPL_RATE(hwc) += DIV_ROUND_UP(SAMPL_RATE(hwc), 10);
debug_sprintf_event(sfdbg, 1, "%s: rate adjustment %ld\n",
__func__,
DIV_ROUND_UP(SAMPL_RATE(hwc), 10));
}
if (sampl_overflow || event_overflow)
debug_sprintf_event(sfdbg, 4, "%s: "
"overflows: sample %llu event %llu"

13
arch/s390/kernel/smp.c
View File

@ -413,14 +413,11 @@ EXPORT_SYMBOL(arch_vcpu_is_preempted);
void smp_yield_cpu(int cpu)
{
if (MACHINE_HAS_DIAG9C) {
diag_stat_inc_norecursion(DIAG_STAT_X09C);
asm volatile("diag %0,0,0x9c"
: : "d" (pcpu_devices[cpu].address));
} else if (MACHINE_HAS_DIAG44 && !smp_cpu_mtid) {
diag_stat_inc_norecursion(DIAG_STAT_X044);
asm volatile("diag 0,0,0x44");
}
if (!MACHINE_HAS_DIAG9C)
return;
diag_stat_inc_norecursion(DIAG_STAT_X09C);
asm volatile("diag %0,0,0x9c"
: : "d" (pcpu_devices[cpu].address));
}
/*

1
arch/s390/lib/spinlock.c
View File

@ -242,7 +242,6 @@ static inline void arch_spin_lock_classic(arch_spinlock_t *lp)
void arch_spin_lock_wait(arch_spinlock_t *lp)
{
/* Use classic spinlocks + niai if the steal time is >= 10% */
if (test_cpu_flag(CIF_DEDICATED_CPU))
arch_spin_lock_queued(lp);
else

2
arch/s390/lib/test_unwind.c
View File

@ -238,7 +238,7 @@ static int test_unwind_irq(struct unwindme *u)
{
preempt_disable();
if (register_external_irq(EXT_IRQ_CLK_COMP, unwindme_irq_handler)) {
pr_info("Couldn't reqister external interrupt handler");
pr_info("Couldn't register external interrupt handler");
return -1;
}
u->task = current;

Some files were not shown because too many files have changed in this diff Show More