dri-devel April 2022

dri-devel@lists.freedesktop.org

351 participants
951 discussions

[pull] amdgpu, amdkfd drm-fixes-5.18
by Alex Deucher 28 Apr '22

28 Apr '22

Hi Dave, Daniel, Fixes for 5.18. The following changes since commit b2d229d4ddb17db541098b83524d901257e93845: Linux 5.18-rc3 (2022-04-17 13:57:31 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.18-2022-04-27 for you to fetch changes up to fb8cc3318e47e1a0ced4025ef614317b541147e7: drm/amdgpu: keep mmhub clock gating being enabled during s2idle suspend (2022-04-27 17:38:02 -0400) ---------------------------------------------------------------- amd-drm-fixes-5.18-2022-04-27: amdgpu: - Runtime pm fix - DCN memory leak fix in error path - SI DPM deadlock fix - S0ix fix amdkfd: - GWS fix - GWS support for CRIU ---------------------------------------------------------------- Alex Deucher (1): drm/amdgpu: don't runtime suspend if there are displays attached (v3) David Yat Sin (2): drm/amdkfd: Fix GWS queue count drm/amdkfd: CRIU add support for GWS queues Evan Quan (1): drm/amd/pm: fix the deadlock issue observed on SI Miaoqian Lin (1): drm/amd/display: Fix memory leak in dcn21_clock_source_create Prike Liang (1): drm/amdgpu: keep mmhub clock gating being enabled during s2idle suspend drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 105 ++++++++++++++------- drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 10 ++ .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 83 ++++++++-------- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 2 +- .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 10 +- .../gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 1 + drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 39 ++++++++ drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c | 10 -- drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 35 ------- drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c | 10 -- 10 files changed, 165 insertions(+), 140 deletions(-)

1 0

[PATCH v17 00/21] Add MediaTek SoC DRM (vdosys1) support for mt8195
by Nancy.Lin 28 Apr '22

28 Apr '22

The hardware path of vdosys1 with DPTx output need to go through by several modules, such as, OVL_ADAPTOR and MERGE. Add DRM and these modules support by the patches below: Changes in v17: - fix reviewer comment in v16 - separate ovl adaptor comp in mtk-mmsys and mtk-mutex - separate mmsys config API - move mdp_rdma binding yaml - fix ovl adaptor pm runtime get sync timing issue - rebase to vdosys0 series v19 (ref [5]) - rebase to [7] for modify vblank register change Changes in v16: - fix reviewer comment in v 15 - fix mtk_drm_ddp_comp.c alignment - fix vdosys0 mmsys num before adding vdosys1 patch Changes in v15: - fix ethdr uppercase hex number in dts Changes in v14: - remove MTK_MMSYS 64 bit dependency - add ethdr.yaml back and fix dt_schema check fail Resend v13 - add related maintainer in maillist Changes in v13: - fix reviewer comment in v12 - fix rdma dt-binding format - fix dts node naming - fix 32 bit build error - modify 64bit dependency for mtk-mmsys - rebase to vdosys0 series v16. (ref [5]) Changes in v12: - fix reviewer comment in v11 - modify mbox index - refine dma dev for ovl_adaptor sub driver Changes in v11: - remove ethdr vblank spin lock - refine ovl_adaptor print message Changes in v10: - refine ethdr reset control using devm_reset_control_array_get_optional_exclusive - fix ovl_adaptor mtk_ovl_adaptor_clk_enable error handle issue Changes in v9: - rebase on kernel-5.16-rc1 - rebase on vdosys0 series v13. (ref [5]) - fix ovl_adaptor sub driver is brought up unintentionally - fix clang build test fail- duplicate ethdr/mdp_rdma init_module/cleanup_module symbol issue Changes in v8: - separate merge async reset to new patch. - separate drm ovl_adaptor sub driver to new patch. - fix reviewer comment in v7. Changes in v7: - rebase on vdosys0 series v12 (ref[5]) - add dma description in ethdr binding document. - refine vdosys1 bit definition of mmsys routing table. - separate merge modification into 3 pathces. - separate mutex modification into 2 patches. - add plane color coding for mdp_rdma csc. - move mdp_rdma pm control to ovl_adaptor. - fix reviewer comment in v6. Changes in v6: - rebase on kernel-5.15-rc1. - change mbox label to gce0 for dts node of vdosys1. - modify mmsys reset num for mt8195. - rebase on vdosys0 series v10. (ref [5]) - use drm to bring up ovl_adaptor driver. - move drm iommu/mutex check from kms init to drm bind. - modify rdma binding doc location. (Documentation/devicetree/bindings/arm/) - modify for reviewer's comment in v5. Changes in v5: - add mmsys reset controller reference. Changes in v4: - use merge common driver for merge1~4. - refine ovl_adaptor rdma driver. - use ovl_adaptor ddp_comp function instead of ethdr. - modify for reviewer's comment in v3. Changes in v3: - modify for reviewer's comment in v2. - add vdosys1 2 pixels align limit. - add mixer odd offset support. Changes in v2: - Merge PSEUDO_OVL and ETHDR into one DRM component. - Add mmsys config API for vdosys1 hardware setting. - Add mmsys reset control using linux reset framework. Signed-off-by: Nancy.Lin <nancy.lin(a)mediatek.com> This series are based on the following patch: [1] arm64: dts: Add mediatek SoC mt8195 and evaluation board 20220112114724.1953-4-tinghan.shen(a)mediatek.com [2] arm64: dts: mt8195: add IOMMU and smi nodes 20210615173233.26682-15-tinghan.shen(a)mediatek.com [3] arm64: dts: mt8195: add gce node 20220126090109.32143-1-jason-jh.lin(a)mediatek.com [4] [v2] arm64: dts: mt8195: add display node for vdosys0 20220225021535.2655-1-jason-jh.lin(a)mediatek.com [5] Add MediaTek SoC DRM (vdosys0) support for mt8195 - v19 series 20220415083911.5186-2-jason-jh.lin(a)mediatek.com [6] dt-bindings: mediatek: mt8195: Add binding for MM IOMMU 20220217113453.13658-2-yong.wu(a)mediatek.com [7] [V2] drm/mediatek: Add vblank register/unregister callback functions 20220321072320.15019-1-rex-bc.chen(a)mediatek.com Nancy.Lin (21): dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 dt-bindings: reset: mt8195: add vdosys1 reset control bit dt-bindings: mediatek: add ethdr definition for mt8195 soc: mediatek: add mtk-mmsys support for mt8195 vdosys1 soc: mediatek: add mtk-mmsys config API for mt8195 vdosys1 soc: mediatek: add cmdq support of mtk-mmsys config API for mt8195 vdosys1 soc: mediatek: mmsys: modify reset controller for MT8195 vdosys1 soc: mediatek: add mtk-mutex support for mt8195 vdosys1 drm/mediatek: add display MDP RDMA support for MT8195 drm/mediatek: add display merge advance config API for MT8195 drm/mediatek: add display merge start/stop API for cmdq support drm/mediatek: add display merge mute/unmute support for MT8195 drm/mediatek: add display merge async reset control drm/mediatek: add ETHDR support for MT8195 drm/mediatek: add mediatek-drm plane color encoding info drm/mediatek: add ovl_adaptor support for MT8195 drm/mediatek: add dma dev get function drm/mediatek: modify mediatek-drm for mt8195 multi mmsys support drm/mediatek: add drm ovl_adaptor sub driver for MT8195 drm/mediatek: add mediatek-drm of vdosys1 support for MT8195 arm64: dts: mt8195: add display node for vdosys1 .../display/mediatek/mediatek,ethdr.yaml | 158 ++++++ .../display/mediatek/mediatek,mdp-rdma.yaml | 86 +++ arch/arm64/boot/dts/mediatek/mt8195.dtsi | 225 +++++++- drivers/gpu/drm/mediatek/Makefile | 5 +- drivers/gpu/drm/mediatek/mtk_disp_drv.h | 38 ++ drivers/gpu/drm/mediatek/mtk_disp_merge.c | 89 ++- .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 514 ++++++++++++++++++ drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 96 ++-- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 6 +- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 125 +++-- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 58 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 351 ++++++++---- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 25 +- drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 + drivers/gpu/drm/mediatek/mtk_drm_plane.h | 1 + drivers/gpu/drm/mediatek/mtk_ethdr.c | 368 +++++++++++++ drivers/gpu/drm/mediatek/mtk_ethdr.h | 26 + drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 315 +++++++++++ drivers/gpu/drm/mediatek/mtk_mdp_rdma.h | 20 + drivers/soc/mediatek/mt8195-mmsys.h | 143 +++++ drivers/soc/mediatek/mtk-mmsys.c | 106 +++- drivers/soc/mediatek/mtk-mmsys.h | 1 + drivers/soc/mediatek/mtk-mutex.c | 37 ++ include/dt-bindings/reset/mt8195-resets.h | 12 + include/linux/soc/mediatek/mtk-mmsys.h | 25 + 25 files changed, 2614 insertions(+), 217 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.c create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.h create mode 100644 drivers/gpu/drm/mediatek/mtk_mdp_rdma.c create mode 100644 drivers/gpu/drm/mediatek/mtk_mdp_rdma.h -- 2.18.0

5 38

[PATCH][next] drm/i915: Fix -Wstringop-overflow warning in call to intel_read_wm_latency()
by Gustavo A. R. Silva 27 Apr '22

27 Apr '22

Fix the following -Wstringop-overflow warnings when building with GCC-11: drivers/gpu/drm/i915/intel_pm.c:3106:9: warning: ‘intel_read_wm_latency’ accessing 16 bytes in a region of size 10 [-Wstringop-overflow=] 3106 | intel_read_wm_latency(dev_priv, dev_priv->wm.pri_latency); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/intel_pm.c:3106:9: note: referencing argument 2 of type ‘u16 *’ {aka ‘short unsigned int *’} drivers/gpu/drm/i915/intel_pm.c:2861:13: note: in a call to function ‘intel_read_wm_latency’ 2861 | static void intel_read_wm_latency(struct drm_i915_private *dev_priv, | ^~~~~~~~~~~~~~~~~~~~~ by removing the over-specified array size from the argument declarations. It seems that this code is actually safe because the size of the array depends on the hardware generation, and the function checks for that. This helps with the ongoing efforts to globally enable -Wstringop-overflow. Link: https://github.com/KSPP/linux/issues/181 Signed-off-by: Gustavo A. R. Silva <gustavoars(a)kernel.org> --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index ee0047fdc95d..5735915facc5 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -2862,7 +2862,7 @@ static void ilk_compute_wm_level(const struct drm_i915_private *dev_priv, } static void intel_read_wm_latency(struct drm_i915_private *dev_priv, - u16 wm[8]) + u16 wm[]) { struct intel_uncore *uncore = &dev_priv->uncore; -- 2.27.0

1 0

[PATCH] drm/display: Select DP helpers for DRM_DP_AUX_CHARDEV and DRM_DP_CEC
by Javier Martinez Canillas 27 Apr '22

27 Apr '22

The DRM_DP_AUX_CHARDEV and DRM_DP_CEC boolean Kconfig symbols enable code that use DP helper functions, exported by the display-helper module. But these don't select the DRM_DISPLAY_DP_HELPER and DRM_DISPLAY_HELPER symbols, to make sure that the functions used will be present. This leads to the following linking errors if CONFIG_DRM_DISPLAY_HELPER is set to m: LD vmlinux.o MODPOST vmlinux.symvers MODINFO modules.builtin.modinfo GEN modules.builtin LD .tmp_vmlinux.kallsyms1 KSYMS .tmp_vmlinux.kallsyms1.S AS .tmp_vmlinux.kallsyms1.S LD .tmp_vmlinux.kallsyms2 KSYMS .tmp_vmlinux.kallsyms2.S AS .tmp_vmlinux.kallsyms2.S LD vmlinux SYSMAP System.map SORTTAB vmlinux OBJCOPY arch/arm64/boot/Image MODPOST modules-only.symvers ERROR: modpost: "drm_dp_dpcd_write" [drivers/gpu/drm/display/drm_display_helper.ko] undefined! ERROR: modpost: "drm_dp_read_desc" [drivers/gpu/drm/display/drm_display_helper.ko] undefined! ERROR: modpost: "drm_dp_dpcd_read" [drivers/gpu/drm/display/drm_display_helper.ko] undefined! make[1]: *** [scripts/Makefile.modpost:134: modules-only.symvers] Error 1 make[1]: *** Deleting file 'modules-only.symvers' make: *** [Makefile:1749: modules] Error 2 Note: It seems this has been an issue for a long time but was made easier to reproduce after the commit 1e0f66420b13 ("drm/display: Introduce a DRM display-helper module"). Adding a Fixes: tag just to make sure that this fix will be picked for stable once the mentioned change also lands there. Fixes: 1e0f66420b13 ("drm/display: Introduce a DRM display-helper module") Signed-off-by: Javier Martinez Canillas <javierm(a)redhat.com> --- drivers/gpu/drm/display/Kconfig | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/display/Kconfig b/drivers/gpu/drm/display/Kconfig index f84f1b0cd23f..d7a413a2c6cc 100644 --- a/drivers/gpu/drm/display/Kconfig +++ b/drivers/gpu/drm/display/Kconfig @@ -32,6 +32,8 @@ config DRM_DISPLAY_HDMI_HELPER config DRM_DP_AUX_CHARDEV bool "DRM DP AUX Interface" depends on DRM + select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_HELPER help Choose this option to enable a /dev/drm_dp_auxN node that allows to read and write values to arbitrary DPCD registers on the DP aux @@ -40,6 +42,8 @@ config DRM_DP_AUX_CHARDEV config DRM_DP_CEC bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support" depends on DRM + select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_HELPER select CEC_CORE help Choose this option if you want to enable HDMI CEC support for -- 2.35.1

1 1

[PATCH 10/11] dt-bindings: display: convert Arm Mali-DP to DT schema
by Andre Przywara 27 Apr '22

27 Apr '22

The Arm Mali Display Processor (DP) 5xx/6xx is a series of IP that scans out a framebuffer and hands the pixels over to a digital signal encoder. It supports multiple layers, scaling and rotation. Convert the existing DT binding to DT schema. Signed-off-by: Andre Przywara <andre.przywara(a)arm.com> --- .../bindings/display/arm,malidp.txt | 68 ---------- .../bindings/display/arm,malidp.yaml | 117 ++++++++++++++++++ 2 files changed, 117 insertions(+), 68 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/arm,malidp.txt create mode 100644 Documentation/devicetree/bindings/display/arm,malidp.yaml diff --git a/Documentation/devicetree/bindings/display/arm,malidp.txt b/Documentation/devicetree/bindings/display/arm,malidp.txt deleted file mode 100644 index 7a97a2b48c2a2..0000000000000 --- a/Documentation/devicetree/bindings/display/arm,malidp.txt +++ /dev/null @@ -1,68 +0,0 @@ -ARM Mali-DP - -The following bindings apply to a family of Display Processors sold as -licensable IP by ARM Ltd. The bindings describe the Mali DP500, DP550 and -DP650 processors that offer multiple composition layers, support for -rotation and scaling output. - -Required properties: - - compatible: should be one of - "arm,mali-dp500" - "arm,mali-dp550" - "arm,mali-dp650" - depending on the particular implementation present in the hardware - - reg: Physical base address and size of the block of registers used by - the processor. - - interrupts: Interrupt list, as defined in ../interrupt-controller/interrupts.txt, - interrupt client nodes. - - interrupt-names: name of the engine inside the processor that will - use the corresponding interrupt. Should be one of "DE" or "SE". - - clocks: A list of phandle + clock-specifier pairs, one for each entry - in 'clock-names' - - clock-names: A list of clock names. It should contain: - - "pclk": for the APB interface clock - - "aclk": for the AXI interface clock - - "mclk": for the main processor clock - - "pxlclk": for the pixel clock feeding the output PLL of the processor. - - arm,malidp-output-port-lines: Array of u8 values describing the number - of output lines per channel (R, G and B). - -Required sub-nodes: - - port: The Mali DP connection to an encoder input port. The connection - is modelled using the OF graph bindings specified in - Documentation/devicetree/bindings/graph.txt - -Optional properties: - - memory-region: phandle to a node describing memory (see - Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt) - to be used for the framebuffer; if not present, the framebuffer may - be located anywhere in memory. - - arm,malidp-arqos-high-level: integer of u32 value describing the ARQoS - levels of DP500's QoS signaling. - - -Example: - -/ { - ... - - dp0: malidp@6f200000 { - compatible = "arm,mali-dp650"; - reg = <0 0x6f200000 0 0x20000>; - memory-region = <&display_reserved>; - interrupts = <0 168 IRQ_TYPE_LEVEL_HIGH>, - <0 168 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "DE", "SE"; - clocks = <&oscclk2>, <&fpgaosc0>, <&fpgaosc1>, <&fpgaosc1>; - clock-names = "pxlclk", "mclk", "aclk", "pclk"; - arm,malidp-output-port-lines = /bits/ 8 <8 8 8>; - arm,malidp-arqos-high-level = <0xd000d000>; - port { - dp0_output: endpoint { - remote-endpoint = <&tda998x_2_input>; - }; - }; - }; - - ... -}; diff --git a/Documentation/devicetree/bindings/display/arm,malidp.yaml b/Documentation/devicetree/bindings/display/arm,malidp.yaml new file mode 100644 index 0000000000000..86b636662f803 --- /dev/null +++ b/Documentation/devicetree/bindings/display/arm,malidp.yaml @@ -0,0 +1,117 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/arm,malidp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm Mali Display Processor (Mali-DP) binding + +maintainers: + - Liviu Dudau <Liviu.Dudau(a)arm.com> + - Andre Przywara <andre.przywara(a)arm.com> + +description: |+ + The following bindings apply to a family of Display Processors sold as + licensable IP by ARM Ltd. The bindings describe the Mali DP500, DP550 and + DP650 processors that offer multiple composition layers, support for + rotation and scaling output. + +properties: + compatible: + enum: + - arm,mali-dp500 + - arm,mali-dp550 + - arm,mali-dp650 + + reg: + maxItems: 1 + + interrupts: + items: + - description: + The interrupt used by the Display Engine (DE). Can be shared with + the interrupt for the Scaling Engine (SE), but it will have to be + listed individually. + - description: + The interrupt used by the Scaling Engine (SE). Can be shared with + the interrupt for the Display Engine (DE), but it will have to be + listed individually. + + interrupt-names: + items: + - const: DE + - const: SE + + clock-names: + items: + - const: pxlclk + - const: mclk + - const: aclk + - const: pclk + + clocks: + items: + - description: the pixel clock feeding the output PLL of the processor + - description: the main processor clock + - description: the AXI interface clock + - description: the APB interface clock + + memory-region: + maxItems: 1 + description: + Phandle to a node describing memory to be used for the framebuffer. + If not present, the framebuffer may be located anywhere in memory. + + arm,malidp-output-port-lines: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: + Number of output lines/bits for each colour channel. + items: + - description: number of output lines for the red channel (R) + - description: number of output lines for the green channel (G) + - description: number of output lines for the blue channel (B) + + arm,malidp-arqos-high-level: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + integer describing the ARQoS levels of DP500's QoS signaling + + port: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Output endpoint of the controller, connecting the LCD panel signals. + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - port + - arm,malidp-output-port-lines + +examples: + - | + dp0: malidp@6f200000 { + compatible = "arm,mali-dp650"; + reg = <0x6f200000 0x20000>; + memory-region = <&display_reserved>; + interrupts = <168>, <168>; + interrupt-names = "DE", "SE"; + clocks = <&oscclk2>, <&fpgaosc0>, <&fpgaosc1>, <&fpgaosc1>; + clock-names = "pxlclk", "mclk", "aclk", "pclk"; + arm,malidp-output-port-lines = /bits/ 8 <8 8 8>; + arm,malidp-arqos-high-level = <0xd000d000>; + + port { + dp0_output: endpoint { + remote-endpoint = <&tda998x_2_input>; + }; + }; + }; + +... -- 2.25.1

2 1

[PATCH 09/11] dt-bindings: display: convert Arm HDLCD to DT schema
by Andre Przywara 27 Apr '22

27 Apr '22

The Arm HDLCD is a display controller that scans out a framebuffer and hands a signal to a digital encoder to generate a DVI or HDMI signal. Convert the existing DT binding to DT schema. Signed-off-by: Andre Przywara <andre.przywara(a)arm.com> --- .../devicetree/bindings/display/arm,hdlcd.txt | 79 ---------------- .../bindings/display/arm,hdlcd.yaml | 91 +++++++++++++++++++ 2 files changed, 91 insertions(+), 79 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/arm,hdlcd.txt create mode 100644 Documentation/devicetree/bindings/display/arm,hdlcd.yaml diff --git a/Documentation/devicetree/bindings/display/arm,hdlcd.txt b/Documentation/devicetree/bindings/display/arm,hdlcd.txt deleted file mode 100644 index 78bc24296f3e4..0000000000000 --- a/Documentation/devicetree/bindings/display/arm,hdlcd.txt +++ /dev/null @@ -1,79 +0,0 @@ -ARM HDLCD - -This is a display controller found on several development platforms produced -by ARM Ltd and in more modern of its' Fast Models. The HDLCD is an RGB -streamer that reads the data from a framebuffer and sends it to a single -digital encoder (DVI or HDMI). - -Required properties: - - compatible: "arm,hdlcd" - - reg: Physical base address and length of the controller's registers. - - interrupts: One interrupt used by the display controller to notify the - interrupt controller when any of the interrupt sources programmed in - the interrupt mask register have activated. - - clocks: A list of phandle + clock-specifier pairs, one for each - entry in 'clock-names'. - - clock-names: A list of clock names. For HDLCD it should contain: - - "pxlclk" for the clock feeding the output PLL of the controller. - -Required sub-nodes: - - port: The HDLCD connection to an encoder chip. The connection is modeled - using the OF graph bindings specified in - Documentation/devicetree/bindings/graph.txt. - -Optional properties: - - memory-region: phandle to a node describing memory (see - Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt) to be - used for the framebuffer; if not present, the framebuffer may be located - anywhere in memory. - - -Example: - -/ { - ... - - hdlcd@2b000000 { - compatible = "arm,hdlcd"; - reg = <0 0x2b000000 0 0x1000>; - interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&oscclk5>; - clock-names = "pxlclk"; - port { - hdlcd_output: endpoint@0 { - remote-endpoint = <&hdmi_enc_input>; - }; - }; - }; - - /* HDMI encoder on I2C bus */ - i2c@7ffa0000 { - .... - hdmi-transmitter@70 { - compatible = "....."; - reg = <0x70>; - port@0 { - hdmi_enc_input: endpoint { - remote-endpoint = <&hdlcd_output>; - }; - - hdmi_enc_output: endpoint { - remote-endpoint = <&hdmi_1_port>; - }; - }; - }; - - }; - - hdmi1: connector@1 { - compatible = "hdmi-connector"; - type = "a"; - port { - hdmi_1_port: endpoint { - remote-endpoint = <&hdmi_enc_output>; - }; - }; - }; - - ... -}; diff --git a/Documentation/devicetree/bindings/display/arm,hdlcd.yaml b/Documentation/devicetree/bindings/display/arm,hdlcd.yaml new file mode 100644 index 0000000000000..1fe8e07334152 --- /dev/null +++ b/Documentation/devicetree/bindings/display/arm,hdlcd.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/arm,hdlcd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm HDLCD display controller binding + +maintainers: + - Liviu Dudau <Liviu.Dudau(a)arm.com> + - Andre Przywara <andre.przywara(a)arm.com> + +description: |+ + The Arm HDLCD is a display controller found on several development platforms + produced by ARM Ltd and in more modern of its Fast Models. The HDLCD is an + RGB streamer that reads the data from a framebuffer and sends it to a single + digital encoder (DVI or HDMI). + +properties: + compatible: + const: arm,hdlcd + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clock-names: + const: pxlclk + + clocks: + maxItems: 1 + description: The input reference for the pixel clock. + + memory-region: + maxItems: 1 + description: + Phandle to a node describing memory to be used for the framebuffer. + If not present, the framebuffer may be located anywhere in memory. + + iommus: + maxItems: 1 + + port: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Output endpoint of the controller, connecting the LCD panel signals. + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - port + +examples: + - | + hdlcd@2b000000 { + compatible = "arm,hdlcd"; + reg = <0x2b000000 0x1000>; + interrupts = <0 85 4>; + clocks = <&oscclk5>; + clock-names = "pxlclk"; + port { + hdlcd_output: endpoint { + remote-endpoint = <&hdmi_enc_input>; + }; + }; + }; + + /* HDMI encoder on I2C bus */ + i2c { + #address-cells = <1>; + #size-cells = <0>; + hdmi-transmitter@70 { + compatible = "nxp,tda998x"; + reg = <0x70>; + port { + hdmi_enc_input: endpoint { + remote-endpoint = <&hdlcd_output>; + }; + }; + }; + + }; + +... -- 2.25.1

2 1

[PATCH v2 0/4] Flat-CCS eviction enhancements
by Ramalingam C 27 Apr '22

27 Apr '22

Flat-CCS eviction enhancements v2: Correcting the memory residency requirement for flat-ccs capability [Thomas] Ramalingam C (4): drm/i915/gt: GEM_BUG_ON unexpected NULL at scatterlist walking drm/i915/gt: optimize the ccs_sz calculation per chunk drm/i915/gt: Document the eviction of the Flat-CCS objects uapi/drm/i915: Document memory residency and Flat-CCS capability of obj drivers/gpu/drm/i915/gt/intel_migrate.c | 65 ++++++++++++------------- include/uapi/drm/i915_drm.h | 18 +++++++ 2 files changed, 50 insertions(+), 33 deletions(-) -- 2.20.1

2 8

[PATCH v2] drm/msm: add trace_dma_fence_emit to msm_gpu_submit
by Chia-I Wu 27 Apr '22

27 Apr '22

In practice, trace_dma_fence_init called from dma_fence_init is good enough and almost no driver calls trace_dma_fence_emit. But drm_sched and virtio both have cases where trace_dma_fence_init and trace_dma_fence_emit can be apart. It is easier for visualization tools to always use the more correct trace_dma_fence_emit when visualizing fence timelines. v2: improve commit message (Dmitry) Signed-off-by: Chia-I Wu <olvaffe(a)gmail.com> Cc: Rob Clark <robdclark(a)chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> --- drivers/gpu/drm/msm/msm_gpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c index faf0c242874e..a82193f41ea2 100644 --- a/drivers/gpu/drm/msm/msm_gpu.c +++ b/drivers/gpu/drm/msm/msm_gpu.c @@ -15,6 +15,7 @@ #include <linux/string_helpers.h> #include <linux/devcoredump.h> #include <linux/sched/task.h> +#include <trace/events/dma_fence.h> /* * Power Management: @@ -769,6 +770,7 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit) gpu->active_submits++; mutex_unlock(&gpu->active_lock); + trace_dma_fence_emit(submit->hw_fence); gpu->funcs->submit(gpu, submit); gpu->cur_ctx_seqno = submit->queue->ctx->seqno; -- 2.35.1.1178.g4f1659d476-goog

3 12

[PATCH v3] drm/doc: Add sections about tiny drivers and external refs to intro page
by Javier Martinez Canillas 27 Apr '22

27 Apr '22

Learning about the DRM subsystem could be quite overwhelming for newcomers but there are lots of useful talks, slides and articles available that can help to understand the needed concepts and ease the learning curve. There are also simple DRM drivers that can be used as example about how a DRM driver should look like. Add sections to the introduction page, that contains references to these. Suggested-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Signed-off-by: Javier Martinez Canillas <javierm(a)redhat.com> Acked-by: Pekka Paalanen <pekka.paalanen(a)collabora.com> Acked-by: Thomas Zimmermann <tzimmermann(a)suse.de> --- Changes in v3: - Fix typos and grammar errors that found when re-reading the changes. Changes in v2: - Remove paragraph that gave wrong impression that DRM is complex (Pekka Paalanen). - Add Thomas Zimmermann's and Pekka Paalanen's Acked-by tags. - Replace "Learning material" title with "External References" (Thomas Zimmermann). - Add a section about tiny DRM drivers being a good first example (Daniel Vetter). - Add some more external references that I found interesting since v1 was posted. Documentation/gpu/introduction.rst | 60 ++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index 25a56e9c0cfd..f05eccd2c07c 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -112,3 +112,63 @@ Please conduct yourself in a respectful and civilised manner when interacting with community members on mailing lists, IRC, or bug trackers. The community represents the project as a whole, and abusive or bullying behaviour is not tolerated by the project. + +Simple DRM drivers to use as examples +===================================== + +The DRM subsystem contains a lot of helper functions to ease writing drivers for +simple graphic devices. For example, the `drivers/gpu/drm/tiny/` directory has a +set of drivers that are simple enough to be implemented in a single source file. + +These drivers make use of the `struct drm_simple_display_pipe_funcs`, that hides +any complexity of the DRM subsystem and just requires drivers to implement a few +functions needed to operate the device. This could be used for devices that just +need a display pipeline with one full-screen scanout buffer feeding one output. + +The tiny DRM drivers are good examples to understand how DRM drivers should look +like. Since are just a few hundreds lines of code, they are quite easy to read. + +External References +=================== + +Delving into a Linux kernel subsystem for the first time can be an overwhelming +experience, one needs to get familiar with all the concepts and learn about the +subsystem's internals, among other details. + +To shallow the learning curve, this section contains a list of presentations +and documents that can be used to learn about DRM/KMS and graphics in general. + +There are different reasons why someone might want to get into DRM: porting an +existing fbdev driver, write a DRM driver for a new hardware, fixing bugs that +could face when working on the graphics user-space stack, etc. For this reason, +the learning material covers many aspects of the Linux graphics stack. From an +overview of the kernel and user-space stacks to very specific topics. + +The list is sorted in reverse chronological order, to keep the most up-to-date +material at the top. But all of them contain useful information, and it can be +valuable to go through older material to understand the rationale and context +in which the changes to the DRM subsystem were made. + +Conference talks +---------------- + +* `An Overview of the Linux and Userspace Graphics Stack <https://www.youtube.com/watch?v=wjAJmqwg47k>`_ - Paul Kocialkowski (2020) +* `Getting pixels on screen on Linux: introduction to Kernel Mode Setting <https://www.youtube.com/watch?v=haes4_Xnc5Q>`_ - Simon Ser (2020) +* `Everything Great about Upstream Graphics <https://www.youtube.com/watch?v=kVzHOgt6WGE>`_ - Daniel Vetter (2019) +* `An introduction to the Linux DRM subsystem <https://www.youtube.com/watch?v=LbDOCJcDRoo>`_ - Maxime Ripard (2017) +* `Embrace the Atomic (Display) Age <https://www.youtube.com/watch?v=LjiB_JeDn2M>`_ - Daniel Vetter (2016) +* `Anatomy of an Atomic KMS Driver <https://www.youtube.com/watch?v=lihqR9sENpc>`_ - Laurent Pinchart (2015) +* `Atomic Modesetting for Drivers <https://www.youtube.com/watch?v=kl9suFgbTc8>`_ - Daniel Vetter (2015) +* `Anatomy of an Embedded KMS Driver <https://www.youtube.com/watch?v=Ja8fM7rTae4>`_ - Laurent Pinchart (2013) + +Slides and articles +------------------- + +* `Understanding the Linux Graphics Stack <https://bootlin.com/doc/training/graphics/graphics-slides.pdf>`_ - Bootlin (2022) +* `DRM KMS overview <https://wiki.st.com/stm32mpu/wiki/DRM_KMS_overview>`_ - STMicroelectronics (2021) +* `Linux graphic stack <https://studiopixl.com/2017-05-13/linux-graphic-stack-an-overview>`_ - Nathan Gauër (2017) +* `Atomic mode setting design overview, part 1 <https://lwn.net/Articles/653071/>`_ - Daniel Vetter (2015) +* `Atomic mode setting design overview, part 2 <https://lwn.net/Articles/653466/>`_ - Daniel Vetter (2015) +* `The DRM/KMS subsystem from a newbie’s point of view <https://bootlin.com/pub/conferences/2014/elce/brezillon-drm-kms/brezillon-d…>`_ - Boris Brezillon (2014) +* `A brief introduction to the Linux graphics stack <https://blogs.igalia.com/itoral/2014/07/29/a-brief-introduction-to-the-linu…>`_ - Iago Toral (2014) +* `The Linux Graphics Stack <https://blog.mecheye.net/2012/06/the-linux-graphics-stack/>`_ - Jasper St. Pierre (2012) -- 2.35.1

2 2

[RESEND PATCH v3] drm/cma-helper: Describe what a "contiguous chunk" actually means
by Daniel Thompson 27 Apr '22

27 Apr '22

Since it's inception in 2012 it has been understood that the DRM GEM CMA helpers do not depend on CMA as the backend allocator. In fact the first bug fix to ensure the cma-helpers work correctly with an IOMMU backend appeared in 2014. However currently the documentation for drm_gem_cma_create() talks about "a contiguous chunk of memory" without making clear which address space it will be a contiguous part of. Additionally the CMA introduction is actively misleading because it only contemplates the CMA backend. This matters because when the device accesses the bus through an IOMMU (and don't use the CMA backend) then the allocated memory is contiguous only in the IOVA space. This is a significant difference compared to the CMA backend and the behaviour can be a surprise even to someone who does a reasonable level of code browsing (but doesn't find all the relevant function pointers ;-) ). Improve the kernel doc comments accordingly. Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> --- Notes: RESEND is unaltered but rebased on v5.18-rc3. Changes in v3: - Rebased on v5.17-rc2 - Minor improvements to wording. Changes in v2: - Oops. I did a final proof read and accidentally committed these changes as a seperate patch. This means that v1 contains only one tenth of the actual patch. This is fixed in v2. Many apologies for the noise! drivers/gpu/drm/drm_gem_cma_helper.c | 39 +++++++++++++++++++++------- 1 file changed, 29 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c b/drivers/gpu/drm/drm_gem_cma_helper.c index f36734c2c9e1..42abee9a0f4f 100644 --- a/drivers/gpu/drm/drm_gem_cma_helper.c +++ b/drivers/gpu/drm/drm_gem_cma_helper.c @@ -26,12 +26,22 @@ /** * DOC: cma helpers * - * The Contiguous Memory Allocator reserves a pool of memory at early boot - * that is used to service requests for large blocks of contiguous memory. + * The DRM GEM/CMA helpers are a means to provide buffer objects that are + * presented to the device as a contiguous chunk of memory. This is useful + * for devices that do not support scatter-gather DMA (either directly or + * by using an intimately attached IOMMU). * - * The DRM GEM/CMA helpers use this allocator as a means to provide buffer - * objects that are physically contiguous in memory. This is useful for - * display drivers that are unable to map scattered buffers via an IOMMU. + * Despite the name, the DRM GEM/CMA helpers are not hardwired to use the + * Contiguous Memory Allocator (CMA). + * + * For devices that access the memory bus through an (external) IOMMU then + * the buffer objects are allocated using a traditional page-based + * allocator and may be scattered through physical memory. However they + * are contiguous in the IOVA space so appear contiguous to devices using + * them. + * + * For other devices then the helpers rely on CMA to provide buffer + * objects that are physically contiguous in memory. * * For GEM callback helpers in struct &drm_gem_object functions, see likewise * named functions with an _object_ infix (e.g., drm_gem_cma_object_vmap() wraps @@ -111,8 +121,14 @@ __drm_gem_cma_create(struct drm_device *drm, size_t size, bool private) * @drm: DRM device * @size: size of the object to allocate * - * This function creates a CMA GEM object and allocates a contiguous chunk of - * memory as backing store. + * This function creates a CMA GEM object and allocates memory as backing store. + * The allocated memory will occupy a contiguous chunk of bus address space. + * + * For devices that are directly connected to the memory bus then the allocated + * memory will be physically contiguous. For devices that access through an + * IOMMU, then the allocated memory is not expected to be physically contiguous + * because having contiguous IOVAs is sufficient to meet a devices DMA + * requirements. * * Returns: * A struct drm_gem_cma_object * on success or an ERR_PTR()-encoded negative @@ -162,9 +178,12 @@ EXPORT_SYMBOL_GPL(drm_gem_cma_create); * @size: size of the object to allocate * @handle: return location for the GEM handle * - * This function creates a CMA GEM object, allocating a physically contiguous - * chunk of memory as backing store. The GEM object is then added to the list - * of object associated with the given file and a handle to it is returned. + * This function creates a CMA GEM object, allocating a chunk of memory as + * backing store. The GEM object is then added to the list of object associated + * with the given file and a handle to it is returned. + * + * The allocated memory will occupy a contiguous chunk of bus address space. + * See drm_gem_cma_create() for more details. * * Returns: * A struct drm_gem_cma_object * on success or an ERR_PTR()-encoded negative base-commit: b2d229d4ddb17db541098b83524d901257e93845 -- 2.35.1

2 1

← Newer
1
...
21
22
23
24
25
26
27
...
96
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2022