dri-devel March 2022

dri-devel@lists.freedesktop.org

370 participants
780 discussions

[REPOST PATCH v4 00/13] drm/msm: Add Display Stream Compression Support
by Vinod Koul 24 Mar '22

24 Mar '22

Display Stream Compression (DSC) compresses the display stream in host which is later decoded by panel. This series enables this for Qualcomm msm driver. This was tested on Google Pixel3 phone which use LGE SW43408 panel. The changes include DSC data and hardware block enabling for DPU1 then support in encoder. We also add support in DSI and introduce required topology changes. In order for panel to set the DSC parameters we add dsc in drm_panel and set it from the msm driver. We still have dsc as a globabl entity. I think while doing DP + DSC we should be able to update it, right now comprehending the requirements are bit difficult. Complete changes which enable this for Pixel3 along with panel driver (not part of this series) and DT changes can be found at: git.linaro.org/people/vinod.koul/kernel.git pixel/dsc_v4 Comments welcome! Changes since v3: - Merge changes from Dmitry to have dsc per encoder instance - add warning for dsc and mode3d enabled together - set dsc in dpu_encoder_phys_vid as well - remove dsc hardcoded mask - use devm_kzalloc for memory allocation for dsc Changes since v2: - Fix comments by Dimitry except the dsc being global. - Move RM patch later for dependency on topology now - Add patch for mode valid callback for dsi_mgr - Add missing structure documentation patch - Fix errors in mode_3d changes - Rebase on v5.16-rc1 and test Changes since v1: - Fix various issues spotted by kbuildbot - Rebase to v5.15-rc3 - Remove unused fields and duplicate defines - Enable DSC blocks only when DSC is enabled - remove sdm845 feature mask, use 0 - Check for DSC in hw_ctl Changes since RFC: - Drop the DT binding patch as we derive the configuration from panel - Drop the drm api patch as we no longer need it (use pps drm api) - Fix comments raised by Dimitry - Add dsc parameters calculation from downstream Vinod Koul (13): drm/msm/dsi: add support for dsc data drm/msm/dsi: Pass DSC params to drm_panel drm/msm/disp/dpu1: Add support for DSC drm/msm/disp/dpu1: Add support for DSC in pingpong block drm/msm/disp/dpu1: Add DSC for SDM845 to hw_catalog drm/msm/disp/dpu1: Add DSC support in hw_ctl drm/msm/disp/dpu1: Add support for DSC in encoder drm/msm/disp/dpu1: Don't use DSC with mode_3d drm/msm: Add missing structure documentation drm/msm/disp/dpu1: Add support for DSC in topology drm/msm/disp/dpu1: Add DSC support in RM drm/msm/dsi: add mode valid callback for dsi_mgr drm/msm/dsi: Add support for DSC configuration drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 177 ++++++++++- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 8 + .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4 + .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 4 + .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 20 ++ .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 13 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 18 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 210 +++++++++++++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h | 77 +++++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 13 + .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 32 ++ .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 14 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 56 ++++ drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 1 + drivers/gpu/drm/msm/dsi/dsi.c | 5 + drivers/gpu/drm/msm/dsi/dsi.h | 3 + drivers/gpu/drm/msm/dsi/dsi.xml.h | 10 + drivers/gpu/drm/msm/dsi/dsi_host.c | 289 +++++++++++++++++- drivers/gpu/drm/msm/dsi/dsi_manager.c | 12 + drivers/gpu/drm/msm/msm_drv.h | 26 ++ include/drm/drm_panel.h | 7 + 25 files changed, 1001 insertions(+), 4 deletions(-) create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h -- 2.31.1

4 63

[PATCH v5 00/19] drm/i915/dg2: Enabling 64k page size and flat ccs
by Ramalingam C 24 Mar '22

24 Mar '22

This series introduces the enabling patches for new memory compression feature Flat CCS and 64k page support for i915 local memory, along with documentation on the uAPI impact. Included the details of the feature and the implications on the uAPI below. Which is also added into Documentation/gpu/rfc/i915_dg2.rst DG2 64K page size support: ========================= On discrete platforms, starting from DG2, we have to contend with GTT page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE objects. Specifically the hardware only supports 64K or larger GTT page sizes for such memory. The kernel will already ensure that all I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page sizes underneath. Note that the returned size here will always reflect any required rounding up done by the kernel, i.e 4K will now become 64K on devices such as DG2. Special DG2 GTT address alignment requirement: The GTT alignment will also need to be at least 2M for such objects. Note that due to how the hardware implements 64K GTT page support, we have some further complications: 1) The entire PDE (which covers a 2MB virtual address range), must contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same PDE is forbidden by the hardware. 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM objects. To keep things simple for userland, we mandate that any GTT mappings must be aligned to and rounded up to 2MB. As this only wastes virtual address space and avoids userland having to copy any needlessly complicated PDE sharing scheme (coloring) and only affects DG2, this is deemed to be a good compromise. Flat CCS support for lmem ========================= On Xe-HP and later devices, we use dedicated compression control state (CCS) stored in local memory for each surface, to support the 3D and media compression formats. The memory required for the CCS of the entire local memory is 1/256 of the local memory size. So before the kernel boot, the required memory is reserved for the CCS data and a secure register will be programmed with the CCS base address. Flat CCS data needs to be cleared when a lmem object is allocated. And CCS data can be copied in and out of CCS region through XY_CTRL_SURF_COPY_BLT. CPU can’t access the CCS data directly. When we exaust the lmem, if the object’s placements support smem, then we can directly decompress the compressed lmem object into smem and start using it from smem itself. But when we need to swapout the compressed lmem object into a smem region though objects’ placement doesn’t support smem, then we copy the lmem content as it is into smem region along with ccs data (using XY_CTRL_SURF_COPY_BLT). When the object is referred, lmem content will be swaped in along with restoration of the CCS data (using XY_CTRL_SURF_COPY_BLT) at corresponding location. Flat-CCS Modifiers for different compression formats ==================================================== I915_FORMAT_MOD_4_TILED_DG2_RC_CCS - used to indicate the buffers of Flat CCS render compression formats. Though the general layout is same as I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS, new hashing/compression algorithm is used. Render compression uses 128 byte compression blocks I915_FORMAT_MOD_4_TILED_DG2_MC_CCS -used to indicate the buffers of Flat CCS media compression formats. Though the general layout is same as I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS, new hashing/compression algorithm is used. Media compression uses 256 byte compression blocks. I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC - used to indicate the buffers of Flat CCS clear color render compression formats. Unified compression format for clear color render compression. The genral layout is a tiled layout using 4Kb tiles i.e Tile4 layout. Fast clear color value expected by HW is located in fb at offset 0 of plane#1 v2: Fixed some formatting issues and platform naming issues Added some more documentation on Flat-CCS v3: Plane programming is handled for flat-ccs and clear color Tile4 and flat ccs modifier patches are rebased on table based modifier reference method Three patches are squashed Y tile is pruned for DG2. flat_ccs_cc plane format info is added Added mesa, compute and media ppl for required uAPI ack. v4: Rebasing of the patches v5: KDoc is enhanced for cc modifier. [Nanley & Lionel] inbuild macro usage for functional fix [Bob] Addressed review comments from Matt Platform coverage fix for modifiers [Imre] Abdiel Janulgue (1): drm/i915/lmem: Enable lmem for platforms with Flat CCS Anshuman Gupta (1): drm/i915/dg2: Flat CCS Support Ayaz A Siddiqui (1): drm/i915/gt: Clear compress metadata for Xe_HP platforms CQ Tang (1): drm/i915/xehpsdv: Add has_flat_ccs to device info Matt Roper (1): drm/i915/dg2: Add DG2 unified compression Matthew Auld (6): drm/i915: enforce min GTT alignment for discrete cards drm/i915: support 64K GTT pages for discrete cards drm/i915/gtt: allow overriding the pt alignment drm/i915/gtt: add xehpsdv_ppgtt_insert_entry drm/i915/migrate: add acceleration support for DG2 drm/i915/uapi: document behaviour for DG2 64K support Mika Kahola (1): uapi/drm/dg2: Introduce format modifier for DG2 clear color Ramalingam C (4): drm/i915: add needs_compact_pt flag Doc/gpu/rfc/i915: i915 DG2 64k pagesize uAPI drm/i915/Flat-CCS: Document on Flat-CCS memory compression Doc/gpu/rfc/i915: i915 DG2 flat-CCS uAPI Robert Beckett (1): drm/i915: add gtt misalignment test Stanislav Lisovskiy (2): drm/i915: Introduce new Tile 4 format drm/i915/dg2: Tile 4 plane format support Documentation/gpu/rfc/i915_dg2.rst | 32 ++ Documentation/gpu/rfc/index.rst | 3 + drivers/gpu/drm/i915/display/intel_display.c | 5 +- drivers/gpu/drm/i915/display/intel_fb.c | 68 +++- drivers/gpu/drm/i915/display/intel_fb.h | 1 + drivers/gpu/drm/i915/display/intel_fbc.c | 1 + .../drm/i915/display/intel_plane_initial.c | 1 + .../drm/i915/display/skl_universal_plane.c | 70 +++- .../gpu/drm/i915/gem/selftests/huge_pages.c | 60 ++++ .../i915/gem/selftests/i915_gem_client_blt.c | 21 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 158 +++++++- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 14 + drivers/gpu/drm/i915/gt/intel_gt.c | 19 + drivers/gpu/drm/i915/gt/intel_gt.h | 1 + drivers/gpu/drm/i915/gt/intel_gtt.c | 12 + drivers/gpu/drm/i915/gt/intel_gtt.h | 31 +- drivers/gpu/drm/i915/gt/intel_migrate.c | 336 ++++++++++++++++-- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 17 +- drivers/gpu/drm/i915/gt/intel_region_lmem.c | 24 +- drivers/gpu/drm/i915/i915_drv.h | 18 +- drivers/gpu/drm/i915/i915_pci.c | 4 + drivers/gpu/drm/i915/i915_reg.h | 4 + drivers/gpu/drm/i915/i915_vma.c | 9 + drivers/gpu/drm/i915/intel_device_info.h | 3 + drivers/gpu/drm/i915/intel_pm.c | 1 + drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 224 ++++++++++-- include/uapi/drm/drm_fourcc.h | 43 +++ include/uapi/drm/i915_drm.h | 44 ++- 28 files changed, 1102 insertions(+), 122 deletions(-) create mode 100644 Documentation/gpu/rfc/i915_dg2.rst -- 2.20.1

