diff options
author | Dave Airlie <airlied@redhat.com> | 2023-12-19 10:07:25 +0300 |
---|---|---|
committer | Dave Airlie <airlied@redhat.com> | 2023-12-19 10:07:32 +0300 |
commit | 48b272853e5ca6680eb7d019347126923da1a2eb (patch) | |
tree | b99c50c08043e17ab06dadb6088cd5b1fcbd95a6 /Documentation | |
parent | a0a28956b46ec7f16ce5d762ac5a124bb532da0d (diff) | |
parent | b1a2aa9bcbb88a7dc1c4df98dbf4f4df9ca79c9f (diff) | |
download | linux-48b272853e5ca6680eb7d019347126923da1a2eb.tar.xz |
Merge tag 'drm-misc-next-2023-12-14' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for $kernel-version:
UAPI Changes:
Cross-subsystem Changes:
- A few fixes for usb/typec
Core Changes:
- ci: Updates to the defconfig, igt version, etc.
- writeback: Move the atomic_check helper from the encoder to connector
Driver Changes:
- rockchip: Add support for rk3588
- xe: Update the TODO list
- panel:
- nv3052c: Register documentation, init sequence improvements and
support for the Fascontek FS035VG158
- st7701: Add support for the Anbernic RG-ARC
- new driver: Synaptics R63353 panel controller, Ilitek ILI9805 panel
controller
- new panel: AUO G156HAN04.0
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <mripard@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/aqpn5miejmkks7pbcfex7b6u63uwsruywxsnr3x5ljs45qatin@nbkkej2elk46
Diffstat (limited to 'Documentation')
9 files changed, 272 insertions, 93 deletions
diff --git a/Documentation/devicetree/bindings/display/panel/fascontek,fs035vg158.yaml b/Documentation/devicetree/bindings/display/panel/fascontek,fs035vg158.yaml new file mode 100644 index 000000000000..d13c4bd26de4 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/fascontek,fs035vg158.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/fascontek,fs035vg158.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Fascontek FS035VG158 3.5" (640x480 pixels) 24-bit IPS LCD panel + +maintainers: + - John Watts <contact@jookia.org> + +allOf: + - $ref: panel-common.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +properties: + compatible: + const: fascontek,fs035vg158 + + spi-3wire: true + +required: + - compatible + - reg + - port + - power-supply + - reset-gpios + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "fascontek,fs035vg158"; + reg = <0>; + + spi-3wire; + spi-max-frequency = <3125000>; + + reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>; + + backlight = <&backlight>; + power-supply = <&vcc>; + + port { + panel_input: endpoint { + remote-endpoint = <&panel_output>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml new file mode 100644 index 000000000000..f4f91f93f490 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/ilitek,ili9805.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ilitek ILI9805 based MIPI-DSI panels + +maintainers: + - Michael Trimarchi <michael@amarulasolutions.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - enum: + - giantplus,gpm1790a0 + - tianma,tm041xdhg01 + - const: ilitek,ili9805 + + avdd-supply: true + dvdd-supply: true + reg: true + +required: + - compatible + - avdd-supply + - dvdd-supply + - reg + - reset-gpios + - port + - backlight + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "giantplus,gpm1790a0", "ilitek,ili9805"; + reg = <0>; + avdd-supply = <&avdd_display>; + dvdd-supply = <&dvdd_display>; + reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_LOW>; /* PL05 */ + backlight = <&backlight>; + + port { + panel_in: endpoint { + remote-endpoint = <&mipi_dsi_out>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml index ebdca5f5a001..7a55961e1a3d 100644 --- a/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml +++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml @@ -18,16 +18,12 @@ properties: compatible: const: leadtek,ltk035c5444t - backlight: true - port: true - power-supply: true - reg: true - reset-gpios: true - spi-3wire: true required: - compatible + - reg + - port - power-supply - reset-gpios diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml index a5a596ff8e75..716ece5f3978 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml @@ -33,6 +33,8 @@ properties: # AU Optronics Corporation 13.3" FHD (1920x1080) TFT LCD panel - auo,g133han01 + # AU Optronics Corporation 15.6" FHD (1920x1080) TFT LCD panel + - auo,g156han04 # AU Optronics Corporation 18.5" FHD (1920x1080) TFT LCD panel - auo,g185han01 # AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml index 4dc0cd4a6a77..b348f5bf0a98 100644 --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml @@ -27,6 +27,7 @@ properties: compatible: items: - enum: + - anbernic,rg-arc-panel - densitron,dmt028vghmcmi-1a - elida,kd50t048a - techstar,ts8550b diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml index b60b90472d42..2531726af306 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml @@ -8,8 +8,8 @@ title: Rockchip SoC display controller (VOP2) description: VOP2 (Video Output Processor v2) is the display controller for the Rockchip - series of SoCs which transfers the image data from a video memory - buffer to an external LCD interface. + series of SoCs which transfers the image data from a video memory buffer to + an external LCD interface. maintainers: - Sandy Huang <hjc@rock-chips.com> @@ -20,6 +20,7 @@ properties: enum: - rockchip,rk3566-vop - rockchip,rk3568-vop + - rockchip,rk3588-vop reg: items: @@ -27,8 +28,8 @@ properties: Must contain one entry corresponding to the base address and length of the register space. - description: - Can optionally contain a second entry corresponding to - the CRTC gamma LUT address. + Can optionally contain a second entry corresponding to the CRTC gamma + LUT address. reg-names: items: @@ -41,45 +42,63 @@ properties: The VOP interrupt is shared by several interrupt sources, such as frame start (VSYNC), line flag and other status interrupts. + # See compatible-specific constraints below. clocks: + minItems: 5 items: - - description: Clock for ddr buffer transfer. - - description: Clock for the ahb bus to R/W the phy regs. + - description: Clock for ddr buffer transfer via axi. + - description: Clock for the ahb bus to R/W the regs. - description: Pixel clock for video port 0. - description: Pixel clock for video port 1. - description: Pixel clock for video port 2. + - description: Pixel clock for video port 3. + - description: Peripheral(vop grf/dsi) clock. clock-names: + minItems: 5 items: - const: aclk - const: hclk - const: dclk_vp0 - const: dclk_vp1 - const: dclk_vp2 + - const: dclk_vp3 + - const: pclk_vop rockchip,grf: $ref: /schemas/types.yaml#/definitions/phandle description: - Phandle to GRF regs used for misc control + Phandle to GRF regs used for control the polarity of dclk/hsync/vsync of DPI, + also used for query vop memory bisr enable status, etc. + + rockchip,vo1-grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to VO GRF regs used for control the polarity of dclk/hsync/vsync of hdmi + on rk3588. + + rockchip,vop-grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to VOP GRF regs used for control data path between vopr and hdmi/edp. + + rockchip,pmu: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to PMU GRF used for query vop memory bisr status on rk3588. ports: $ref: /schemas/graph.yaml#/properties/ports - properties: - port@0: + patternProperties: + "^port@[0-3]$": $ref: /schemas/graph.yaml#/properties/port - description: - Output endpoint of VP0 + description: Output endpoint of VP0/1/2/3. - port@1: - $ref: /schemas/graph.yaml#/properties/port - description: - Output endpoint of VP1 + required: + - port@0 - port@2: - $ref: /schemas/graph.yaml#/properties/port - description: - Output endpoint of VP2 + unevaluatedProperties: false iommus: maxItems: 1 @@ -96,6 +115,49 @@ required: - clock-names - ports +allOf: + - if: + properties: + compatible: + contains: + const: rockchip,rk3588-vop + then: + properties: + clocks: + minItems: 7 + clock-names: + minItems: 7 + + ports: + required: + - port@0 + - port@1 + - port@2 + - port@3 + + required: + - rockchip,grf + - rockchip,vo1-grf + - rockchip,vop-grf + - rockchip,pmu + + else: + properties: + rockchip,vo1-grf: false + rockchip,vop-grf: false + rockchip,pmu: false + + clocks: + maxItems: 5 + clock-names: + maxItems: 5 + + ports: + required: + - port@0 + - port@1 + - port@2 + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 309b94c328c8..08ba7aad0d76 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -474,6 +474,8 @@ patternProperties: description: Fairphone B.V. "^faraday,.*": description: Faraday Technology Corporation + "^fascontek,.*": + description: Fascontek "^fastrax,.*": description: Fastrax Oy "^fcs,.*": diff --git a/Documentation/gpu/automated_testing.rst b/Documentation/gpu/automated_testing.rst index 240e29d5ba68..2d5a28866afe 100644 --- a/Documentation/gpu/automated_testing.rst +++ b/Documentation/gpu/automated_testing.rst @@ -69,14 +69,15 @@ the result. They will still be run. Each new flake entry must be associated with a link to the email reporting the bug to the author of the affected driver, the board name or Device Tree name of -the board, the first kernel version affected, and an approximation of the -failure rate. +the board, the first kernel version affected, the IGT version used for tests, +and an approximation of the failure rate. They should be provided under the following format:: # Bug Report: $LORE_OR_PATCHWORK_URL # Board Name: broken-board.dtb - # Version: 6.6-rc1 + # Linux Version: 6.6-rc1 + # IGT Version: 1.28-gd2af13d9f # Failure Rate: 100 flaky-test diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst index ceb21219d52e..97cf87578f97 100644 --- a/Documentation/gpu/rfc/xe.rst +++ b/Documentation/gpu/rfc/xe.rst @@ -70,35 +70,42 @@ When the time comes for Xe, the protection will be lifted on Xe and kept in i915 Xe – Pre-Merge Goals - Work-in-Progress ======================================= -Drm_scheduler -------------- -Xe primarily uses Firmware based scheduling (GuC FW). However, it will use -drm_scheduler as the scheduler ‘frontend’ for userspace submission in order to -resolve syncobj and dma-buf implicit sync dependencies. However, drm_scheduler is -not yet prepared to handle the 1-to-1 relationship between drm_gpu_scheduler and -drm_sched_entity. +Display integration with i915 +----------------------------- +In order to share the display code with the i915 driver so that there is maximum +reuse, the i915/display/ code is built twice, once for i915.ko and then for +xe.ko. Currently, the i915/display code in Xe tree is polluted with many 'ifdefs' +depending on the build target. The goal is to refactor both Xe and i915/display +code simultaneously in order to get a clean result before they land upstream, so +that display can already be part of the initial pull request towards drm-next. -Deeper changes to drm_scheduler should *not* be required to get Xe accepted, but -some consensus needs to be reached between Xe and other community drivers that -could also benefit from this work, for coupling FW based/assisted submission such -as the ARM’s new Mali GPU driver, and others. +However, display code should not gate the acceptance of Xe in upstream. Xe +patches will be refactored in a way that display code can be removed, if needed, +from the first pull request of Xe towards drm-next. The expectation is that when +both drivers are part of the drm-tip, the introduction of cleaner patches will be +easier and speed up. -As a key measurable result, the patch series introducing Xe itself shall not -depend on any other patch touching drm_scheduler itself that was not yet merged -through drm-misc. This, by itself, already includes the reach of an agreement for -uniform 1 to 1 relationship implementation / usage across drivers. +Xe – uAPI high level overview +============================= -ASYNC VM_BIND -------------- -Although having a common DRM level IOCTL for VM_BIND is not a requirement to get -Xe merged, it is mandatory to have a consensus with other drivers and Mesa. -It needs to be clear how to handle async VM_BIND and interactions with userspace -memory fences. Ideally with helper support so people don't get it wrong in all -possible ways. +...Warning: To be done in follow up patches after/when/where the main consensus in various items are individually reached. -As a key measurable result, the benefits of ASYNC VM_BIND and a discussion of -various flavors, error handling and sample API suggestions are documented in -:doc:`The ASYNC VM_BIND document </gpu/drm-vm-bind-async>`. +Xe – Pre-Merge Goals - Completed +================================ + +Drm_exec +-------- +Helper to make dma_resv locking for a big number of buffers is getting removed in +the drm_exec series proposed in https://patchwork.freedesktop.org/patch/524376/ +If that happens, Xe needs to change and incorporate the changes in the driver. +The goal is to engage with the Community to understand if the best approach is to +move that to the drivers that are using it or if we should keep the helpers in +place waiting for Xe to get merged. + +This item ties into the GPUVA, VM_BIND, and even long-running compute support. + +As a key measurable result, we need to have a community consensus documented in +this document and the Xe driver prepared for the changes, if necessary. Userptr integration and vm_bind ------------------------------- @@ -132,6 +139,36 @@ the time comes. The DRM GPUVM helpers do not yet include the userptr parts, but discussions about implementing them are ongoing. +ASYNC VM_BIND +------------- +Although having a common DRM level IOCTL for VM_BIND is not a requirement to get +Xe merged, it is mandatory to have a consensus with other drivers and Mesa. +It needs to be clear how to handle async VM_BIND and interactions with userspace +memory fences. Ideally with helper support so people don't get it wrong in all +possible ways. + +As a key measurable result, the benefits of ASYNC VM_BIND and a discussion of +various flavors, error handling and sample API suggestions are documented in +:doc:`The ASYNC VM_BIND document </gpu/drm-vm-bind-async>`. + +Drm_scheduler +------------- +Xe primarily uses Firmware based scheduling (GuC FW). However, it will use +drm_scheduler as the scheduler ‘frontend’ for userspace submission in order to +resolve syncobj and dma-buf implicit sync dependencies. However, drm_scheduler is +not yet prepared to handle the 1-to-1 relationship between drm_gpu_scheduler and +drm_sched_entity. + +Deeper changes to drm_scheduler should *not* be required to get Xe accepted, but +some consensus needs to be reached between Xe and other community drivers that +could also benefit from this work, for coupling FW based/assisted submission such +as the ARM’s new Mali GPU driver, and others. + +As a key measurable result, the patch series introducing Xe itself shall not +depend on any other patch touching drm_scheduler itself that was not yet merged +through drm-misc. This, by itself, already includes the reach of an agreement for +uniform 1 to 1 relationship implementation / usage across drivers. + Long running compute: minimal data structure/scaffolding -------------------------------------------------------- The generic scheduler code needs to include the handling of endless compute @@ -144,46 +181,6 @@ this minimal drm/scheduler work, if needed, merged to drm-misc in a way that any drm driver, including Xe, could re-use and add their own individual needs on top in a next stage. However, this should not block the initial merge. -This is a non-blocker item since the driver without the support for the long -running compute enabled is not a showstopper. - -Display integration with i915 ------------------------------ -In order to share the display code with the i915 driver so that there is maximum -reuse, the i915/display/ code is built twice, once for i915.ko and then for -xe.ko. Currently, the i915/display code in Xe tree is polluted with many 'ifdefs' -depending on the build target. The goal is to refactor both Xe and i915/display -code simultaneously in order to get a clean result before they land upstream, so -that display can already be part of the initial pull request towards drm-next. - -However, display code should not gate the acceptance of Xe in upstream. Xe -patches will be refactored in a way that display code can be removed, if needed, -from the first pull request of Xe towards drm-next. The expectation is that when -both drivers are part of the drm-tip, the introduction of cleaner patches will be -easier and speed up. - -Drm_exec --------- -Helper to make dma_resv locking for a big number of buffers is getting removed in -the drm_exec series proposed in https://patchwork.freedesktop.org/patch/524376/ -If that happens, Xe needs to change and incorporate the changes in the driver. -The goal is to engage with the Community to understand if the best approach is to -move that to the drivers that are using it or if we should keep the helpers in -place waiting for Xe to get merged. - -This item ties into the GPUVA, VM_BIND, and even long-running compute support. - -As a key measurable result, we need to have a community consensus documented in -this document and the Xe driver prepared for the changes, if necessary. - -Xe – uAPI high level overview -============================= - -...Warning: To be done in follow up patches after/when/where the main consensus in various items are individually reached. - -Xe – Pre-Merge Goals - Completed -================================ - Dev_coredump ------------ |