dri-devel April 2021

dri-devel@lists.freedesktop.org

317 participants
715 discussions

[PATCH 1/2] drm/virtio: Create Dumb BOs as guest Blobs
by Vivek Kasireddy 15 Apr '21

15 Apr '21

If support for Blob resources is available, then dumb BOs created by the driver can be considered as guest Blobs. And, for guest Blobs, there is no need to do any transfers or flushes but we do need to do set_scanout even if the FB has not changed as part of plane updates. Cc: Gerd Hoffmann <kraxel(a)redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy(a)intel.com> --- drivers/gpu/drm/virtio/virtgpu_gem.c | 8 ++++++++ drivers/gpu/drm/virtio/virtgpu_object.c | 3 +++ drivers/gpu/drm/virtio/virtgpu_plane.c | 18 +++++++++++------- 3 files changed, 22 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c index 8502400b2f9c..5f49fb1cce65 100644 --- a/drivers/gpu/drm/virtio/virtgpu_gem.c +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c @@ -64,6 +64,7 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv, { struct drm_gem_object *gobj; struct virtio_gpu_object_params params = { 0 }; + struct virtio_gpu_device *vgdev = dev->dev_private; int ret; uint32_t pitch; @@ -79,6 +80,13 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv, params.height = args->height; params.size = args->size; params.dumb = true; + + if (vgdev->has_resource_blob) { + params.blob_mem = VIRTGPU_BLOB_MEM_GUEST; + params.blob_flags = VIRTGPU_BLOB_FLAG_USE_SHAREABLE; + params.blob = true; + } + ret = virtio_gpu_gem_create(file_priv, dev, &params, &gobj, &args->handle); if (ret) diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index 4ff1ec28e630..f648b0e24447 100644 --- a/drivers/gpu/drm/virtio/virtgpu_object.c +++ b/drivers/gpu/drm/virtio/virtgpu_object.c @@ -254,6 +254,9 @@ int virtio_gpu_object_create(struct virtio_gpu_device *vgdev, } if (params->blob) { + if (params->blob_mem == VIRTGPU_BLOB_MEM_GUEST) + bo->guest_blob = true; + virtio_gpu_cmd_resource_create_blob(vgdev, bo, params, ents, nents); } else if (params->virgl) { diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c index 4e1b17548007..3731f1a6477d 100644 --- a/drivers/gpu/drm/virtio/virtgpu_plane.c +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c @@ -161,10 +161,11 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane, return; bo = gem_to_virtio_gpu_obj(plane->state->fb->obj[0]); - if (bo->dumb) + if (bo->dumb && !bo->guest_blob) virtio_gpu_update_dumb_bo(vgdev, plane->state, &rect); - if (plane->state->fb != old_state->fb || + if ((bo->dumb && bo->guest_blob) || + plane->state->fb != old_state->fb || plane->state->src_w != old_state->src_w || plane->state->src_h != old_state->src_h || plane->state->src_x != old_state->src_x || @@ -198,11 +199,14 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane, } } - virtio_gpu_cmd_resource_flush(vgdev, bo->hw_res_handle, - rect.x1, - rect.y1, - rect.x2 - rect.x1, - rect.y2 - rect.y1); + if (!bo->guest_blob) { + virtio_gpu_cmd_resource_flush(vgdev, bo->hw_res_handle, + rect.x1, + rect.y1, + rect.x2 - rect.x1, + rect.y2 - rect.y1); + } + virtio_gpu_notify(vgdev); } -- 2.26.2

5 18

[PATCH v3 0/3] drm/bridge: Add it66121 driver
by Neil Armstrong 15 Apr '21

15 Apr '21

The IT66121 is a high-performance and low-power single channel HDMI transmitter, fully compliant with HDMI 1.3a, HDCP 1.2 and backward compatible to DVI 1.0 specifications. It supports pixel rates from 25MHz to 165MHz. This series contains document bindings, add vendor prefix, Kconfig to enable or not. For now, the driver handles only RGB without color conversion. Audio, CEC and HDCP are not implemented yet. Changes since v2 at [1]: - fixed DT bindings by: - adding bus-width property to input port - correctly defining ports - other minor fixes - fixed bridge driver by: - general cleanup following Andy's comments - implemented support for NO_CONNECTOR - makes basic usage of the bus width property - add support for bus format negociation - other minor fixes - fixed order of MAINTAINERS entries [1] https://lore.kernel.org/r/20200311125135.30832-1-ple@baylibre.com Phong LE (3): dt-bindings: display: bridge: add it66121 bindings drm: bridge: add it66121 driver MAINTAINERS: add it66121 HDMI bridge driver entry .../bindings/display/bridge/ite,it66121.yaml | 123 ++ MAINTAINERS | 8 + drivers/gpu/drm/bridge/Kconfig | 8 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ite-it66121.c | 1081 +++++++++++++++++ 5 files changed, 1221 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml create mode 100644 drivers/gpu/drm/bridge/ite-it66121.c -- 2.25.1

5 21

[PATCH v3 0/9] drm: Support simple-framebuffer devices and firmware fbs
by Thomas Zimmermann 15 Apr '21

15 Apr '21

This patchset adds support for simple-framebuffer platform devices and a handover mechanism for native drivers to take-over control of the hardware. The new driver, called simpledrm, binds to a simple-frambuffer platform device. The kernel's boot code creates such devices for firmware-provided framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot loader sets up the framebuffers. Description via device tree is also an option. Simpledrm is small enough to be linked into the kernel. The driver's main purpose is to provide graphical output during the early phases of the boot process, before the native DRM drivers are available. Native drivers are typically loaded from an initrd ram disk. Occationally simpledrm can also serve as interim solution on graphics hardware without native DRM driver. So far distributions rely on fbdev drivers, such as efifb, vesafb or simplefb, for early-boot graphical output. However fbdev is deprecated and the drivers do not provide DRM interfaces for modern userspace. Patches 1 and 2 prepare the DRM format helpers for simpledrm. Patches 4 to 8 add the simpledrm driver. It's build on simple DRM helpers and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During pageflips, SHMEM buffers are copied into the framebuffer memory, similar to cirrus or mgag200. The code in patches 7 and 8 handles clocks and regulators. It's based on the simplefb drivers, but has been modified for DRM. Patches 3 and 9 add a hand-over mechanism. Simpledrm acquires it's framebuffer's I/O-memory range and provides a callback function to be removed by a native driver. The native driver will remove simpledrm before taking over the hardware. The removal is integrated into existing helpers, so drivers use it automatically. I've also been working on fastboot support (i.e., flicker-free booting). This requires state-readout from simpledrm via generic interfaces, as outlined in [1]. I do have some prototype code, but it will take a while to get this ready. Simpledrm will then support it. I've tested simpledrm with x86 EFI and VESA framebuffers, which both work reliably. The fbdev console and Weston work automatically. Xorg requires manual configuration of the device. Xorgs current modesetting driver does not work with both, platform and PCI device, for the same physical hardware. Once configured, X11 works. I looked into X11, but couldn't see an easy way of fixing the problem. With the push towards Wayland+Xwayland I expect the problem to become a non-issue soon. Additional testing has been reported at [2]. One cosmetical issue is that simpledrm's device file is card0 and the native driver's device file is card1. After simpledrm has been kicked out, only card1 is left. This does not seem to be a practical problem however. TODO/IDEAS: * provide deferred takeover * provide bootsplash DRM client * make simplekms usable with ARM-EFI fbs v3: * clear screen to black when disabled (Daniel) * rebase onto existing aperture helpers * detach via hot-unplug via platform_device_unregister() v2: * rename to simpledrm, aperture helpers * reorganized patches * use hotplug helpers for removal (Daniel) * added DT match tables (Rob) * use shadow-plane helpers * lots of minor cleanups [1] https://lore.kernel.org/dri-devel/CAKMK7uHtqHy_oz4W7F+hmp9iqp7W5Ra8CxPvJ=9B… [2] https://lore.kernel.org/dri-devel/1761762.3HQLrFs1K7@nerdopolis/ Thomas Zimmermann (9): drm/format-helper: Pass destination pitch to drm_fb_memcpy_dstclip() drm/format-helper: Add blitter functions drm/aperture: Add infrastructure for aperture ownership drm: Add simpledrm driver drm/simpledrm: Add fbdev emulation drm/simpledrm: Initialize framebuffer data from device-tree node drm/simpledrm: Acquire clocks from DT device node drm/simpledrm: Acquire regulators from DT device node drm/simpledrm: Acquire memory aperture for framebuffer MAINTAINERS | 7 + drivers/gpu/drm/drm_aperture.c | 216 +++++- drivers/gpu/drm/drm_format_helper.c | 96 ++- drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +- drivers/gpu/drm/tiny/Kconfig | 16 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/cirrus.c | 2 +- drivers/gpu/drm/tiny/simpledrm.c | 920 +++++++++++++++++++++++++ include/drm/drm_aperture.h | 36 +- include/drm/drm_format_helper.h | 10 +- 10 files changed, 1279 insertions(+), 27 deletions(-) create mode 100644 drivers/gpu/drm/tiny/simpledrm.c -- 2.31.1

1 9

[PATCH] drm/kmb: remove unused function
by Jiapeng Chong 15 Apr '21

15 Apr '21

Fix the following clang warning: drivers/gpu/drm/kmb/kmb_dsi.c:824:2: warning: unused function 'set_test_mode_src_osc_freq_target_hi_bits' [-Wunused-function]. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/kmb/kmb_dsi.c | 16 ---------------- 1 file changed, 16 deletions(-) diff --git a/drivers/gpu/drm/kmb/kmb_dsi.c b/drivers/gpu/drm/kmb/kmb_dsi.c index 4b5d82a..448cc1b 100644 --- a/drivers/gpu/drm/kmb/kmb_dsi.c +++ b/drivers/gpu/drm/kmb/kmb_dsi.c @@ -820,22 +820,6 @@ static void test_mode_send(struct kmb_dsi *kmb_dsi, u32 dphy_no, (freq & 0x7f)); } -static inline void - set_test_mode_src_osc_freq_target_hi_bits(struct kmb_dsi *kmb_dsi, - u32 dphy_no, - u32 freq) -{ - u32 data; - - /* Flag this as high nibble */ - data = ((freq >> 6) & 0x1f) | (1 << 7); - - /* Typical rise/fall time=166, refer Table 1207 databook, - * sr_osc_freq_target[11:7] - */ - test_mode_send(kmb_dsi, dphy_no, TEST_CODE_SLEW_RATE_DDL_CYCLES, data); -} - static void mipi_tx_get_vco_params(struct vco_params *vco) { int i; -- 1.8.3.1

1 0

[PATCH 00/18] drm/vc4: hdmi: Add Support for the YUV output
by Maxime Ripard 15 Apr '21

15 Apr '21

Hi, Here's an attempt at support the HDMI YUV output on the BCM2711 SoC found on the RaspberryPi4. I took the same approach than what dw-hdmi did already, turning a bunch of functions found in that driver into helpers since they were fairly generic. However, it feels a bit clunky overall and there's a few rough edges that should be addressed in a generic manner: - while the format negociation makes sense for a bridge, it feels a bit over-engineered for a simple encoder where that setting could be a simple switch (and possibly a property?) - more importantly, whether we're choosing an YUV output or not is completely hidden away from the userspace even though it might have some effect on the visual quality output (thinking about YUV420 and YUV422 here mostly). - Similarly, the list we report is static and the userspace cannot change or force one mode over the other. We will always pick YUV444 over RGB444 if both are available for example. While the first one might just be due to a lack of helpers, the second and third ones are also feeling a bit inconsistent with how we're handling the 10/12 bit output for example Let me know what you think, Maxime Maxime Ripard (18): drm: Introduce new HDMI helpers drm/bridge: Add HDMI output fmt helper drm/bridge: dw-hdmi: Use helpers drm/vc4: txp: Properly set the possible_crtcs mask drm/vc4: crtc: Skip the TXP drm/vc4: Rework the encoder retrieval code drm/vc4: hdmi: Add full range RGB helper drm/vc4: hdmi: Use full range helper in csc functions drm/vc4: hdmi: Remove limited_rgb_range drm/vc4: hdmi: Convert to bridge drm/vc4: hdmi: Move XBAR setup to csc_setup drm/vc4: hdmi: Replace CSC_CTL hardcoded value by defines drm/vc4: hdmi: Define colorspace matrices drm/vc4: hdmi: Change CSC callback prototype drm/vc4: hdmi: Rework the infoframe prototype drm/vc4: hdmi: Support HDMI YUV output drm/vc4: hdmi: Move the pixel rate calculation to a helper drm/vc4: hdmi: Force YUV422 if the rate is too high drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 268 ++------------- drivers/gpu/drm/drm_bridge.c | 118 +++++++ drivers/gpu/drm/drm_hdmi.c | 170 +++++++++ drivers/gpu/drm/vc4/vc4_crtc.c | 59 +++- drivers/gpu/drm/vc4/vc4_drv.c | 41 +++ drivers/gpu/drm/vc4/vc4_drv.h | 26 +- drivers/gpu/drm/vc4/vc4_hdmi.c | 399 +++++++++++++++------- drivers/gpu/drm/vc4/vc4_hdmi.h | 13 +- drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 6 + drivers/gpu/drm/vc4/vc4_regs.h | 19 ++ drivers/gpu/drm/vc4/vc4_txp.c | 2 +- include/drm/drm_bridge.h | 6 + include/drm/drm_hdmi.h | 24 ++ 14 files changed, 770 insertions(+), 383 deletions(-) create mode 100644 drivers/gpu/drm/drm_hdmi.c create mode 100644 include/drm/drm_hdmi.h -- 2.30.2

4 45

[PATCH v4 0/3] Add devcoredump support for DPU
by Abhinav Kumar 15 Apr '21

15 Apr '21

This series adds support to use devcoredump for DPU driver. It introduces the msm_disp_snapshot module which assists in the capturing of register dumps during error scenarios. When a display related error happens, the msm_disp_snapshot module captures all the relevant register dumps along with the snapshot of the drm atomic state and triggers a devcoredump. changes in v4: - rename dpu_dbg to msm_disp_snapshot and move it to msm/disp - start using a list of blocks to store the hardware block information - cleanup block allocation and freeing logic to simplify it Abhinav Kumar (3): drm: allow drm_atomic_print_state() to accept any drm_printer drm/msm: add support to take dpu snapshot drm/msm: add disp snapshot points across dpu driver drivers/gpu/drm/drm_atomic.c | 28 +++- drivers/gpu/drm/drm_atomic_uapi.c | 4 +- drivers/gpu/drm/drm_crtc_internal.h | 4 +- drivers/gpu/drm/msm/Makefile | 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 +- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 14 +- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 8 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 61 +++++++ drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 5 + drivers/gpu/drm/msm/disp/msm_disp_snapshot.c | 161 ++++++++++++++++++ drivers/gpu/drm/msm/disp/msm_disp_snapshot.h | 167 +++++++++++++++++++ drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c | 181 +++++++++++++++++++++ drivers/gpu/drm/msm/dp/dp_catalog.c | 12 ++ drivers/gpu/drm/msm/dp/dp_catalog.h | 4 + drivers/gpu/drm/msm/dp/dp_display.c | 29 ++++ drivers/gpu/drm/msm/dp/dp_display.h | 1 + drivers/gpu/drm/msm/dsi/dsi.c | 5 + drivers/gpu/drm/msm/dsi/dsi.h | 4 + drivers/gpu/drm/msm/dsi/dsi_host.c | 19 +++ drivers/gpu/drm/msm/msm_drv.c | 29 +++- drivers/gpu/drm/msm/msm_drv.h | 2 + drivers/gpu/drm/selftests/test-drm_framebuffer.c | 1 + 23 files changed, 743 insertions(+), 18 deletions(-) create mode 100644 drivers/gpu/drm/msm/disp/msm_disp_snapshot.c create mode 100644 drivers/gpu/drm/msm/disp/msm_disp_snapshot.h create mode 100644 drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

4 6

[PATCH 00/34] Add HMM-based SVM memory manager to KFD v5
by Felix Kuehling 15 Apr '21

15 Apr '21

Updates since v4: - Rebased on upstream. - Added SPDX license headers and updated copyright on added files - Disabled XNACK on GFXv10 and later GPUs that don't support shader preemption on fault - Updated PTE flags for Aldebaran This series and the corresponding ROCm Thunk and KFDTest changes are also available on gitub and patchwork. Link: https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/tree/fxkamd/hmm-wip Link: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/tree/fxkamd/hmm-w… Link: https://patchwork.freedesktop.org/series/85563/ Alex Sierra (9): drm/amdkfd: helper to convert gpu id and idx drm/amdkfd: add xnack enabled flag to kfd_process drm/amdkfd: add ioctl to configure and query xnack retries drm/amdgpu: enable 48-bit IH timestamp counter drm/amdkfd: SVM API call to restore page tables drm/amdkfd: add svm_bo reference for eviction fence drm/amdgpu: add param bit flag to create SVM BOs drm/amdgpu: svm bo enable_signal call condition drm/amdgpu: add svm_bo eviction to enable_signal cb Felix Kuehling (13): drm/amdkfd: map svm range to GPUs drm/amdkfd: svm range eviction and restore drm/amdgpu: Enable retry faults unconditionally on Aldebaran drm/amdkfd: validate vram svm range from TTM drm/amdkfd: HMM migrate ram to vram drm/amdkfd: HMM migrate vram to ram drm/amdkfd: invalidate tables on page retry fault drm/amdkfd: page table restore through svm API drm/amdkfd: add svm_bo eviction mechanism support drm/amdkfd: refine migration policy with xnack on drm/amdkfd: add svm range validate timestamp drm/amdkfd: multiple gpu migrate vram to vram drm/amdkfd: Add CONFIG_HSA_AMD_SVM Philip Yang (12): drm/amdkfd: add svm ioctl API drm/amdkfd: register svm range drm/amdkfd: add svm ioctl GET_ATTR op drm/amdgpu: add common HMM get pages function drm/amdkfd: support larger svm range allocation drm/amdkfd: validate svm range system memory drm/amdkfd: deregister svm range drm/amdgpu: export vm update mapping interface drm/amdkfd: register HMM device private zone drm/amdkfd: support xgmi same hive mapping drm/amdkfd: copy memory through gart table drm/amdkfd: Add SVM API support capability bits drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 4 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 16 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 13 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 86 + drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h | 7 + drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 4 + drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 90 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 38 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 11 + drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 8 +- drivers/gpu/drm/amd/amdgpu/mmhub_v1_7.c | 6 +- drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 1 + drivers/gpu/drm/amd/amdkfd/Kconfig | 13 + drivers/gpu/drm/amd/amdkfd/Makefile | 5 + drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 64 + drivers/gpu/drm/amd/amdkfd/kfd_device.c | 4 + .../amd/amdkfd/kfd_device_queue_manager_v9.c | 13 +- drivers/gpu/drm/amd/amdkfd/kfd_flat_memory.c | 4 + drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 923 ++++++ drivers/gpu/drm/amd/amdkfd/kfd_migrate.h | 65 + drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 36 + drivers/gpu/drm/amd/amdkfd/kfd_process.c | 90 + drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 2902 +++++++++++++++++ drivers/gpu/drm/amd/amdkfd/kfd_svm.h | 206 ++ drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 6 + drivers/gpu/drm/amd/amdkfd/kfd_topology.h | 10 +- include/uapi/linux/kfd_ioctl.h | 171 +- 28 files changed, 4693 insertions(+), 106 deletions(-) create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_migrate.c create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_migrate.h create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_svm.c create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_svm.h -- 2.31.1

1 34

[PATCH v2 00/14] drm: Fix EDID reading on ti-sn65dsi86
by Douglas Anderson 15 Apr '21

15 Apr '21

The primary goal of this series is to try to properly fix EDID reading for eDP panels using the ti-sn65dsi86 bridge. Previously we had a patch that added EDID reading but it turned out not to work at bootup. This caused some extra churn at bootup as we tried (and failed) to read the EDID several times and also ended up forcing us to use the hardcoded mode at boot. With this patch series I believe EDID reading is reliable at boot now and we never use the hardcoded mode. This series is the logical successor to the 3-part series containing the patch ("drm/bridge: ti-sn65dsi86: Properly get the EDID, but only if refclk") [1] though only one actual patch is the same between the two. This series starts out with some general / obvious fixes and moves on to some more specific and maybe controversial ones. I wouldn't object to some of the earlier ones landing if they look ready. This patch was developed against drm-misc-next on a sc7180-trogdor-lazor device. To get things booting for me, I had to use Stephen's patch [2] to keep from crashing but otherwise all the patches I needed were here. [1] https://lore.kernel.org/r/20210304155144.3.I60a7fb23ce4589006bc95c64ab8d15c… [2] https://lore.kernel.org/r/161706912161.3012082.17313817257247946143@swboyd.… Changes in v2: - Removed 2nd paragraph in commit message. Douglas Anderson (14): drm/bridge: Fix the stop condition of drm_bridge_chain_pre_enable() drm/bridge: ti-sn65dsi86: Simplify refclk handling drm/bridge: ti-sn65dsi86: Remove incorrectly tagged kerneldoc comment drm/bridge: ti-sn65dsi86: Reorder remove() drm/bridge: ti-sn65dsi86: Move MIPI detach() / unregister() to detach() drm/bridge: ti-sn65dsi86: Move drm_panel_unprepare() to post_disable() drm/bridge: ti-sn65dsi86: Get rid of the useless detect() function drm/bridge: ti-sn65dsi86: Remove extra call: drm_connector_update_edid_property() drm/edid: Use the cached EDID in drm_get_edid() if eDP drm/bridge: ti-sn65dsi86: Stop caching the EDID ourselves drm/bridge: ti-sn65dsi86: Power things properly for reading the EDID drm/bridge: ti-sn65dsi86: Read the EDID only if refclk was provided drm/bridge: ti-sn65dsi86: Print an error if we fallback to panel modes drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare drivers/gpu/drm/bridge/ti-sn65dsi86.c | 125 ++++++++++++++++---------- drivers/gpu/drm/drm_bridge.c | 3 + drivers/gpu/drm/drm_edid.c | 32 ++++++- drivers/gpu/drm/panel/Kconfig | 1 + drivers/gpu/drm/panel/panel-simple.c | 93 ++++++++++++++----- 5 files changed, 184 insertions(+), 70 deletions(-) -- 2.31.0.291.g576ba9dcdaf-goog

5 34

[PATCH v2 1/3] drm/msm/dp: check sink_count before update is_connected status
by Kuogee Hsieh 14 Apr '21

14 Apr '21

Link status is different from display connected status in the case of something like an Apple dongle where the type-c plug can be connected, and therefore the link is connected, but no sink is connected until an HDMI cable is plugged into the dongle. The sink_count of DPCD of dongle will increase to 1 once an HDMI cable is plugged into the dongle so that display connected status will become true. This checking also apply at pm_resume. Fixes: 94e58e2d06e3 ("drm/msm/dp: reset dp controller only at boot up and pm_resume") Reported-by: Stephen Boyd <swboyd(a)chromium.org> Reviewed-by: Stephen Boyd <swboyd(a)chromium.org> Tested-by: Stephen Boyd <swboyd(a)chromium.org> Signed-off-by: Kuogee Hsieh <khsieh(a)codeaurora.org> --- drivers/gpu/drm/msm/dp/dp_display.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c index 5a39da6..0ba71c7 100644 --- a/drivers/gpu/drm/msm/dp/dp_display.c +++ b/drivers/gpu/drm/msm/dp/dp_display.c @@ -586,10 +586,8 @@ static int dp_connect_pending_timeout(struct dp_display_private *dp, u32 data) mutex_lock(&dp->event_mutex); state = dp->hpd_state; - if (state == ST_CONNECT_PENDING) { - dp_display_enable(dp, 0); + if (state == ST_CONNECT_PENDING) dp->hpd_state = ST_CONNECTED; - } mutex_unlock(&dp->event_mutex); @@ -669,10 +667,8 @@ static int dp_disconnect_pending_timeout(struct dp_display_private *dp, u32 data mutex_lock(&dp->event_mutex); state = dp->hpd_state; - if (state == ST_DISCONNECT_PENDING) { - dp_display_disable(dp, 0); + if (state == ST_DISCONNECT_PENDING) dp->hpd_state = ST_DISCONNECTED; - } mutex_unlock(&dp->event_mutex); @@ -1272,7 +1268,12 @@ static int dp_pm_resume(struct device *dev) status = dp_catalog_link_is_connected(dp->catalog); - if (status) + /* + * can not declared display is connected unless + * HDMI cable is plugged in and sink_count of + * dongle become 1 + */ + if (status && dp->link->sink_count) dp->dp_display.is_connected = true; else dp->dp_display.is_connected = false; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

2 1

[PATCH resend 0/9] drm: Add privacy-screen class and connector properties
by Hans de Goede 14 Apr '21

14 Apr '21

Hi All, Here is the privacy-screen related code which I last posted in August of last year. To the best of my knowledge there is consensus about / everyone is in agreement with the new userspace API (2 connector properties) this patch-set add (patch 1 of the series). The blocker the last time was that there were no userspace users of the new properties and as a rule we don't add new drm userspace API without users. There now is GNOME userspace code using the new properties: https://hackmd.io/@3v1n0/rkyIy3BOw The new API works as designed for this userspace user and the branches mentioned at the above link add the following features to GNOME: 1. Showing an OSD notification when the privacy-screen is toggled on/off through hotkeys handled by the embedded-controller 2. Allowing control of the privacy-screen from the GNOME control-panel, including the on/off slider shown there updating to match the hw-setting when the setting is changed with the control-panel open. 3. Restoring the last user-setting at login This series consists of a number of different parts: 1. A new version of Rajat's privacy-screen connector properties patch, this adds new userspace API in the form of new properties 2. Since on most devices the privacy screen is actually controlled by some vendor specific ACPI/WMI interface which has a driver under drivers/platform/x86, we need some "glue" code to make this functionality available to KMS drivers. Patches 2-4 add a new privacy-screen class for this, which allows non KMS drivers (and possibly KMS drivers too) to register a privacy-screen device and also adds an interface for KMS drivers to get access to the privacy-screen associated with a specific connector. This is modelled similar to how we deal with e.g. PWMs and GPIOs in the kernel, including separate includes for consumers and providers(drivers). 3. Some drm_connector helper functions to keep the actual changes needed for this in individual KMS drivers as small as possible (patch 5). 4. Make the thinkpad_acpi code register a privacy-screen device on ThinkPads with a privacy-screen (patches 6-8) 5. Make the i915 driver export the privacy-screen functionality through the connector properties on the eDP connector. I believe that it would be best to merge the entire series, including the thinkpad_acpi changes through drm-misc in one go. As the pdx86 subsys maintainer I hereby give my ack for merging the thinkpad_acpi changes through drm-misc. There is one small caveat with this series, which it is good to be aware of. The i915 driver will now return -EPROBE_DEFER on Thinkpads with an eprivacy screen, until the thinkpad_acpi driver is loaded. This means that initrd generation tools will need to be updated to include thinkpad_acpi when the i915 driver is added to the initrd. Without this the loading of the i915 driver will be delayed to after the switch to real rootfs. Regards, Hans Hans de Goede (8): drm: Add privacy-screen class drm/privacy-screen: Add X86 specific arch init code drm/privacy-screen: Add notifier support drm/connector: Add a drm_connector privacy-screen helper functions platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey() helper platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI handles only once platform/x86: thinkpad_acpi: Register a privacy-screen device drm/i915: Add privacy-screen support Rajat Jain (1): drm/connector: Add support for privacy-screen properties (v4) Documentation/gpu/drm-kms-helpers.rst | 15 + Documentation/gpu/drm-kms.rst | 2 + MAINTAINERS | 8 + drivers/gpu/drm/Kconfig | 5 + drivers/gpu/drm/Makefile | 4 + drivers/gpu/drm/drm_atomic_uapi.c | 4 + drivers/gpu/drm/drm_connector.c | 214 ++++++++ drivers/gpu/drm/drm_privacy_screen.c | 493 +++++++++++++++++++ drivers/gpu/drm/drm_privacy_screen_x86.c | 82 +++ drivers/gpu/drm/i915/display/intel_display.c | 5 + drivers/gpu/drm/i915/display/intel_dp.c | 10 + drivers/gpu/drm/i915/i915_pci.c | 12 + drivers/platform/x86/Kconfig | 1 + drivers/platform/x86/thinkpad_acpi.c | 131 +++-- include/drm/drm_connector.h | 56 +++ include/drm/drm_privacy_screen_consumer.h | 32 ++ include/drm/drm_privacy_screen_driver.h | 84 ++++ include/drm/drm_privacy_screen_machine.h | 46 ++ 18 files changed, 1162 insertions(+), 42 deletions(-) create mode 100644 drivers/gpu/drm/drm_privacy_screen.c create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c create mode 100644 include/drm/drm_privacy_screen_consumer.h create mode 100644 include/drm/drm_privacy_screen_driver.h create mode 100644 include/drm/drm_privacy_screen_machine.h -- 2.31.1

2 10

← Newer
1
...
44
45
46
47
48
49
50
...
72
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2021