7 43

[PATCH] backlight: replace usage of found with dedicated list iterator variable
by Jakob Koschel 24 Mar '22

24 Mar '22

To move the list iterator variable into the list_for_each_entry_*() macro in the future it should be avoided to use the list iterator variable after the loop body. To *never* use the list iterator variable after the loop it was concluded to use a separate iterator variable instead of a found boolean [1]. This removes the need to use a found variable and simply checking if the variable was set, can determine if the break/goto was hit. Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cW… Signed-off-by: Jakob Koschel <jakobkoschel(a)gmail.com> --- drivers/video/backlight/backlight.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c index 4ae6fae94ac2..c05380d7a09e 100644 --- a/drivers/video/backlight/backlight.c +++ b/drivers/video/backlight/backlight.c @@ -479,19 +479,18 @@ EXPORT_SYMBOL(backlight_device_register); */ struct backlight_device *backlight_device_get_by_type(enum backlight_type type) { - bool found = false; - struct backlight_device *bd; + struct backlight_device *bd = NULL, *iter; mutex_lock(&backlight_dev_list_mutex); - list_for_each_entry(bd, &backlight_dev_list, entry) { - if (bd->props.type == type) { - found = true; + list_for_each_entry(iter, &backlight_dev_list, entry) { + if (iter->props.type == type) { + bd = iter; break; } } mutex_unlock(&backlight_dev_list_mutex); - return found ? bd : NULL; + return bd; } EXPORT_SYMBOL(backlight_device_get_by_type); base-commit: f443e374ae131c168a065ea1748feac6b2e76613 -- 2.25.1

2 1

[PATCH] drm: gma500: clean up some style problems reported by checkpatch.pl
by Haowen Bai 24 Mar '22

24 Mar '22

WARNING: Statements should start on a tabstop WARNING: Missing a blank line after declarations Signed-off-by: Haowen Bai <baihaowen(a)meizu.com> --- drivers/gpu/drm/gma500/mid_bios.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/gma500/mid_bios.c b/drivers/gpu/drm/gma500/mid_bios.c index 7e76790..71942c2 100644 --- a/drivers/gpu/drm/gma500/mid_bios.c +++ b/drivers/gpu/drm/gma500/mid_bios.c @@ -50,8 +50,8 @@ static void mid_get_fuse_settings(struct drm_device *dev) DRM_INFO("internal display is %s\n", dev_priv->iLVDS_enable ? "LVDS display" : "MIPI display"); - /* Prevent runtime suspend at start*/ - if (dev_priv->iLVDS_enable) { + /* Prevent runtime suspend at start*/ + if (dev_priv->iLVDS_enable) { dev_priv->is_lvds_on = true; dev_priv->is_mipi_on = false; } else { @@ -325,6 +325,7 @@ static void mid_get_vbt_data(struct drm_psb_private *dev_priv) int mid_chip_setup(struct drm_device *dev) { struct drm_psb_private *dev_priv = to_drm_psb_private(dev); + mid_get_fuse_settings(dev); mid_get_vbt_data(dev_priv); mid_get_pci_revID(dev_priv); -- 2.7.4

2 1

[PULL] drm-misc-next-fixes
by Maarten Lankhorst 24 Mar '22

24 Mar '22

The previous pull request tag was botched due to my key expiring, updated! drm-misc-next-fixes-2022-03-24-1: drm-misc-next-fixes for v5.18-rc1: - Make audio and color plane support checking only happen when a CEA extension block is found. - Fix a small regression from ttm_resource_fini() - Small selftest fix. The following changes since commit f6d790e5a7fe42706756c7fa1686d08d230610fc: Merge tag 'drm-intel-next-fixes-2022-03-10' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-03-11 13:27:00 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2022-03-24-1 for you to fetch changes up to 7344bad7fb6daa4877a1c064b52c7d5f9182c41b: drm/edid: fix CEA extension byte #3 parsing (2022-03-24 11:41:14 +0200) ---------------------------------------------------------------- drm-misc-next-fixes for v5.18-rc1: - Make audio and color plane support checking only happen when a CEA extension block is found. - Fix a small regression from ttm_resource_fini() - Small selftest fix. ---------------------------------------------------------------- Cooper Chiou (1): drm/edid: check basic audio support on CEA extension block Jani Nikula (1): drm/edid: fix CEA extension byte #3 parsing Nathan Chancellor (1): drm/selftest: plane_helper: Put test structures in static storage Zack Rusin (1): drm/ttm: Fix a kernel oops due to an invalid read drivers/gpu/drm/drm_edid.c | 15 ++++++++++----- drivers/gpu/drm/selftests/test-drm_plane_helper.c | 8 ++++---- drivers/gpu/drm/ttm/ttm_range_manager.c | 2 +- 3 files changed, 15 insertions(+), 10 deletions(-)

1 0

[PULL] drm-misc-next-fixes
by Maarten Lankhorst 24 Mar '22

24 Mar '22

drm-misc-next-fixes-2022-03-24: Short summary of fixes pull (less than what git shortlog provides): - explain anything non-fixes (e.g. cleanups) and why it's appropriate - highlight regressions - summarize pull requests contained This shouldn't be more than a few lines (or it indicates your fixes pull is a bit too big). The following changes since commit f6d790e5a7fe42706756c7fa1686d08d230610fc: Merge tag 'drm-intel-next-fixes-2022-03-10' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-03-11 13:27:00 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2022-03-24 for you to fetch changes up to 7344bad7fb6daa4877a1c064b52c7d5f9182c41b: drm/edid: fix CEA extension byte #3 parsing (2022-03-24 11:41:14 +0200) ---------------------------------------------------------------- Short summary of fixes pull (less than what git shortlog provides): - explain anything non-fixes (e.g. cleanups) and why it's appropriate - highlight regressions - summarize pull requests contained This shouldn't be more than a few lines (or it indicates your fixes pull is a bit too big). ---------------------------------------------------------------- Cooper Chiou (1): drm/edid: check basic audio support on CEA extension block Jani Nikula (1): drm/edid: fix CEA extension byte #3 parsing Nathan Chancellor (1): drm/selftest: plane_helper: Put test structures in static storage Zack Rusin (1): drm/ttm: Fix a kernel oops due to an invalid read drivers/gpu/drm/drm_edid.c | 15 ++++++++++----- drivers/gpu/drm/selftests/test-drm_plane_helper.c | 8 ++++---- drivers/gpu/drm/ttm/ttm_range_manager.c | 2 +- 3 files changed, 15 insertions(+), 10 deletions(-)

1 0

[PATCH -next] drm/vc4: Fix build error when CONFIG_DRM_VC4=y && CONFIG_RASPBERRYPI_FIRMWARE=m
by Zheng Bin 24 Mar '22

24 Mar '22

If CONFIG_DRM_VC4=y, CONFIG_RASPBERRYPI_FIRMWARE=m, CONFIG_COMPILE_TEST=n, bulding fails: drivers/gpu/drm/vc4/vc4_drv.o: In function `vc4_drm_bind': vc4_drv.c:(.text+0x320): undefined reference to `rpi_firmware_get' vc4_drv.c:(.text+0x320): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `rpi_firmware_get' vc4_drv.c:(.text+0x34c): undefined reference to `rpi_firmware_property' vc4_drv.c:(.text+0x34c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `rpi_firmware_property' vc4_drv.c:(.text+0x354): undefined reference to `rpi_firmware_put' vc4_drv.c:(.text+0x354): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `rpi_firmware_put' Make DRM_VC4 depends on RASPBERRYPI_FIRMWARE to fix this. Fixes: c406ad5e4a85 ("drm/vc4: Notify the firmware when DRM is in charge") Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: Zheng Bin <zhengbin13(a)huawei.com> --- drivers/gpu/drm/vc4/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig index de3424fed2fc..640907945b5b 100644 --- a/drivers/gpu/drm/vc4/Kconfig +++ b/drivers/gpu/drm/vc4/Kconfig @@ -1,7 +1,8 @@ # SPDX-License-Identifier: GPL-2.0-only config DRM_VC4 tristate "Broadcom VC4 Graphics" - depends on ARCH_BCM || ARCH_BCM2835 || COMPILE_TEST + depends on ((ARCH_BCM || ARCH_BCM2835) && \ + RASPBERRYPI_FIRMWARE) || COMPILE_TEST depends on DRM depends on SND && SND_SOC depends on COMMON_CLK -- 2.31.1

2 1

[PATCH v6 0/7] drm/vc4: hdmi: Yet Another Approach to HDMI YUV output
by Maxime Ripard 24 Mar '22

24 Mar '22

Hi, This is another attempt at supporting the HDMI YUV output in the vc4 HDMI driver. This is a follow-up of https://lore.kernel.org/dri-devel/20210317154352.732095-1-maxime@cerno.tech/ And the discussions that occured recently on the mailing lists and IRC about this. The series mentioned above had multiple issues, the main one being that it was a bit too much complicated for what we wanted to achieve. This series is taking a much simpler approach with an ad-hoc solution. I think some parts of it could still be moved to KMS helpers (notably, the output format enum, and the helper to set the infoframe for it) and structures (the output format stored in drm_connector_state). This would also interact nicely with the work done here: https://lore.kernel.org/dri-devel/20211118103814.524670-1-maxime@cerno.tech/ This can come as a second step though. The other issues with the first attempt was that nothing was reported to userspace about the decision we made about the format, and that this decision was essentially policy, without any way for the userspace to influence it. Those two points however are being worked on by Werner in a cross-driver effort: https://lore.kernel.org/dri-devel/e452775c-5b95-bbfd-e818-f1480f556336@tuxe… Since it's a KMS decision, I don't think we should hold off any driver as long as it's consistent with what the other drivers are doing. Let me know what you think, Maxime --- Changes from v5: - Renamed pixel_rate to tmds_char_rate - used do_div when necessary - Used limited range YUV matrixes - Rebased on current drm-misc-next Changes from v4: - Fix a clock calculation - Rebased on latest drm-misc-next tag Changes from v3: - Rebased on latest next - Fixed build error Changes from v2: - Rename the output format enum - Split the edid_hdmi_dc_modes in two for RGB444 and YUV444 - Remove color_formats modifications from _parse_deep_color entirely - Fixed comment formatting - Fixed mode_valid that would always return true - Fixed max_tmds_clock handling Changes from v1: - Fixed an EDID parsing error for YUV422 - Fixed the scrambling setup when using a bpc > 8 - Added some logging - Fixed some build-bot warnings - Fixed a number of HDMI specifications and EDID issues - Try to max out the bpc every time Maxime Ripard (7): drm/vc4: hdmi: Rename pixel_rate variable drm/vc4: hdmi: Move clock validation to its own function drm/vc4: hdmi: Move clock calculation into its own function drm/vc4: hdmi: Take the sink maximum TMDS clock into account drm/vc4: hdmi: Take bpp into account for the scrambler drm/vc4: hdmi: Always try to have the highest bpc drm/vc4: hdmi: Support HDMI YUV output drivers/gpu/drm/vc4/vc4_hdmi.c | 429 +++++++++++++++++++++++++--- drivers/gpu/drm/vc4/vc4_hdmi.h | 23 +- drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 2 +- drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 6 + drivers/gpu/drm/vc4/vc4_regs.h | 16 ++ 5 files changed, 427 insertions(+), 49 deletions(-) -- 2.35.1

2 9

[PATCH -next] drm/bridge: it6505: Fix build error without DRM_DP_HELPER
by Zheng Bin 24 Mar '22

24 Mar '22

If DRM_DP_HELPER is not set, bulding fails: ld: drivers/gpu/drm/bridge/ite-it6505.o: in function `it6505_link_training_work': ite-it6505.c:(.text+0x50d8): undefined reference to `drm_dp_dpcd_write' ld: ite-it6505.c:(.text+0x51c4): undefined reference to `drm_dp_link_train_clock_recovery_delay' ld: ite-it6505.c:(.text+0x51d7): undefined reference to `drm_dp_dpcd_read_link_status' ld: ite-it6505.c:(.text+0x51ec): undefined reference to `drm_dp_clock_recovery_ok' ld: ite-it6505.c:(.text+0x5387): undefined reference to `drm_dp_get_adjust_request_voltage' ld: ite-it6505.c:(.text+0x539d): undefined reference to `drm_dp_get_adjust_request_pre_emphasis' ld: ite-it6505.c:(.text+0x5548): undefined reference to `drm_dp_link_train_channel_eq_delay' ld: ite-it6505.c:(.text+0x555b): undefined reference to `drm_dp_dpcd_read_link_status' ld: ite-it6505.c:(.text+0x5570): undefined reference to `drm_dp_clock_recovery_ok' ld: ite-it6505.c:(.text+0x558d): undefined reference to `drm_dp_channel_eq_ok' ld: ite-it6505.c:(.text+0x55da): undefined reference to `drm_dp_get_adjust_request_voltage' ld: ite-it6505.c:(.text+0x55f2): undefined reference to `drm_dp_get_adjust_request_pre_emphasis' ld: drivers/gpu/drm/bridge/ite-it6505.o: in function `it6505_bridge_detect': ite-it6505.c:(.text+0x59f1): undefined reference to `drm_dp_dpcd_read' ld: ite-it6505.c:(.text+0x5a16): undefined reference to `drm_dp_bw_code_to_link_rate' ld: ite-it6505.c:(.text+0x5a87): undefined reference to `drm_dp_dpcd_read' ld: ite-it6505.c:(.text+0x5ac1): undefined reference to `drm_dp_dpcd_write' ld: ite-it6505.c:(.text+0x5d43): undefined reference to `drm_dp_link_rate_to_bw_code' Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver") Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: Zheng Bin <zhengbin13(a)huawei.com> --- drivers/gpu/drm/bridge/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 007e5a282f67..2145b08f9534 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -78,6 +78,7 @@ config DRM_ITE_IT6505 tristate "ITE IT6505 DisplayPort bridge" depends on OF select DRM_KMS_HELPER + select DRM_DP_HELPER select EXTCON help ITE IT6505 DisplayPort bridge chip driver. -- 2.31.1

1 0

[PATCH -next] drm/bridge: it6505: Fix build error
by YueHaibing 24 Mar '22

24 Mar '22

If DRM_ITE_IT6505 is y but DRM_DP_HELPER is m, building failed: drivers/gpu/drm/bridge/ite-it6505.o: In function `it6505_i2c_remove': ite-it6505.c:(.text+0x35c): undefined reference to `drm_dp_aux_unregister' drivers/gpu/drm/bridge/ite-it6505.o: In function `it6505_dpcd_read': ite-it6505.c:(.text+0x420): undefined reference to `drm_dp_dpcd_read' drivers/gpu/drm/bridge/ite-it6505.o: In function `it6505_get_dpcd': ite-it6505.c:(.text+0x4a4): undefined reference to `drm_dp_dpcd_read' drivers/gpu/drm/bridge/ite-it6505.o: In function `it6505_dpcd_write': ite-it6505.c:(.text+0x52c): undefined reference to `drm_dp_dpcd_write' Select DRM_DP_HELPER for DRM_ITE_IT6505 to fix this. Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver") Signed-off-by: YueHaibing <yuehaibing(a)huawei.com> --- drivers/gpu/drm/bridge/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index c86f5be4dfe0..1b8721a7a6df 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -78,6 +78,7 @@ config DRM_DISPLAY_CONNECTOR config DRM_ITE_IT6505 tristate "ITE IT6505 DisplayPort bridge" depends on OF + select DRM_DP_HELPER select DRM_KMS_HELPER select EXTCON help -- 2.17.1

2 3

← Newer
1
...
28
29
30
31
32
33
34
...
78
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2022