mirror of
https://github.com/torvalds/linux.git
synced 2026-03-08 01:04:41 +01:00
Merge drm/drm-next into drm-xe-next
Backmerging to bring in a needed dependency for the Xe VFIO driver variant. This should ideally have been done before we commited that, so we now have a small window in drm-xe-next where that driver doesn't compile. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512030331.I8CveRre-lkp@intel.com/ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
This commit is contained in:
Thomas Hellström
commit
0f94e51b53
2857 changed files with 97306 additions and 24799 deletions
|
|
@ -167,7 +167,7 @@ ForEachMacros:
|
|||
- 'drm_connector_for_each_possible_encoder'
|
||||
- 'drm_exec_for_each_locked_object'
|
||||
- 'drm_exec_for_each_locked_object_reverse'
|
||||
- 'drm_for_each_bridge_in_chain'
|
||||
- 'drm_for_each_bridge_in_chain_scoped'
|
||||
- 'drm_for_each_connector_iter'
|
||||
- 'drm_for_each_crtc'
|
||||
- 'drm_for_each_crtc_reverse'
|
||||
|
|
|
|||
10
.mailmap
10
.mailmap
|
|
@ -27,6 +27,7 @@ Alan Cox <alan@lxorguk.ukuu.org.uk>
|
|||
Alan Cox <root@hraefn.swansea.linux.org.uk>
|
||||
Aleksandar Markovic <aleksandar.markovic@mips.com> <aleksandar.markovic@imgtec.com>
|
||||
Aleksey Gorelov <aleksey_gorelov@phoenix.com>
|
||||
Alex Williamson <alex@shazbot.org> <alex.williamson@redhat.com>
|
||||
Alexander Lobakin <alobakin@pm.me> <alobakin@dlink.ru>
|
||||
Alexander Lobakin <alobakin@pm.me> <alobakin@marvell.com>
|
||||
Alexander Lobakin <alobakin@pm.me> <bloodyreaper@yandex.ru>
|
||||
|
|
@ -173,6 +174,7 @@ Carlos Bilbao <carlos.bilbao@kernel.org> <bilbao@vt.edu>
|
|||
Changbin Du <changbin.du@intel.com> <changbin.du@gmail.com>
|
||||
Chao Yu <chao@kernel.org> <chao2.yu@samsung.com>
|
||||
Chao Yu <chao@kernel.org> <yuchao0@huawei.com>
|
||||
Chen-Yu Tsai <wens@kernel.org> <wens@csie.org>
|
||||
Chester Lin <chester62515@gmail.com> <clin@suse.com>
|
||||
Chris Chiu <chris.chiu@canonical.com> <chiu@endlessm.com>
|
||||
Chris Chiu <chris.chiu@canonical.com> <chiu@endlessos.org>
|
||||
|
|
@ -205,6 +207,7 @@ Danilo Krummrich <dakr@kernel.org> <dakr@redhat.com>
|
|||
David Brownell <david-b@pacbell.net>
|
||||
David Collins <quic_collinsd@quicinc.com> <collinsd@codeaurora.org>
|
||||
David Heidelberg <david@ixit.cz> <d.okias@gmail.com>
|
||||
David Hildenbrand <david@kernel.org> <david@redhat.com>
|
||||
David Rheinsberg <david@readahead.eu> <dh.herrmann@gmail.com>
|
||||
David Rheinsberg <david@readahead.eu> <dh.herrmann@googlemail.com>
|
||||
David Rheinsberg <david@readahead.eu> <david.rheinsberg@gmail.com>
|
||||
|
|
@ -227,6 +230,7 @@ Dmitry Safonov <0x7f454c46@gmail.com> <dima@arista.com>
|
|||
Dmitry Safonov <0x7f454c46@gmail.com> <d.safonov@partner.samsung.com>
|
||||
Dmitry Safonov <0x7f454c46@gmail.com> <dsafonov@virtuozzo.com>
|
||||
Domen Puncer <domen@coderock.org>
|
||||
Dong Aisheng <aisheng.dong@nxp.com> <b29396@freescale.com>
|
||||
Douglas Gilbert <dougg@torque.net>
|
||||
Drew Fustini <fustini@kernel.org> <drew@pdp7.com>
|
||||
<duje@dujemihanovic.xyz> <duje.mihanovic@skole.hr>
|
||||
|
|
@ -424,7 +428,7 @@ Kenneth W Chen <kenneth.w.chen@intel.com>
|
|||
Kenneth Westfield <quic_kwestfie@quicinc.com> <kwestfie@codeaurora.org>
|
||||
Kiran Gunda <quic_kgunda@quicinc.com> <kgunda@codeaurora.org>
|
||||
Kirill Tkhai <tkhai@ya.ru> <ktkhai@virtuozzo.com>
|
||||
Kirill A. Shutemov <kas@kernel.org> <kirill.shutemov@linux.intel.com>
|
||||
Kiryl Shutsemau <kas@kernel.org> <kirill.shutemov@linux.intel.com>
|
||||
Kishon Vijay Abraham I <kishon@kernel.org> <kishon@ti.com>
|
||||
Konrad Dybcio <konradybcio@kernel.org> <konrad.dybcio@linaro.org>
|
||||
Konrad Dybcio <konradybcio@kernel.org> <konrad.dybcio@somainline.org>
|
||||
|
|
@ -604,7 +608,8 @@ Oleksij Rempel <o.rempel@pengutronix.de>
|
|||
Oleksij Rempel <o.rempel@pengutronix.de> <ore@pengutronix.de>
|
||||
Oliver Hartkopp <socketcan@hartkopp.net> <oliver.hartkopp@volkswagen.de>
|
||||
Oliver Hartkopp <socketcan@hartkopp.net> <oliver@hartkopp.net>
|
||||
Oliver Upton <oliver.upton@linux.dev> <oupton@google.com>
|
||||
Oliver Upton <oupton@kernel.org> <oupton@google.com>
|
||||
Oliver Upton <oupton@kernel.org> <oliver.upton@linux.dev>
|
||||
Ondřej Jirman <megi@xff.cz> <megous@megous.com>
|
||||
Oza Pawandeep <quic_poza@quicinc.com> <poza@codeaurora.org>
|
||||
Pali Rohár <pali@kernel.org> <pali.rohar@gmail.com>
|
||||
|
|
@ -643,6 +648,7 @@ Qais Yousef <qyousef@layalina.io> <qais.yousef@arm.com>
|
|||
Quentin Monnet <qmo@kernel.org> <quentin.monnet@netronome.com>
|
||||
Quentin Monnet <qmo@kernel.org> <quentin@isovalent.com>
|
||||
Quentin Perret <qperret@qperret.net> <quentin.perret@arm.com>
|
||||
Rae Moar <raemoar63@gmail.com> <rmoar@google.com>
|
||||
Rafael J. Wysocki <rjw@rjwysocki.net> <rjw@sisk.pl>
|
||||
Rajeev Nandan <quic_rajeevny@quicinc.com> <rajeevny@codeaurora.org>
|
||||
Rajendra Nayak <quic_rjendra@quicinc.com> <rnayak@codeaurora.org>
|
||||
|
|
|
|||
4
CREDITS
4
CREDITS
|
|
@ -2036,6 +2036,10 @@ S: Botanicka' 68a
|
|||
S: 602 00 Brno
|
||||
S: Czech Republic
|
||||
|
||||
N: Karsten Keil
|
||||
E: isdn@linux-pingi.de
|
||||
D: ISDN subsystem maintainer
|
||||
|
||||
N: Jakob Kemi
|
||||
E: jakob.kemi@telia.com
|
||||
D: V4L W9966 Webcam driver
|
||||
|
|
|
|||
19
Documentation/ABI/stable/sysfs-driver-qaic
Normal file
19
Documentation/ABI/stable/sysfs-driver-qaic
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
What: /sys/bus/pci/drivers/qaic/XXXX:XX:XX.X/accel/accel<minor_nr>/dbc<N>_state
|
||||
Date: October 2025
|
||||
KernelVersion: 6.19
|
||||
Contact: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
|
||||
Description: Represents the current state of DMA Bridge channel (DBC). Below are the possible
|
||||
states:
|
||||
|
||||
=================== ==========================================================
|
||||
IDLE (0) DBC is free and can be activated
|
||||
ASSIGNED (1) DBC is activated and a workload is running on device
|
||||
BEFORE_SHUTDOWN (2) Sub-system associated with this workload has crashed and
|
||||
it will shutdown soon
|
||||
AFTER_SHUTDOWN (3) Sub-system associated with this workload has crashed and
|
||||
it has shutdown
|
||||
BEFORE_POWER_UP (4) Sub-system associated with this workload is shutdown and
|
||||
it will be powered up soon
|
||||
AFTER_POWER_UP (5) Sub-system associated with this workload is now powered up
|
||||
=================== ==========================================================
|
||||
Users: Any userspace application or clients interested in DBC state.
|
||||
|
|
@ -487,8 +487,8 @@ one user crashes, the fallout of that should be limited to that workload and not
|
|||
impact other workloads. SSR accomplishes this.
|
||||
|
||||
If a particular workload crashes, QSM notifies the host via the QAIC_SSR MHI
|
||||
channel. This notification identifies the workload by it's assigned DBC. A
|
||||
multi-stage recovery process is then used to cleanup both sides, and get the
|
||||
channel. This notification identifies the workload by its assigned DBC. A
|
||||
multi-stage recovery process is then used to cleanup both sides, and gets the
|
||||
DBC/NSPs into a working state.
|
||||
|
||||
When SSR occurs, any state in the workload is lost. Any inputs that were in
|
||||
|
|
@ -496,6 +496,27 @@ process, or queued by not yet serviced, are lost. The loaded artifacts will
|
|||
remain in on-card DDR, but the host will need to re-activate the workload if
|
||||
it desires to recover the workload.
|
||||
|
||||
When SSR occurs for a specific NSP, the assigned DBC goes through the
|
||||
following state transactions in order:
|
||||
|
||||
DBC_STATE_BEFORE_SHUTDOWN
|
||||
Indicates that the affected NSP was found in an unrecoverable error
|
||||
condition.
|
||||
DBC_STATE_AFTER_SHUTDOWN
|
||||
Indicates that the NSP is under reset.
|
||||
DBC_STATE_BEFORE_POWER_UP
|
||||
Indicates that the NSP's debug information has been collected, and is
|
||||
ready to be collected by the host (if desired). At that stage the NSP
|
||||
is restarted by QSM.
|
||||
DBC_STATE_AFTER_POWER_UP
|
||||
Indicates that the NSP has been restarted, fully operational and is
|
||||
in idle state.
|
||||
|
||||
SSR also has an optional crashdump collection feature. If enabled, the host can
|
||||
collect the memory dump for the crashed NSP and dump it to the user space via
|
||||
the dev_coredump subsystem. The host can also decline the crashdump collection
|
||||
request from the device.
|
||||
|
||||
Reliability, Accessibility, Serviceability (RAS)
|
||||
================================================
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ polling mode and reenables the IRQ line.
|
|||
This mitigation in QAIC is very effective. The same lprnet usecase that
|
||||
generates 100k IRQs per second (per /proc/interrupts) is reduced to roughly 64
|
||||
IRQs over 5 minutes while keeping the host system stable, and having the same
|
||||
workload throughput performance (within run to run noise variation).
|
||||
workload throughput performance (within run-to-run noise variation).
|
||||
|
||||
Single MSI Mode
|
||||
---------------
|
||||
|
|
@ -49,7 +49,7 @@ useful to be able to fall back to a single MSI when needed.
|
|||
To support this fallback, we allow the case where only one MSI is able to be
|
||||
allocated, and share that one MSI between MHI and the DBCs. The device detects
|
||||
when only one MSI has been configured and directs the interrupts for the DBCs
|
||||
to the interrupt normally used for MHI. Unfortunately this means that the
|
||||
to the interrupt normally used for MHI. Unfortunately, this means that the
|
||||
interrupt handlers for every DBC and MHI wake up for every interrupt that
|
||||
arrives; however, the DBC threaded irq handlers only are started when work to be
|
||||
done is detected (MHI will always start its threaded handler).
|
||||
|
|
@ -62,9 +62,9 @@ never disabled, allowing each new entry to the FIFO to trigger a new interrupt.
|
|||
Neural Network Control (NNC) Protocol
|
||||
=====================================
|
||||
|
||||
The implementation of NNC is split between the KMD (QAIC) and UMD. In general
|
||||
The implementation of NNC is split between the KMD (QAIC) and UMD. In general,
|
||||
QAIC understands how to encode/decode NNC wire protocol, and elements of the
|
||||
protocol which require kernel space knowledge to process (for example, mapping
|
||||
protocol which requires kernel space knowledge to process (for example, mapping
|
||||
host memory to device IOVAs). QAIC understands the structure of a message, and
|
||||
all of the transactions. QAIC does not understand commands (the payload of a
|
||||
passthrough transaction).
|
||||
|
|
|
|||
|
|
@ -49,6 +49,10 @@ properties:
|
|||
$ref: /schemas/graph.yaml#/properties/port
|
||||
description: HDMI output port
|
||||
|
||||
port@2:
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
description: Parallel audio input port
|
||||
|
||||
required:
|
||||
- port@0
|
||||
- port@1
|
||||
|
|
@ -98,5 +102,13 @@ examples:
|
|||
remote-endpoint = <&hdmi0_con>;
|
||||
};
|
||||
};
|
||||
|
||||
port@2 {
|
||||
reg = <2>;
|
||||
|
||||
endpoint {
|
||||
remote-endpoint = <&pai_to_hdmi_tx>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -19,6 +19,7 @@ properties:
|
|||
compatible:
|
||||
enum:
|
||||
- ite,it66121
|
||||
- ite,it66122
|
||||
- ite,it6610
|
||||
|
||||
reg:
|
||||
|
|
|
|||
|
|
@ -14,6 +14,9 @@ description: |
|
|||
R-Car Gen4 SoCs. The encoder can operate in either DSI or CSI-2 mode, with up
|
||||
to four data lanes.
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/display/dsi-controller.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
|
|
@ -80,14 +83,14 @@ required:
|
|||
- resets
|
||||
- ports
|
||||
|
||||
additionalProperties: false
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/r8a779a0-cpg-mssr.h>
|
||||
#include <dt-bindings/power/r8a779a0-sysc.h>
|
||||
|
||||
dsi0: dsi-encoder@fed80000 {
|
||||
dsi@fed80000 {
|
||||
compatible = "renesas,r8a779a0-dsi-csi2-tx";
|
||||
reg = <0xfed80000 0x10000>;
|
||||
power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>;
|
||||
|
|
@ -117,4 +120,51 @@ examples:
|
|||
};
|
||||
};
|
||||
};
|
||||
|
||||
- |
|
||||
#include <dt-bindings/clock/r8a779g0-cpg-mssr.h>
|
||||
#include <dt-bindings/power/r8a779g0-sysc.h>
|
||||
|
||||
dsi@fed80000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
compatible = "renesas,r8a779g0-dsi-csi2-tx";
|
||||
reg = <0xfed80000 0x10000>;
|
||||
clocks = <&cpg CPG_MOD 415>,
|
||||
<&cpg CPG_CORE R8A779G0_CLK_DSIEXT>,
|
||||
<&cpg CPG_CORE R8A779G0_CLK_DSIREF>;
|
||||
clock-names = "fck", "dsi", "pll";
|
||||
power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
|
||||
resets = <&cpg 415>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
|
||||
dsi0port1_out: endpoint {
|
||||
remote-endpoint = <&panel_in>;
|
||||
data-lanes = <1 2>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
panel@0 {
|
||||
reg = <0>;
|
||||
compatible = "raspberrypi,dsi-7inch", "ilitek,ili9881c";
|
||||
power-supply = <&vcc_lcd_reg>;
|
||||
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&dsi0port1_out>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
|
|
|
|||
|
|
@ -27,7 +27,9 @@ properties:
|
|||
- const: adi,adv7123
|
||||
- enum:
|
||||
- adi,adv7123
|
||||
- asl-tek,cs5263
|
||||
- dumb-vga-dac
|
||||
- parade,ps185hdm
|
||||
- radxa,ra620
|
||||
- realtek,rtd2171
|
||||
- ti,opa362
|
||||
|
|
|
|||
|
|
@ -0,0 +1,69 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/imx/fsl,imx8mp-hdmi-pai.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Freescale i.MX8MP HDMI Parallel Audio Interface
|
||||
|
||||
maintainers:
|
||||
- Shengjiu Wang <shengjiu.wang@nxp.com>
|
||||
|
||||
description:
|
||||
The HDMI TX Parallel Audio Interface (HTX_PAI) is a bridge between the
|
||||
Audio Subsystem to the HDMI TX Controller.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: fsl,imx8mp-hdmi-pai
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
clock-names:
|
||||
const: apb
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
port:
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
description: Output to the HDMI TX controller.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
- clock-names
|
||||
- power-domains
|
||||
- port
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/imx8mp-clock.h>
|
||||
#include <dt-bindings/power/imx8mp-power.h>
|
||||
|
||||
audio-bridge@32fc4800 {
|
||||
compatible = "fsl,imx8mp-hdmi-pai";
|
||||
reg = <0x32fc4800 0x800>;
|
||||
interrupt-parent = <&irqsteer_hdmi>;
|
||||
interrupts = <14>;
|
||||
clocks = <&clk IMX8MP_CLK_HDMI_APB>;
|
||||
clock-names = "apb";
|
||||
power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_PAI>;
|
||||
|
||||
port {
|
||||
pai_to_hdmi_tx: endpoint {
|
||||
remote-endpoint = <&hdmi_tx_from_pai>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -18,6 +18,7 @@ properties:
|
|||
compatible:
|
||||
oneOf:
|
||||
- enum:
|
||||
- qcom,glymur-dp
|
||||
- qcom,sa8775p-dp
|
||||
- qcom,sc7180-dp
|
||||
- qcom,sc7280-dp
|
||||
|
|
@ -31,6 +32,11 @@ properties:
|
|||
- qcom,sm8650-dp
|
||||
- qcom,x1e80100-dp
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,qcs8300-dp
|
||||
- const: qcom,sa8775p-dp
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,sm6350-dp
|
||||
|
|
@ -53,6 +59,12 @@ properties:
|
|||
- qcom,sm8550-dp
|
||||
- const: qcom,sm8350-dp
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,sm6150-dp
|
||||
- const: qcom,sm8150-dp
|
||||
- const: qcom,sm8350-dp
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,sm8750-dp
|
||||
|
|
@ -195,9 +207,11 @@ allOf:
|
|||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,glymur-dp
|
||||
- qcom,sa8775p-dp
|
||||
- qcom,x1e80100-dp
|
||||
then:
|
||||
$ref: /schemas/sound/dai-common.yaml#
|
||||
oneOf:
|
||||
- required:
|
||||
- aux-bus
|
||||
|
|
@ -239,6 +253,7 @@ allOf:
|
|||
enum:
|
||||
# these platforms support 2 streams MST on some interfaces,
|
||||
# others are SST only
|
||||
- qcom,glymur-dp
|
||||
- qcom,sc8280xp-dp
|
||||
- qcom,x1e80100-dp
|
||||
then:
|
||||
|
|
@ -295,7 +310,7 @@ allOf:
|
|||
minItems: 6
|
||||
maxItems: 8
|
||||
|
||||
additionalProperties: false
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ properties:
|
|||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- pattern: '^qcom,adreno-gmu-[67][0-9][0-9]\.[0-9]$'
|
||||
- pattern: '^qcom,adreno-gmu-[6-8][0-9][0-9]\.[0-9]$'
|
||||
- const: qcom,adreno-gmu
|
||||
- items:
|
||||
- pattern: '^qcom,adreno-gmu-x[1-9][0-9][0-9]\.[0-9]$'
|
||||
|
|
@ -299,6 +299,64 @@ allOf:
|
|||
required:
|
||||
- qcom,qmp
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: qcom,adreno-gmu-840.1
|
||||
then:
|
||||
properties:
|
||||
reg:
|
||||
items:
|
||||
- description: Core GMU registers
|
||||
reg-names:
|
||||
items:
|
||||
- const: gmu
|
||||
clocks:
|
||||
items:
|
||||
- description: GPU AHB clock
|
||||
- description: GMU clock
|
||||
- description: GPU CX clock
|
||||
- description: GPU MEMNOC clock
|
||||
- description: GMU HUB clock
|
||||
clock-names:
|
||||
items:
|
||||
- const: ahb
|
||||
- const: gmu
|
||||
- const: cxo
|
||||
- const: memnoc
|
||||
- const: hub
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: qcom,adreno-gmu-x285.1
|
||||
then:
|
||||
properties:
|
||||
reg:
|
||||
items:
|
||||
- description: Core GMU registers
|
||||
reg-names:
|
||||
items:
|
||||
- const: gmu
|
||||
clocks:
|
||||
items:
|
||||
- description: GPU AHB clock
|
||||
- description: GMU clock
|
||||
- description: GPU CX clock
|
||||
- description: GPU MEMNOC clock
|
||||
- description: GMU HUB clock
|
||||
- description: GMU RSCC HUB clock
|
||||
clock-names:
|
||||
items:
|
||||
- const: ahb
|
||||
- const: gmu
|
||||
- const: cxo
|
||||
- const: memnoc
|
||||
- const: hub
|
||||
- const: rscc
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,264 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/msm/qcom,glymur-mdss.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Glymur Display MDSS
|
||||
|
||||
maintainers:
|
||||
- Abel Vesa <abel.vesa@linaro.org>
|
||||
|
||||
description:
|
||||
Glymur MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like
|
||||
DPU display controller, DP interfaces, etc.
|
||||
|
||||
$ref: /schemas/display/msm/mdss-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,glymur-mdss
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Display AHB
|
||||
- description: Display hf AXI
|
||||
- description: Display core
|
||||
|
||||
iommus:
|
||||
maxItems: 1
|
||||
|
||||
interconnects:
|
||||
items:
|
||||
- description: Interconnect path from mdp0 port to the data bus
|
||||
- description: Interconnect path from CPU to the reg bus
|
||||
|
||||
interconnect-names:
|
||||
items:
|
||||
- const: mdp0-mem
|
||||
- const: cpu-cfg
|
||||
|
||||
patternProperties:
|
||||
"^display-controller@[0-9a-f]+$":
|
||||
type: object
|
||||
additionalProperties: true
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,glymur-dpu
|
||||
|
||||
"^displayport-controller@[0-9a-f]+$":
|
||||
type: object
|
||||
additionalProperties: true
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,glymur-dp
|
||||
|
||||
"^phy@[0-9a-f]+$":
|
||||
type: object
|
||||
additionalProperties: true
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,glymur-dp-phy
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
#include <dt-bindings/interconnect/qcom,icc.h>
|
||||
#include <dt-bindings/interconnect/qcom,glymur-rpmh.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/phy/phy-qcom-qmp.h>
|
||||
#include <dt-bindings/power/qcom,rpmhpd.h>
|
||||
|
||||
display-subsystem@ae00000 {
|
||||
compatible = "qcom,glymur-mdss";
|
||||
reg = <0x0ae00000 0x1000>;
|
||||
reg-names = "mdss";
|
||||
|
||||
interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
|
||||
|
||||
clocks = <&dispcc_ahb_clk>,
|
||||
<&gcc_disp_hf_axi_clk>,
|
||||
<&dispcc_mdp_clk>;
|
||||
clock-names = "bus", "nrt_bus", "core";
|
||||
|
||||
interconnects = <&mmss_noc MASTER_MDP QCOM_ICC_TAG_ALWAYS
|
||||
&mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
|
||||
<&hsc_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
|
||||
&config_noc SLAVE_DISPLAY_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
|
||||
interconnect-names = "mdp0-mem",
|
||||
"cpu-cfg";
|
||||
|
||||
resets = <&disp_cc_mdss_core_bcr>;
|
||||
|
||||
power-domains = <&mdss_gdsc>;
|
||||
|
||||
iommus = <&apps_smmu 0x1c00 0x2>;
|
||||
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges;
|
||||
|
||||
display-controller@ae01000 {
|
||||
compatible = "qcom,glymur-dpu";
|
||||
reg = <0x0ae01000 0x8f000>,
|
||||
<0x0aeb0000 0x2008>;
|
||||
reg-names = "mdp", "vbif";
|
||||
|
||||
clocks = <&gcc_axi_clk>,
|
||||
<&dispcc_ahb_clk>,
|
||||
<&dispcc_mdp_lut_clk>,
|
||||
<&dispcc_mdp_clk>,
|
||||
<&dispcc_mdp_vsync_clk>;
|
||||
clock-names = "nrt_bus",
|
||||
"iface",
|
||||
"lut",
|
||||
"core",
|
||||
"vsync";
|
||||
|
||||
assigned-clocks = <&dispcc_mdp_vsync_clk>;
|
||||
assigned-clock-rates = <19200000>;
|
||||
|
||||
operating-points-v2 = <&mdp_opp_table>;
|
||||
power-domains = <&rpmhpd RPMHPD_MMCX>;
|
||||
|
||||
interrupt-parent = <&mdss>;
|
||||
interrupts = <0>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
dpu_intf1_out: endpoint {
|
||||
remote-endpoint = <&dsi0_in>;
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
dpu_intf2_out: endpoint {
|
||||
remote-endpoint = <&dsi1_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
mdp_opp_table: opp-table {
|
||||
compatible = "operating-points-v2";
|
||||
|
||||
opp-200000000 {
|
||||
opp-hz = /bits/ 64 <200000000>;
|
||||
required-opps = <&rpmhpd_opp_low_svs>;
|
||||
};
|
||||
|
||||
opp-325000000 {
|
||||
opp-hz = /bits/ 64 <325000000>;
|
||||
required-opps = <&rpmhpd_opp_svs>;
|
||||
};
|
||||
|
||||
opp-375000000 {
|
||||
opp-hz = /bits/ 64 <375000000>;
|
||||
required-opps = <&rpmhpd_opp_svs_l1>;
|
||||
};
|
||||
|
||||
opp-514000000 {
|
||||
opp-hz = /bits/ 64 <514000000>;
|
||||
required-opps = <&rpmhpd_opp_nom>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
displayport-controller@ae90000 {
|
||||
compatible = "qcom,glymur-dp";
|
||||
reg = <0xae90000 0x200>,
|
||||
<0xae90200 0x200>,
|
||||
<0xae90400 0x600>,
|
||||
<0xae91000 0x400>,
|
||||
<0xae91400 0x400>;
|
||||
|
||||
interrupt-parent = <&mdss>;
|
||||
interrupts = <12>;
|
||||
|
||||
clocks = <&dispcc_mdss_ahb_clk>,
|
||||
<&dispcc_dptx0_aux_clk>,
|
||||
<&dispcc_dptx0_link_clk>,
|
||||
<&dispcc_dptx0_link_intf_clk>,
|
||||
<&dispcc_dptx0_pixel0_clk>,
|
||||
<&dispcc_dptx0_pixel1_clk>;
|
||||
clock-names = "core_iface",
|
||||
"core_aux",
|
||||
"ctrl_link",
|
||||
"ctrl_link_iface",
|
||||
"stream_pixel",
|
||||
"stream_1_pixel";
|
||||
|
||||
assigned-clocks = <&dispcc_mdss_dptx0_link_clk_src>,
|
||||
<&dispcc_mdss_dptx0_pixel0_clk_src>,
|
||||
<&dispcc_mdss_dptx0_pixel1_clk_src>;
|
||||
assigned-clock-parents = <&usb_1_ss0_qmpphy QMP_USB43DP_DP_LINK_CLK>,
|
||||
<&usb_1_ss0_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>,
|
||||
<&usb_1_ss0_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>;
|
||||
|
||||
operating-points-v2 = <&mdss_dp0_opp_table>;
|
||||
|
||||
power-domains = <&rpmhpd RPMHPD_MMCX>;
|
||||
|
||||
phys = <&usb_1_ss0_qmpphy QMP_USB43DP_DP_PHY>;
|
||||
phy-names = "dp";
|
||||
|
||||
#sound-dai-cells = <0>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
|
||||
mdss_dp0_in: endpoint {
|
||||
remote-endpoint = <&mdss_intf0_out>;
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
|
||||
mdss_dp0_out: endpoint {
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
mdss_dp0_opp_table: opp-table {
|
||||
compatible = "operating-points-v2";
|
||||
|
||||
opp-160000000 {
|
||||
opp-hz = /bits/ 64 <160000000>;
|
||||
required-opps = <&rpmhpd_opp_low_svs>;
|
||||
};
|
||||
|
||||
opp-270000000 {
|
||||
opp-hz = /bits/ 64 <270000000>;
|
||||
required-opps = <&rpmhpd_opp_svs>;
|
||||
};
|
||||
|
||||
opp-540000000 {
|
||||
opp-hz = /bits/ 64 <540000000>;
|
||||
required-opps = <&rpmhpd_opp_svs_l1>;
|
||||
};
|
||||
|
||||
opp-810000000 {
|
||||
opp-hz = /bits/ 64 <810000000>;
|
||||
required-opps = <&rpmhpd_opp_nom>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
|
|
@ -0,0 +1,286 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/msm/qcom,qcs8300-mdss.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Technologies, Inc. QCS8300 Display MDSS
|
||||
|
||||
maintainers:
|
||||
- Yongxing Mou <yongxing.mou@oss.qualcomm.com>
|
||||
|
||||
description:
|
||||
QCS8300 MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like
|
||||
DPU display controller, DP interfaces and EDP etc.
|
||||
|
||||
$ref: /schemas/display/msm/mdss-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,qcs8300-mdss
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Display AHB
|
||||
- description: Display hf AXI
|
||||
- description: Display core
|
||||
|
||||
iommus:
|
||||
maxItems: 1
|
||||
|
||||
interconnects:
|
||||
maxItems: 3
|
||||
|
||||
interconnect-names:
|
||||
maxItems: 3
|
||||
|
||||
patternProperties:
|
||||
"^display-controller@[0-9a-f]+$":
|
||||
type: object
|
||||
additionalProperties: true
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: qcom,qcs8300-dpu
|
||||
|
||||
"^displayport-controller@[0-9a-f]+$":
|
||||
type: object
|
||||
additionalProperties: true
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: qcom,qcs8300-dp
|
||||
|
||||
"^phy@[0-9a-f]+$":
|
||||
type: object
|
||||
additionalProperties: true
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: qcom,qcs8300-edp-phy
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interconnect/qcom,icc.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/clock/qcom,qcs8300-gcc.h>
|
||||
#include <dt-bindings/clock/qcom,sa8775p-dispcc.h>
|
||||
#include <dt-bindings/interconnect/qcom,qcs8300-rpmh.h>
|
||||
#include <dt-bindings/power/qcom,rpmhpd.h>
|
||||
#include <dt-bindings/power/qcom-rpmpd.h>
|
||||
|
||||
mdss: display-subsystem@ae00000 {
|
||||
compatible = "qcom,qcs8300-mdss";
|
||||
reg = <0x0ae00000 0x1000>;
|
||||
reg-names = "mdss";
|
||||
|
||||
interconnects = <&mmss_noc MASTER_MDP0 QCOM_ICC_TAG_ACTIVE_ONLY
|
||||
&mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
|
||||
<&mmss_noc MASTER_MDP1 QCOM_ICC_TAG_ACTIVE_ONLY
|
||||
&mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
|
||||
<&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
|
||||
&config_noc SLAVE_DISPLAY_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
|
||||
interconnect-names = "mdp0-mem",
|
||||
"mdp1-mem",
|
||||
"cpu-cfg";
|
||||
|
||||
resets = <&dispcc_core_bcr>;
|
||||
power-domains = <&dispcc_gdsc>;
|
||||
|
||||
clocks = <&dispcc_ahb_clk>,
|
||||
<&gcc GCC_DISP_HF_AXI_CLK>,
|
||||
<&dispcc_mdp_clk>;
|
||||
|
||||
interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
iommus = <&apps_smmu 0x1000 0x402>;
|
||||
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges;
|
||||
|
||||
display-controller@ae01000 {
|
||||
compatible = "qcom,qcs8300-dpu", "qcom,sa8775p-dpu";
|
||||
reg = <0x0ae01000 0x8f000>,
|
||||
<0x0aeb0000 0x2008>;
|
||||
reg-names = "mdp", "vbif";
|
||||
|
||||
clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
|
||||
<&dispcc0 MDSS_DISP_CC_MDSS_AHB_CLK>,
|
||||
<&dispcc0 MDSS_DISP_CC_MDSS_MDP_LUT_CLK>,
|
||||
<&dispcc0 MDSS_DISP_CC_MDSS_MDP_CLK>,
|
||||
<&dispcc0 MDSS_DISP_CC_MDSS_VSYNC_CLK>;
|
||||
clock-names = "nrt_bus",
|
||||
"iface",
|
||||
"lut",
|
||||
"core",
|
||||
"vsync";
|
||||
|
||||
assigned-clocks = <&dispcc0 MDSS_DISP_CC_MDSS_VSYNC_CLK>;
|
||||
assigned-clock-rates = <19200000>;
|
||||
operating-points-v2 = <&mdp_opp_table>;
|
||||
power-domains = <&rpmhpd RPMHPD_MMCX>;
|
||||
|
||||
interrupt-parent = <&mdss>;
|
||||
interrupts = <0>;
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
|
||||
dpu_intf0_out: endpoint {
|
||||
remote-endpoint = <&mdss_dp0_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
mdp_opp_table: opp-table {
|
||||
compatible = "operating-points-v2";
|
||||
|
||||
opp-375000000 {
|
||||
opp-hz = /bits/ 64 <375000000>;
|
||||
required-opps = <&rpmhpd_opp_svs_l1>;
|
||||
};
|
||||
|
||||
opp-500000000 {
|
||||
opp-hz = /bits/ 64 <500000000>;
|
||||
required-opps = <&rpmhpd_opp_nom>;
|
||||
};
|
||||
|
||||
opp-575000000 {
|
||||
opp-hz = /bits/ 64 <575000000>;
|
||||
required-opps = <&rpmhpd_opp_turbo>;
|
||||
};
|
||||
|
||||
opp-650000000 {
|
||||
opp-hz = /bits/ 64 <650000000>;
|
||||
required-opps = <&rpmhpd_opp_turbo_l1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
mdss_dp0_phy: phy@aec2a00 {
|
||||
compatible = "qcom,qcs8300-edp-phy", "qcom,sa8775p-edp-phy";
|
||||
|
||||
reg = <0x0aec2a00 0x200>,
|
||||
<0x0aec2200 0xd0>,
|
||||
<0x0aec2600 0xd0>,
|
||||
<0x0aec2000 0x1c8>;
|
||||
|
||||
clocks = <&dispcc MDSS_DISP_CC_MDSS_DPTX0_AUX_CLK>,
|
||||
<&dispcc MDSS_DISP_CC_MDSS_AHB_CLK>;
|
||||
clock-names = "aux",
|
||||
"cfg_ahb";
|
||||
|
||||
#clock-cells = <1>;
|
||||
#phy-cells = <0>;
|
||||
|
||||
vdda-phy-supply = <&vreg_l1c>;
|
||||
vdda-pll-supply = <&vreg_l4a>;
|
||||
};
|
||||
|
||||
displayport-controller@af54000 {
|
||||
compatible = "qcom,qcs8300-dp", "qcom,sa8775p-dp";
|
||||
|
||||
pinctrl-0 = <&dp_hot_plug_det>;
|
||||
pinctrl-names = "default";
|
||||
|
||||
reg = <0xaf54000 0x104>,
|
||||
<0xaf54200 0x0c0>,
|
||||
<0xaf55000 0x770>,
|
||||
<0xaf56000 0x09c>,
|
||||
<0xaf57000 0x09c>,
|
||||
<0xaf58000 0x09c>,
|
||||
<0xaf59000 0x09c>,
|
||||
<0xaf5a000 0x23c>,
|
||||
<0xaf5b000 0x23c>;
|
||||
|
||||
interrupt-parent = <&mdss>;
|
||||
interrupts = <12>;
|
||||
clocks = <&dispcc0 MDSS_DISP_CC_MDSS_AHB_CLK>,
|
||||
<&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_AUX_CLK>,
|
||||
<&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_LINK_CLK>,
|
||||
<&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_LINK_INTF_CLK>,
|
||||
<&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL0_CLK>,
|
||||
<&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL1_CLK>,
|
||||
<&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL2_CLK>,
|
||||
<&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL3_CLK>;
|
||||
clock-names = "core_iface",
|
||||
"core_aux",
|
||||
"ctrl_link",
|
||||
"ctrl_link_iface",
|
||||
"stream_pixel",
|
||||
"stream_1_pixel",
|
||||
"stream_2_pixel",
|
||||
"stream_3_pixel";
|
||||
assigned-clocks = <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_LINK_CLK_SRC>,
|
||||
<&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL0_CLK_SRC>,
|
||||
<&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL1_CLK_SRC>,
|
||||
<&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL2_CLK_SRC>,
|
||||
<&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL3_CLK_SRC>;
|
||||
assigned-clock-parents = <&mdss_dp0_phy 0>,
|
||||
<&mdss_dp0_phy 1>,
|
||||
<&mdss_dp0_phy 1>,
|
||||
<&mdss_dp0_phy 1>;
|
||||
phys = <&mdss_dp0_phy>;
|
||||
phy-names = "dp";
|
||||
operating-points-v2 = <&dp_opp_table>;
|
||||
power-domains = <&rpmhpd RPMHPD_MMCX>;
|
||||
|
||||
#sound-dai-cells = <0>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
|
||||
mdss_dp0_in: endpoint {
|
||||
remote-endpoint = <&dpu_intf0_out>;
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
|
||||
mdss_dp_out: endpoint { };
|
||||
};
|
||||
};
|
||||
|
||||
dp_opp_table: opp-table {
|
||||
compatible = "operating-points-v2";
|
||||
|
||||
opp-160000000 {
|
||||
opp-hz = /bits/ 64 <160000000>;
|
||||
required-opps = <&rpmhpd_opp_low_svs>;
|
||||
};
|
||||
|
||||
opp-270000000 {
|
||||
opp-hz = /bits/ 64 <270000000>;
|
||||
required-opps = <&rpmhpd_opp_svs>;
|
||||
};
|
||||
|
||||
opp-540000000 {
|
||||
opp-hz = /bits/ 64 <540000000>;
|
||||
required-opps = <&rpmhpd_opp_svs_l1>;
|
||||
};
|
||||
|
||||
opp-810000000 {
|
||||
opp-hz = /bits/ 64 <810000000>;
|
||||
required-opps = <&rpmhpd_opp_nom>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
|
|
@ -51,6 +51,14 @@ patternProperties:
|
|||
compatible:
|
||||
const: qcom,sm6150-dpu
|
||||
|
||||
"^displayport-controller@[0-9a-f]+$":
|
||||
type: object
|
||||
additionalProperties: true
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: qcom,sm6150-dp
|
||||
|
||||
"^dsi@[0-9a-f]+$":
|
||||
type: object
|
||||
additionalProperties: true
|
||||
|
|
@ -130,35 +138,37 @@ examples:
|
|||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
dpu_intf0_out: endpoint {
|
||||
};
|
||||
reg = <0>;
|
||||
|
||||
dpu_intf0_out: endpoint {
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
dpu_intf1_out: endpoint {
|
||||
remote-endpoint = <&mdss_dsi0_in>;
|
||||
};
|
||||
reg = <1>;
|
||||
|
||||
dpu_intf1_out: endpoint {
|
||||
remote-endpoint = <&mdss_dsi0_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
mdp_opp_table: opp-table {
|
||||
compatible = "operating-points-v2";
|
||||
|
||||
opp-19200000 {
|
||||
opp-hz = /bits/ 64 <19200000>;
|
||||
required-opps = <&rpmhpd_opp_low_svs>;
|
||||
opp-192000000 {
|
||||
opp-hz = /bits/ 64 <192000000>;
|
||||
required-opps = <&rpmhpd_opp_low_svs>;
|
||||
};
|
||||
|
||||
opp-25600000 {
|
||||
opp-hz = /bits/ 64 <25600000>;
|
||||
required-opps = <&rpmhpd_opp_svs>;
|
||||
opp-256000000 {
|
||||
opp-hz = /bits/ 64 <256000000>;
|
||||
required-opps = <&rpmhpd_opp_svs>;
|
||||
};
|
||||
|
||||
opp-307200000 {
|
||||
opp-hz = /bits/ 64 <307200000>;
|
||||
required-opps = <&rpmhpd_opp_nom>;
|
||||
opp-hz = /bits/ 64 <307200000>;
|
||||
required-opps = <&rpmhpd_opp_nom>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -13,11 +13,17 @@ $ref: /schemas/display/msm/dpu-common.yaml#
|
|||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,sa8775p-dpu
|
||||
- qcom,sm8650-dpu
|
||||
- qcom,sm8750-dpu
|
||||
- qcom,x1e80100-dpu
|
||||
oneOf:
|
||||
- enum:
|
||||
- qcom,glymur-dpu
|
||||
- qcom,sa8775p-dpu
|
||||
- qcom,sm8650-dpu
|
||||
- qcom,sm8750-dpu
|
||||
- qcom,x1e80100-dpu
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,qcs8300-dpu
|
||||
- const: qcom,sa8775p-dpu
|
||||
|
||||
reg:
|
||||
items:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,68 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/ilitek,il79900a.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Ilitek IL79900a based MIPI-DSI panels
|
||||
|
||||
maintainers:
|
||||
- Langyan Ye <yelangyan@huaqin.corp-partner.google.com>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- tianma,tl121bvms07-00
|
||||
- const: ilitek,il79900a
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
description: DSI virtual channel used by the panel
|
||||
|
||||
enable-gpios:
|
||||
maxItems: 1
|
||||
description: GPIO specifier for the enable pin
|
||||
|
||||
avdd-supply:
|
||||
description: Positive analog voltage supply (AVDD)
|
||||
|
||||
avee-supply:
|
||||
description: Negative analog voltage supply (AVEE)
|
||||
|
||||
pp1800-supply:
|
||||
description: 1.8V logic voltage supply
|
||||
|
||||
backlight: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- enable-gpios
|
||||
- avdd-supply
|
||||
- avee-supply
|
||||
- pp1800-supply
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
dsi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
panel@0 {
|
||||
compatible = "tianma,tl121bvms07-00", "ilitek,il79900a";
|
||||
reg = <0>;
|
||||
enable-gpios = <&pio 25 0>;
|
||||
avdd-supply = <®_avdd>;
|
||||
avee-supply = <®_avee>;
|
||||
pp1800-supply = <®_pp1800>;
|
||||
backlight = <&backlight>;
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -20,9 +20,11 @@ properties:
|
|||
- bananapi,lhr050h41
|
||||
- bestar,bsd1218-a101kl68
|
||||
- feixin,k101-im2byl02
|
||||
- raspberrypi,dsi-5inch
|
||||
- raspberrypi,dsi-7inch
|
||||
- startek,kd050hdfia020
|
||||
- tdo,tl050hdv35
|
||||
- wanchanglong,w552946aaa
|
||||
- wanchanglong,w552946aba
|
||||
- const: ilitek,ili9881c
|
||||
|
||||
|
|
@ -30,6 +32,7 @@ properties:
|
|||
maxItems: 1
|
||||
|
||||
backlight: true
|
||||
port: true
|
||||
power-supply: true
|
||||
reset-gpios: true
|
||||
rotation: true
|
||||
|
|
|
|||
|
|
@ -0,0 +1,60 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/lg,ld070wx3-sl01.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: LG Corporation 7" WXGA TFT LCD panel
|
||||
|
||||
maintainers:
|
||||
- Svyatoslav Ryhel <clamor95@gmail.com>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: lg,ld070wx3-sl01
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
vdd-supply: true
|
||||
vcc-supply: true
|
||||
|
||||
backlight: true
|
||||
port: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- vdd-supply
|
||||
- vcc-supply
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
dsi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
panel@0 {
|
||||
compatible = "lg,ld070wx3-sl01";
|
||||
reg = <0>;
|
||||
|
||||
vdd-supply = <&vdd_3v3_lcd>;
|
||||
vcc-supply = <&vcc_1v8_lcd>;
|
||||
|
||||
backlight = <&backlight>;
|
||||
|
||||
port {
|
||||
endpoint {
|
||||
remote-endpoint = <&dsi0_out>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
|
|
@ -59,6 +59,8 @@ properties:
|
|||
# Jenson Display BL-JT60050-01A 7" WSVGA (1024x600) color TFT LCD LVDS panel
|
||||
- jenson,bl-jt60050-01a
|
||||
- tbs,a711-panel
|
||||
# Winstar WF70A8SYJHLNGA 7" WSVGA (1024x600) color TFT LCD LVDS panel
|
||||
- winstar,wf70a8syjhlnga
|
||||
|
||||
- const: panel-lvds
|
||||
|
||||
|
|
|
|||
|
|
@ -19,6 +19,9 @@ description: |
|
|||
|
||||
If the panel is more advanced a dedicated binding file is required.
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
|
||||
compatible:
|
||||
|
|
@ -42,8 +45,6 @@ properties:
|
|||
- kingdisplay,kd097d04
|
||||
# LG ACX467AKM-7 4.95" 1080×1920 LCD Panel
|
||||
- lg,acx467akm-7
|
||||
# LG Corporation 7" WXGA TFT LCD panel
|
||||
- lg,ld070wx3-sl01
|
||||
# LG Corporation 5" HD TFT LCD panel
|
||||
- lg,lh500wx1-sd03
|
||||
# Lincoln LCD197 5" 1080x1920 LCD panel
|
||||
|
|
@ -56,10 +57,6 @@ properties:
|
|||
- panasonic,vvx10f034n00
|
||||
# Samsung s6e3fa7 1080x2220 based AMS559NK06 AMOLED panel
|
||||
- samsung,s6e3fa7-ams559nk06
|
||||
# Samsung s6e3fc2x01 1080x2340 AMOLED panel
|
||||
- samsung,s6e3fc2x01
|
||||
# Samsung sofef00 1080x2280 AMOLED panel
|
||||
- samsung,sofef00
|
||||
# Shangai Top Display Optoelectronics 7" TL070WSH30 1024x600 TFT LCD panel
|
||||
- tdo,tl070wsh30
|
||||
|
||||
|
|
@ -72,31 +69,12 @@ properties:
|
|||
reset-gpios: true
|
||||
port: true
|
||||
power-supply: true
|
||||
vddio-supply: true
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- samsung,s6e3fc2x01
|
||||
- samsung,sofef00
|
||||
then:
|
||||
properties:
|
||||
power-supply: false
|
||||
required:
|
||||
- vddio-supply
|
||||
else:
|
||||
properties:
|
||||
vddio-supply: false
|
||||
required:
|
||||
- power-supply
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- power-supply
|
||||
- reg
|
||||
|
||||
examples:
|
||||
|
|
|
|||
|
|
@ -184,6 +184,8 @@ properties:
|
|||
- innolux,n156bge-l21
|
||||
# Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel
|
||||
- innolux,zj070na-01p
|
||||
# JuTouch Technology Co.. 10" JT101TM023 WXGA (1280 x 800) LVDS panel
|
||||
- jutouch,jt101tm023
|
||||
# Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
|
||||
- koe,tx14d24vm1bpa
|
||||
# Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel
|
||||
|
|
@ -268,6 +270,8 @@ properties:
|
|||
- qiaodian,qd43003c0-40
|
||||
# Shenzhen QiShenglong Industrialist Co., Ltd. Gopher 2b 4.3" 480(RGB)x272 TFT LCD panel
|
||||
- qishenglong,gopher2b-lcd
|
||||
# Raystar Optronics, Inc. RFF500F-AWH-DNN 5.0" TFT 840x480
|
||||
- raystar,rff500f-awh-dnn
|
||||
# Rocktech Displays Ltd. RK101II01D-CT 10.1" TFT 1280x800
|
||||
- rocktech,rk101ii01d-ct
|
||||
# Rocktech Display Ltd. RK070ER9427 800(RGB)x480 TFT LCD panel
|
||||
|
|
@ -276,6 +280,8 @@ properties:
|
|||
- rocktech,rk043fn48h
|
||||
# Samsung Electronics 10.1" WXGA (1280x800) TFT LCD panel
|
||||
- samsung,ltl101al01
|
||||
# Samsung Electronics 10.6" FWXGA (1366x768) TFT LCD panel
|
||||
- samsung,ltl106al01
|
||||
# Samsung Electronics 10.1" WSVGA TFT LCD panel
|
||||
- samsung,ltn101nt05
|
||||
# Satoz SAT050AT40H12R2 5.0" WVGA TFT LCD panel
|
||||
|
|
|
|||
|
|
@ -9,6 +9,9 @@ title: Ronbo RB070D30 DSI Display Panel
|
|||
maintainers:
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: ronbo,rb070d30
|
||||
|
|
@ -20,10 +23,6 @@ properties:
|
|||
description: GPIO used for the power pin
|
||||
maxItems: 1
|
||||
|
||||
reset-gpios:
|
||||
description: GPIO used for the reset pin
|
||||
maxItems: 1
|
||||
|
||||
shlr-gpios:
|
||||
description: GPIO used for the shlr pin (horizontal flip)
|
||||
maxItems: 1
|
||||
|
|
@ -35,10 +34,6 @@ properties:
|
|||
vcc-lcd-supply:
|
||||
description: Power regulator
|
||||
|
||||
backlight:
|
||||
description: Backlight used by the panel
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- power-gpios
|
||||
|
|
@ -47,5 +42,6 @@ required:
|
|||
- shlr-gpios
|
||||
- updn-gpios
|
||||
- vcc-lcd-supply
|
||||
- port
|
||||
|
||||
additionalProperties: false
|
||||
unevaluatedProperties: false
|
||||
|
|
|
|||
|
|
@ -33,6 +33,8 @@ properties:
|
|||
- samsung,atna45dc02
|
||||
# Samsung 15.6" 3K (2880x1620 pixels) eDP AMOLED panel
|
||||
- samsung,atna56ac03
|
||||
# Samsung 16.0" 3K (2880x1800 pixels) eDP AMOLED panel
|
||||
- samsung,atna60cl08
|
||||
- const: samsung,atna33xc20
|
||||
|
||||
enable-gpios: true
|
||||
|
|
|
|||
|
|
@ -0,0 +1,81 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/samsung,s6e3fc2x01.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Samsung S6E3FC2X01 AMOLED DDIC
|
||||
|
||||
description: The S6E3FC2X01 is display driver IC with connected panel.
|
||||
|
||||
maintainers:
|
||||
- David Heidelberg <david@ixit.cz>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
# Samsung 6.41 inch, 1080x2340 pixels, 19.5:9 ratio
|
||||
- samsung,s6e3fc2x01-ams641rw
|
||||
- const: samsung,s6e3fc2x01
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
reset-gpios: true
|
||||
|
||||
port: true
|
||||
|
||||
vddio-supply:
|
||||
description: VDD regulator
|
||||
|
||||
vci-supply:
|
||||
description: VCI regulator
|
||||
|
||||
poc-supply:
|
||||
description: POC regulator
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reset-gpios
|
||||
- vddio-supply
|
||||
- vci-supply
|
||||
- poc-supply
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
dsi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
panel@0 {
|
||||
compatible = "samsung,s6e3fc2x01-ams641rw", "samsung,s6e3fc2x01";
|
||||
reg = <0>;
|
||||
|
||||
vddio-supply = <&vreg_l14a_1p88>;
|
||||
vci-supply = <&s2dos05_buck1>;
|
||||
poc-supply = <&s2dos05_ldo1>;
|
||||
|
||||
te-gpios = <&tlmm 10 GPIO_ACTIVE_HIGH>;
|
||||
reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>;
|
||||
|
||||
pinctrl-0 = <&sde_dsi_active &sde_te_active_sleep>;
|
||||
pinctrl-1 = <&sde_dsi_suspend &sde_te_active_sleep>;
|
||||
pinctrl-names = "default", "sleep";
|
||||
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&mdss_dsi0_out>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -0,0 +1,79 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/samsung,sofef00.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Samsung SOFEF00 AMOLED DDIC
|
||||
|
||||
description: The SOFEF00 is display driver IC with connected panel.
|
||||
|
||||
maintainers:
|
||||
- David Heidelberg <david@ixit.cz>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
# Samsung 6.01 inch, 1080x2160 pixels, 18:9 ratio
|
||||
- samsung,sofef00-ams601nt22
|
||||
# Samsung 6.28 inch, 1080x2280 pixels, 19:9 ratio
|
||||
- samsung,sofef00-ams628nw01
|
||||
- const: samsung,sofef00
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
poc-supply:
|
||||
description: POC regulator
|
||||
|
||||
vci-supply:
|
||||
description: VCI regulator
|
||||
|
||||
vddio-supply:
|
||||
description: VDD regulator
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reset-gpios
|
||||
- poc-supply
|
||||
- vci-supply
|
||||
- vddio-supply
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
dsi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
panel@0 {
|
||||
compatible = "samsung,sofef00-ams628nw01", "samsung,sofef00";
|
||||
reg = <0>;
|
||||
|
||||
vddio-supply = <&vreg_l14a_1p88>;
|
||||
vci-supply = <&s2dos05_buck1>;
|
||||
poc-supply = <&s2dos05_ldo1>;
|
||||
|
||||
te-gpios = <&tlmm 10 GPIO_ACTIVE_HIGH>;
|
||||
reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>;
|
||||
|
||||
pinctrl-0 = <&panel_active>;
|
||||
pinctrl-1 = <&panel_suspend>;
|
||||
pinctrl-names = "default", "sleep";
|
||||
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&mdss_dsi0_out>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -0,0 +1,99 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/sharp,lq079l1sx01.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Sharp Microelectronics 7.9" WQXGA TFT LCD panel
|
||||
|
||||
maintainers:
|
||||
- Svyatoslav Ryhel <clamor95@gmail.com>
|
||||
|
||||
description: >
|
||||
This panel requires a dual-channel DSI host to operate and it supports
|
||||
only left-right split mode, where each channel drives the left or right
|
||||
half of the screen and only video mode.
|
||||
|
||||
Each of the DSI channels controls a separate DSI peripheral.
|
||||
The peripheral driven by the first link (DSI-LINK1), left one, is
|
||||
considered the primary peripheral and controls the device.
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common-dual.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: sharp,lq079l1sx01
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
avdd-supply:
|
||||
description: regulator that supplies the analog voltage
|
||||
|
||||
vddio-supply:
|
||||
description: regulator that supplies the I/O voltage
|
||||
|
||||
vsp-supply:
|
||||
description: positive boost supply regulator
|
||||
|
||||
vsn-supply:
|
||||
description: negative boost supply regulator
|
||||
|
||||
reset-gpios:
|
||||
maxItems: 1
|
||||
|
||||
backlight: true
|
||||
ports: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- avdd-supply
|
||||
- vddio-supply
|
||||
- ports
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
dsi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
panel@0 {
|
||||
compatible = "sharp,lq079l1sx01";
|
||||
reg = <0>;
|
||||
|
||||
reset-gpios = <&gpio 59 GPIO_ACTIVE_LOW>;
|
||||
|
||||
avdd-supply = <&avdd_lcd>;
|
||||
vddio-supply = <&vdd_lcd_io>;
|
||||
vsp-supply = <&vsp_5v5_lcd>;
|
||||
vsn-supply = <&vsn_5v5_lcd>;
|
||||
|
||||
backlight = <&backlight>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
panel_in0: endpoint {
|
||||
remote-endpoint = <&dsi0_out>;
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
panel_in1: endpoint {
|
||||
remote-endpoint = <&dsi1_out>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
|
|
@ -0,0 +1,89 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/synaptics,td4300-panel.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Synaptics TDDI Display Panel Controller
|
||||
|
||||
maintainers:
|
||||
- Kaustabh Chakraborty <kauschluss@disroot.org>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- syna,td4101-panel
|
||||
- syna,td4300-panel
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
vio-supply:
|
||||
description: core I/O voltage supply
|
||||
|
||||
vsn-supply:
|
||||
description: negative voltage supply for analog circuits
|
||||
|
||||
vsp-supply:
|
||||
description: positive voltage supply for analog circuits
|
||||
|
||||
backlight-gpios:
|
||||
maxItems: 1
|
||||
description: backlight enable GPIO
|
||||
|
||||
reset-gpios: true
|
||||
width-mm: true
|
||||
height-mm: true
|
||||
panel-timing: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- width-mm
|
||||
- height-mm
|
||||
- panel-timing
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
dsi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
panel@0 {
|
||||
compatible = "syna,td4300-panel";
|
||||
reg = <0>;
|
||||
|
||||
vio-supply = <&panel_vio_reg>;
|
||||
vsn-supply = <&panel_vsn_reg>;
|
||||
vsp-supply = <&panel_vsp_reg>;
|
||||
|
||||
backlight-gpios = <&gpd3 5 GPIO_ACTIVE_LOW>;
|
||||
reset-gpios = <&gpd3 4 GPIO_ACTIVE_LOW>;
|
||||
|
||||
width-mm = <68>;
|
||||
height-mm = <121>;
|
||||
|
||||
panel-timing {
|
||||
clock-frequency = <144389520>;
|
||||
|
||||
hactive = <1080>;
|
||||
hsync-len = <4>;
|
||||
hfront-porch = <120>;
|
||||
hback-porch = <32>;
|
||||
|
||||
vactive = <1920>;
|
||||
vsync-len = <2>;
|
||||
vfront-porch = <21>;
|
||||
vback-porch = <4>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -25,6 +25,9 @@ properties:
|
|||
- enum:
|
||||
- renesas,r9a07g054-du # RZ/V2L
|
||||
- const: renesas,r9a07g044-du # RZ/G2L fallback
|
||||
- items:
|
||||
- const: renesas,r9a09g056-du # RZ/V2N
|
||||
- const: renesas,r9a09g057-du # RZ/V2H(P) fallback
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -17,6 +17,7 @@ properties:
|
|||
- rockchip,px30-mipi-dsi
|
||||
- rockchip,rk3128-mipi-dsi
|
||||
- rockchip,rk3288-mipi-dsi
|
||||
- rockchip,rk3368-mipi-dsi
|
||||
- rockchip,rk3399-mipi-dsi
|
||||
- rockchip,rk3568-mipi-dsi
|
||||
- rockchip,rv1126-mipi-dsi
|
||||
|
|
@ -73,6 +74,7 @@ allOf:
|
|||
enum:
|
||||
- rockchip,px30-mipi-dsi
|
||||
- rockchip,rk3128-mipi-dsi
|
||||
- rockchip,rk3368-mipi-dsi
|
||||
- rockchip,rk3568-mipi-dsi
|
||||
- rockchip,rv1126-mipi-dsi
|
||||
|
||||
|
|
|
|||
|
|
@ -113,6 +113,14 @@ properties:
|
|||
description:
|
||||
Additional HDMI QP related data is accessed through VO GRF regs.
|
||||
|
||||
frl-enable-gpios:
|
||||
description:
|
||||
Optional GPIO line to be asserted when operating in HDMI 2.1 FRL mode and
|
||||
deasserted for HDMI 1.4/2.0 TMDS. It can be used to control external
|
||||
voltage bias for HDMI data lines. When not present the HDMI encoder will
|
||||
operate in TMDS mode only.
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
|
@ -132,8 +140,10 @@ unevaluatedProperties: false
|
|||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/rockchip,rk3588-cru.h>
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
#include <dt-bindings/pinctrl/rockchip.h>
|
||||
#include <dt-bindings/power/rk3588-power.h>
|
||||
#include <dt-bindings/reset/rockchip,rk3588-cru.h>
|
||||
|
||||
|
|
@ -164,6 +174,7 @@ examples:
|
|||
rockchip,grf = <&sys_grf>;
|
||||
rockchip,vo-grf = <&vo1_grf>;
|
||||
#sound-dai-cells = <0>;
|
||||
frl-enable-gpios = <&gpio4 RK_PB1 GPIO_ACTIVE_LOW>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/ti,twl4030-gpio.yaml#
|
||||
$id: http://devicetree.org/schemas/gpio/ti,twl4030-gpio.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: TI TWL4030 GPIO controller
|
||||
|
|
|
|||
|
|
@ -18,6 +18,8 @@ properties:
|
|||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- mediatek,mt8196-mali
|
||||
- nxp,imx95-mali # G310
|
||||
- rockchip,rk3588-mali
|
||||
- const: arm,mali-valhall-csf # Mali Valhall GPU model/revision is fully discoverable
|
||||
|
||||
|
|
@ -44,7 +46,9 @@ properties:
|
|||
minItems: 1
|
||||
items:
|
||||
- const: core
|
||||
- const: coregroup
|
||||
- enum:
|
||||
- coregroup
|
||||
- stacks
|
||||
- const: stacks
|
||||
|
||||
mali-supply: true
|
||||
|
|
@ -91,7 +95,6 @@ required:
|
|||
- interrupts
|
||||
- interrupt-names
|
||||
- clocks
|
||||
- mali-supply
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
|
|
@ -108,6 +111,29 @@ allOf:
|
|||
power-domains:
|
||||
maxItems: 1
|
||||
power-domain-names: false
|
||||
required:
|
||||
- mali-supply
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: mediatek,mt8196-mali
|
||||
then:
|
||||
properties:
|
||||
mali-supply: false
|
||||
sram-supply: false
|
||||
operating-points-v2: false
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
power-domain-names: false
|
||||
clocks:
|
||||
maxItems: 2
|
||||
clock-names:
|
||||
items:
|
||||
- const: core
|
||||
- const: stacks
|
||||
required:
|
||||
- power-domains
|
||||
|
||||
examples:
|
||||
- |
|
||||
|
|
@ -143,5 +169,17 @@ examples:
|
|||
};
|
||||
};
|
||||
};
|
||||
- |
|
||||
gpu@48000000 {
|
||||
compatible = "mediatek,mt8196-mali", "arm,mali-valhall-csf";
|
||||
reg = <0x48000000 0x480000>;
|
||||
clocks = <&gpufreq 0>, <&gpufreq 1>;
|
||||
clock-names = "core", "stacks";
|
||||
interrupts = <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH 0>,
|
||||
<GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH 0>,
|
||||
<GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH 0>;
|
||||
interrupt-names = "job", "mmu", "gpu";
|
||||
power-domains = <&gpufreq>;
|
||||
};
|
||||
|
||||
...
|
||||
|
|
|
|||
|
|
@ -13,6 +13,16 @@ maintainers:
|
|||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- renesas,r8a7796-gpu
|
||||
- renesas,r8a77961-gpu
|
||||
- const: img,img-gx6250
|
||||
- const: img,img-rogue
|
||||
- items:
|
||||
- const: renesas,r8a77965-gpu
|
||||
- const: img,img-ge7800
|
||||
- const: img,img-rogue
|
||||
- items:
|
||||
- enum:
|
||||
- ti,am62-gpu
|
||||
|
|
@ -82,6 +92,33 @@ required:
|
|||
additionalProperties: false
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- ti,am62-gpu
|
||||
- ti,j721s2-gpu
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- img,img-ge7800
|
||||
- img,img-gx6250
|
||||
- thead,th1520-gpu
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
minItems: 3
|
||||
clock-names:
|
||||
minItems: 3
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
|
|
@ -90,14 +127,31 @@ allOf:
|
|||
then:
|
||||
properties:
|
||||
power-domains:
|
||||
items:
|
||||
- description: Power domain A
|
||||
maxItems: 1
|
||||
power-domain-names:
|
||||
maxItems: 1
|
||||
required:
|
||||
- power-domains
|
||||
- power-domain-names
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- img,img-bxs-4-64
|
||||
- img,img-ge7800
|
||||
- img,img-gx6250
|
||||
then:
|
||||
properties:
|
||||
power-domains:
|
||||
minItems: 2
|
||||
power-domain-names:
|
||||
minItems: 2
|
||||
required:
|
||||
- power-domains
|
||||
- power-domain-names
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
|
|
@ -105,10 +159,6 @@ allOf:
|
|||
const: thead,th1520-gpu
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
minItems: 3
|
||||
clock-names:
|
||||
minItems: 3
|
||||
power-domains:
|
||||
items:
|
||||
- description: The single, unified power domain for the GPU on the
|
||||
|
|
@ -117,35 +167,6 @@ allOf:
|
|||
required:
|
||||
- power-domains
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: img,img-bxs-4-64
|
||||
then:
|
||||
properties:
|
||||
power-domains:
|
||||
items:
|
||||
- description: Power domain A
|
||||
- description: Power domain B
|
||||
power-domain-names:
|
||||
minItems: 2
|
||||
required:
|
||||
- power-domains
|
||||
- power-domain-names
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- ti,am62-gpu
|
||||
- ti,j721s2-gpu
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,36 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/i2c/apm,xgene-slimpro-i2c.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: APM X-Gene SLIMpro Mailbox I2C
|
||||
|
||||
maintainers:
|
||||
- Khuong Dinh <khuong@os.amperecomputing.com>
|
||||
|
||||
description:
|
||||
An I2C controller accessed over the "SLIMpro" mailbox.
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/i2c/i2c-controller.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: apm,xgene-slimpro-i2c
|
||||
|
||||
mboxes:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- mboxes
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
compatible = "apm,xgene-slimpro-i2c";
|
||||
mboxes = <&mailbox 0>;
|
||||
};
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
APM X-Gene SLIMpro Mailbox I2C Driver
|
||||
|
||||
An I2C controller accessed over the "SLIMpro" mailbox.
|
||||
|
||||
Required properties :
|
||||
|
||||
- compatible : should be "apm,xgene-slimpro-i2c"
|
||||
- mboxes : use the label reference for the mailbox as the first parameter.
|
||||
The second parameter is the channel number.
|
||||
|
||||
Example :
|
||||
i2cslimpro {
|
||||
compatible = "apm,xgene-slimpro-i2c";
|
||||
mboxes = <&mailbox 0>;
|
||||
};
|
||||
|
|
@ -89,6 +89,8 @@ properties:
|
|||
- description: Qcom Adreno GPUs implementing "qcom,smmu-500" and "arm,mmu-500"
|
||||
items:
|
||||
- enum:
|
||||
- qcom,glymur-smmu-500
|
||||
- qcom,kaanapali-smmu-500
|
||||
- qcom,milos-smmu-500
|
||||
- qcom,qcm2290-smmu-500
|
||||
- qcom,qcs615-smmu-500
|
||||
|
|
|
|||
|
|
@ -180,9 +180,9 @@ allOf:
|
|||
then:
|
||||
properties:
|
||||
reg:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
reg-names:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
else:
|
||||
properties:
|
||||
reg:
|
||||
|
|
|
|||
79
Documentation/devicetree/bindings/npu/arm,ethos.yaml
Normal file
79
Documentation/devicetree/bindings/npu/arm,ethos.yaml
Normal file
|
|
@ -0,0 +1,79 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/npu/arm,ethos.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Arm Ethos U65/U85
|
||||
|
||||
maintainers:
|
||||
- Rob Herring <robh@kernel.org>
|
||||
|
||||
description: >
|
||||
The Arm Ethos-U NPUs are designed for IoT inference applications. The NPUs
|
||||
can accelerate 8-bit and 16-bit integer quantized networks:
|
||||
|
||||
Transformer networks (U85 only)
|
||||
Convolutional Neural Networks (CNN)
|
||||
Recurrent Neural Networks (RNN)
|
||||
|
||||
Further documentation is available here:
|
||||
|
||||
U65 TRM: https://developer.arm.com/documentation/102023/
|
||||
U85 TRM: https://developer.arm.com/documentation/102685/
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,imx93-npu
|
||||
- const: arm,ethos-u65
|
||||
- items:
|
||||
- {}
|
||||
- const: arm,ethos-u85
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 2
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: core
|
||||
- const: apb
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
sram:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/clock/imx93-clock.h>
|
||||
|
||||
npu@4a900000 {
|
||||
compatible = "fsl,imx93-npu", "arm,ethos-u65";
|
||||
reg = <0x4a900000 0x1000>;
|
||||
interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
|
||||
power-domains = <&mlmix>;
|
||||
clocks = <&clk IMX93_CLK_ML>, <&clk IMX93_CLK_ML_APB>;
|
||||
clock-names = "core", "apb";
|
||||
sram = <&sram>;
|
||||
};
|
||||
...
|
||||
|
|
@ -142,7 +142,9 @@ allOf:
|
|||
required:
|
||||
- orientation-switch
|
||||
then:
|
||||
$ref: /schemas/usb/usb-switch.yaml#
|
||||
allOf:
|
||||
- $ref: /schemas/usb/usb-switch.yaml#
|
||||
- $ref: /schemas/usb/usb-switch-ports.yaml#
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
|
|
|
|||
|
|
@ -24,6 +24,10 @@ properties:
|
|||
- enum:
|
||||
- qcom,qcs8300-qmp-ufs-phy
|
||||
- const: qcom,sa8775p-qmp-ufs-phy
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,kaanapali-qmp-ufs-phy
|
||||
- const: qcom,sm8750-qmp-ufs-phy
|
||||
- enum:
|
||||
- qcom,msm8996-qmp-ufs-phy
|
||||
- qcom,msm8998-qmp-ufs-phy
|
||||
|
|
|
|||
|
|
@ -125,7 +125,9 @@ allOf:
|
|||
contains:
|
||||
const: google,gs101-usb31drd-phy
|
||||
then:
|
||||
$ref: /schemas/usb/usb-switch.yaml#
|
||||
allOf:
|
||||
- $ref: /schemas/usb/usb-switch.yaml#
|
||||
- $ref: /schemas/usb/usb-switch-ports.yaml#
|
||||
|
||||
properties:
|
||||
clocks:
|
||||
|
|
|
|||
|
|
@ -197,6 +197,7 @@ allOf:
|
|||
- renesas,rcar-gen2-scif
|
||||
- renesas,rcar-gen3-scif
|
||||
- renesas,rcar-gen4-scif
|
||||
- renesas,rcar-gen5-scif
|
||||
then:
|
||||
properties:
|
||||
interrupts:
|
||||
|
|
|
|||
|
|
@ -79,6 +79,7 @@ properties:
|
|||
- fsl,imx-audio-nau8822
|
||||
- fsl,imx-audio-sgtl5000
|
||||
- fsl,imx-audio-si476x
|
||||
- fsl,imx-audio-tlv320
|
||||
- fsl,imx-audio-tlv320aic31xx
|
||||
- fsl,imx-audio-tlv320aic32x4
|
||||
- fsl,imx-audio-wm8524
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ properties:
|
|||
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
maxItems: 4
|
||||
items:
|
||||
enum: [1, 2, 3, 4]
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ properties:
|
|||
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
maxItems: 5
|
||||
items:
|
||||
enum: [1, 2, 3, 4, 5]
|
||||
|
||||
|
|
|
|||
|
|
@ -33,6 +33,7 @@ properties:
|
|||
- qcom,apq8096-sndcard
|
||||
- qcom,glymur-sndcard
|
||||
- qcom,qcm6490-idp-sndcard
|
||||
- qcom,qcs615-sndcard
|
||||
- qcom,qcs6490-rb3gen2-sndcard
|
||||
- qcom,qcs8275-sndcard
|
||||
- qcom,qcs9075-sndcard
|
||||
|
|
|
|||
|
|
@ -24,10 +24,10 @@ description: |
|
|||
Instruments Smart Amp speaker protection algorithm. The
|
||||
integrated speaker voltage and current sense provides for real time
|
||||
monitoring of loudspeaker behavior.
|
||||
The TAS5825/TAS5827 is a stereo, digital input Class-D audio
|
||||
amplifier optimized for efficiently driving high peak power into
|
||||
small loudspeakers. An integrated on-chip DSP supports Texas
|
||||
Instruments Smart Amp speaker protection algorithm.
|
||||
The TAS5802/TAS5815/TAS5825/TAS5827/TAS5828 is a stereo, digital input
|
||||
Class-D audio amplifier optimized for efficiently driving high peak
|
||||
power into small loudspeakers. An integrated on-chip DSP supports
|
||||
Texas Instruments Smart Amp speaker protection algorithm.
|
||||
|
||||
Specifications about the audio amplifier can be found at:
|
||||
https://www.ti.com/lit/gpn/tas2120
|
||||
|
|
@ -35,8 +35,10 @@ description: |
|
|||
https://www.ti.com/lit/gpn/tas2563
|
||||
https://www.ti.com/lit/gpn/tas2572
|
||||
https://www.ti.com/lit/gpn/tas2781
|
||||
https://www.ti.com/lit/gpn/tas5815
|
||||
https://www.ti.com/lit/gpn/tas5825m
|
||||
https://www.ti.com/lit/gpn/tas5827
|
||||
https://www.ti.com/lit/gpn/tas5828m
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
@ -65,11 +67,21 @@ properties:
|
|||
Protection and Audio Processing, 16/20/24/32bit stereo I2S or
|
||||
multichannel TDM.
|
||||
|
||||
ti,tas5802: 22-W, Inductor-Less, Digital Input, Closed-Loop Class-D
|
||||
Audio Amplifier with 96-Khz Extended Processing and Low Idle Power
|
||||
Dissipation.
|
||||
|
||||
ti,tas5815: 30-W, Digital Input, Stereo, Closed-loop Class-D Audio
|
||||
Amplifier with 96 kHz Enhanced Processing
|
||||
|
||||
ti,tas5825: 38-W Stereo, Inductor-Less, Digital Input, Closed-Loop 4.5V
|
||||
to 26.4V Class-D Audio Amplifier with 192-kHz Extended Audio Processing.
|
||||
|
||||
ti,tas5827: 47-W Stereo, Digital Input, High Efficiency Closed-Loop Class-D
|
||||
Amplifier with Class-H Algorithm
|
||||
ti,tas5827: 47-W Stereo, Digital Input, High Efficiency Closed-Loop
|
||||
Class-D Amplifier with Class-H Algorithm
|
||||
|
||||
ti,tas5828: 50-W Stereo, Digital Input, High Efficiency Closed-Loop
|
||||
Class-D Amplifier with Hybrid-Pro Algorithm
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
|
|
@ -80,8 +92,11 @@ properties:
|
|||
- ti,tas2563
|
||||
- ti,tas2570
|
||||
- ti,tas2572
|
||||
- ti,tas5802
|
||||
- ti,tas5815
|
||||
- ti,tas5825
|
||||
- ti,tas5827
|
||||
- ti,tas5828
|
||||
- const: ti,tas2781
|
||||
- enum:
|
||||
- ti,tas2781
|
||||
|
|
@ -177,12 +192,28 @@ allOf:
|
|||
minimum: 0x38
|
||||
maximum: 0x3f
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- ti,tas5802
|
||||
- ti,tas5815
|
||||
then:
|
||||
properties:
|
||||
reg:
|
||||
maxItems: 4
|
||||
items:
|
||||
minimum: 0x54
|
||||
maximum: 0x57
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- ti,tas5827
|
||||
- ti,tas5828
|
||||
then:
|
||||
properties:
|
||||
reg:
|
||||
|
|
|
|||
|
|
@ -14,9 +14,14 @@ allOf:
|
|||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- cdns,spi-r1p6
|
||||
- xlnx,zynq-spi-r1p6
|
||||
oneOf:
|
||||
- enum:
|
||||
- xlnx,zynq-spi-r1p6
|
||||
- items:
|
||||
- enum:
|
||||
- xlnx,zynqmp-spi-r1p6
|
||||
- xlnx,versal-net-spi-r1p6
|
||||
- const: cdns,spi-r1p6
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -34,6 +34,7 @@ properties:
|
|||
- rockchip,rk3328-spi
|
||||
- rockchip,rk3368-spi
|
||||
- rockchip,rk3399-spi
|
||||
- rockchip,rk3506-spi
|
||||
- rockchip,rk3528-spi
|
||||
- rockchip,rk3562-spi
|
||||
- rockchip,rk3568-spi
|
||||
|
|
|
|||
|
|
@ -15,6 +15,7 @@ select:
|
|||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,kaanapali-ufshc
|
||||
- qcom,sm8650-ufshc
|
||||
- qcom,sm8750-ufshc
|
||||
required:
|
||||
|
|
@ -24,6 +25,7 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- qcom,kaanapali-ufshc
|
||||
- qcom,sm8650-ufshc
|
||||
- qcom,sm8750-ufshc
|
||||
- const: qcom,ufshc
|
||||
|
|
|
|||
|
|
@ -76,6 +76,7 @@ required:
|
|||
|
||||
allOf:
|
||||
- $ref: usb-switch.yaml#
|
||||
- $ref: usb-switch-ports.yaml#
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
|
|
|
|||
|
|
@ -89,13 +89,21 @@ required:
|
|||
- reg
|
||||
- "#address-cells"
|
||||
- "#size-cells"
|
||||
- dma-ranges
|
||||
- ranges
|
||||
- clocks
|
||||
- clock-names
|
||||
- interrupts
|
||||
- power-domains
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
const: fsl,imx8mp-dwc3
|
||||
then:
|
||||
required:
|
||||
- dma-ranges
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
|
|
|
|||
|
|
@ -52,6 +52,7 @@ required:
|
|||
|
||||
allOf:
|
||||
- $ref: usb-switch.yaml#
|
||||
- $ref: usb-switch-ports.yaml#
|
||||
- if:
|
||||
required:
|
||||
- mode-switch
|
||||
|
|
|
|||
|
|
@ -46,6 +46,7 @@ required:
|
|||
|
||||
allOf:
|
||||
- $ref: usb-switch.yaml#
|
||||
- $ref: usb-switch-ports.yaml#
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
|
|
|
|||
|
|
@ -91,6 +91,7 @@ required:
|
|||
|
||||
allOf:
|
||||
- $ref: usb-switch.yaml#
|
||||
- $ref: usb-switch-ports.yaml#
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
|
|
|
|||
|
|
@ -81,6 +81,7 @@ required:
|
|||
|
||||
allOf:
|
||||
- $ref: usb-switch.yaml#
|
||||
- $ref: usb-switch-ports.yaml#
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
|
|
|
|||
|
|
@ -68,6 +68,7 @@ properties:
|
|||
- qcom,sm8550-dwc3
|
||||
- qcom,sm8650-dwc3
|
||||
- qcom,x1e80100-dwc3
|
||||
- qcom,x1e80100-dwc3-mp
|
||||
- const: qcom,snps-dwc3
|
||||
|
||||
reg:
|
||||
|
|
@ -460,8 +461,10 @@ allOf:
|
|||
then:
|
||||
properties:
|
||||
interrupts:
|
||||
minItems: 4
|
||||
maxItems: 5
|
||||
interrupt-names:
|
||||
minItems: 4
|
||||
items:
|
||||
- const: dwc_usb3
|
||||
- const: pwr_event
|
||||
|
|
|
|||
|
|
@ -60,6 +60,7 @@ required:
|
|||
|
||||
allOf:
|
||||
- $ref: usb-switch.yaml#
|
||||
- $ref: usb-switch-ports.yaml#
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@ maintainers:
|
|||
|
||||
allOf:
|
||||
- $ref: usb-switch.yaml#
|
||||
- $ref: usb-switch-ports.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
68
Documentation/devicetree/bindings/usb/usb-switch-ports.yaml
Normal file
68
Documentation/devicetree/bindings/usb/usb-switch-ports.yaml
Normal file
|
|
@ -0,0 +1,68 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/usb/usb-switch-ports.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: USB Orientation and Mode Switches Ports Graph Properties
|
||||
|
||||
maintainers:
|
||||
- Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
|
||||
description:
|
||||
Ports Graph properties for devices handling USB mode and orientation switching.
|
||||
|
||||
properties:
|
||||
port:
|
||||
$ref: /schemas/graph.yaml#/$defs/port-base
|
||||
description:
|
||||
A port node to link the device to a TypeC controller for the purpose of
|
||||
handling altmode muxing and orientation switching.
|
||||
|
||||
properties:
|
||||
endpoint:
|
||||
$ref: /schemas/graph.yaml#/$defs/endpoint-base
|
||||
unevaluatedProperties: false
|
||||
properties:
|
||||
data-lanes:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
minItems: 1
|
||||
maxItems: 8
|
||||
uniqueItems: true
|
||||
items:
|
||||
maximum: 8
|
||||
|
||||
ports:
|
||||
$ref: /schemas/graph.yaml#/properties/ports
|
||||
properties:
|
||||
port@0:
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
description:
|
||||
Super Speed (SS) Output endpoint to the Type-C connector
|
||||
|
||||
port@1:
|
||||
$ref: /schemas/graph.yaml#/$defs/port-base
|
||||
description:
|
||||
Super Speed (SS) Input endpoint from the Super-Speed PHY
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
endpoint:
|
||||
$ref: /schemas/graph.yaml#/$defs/endpoint-base
|
||||
unevaluatedProperties: false
|
||||
properties:
|
||||
data-lanes:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
minItems: 1
|
||||
maxItems: 8
|
||||
uniqueItems: true
|
||||
items:
|
||||
maximum: 8
|
||||
|
||||
oneOf:
|
||||
- required:
|
||||
- port
|
||||
- required:
|
||||
- ports
|
||||
|
||||
additionalProperties: true
|
||||
|
|
@ -25,56 +25,4 @@ properties:
|
|||
description: Possible handler of SuperSpeed signals retiming
|
||||
type: boolean
|
||||
|
||||
port:
|
||||
$ref: /schemas/graph.yaml#/$defs/port-base
|
||||
description:
|
||||
A port node to link the device to a TypeC controller for the purpose of
|
||||
handling altmode muxing and orientation switching.
|
||||
|
||||
properties:
|
||||
endpoint:
|
||||
$ref: /schemas/graph.yaml#/$defs/endpoint-base
|
||||
unevaluatedProperties: false
|
||||
properties:
|
||||
data-lanes:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
minItems: 1
|
||||
maxItems: 8
|
||||
uniqueItems: true
|
||||
items:
|
||||
maximum: 8
|
||||
|
||||
ports:
|
||||
$ref: /schemas/graph.yaml#/properties/ports
|
||||
properties:
|
||||
port@0:
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
description:
|
||||
Super Speed (SS) Output endpoint to the Type-C connector
|
||||
|
||||
port@1:
|
||||
$ref: /schemas/graph.yaml#/$defs/port-base
|
||||
description:
|
||||
Super Speed (SS) Input endpoint from the Super-Speed PHY
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
endpoint:
|
||||
$ref: /schemas/graph.yaml#/$defs/endpoint-base
|
||||
unevaluatedProperties: false
|
||||
properties:
|
||||
data-lanes:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
minItems: 1
|
||||
maxItems: 8
|
||||
uniqueItems: true
|
||||
items:
|
||||
maximum: 8
|
||||
|
||||
oneOf:
|
||||
- required:
|
||||
- port
|
||||
- required:
|
||||
- ports
|
||||
|
||||
additionalProperties: true
|
||||
|
|
|
|||
|
|
@ -176,6 +176,8 @@ patternProperties:
|
|||
description: All Sensors Corporation
|
||||
"^asix,.*":
|
||||
description: ASIX Electronics Corporation
|
||||
"^asl-tek,.*":
|
||||
description: ASL Xiamen Technology Co., Ltd.
|
||||
"^aspeed,.*":
|
||||
description: ASPEED Technology Inc.
|
||||
"^asrock,.*":
|
||||
|
|
@ -835,6 +837,8 @@ patternProperties:
|
|||
description: JOZ BV
|
||||
"^jty,.*":
|
||||
description: JTY
|
||||
"^jutouch,.*":
|
||||
description: JuTouch Technology Co., Ltd.
|
||||
"^kam,.*":
|
||||
description: Kamstrup A/S
|
||||
"^karo,.*":
|
||||
|
|
@ -1323,6 +1327,8 @@ patternProperties:
|
|||
description: Raumfeld GmbH
|
||||
"^raydium,.*":
|
||||
description: Raydium Semiconductor Corp.
|
||||
"^raystar,.*":
|
||||
description: Raystar Optronics, Inc.
|
||||
"^rda,.*":
|
||||
description: Unisoc Communications, Inc.
|
||||
"^realtek,.*":
|
||||
|
|
|
|||
|
|
@ -183,10 +183,10 @@ in the place where the name normally goes. The structure is
|
|||
- det_checksum
|
||||
- Directory leaf block checksum.
|
||||
|
||||
The leaf directory block checksum is calculated against the FS UUID, the
|
||||
directory's inode number, the directory's inode generation number, and
|
||||
the entire directory entry block up to (but not including) the fake
|
||||
directory entry.
|
||||
The leaf directory block checksum is calculated against the FS UUID (or
|
||||
the checksum seed, if that feature is enabled for the fs), the directory's
|
||||
inode number, the directory's inode generation number, and the entire
|
||||
directory entry block up to (but not including) the fake directory entry.
|
||||
|
||||
Hash Tree Directories
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -196,12 +196,12 @@ new feature was added to ext3 to provide a faster (but peculiar)
|
|||
balanced tree keyed off a hash of the directory entry name. If the
|
||||
EXT4_INDEX_FL (0x1000) flag is set in the inode, this directory uses a
|
||||
hashed btree (htree) to organize and find directory entries. For
|
||||
backwards read-only compatibility with ext2, this tree is actually
|
||||
hidden inside the directory file, masquerading as “empty” directory data
|
||||
blocks! It was stated previously that the end of the linear directory
|
||||
entry table was signified with an entry pointing to inode 0; this is
|
||||
(ab)used to fool the old linear-scan algorithm into thinking that the
|
||||
rest of the directory block is empty so that it moves on.
|
||||
backwards read-only compatibility with ext2, interior tree nodes are actually
|
||||
hidden inside the directory file, masquerading as “empty” directory entries
|
||||
spanning the whole block. It was stated previously that directory entries
|
||||
with the inode set to 0 are treated as unused entries; this is (ab)used to
|
||||
fool the old linear-scan algorithm into skipping over those blocks containing
|
||||
the interior tree node data.
|
||||
|
||||
The root of the tree always lives in the first data block of the
|
||||
directory. By ext2 custom, the '.' and '..' entries must appear at the
|
||||
|
|
@ -209,24 +209,24 @@ beginning of this first block, so they are put here as two
|
|||
``struct ext4_dir_entry_2`` s and not stored in the tree. The rest of
|
||||
the root node contains metadata about the tree and finally a hash->block
|
||||
map to find nodes that are lower in the htree. If
|
||||
``dx_root.info.indirect_levels`` is non-zero then the htree has two
|
||||
levels; the data block pointed to by the root node's map is an interior
|
||||
node, which is indexed by a minor hash. Interior nodes in this tree
|
||||
contains a zeroed out ``struct ext4_dir_entry_2`` followed by a
|
||||
minor_hash->block map to find leafe nodes. Leaf nodes contain a linear
|
||||
array of all ``struct ext4_dir_entry_2``; all of these entries
|
||||
(presumably) hash to the same value. If there is an overflow, the
|
||||
entries simply overflow into the next leaf node, and the
|
||||
least-significant bit of the hash (in the interior node map) that gets
|
||||
us to this next leaf node is set.
|
||||
``dx_root.info.indirect_levels`` is non-zero then the htree has that many
|
||||
levels and the blocks pointed to by the root node's map are interior nodes.
|
||||
These interior nodes have a zeroed out ``struct ext4_dir_entry_2`` followed by
|
||||
a hash->block map to find nodes of the next level. Leaf nodes look like
|
||||
classic linear directory blocks, but all of its entries have a hash value
|
||||
equal or greater than the indicated hash of the parent node.
|
||||
|
||||
To traverse the directory as a htree, the code calculates the hash of
|
||||
the desired file name and uses it to find the corresponding block
|
||||
number. If the tree is flat, the block is a linear array of directory
|
||||
entries that can be searched; otherwise, the minor hash of the file name
|
||||
is computed and used against this second block to find the corresponding
|
||||
third block number. That third block number will be a linear array of
|
||||
directory entries.
|
||||
The actual hash value for an entry name is only 31 bits, the least-significant
|
||||
bit is set to 0. However, if there is a hash collision between directory
|
||||
entries, the least-significant bit may get set to 1 on interior nodes in the
|
||||
case where these two (or more) hash-colliding entries do not fit into one leaf
|
||||
node and must be split across multiple nodes.
|
||||
|
||||
To look up a name in such a htree, the code calculates the hash of the desired
|
||||
file name and uses it to find the leaf node with the range of hash values the
|
||||
calculated hash falls into (in other words, a lookup works basically the same
|
||||
as it would in a B-Tree keyed by the hash value), and possibly also scanning
|
||||
the leaf nodes that follow (in tree order) in case of hash collisions.
|
||||
|
||||
To traverse the directory as a linear array (such as the old code does),
|
||||
the code simply reads every data block in the directory. The blocks used
|
||||
|
|
@ -319,7 +319,8 @@ of a data block:
|
|||
* - 0x24
|
||||
- __le32
|
||||
- block
|
||||
- The block number (within the directory file) that goes with hash=0.
|
||||
- The block number (within the directory file) that lead to the left-most
|
||||
leaf node, i.e. the leaf containing entries with the lowest hash values.
|
||||
* - 0x28
|
||||
- struct dx_entry
|
||||
- entries[0]
|
||||
|
|
@ -442,7 +443,7 @@ The dx_tail structure is 8 bytes long and looks like this:
|
|||
* - 0x0
|
||||
- u32
|
||||
- dt_reserved
|
||||
- Zero.
|
||||
- Unused (but still part of the checksum curiously).
|
||||
* - 0x4
|
||||
- __le32
|
||||
- dt_checksum
|
||||
|
|
@ -450,4 +451,4 @@ The dx_tail structure is 8 bytes long and looks like this:
|
|||
|
||||
The checksum is calculated against the FS UUID, the htree index header
|
||||
(dx_root or dx_node), all of the htree indices (dx_entry) that are in
|
||||
use, and the tail block (dx_tail).
|
||||
use, and the tail block (dx_tail) with the dt_checksum initially set to 0.
|
||||
|
|
|
|||
|
|
@ -37,8 +37,8 @@ which corresponds to the following ASL (in the scope of \_SB)::
|
|||
Name (_HID, ...)
|
||||
Name (_CRS, ResourceTemplate () {
|
||||
I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
|
||||
AddressingMode7Bit, "\\_SB.SMB1.CH00", 0x00,
|
||||
ResourceConsumer,,)
|
||||
AddressingMode7Bit, "\\_SB.SMB1.MUX0.CH00",
|
||||
0x00, ResourceConsumer,,)
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -52,8 +52,8 @@ which corresponds to the following ASL (in the scope of \_SB)::
|
|||
Name (_HID, ...)
|
||||
Name (_CRS, ResourceTemplate () {
|
||||
I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
|
||||
AddressingMode7Bit, "\\_SB.SMB1.CH01", 0x00,
|
||||
ResourceConsumer,,)
|
||||
AddressingMode7Bit, "\\_SB.SMB1.MUX0.CH01",
|
||||
0x00, ResourceConsumer,,)
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -92,6 +92,18 @@ GEM Atomic Helper Reference
|
|||
.. kernel-doc:: drivers/gpu/drm/drm_gem_atomic_helper.c
|
||||
:export:
|
||||
|
||||
VBLANK Helper Reference
|
||||
-----------------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_vblank_helper.c
|
||||
:doc: overview
|
||||
|
||||
.. kernel-doc:: include/drm/drm_vblank_helper.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_vblank_helper.c
|
||||
:export:
|
||||
|
||||
Simple KMS Helper Reference
|
||||
===========================
|
||||
|
||||
|
|
|
|||
|
|
@ -413,6 +413,21 @@ Plane Panic Functions Reference
|
|||
.. kernel-doc:: drivers/gpu/drm/drm_panic.c
|
||||
:export:
|
||||
|
||||
Colorop Abstraction
|
||||
===================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_colorop.c
|
||||
:doc: overview
|
||||
|
||||
Colorop Functions Reference
|
||||
---------------------------
|
||||
|
||||
.. kernel-doc:: include/drm/drm_colorop.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_colorop.c
|
||||
:export:
|
||||
|
||||
Display Modes Function Reference
|
||||
================================
|
||||
|
||||
|
|
|
|||
|
|
@ -44,25 +44,6 @@ automatically generates the corresponding mappings between a value and a number.
|
|||
| Complexity: Beginner
|
||||
| Link: https://docs.rs/num/latest/num/trait.FromPrimitive.html
|
||||
|
||||
Conversion from byte slices for types implementing FromBytes [TRSM]
|
||||
-------------------------------------------------------------------
|
||||
|
||||
We retrieve several structures from byte streams coming from the BIOS or loaded
|
||||
firmware. At the moment converting the bytes slice into the proper type require
|
||||
an inelegant `unsafe` operation; this will go away once `FromBytes` implements
|
||||
a proper `from_bytes` method.
|
||||
|
||||
| Complexity: Beginner
|
||||
|
||||
CoherentAllocation improvements [COHA]
|
||||
--------------------------------------
|
||||
|
||||
`CoherentAllocation` needs a safe way to write into the allocation, and to
|
||||
obtain slices within the allocation.
|
||||
|
||||
| Complexity: Beginner
|
||||
| Contact: Abdiel Janulgue
|
||||
|
||||
Generic register abstraction [REGA]
|
||||
-----------------------------------
|
||||
|
||||
|
|
@ -153,17 +134,6 @@ A `num` core kernel module is being designed to provide these operations.
|
|||
| Complexity: Intermediate
|
||||
| Contact: Alexandre Courbot
|
||||
|
||||
Delay / Sleep abstractions [DLAY]
|
||||
---------------------------------
|
||||
|
||||
Rust abstractions for the kernel's delay() and sleep() functions.
|
||||
|
||||
FUJITA Tomonori plans to work on abstractions for read_poll_timeout_atomic()
|
||||
(and friends) [1].
|
||||
|
||||
| Complexity: Beginner
|
||||
| Link: https://lore.kernel.org/netdev/20250228.080550.354359820929821928.fujita.tomonori@gmail.com/ [1]
|
||||
|
||||
IRQ abstractions
|
||||
----------------
|
||||
|
||||
|
|
|
|||
378
Documentation/gpu/rfc/color_pipeline.rst
Normal file
378
Documentation/gpu/rfc/color_pipeline.rst
Normal file
|
|
@ -0,0 +1,378 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
========================
|
||||
Linux Color Pipeline API
|
||||
========================
|
||||
|
||||
What problem are we solving?
|
||||
============================
|
||||
|
||||
We would like to support pre-, and post-blending complex color
|
||||
transformations in display controller hardware in order to allow for
|
||||
HW-supported HDR use-cases, as well as to provide support to
|
||||
color-managed applications, such as video or image editors.
|
||||
|
||||
It is possible to support an HDR output on HW supporting the Colorspace
|
||||
and HDR Metadata drm_connector properties, but that requires the
|
||||
compositor or application to render and compose the content into one
|
||||
final buffer intended for display. Doing so is costly.
|
||||
|
||||
Most modern display HW offers various 1D LUTs, 3D LUTs, matrices, and other
|
||||
operations to support color transformations. These operations are often
|
||||
implemented in fixed-function HW and therefore much more power efficient than
|
||||
performing similar operations via shaders or CPU.
|
||||
|
||||
We would like to make use of this HW functionality to support complex color
|
||||
transformations with no, or minimal CPU or shader load. The switch between HW
|
||||
fixed-function blocks and shaders/CPU must be seamless with no visible
|
||||
difference when fallback to shaders/CPU is neceesary at any time.
|
||||
|
||||
|
||||
How are other OSes solving this problem?
|
||||
========================================
|
||||
|
||||
The most widely supported use-cases regard HDR content, whether video or
|
||||
gaming.
|
||||
|
||||
Most OSes will specify the source content format (color gamut, encoding transfer
|
||||
function, and other metadata, such as max and average light levels) to a driver.
|
||||
Drivers will then program their fixed-function HW accordingly to map from a
|
||||
source content buffer's space to a display's space.
|
||||
|
||||
When fixed-function HW is not available the compositor will assemble a shader to
|
||||
ask the GPU to perform the transformation from the source content format to the
|
||||
display's format.
|
||||
|
||||
A compositor's mapping function and a driver's mapping function are usually
|
||||
entirely separate concepts. On OSes where a HW vendor has no insight into
|
||||
closed-source compositor code such a vendor will tune their color management
|
||||
code to visually match the compositor's. On other OSes, where both mapping
|
||||
functions are open to an implementer they will ensure both mappings match.
|
||||
|
||||
This results in mapping algorithm lock-in, meaning that no-one alone can
|
||||
experiment with or introduce new mapping algorithms and achieve
|
||||
consistent results regardless of which implementation path is taken.
|
||||
|
||||
Why is Linux different?
|
||||
=======================
|
||||
|
||||
Unlike other OSes, where there is one compositor for one or more drivers, on
|
||||
Linux we have a many-to-many relationship. Many compositors; many drivers.
|
||||
In addition each compositor vendor or community has their own view of how
|
||||
color management should be done. This is what makes Linux so beautiful.
|
||||
|
||||
This means that a HW vendor can now no longer tune their driver to one
|
||||
compositor, as tuning it to one could make it look fairly different from
|
||||
another compositor's color mapping.
|
||||
|
||||
We need a better solution.
|
||||
|
||||
|
||||
Descriptive API
|
||||
===============
|
||||
|
||||
An API that describes the source and destination colorspaces is a descriptive
|
||||
API. It describes the input and output color spaces but does not describe
|
||||
how precisely they should be mapped. Such a mapping includes many minute
|
||||
design decision that can greatly affect the look of the final result.
|
||||
|
||||
It is not feasible to describe such mapping with enough detail to ensure the
|
||||
same result from each implementation. In fact, these mappings are a very active
|
||||
research area.
|
||||
|
||||
|
||||
Prescriptive API
|
||||
================
|
||||
|
||||
A prescriptive API describes not the source and destination colorspaces. It
|
||||
instead prescribes a recipe for how to manipulate pixel values to arrive at the
|
||||
desired outcome.
|
||||
|
||||
This recipe is generally an ordered list of straight-forward operations,
|
||||
with clear mathematical definitions, such as 1D LUTs, 3D LUTs, matrices,
|
||||
or other operations that can be described in a precise manner.
|
||||
|
||||
|
||||
The Color Pipeline API
|
||||
======================
|
||||
|
||||
HW color management pipelines can significantly differ between HW
|
||||
vendors in terms of availability, ordering, and capabilities of HW
|
||||
blocks. This makes a common definition of color management blocks and
|
||||
their ordering nigh impossible. Instead we are defining an API that
|
||||
allows user space to discover the HW capabilities in a generic manner,
|
||||
agnostic of specific drivers and hardware.
|
||||
|
||||
|
||||
drm_colorop Object
|
||||
==================
|
||||
|
||||
To support the definition of color pipelines we define the DRM core
|
||||
object type drm_colorop. Individual drm_colorop objects will be chained
|
||||
via the NEXT property of a drm_colorop to constitute a color pipeline.
|
||||
Each drm_colorop object is unique, i.e., even if multiple color
|
||||
pipelines have the same operation they won't share the same drm_colorop
|
||||
object to describe that operation.
|
||||
|
||||
Note that drivers are not expected to map drm_colorop objects statically
|
||||
to specific HW blocks. The mapping of drm_colorop objects is entirely a
|
||||
driver-internal detail and can be as dynamic or static as a driver needs
|
||||
it to be. See more in the Driver Implementation Guide section below.
|
||||
|
||||
Each drm_colorop has three core properties:
|
||||
|
||||
TYPE: An enumeration property, defining the type of transformation, such as
|
||||
* enumerated curve
|
||||
* custom (uniform) 1D LUT
|
||||
* 3x3 matrix
|
||||
* 3x4 matrix
|
||||
* 3D LUT
|
||||
* etc.
|
||||
|
||||
Depending on the type of transformation other properties will describe
|
||||
more details.
|
||||
|
||||
BYPASS: A boolean property that can be used to easily put a block into
|
||||
bypass mode. The BYPASS property is not mandatory for a colorop, as long
|
||||
as the entire pipeline can get bypassed by setting the COLOR_PIPELINE on
|
||||
a plane to '0'.
|
||||
|
||||
NEXT: The ID of the next drm_colorop in a color pipeline, or 0 if this
|
||||
drm_colorop is the last in the chain.
|
||||
|
||||
An example of a drm_colorop object might look like one of these::
|
||||
|
||||
/* 1D enumerated curve */
|
||||
Color operation 42
|
||||
├─ "TYPE": immutable enum {1D enumerated curve, 1D LUT, 3x3 matrix, 3x4 matrix, 3D LUT, etc.} = 1D enumerated curve
|
||||
├─ "BYPASS": bool {true, false}
|
||||
├─ "CURVE_1D_TYPE": enum {sRGB EOTF, sRGB inverse EOTF, PQ EOTF, PQ inverse EOTF, …}
|
||||
└─ "NEXT": immutable color operation ID = 43
|
||||
|
||||
/* custom 4k entry 1D LUT */
|
||||
Color operation 52
|
||||
├─ "TYPE": immutable enum {1D enumerated curve, 1D LUT, 3x3 matrix, 3x4 matrix, 3D LUT, etc.} = 1D LUT
|
||||
├─ "BYPASS": bool {true, false}
|
||||
├─ "SIZE": immutable range = 4096
|
||||
├─ "DATA": blob
|
||||
└─ "NEXT": immutable color operation ID = 0
|
||||
|
||||
/* 17^3 3D LUT */
|
||||
Color operation 72
|
||||
├─ "TYPE": immutable enum {1D enumerated curve, 1D LUT, 3x3 matrix, 3x4 matrix, 3D LUT, etc.} = 3D LUT
|
||||
├─ "BYPASS": bool {true, false}
|
||||
├─ "SIZE": immutable range = 17
|
||||
├─ "DATA": blob
|
||||
└─ "NEXT": immutable color operation ID = 73
|
||||
|
||||
drm_colorop extensibility
|
||||
-------------------------
|
||||
|
||||
Unlike existing DRM core objects, like &drm_plane, drm_colorop is not
|
||||
extensible. This simplifies implementations and keeps all functionality
|
||||
for managing &drm_colorop objects in the DRM core.
|
||||
|
||||
If there is a need one may introduce a simple &drm_colorop_funcs
|
||||
function table in the future, for example to support an IN_FORMATS
|
||||
property on a &drm_colorop.
|
||||
|
||||
If a driver requires the ability to create a driver-specific colorop
|
||||
object they will need to add &drm_colorop func table support with
|
||||
support for the usual functions, like destroy, atomic_duplicate_state,
|
||||
and atomic_destroy_state.
|
||||
|
||||
|
||||
COLOR_PIPELINE Plane Property
|
||||
=============================
|
||||
|
||||
Color Pipelines are created by a driver and advertised via a new
|
||||
COLOR_PIPELINE enum property on each plane. Values of the property
|
||||
always include object id 0, which is the default and means all color
|
||||
processing is disabled. Additional values will be the object IDs of the
|
||||
first drm_colorop in a pipeline. A driver can create and advertise none,
|
||||
one, or more possible color pipelines. A DRM client will select a color
|
||||
pipeline by setting the COLOR PIPELINE to the respective value.
|
||||
|
||||
NOTE: Many DRM clients will set enumeration properties via the string
|
||||
value, often hard-coding it. Since this enumeration is generated based
|
||||
on the colorop object IDs it is important to perform the Color Pipeline
|
||||
Discovery, described below, instead of hard-coding color pipeline
|
||||
assignment. Drivers might generate the enum strings dynamically.
|
||||
Hard-coded strings might only work for specific drivers on a specific
|
||||
pieces of HW. Color Pipeline Discovery can work universally, as long as
|
||||
drivers implement the required color operations.
|
||||
|
||||
The COLOR_PIPELINE property is only exposed when the
|
||||
DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE is set. Drivers shall ignore any
|
||||
existing pre-blend color operations when this cap is set, such as
|
||||
COLOR_RANGE and COLOR_ENCODING. If drivers want to support COLOR_RANGE
|
||||
or COLOR_ENCODING functionality when the color pipeline client cap is
|
||||
set, they are expected to expose colorops in the pipeline to allow for
|
||||
the appropriate color transformation.
|
||||
|
||||
Setting of the COLOR_PIPELINE plane property or drm_colorop properties
|
||||
is only allowed for userspace that sets this client cap.
|
||||
|
||||
An example of a COLOR_PIPELINE property on a plane might look like this::
|
||||
|
||||
Plane 10
|
||||
├─ "TYPE": immutable enum {Overlay, Primary, Cursor} = Primary
|
||||
├─ …
|
||||
└─ "COLOR_PIPELINE": enum {0, 42, 52} = 0
|
||||
|
||||
|
||||
Color Pipeline Discovery
|
||||
========================
|
||||
|
||||
A DRM client wanting color management on a drm_plane will:
|
||||
|
||||
1. Get the COLOR_PIPELINE property of the plane
|
||||
2. iterate all COLOR_PIPELINE enum values
|
||||
3. for each enum value walk the color pipeline (via the NEXT pointers)
|
||||
and see if the available color operations are suitable for the
|
||||
desired color management operations
|
||||
|
||||
If userspace encounters an unknown or unsuitable color operation during
|
||||
discovery it does not need to reject the entire color pipeline outright,
|
||||
as long as the unknown or unsuitable colorop has a "BYPASS" property.
|
||||
Drivers will ensure that a bypassed block does not have any effect.
|
||||
|
||||
An example of chained properties to define an AMD pre-blending color
|
||||
pipeline might look like this::
|
||||
|
||||
Plane 10
|
||||
├─ "TYPE" (immutable) = Primary
|
||||
└─ "COLOR_PIPELINE": enum {0, 44} = 0
|
||||
|
||||
Color operation 44
|
||||
├─ "TYPE" (immutable) = 1D enumerated curve
|
||||
├─ "BYPASS": bool
|
||||
├─ "CURVE_1D_TYPE": enum {sRGB EOTF, PQ EOTF} = sRGB EOTF
|
||||
└─ "NEXT" (immutable) = 45
|
||||
|
||||
Color operation 45
|
||||
├─ "TYPE" (immutable) = 3x4 Matrix
|
||||
├─ "BYPASS": bool
|
||||
├─ "DATA": blob
|
||||
└─ "NEXT" (immutable) = 46
|
||||
|
||||
Color operation 46
|
||||
├─ "TYPE" (immutable) = 1D enumerated curve
|
||||
├─ "BYPASS": bool
|
||||
├─ "CURVE_1D_TYPE": enum {sRGB Inverse EOTF, PQ Inverse EOTF} = sRGB EOTF
|
||||
└─ "NEXT" (immutable) = 47
|
||||
|
||||
Color operation 47
|
||||
├─ "TYPE" (immutable) = 1D LUT
|
||||
├─ "SIZE": immutable range = 4096
|
||||
├─ "DATA": blob
|
||||
└─ "NEXT" (immutable) = 48
|
||||
|
||||
Color operation 48
|
||||
├─ "TYPE" (immutable) = 3D LUT
|
||||
├─ "DATA": blob
|
||||
└─ "NEXT" (immutable) = 49
|
||||
|
||||
Color operation 49
|
||||
├─ "TYPE" (immutable) = 1D enumerated curve
|
||||
├─ "BYPASS": bool
|
||||
├─ "CURVE_1D_TYPE": enum {sRGB EOTF, PQ EOTF} = sRGB EOTF
|
||||
└─ "NEXT" (immutable) = 0
|
||||
|
||||
|
||||
Color Pipeline Programming
|
||||
==========================
|
||||
|
||||
Once a DRM client has found a suitable pipeline it will:
|
||||
|
||||
1. Set the COLOR_PIPELINE enum value to the one pointing at the first
|
||||
drm_colorop object of the desired pipeline
|
||||
2. Set the properties for all drm_colorop objects in the pipeline to the
|
||||
desired values, setting BYPASS to true for unused drm_colorop blocks,
|
||||
and false for enabled drm_colorop blocks
|
||||
3. Perform (TEST_ONLY or not) atomic commit with all the other KMS
|
||||
states it wishes to change
|
||||
|
||||
To configure the pipeline for an HDR10 PQ plane and blending in linear
|
||||
space, a compositor might perform an atomic commit with the following
|
||||
property values::
|
||||
|
||||
Plane 10
|
||||
└─ "COLOR_PIPELINE" = 42
|
||||
|
||||
Color operation 42
|
||||
└─ "BYPASS" = true
|
||||
|
||||
Color operation 44
|
||||
└─ "BYPASS" = true
|
||||
|
||||
Color operation 45
|
||||
└─ "BYPASS" = true
|
||||
|
||||
Color operation 46
|
||||
└─ "BYPASS" = true
|
||||
|
||||
Color operation 47
|
||||
├─ "DATA" = Gamut mapping + tone mapping + night mode
|
||||
└─ "BYPASS" = false
|
||||
|
||||
Color operation 48
|
||||
├─ "CURVE_1D_TYPE" = PQ EOTF
|
||||
└─ "BYPASS" = false
|
||||
|
||||
|
||||
Driver Implementer's Guide
|
||||
==========================
|
||||
|
||||
What does this all mean for driver implementations? As noted above the
|
||||
colorops can map to HW directly but don't need to do so. Here are some
|
||||
suggestions on how to think about creating your color pipelines:
|
||||
|
||||
- Try to expose pipelines that use already defined colorops, even if
|
||||
your hardware pipeline is split differently. This allows existing
|
||||
userspace to immediately take advantage of the hardware.
|
||||
|
||||
- Additionally, try to expose your actual hardware blocks as colorops.
|
||||
Define new colorop types where you believe it can offer significant
|
||||
benefits if userspace learns to program them.
|
||||
|
||||
- Avoid defining new colorops for compound operations with very narrow
|
||||
scope. If you have a hardware block for a special operation that
|
||||
cannot be split further, you can expose that as a new colorop type.
|
||||
However, try to not define colorops for "use cases", especially if
|
||||
they require you to combine multiple hardware blocks.
|
||||
|
||||
- Design new colorops as prescriptive, not descriptive; by the
|
||||
mathematical formula, not by the assumed input and output.
|
||||
|
||||
A defined colorop type must be deterministic. The exact behavior of the
|
||||
colorop must be documented entirely, whether via a mathematical formula
|
||||
or some other description. Its operation can depend only on its
|
||||
properties and input and nothing else, allowed error tolerance
|
||||
notwithstanding.
|
||||
|
||||
|
||||
Driver Forward/Backward Compatibility
|
||||
=====================================
|
||||
|
||||
As this is uAPI drivers can't regress color pipelines that have been
|
||||
introduced for a given HW generation. New HW generations are free to
|
||||
abandon color pipelines advertised for previous generations.
|
||||
Nevertheless, it can be beneficial to carry support for existing color
|
||||
pipelines forward as those will likely already have support in DRM
|
||||
clients.
|
||||
|
||||
Introducing new colorops to a pipeline is fine, as long as they can be
|
||||
bypassed or are purely informational. DRM clients implementing support
|
||||
for the pipeline can always skip unknown properties as long as they can
|
||||
be confident that doing so will not cause unexpected results.
|
||||
|
||||
If a new colorop doesn't fall into one of the above categories
|
||||
(bypassable or informational) the modified pipeline would be unusable
|
||||
for user space. In this case a new pipeline should be defined.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
1. https://lore.kernel.org/dri-devel/QMers3awXvNCQlyhWdTtsPwkp5ie9bze_hD5nAccFW7a_RXlWjYB7MoUW_8CKLT2bSQwIXVi5H6VULYIxCdgvryZoAoJnC5lZgyK1QWn488=@emersion.fr/
|
||||
|
|
@ -35,3 +35,6 @@ host such documentation:
|
|||
.. toctree::
|
||||
|
||||
i915_vm_bind.rst
|
||||
|
||||
.. toctree::
|
||||
color_pipeline.rst
|
||||
|
|
@ -623,6 +623,43 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de>, Simona Vetter
|
|||
|
||||
Level: Advanced
|
||||
|
||||
Implement a new DUMB_CREATE2 ioctl
|
||||
----------------------------------
|
||||
|
||||
The current DUMB_CREATE ioctl is not well defined. Instead of a pixel and
|
||||
framebuffer format, it only accepts a color mode of vague semantics. Assuming
|
||||
a linear framebuffer, the color mode gives an idea of the supported pixel
|
||||
format. But userspace effectively has to guess the correct values. It really
|
||||
only works reliably with framebuffers in XRGB8888. Userspace has begun to
|
||||
workaround these limitations by computing arbitrary format's buffer sizes and
|
||||
calculating their sizes in terms of XRGB8888 pixels.
|
||||
|
||||
One possible solution is a new ioctl DUMB_CREATE2. It should accept a DRM
|
||||
format and a format modifier to resolve the color mode's ambiguity. As
|
||||
framebuffers can be multi-planar, the new ioctl has to return the buffer size,
|
||||
pitch and GEM handle for each individual color plane.
|
||||
|
||||
In the first step, the new ioctl can be limited to the current features of
|
||||
the existing DUMB_CREATE. Individual drivers can then be extended to support
|
||||
multi-planar formats. Rockchip might require this and would be a good candidate.
|
||||
|
||||
It might also be helpful to userspace to query information about the size of
|
||||
a potential buffer, if allocated. Userspace would supply geometry and format;
|
||||
the kernel would return minimal allocation sizes and scanline pitch. There is
|
||||
interest to allocate that memory from another device and provide it to the
|
||||
DRM driver (say via dma-buf).
|
||||
|
||||
Another requested feature is the ability to allocate a buffer by size, without
|
||||
format. Accelators use this for their buffer allocation and it could likely be
|
||||
generalized.
|
||||
|
||||
In addition to the kernel implementation, there must be user-space support
|
||||
for the new ioctl. There's code in Mesa that might be able to use the new
|
||||
call.
|
||||
|
||||
Contact: Thomas Zimmermann <tzimmermann@suse.de>
|
||||
|
||||
Level: Advanced
|
||||
|
||||
Better Testing
|
||||
==============
|
||||
|
|
|
|||
|
|
@ -51,6 +51,97 @@ To disable the driver, use ::
|
|||
|
||||
sudo modprobe -r vkms
|
||||
|
||||
Configuring With Configfs
|
||||
=========================
|
||||
|
||||
It is possible to create and configure multiple VKMS instances via configfs.
|
||||
|
||||
Start by mounting configfs and loading VKMS::
|
||||
|
||||
sudo mount -t configfs none /config
|
||||
sudo modprobe vkms
|
||||
|
||||
Once VKMS is loaded, ``/config/vkms`` is created automatically. Each directory
|
||||
under ``/config/vkms`` represents a VKMS instance, create a new one::
|
||||
|
||||
sudo mkdir /config/vkms/my-vkms
|
||||
|
||||
By default, the instance is disabled::
|
||||
|
||||
cat /config/vkms/my-vkms/enabled
|
||||
0
|
||||
|
||||
And directories are created for each configurable item of the display pipeline::
|
||||
|
||||
tree /config/vkms/my-vkms
|
||||
├── connectors
|
||||
├── crtcs
|
||||
├── enabled
|
||||
├── encoders
|
||||
└── planes
|
||||
|
||||
To add items to the display pipeline, create one or more directories under the
|
||||
available paths.
|
||||
|
||||
Start by creating one or more planes::
|
||||
|
||||
sudo mkdir /config/vkms/my-vkms/planes/plane0
|
||||
|
||||
Planes have 1 configurable attribute:
|
||||
|
||||
- type: Plane type: 0 overlay, 1 primary, 2 cursor (same values as those
|
||||
exposed by the "type" property of a plane)
|
||||
|
||||
Continue by creating one or more CRTCs::
|
||||
|
||||
sudo mkdir /config/vkms/my-vkms/crtcs/crtc0
|
||||
|
||||
CRTCs have 1 configurable attribute:
|
||||
|
||||
- writeback: Enable or disable writeback connector support by writing 1 or 0
|
||||
|
||||
Next, create one or more encoders::
|
||||
|
||||
sudo mkdir /config/vkms/my-vkms/encoders/encoder0
|
||||
|
||||
Last but not least, create one or more connectors::
|
||||
|
||||
sudo mkdir /config/vkms/my-vkms/connectors/connector0
|
||||
|
||||
Connectors have 1 configurable attribute:
|
||||
|
||||
- status: Connection status: 1 connected, 2 disconnected, 3 unknown (same values
|
||||
as those exposed by the "status" property of a connector)
|
||||
|
||||
To finish the configuration, link the different pipeline items::
|
||||
|
||||
sudo ln -s /config/vkms/my-vkms/crtcs/crtc0 /config/vkms/my-vkms/planes/plane0/possible_crtcs
|
||||
sudo ln -s /config/vkms/my-vkms/crtcs/crtc0 /config/vkms/my-vkms/encoders/encoder0/possible_crtcs
|
||||
sudo ln -s /config/vkms/my-vkms/encoders/encoder0 /config/vkms/my-vkms/connectors/connector0/possible_encoders
|
||||
|
||||
Since at least one primary plane is required, make sure to set the right type::
|
||||
|
||||
echo "1" | sudo tee /config/vkms/my-vkms/planes/plane0/type
|
||||
|
||||
Once you are done configuring the VKMS instance, enable it::
|
||||
|
||||
echo "1" | sudo tee /config/vkms/my-vkms/enabled
|
||||
|
||||
Finally, you can remove the VKMS instance disabling it::
|
||||
|
||||
echo "0" | sudo tee /config/vkms/my-vkms/enabled
|
||||
|
||||
And removing the top level directory and its subdirectories::
|
||||
|
||||
sudo rm /config/vkms/my-vkms/planes/*/possible_crtcs/*
|
||||
sudo rm /config/vkms/my-vkms/encoders/*/possible_crtcs/*
|
||||
sudo rm /config/vkms/my-vkms/connectors/*/possible_encoders/*
|
||||
sudo rmdir /config/vkms/my-vkms/planes/*
|
||||
sudo rmdir /config/vkms/my-vkms/crtcs/*
|
||||
sudo rmdir /config/vkms/my-vkms/encoders/*
|
||||
sudo rmdir /config/vkms/my-vkms/connectors/*
|
||||
sudo rmdir /config/vkms/my-vkms
|
||||
|
||||
Testing With IGT
|
||||
================
|
||||
|
||||
|
|
@ -68,26 +159,23 @@ To return to graphical mode, do::
|
|||
|
||||
sudo systemctl isolate graphical.target
|
||||
|
||||
Once you are in text only mode, you can run tests using the --device switch
|
||||
or IGT_DEVICE variable to specify the device filter for the driver we want
|
||||
to test. IGT_DEVICE can also be used with the run-test.sh script to run the
|
||||
Once you are in text only mode, you can run tests using the IGT_FORCE_DRIVER
|
||||
variable to specify the device filter for the driver we want to test.
|
||||
IGT_FORCE_DRIVER can also be used with the run-tests.sh script to run the
|
||||
tests for a specific driver::
|
||||
|
||||
sudo ./build/tests/<name of test> --device "sys:/sys/devices/platform/vkms"
|
||||
sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./build/tests/<name of test>
|
||||
sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./scripts/run-tests.sh -t <name of test>
|
||||
sudo IGT_FORCE_DRIVER="vkms" ./build/tests/<name of test>
|
||||
sudo IGT_FORCE_DRIVER="vkms" ./scripts/run-tests.sh -t <name of test>
|
||||
|
||||
For example, to test the functionality of the writeback library,
|
||||
we can run the kms_writeback test::
|
||||
|
||||
sudo ./build/tests/kms_writeback --device "sys:/sys/devices/platform/vkms"
|
||||
sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./build/tests/kms_writeback
|
||||
sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./scripts/run-tests.sh -t kms_writeback
|
||||
sudo IGT_FORCE_DRIVER="vkms" ./build/tests/kms_writeback
|
||||
sudo IGT_FORCE_DRIVER="vkms" ./scripts/run-tests.sh -t kms_writeback
|
||||
|
||||
You can also run subtests if you do not want to run the entire test::
|
||||
|
||||
sudo ./build/tests/kms_flip --run-subtest basic-plain-flip --device "sys:/sys/devices/platform/vkms"
|
||||
sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./build/tests/kms_flip --run-subtest basic-plain-flip
|
||||
sudo IGT_FORCE_DRIVER="vkms" ./build/tests/kms_flip --run-subtest basic-plain-flip
|
||||
|
||||
Testing With KUnit
|
||||
==================
|
||||
|
|
@ -147,21 +235,14 @@ Runtime Configuration
|
|||
---------------------
|
||||
|
||||
We want to be able to reconfigure vkms instance without having to reload the
|
||||
module. Use/Test-cases:
|
||||
module through configfs. Use/Test-cases:
|
||||
|
||||
- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling
|
||||
of compositors).
|
||||
|
||||
- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of
|
||||
them first).
|
||||
|
||||
- Change output configuration: Plug/unplug screens, change EDID, allow changing
|
||||
the refresh rate.
|
||||
|
||||
The currently proposed solution is to expose vkms configuration through
|
||||
configfs. All existing module options should be supported through configfs
|
||||
too.
|
||||
|
||||
Writeback support
|
||||
-----------------
|
||||
|
||||
|
|
|
|||
|
|
@ -605,6 +605,8 @@ operations:
|
|||
reply: &pin-attrs
|
||||
attributes:
|
||||
- id
|
||||
- module-name
|
||||
- clock-id
|
||||
- board-label
|
||||
- panel-label
|
||||
- package-label
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@ found on https://linux-ax25.in-berlin.de.
|
|||
|
||||
There is a mailing list for discussing Linux amateur radio matters
|
||||
called linux-hams@vger.kernel.org. To subscribe to it, send a message to
|
||||
majordomo@vger.kernel.org with the words "subscribe linux-hams" in the body
|
||||
of the message, the subject field is ignored. You don't need to be
|
||||
subscribed to post but of course that means you might miss an answer.
|
||||
linux-hams+subscribe@vger.kernel.org or use the web interface at
|
||||
https://vger.kernel.org. The subject and body of the message are
|
||||
ignored. You don't need to be subscribed to post but of course that
|
||||
means you might miss an answer.
|
||||
|
|
|
|||
|
|
@ -1398,10 +1398,9 @@ second bit timing has to be specified in order to enable the CAN FD bitrate.
|
|||
Additionally CAN FD capable CAN controllers support up to 64 bytes of
|
||||
payload. The representation of this length in can_frame.len and
|
||||
canfd_frame.len for userspace applications and inside the Linux network
|
||||
layer is a plain value from 0 .. 64 instead of the CAN 'data length code'.
|
||||
The data length code was a 1:1 mapping to the payload length in the Classical
|
||||
CAN frames anyway. The payload length to the bus-relevant DLC mapping is
|
||||
only performed inside the CAN drivers, preferably with the helper
|
||||
layer is a plain value from 0 .. 64 instead of the Classical CAN length
|
||||
which ranges from 0 to 8. The payload length to the bus-relevant DLC mapping
|
||||
is only performed inside the CAN drivers, preferably with the helper
|
||||
functions can_fd_dlc2len() and can_fd_len2dlc().
|
||||
|
||||
The CAN netdevice driver capabilities can be distinguished by the network
|
||||
|
|
@ -1465,6 +1464,70 @@ Example when 'fd-non-iso on' is added on this switchable CAN FD adapter::
|
|||
can <FD,FD-NON-ISO> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
|
||||
|
||||
|
||||
Transmitter Delay Compensation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
At high bit rates, the propagation delay from the TX pin to the RX pin of
|
||||
the transceiver might become greater than the actual bit time causing
|
||||
measurement errors: the RX pin would still be measuring the previous bit.
|
||||
|
||||
The Transmitter Delay Compensation (thereafter, TDC) resolves this problem
|
||||
by introducing a Secondary Sample Point (SSP) equal to the distance, in
|
||||
minimum time quantum, from the start of the bit time on the TX pin to the
|
||||
actual measurement on the RX pin. The SSP is calculated as the sum of two
|
||||
configurable values: the TDC Value (TDCV) and the TDC offset (TDCO).
|
||||
|
||||
TDC, if supported by the device, can be configured together with CAN-FD
|
||||
using the ip tool's "tdc-mode" argument as follow:
|
||||
|
||||
**omitted**
|
||||
When no "tdc-mode" option is provided, the kernel will automatically
|
||||
decide whether TDC should be turned on, in which case it will
|
||||
calculate a default TDCO and use the TDCV as measured by the
|
||||
device. This is the recommended method to use TDC.
|
||||
|
||||
**"tdc-mode off"**
|
||||
TDC is explicitly disabled.
|
||||
|
||||
**"tdc-mode auto"**
|
||||
The user must provide the "tdco" argument. The TDCV will be
|
||||
automatically calculated by the device. This option is only
|
||||
available if the device supports the TDC-AUTO CAN controller mode.
|
||||
|
||||
**"tdc-mode manual"**
|
||||
The user must provide both the "tdco" and "tdcv" arguments. This
|
||||
option is only available if the device supports the TDC-MANUAL CAN
|
||||
controller mode.
|
||||
|
||||
Note that some devices may offer an additional parameter: "tdcf" (TDC Filter
|
||||
window). If supported by your device, this can be added as an optional
|
||||
argument to either "tdc-mode auto" or "tdc-mode manual".
|
||||
|
||||
Example configuring a 500 kbit/s arbitration bitrate, a 5 Mbit/s data
|
||||
bitrate, a TDCO of 15 minimum time quantum and a TDCV automatically measured
|
||||
by the device::
|
||||
|
||||
$ ip link set can0 up type can bitrate 500000 \
|
||||
fd on dbitrate 4000000 \
|
||||
tdc-mode auto tdco 15
|
||||
$ ip -details link show can0
|
||||
5: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP \
|
||||
mode DEFAULT group default qlen 10
|
||||
link/can promiscuity 0 allmulti 0 minmtu 72 maxmtu 72
|
||||
can <FD,TDC-AUTO> state ERROR-ACTIVE restart-ms 0
|
||||
bitrate 500000 sample-point 0.875
|
||||
tq 12 prop-seg 69 phase-seg1 70 phase-seg2 20 sjw 10 brp 1
|
||||
ES582.1/ES584.1: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 \
|
||||
brp_inc 1
|
||||
dbitrate 4000000 dsample-point 0.750
|
||||
dtq 12 dprop-seg 7 dphase-seg1 7 dphase-seg2 5 dsjw 2 dbrp 1
|
||||
tdco 15 tdcf 0
|
||||
ES582.1/ES584.1: dtseg1 2..32 dtseg2 1..16 dsjw 1..8 dbrp 1..32 \
|
||||
dbrp_inc 1
|
||||
tdco 0..127 tdcf 0..127
|
||||
clock 80000000
|
||||
|
||||
|
||||
Supported CAN Hardware
|
||||
----------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -137,16 +137,20 @@ d. Checksum offload header v5
|
|||
|
||||
Checksum offload header fields are in big endian format.
|
||||
|
||||
Packet format::
|
||||
|
||||
Bit 0 - 6 7 8-15 16-31
|
||||
Function Header Type Next Header Checksum Valid Reserved
|
||||
|
||||
Header Type is to indicate the type of header, this usually is set to CHECKSUM
|
||||
|
||||
Header types
|
||||
= ==========================================
|
||||
|
||||
= ===============
|
||||
0 Reserved
|
||||
1 Reserved
|
||||
2 checksum header
|
||||
= ===============
|
||||
|
||||
Checksum Valid is to indicate whether the header checksum is valid. Value of 1
|
||||
implies that checksum is calculated on this packet and is valid, value of 0
|
||||
|
|
@ -183,9 +187,11 @@ rmnet in a single linear skb. rmnet will process the individual
|
|||
packets and either ACK the MAP command or deliver the IP packet to the
|
||||
network stack as needed
|
||||
|
||||
MAP header|IP Packet|Optional padding|MAP header|IP Packet|Optional padding....
|
||||
Packet format::
|
||||
|
||||
MAP header|IP Packet|Optional padding|MAP header|Command Packet|Optional pad...
|
||||
MAP header|IP Packet|Optional padding|MAP header|IP Packet|Optional padding....
|
||||
|
||||
MAP header|IP Packet|Optional padding|MAP header|Command Packet|Optional pad...
|
||||
|
||||
3. Userspace configuration
|
||||
==========================
|
||||
|
|
|
|||
|
|
@ -96,9 +96,8 @@ needed to these network configuration daemons to make sure that an IP is
|
|||
received only on the 'failover' device.
|
||||
|
||||
Below is the patch snippet used with 'cloud-ifupdown-helper' script found on
|
||||
Debian cloud images:
|
||||
Debian cloud images::
|
||||
|
||||
::
|
||||
@@ -27,6 +27,8 @@ do_setup() {
|
||||
local working="$cfgdir/.$INTERFACE"
|
||||
local final="$cfgdir/$INTERFACE"
|
||||
|
|
@ -172,9 +171,8 @@ appropriate FDB entry is added.
|
|||
|
||||
The following script is executed on the destination hypervisor once migration
|
||||
completes, and it reattaches the VF to the VM and brings down the virtio-net
|
||||
interface.
|
||||
interface::
|
||||
|
||||
::
|
||||
# reattach-vf.sh
|
||||
#!/bin/bash
|
||||
|
||||
|
|
|
|||
|
|
@ -19,9 +19,6 @@ Userdata append support by Matthew Wood <thepacketgeek@gmail.com>, Jan 22 2024
|
|||
|
||||
Sysdata append support by Breno Leitao <leitao@debian.org>, Jan 15 2025
|
||||
|
||||
Please send bug reports to Matt Mackall <mpm@selenic.com>
|
||||
Satyam Sharma <satyam.sharma@gmail.com>, and Cong Wang <xiyou.wangcong@gmail.com>
|
||||
|
||||
Introduction:
|
||||
=============
|
||||
|
||||
|
|
|
|||
|
|
@ -25,6 +25,9 @@ seg6_require_hmac - INTEGER
|
|||
|
||||
Default is 0.
|
||||
|
||||
/proc/sys/net/ipv6/seg6_* variables:
|
||||
====================================
|
||||
|
||||
seg6_flowlabel - INTEGER
|
||||
Controls the behaviour of computing the flowlabel of outer
|
||||
IPv6 header in case of SR T.encaps
|
||||
|
|
|
|||
|
|
@ -38,6 +38,81 @@ Like ``clang-format`` for the rest of the kernel, ``rustfmt`` works on
|
|||
individual files, and does not require a kernel configuration. Sometimes it may
|
||||
even work with broken code.
|
||||
|
||||
Imports
|
||||
~~~~~~~
|
||||
|
||||
``rustfmt``, by default, formats imports in a way that is prone to conflicts
|
||||
while merging and rebasing, since in some cases it condenses several items into
|
||||
the same line. For instance:
|
||||
|
||||
.. code-block:: rust
|
||||
|
||||
// Do not use this style.
|
||||
use crate::{
|
||||
example1,
|
||||
example2::{example3, example4, example5},
|
||||
example6, example7,
|
||||
example8::example9,
|
||||
};
|
||||
|
||||
Instead, the kernel uses a vertical layout that looks like this:
|
||||
|
||||
.. code-block:: rust
|
||||
|
||||
use crate::{
|
||||
example1,
|
||||
example2::{
|
||||
example3,
|
||||
example4,
|
||||
example5, //
|
||||
},
|
||||
example6,
|
||||
example7,
|
||||
example8::example9, //
|
||||
};
|
||||
|
||||
That is, each item goes into its own line, and braces are used as soon as there
|
||||
is more than one item in a list.
|
||||
|
||||
The trailing empty comment allows to preserve this formatting. Not only that,
|
||||
``rustfmt`` will actually reformat imports vertically when the empty comment is
|
||||
added. That is, it is possible to easily reformat the original example into the
|
||||
expected style by running ``rustfmt`` on an input like:
|
||||
|
||||
.. code-block:: rust
|
||||
|
||||
// Do not use this style.
|
||||
use crate::{
|
||||
example1,
|
||||
example2::{example3, example4, example5, //
|
||||
},
|
||||
example6, example7,
|
||||
example8::example9, //
|
||||
};
|
||||
|
||||
The trailing empty comment works for nested imports, as shown above, as well as
|
||||
for single item imports -- this can be useful to minimize diffs within patch
|
||||
series:
|
||||
|
||||
.. code-block:: rust
|
||||
|
||||
use crate::{
|
||||
example1, //
|
||||
};
|
||||
|
||||
The trailing empty comment works in any of the lines within the braces, but it
|
||||
is preferred to keep it in the last item, since it is reminiscent of the
|
||||
trailing comma in other formatters. Sometimes it may be simpler to avoid moving
|
||||
the comment several times within a patch series due to changes in the list.
|
||||
|
||||
There may be cases where exceptions may need to be made, i.e. none of this is
|
||||
a hard rule. There is also code that is not migrated to this style yet, but
|
||||
please do not introduce code in other styles.
|
||||
|
||||
Eventually, the goal is to get ``rustfmt`` to support this formatting style (or
|
||||
a similar one) automatically in a stable release without requiring the trailing
|
||||
empty comment. Thus, at some point, the goal is to remove those comments.
|
||||
|
||||
|
||||
Comments
|
||||
--------
|
||||
|
|
|
|||
|
|
@ -105,10 +105,10 @@ In this example the SSID is 10280c63.
|
|||
|
||||
The format of the firmware file names is:
|
||||
|
||||
SoundWire (except CS35L56 Rev B0):
|
||||
SoundWire:
|
||||
cs35lxx-b0-dsp1-misc-SSID[-spkidX]-l?u?
|
||||
|
||||
SoundWire CS35L56 Rev B0:
|
||||
SoundWire CS35L56 Rev B0 firmware released before kernel version 6.16:
|
||||
cs35lxx-b0-dsp1-misc-SSID[-spkidX]-ampN
|
||||
|
||||
Non-SoundWire (HDA and I2S):
|
||||
|
|
@ -127,9 +127,8 @@ Where:
|
|||
* spkidX is an optional part, used for laptops that have firmware
|
||||
configurations for different makes and models of internal speakers.
|
||||
|
||||
The CS35L56 Rev B0 continues to use the old filename scheme because a
|
||||
large number of firmware files have already been published with these
|
||||
names.
|
||||
Early firmware for CS35L56 Rev B0 used the ALSA prefix (ampN) as the
|
||||
filename qualifier. Support for the l?u? qualifier was added in kernel 6.16.
|
||||
|
||||
Sound Open Firmware and ALSA topology files
|
||||
-------------------------------------------
|
||||
|
|
|
|||
|
|
@ -16,13 +16,52 @@ following heaps:
|
|||
|
||||
- The ``system`` heap allocates virtually contiguous, cacheable, buffers.
|
||||
|
||||
- The ``cma`` heap allocates physically contiguous, cacheable,
|
||||
buffers. Only present if a CMA region is present. Such a region is
|
||||
usually created either through the kernel commandline through the
|
||||
``cma`` parameter, a memory region Device-Tree node with the
|
||||
``linux,cma-default`` property set, or through the ``CMA_SIZE_MBYTES`` or
|
||||
``CMA_SIZE_PERCENTAGE`` Kconfig options. The heap's name in devtmpfs is
|
||||
``default_cma_region``. For backwards compatibility, when the
|
||||
``DMABUF_HEAPS_CMA_LEGACY`` Kconfig option is set, a duplicate node is
|
||||
created following legacy naming conventions; the legacy name might be
|
||||
``reserved``, ``linux,cma``, or ``default-pool``.
|
||||
- The ``default_cma_region`` heap allocates physically contiguous,
|
||||
cacheable, buffers. Only present if a CMA region is present. Such a
|
||||
region is usually created either through the kernel commandline
|
||||
through the ``cma`` parameter, a memory region Device-Tree node with
|
||||
the ``linux,cma-default`` property set, or through the
|
||||
``CMA_SIZE_MBYTES`` or ``CMA_SIZE_PERCENTAGE`` Kconfig options. Prior
|
||||
to Linux 6.17, its name wasn't stable and could be called
|
||||
``reserved``, ``linux,cma``, or ``default-pool``, depending on the
|
||||
platform.
|
||||
|
||||
- A heap will be created for each reusable region in the device tree
|
||||
with the ``shared-dma-pool`` compatible, using the full device tree
|
||||
node name as its name. The buffer semantics are identical to
|
||||
``default-cma-region``.
|
||||
|
||||
Naming Convention
|
||||
=================
|
||||
|
||||
``dma-buf`` heaps name should meet a number of constraints:
|
||||
|
||||
- The name must be stable, and must not change from one version to the other.
|
||||
Userspace identifies heaps by their name, so if the names ever change, we
|
||||
would be likely to introduce regressions.
|
||||
|
||||
- The name must describe the memory region the heap will allocate from, and
|
||||
must uniquely identify it in a given platform. Since userspace applications
|
||||
use the heap name as the discriminant, it must be able to tell which heap it
|
||||
wants to use reliably if there's multiple heaps.
|
||||
|
||||
- The name must not mention implementation details, such as the allocator. The
|
||||
heap driver will change over time, and implementation details when it was
|
||||
introduced might not be relevant in the future.
|
||||
|
||||
- The name should describe properties of the buffers that would be allocated.
|
||||
Doing so will make heap identification easier for userspace. Such properties
|
||||
are:
|
||||
|
||||
- ``contiguous`` for physically contiguous buffers;
|
||||
|
||||
- ``protected`` for encrypted buffers not accessible the OS;
|
||||
|
||||
- The name may describe intended usage. Doing so will make heap identification
|
||||
easier for userspace applications and users.
|
||||
|
||||
For example, assuming a platform with a reserved memory region located
|
||||
at the RAM address 0x42000000, intended to allocate video framebuffers,
|
||||
physically contiguous, and backed by the CMA kernel allocator, good
|
||||
names would be ``memory@42000000-contiguous`` or ``video@42000000``, but
|
||||
``cma-video`` wouldn't.
|
||||
|
|
|
|||
|
|
@ -13,10 +13,10 @@ Simple CLI
|
|||
Kernel comes with a simple CLI tool which should be useful when
|
||||
developing Netlink related code. The tool is implemented in Python
|
||||
and can use a YAML specification to issue Netlink requests
|
||||
to the kernel. Only Generic Netlink is supported.
|
||||
to the kernel.
|
||||
|
||||
The tool is located at ``tools/net/ynl/pyynl/cli.py``. It accepts
|
||||
a handul of arguments, the most important ones are:
|
||||
a handful of arguments, the most important ones are:
|
||||
|
||||
- ``--spec`` - point to the spec file
|
||||
- ``--do $name`` / ``--dump $name`` - issue request ``$name``
|
||||
|
|
|
|||
|
|
@ -1229,6 +1229,9 @@ It is not possible to read back a pending external abort (injected via
|
|||
KVM_SET_VCPU_EVENTS or otherwise) because such an exception is always delivered
|
||||
directly to the virtual CPU).
|
||||
|
||||
Calling this ioctl on a vCPU that hasn't been initialized will return
|
||||
-ENOEXEC.
|
||||
|
||||
::
|
||||
|
||||
struct kvm_vcpu_events {
|
||||
|
|
@ -1309,6 +1312,8 @@ exceptions by manipulating individual registers using the KVM_SET_ONE_REG API.
|
|||
|
||||
See KVM_GET_VCPU_EVENTS for the data structure.
|
||||
|
||||
Calling this ioctl on a vCPU that hasn't been initialized will return
|
||||
-ENOEXEC.
|
||||
|
||||
4.33 KVM_GET_DEBUGREGS
|
||||
----------------------
|
||||
|
|
@ -6432,9 +6437,18 @@ most one mapping per page, i.e. binding multiple memory regions to a single
|
|||
guest_memfd range is not allowed (any number of memory regions can be bound to
|
||||
a single guest_memfd file, but the bound ranges must not overlap).
|
||||
|
||||
When the capability KVM_CAP_GUEST_MEMFD_MMAP is supported, the 'flags' field
|
||||
supports GUEST_MEMFD_FLAG_MMAP. Setting this flag on guest_memfd creation
|
||||
enables mmap() and faulting of guest_memfd memory to host userspace.
|
||||
The capability KVM_CAP_GUEST_MEMFD_FLAGS enumerates the `flags` that can be
|
||||
specified via KVM_CREATE_GUEST_MEMFD. Currently defined flags:
|
||||
|
||||
============================ ================================================
|
||||
GUEST_MEMFD_FLAG_MMAP Enable using mmap() on the guest_memfd file
|
||||
descriptor.
|
||||
GUEST_MEMFD_FLAG_INIT_SHARED Make all memory in the file shared during
|
||||
KVM_CREATE_GUEST_MEMFD (memory files created
|
||||
without INIT_SHARED will be marked private).
|
||||
Shared memory can be faulted into host userspace
|
||||
page tables. Private memory cannot.
|
||||
============================ ================================================
|
||||
|
||||
When the KVM MMU performs a PFN lookup to service a guest fault and the backing
|
||||
guest_memfd has the GUEST_MEMFD_FLAG_MMAP set, then the fault will always be
|
||||
|
|
|
|||
|
|
@ -13,7 +13,8 @@ will act as the VM interrupt controller, requiring emulated user-space devices
|
|||
to inject interrupts to the VGIC instead of directly to CPUs. It is not
|
||||
possible to create both a GICv3 and GICv2 on the same VM.
|
||||
|
||||
Creating a guest GICv3 device requires a host GICv3 as well.
|
||||
Creating a guest GICv3 device requires a host GICv3 host, or a GICv5 host with
|
||||
support for FEAT_GCIE_LEGACY.
|
||||
|
||||
|
||||
Groups:
|
||||
|
|
|
|||
140
MAINTAINERS
140
MAINTAINERS
|
|
@ -915,6 +915,7 @@ F: drivers/staging/media/sunxi/cedrus/
|
|||
ALPHA PORT
|
||||
M: Richard Henderson <richard.henderson@linaro.org>
|
||||
M: Matt Turner <mattst88@gmail.com>
|
||||
M: Magnus Lindholm <linmag7@gmail.com>
|
||||
L: linux-alpha@vger.kernel.org
|
||||
S: Odd Fixes
|
||||
F: arch/alpha/
|
||||
|
|
@ -1080,7 +1081,7 @@ M: Austin Zheng <austin.zheng@amd.com>
|
|||
M: Jun Lei <jun.lei@amd.com>
|
||||
S: Supported
|
||||
F: drivers/gpu/drm/amd/display/dc/dml/
|
||||
F: drivers/gpu/drm/amd/display/dc/dml2/
|
||||
F: drivers/gpu/drm/amd/display/dc/dml2_0/
|
||||
|
||||
AMD FAM15H PROCESSOR POWER MONITORING DRIVER
|
||||
M: Huang Rui <ray.huang@amd.com>
|
||||
|
|
@ -1997,6 +1998,10 @@ F: include/uapi/linux/if_arcnet.h
|
|||
|
||||
ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
|
||||
M: Arnd Bergmann <arnd@arndb.de>
|
||||
M: Krzysztof Kozlowski <krzk@kernel.org>
|
||||
M: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
||||
M: Linus Walleij <linus.walleij@linaro.org>
|
||||
R: Drew Fustini <fustini@kernel.org>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: soc@lists.linux.dev
|
||||
S: Maintained
|
||||
|
|
@ -2017,6 +2022,15 @@ F: arch/arm64/include/asm/arch_timer.h
|
|||
F: drivers/clocksource/arm_arch_timer.c
|
||||
F: drivers/clocksource/arm_arch_timer_mmio.c
|
||||
|
||||
ARM ETHOS-U NPU DRIVER
|
||||
M: Rob Herring (Arm) <robh@kernel.org>
|
||||
M: Tomeu Vizoso <tomeu@tomeuvizoso.net>
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
S: Supported
|
||||
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
||||
F: drivers/accel/ethosu/
|
||||
F: include/uapi/drm/ethosu_accel.h
|
||||
|
||||
ARM GENERIC INTERRUPT CONTROLLER DRIVERS
|
||||
M: Marc Zyngier <maz@kernel.org>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
|
|
@ -2092,7 +2106,8 @@ F: drivers/gpu/drm/arm/display/komeda/
|
|||
ARM MALI PANFROST DRM DRIVER
|
||||
M: Boris Brezillon <boris.brezillon@collabora.com>
|
||||
M: Rob Herring <robh@kernel.org>
|
||||
R: Steven Price <steven.price@arm.com>
|
||||
M: Steven Price <steven.price@arm.com>
|
||||
M: Adrián Larumbe <adrian.larumbe@collabora.com>
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
S: Supported
|
||||
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
||||
|
|
@ -2298,7 +2313,7 @@ S: Maintained
|
|||
F: drivers/clk/sunxi/
|
||||
|
||||
ARM/Allwinner sunXi SoC support
|
||||
M: Chen-Yu Tsai <wens@csie.org>
|
||||
M: Chen-Yu Tsai <wens@kernel.org>
|
||||
M: Jernej Skrabec <jernej.skrabec@gmail.com>
|
||||
M: Samuel Holland <samuel@sholland.org>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
|
|
@ -3841,6 +3856,7 @@ F: drivers/hwmon/asus-ec-sensors.c
|
|||
ASUS NOTEBOOKS AND EEEPC ACPI/WMI EXTRAS DRIVERS
|
||||
M: Corentin Chary <corentin.chary@gmail.com>
|
||||
M: Luke D. Jones <luke@ljones.dev>
|
||||
M: Denis Benato <benato.denis96@gmail.com>
|
||||
L: platform-driver-x86@vger.kernel.org
|
||||
S: Maintained
|
||||
W: https://asus-linux.org/
|
||||
|
|
@ -4393,7 +4409,7 @@ BLOCK LAYER
|
|||
M: Jens Axboe <axboe@kernel.dk>
|
||||
L: linux-block@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git
|
||||
F: Documentation/ABI/stable/sysfs-block
|
||||
F: Documentation/block/
|
||||
F: block/
|
||||
|
|
@ -4804,6 +4820,7 @@ F: drivers/net/ethernet/broadcom/b44.*
|
|||
|
||||
BROADCOM B53/SF2 ETHERNET SWITCH DRIVER
|
||||
M: Florian Fainelli <florian.fainelli@broadcom.com>
|
||||
M: Jonas Gorski <jonas.gorski@gmail.com>
|
||||
L: netdev@vger.kernel.org
|
||||
L: openwrt-devel@lists.openwrt.org (subscribers-only)
|
||||
S: Supported
|
||||
|
|
@ -4812,6 +4829,7 @@ F: drivers/net/dsa/b53/*
|
|||
F: drivers/net/dsa/bcm_sf2*
|
||||
F: include/linux/dsa/brcm.h
|
||||
F: include/linux/platform_data/b53.h
|
||||
F: net/dsa/tag_brcm.c
|
||||
|
||||
BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
|
||||
M: Florian Fainelli <florian.fainelli@broadcom.com>
|
||||
|
|
@ -7308,6 +7326,7 @@ F: Documentation/userspace-api/dma-buf-alloc-exchange.rst
|
|||
F: drivers/dma-buf/
|
||||
F: include/linux/*fence.h
|
||||
F: include/linux/dma-buf.h
|
||||
F: include/linux/dma-buf/
|
||||
F: include/linux/dma-resv.h
|
||||
K: \bdma_(?:buf|fence|resv)\b
|
||||
|
||||
|
|
@ -7636,8 +7655,7 @@ F: drivers/accel/
|
|||
F: include/drm/drm_accel.h
|
||||
|
||||
DRM DRIVER FOR ALLWINNER DE2 AND DE3 ENGINE
|
||||
M: Maxime Ripard <mripard@kernel.org>
|
||||
M: Chen-Yu Tsai <wens@csie.org>
|
||||
M: Chen-Yu Tsai <wens@kernel.org>
|
||||
R: Jernej Skrabec <jernej.skrabec@gmail.com>
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
S: Supported
|
||||
|
|
@ -7746,7 +7764,8 @@ F: Documentation/devicetree/bindings/display/panel/panel-edp.yaml
|
|||
F: drivers/gpu/drm/panel/panel-edp.c
|
||||
|
||||
DRM DRIVER FOR GENERIC USB DISPLAY
|
||||
S: Orphan
|
||||
M: Ruben Wauters <rubenru09@aol.com>
|
||||
S: Maintained
|
||||
W: https://github.com/notro/gud/wiki
|
||||
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
||||
F: drivers/gpu/drm/gud/
|
||||
|
|
@ -7868,6 +7887,7 @@ DRM DRIVER for Qualcomm Adreno GPUs
|
|||
M: Rob Clark <robin.clark@oss.qualcomm.com>
|
||||
R: Sean Paul <sean@poorly.run>
|
||||
R: Konrad Dybcio <konradybcio@kernel.org>
|
||||
R: Akhil P Oommen <akhilpo@oss.qualcomm.com>
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
L: freedreno@lists.freedesktop.org
|
||||
|
|
@ -7887,7 +7907,7 @@ DRM DRIVER for Qualcomm display hardware
|
|||
M: Rob Clark <robin.clark@oss.qualcomm.com>
|
||||
M: Dmitry Baryshkov <lumag@kernel.org>
|
||||
R: Abhinav Kumar <abhinav.kumar@linux.dev>
|
||||
R: Jessica Zhang <jessica.zhang@oss.qualcomm.com>
|
||||
R: Jessica Zhang <jesszhan0024@gmail.com>
|
||||
R: Sean Paul <sean@poorly.run>
|
||||
R: Marijn Suijten <marijn.suijten@somainline.org>
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
|
|
@ -8056,12 +8076,25 @@ S: Maintained
|
|||
F: Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml
|
||||
F: drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
|
||||
|
||||
DRM DRIVER FOR SAMSUNG S6E3FC2X01 DDIC
|
||||
M: David Heidelberg <david@ixit.cz>
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/display/panel/samsung,s6e3fc2x01.yaml
|
||||
F: drivers/gpu/drm/panel/panel-samsung-s6e3fc2x01.c
|
||||
|
||||
DRM DRIVER FOR SAMSUNG S6E3HA8 PANELS
|
||||
M: Dzmitry Sankouski <dsankouski@gmail.com>
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/display/panel/samsung,s6e3ha8.yaml
|
||||
F: drivers/gpu/drm/panel/panel-samsung-s6e3ha8.c
|
||||
|
||||
DRM DRIVER FOR SAMSUNG SOFEF00 DDIC
|
||||
M: David Heidelberg <david@ixit.cz>
|
||||
M: Casey Connolly <casey.connolly@linaro.org>
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/display/panel/samsung,sofef00.yaml
|
||||
F: drivers/gpu/drm/panel/panel-samsung-sofef00.c
|
||||
|
||||
DRM DRIVER FOR SHARP MEMORY LCD
|
||||
M: Alex Lanzano <lanzano.alex@gmail.com>
|
||||
S: Maintained
|
||||
|
|
@ -8246,12 +8279,12 @@ S: Supported
|
|||
W: https://drm.pages.freedesktop.org/maintainer-tools/drm-rust.html
|
||||
T: git https://gitlab.freedesktop.org/drm/rust/kernel.git
|
||||
F: drivers/gpu/drm/nova/
|
||||
F: drivers/gpu/drm/tyr/
|
||||
F: drivers/gpu/nova-core/
|
||||
F: rust/kernel/drm/
|
||||
|
||||
DRM DRIVERS FOR ALLWINNER A10
|
||||
M: Maxime Ripard <mripard@kernel.org>
|
||||
M: Chen-Yu Tsai <wens@csie.org>
|
||||
M: Chen-Yu Tsai <wens@kernel.org>
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
S: Supported
|
||||
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
||||
|
|
@ -8578,6 +8611,7 @@ S: Supported
|
|||
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
||||
F: drivers/gpu/drm/scheduler/
|
||||
F: include/drm/gpu_scheduler.h
|
||||
F: include/drm/spsc_queue.h
|
||||
|
||||
DRM GPUVM
|
||||
M: Danilo Krummrich <dakr@kernel.org>
|
||||
|
|
@ -8600,7 +8634,7 @@ F: drivers/gpu/drm/clients/drm_log.c
|
|||
|
||||
DRM PANEL DRIVERS
|
||||
M: Neil Armstrong <neil.armstrong@linaro.org>
|
||||
R: Jessica Zhang <jessica.zhang@oss.qualcomm.com>
|
||||
R: Jessica Zhang <jesszhan0024@gmail.com>
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
S: Maintained
|
||||
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
||||
|
|
@ -9201,6 +9235,7 @@ R: Yue Hu <zbestahu@gmail.com>
|
|||
R: Jeffle Xu <jefflexu@linux.alibaba.com>
|
||||
R: Sandeep Dhavale <dhavale@google.com>
|
||||
R: Hongbo Li <lihongbo22@huawei.com>
|
||||
R: Chunhai Guo <guochunhai@vivo.com>
|
||||
L: linux-erofs@lists.ozlabs.org
|
||||
S: Maintained
|
||||
W: https://erofs.docs.kernel.org
|
||||
|
|
@ -11519,7 +11554,7 @@ F: include/linux/platform_data/huawei-gaokun-ec.h
|
|||
HUGETLB SUBSYSTEM
|
||||
M: Muchun Song <muchun.song@linux.dev>
|
||||
M: Oscar Salvador <osalvador@suse.de>
|
||||
R: David Hildenbrand <david@redhat.com>
|
||||
R: David Hildenbrand <david@kernel.org>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
F: Documentation/ABI/testing/sysfs-kernel-mm-hugepages
|
||||
|
|
@ -12514,6 +12549,7 @@ F: include/linux/avf/virtchnl.h
|
|||
F: include/linux/net/intel/*/
|
||||
|
||||
INTEL ETHERNET PROTOCOL DRIVER FOR RDMA
|
||||
M: Krzysztof Czurylo <krzysztof.czurylo@intel.com>
|
||||
M: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
|
||||
L: linux-rdma@vger.kernel.org
|
||||
S: Supported
|
||||
|
|
@ -12854,7 +12890,8 @@ F: tools/testing/selftests/sgx/*
|
|||
K: \bSGX_
|
||||
|
||||
INTEL SKYLAKE INT3472 ACPI DEVICE DRIVER
|
||||
M: Daniel Scally <djrscally@gmail.com>
|
||||
M: Daniel Scally <dan.scally@ideasonboard.com>
|
||||
M: Sakari Ailus <sakari.ailus@linux.intel.com>
|
||||
S: Maintained
|
||||
F: drivers/platform/x86/intel/int3472/
|
||||
F: include/linux/platform_data/x86/int3472.h
|
||||
|
|
@ -13109,6 +13146,15 @@ F: include/uapi/linux/io_uring.h
|
|||
F: include/uapi/linux/io_uring/
|
||||
F: io_uring/
|
||||
|
||||
IO_URING ZCRX
|
||||
M: Pavel Begunkov <asml.silence@gmail.com>
|
||||
L: io-uring@vger.kernel.org
|
||||
L: netdev@vger.kernel.org
|
||||
T: git https://github.com/isilence/linux.git zcrx/for-next
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git
|
||||
S: Maintained
|
||||
F: io_uring/zcrx.*
|
||||
|
||||
IPMI SUBSYSTEM
|
||||
M: Corey Minyard <corey@minyard.net>
|
||||
L: openipmi-developer@lists.sourceforge.net (moderated for non-subscribers)
|
||||
|
|
@ -13244,10 +13290,8 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git mast
|
|||
F: drivers/infiniband/ulp/isert
|
||||
|
||||
ISDN/CMTP OVER BLUETOOTH
|
||||
M: Karsten Keil <isdn@linux-pingi.de>
|
||||
L: isdn4linux@listserv.isdn4linux.de (subscribers-only)
|
||||
L: netdev@vger.kernel.org
|
||||
S: Odd Fixes
|
||||
S: Orphan
|
||||
W: http://www.isdn4linux.de
|
||||
F: Documentation/isdn/
|
||||
F: drivers/isdn/capi/
|
||||
|
|
@ -13256,10 +13300,8 @@ F: include/uapi/linux/isdn/
|
|||
F: net/bluetooth/cmtp/
|
||||
|
||||
ISDN/mISDN SUBSYSTEM
|
||||
M: Karsten Keil <isdn@linux-pingi.de>
|
||||
L: isdn4linux@listserv.isdn4linux.de (subscribers-only)
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
S: Orphan
|
||||
W: http://www.isdn4linux.de
|
||||
F: drivers/isdn/Kconfig
|
||||
F: drivers/isdn/Makefile
|
||||
|
|
@ -13413,9 +13455,12 @@ F: mm/kasan/
|
|||
F: scripts/Makefile.kasan
|
||||
|
||||
KCONFIG
|
||||
M: Nathan Chancellor <nathan@kernel.org>
|
||||
M: Nicolas Schier <nsc@kernel.org>
|
||||
L: linux-kbuild@vger.kernel.org
|
||||
S: Orphan
|
||||
S: Odd Fixes
|
||||
Q: https://patchwork.kernel.org/project/linux-kbuild/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux.git
|
||||
F: Documentation/kbuild/kconfig*
|
||||
F: scripts/Kconfig.include
|
||||
F: scripts/kconfig/
|
||||
|
|
@ -13600,7 +13645,7 @@ F: fs/smb/server/
|
|||
KERNEL UNIT TESTING FRAMEWORK (KUnit)
|
||||
M: Brendan Higgins <brendan.higgins@linux.dev>
|
||||
M: David Gow <davidgow@google.com>
|
||||
R: Rae Moar <rmoar@google.com>
|
||||
R: Rae Moar <raemoar63@gmail.com>
|
||||
L: linux-kselftest@vger.kernel.org
|
||||
L: kunit-dev@googlegroups.com
|
||||
S: Maintained
|
||||
|
|
@ -13641,7 +13686,7 @@ F: virt/kvm/*
|
|||
|
||||
KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)
|
||||
M: Marc Zyngier <maz@kernel.org>
|
||||
M: Oliver Upton <oliver.upton@linux.dev>
|
||||
M: Oliver Upton <oupton@kernel.org>
|
||||
R: Joey Gouly <joey.gouly@arm.com>
|
||||
R: Suzuki K Poulose <suzuki.poulose@arm.com>
|
||||
R: Zenghui Yu <yuzenghui@huawei.com>
|
||||
|
|
@ -13715,7 +13760,7 @@ KERNEL VIRTUAL MACHINE for s390 (KVM/s390)
|
|||
M: Christian Borntraeger <borntraeger@linux.ibm.com>
|
||||
M: Janosch Frank <frankja@linux.ibm.com>
|
||||
M: Claudio Imbrenda <imbrenda@linux.ibm.com>
|
||||
R: David Hildenbrand <david@redhat.com>
|
||||
R: David Hildenbrand <david@kernel.org>
|
||||
L: kvm@vger.kernel.org
|
||||
S: Supported
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git
|
||||
|
|
@ -14392,6 +14437,7 @@ F: tools/memory-model/
|
|||
|
||||
LINUX-NEXT TREE
|
||||
M: Stephen Rothwell <sfr@canb.auug.org.au>
|
||||
M: Mark Brown <broonie@kernel.org>
|
||||
L: linux-next@vger.kernel.org
|
||||
S: Supported
|
||||
B: mailto:linux-next@vger.kernel.org and the appropriate development tree
|
||||
|
|
@ -16201,7 +16247,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git
|
|||
F: drivers/devfreq/tegra30-devfreq.c
|
||||
|
||||
MEMORY HOT(UN)PLUG
|
||||
M: David Hildenbrand <david@redhat.com>
|
||||
M: David Hildenbrand <david@kernel.org>
|
||||
M: Oscar Salvador <osalvador@suse.de>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
|
|
@ -16226,7 +16272,7 @@ F: tools/mm/
|
|||
|
||||
MEMORY MANAGEMENT - CORE
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: David Hildenbrand <david@redhat.com>
|
||||
M: David Hildenbrand <david@kernel.org>
|
||||
R: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
||||
R: Liam R. Howlett <Liam.Howlett@oracle.com>
|
||||
R: Vlastimil Babka <vbabka@suse.cz>
|
||||
|
|
@ -16282,7 +16328,7 @@ F: mm/execmem.c
|
|||
|
||||
MEMORY MANAGEMENT - GUP (GET USER PAGES)
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: David Hildenbrand <david@redhat.com>
|
||||
M: David Hildenbrand <david@kernel.org>
|
||||
R: Jason Gunthorpe <jgg@nvidia.com>
|
||||
R: John Hubbard <jhubbard@nvidia.com>
|
||||
R: Peter Xu <peterx@redhat.com>
|
||||
|
|
@ -16298,7 +16344,7 @@ F: tools/testing/selftests/mm/gup_test.c
|
|||
|
||||
MEMORY MANAGEMENT - KSM (Kernel Samepage Merging)
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: David Hildenbrand <david@redhat.com>
|
||||
M: David Hildenbrand <david@kernel.org>
|
||||
R: Xu Xin <xu.xin16@zte.com.cn>
|
||||
R: Chengming Zhou <chengming.zhou@linux.dev>
|
||||
L: linux-mm@kvack.org
|
||||
|
|
@ -16314,7 +16360,7 @@ F: mm/mm_slot.h
|
|||
|
||||
MEMORY MANAGEMENT - MEMORY POLICY AND MIGRATION
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: David Hildenbrand <david@redhat.com>
|
||||
M: David Hildenbrand <david@kernel.org>
|
||||
R: Zi Yan <ziy@nvidia.com>
|
||||
R: Matthew Brost <matthew.brost@intel.com>
|
||||
R: Joshua Hahn <joshua.hahnjy@gmail.com>
|
||||
|
|
@ -16354,7 +16400,7 @@ F: mm/workingset.c
|
|||
|
||||
MEMORY MANAGEMENT - MISC
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: David Hildenbrand <david@redhat.com>
|
||||
M: David Hildenbrand <david@kernel.org>
|
||||
R: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
||||
R: Liam R. Howlett <Liam.Howlett@oracle.com>
|
||||
R: Vlastimil Babka <vbabka@suse.cz>
|
||||
|
|
@ -16442,7 +16488,7 @@ F: mm/shuffle.h
|
|||
MEMORY MANAGEMENT - RECLAIM
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: Johannes Weiner <hannes@cmpxchg.org>
|
||||
R: David Hildenbrand <david@redhat.com>
|
||||
R: David Hildenbrand <david@kernel.org>
|
||||
R: Michal Hocko <mhocko@kernel.org>
|
||||
R: Qi Zheng <zhengqi.arch@bytedance.com>
|
||||
R: Shakeel Butt <shakeel.butt@linux.dev>
|
||||
|
|
@ -16455,7 +16501,7 @@ F: mm/workingset.c
|
|||
|
||||
MEMORY MANAGEMENT - RMAP (REVERSE MAPPING)
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: David Hildenbrand <david@redhat.com>
|
||||
M: David Hildenbrand <david@kernel.org>
|
||||
M: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
||||
R: Rik van Riel <riel@surriel.com>
|
||||
R: Liam R. Howlett <Liam.Howlett@oracle.com>
|
||||
|
|
@ -16479,12 +16525,12 @@ F: mm/secretmem.c
|
|||
|
||||
MEMORY MANAGEMENT - SWAP
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: Chris Li <chrisl@kernel.org>
|
||||
M: Kairui Song <kasong@tencent.com>
|
||||
R: Kemeng Shi <shikemeng@huaweicloud.com>
|
||||
R: Kairui Song <kasong@tencent.com>
|
||||
R: Nhat Pham <nphamcs@gmail.com>
|
||||
R: Baoquan He <bhe@redhat.com>
|
||||
R: Barry Song <baohua@kernel.org>
|
||||
R: Chris Li <chrisl@kernel.org>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
F: Documentation/mm/swap-table.rst
|
||||
|
|
@ -16500,7 +16546,7 @@ F: mm/swapfile.c
|
|||
|
||||
MEMORY MANAGEMENT - THP (TRANSPARENT HUGE PAGE)
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: David Hildenbrand <david@redhat.com>
|
||||
M: David Hildenbrand <david@kernel.org>
|
||||
M: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
||||
R: Zi Yan <ziy@nvidia.com>
|
||||
R: Baolin Wang <baolin.wang@linux.alibaba.com>
|
||||
|
|
@ -16602,7 +16648,7 @@ MEMORY MAPPING - MADVISE (MEMORY ADVICE)
|
|||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: Liam R. Howlett <Liam.Howlett@oracle.com>
|
||||
M: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
||||
M: David Hildenbrand <david@redhat.com>
|
||||
M: David Hildenbrand <david@kernel.org>
|
||||
R: Vlastimil Babka <vbabka@suse.cz>
|
||||
R: Jann Horn <jannh@google.com>
|
||||
L: linux-mm@kvack.org
|
||||
|
|
@ -18012,6 +18058,16 @@ X: net/rfkill/
|
|||
X: net/wireless/
|
||||
X: tools/testing/selftests/net/can/
|
||||
|
||||
NETWORKING [IOAM]
|
||||
M: Justin Iurman <justin.iurman@uliege.be>
|
||||
S: Maintained
|
||||
F: Documentation/networking/ioam6*
|
||||
F: include/linux/ioam6*
|
||||
F: include/net/ioam6*
|
||||
F: include/uapi/linux/ioam6*
|
||||
F: net/ipv6/ioam6*
|
||||
F: tools/testing/selftests/net/ioam6*
|
||||
|
||||
NETWORKING [IPSEC]
|
||||
M: Steffen Klassert <steffen.klassert@secunet.com>
|
||||
M: Herbert Xu <herbert@gondor.apana.org.au>
|
||||
|
|
@ -20134,6 +20190,7 @@ R: Alexander Shishkin <alexander.shishkin@linux.intel.com>
|
|||
R: Jiri Olsa <jolsa@kernel.org>
|
||||
R: Ian Rogers <irogers@google.com>
|
||||
R: Adrian Hunter <adrian.hunter@intel.com>
|
||||
R: James Clark <james.clark@linaro.org>
|
||||
L: linux-perf-users@vger.kernel.org
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Supported
|
||||
|
|
@ -21305,6 +21362,7 @@ F: drivers/media/platform/qcom/venus/
|
|||
QUALCOMM WCN36XX WIRELESS DRIVER
|
||||
M: Loic Poulain <loic.poulain@oss.qualcomm.com>
|
||||
L: wcn36xx@lists.infradead.org
|
||||
L: linux-wireless@vger.kernel.org
|
||||
S: Supported
|
||||
W: https://wireless.wiki.kernel.org/en/users/Drivers/wcn36xx
|
||||
F: drivers/net/wireless/ath/wcn36xx/
|
||||
|
|
@ -26873,7 +26931,7 @@ S: Maintained
|
|||
F: drivers/vfio/cdx/*
|
||||
|
||||
VFIO DRIVER
|
||||
M: Alex Williamson <alex.williamson@redhat.com>
|
||||
M: Alex Williamson <alex@shazbot.org>
|
||||
L: kvm@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git https://github.com/awilliam/linux-vfio.git
|
||||
|
|
@ -27043,7 +27101,7 @@ T: git git://linuxtv.org/media.git
|
|||
F: drivers/media/test-drivers/vimc/*
|
||||
|
||||
VIRT LIB
|
||||
M: Alex Williamson <alex.williamson@redhat.com>
|
||||
M: Alex Williamson <alex@shazbot.org>
|
||||
M: Paolo Bonzini <pbonzini@redhat.com>
|
||||
L: kvm@vger.kernel.org
|
||||
S: Supported
|
||||
|
|
@ -27064,7 +27122,7 @@ F: net/vmw_vsock/virtio_transport_common.c
|
|||
|
||||
VIRTIO BALLOON
|
||||
M: "Michael S. Tsirkin" <mst@redhat.com>
|
||||
M: David Hildenbrand <david@redhat.com>
|
||||
M: David Hildenbrand <david@kernel.org>
|
||||
L: virtualization@lists.linux.dev
|
||||
S: Maintained
|
||||
F: drivers/virtio/virtio_balloon.c
|
||||
|
|
@ -27219,7 +27277,7 @@ F: drivers/iommu/virtio-iommu.c
|
|||
F: include/uapi/linux/virtio_iommu.h
|
||||
|
||||
VIRTIO MEM DRIVER
|
||||
M: David Hildenbrand <david@redhat.com>
|
||||
M: David Hildenbrand <david@kernel.org>
|
||||
L: virtualization@lists.linux.dev
|
||||
S: Maintained
|
||||
W: https://virtio-mem.gitlab.io/
|
||||
|
|
@ -27701,7 +27759,7 @@ F: drivers/acpi/pmic/intel_pmic_xpower.c
|
|||
N: axp288
|
||||
|
||||
X-POWERS MULTIFUNCTION PMIC DEVICE DRIVERS
|
||||
M: Chen-Yu Tsai <wens@csie.org>
|
||||
M: Chen-Yu Tsai <wens@kernel.org>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
N: axp[128]
|
||||
|
|
@ -27825,7 +27883,7 @@ F: arch/x86/kernel/stacktrace.c
|
|||
F: arch/x86/kernel/unwind_*.c
|
||||
|
||||
X86 TRUST DOMAIN EXTENSIONS (TDX)
|
||||
M: Kirill A. Shutemov <kas@kernel.org>
|
||||
M: Kiryl Shutsemau <kas@kernel.org>
|
||||
R: Dave Hansen <dave.hansen@linux.intel.com>
|
||||
R: Rick Edgecombe <rick.p.edgecombe@intel.com>
|
||||
L: x86@kernel.org
|
||||
|
|
|
|||
2
Makefile
2
Makefile
|
|
@ -2,7 +2,7 @@
|
|||
VERSION = 6
|
||||
PATCHLEVEL = 18
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc1
|
||||
EXTRAVERSION = -rc6
|
||||
NAME = Baby Opossum Posse
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
|
|
|||
|
|
@ -917,6 +917,13 @@ config ARCH_USES_CFI_TRAPS
|
|||
An architecture should select this option if it requires the
|
||||
.kcfi_traps section for KCFI trap handling.
|
||||
|
||||
config ARCH_USES_CFI_GENERIC_LLVM_PASS
|
||||
bool
|
||||
help
|
||||
An architecture should select this option if it uses the generic
|
||||
KCFIPass in LLVM to expand kCFI bundles instead of architecture-specific
|
||||
lowering.
|
||||
|
||||
config CFI
|
||||
bool "Use Kernel Control Flow Integrity (kCFI)"
|
||||
default CFI_CLANG
|
||||
|
|
@ -965,6 +972,7 @@ config HAVE_CFI_ICALL_NORMALIZE_INTEGERS_RUSTC
|
|||
def_bool y
|
||||
depends on HAVE_CFI_ICALL_NORMALIZE_INTEGERS
|
||||
depends on RUSTC_VERSION >= 107900
|
||||
depends on ARM64 || X86_64
|
||||
# With GCOV/KASAN we need this fix: https://github.com/rust-lang/rust/pull/129373
|
||||
depends on (RUSTC_LLVM_VERSION >= 190103 && RUSTC_VERSION >= 108200) || \
|
||||
(!GCOV_KERNEL && !KASAN_GENERIC && !KASAN_SW_TAGS)
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ CONFIG_MMC_SDHCI=y
|
|||
CONFIG_MMC_SDHCI_PLTFM=y
|
||||
CONFIG_MMC_DW=y
|
||||
# CONFIG_IOMMU_SUPPORT is not set
|
||||
CONFIG_EXT3_FS=y
|
||||
CONFIG_EXT4_FS=y
|
||||
CONFIG_MSDOS_FS=y
|
||||
CONFIG_VFAT_FS=y
|
||||
CONFIG_NTFS_FS=y
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ CONFIG_MMC_SDHCI=y
|
|||
CONFIG_MMC_SDHCI_PLTFM=y
|
||||
CONFIG_MMC_DW=y
|
||||
# CONFIG_IOMMU_SUPPORT is not set
|
||||
CONFIG_EXT3_FS=y
|
||||
CONFIG_EXT4_FS=y
|
||||
CONFIG_MSDOS_FS=y
|
||||
CONFIG_VFAT_FS=y
|
||||
CONFIG_NTFS_FS=y
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ CONFIG_MMC_SDHCI=y
|
|||
CONFIG_MMC_SDHCI_PLTFM=y
|
||||
CONFIG_MMC_DW=y
|
||||
# CONFIG_IOMMU_SUPPORT is not set
|
||||
CONFIG_EXT3_FS=y
|
||||
CONFIG_EXT4_FS=y
|
||||
CONFIG_MSDOS_FS=y
|
||||
CONFIG_VFAT_FS=y
|
||||
CONFIG_NTFS_FS=y
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ CONFIG_DMADEVICES=y
|
|||
CONFIG_DW_AXI_DMAC=y
|
||||
CONFIG_IIO=y
|
||||
CONFIG_TI_ADC108S102=y
|
||||
CONFIG_EXT3_FS=y
|
||||
CONFIG_EXT4_FS=y
|
||||
CONFIG_VFAT_FS=y
|
||||
CONFIG_TMPFS=y
|
||||
CONFIG_NFS_FS=y
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ CONFIG_USB_OHCI_HCD_PLATFORM=y
|
|||
CONFIG_USB_STORAGE=y
|
||||
CONFIG_USB_SERIAL=y
|
||||
# CONFIG_IOMMU_SUPPORT is not set
|
||||
CONFIG_EXT3_FS=y
|
||||
CONFIG_EXT4_FS=y
|
||||
CONFIG_EXT4_FS=y
|
||||
CONFIG_MSDOS_FS=y
|
||||
CONFIG_VFAT_FS=y
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ CONFIG_MMC_DW=y
|
|||
CONFIG_UIO=y
|
||||
CONFIG_UIO_PDRV_GENIRQ=y
|
||||
# CONFIG_IOMMU_SUPPORT is not set
|
||||
CONFIG_EXT3_FS=y
|
||||
CONFIG_EXT4_FS=y
|
||||
CONFIG_MSDOS_FS=y
|
||||
CONFIG_VFAT_FS=y
|
||||
CONFIG_NTFS_FS=y
|
||||
|
|
|
|||
|
|
@ -44,6 +44,8 @@ config ARM
|
|||
select ARCH_USE_BUILTIN_BSWAP
|
||||
select ARCH_USE_CMPXCHG_LOCKREF
|
||||
select ARCH_USE_MEMTEST
|
||||
# https://github.com/llvm/llvm-project/commit/d130f402642fba3d065aacb506cb061c899558de
|
||||
select ARCH_USES_CFI_GENERIC_LLVM_PASS if CLANG_VERSION < 220000
|
||||
select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
|
||||
select ARCH_WANT_GENERAL_HUGETLB
|
||||
select ARCH_WANT_IPC_PARSE_VERSION
|
||||
|
|
|
|||
|
|
@ -77,6 +77,14 @@
|
|||
/delete-property/ pinctrl-0;
|
||||
};
|
||||
|
||||
&pm {
|
||||
clocks = <&firmware_clocks 5>,
|
||||
<&clocks BCM2835_CLOCK_PERI_IMAGE>,
|
||||
<&clocks BCM2835_CLOCK_H264>,
|
||||
<&clocks BCM2835_CLOCK_ISP>;
|
||||
clock-names = "v3d", "peri_image", "h264", "isp";
|
||||
};
|
||||
|
||||
&rmem {
|
||||
/*
|
||||
* RPi4's co-processor will copy the board's bootloader configuration
|
||||
|
|
|
|||
|
|
@ -13,7 +13,16 @@
|
|||
clock-names = "pixel", "hdmi";
|
||||
};
|
||||
|
||||
&pm {
|
||||
clocks = <&firmware_clocks 5>,
|
||||
<&clocks BCM2835_CLOCK_PERI_IMAGE>,
|
||||
<&clocks BCM2835_CLOCK_H264>,
|
||||
<&clocks BCM2835_CLOCK_ISP>;
|
||||
clock-names = "v3d", "peri_image", "h264", "isp";
|
||||
};
|
||||
|
||||
&v3d {
|
||||
clocks = <&firmware_clocks 5>;
|
||||
power-domains = <&power RPI_POWER_DOMAIN_V3D>;
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -34,6 +34,41 @@
|
|||
status = "disabled";
|
||||
};
|
||||
|
||||
display-subsystem {
|
||||
compatible = "st,sti-display-subsystem";
|
||||
ports = <&compositor>, <&hqvdp>, <&tvout>, <&sti_hdmi>;
|
||||
|
||||
assigned-clocks = <&clk_s_d2_quadfs 0>,
|
||||
<&clk_s_d2_quadfs 1>,
|
||||
<&clk_s_c0_pll1 0>,
|
||||
<&clk_s_c0_flexgen CLK_COMPO_DVP>,
|
||||
<&clk_s_c0_flexgen CLK_MAIN_DISP>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_MAIN_DISP>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_AUX_DISP>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_GDP1>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_GDP2>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_GDP3>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_GDP4>;
|
||||
|
||||
assigned-clock-parents = <0>,
|
||||
<0>,
|
||||
<0>,
|
||||
<&clk_s_c0_pll1 0>,
|
||||
<&clk_s_c0_pll1 0>,
|
||||
<&clk_s_d2_quadfs 0>,
|
||||
<&clk_s_d2_quadfs 1>,
|
||||
<&clk_s_d2_quadfs 0>,
|
||||
<&clk_s_d2_quadfs 0>,
|
||||
<&clk_s_d2_quadfs 0>,
|
||||
<&clk_s_d2_quadfs 0>;
|
||||
|
||||
assigned-clock-rates = <297000000>,
|
||||
<297000000>,
|
||||
<0>,
|
||||
<400000000>,
|
||||
<400000000>;
|
||||
};
|
||||
|
||||
soc {
|
||||
ohci0: usb@9a03c00 {
|
||||
compatible = "st,st-ohci-300x";
|
||||
|
|
@ -99,153 +134,176 @@
|
|||
status = "disabled";
|
||||
};
|
||||
|
||||
sti-display-subsystem@0 {
|
||||
compatible = "st,sti-display-subsystem";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compositor: display-controller@9d11000 {
|
||||
compatible = "st,stih407-compositor";
|
||||
reg = <0x9d11000 0x1000>;
|
||||
|
||||
reg = <0 0>;
|
||||
assigned-clocks = <&clk_s_d2_quadfs 0>,
|
||||
<&clk_s_d2_quadfs 1>,
|
||||
<&clk_s_c0_pll1 0>,
|
||||
<&clk_s_c0_flexgen CLK_COMPO_DVP>,
|
||||
<&clk_s_c0_flexgen CLK_MAIN_DISP>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_MAIN_DISP>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_AUX_DISP>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_GDP1>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_GDP2>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_GDP3>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_GDP4>;
|
||||
clock-names = "compo_main",
|
||||
"compo_aux",
|
||||
"pix_main",
|
||||
"pix_aux",
|
||||
"pix_gdp1",
|
||||
"pix_gdp2",
|
||||
"pix_gdp3",
|
||||
"pix_gdp4",
|
||||
"main_parent",
|
||||
"aux_parent";
|
||||
|
||||
assigned-clock-parents = <0>,
|
||||
<0>,
|
||||
<0>,
|
||||
<&clk_s_c0_pll1 0>,
|
||||
<&clk_s_c0_pll1 0>,
|
||||
<&clk_s_d2_quadfs 0>,
|
||||
<&clk_s_d2_quadfs 1>,
|
||||
<&clk_s_d2_quadfs 0>,
|
||||
clocks = <&clk_s_c0_flexgen CLK_COMPO_DVP>,
|
||||
<&clk_s_c0_flexgen CLK_COMPO_DVP>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_MAIN_DISP>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_AUX_DISP>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_GDP1>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_GDP2>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_GDP3>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_GDP4>,
|
||||
<&clk_s_d2_quadfs 0>,
|
||||
<&clk_s_d2_quadfs 1>;
|
||||
|
||||
reset-names = "compo-main", "compo-aux";
|
||||
resets = <&softreset STIH407_COMPO_SOFTRESET>,
|
||||
<&softreset STIH407_COMPO_SOFTRESET>;
|
||||
st,vtg = <&vtg_main>, <&vtg_aux>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
compo_main_out: endpoint {
|
||||
remote-endpoint = <&tvout_in0>;
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
compo_aux_out: endpoint {
|
||||
remote-endpoint = <&tvout_in1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
tvout: encoder@8d08000 {
|
||||
compatible = "st,stih407-tvout";
|
||||
reg = <0x8d08000 0x1000>;
|
||||
reg-names = "tvout-reg";
|
||||
reset-names = "tvout";
|
||||
resets = <&softreset STIH407_HDTVOUT_SOFTRESET>;
|
||||
assigned-clocks = <&clk_s_d2_flexgen CLK_PIX_HDMI>,
|
||||
<&clk_s_d2_flexgen CLK_TMDS_HDMI>,
|
||||
<&clk_s_d2_flexgen CLK_REF_HDMIPHY>,
|
||||
<&clk_s_d0_flexgen CLK_PCM_0>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_HDDAC>,
|
||||
<&clk_s_d2_flexgen CLK_HDDAC>;
|
||||
|
||||
assigned-clock-parents = <&clk_s_d2_quadfs 0>,
|
||||
<&clk_tmdsout_hdmi>,
|
||||
<&clk_s_d2_quadfs 0>,
|
||||
<&clk_s_d0_quadfs 0>,
|
||||
<&clk_s_d2_quadfs 0>,
|
||||
<&clk_s_d2_quadfs 0>;
|
||||
|
||||
assigned-clock-rates = <297000000>,
|
||||
<297000000>,
|
||||
<0>,
|
||||
<400000000>,
|
||||
<400000000>;
|
||||
|
||||
ranges;
|
||||
|
||||
sti-compositor@9d11000 {
|
||||
compatible = "st,stih407-compositor";
|
||||
reg = <0x9d11000 0x1000>;
|
||||
|
||||
clock-names = "compo_main",
|
||||
"compo_aux",
|
||||
"pix_main",
|
||||
"pix_aux",
|
||||
"pix_gdp1",
|
||||
"pix_gdp2",
|
||||
"pix_gdp3",
|
||||
"pix_gdp4",
|
||||
"main_parent",
|
||||
"aux_parent";
|
||||
|
||||
clocks = <&clk_s_c0_flexgen CLK_COMPO_DVP>,
|
||||
<&clk_s_c0_flexgen CLK_COMPO_DVP>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_MAIN_DISP>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_AUX_DISP>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_GDP1>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_GDP2>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_GDP3>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_GDP4>,
|
||||
<&clk_s_d2_quadfs 0>,
|
||||
<&clk_s_d2_quadfs 1>;
|
||||
|
||||
reset-names = "compo-main", "compo-aux";
|
||||
resets = <&softreset STIH407_COMPO_SOFTRESET>,
|
||||
<&softreset STIH407_COMPO_SOFTRESET>;
|
||||
st,vtg = <&vtg_main>, <&vtg_aux>;
|
||||
};
|
||||
|
||||
sti-tvout@8d08000 {
|
||||
compatible = "st,stih407-tvout";
|
||||
reg = <0x8d08000 0x1000>;
|
||||
reg-names = "tvout-reg";
|
||||
reset-names = "tvout";
|
||||
resets = <&softreset STIH407_HDTVOUT_SOFTRESET>;
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
assigned-clocks = <&clk_s_d2_flexgen CLK_PIX_HDMI>,
|
||||
<&clk_s_d2_flexgen CLK_TMDS_HDMI>,
|
||||
<&clk_s_d2_flexgen CLK_REF_HDMIPHY>,
|
||||
<&clk_s_d0_flexgen CLK_PCM_0>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_HDDAC>,
|
||||
<&clk_s_d2_flexgen CLK_HDDAC>;
|
||||
#size-cells = <0>;
|
||||
|
||||
assigned-clock-parents = <&clk_s_d2_quadfs 0>,
|
||||
<&clk_tmdsout_hdmi>,
|
||||
<&clk_s_d2_quadfs 0>,
|
||||
<&clk_s_d0_quadfs 0>,
|
||||
<&clk_s_d2_quadfs 0>,
|
||||
<&clk_s_d2_quadfs 0>;
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
tvout_in0: endpoint {
|
||||
remote-endpoint = <&compo_main_out>;
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
tvout_in1: endpoint {
|
||||
remote-endpoint = <&compo_aux_out>;
|
||||
};
|
||||
};
|
||||
|
||||
port@2 {
|
||||
reg = <2>;
|
||||
tvout_out0: endpoint {
|
||||
remote-endpoint = <&hdmi_in>;
|
||||
};
|
||||
};
|
||||
|
||||
port@3 {
|
||||
reg = <3>;
|
||||
tvout_out1: endpoint {
|
||||
remote-endpoint = <&hda_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
sti_hdmi: sti-hdmi@8d04000 {
|
||||
compatible = "st,stih407-hdmi";
|
||||
reg = <0x8d04000 0x1000>;
|
||||
reg-names = "hdmi-reg";
|
||||
#sound-dai-cells = <0>;
|
||||
interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "irq";
|
||||
clock-names = "pix",
|
||||
"tmds",
|
||||
"phy",
|
||||
"audio",
|
||||
"main_parent",
|
||||
"aux_parent";
|
||||
sti_hdmi: hdmi@8d04000 {
|
||||
compatible = "st,stih407-hdmi";
|
||||
reg = <0x8d04000 0x1000>;
|
||||
reg-names = "hdmi-reg";
|
||||
#sound-dai-cells = <0>;
|
||||
interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "irq";
|
||||
clock-names = "pix",
|
||||
"tmds",
|
||||
"phy",
|
||||
"audio",
|
||||
"main_parent",
|
||||
"aux_parent";
|
||||
|
||||
clocks = <&clk_s_d2_flexgen CLK_PIX_HDMI>,
|
||||
<&clk_s_d2_flexgen CLK_TMDS_HDMI>,
|
||||
<&clk_s_d2_flexgen CLK_REF_HDMIPHY>,
|
||||
<&clk_s_d0_flexgen CLK_PCM_0>,
|
||||
<&clk_s_d2_quadfs 0>,
|
||||
<&clk_s_d2_quadfs 1>;
|
||||
clocks = <&clk_s_d2_flexgen CLK_PIX_HDMI>,
|
||||
<&clk_s_d2_flexgen CLK_TMDS_HDMI>,
|
||||
<&clk_s_d2_flexgen CLK_REF_HDMIPHY>,
|
||||
<&clk_s_d0_flexgen CLK_PCM_0>,
|
||||
<&clk_s_d2_quadfs 0>,
|
||||
<&clk_s_d2_quadfs 1>;
|
||||
|
||||
hdmi,hpd-gpio = <&pio5 3 GPIO_ACTIVE_LOW>;
|
||||
reset-names = "hdmi";
|
||||
resets = <&softreset STIH407_HDMI_TX_PHY_SOFTRESET>;
|
||||
ddc = <&hdmiddc>;
|
||||
hdmi,hpd-gpio = <&pio5 3 GPIO_ACTIVE_LOW>;
|
||||
reset-names = "hdmi";
|
||||
resets = <&softreset STIH407_HDMI_TX_PHY_SOFTRESET>;
|
||||
ddc = <&hdmiddc>;
|
||||
|
||||
port {
|
||||
hdmi_in: endpoint {
|
||||
remote-endpoint = <&tvout_out0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
sti-hda@8d02000 {
|
||||
compatible = "st,stih407-hda";
|
||||
status = "disabled";
|
||||
reg = <0x8d02000 0x400>, <0x92b0120 0x4>;
|
||||
reg-names = "hda-reg", "video-dacs-ctrl";
|
||||
clock-names = "pix",
|
||||
"hddac",
|
||||
"main_parent",
|
||||
"aux_parent";
|
||||
clocks = <&clk_s_d2_flexgen CLK_PIX_HDDAC>,
|
||||
<&clk_s_d2_flexgen CLK_HDDAC>,
|
||||
<&clk_s_d2_quadfs 0>,
|
||||
<&clk_s_d2_quadfs 1>;
|
||||
};
|
||||
analog@8d02000 {
|
||||
compatible = "st,stih407-hda";
|
||||
status = "disabled";
|
||||
reg = <0x8d02000 0x400>, <0x92b0120 0x4>;
|
||||
reg-names = "hda-reg", "video-dacs-ctrl";
|
||||
clock-names = "pix",
|
||||
"hddac",
|
||||
"main_parent",
|
||||
"aux_parent";
|
||||
clocks = <&clk_s_d2_flexgen CLK_PIX_HDDAC>,
|
||||
<&clk_s_d2_flexgen CLK_HDDAC>,
|
||||
<&clk_s_d2_quadfs 0>,
|
||||
<&clk_s_d2_quadfs 1>;
|
||||
|
||||
sti-hqvdp@9c00000 {
|
||||
compatible = "st,stih407-hqvdp";
|
||||
reg = <0x9C00000 0x100000>;
|
||||
clock-names = "hqvdp", "pix_main";
|
||||
clocks = <&clk_s_c0_flexgen CLK_MAIN_DISP>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_MAIN_DISP>;
|
||||
reset-names = "hqvdp";
|
||||
resets = <&softreset STIH407_HDQVDP_SOFTRESET>;
|
||||
st,vtg = <&vtg_main>;
|
||||
port {
|
||||
hda_in: endpoint {
|
||||
remote-endpoint = <&tvout_out1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
hqvdp: plane@9c00000 {
|
||||
compatible = "st,stih407-hqvdp";
|
||||
reg = <0x9C00000 0x100000>;
|
||||
clock-names = "hqvdp", "pix_main";
|
||||
clocks = <&clk_s_c0_flexgen CLK_MAIN_DISP>,
|
||||
<&clk_s_d2_flexgen CLK_PIX_MAIN_DISP>;
|
||||
reset-names = "hqvdp";
|
||||
resets = <&softreset STIH407_HDQVDP_SOFTRESET>;
|
||||
st,vtg = <&vtg_main>;
|
||||
};
|
||||
|
||||
bdisp0:bdisp@9f10000 {
|
||||
compatible = "st,stih407-bdisp";
|
||||
reg = <0x9f10000 0x1000>;
|
||||
|
|
|
|||
|
|
@ -194,8 +194,7 @@ CONFIG_MAILBOX=y
|
|||
CONFIG_PL320_MBOX=y
|
||||
# CONFIG_IOMMU_SUPPORT is not set
|
||||
CONFIG_EXT2_FS=y
|
||||
CONFIG_EXT3_FS=y
|
||||
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
|
||||
CONFIG_EXT4_FS=y
|
||||
CONFIG_EXT4_FS=y
|
||||
CONFIG_AUTOFS_FS=y
|
||||
CONFIG_FUSE_FS=y
|
||||
|
|
|
|||
|
|
@ -154,8 +154,8 @@ CONFIG_PWM_BCM2835=y
|
|||
CONFIG_EXT2_FS=y
|
||||
CONFIG_EXT2_FS_XATTR=y
|
||||
CONFIG_EXT2_FS_POSIX_ACL=y
|
||||
CONFIG_EXT3_FS=y
|
||||
CONFIG_EXT3_FS_POSIX_ACL=y
|
||||
CONFIG_EXT4_FS=y
|
||||
CONFIG_EXT4_FS_POSIX_ACL=y
|
||||
CONFIG_FANOTIFY=y
|
||||
CONFIG_MSDOS_FS=y
|
||||
CONFIG_VFAT_FS=y
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue