dri-devel October 2021

dri-devel@lists.freedesktop.org

347 participants
825 discussions

[PATCH] [RESEND] drm/rcar: stop using 'imply' for dependencies
by Arnd Bergmann 09 Nov '21

09 Nov '21

From: Arnd Bergmann <arnd(a)arndb.de> The meaning of the 'imply' keyword has changed recently, and neither the old meaning (select the symbol if its dependencies are met) nor the new meaning (enable it by default, but let the user set any other setting) is what we want here. Work around this by adding two more Kconfig options that lead to the correct behavior: if DRM_RCAR_USE_CMM and DRM_RCAR_USE_LVDS are enabled, that portion of the driver becomes usable, and no configuration results in a link error. This avoids a link failure: arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_begin': rcar_du_crtc.c:(.text+0x1444): undefined reference to `rcar_cmm_setup' arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_enable': rcar_du_crtc.c:(.text+0x14d4): undefined reference to `rcar_cmm_enable' arm-linux-gnueabi-ld: rcar_du_crtc.c:(.text+0x1548): undefined reference to `rcar_cmm_setup' arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_disable': rcar_du_crtc.c:(.text+0x18b8): undefined reference to `rcar_cmm_disable' arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_kms.o: in function `rcar_du_modeset_init': Link: https://lore.kernel.org/all/20200417155553.675905-5-arnd@arndb.de/ Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- This was last posted as part of a longer series to rework the DRM dependencies in a more logical way. The rest of the series is still open, but this one is needed as a bug fix regardless of the rest. --- drivers/gpu/drm/rcar-du/Kconfig | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig index b47e74421e34..3e588ddba245 100644 --- a/drivers/gpu/drm/rcar-du/Kconfig +++ b/drivers/gpu/drm/rcar-du/Kconfig @@ -4,8 +4,6 @@ config DRM_RCAR_DU depends on DRM && OF depends on ARM || ARM64 depends on ARCH_RENESAS || COMPILE_TEST - imply DRM_RCAR_CMM - imply DRM_RCAR_LVDS select DRM_KMS_HELPER select DRM_KMS_CMA_HELPER select DRM_GEM_CMA_HELPER @@ -14,13 +12,17 @@ config DRM_RCAR_DU Choose this option if you have an R-Car chipset. If M is selected the module will be called rcar-du-drm. -config DRM_RCAR_CMM - tristate "R-Car DU Color Management Module (CMM) Support" - depends on DRM && OF +config DRM_RCAR_USE_CMM + bool "R-Car DU Color Management Module (CMM) Support" depends on DRM_RCAR_DU + default DRM_RCAR_DU help Enable support for R-Car Color Management Module (CMM). +config DRM_RCAR_CMM + def_tristate DRM_RCAR_DU + depends on DRM_RCAR_USE_CMM + config DRM_RCAR_DW_HDMI tristate "R-Car Gen3 and RZ/G2 DU HDMI Encoder Support" depends on DRM && OF @@ -28,15 +30,20 @@ config DRM_RCAR_DW_HDMI help Enable support for R-Car Gen3 or RZ/G2 internal HDMI encoder. +config DRM_RCAR_USE_LVDS + bool "R-Car DU LVDS Encoder Support" + depends on DRM_BRIDGE && OF + default DRM_RCAR_DU + help + Enable support for the R-Car Display Unit embedded LVDS encoders. + config DRM_RCAR_LVDS - tristate "R-Car DU LVDS Encoder Support" - depends on DRM && DRM_BRIDGE && OF + def_tristate DRM_RCAR_DU + depends on DRM_RCAR_USE_LVDS select DRM_KMS_HELPER select DRM_PANEL select OF_FLATTREE select OF_OVERLAY - help - Enable support for the R-Car Display Unit embedded LVDS encoders. config DRM_RCAR_VSP bool "R-Car DU VSP Compositor Support" if ARM -- 2.29.2

3 2

[PATCH v6 0/9] drm/omap: Add virtual-planes support
by Neil Armstrong 09 Nov '21

09 Nov '21

This patchset is the follow-up the v4 patchset from Benoit Parrot at [1]. This patch series adds virtual-plane support to omapdrm driver to allow the use of display wider than 2048 pixels. In order to do so we introduce the concept of hw_overlay which can then be dynamically allocated to a plane. When the requested output width exceed what be supported by one overlay a second is then allocated if possible to handle display wider then 2048. This series replaces an earlier series which was DT based and using statically allocated resources. This implementation is inspired from the work done in msm/disp/mdp5 driver. Changes since v5 at [2]: - Patch 1: renamed width/height_fp to max_width/height - Patch 2: no changes - Patch 3: removed possible_crtcs stuff, added cleanup on failure to allocate, removed name in omap_plane struct & plane_id_to_name in omap_plane.c, switched all omap_plane->name to plane->name or omap_plane->id - Patch 4: aligned omap_plane_atomic_duplicate_state the the crtc style - Patch 5: removed glob_obj_lock & reformated global state declaration in omap_drv.h - Patch 6: moved drm_atomic_helper_check_plane_state() from atomic_check() in separate commit, removed zpos change, updated debug messages to be useful, renamed omap_overlay_disable() to omap_overlay_update_state(), added useful comments for omap_overlay_assign() & omap_overlay_update_state(), simplified omap_overlay_assign() & omap_overlay_update_state() for actual use-cases, refactored omap_plane_atomic_check() changes to be cleaner & simpler - Patch 7: no changes (except possible_crtcs print removal) - Patch 8: Reformated omap_plane_atomic_check() & omap_overlay_assign() changes to match previous patches layout Changes since v4 at [1]: - rebased on v5.15-rc2 - adapted to drm_atomic_get_new/old_plane_state() - tested on Beagle-x15 - checked for non-regression on Beagle-x15 - removed unused "state" variable in omap_global_state [1] https://lore.kernel.org/all/20181012201703.29065-1-bparrot@ti.com/ [2] https://lore.kernel.org/all/20210923070701.145377-1-narmstrong@baylibre.com/ Benoit Parrot (8): drm/omap: Add ability to check if requested plane modes can be supported drm/omap: Add ovl checking funcs to dispc_ops drm/omap: introduce omap_hw_overlay drm/omap: omap_plane: subclass drm_plane_state drm/omap: Add global state as a private atomic object drm/omap: dynamically assign hw overlays to planes drm/omap: add plane_atomic_print_state support drm/omap: Add a 'right overlay' to plane state Neil Armstrong (1): drm/omap: add sanity plane state check drivers/gpu/drm/omapdrm/Makefile | 1 + drivers/gpu/drm/omapdrm/dss/dispc.c | 31 ++- drivers/gpu/drm/omapdrm/dss/dss.h | 5 + drivers/gpu/drm/omapdrm/omap_drv.c | 189 ++++++++++++- drivers/gpu/drm/omapdrm/omap_drv.h | 24 ++ drivers/gpu/drm/omapdrm/omap_fb.c | 33 ++- drivers/gpu/drm/omapdrm/omap_fb.h | 4 +- drivers/gpu/drm/omapdrm/omap_overlay.c | 212 +++++++++++++++ drivers/gpu/drm/omapdrm/omap_overlay.h | 35 +++ drivers/gpu/drm/omapdrm/omap_plane.c | 354 +++++++++++++++++++++---- drivers/gpu/drm/omapdrm/omap_plane.h | 1 + 11 files changed, 830 insertions(+), 59 deletions(-) create mode 100644 drivers/gpu/drm/omapdrm/omap_overlay.c create mode 100644 drivers/gpu/drm/omapdrm/omap_overlay.h base-commit: e4e737bb5c170df6135a127739a9e6148ee3da82 -- 2.25.1

2 20

linux-next: build failure after merge of the drm-misc tree
by Stephen Rothwell 09 Nov '21

09 Nov '21

Hi all, After merging the drm-misc tree, today's linux-next build (arm multi_v7_defconfig) failed like this: drivers/gpu/drm/drm_modeset_lock.c:111:29: error: conflicting types for '__stack_depot_save' 111 | static depot_stack_handle_t __stack_depot_save(void) | ^~~~~~~~~~~~~~~~~~ In file included from include/linux/page_ext.h:7, from include/linux/mm.h:25, from include/linux/kallsyms.h:13, from include/linux/bpf.h:20, from include/linux/bpf-cgroup.h:5, from include/linux/cgroup-defs.h:22, from include/linux/cgroup.h:28, from include/linux/memcontrol.h:13, from include/linux/swap.h:9, from include/linux/suspend.h:5, from include/linux/regulator/consumer.h:35, from include/linux/i2c.h:18, from include/drm/drm_crtc.h:28, from include/drm/drm_atomic.h:31, from drivers/gpu/drm/drm_modeset_lock.c:24: include/linux/stackdepot.h:18:22: note: previous declaration of '__stack_depot_save' was here 18 | depot_stack_handle_t __stack_depot_save(unsigned long *entries, | ^~~~~~~~~~~~~~~~~~ Caused by commit cd06ab2fd48f ("drm/locking: add backtrace for locking contended locks without backoff") This may only have been revealed because of another fix I have had to apply today. I have applied the following patch for today. From: Stephen Rothwell <sfr(a)canb.auug.org.au> Date: Fri, 15 Oct 2021 20:17:52 +1100 Subject: [PATCH] drm/locking: fix for name conflict Fixes: cd06ab2fd48f ("drm/locking: add backtrace for locking contended locks without backoff") Signed-off-by: Stephen Rothwell <sfr(a)canb.auug.org.au> --- drivers/gpu/drm/drm_modeset_lock.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c index 4d32b61fa1fd..ee36dd20900d 100644 --- a/drivers/gpu/drm/drm_modeset_lock.c +++ b/drivers/gpu/drm/drm_modeset_lock.c @@ -79,7 +79,7 @@ static DEFINE_WW_CLASS(crtc_ww_class); #if IS_ENABLED(CONFIG_DRM_DEBUG_MODESET_LOCK) -static noinline depot_stack_handle_t __stack_depot_save(void) +static noinline depot_stack_handle_t __drm_stack_depot_save(void) { unsigned long entries[8]; unsigned int n; @@ -108,7 +108,7 @@ static void __stack_depot_print(depot_stack_handle_t stack_depot) kfree(buf); } #else /* CONFIG_DRM_DEBUG_MODESET_LOCK */ -static depot_stack_handle_t __stack_depot_save(void) +static depot_stack_handle_t __drm_stack_depot_save(void) { return 0; } @@ -317,7 +317,7 @@ static inline int modeset_lock(struct drm_modeset_lock *lock, ret = 0; } else if (ret == -EDEADLK) { ctx->contended = lock; - ctx->stack_depot = __stack_depot_save(); + ctx->stack_depot = __drm_stack_depot_save(); } return ret; -- 2.33.0 -- Cheers, Stephen Rothwell

5 10

[PATCH v8, 00/17] Support multi hardware decode using of_platform_populate
by Yunfei Dong 09 Nov '21

09 Nov '21

This series adds support for multi hardware decode into mtk-vcodec, by first adding use of_platform_populate to manage each hardware information: interrupt, clock, register bases and power. Secondly add core work queue to deal with core hardware message, at the same time, add msg queue for different hardware share messages. Lastly, the architecture of different specs are not the same, using specs type to separate them. This series has been tested with both MT8183 and MT8173. Decoding was working for both chips. Patches 1~3 rewrite get register bases and power on/off interface. Patches 4 build decoder pm file to module. Patches 5 add to support 8192. Patch 6 add component framework to support multi hardware. Patch 7 separate video encoder and decoder document Patches 8-17 add interfaces to support core hardware. --- Changes compared with v7: - add new patch 4 to build decoder pm file as module - add new patch 5 to support 8192 - fix comments for patch 6/17 - change some logic for using work queue instead of create thread for core hardware decode for patch 10/17 - using work queue for hardware decode instead of create thread for patch 13/17 - add returen value for patch 14/17 - fix yaml check fail 15/17 Changes compared with v6: - Use of_platform_populate to manage multi hardware, not component framework for patch 4/15 - Re-write dtsi document for hardware architecture changed for patch 13/15 -The dtsi will write like below in patch 13/15: vcodec_dec: vcodec_dec@16000000 { compatible = "mediatek,mt8192-vcodec-dec"; #address-cells = <2>; #size-cells = <2>; ranges; reg = <0 0x16000000 0 0x1000>; /* VDEC_SYS */ mediatek,scp = <&scp>; iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>; dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; vcodec_lat { compatible = "mediatek,mtk-vcodec-lat"; reg = <0 0x16010000 0 0x800>; /* VDEC_MISC */ reg-name = "reg-misc"; interrupts = <GIC_SPI 426 IRQ_TYPE_LEVEL_HIGH 0>; iommus = <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD_EXT>, <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD2_EXT>, <&iommu0 M4U_PORT_L5_VDEC_LAT0_AVC_MV_EXT>, <&iommu0 M4U_PORT_L5_VDEC_LAT0_PRED_RD_EXT>, <&iommu0 M4U_PORT_L5_VDEC_LAT0_TILE_EXT>, <&iommu0 M4U_PORT_L5_VDEC_LAT0_WDMA_EXT>, <&iommu0 M4U_PORT_L5_VDEC_LAT0_RG_CTRL_DMA_EXT>, <&iommu0 M4U_PORT_L5_VDEC_UFO_ENC_EXT>; clocks = <&topckgen CLK_TOP_VDEC_SEL>, <&vdecsys_soc CLK_VDEC_SOC_VDEC>, <&vdecsys_soc CLK_VDEC_SOC_LAT>, <&vdecsys_soc CLK_VDEC_SOC_LARB1>, <&topckgen CLK_TOP_MAINPLL_D4>; clock-names = "vdec-sel", "vdec-soc-vdec", "vdec-soc-lat", "vdec-vdec", "vdec-top"; assigned-clocks = <&topckgen CLK_TOP_VDEC_SEL>; assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D4>; power-domains = <&spm MT8192_POWER_DOMAIN_VDEC>; }; vcodec_core { compatible = "mediatek,mtk-vcodec-core"; reg = <0 0x16025000 0 0x1000>; /* VDEC_CORE_MISC */ reg-names = "reg-misc"; interrupts = <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH 0>; iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>, <&iommu0 M4U_PORT_L4_VDEC_UFO_EXT>, <&iommu0 M4U_PORT_L4_VDEC_PP_EXT>, <&iommu0 M4U_PORT_L4_VDEC_PRED_RD_EXT>, <&iommu0 M4U_PORT_L4_VDEC_PRED_WR_EXT>, <&iommu0 M4U_PORT_L4_VDEC_PPWRAP_EXT>, <&iommu0 M4U_PORT_L4_VDEC_TILE_EXT>, <&iommu0 M4U_PORT_L4_VDEC_VLD_EXT>, <&iommu0 M4U_PORT_L4_VDEC_VLD2_EXT>, <&iommu0 M4U_PORT_L4_VDEC_AVC_MV_EXT>, <&iommu0 M4U_PORT_L4_VDEC_RG_CTRL_DMA_EXT>; clocks = <&topckgen CLK_TOP_VDEC_SEL>, <&vdecsys CLK_VDEC_VDEC>, <&vdecsys CLK_VDEC_LAT>, <&vdecsys CLK_VDEC_LARB1>, <&topckgen CLK_TOP_MAINPLL_D4>; clock-names = "vdec-sel", "vdec-soc-vdec", "vdec-soc-lat", "vdec-vdec", "vdec-top"; assigned-clocks = <&topckgen CLK_TOP_VDEC_SEL>; assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D4>; power-domains = <&spm MT8192_POWER_DOMAIN_VDEC2>; }; }; Changes compared with v5: - Add decoder hardware block diagram for patch 13/15 Changes compared with v4: - Fix comments for patch 4/15 >> + if (dev->is_comp_supported) { >> + ret = mtk_vcodec_init_master(dev); >> + if (ret < 0) >> + goto err_component_match; >> + } else { >> + platform_set_drvdata(pdev, dev); >> + } Fix platform_set_drvdata. - Fix build error for patch 9/15 - Add depend patch in case of error header file for patch 13/15 Changes compared with v3: - Fix return value for patch 1/15 - Fix comments for patch 4/15 > Looking up "mediatek,mtk-vcodec-core" to determine if it uses component framwork sounds like... Add prameter in pdata, for all platform will use compoent after mt8183 >> + if (dev->is_comp_supported) { >> + ret = mtk_vcodec_init_master(dev); >> + if (ret < 0) >> + goto err_component_match; >> + } else { >> + platform_set_drvdata(pdev, dev); >> + } > + Has asked the same question in [1]. Why it removes the > +platform_set_drvdata() above? mtk_vcodec_init_master() also calls platform_set_drvdata(). Must call component_master_add_with_match after platform_set_drvdata for component architecture. - Fix yaml files check fail for patch 5/15 - Fix yaml file check fail for patch 14/15 Changes compared with v1: - Fix many comments for patch 3/14 - Remove unnecessary code for patch 4/14 - Using enum mtk_vdec_hw_count instead of magic numbers for patch 6/14 - Reconstructed get/put lat buffer for lat and core hardware for patch 7/14 - Using yaml format to instead of txt file for patch 12/14 Yunfei Dong (17): media: mtk-vcodec: Get numbers of register bases from DT media: mtk-vcodec: Align vcodec wake up interrupt interface media: mtk-vcodec: Refactor vcodec pm interface media: mtk-vcodec: Build decoder pm file as module media: mtk-vcodec: Support MT8192 media: mtk-vcodec: Manage multi hardware information dt-bindings: media: mtk-vcodec: Separate video encoder and decoder dt-bindings media: mtk-vcodec: Use pure single core for MT8183 media: mtk-vcodec: Add irq interface for multi hardware media: mtk-vcodec: Add msg queue feature for lat and core architecture media: mtk-vcodec: Generalize power and clock on/off interfaces media: mtk-vcodec: Add new interface to lock different hardware media: mtk-vcodec: Add work queue for core hardware decode media: mtk-vcodec: Support 34bits dma address for vdec dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8192 media: mtk-vcodec: Add core dec and dec end ipi msg media: mtk-vcodec: Use codec type to separate different hardware .../media/mediatek,vcodec-comp-decoder.yaml | 273 +++++++++++++++++ .../media/mediatek,vcodec-decoder.yaml | 176 +++++++++++ .../media/mediatek,vcodec-encoder.yaml | 187 ++++++++++++ .../bindings/media/mediatek-vcodec.txt | 131 -------- drivers/media/platform/mtk-vcodec/Makefile | 10 +- .../platform/mtk-vcodec/mtk_vcodec_dec.c | 4 +- .../platform/mtk-vcodec/mtk_vcodec_dec.h | 1 + .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 212 ++++++++++--- .../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 166 ++++++++++ .../platform/mtk-vcodec/mtk_vcodec_dec_hw.h | 55 ++++ .../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 107 +++++-- .../platform/mtk-vcodec/mtk_vcodec_dec_pm.h | 13 +- .../mtk-vcodec/mtk_vcodec_dec_stateful.c | 2 + .../mtk-vcodec/mtk_vcodec_dec_stateless.c | 20 ++ .../platform/mtk-vcodec/mtk_vcodec_drv.h | 75 ++++- .../platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 12 +- .../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 1 - .../platform/mtk-vcodec/mtk_vcodec_intr.c | 27 +- .../platform/mtk-vcodec/mtk_vcodec_intr.h | 4 +- .../platform/mtk-vcodec/mtk_vcodec_util.c | 87 +++++- .../platform/mtk-vcodec/mtk_vcodec_util.h | 8 +- .../platform/mtk-vcodec/vdec/vdec_h264_if.c | 2 +- .../mtk-vcodec/vdec/vdec_h264_req_if.c | 2 +- .../platform/mtk-vcodec/vdec/vdec_vp8_if.c | 2 +- .../platform/mtk-vcodec/vdec/vdec_vp9_if.c | 2 +- .../media/platform/mtk-vcodec/vdec_drv_if.c | 21 +- .../media/platform/mtk-vcodec/vdec_ipi_msg.h | 16 +- .../platform/mtk-vcodec/vdec_msg_queue.c | 286 ++++++++++++++++++ .../platform/mtk-vcodec/vdec_msg_queue.h | 148 +++++++++ .../media/platform/mtk-vcodec/vdec_vpu_if.c | 46 ++- .../media/platform/mtk-vcodec/vdec_vpu_if.h | 22 ++ .../platform/mtk-vcodec/venc/venc_h264_if.c | 2 +- .../platform/mtk-vcodec/venc/venc_vp8_if.c | 2 +- 33 files changed, 1842 insertions(+), 280 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/mediatek,vcodec-comp-decoder.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml create mode 100644 Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml delete mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.h create mode 100644 drivers/media/platform/mtk-vcodec/vdec_msg_queue.c create mode 100644 drivers/media/platform/mtk-vcodec/vdec_msg_queue.h -- 2.25.1

5 28

[PATCH] doc: gpu: Add document describing buffer exchange
by Daniel Stone 09 Nov '21

09 Nov '21

Since there's a lot of confusion around this, document both the rules and the best practice around negotiating, allocating, importing, and using buffers when crossing context/process/device/subsystem boundaries. This ties up all of dmabuf, formats and modifiers, and their usage. Signed-off-by: Daniel Stone <daniels(a)collabora.com> --- This is just a quick first draft, inspired by: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3197#note_1048637 It's not complete or perfect, but I'm off to eat a roast then have a nice walk in the sun, so figured it'd be better to dash it off rather than let it rot on my hard drive. .../gpu/exchanging-pixel-buffers.rst | 285 ++++++++++++++++++ Documentation/gpu/index.rst | 1 + 2 files changed, 286 insertions(+) create mode 100644 Documentation/gpu/exchanging-pixel-buffers.rst diff --git a/Documentation/gpu/exchanging-pixel-buffers.rst b/Documentation/gpu/exchanging-pixel-buffers.rst new file mode 100644 index 000000000000..75c4de13d5c8 --- /dev/null +++ b/Documentation/gpu/exchanging-pixel-buffers.rst @@ -0,0 +1,285 @@ +.. Copyright 2021 Collabora Ltd. + +======================== +Exchanging pixel buffers +======================== + +As originally designed, the Linux graphics subsystem had extremely limited +support for sharing pixel-buffer allocations between processes, devices, and +subsystems. Modern systems require extensive integration between all three +classes; this document details how applications and kernel subsystems should +approach this sharing for two-dimensional image data. + +It is written with reference to the DRM subsystem for GPU and display devices, +V4L2 for media devices, and also to Vulkan, EGL and Wayland, for userspace +support, however any other subsystems should also follow this design and advice. + + +Formats and modifiers +===================== + +Each buffer must have an underlying format. This format describes the data which +can be stored and loaded for each pixel. Although each subsystem has its own +format descriptions (e.g. V4L2 and fbdev), the `DRM_FORMAT_*` tokens should be +reused wherever possible, as they are the standard descriptions used for +interchange. + +Each `DRM_FORMAT_*` token describes the per-pixel data available, in terms of +the translation between one or more pixels in memory, and the color data +contained within that memory. The number and type of color channels are +described: whether they are RGB or YUV, integer or floating-point, the size +of each channel and their locations within the pixel memory, and the +relationship between color planes. + +For example, `DRM_FORMAT_ARGB8888` describes a format in which each pixel has a +single 32-bit value in memory. Alpha, red, green, and blue, color channels are +available at 8-byte precision per channel, ordered respectively from most to +least significant bits in little-endian storage. As a more complex example, +`DRM_FORMAT_NV12` describes a format in which luma and chroma YUV samples are +stored in separate memory planes, where the chroma plane is stored at half the +resolution in both dimensions (i.e. one U/V chroma sample is stored for each 2x2 +pixel grouping). + +Format modifiers describe a translation mechanism between these per-pixel memory +samples, and the actual memory storage for the buffer. The most straightforward +modifier is `DRM_FORMAT_MOD_LINEAR`, describing a scheme in which each pixel has +contiguous storage beginning at (0,0); each pixel's location in memory will be +`base + (y * stride) + (x * bpp)`. This is considered the baseline interchange +format, and most convenient for CPU access. + +Modern hardware employs much more sophisticated access mechanisms, typically +making use of tiled access and possibly also compression. For example, the +`DRM_FORMAT_MOD_VIVANTE_TILED` modifier describes memory storage where pixels +are stored in 4x4 blocks arranged in row-major ordering, i.e. the first tile in +memory stores pixels (0,0) to (3,3) inclusive, and the second tile in memory +stores pixels (4,0) to (7,3) inclusive. + +Some modifiers may modify the number of memory buffers required to store the +data; for example, the `I915_FORMAT_MOD_Y_TILED_CCS` modifier adds a second +memory buffer to RGB formats in which it stores data about the status of every +tile, notably including whether the tile is fully populated with pixel data, or +can be expanded from a single solid color. + +These extended layouts are highly vendor-specific, and even specific to +particular generations or configurations of devices per-vendor. For this reason, +support of modifiers must be explicitly enumerated and negotiated by all users +in order to ensure a compatible and optimal pipeline, as discussed below. + + +Dimensions and size +=================== + +Each pixel buffer must be accompanied by logical pixel dimensions. This refers +to the number of unique samples which can be extracted from, or stored to, the +underlying memory storage. For example, even though a 1920x1080 +`DRM_FORMAT_NV12` buffer has a luma plane containing 1920x1080 samples for the Y +component, and 960x540 samples for the U and V components, the overall buffer is +still described as having dimensions of 1920x1080. + +The in-memory storage of a buffer is not guaranteed to begin immediately at the +base address of the underlying memory, nor is it guaranteed that the memory +storage is tightly clipped to either dimension. + +Each plane must therefore be described with an `offset` in bytes, which will be +added to the base address of the memory storage before performing any per-pixel +calculations. This may be used to combine multiple planes into a single pixel +buffer; for example, `DRM_FORMAT_NV12` may be stored in a single memory buffer +where the luma plane's storage begins immediately at the start of the buffer +with an offset of 0, and the chroma plane's storage begins after the offset of +the luma plane as expressed through its offset. + +Each plane must also have a `stride` in bytes, expressing the offset in memory +between two contiguous scanlines. For example, a `DRM_FORMAT_MOD_LINEAR` buffer +with dimensions of 1000x1000 may have been allocated as if it were 1024x1000, in +order to allow for aligned access patterns. In this case, the buffer will still +be described with a width of 1000, however the stride will be `1024 * bpp`, +indicating that there are 24 pixels at the positive extreme of the x axis whose +values are not significant. + +Buffers may also be padded further in the y dimension, simply by allocating a +larger area than would ordinarily be required. For example, many media decoders +are not able to natively output buffers of height 1080, but instead require an +effective height of 1088 pixels. In this case, the buffer continues to be +described as having a height of 1080, with the memory allocation for each buffer +being increased to account for the extra padding. + + +Enumeration +=========== + +Every user of pixel buffers must be able to enumerate a set of supported formats +and modifiers, described together. Within KMS, this is achieved with the +`IN_FORMATS` property on each DRM plane, listing the supported DRM formats, and +the modifiers supported for each format. In userspace, this is supported through +the `EGL_EXT_image_dma_buf_import_modifiers` extension entrypoints for EGL, the +`VK_EXT_image_drm_format_modifier` extension for Vulkan, and the +`zwp_linux_dmabuf_v1` extension for Wayland. + +Each of these interfaces allows users to query a set of supported +format+modifier combinations. + + +Negotiation +=========== + +It is the responsibility of userspace to negotiate an acceptable format+modifier +combination for its usage. This is performed through a simple intersection of +lists. For example, if a user wants to use Vulkan to render an image to be +displayed on a KMS plane, it must: + - query KMS for the `IN_FORMATS` property for the given plane + - query Vulkan for the supported formats for its physical device + - intersect these formats to determine the most appropriate one + - for this format, intersect the lists of supported modifiers for both KMS and + Vulkan, to obtain a final list of acceptable modifiers for that format + +This intersection must be performed for all usages. For example, if the user +also wishes to encode the image to a video stream, it must query the media API +it intends to use for encoding for the set of modifiers it supports, and +additionally intersect against this list. + +If the intersection of all lists is an empty list, it is not possible to share +buffers in this way, and an alternate strategy must be considered (e.g. using +CPU access routines to copy data between the different uses, with the +corresponding performance cost). + +The resulting modifier list is unsorted; the order is not significant. + + +Allocation +========== + +Once userspace has determined an appropriate format, and corresponding list of +acceptable modifiers, it must allocate the buffer. As there is no universal +buffer-allocation interface available at either kernel or userspace level, the +client makes an arbitrary choice of allocation interface such as Vulkan, GBM, or +a media API. + +Each allocation request must take, at a minimum: the pixel format, a list of +acceptable modifiers, and the buffer's width and height. Each API may extend +this set of properties in different ways, such as allowing allocation in more +than two dimensions, intended usage patterns, etc. + +The component which allocates the buffer will make an arbitrary choice of what +it considers the 'best' modifier within the acceptable list for the requested +allocation, any padding required, and further properties of the underlying +memory buffers such as whether they are stored in system or device-specific +memory, whether or not they are physically contiguous, and their cache mode. +These properties of the memory buffer are not visible to userspace, however the +`dma-heaps` API is an effort to address this. + +After allocation, the client must query the allocator to determine the actual +modifier selected for the buffer, as well as the per-plane offset and stride. +Allocators are not permitted to vary the format in use, to select a modifier not +provided within the acceptable list, nor to vary the pixel dimensions other than +the padding expressed through offset, stride, and size. + + +Import +====== + +To use a buffer within a different context, device, or subsystem, the user +passes these parameters (format, modifier, width, height, and per-plane offset +and stride) to an importing API. + +Each memory plane is referred to by a buffer handle, which may be unique or +duplicated within a buffer. For example, a `DRM_FORMAT_NV12` buffer may have the +luma and chroma buffers combined into a single memory buffer by use of the +per-plane offset parameters, or they may be completely separate allocations in +memory. For this reason, each import and allocation API must provide a separate +handle for each plane. + +Each kernel subsystem has its own types and interfaces for buffer management. +DRM uses GEM buffer objects (BOs), V4L2 has its own references, etc. These types +are not portable between contexts, processes, devices, or subsystems. + +To address this, `dma-buf` handles are used as the universal interchange for +buffers. Subsystem-specific operations are used to export native buffer handles +to a `dma-buf` file descriptor, and to import those file descriptors into a +native buffer handle. dma-buf file descriptors can be transferred between +contexts, processes, devices, and subsystems. + +For example, a Wayland media player may use V4L2 to decode a video frame into +a `DRM_FORMAT_NV12` buffer. This will result in two memory planes (luma and +chroma) being dequeued by the user from V4L2. These planes are then exported to +one dma-buf file descriptor per plane, these descriptors are then sent along +with the metadata (format, modifier, width, height, per-plane offset and stride) +to the Wayland server. The Wayland server will then import these file +descriptors as an EGLImage for use through EGL/OpenGL (ES), a VkImage for use +through Vulkan, or a `drm_fb` for use through KMS; each of these import +operations will take the same metadata and convert the dma-buf file descriptors +into their native buffer handles. + + +Implicit modifiers +================== + +The concept of modifiers post-dates all of the subsystems mentioned above. As +such, it has been retrofitted into all of these APIs, and in order to ensure +backwards compatibility, support is needed for drivers and userspace which do +not (yet) support modifiers. + +As an example, GBM is used to allocate buffers to be shared between EGL for +rendering and KMS for display. It has two entrypoints for allocating buffers: +`gbm_bo_create` which only takes the format, width, height, and a usage token, +and `gbm_bo_create_with_modifiers` which extends this with a list of modifiers. + +In the latter case, the allocation is as discussed above, being provided with a +list of acceptable modifiers that the implementation can choose from (or fail if +it is not possible to allocate within those constraints). In the former case +where modifiers are not provided, the GBM implementation must make its own +choice as to what is likely to be the 'best' layout. Such a choice is entirely +implementation-specific: some will internally use tiled layouts which are not +CPU-accessible if the implementation decides that is a good idea through +whatever heuristic. It is the implementation's responsibility to ensure that +this choice is appropriate. + +To support this case where the layout is not known because there is no awareness +of modifiers, a special `DRM_FORMAT_MOD_INVALID` token has been defined. This +pseudo-modifier declares that the layout is not known, and that the driver +should use its own logic to determine what the underlying layout may be. + +There are four cases where this token may be used: + - during enumeration, an interface may return `DRM_FORMAT_MOD_INVALID`, either + as the sole member of a modifier list to declare that explicit modifiers are + not supported, or as part of a larger list to declare that implicit modifiers + may be used + - during allocation, a user may supply `DRM_FORMAT_MOD_INVALID`, either as the + sole member of a modifier list (equivalent to not supplying a modifier list + at all) to declare that explicit modifiers are not supported and must not be + used, or as part of a larger list to declare that an allocation using implicit + modifiers is acceptable + - in a post-allocation query, an implementation may return + `DRM_FORMAT_MOD_INVALID` as the modifier of the allocated buffer to declare + that the underlying layout is implementation-defined and that an explicit + modifier description is not available; per the above rules, this may only be + returned when the user has included `DRM_FORMAT_MOD_INVALID` as part of the + list of acceptable modifiers, or not provided a list + - when importing a buffer, the user may supply `DRM_FORMAT_MOD_INVALID` as the + buffer modifier (or not supply a modifier) to indicate that the modifier is + unknown for whatever reason; this is only acceptable when the buffer has + not been allocated with an explicit modifier + +It follows from this that a buffer chain must be either fully implicit or fully +explicit. For example, if a user wishes to allocate a buffer for use between +GPU, display, and media, but the media API does not support modifiers, then the +user **must not** allocate the buffer with explicit modifiers and attempt to +import the buffer into the media API with no modifier, but either perform the +allocation using implicit modifiers, or allocate the buffer for media use +separately and copy between the two buffers. + +As one exception to the above, allocations may be 'upgraded' from implicit +to explicit modifiers. For example, if the buffer is allocated with +`gbm_bo_create` (taking no modifiers), the user may then query the modifier with +`gbm_bo_get_modifier` and then use this modifier as an explicit modifier token +if a valid modifier is returned. + +When allocating buffers for exchange between different users and modifiers are +not available, implementations are strongly encouraged to use +`DRM_FORMAT_MOD_LINEAR` for their allocation, as this is the universal baseline +for exchange. + +Any new users - userspace programs and protocols, kernel subsystems, etc - +wishing to exchange buffers must offer interoperability through dma-buf file +descriptors for memory planes, DRM format tokens to describe the format, DRM +format modifiers to describe the layout in memory, at least width and height for +dimensions, and at least offset and stride for each memory plane. diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index b9c1214d8f23..cb12f2654ed7 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -10,6 +10,7 @@ Linux GPU Driver Developer's Guide drm-kms drm-kms-helpers drm-uapi + exchanging-pixel-buffers driver-uapi drm-client drivers -- 2.31.1

6 10

[Bug 214725] New: simpledrm and i915 both active after boot
by bugzilla-daemon＠bugzilla.kernel.org 09 Nov '21

09 Nov '21

https://bugzilla.kernel.org/show_bug.cgi?id=214725 Bug ID: 214725 Summary: simpledrm and i915 both active after boot Product: Drivers Version: 2.5 Kernel Version: 5.14.11 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: dennis.lissov(a)gmail.com Regression: No Gentoo Linux, custom kernel build, 5.14.11 with CONFIG_DRM_SIMPLEDRM=y CONFIG_DRM_I915=y Plasma (wayland) sees two monitors: the laptop screen and an unknown one. The only monitor physically present is the laptop screen. This did not happen a few months ago (possibly started with 5.14 upgrade). $ ls /sys/class/drm/ card0 card0-eDP-1 card1 card1-Unknown-1 card2 card2-DP-1 card2-DP-2 card2-DP-3 renderD128 renderD129 version $ readlink /sys/class/drm/card0 # Intel GPU ../../devices/pci0000:00/0000:00:02.0/drm/card0 $ readlink /sys/class/drm/card1 # Simple DRM ../../devices/platform/simple-framebuffer.0/drm/card1 $ readlink /sys/class/drm/card2 # Nouveau (not used at the moment) ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card2 $ dmesg | egrep '(simple|i915)' [ 0.000000] Command line: BOOT_IMAGE=/kernel-5.14.11 root=[...] ro acpi_backlight=video resume=[...] i915.enable_gvt=1 quiet [ 0.060342] Kernel command line: BOOT_IMAGE=/kernel-5.14.11 root=[...] ro acpi_backlight=video resume=[...] i915.enable_gvt=1 quiet [ 1.076957] i915 0000:00:02.0: [drm] VT-d active for gfx access [ 1.076961] i915 0000:00:02.0: vgaarb: deactivate vga console [ 1.387359] i915 0000:00:02.0: Direct firmware load for i915/gvt/vid_0x8086_did_0x191b_rid_0x06.golden_hw_state failed with error -2 [ 1.404418] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem [ 1.404525] i915 0000:00:02.0: [drm] Disabling framebuffer compression (FBC) to prevent screen flicker with VT-d enabled [ 1.404931] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/skl_dmc_ver1_27.bin (v1.27) [ 1.422128] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0 [ 1.425127] [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 1 [ 1.437859] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrm frame buffer device [ 1.438058] fbcon: i915 (fb1) is primary device [ 2.579133] i915 0000:00:02.0: [drm] fb1: i915 frame buffer device [ 22.162612] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops) [ 52.106084] simple-framebuffer simple-framebuffer.0: swiotlb buffer is full (sz: 8388608 bytes), total 32768 (slots), used 0 (slots) Looks like the hand-over mechanism does not correctly handle this combination, possibly due to i915 loading before simpledrm. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

2 2

[PATCH] drm: Fix possible memleak in drm_client_modeset_probe
by He Ying 09 Nov '21

09 Nov '21

I got memory leak as follows when doing fault injection test: WARNING: CPU: 0 PID: 1214 at drm_mode_config_cleanup+0x689/0x890 [drm] RIP: 0010:drm_mode_config_cleanup+0x689/0x890 [drm] Call Trace: ? tracer_hardirqs_on+0x33/0x520 ? drm_mode_config_reset+0x3f0/0x3f0 [drm] ? trace_event_raw_event_rcu_torture_read+0x2c0/0x2c0 ? __sanitizer_cov_trace_pc+0x1d/0x50 ? call_rcu+0x489/0x15e0 ? trace_hardirqs_on+0x63/0x2d0 ? write_comp_data+0x2a/0x90 ? drm_mode_config_cleanup+0x890/0x890 [drm] drm_managed_release+0x1fa/0x4f0 [drm] drm_dev_release+0x72/0xb0 [drm] devm_drm_dev_init_release+0x81/0xa0 [drm] release_nodes+0xba/0x3b0 ... entry_SYSCALL_64_after_hwframe+0x44/0xae and then an error message: [drm:drm_mode_config_cleanup [drm]] *ERROR* connector SPI-1 leaked! When krealloc() in drm_client_modeset_probe() fails, it goes to the label 'free_connectors'. However, krealloc() is between drm_connector_list_iter_begin() and *_end(). Going to the label directly is not a good idea. Because iter->conn is not cleaned up if so. Fix the problem by going to the label outside drm_connector_list_iter_end(). Signed-off-by: He Ying <heying24(a)huawei.com> --- drivers/gpu/drm/drm_client_modeset.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm/drm_client_modeset.c index ced09c7c06f9..7ac88ae93f38 100644 --- a/drivers/gpu/drm/drm_client_modeset.c +++ b/drivers/gpu/drm/drm_client_modeset.c @@ -789,7 +789,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, unsigned int width, tmp = krealloc(connectors, (connector_count + 1) * sizeof(*connectors), GFP_KERNEL); if (!tmp) { ret = -ENOMEM; - goto free_connectors; + break; } connectors = tmp; @@ -798,6 +798,9 @@ int drm_client_modeset_probe(struct drm_client_dev *client, unsigned int width, } drm_connector_list_iter_end(&conn_iter); + if (ret) + goto free_connectors; + if (!connector_count) return 0; -- 2.17.1

1 1

[PATCH] drm: Fix wrong use of connector in vop_get_edp_connector
by He Ying 09 Nov '21

09 Nov '21

>From the comments of drm_for_each_connector_iter(), we know that "connector is only valid within the list body, if you want to use connector after calling drm_connector_list_iter_end() then you need to grab your own reference first using drm_connector_get()". So fix the wrong use of connector according to the comments and then call drm_connector_put() after using connector finishes. Signed-off-by: He Ying <heying24(a)huawei.com> Fixes: 2cbeb64f6c70 ("drm/rockchip: use drm_for_each_connector_iter()") --- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index a25b98b7f5bd..469922ad29fa 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c @@ -1581,19 +1581,19 @@ static void vop_crtc_reset(struct drm_crtc *crtc) #ifdef CONFIG_DRM_ANALOGIX_DP static struct drm_connector *vop_get_edp_connector(struct vop *vop) { - struct drm_connector *connector; + struct drm_connector *connector = NULL; struct drm_connector_list_iter conn_iter; drm_connector_list_iter_begin(vop->drm_dev, &conn_iter); drm_for_each_connector_iter(connector, &conn_iter) { if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) { - drm_connector_list_iter_end(&conn_iter); - return connector; + drm_connector_get(connector); + break; } } drm_connector_list_iter_end(&conn_iter); - return NULL; + return connector; } static int vop_crtc_set_crc_source(struct drm_crtc *crtc, @@ -1614,6 +1614,7 @@ static int vop_crtc_set_crc_source(struct drm_crtc *crtc, else ret = -EINVAL; + drm_connector_put(connector); return ret; } -- 2.17.1

1 1

[PATCH] dt-bindings: display: bridge: Convert toshiba, tc358767.txt to yaml
by Rahul T R 08 Nov '21

08 Nov '21

Convert toshiba,tc358767.txt binding to yaml format Signed-off-by: Rahul T R <r-ravikumar(a)ti.com> --- .../display/bridge/toshiba,tc358767.txt | 54 ------ .../display/bridge/toshiba,tc358767.yaml | 158 ++++++++++++++++++ 2 files changed, 158 insertions(+), 54 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt create mode 100644 Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt deleted file mode 100644 index 583c5e9dbe6b..000000000000 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt +++ /dev/null @@ -1,54 +0,0 @@ -Toshiba TC358767 eDP bridge bindings - -Required properties: - - compatible: "toshiba,tc358767" - - reg: i2c address of the bridge, 0x68 or 0x0f, depending on bootstrap pins - - clock-names: should be "ref" - - clocks: OF device-tree clock specification for refclk input. The reference - clock rate must be 13 MHz, 19.2 MHz, 26 MHz, or 38.4 MHz. - -Optional properties: - - shutdown-gpios: OF device-tree gpio specification for SD pin - (active high shutdown input) - - reset-gpios: OF device-tree gpio specification for RSTX pin - (active low system reset) - - toshiba,hpd-pin: TC358767 GPIO pin number to which HPD is connected to (0 or 1) - - ports: the ports node can contain video interface port nodes to connect - to a DPI/DSI source and to an eDP/DP sink according to [1][2]: - - port@0: DSI input port - - port@1: DPI input port - - port@2: eDP/DP output port - -[1]: Documentation/devicetree/bindings/graph.txt -[2]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - edp-bridge@68 { - compatible = "toshiba,tc358767"; - reg = <0x68>; - shutdown-gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>; - reset-gpios = <&gpio3 24 GPIO_ACTIVE_LOW>; - clock-names = "ref"; - clocks = <&edp_refclk>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@1 { - reg = <1>; - - bridge_in: endpoint { - remote-endpoint = <&dpi_out>; - }; - }; - - port@2 { - reg = <2>; - - bridge_out: endpoint { - remote-endpoint = <&panel_in>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml new file mode 100644 index 000000000000..f1541cc05297 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml @@ -0,0 +1,158 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358767.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Toshiba TC358767 eDP bridge bindings + +maintainers: + - Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> + +description: The TC358767 is bridge device which converts DSI/DPI to eDP/DP + +properties: + compatible: + const: toshiba,tc358767 + + reg: + enum: + - 0x68 + - 0x0f + description: | + i2c address of the bridge, 0x68 or 0x0f, depending on bootstrap pins + + clock-names: + const: "ref" + + clocks: + maxItems: 1 + description: | + OF device-tree clock specification for refclk input. The reference. + clock rate must be 13 MHz, 19.2 MHz, 26 MHz, or 38.4 MHz. + + shutdown-gpios: + maxItems: 1 + description: | + OF device-tree gpio specification for SD pin(active high shutdown input) + + reset-gpios: + maxItems: 1 + description: | + OF device-tree gpio specification for RSTX pin(active low system reset) + + toshiba,hpd-pin: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 + - 1 + description: TC358767 GPIO pin number to which HPD is connected to (0 or 1) + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: | + DSI input port. The remote endpoint phandle should be a + reference to a valid DSI output endpoint node + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: | + DPI input port. The remote endpoint phandle should be a + reference to a valid DPI output endpoint node + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: | + eDP/DP output port. The remote endpoint phandle should be a + reference to a valid eDP panel input endpoint node. This port is + optional, treated as DP panel if not defined + + oneOf: + - required: + - port@0 + - required: + - port@1 + + +required: + - compatible + - reg + - clock-names + - clocks + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + /* DPI input and eDP output */ + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + edp-bridge@68 { + compatible = "toshiba,tc358767"; + reg = <0x68>; + shutdown-gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio3 24 GPIO_ACTIVE_LOW>; + clock-names = "ref"; + clocks = <&edp_refclk>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + reg = <1>; + + bridge_in_0: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + + port@2 { + reg = <2>; + + bridge_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; + }; + }; + - | + /* DPI input and DP output */ + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + edp-bridge@68 { + compatible = "toshiba,tc358767"; + reg = <0x68>; + shutdown-gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio3 24 GPIO_ACTIVE_LOW>; + clock-names = "ref"; + clocks = <&edp_refclk>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + reg = <1>; + + bridge_in_1: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + }; + }; + }; -- 2.17.1

2 1

[PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
by Daniel Vetter 08 Nov '21

08 Nov '21

When doing an atomic modeset with ALLOW_MODESET drivers are allowed to pull in arbitrary other resources, including CRTCs (e.g. when reconfiguring global resources). But in nonblocking mode userspace has then no idea this happened, which can lead to spurious EBUSY calls, both: - when that other CRTC is currently busy doing a page_flip the ALLOW_MODESET commit can fail with an EBUSY - on the other CRTC a normal atomic flip can fail with EBUSY because of the additional commit inserted by the kernel without userspace's knowledge For blocking commits this isn't a problem, because everyone else will just block until all the CRTC are reconfigured. Only thing userspace can notice is the dropped frames without any reason for why frames got dropped. Consensus is that we need new uapi to handle this properly, but no one has any idea what exactly the new uapi should look like. Since this has been shipping for years already compositors need to deal no matter what, so as a first step just try to enforce this across drivers better with some checks. v2: Add comments and a WARN_ON to enforce this only when allowed - we don't want to silently convert page flips into blocking plane updates just because the driver is buggy. v3: Fix inverted WARN_ON (Pekka). v4: Drop the uapi changes, only add a WARN_ON for now to enforce some rules for drivers. v5: Make the WARNING more informative (Daniel) v6: Add unconditional debug output for compositor hackers to figure out what's going on when they get an EBUSY (Daniel) v7: Fix up old/new_crtc_state confusion for real (Pekka/Ville) References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568 Cc: Daniel Stone <daniel(a)fooishbar.org> Cc: Pekka Paalanen <pekka.paalanen(a)collabora.co.uk> Cc: Simon Ser <contact(a)emersion.fr> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/drm_atomic.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 58527f151984..aac9122f1da2 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -281,6 +281,10 @@ EXPORT_SYMBOL(__drm_atomic_state_free); * needed. It will also grab the relevant CRTC lock to make sure that the state * is consistent. * + * WARNING: Drivers may only add new CRTC states to a @state if + * drm_atomic_state.allow_modeset is set, or if it's a driver-internal commit + * not created by userspace through an IOCTL call. + * * Returns: * * Either the allocated state or the error code encoded into the pointer. When @@ -1262,10 +1266,15 @@ int drm_atomic_check_only(struct drm_atomic_state *state) struct drm_crtc_state *new_crtc_state; struct drm_connector *conn; struct drm_connector_state *conn_state; + unsigned requested_crtc = 0; + unsigned affected_crtc = 0; int i, ret = 0; DRM_DEBUG_ATOMIC("checking %p\n", state); + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) + requested_crtc |= drm_crtc_mask(crtc); + for_each_oldnew_plane_in_state(state, plane, old_plane_state, new_plane_state, i) { ret = drm_atomic_plane_check(old_plane_state, new_plane_state); if (ret) { @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state) } } + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) + affected_crtc |= drm_crtc_mask(crtc); + + /* + * For commits that allow modesets drivers can add other CRTCs to the + * atomic commit, e.g. when they need to reallocate global resources. + * This can cause spurious EBUSY, which robs compositors of a very + * effective sanity check for their drawing loop. Therefor only allow + * drivers to add unrelated CRTC states for modeset commits. + * + * FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output + * so compositors know what's going on. + */ + if (affected_crtc != requested_crtc) { + DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x, affected 0x%0x\n", + requested_crtc, affected_crtc); + WARN(!state->allow_modeset, "adding CRTC not allowed without modesets: requested 0x%x, affected 0x%0x\n", + requested_crtc, affected_crtc); + } + return 0; } EXPORT_SYMBOL(drm_atomic_check_only); -- 2.28.0

5 8

← Newer
1
...
13
14
15
16
17
18
19
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2021