dri-devel October 2021

dri-devel@lists.freedesktop.org

347 participants
825 discussions

[PATCH v4 0/4] check sink_count before update is_connected status
by Kuogee Hsieh 01 Dec '21

01 Dec '21

1) check sink_count before update is_connected status 2) initialize audio_comp when audio starts 3) check main link status before start aux read 4) dp_link_parse_sink_count() return immediately if aux read failed Kuogee Hsieh (4): drm/msm/dp: check sink_count before update is_connected status drm/msm/dp: initialize audio_comp when audio starts drm/msm/dp: check main link status before start aux read drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read failed drivers/gpu/drm/msm/dp/dp_audio.c | 1 + drivers/gpu/drm/msm/dp/dp_aux.c | 5 +++++ drivers/gpu/drm/msm/dp/dp_display.c | 38 +++++++++++++++++++++++++------------ drivers/gpu/drm/msm/dp/dp_display.h | 1 + drivers/gpu/drm/msm/dp/dp_link.c | 20 ++++++++++++++----- 5 files changed, 48 insertions(+), 17 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

5 11

[PATCH v2 0/3] drm/etnaviv: IOMMU related fixes
by Michael Walle 01 Dec '21

01 Dec '21

This patch series fixes usage of the etnaviv driver with GPUs behind a IOMMU. It was tested on a NXP LS1028A SoC. Together with Lucas' MMU patches [1] there are not more (GPU internal) MMU nor (system) IOMMU faults on the LS1028A. [1] https://lists.freedesktop.org/archives/etnaviv/2021-August/003682.html changes since v1: - don't move the former dma_mask setup code around in patch 2/3. Will avoid any confusion. Michael Walle (3): drm/etnaviv: use PLATFORM_DEVID_NONE drm/etnaviv: fix dma configuration of the virtual device drm/etnaviv: use a 32 bit mask as coherent DMA mask drivers/gpu/drm/etnaviv/etnaviv_drv.c | 41 ++++++++++++++++++++------- 1 file changed, 31 insertions(+), 10 deletions(-) -- 2.30.2

3 8

[PATCH 01/28] drm/i915: Fix i915_request fence wait semantics
by Maarten Lankhorst 29 Nov '21

29 Nov '21

The i915_request fence wait behaves differently for timeout = 0 compared to expected dma-fence behavior. i915 behavior: - Unsignaled: -ETIME - Signaled: 0 (= timeout) Expected: - Unsignaled: 0 - Signaled: 1 Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> --- drivers/gpu/drm/i915/i915_request.c | 57 ++++++++++++++++++++++++----- drivers/gpu/drm/i915/i915_request.h | 5 +++ 2 files changed, 52 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 820a1f38b271..42cd17357771 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -96,9 +96,9 @@ static signed long i915_fence_wait(struct dma_fence *fence, bool interruptible, signed long timeout) { - return i915_request_wait(to_request(fence), - interruptible | I915_WAIT_PRIORITY, - timeout); + return i915_request_wait_timeout(to_request(fence), + interruptible | I915_WAIT_PRIORITY, + timeout); } struct kmem_cache *i915_request_slab_cache(void) @@ -1857,23 +1857,27 @@ static void request_wait_wake(struct dma_fence *fence, struct dma_fence_cb *cb) } /** - * i915_request_wait - wait until execution of request has finished + * i915_request_wait_timeout - wait until execution of request has finished * @rq: the request to wait upon * @flags: how to wait * @timeout: how long to wait in jiffies * - * i915_request_wait() waits for the request to be completed, for a + * i915_request_wait_timeout() waits for the request to be completed, for a * maximum of @timeout jiffies (with MAX_SCHEDULE_TIMEOUT implying an * unbounded wait). * * Returns the remaining time (in jiffies) if the request completed, which may - * be zero or -ETIME if the request is unfinished after the timeout expires. + * be zero if the request is unfinished after the timeout expires. + * If the timeout is 0, it will return 1 if the fence is signaled. + * * May return -EINTR is called with I915_WAIT_INTERRUPTIBLE and a signal is * pending before the request completes. + * + * NOTE: This function has the same wait semantics as dma-fence. */ -long i915_request_wait(struct i915_request *rq, - unsigned int flags, - long timeout) +long i915_request_wait_timeout(struct i915_request *rq, + unsigned int flags, + long timeout) { const int state = flags & I915_WAIT_INTERRUPTIBLE ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE; @@ -1883,7 +1887,7 @@ long i915_request_wait(struct i915_request *rq, GEM_BUG_ON(timeout < 0); if (dma_fence_is_signaled(&rq->fence)) - return timeout; + return timeout ?: 1; if (!timeout) return -ETIME; @@ -1992,6 +1996,39 @@ long i915_request_wait(struct i915_request *rq, return timeout; } +/** + * i915_request_wait - wait until execution of request has finished + * @rq: the request to wait upon + * @flags: how to wait + * @timeout: how long to wait in jiffies + * + * i915_request_wait() waits for the request to be completed, for a + * maximum of @timeout jiffies (with MAX_SCHEDULE_TIMEOUT implying an + * unbounded wait). + * + * Returns the remaining time (in jiffies) if the request completed, which may + * be zero or -ETIME if the request is unfinished after the timeout expires. + * May return -EINTR is called with I915_WAIT_INTERRUPTIBLE and a signal is + * pending before the request completes. + * + * NOTE: This function behaves differently from dma-fence wait semantics for + * timeout = 0. It returns 0 on success, and -ETIME if not signaled. + */ +long i915_request_wait(struct i915_request *rq, + unsigned int flags, + long timeout) +{ + long ret = i915_request_wait_timeout(rq, flags, timeout); + + if (!ret) + return -ETIME; + + if (ret > 0 && !timeout) + return 0; + + return ret; +} + static int print_sched_attr(const struct i915_sched_attr *attr, char *buf, int x, int len) { diff --git a/drivers/gpu/drm/i915/i915_request.h b/drivers/gpu/drm/i915/i915_request.h index dc359242d1ae..3c6e8acd1457 100644 --- a/drivers/gpu/drm/i915/i915_request.h +++ b/drivers/gpu/drm/i915/i915_request.h @@ -414,6 +414,11 @@ void i915_request_unsubmit(struct i915_request *request); void i915_request_cancel(struct i915_request *rq, int error); +long i915_request_wait_timeout(struct i915_request *rq, + unsigned int flags, + long timeout) + __attribute__((nonnull(1))); + long i915_request_wait(struct i915_request *rq, unsigned int flags, long timeout) -- 2.33.0

6 62

[PATCH] drm/i915: Disable bonding on gen12+ platforms
by Matthew Brost 26 Nov '21

26 Nov '21

Disable bonding on gen12+ platforms aside from ones already supported by the i915 - TGL, RKL, and ADL-S. Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c index 05c3ee191710..9c3672bac0e2 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c @@ -446,6 +446,13 @@ set_proto_ctx_engines_bond(struct i915_user_extension __user *base, void *data) u16 idx, num_bonds; int err, n; + if (GRAPHICS_VER(i915) >= 12 && !IS_TIGERLAKE(i915) && + !IS_ROCKETLAKE(i915) && !IS_ALDERLAKE_S(i915)) { + drm_dbg(&i915->drm, + "Bonding on gen12+ aside from TGL, RKL, and ADL_S not allowed\n"); + return -ENODEV; + } + if (get_user(idx, &ext->virtual_index)) return -EFAULT; -- 2.28.0

5 4

[RFC 00/13] MediaTek MT8192 APU
by Flora Fu 26 Nov '21

26 Nov '21

Add Support for MediaTek MT8192 APU. The MediaTek AI Processing Unit (APU) is a proprietary hardware in the SoC to support AI functions. The patches support the MT8192 APU running on internal microprocess. Software packages contins power control, tinysys controller and middleware. This series is based on drivers implemented in MT8192 apu power domain[1] and IOMMU[2] patches. [1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=568927 [2] https://patchwork.kernel.org/project/linux-mediatek/list/?series=551641 The device tree depends on [3][4][5] which haven't yet been accepted. [3] https://patchwork.kernel.org/project/linux-mediatek/list/?series=521655 [4] https://patchwork.kernel.org/patch/12134935 [5] https://patchwork.kernel.org/patch/12140237 Flora Fu (12): dt-bindings: soc: mediatek: apusys: add mt8192 apu iommu bindings dt-bindings: soc: mediatek: apusys: Add new document for APU power dt-bindings: soc: mediatek: apusys: Add new document for APU tinysys iommu/mediatek: Add APU iommu support soc: mediatek: Add command for APU SMC call soc: mediatek: apu: Add apu core driver soc: mediatek: apu: Add apu power driver soc: mediatek: apu: Add apusys rv driver soc: mediatek: apu: Add middleware driver arm64: dts: mt8192: Add apu power nodes arm64: dts: mt8192: Add apu tinysys arm64: dts: mt8192: Add regulator for APU Yong Wu (1): arm64: dts: mt8192: Add APU-IOMMU nodes .../bindings/iommu/mediatek,iommu.yaml | 2 + .../soc/mediatek/mediatek,apu-pwr.yaml | 88 ++ .../soc/mediatek/mediatek,apu-rv.yaml | 140 +++ arch/arm64/boot/dts/mediatek/mt8192-evb.dts | 5 + arch/arm64/boot/dts/mediatek/mt8192.dtsi | 107 ++ drivers/iommu/mtk_iommu.c | 57 ++ drivers/soc/mediatek/Kconfig | 18 + drivers/soc/mediatek/apusys/Makefile | 22 + drivers/soc/mediatek/apusys/apu-config.h | 100 ++ drivers/soc/mediatek/apusys/apu-core.c | 97 ++ drivers/soc/mediatek/apusys/apu-core.h | 18 + drivers/soc/mediatek/apusys/apu-device.h | 39 + drivers/soc/mediatek/apusys/apu-ipi.c | 486 +++++++++ drivers/soc/mediatek/apusys/apu-mbox.c | 83 ++ drivers/soc/mediatek/apusys/apu-mbox.h | 27 + drivers/soc/mediatek/apusys/apu-pwr-dbg.c | 167 ++++ drivers/soc/mediatek/apusys/apu-pwr-ipi.c | 377 +++++++ drivers/soc/mediatek/apusys/apu-pwr.c | 599 +++++++++++ drivers/soc/mediatek/apusys/apu-pwr.h | 260 +++++ drivers/soc/mediatek/apusys/apu-rproc.c | 806 +++++++++++++++ drivers/soc/mediatek/apusys/apu-sw-logger.c | 429 ++++++++ drivers/soc/mediatek/apusys/apu.h | 256 +++++ drivers/soc/mediatek/apusys/mdw-cmd.c | 618 ++++++++++++ drivers/soc/mediatek/apusys/mdw-drv.c | 211 ++++ drivers/soc/mediatek/apusys/mdw-ioctl.c | 331 ++++++ drivers/soc/mediatek/apusys/mdw-ioctl.h | 256 +++++ drivers/soc/mediatek/apusys/mdw-mem.c | 938 ++++++++++++++++++ drivers/soc/mediatek/apusys/mdw-mem.h | 23 + drivers/soc/mediatek/apusys/mdw-rv-cmd.c | 158 +++ drivers/soc/mediatek/apusys/mdw-rv-dev.c | 386 +++++++ drivers/soc/mediatek/apusys/mdw-rv-msg.h | 90 ++ drivers/soc/mediatek/apusys/mdw-rv.c | 131 +++ drivers/soc/mediatek/apusys/mdw-rv.h | 98 ++ drivers/soc/mediatek/apusys/mdw-sysfs.c | 200 ++++ drivers/soc/mediatek/apusys/mdw.h | 208 ++++ drivers/soc/mediatek/apusys/mt81xx-plat.c | 320 ++++++ include/dt-bindings/memory/mt8192-larb-port.h | 4 + include/linux/soc/mediatek/mtk_sip_svc.h | 2 + 38 files changed, 8157 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pwr.yaml create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-rv.yaml create mode 100644 drivers/soc/mediatek/apusys/apu-config.h create mode 100644 drivers/soc/mediatek/apusys/apu-core.c create mode 100644 drivers/soc/mediatek/apusys/apu-core.h create mode 100644 drivers/soc/mediatek/apusys/apu-device.h create mode 100644 drivers/soc/mediatek/apusys/apu-ipi.c create mode 100644 drivers/soc/mediatek/apusys/apu-mbox.c create mode 100644 drivers/soc/mediatek/apusys/apu-mbox.h create mode 100644 drivers/soc/mediatek/apusys/apu-pwr-dbg.c create mode 100644 drivers/soc/mediatek/apusys/apu-pwr-ipi.c create mode 100644 drivers/soc/mediatek/apusys/apu-pwr.c create mode 100644 drivers/soc/mediatek/apusys/apu-pwr.h create mode 100644 drivers/soc/mediatek/apusys/apu-rproc.c create mode 100644 drivers/soc/mediatek/apusys/apu-sw-logger.c create mode 100644 drivers/soc/mediatek/apusys/apu.h create mode 100644 drivers/soc/mediatek/apusys/mdw-cmd.c create mode 100644 drivers/soc/mediatek/apusys/mdw-drv.c create mode 100644 drivers/soc/mediatek/apusys/mdw-ioctl.c create mode 100644 drivers/soc/mediatek/apusys/mdw-ioctl.h create mode 100644 drivers/soc/mediatek/apusys/mdw-mem.c create mode 100644 drivers/soc/mediatek/apusys/mdw-mem.h create mode 100644 drivers/soc/mediatek/apusys/mdw-rv-cmd.c create mode 100644 drivers/soc/mediatek/apusys/mdw-rv-dev.c create mode 100644 drivers/soc/mediatek/apusys/mdw-rv-msg.h create mode 100644 drivers/soc/mediatek/apusys/mdw-rv.c create mode 100644 drivers/soc/mediatek/apusys/mdw-rv.h create mode 100644 drivers/soc/mediatek/apusys/mdw-sysfs.c create mode 100644 drivers/soc/mediatek/apusys/mdw.h create mode 100644 drivers/soc/mediatek/apusys/mt81xx-plat.c -- 2.18.0

4 23

[PATCH 0/2] drm/msm: Smooth out ringbuffer-full handling
by Rob Clark 25 Nov '21

25 Nov '21

From: Rob Clark <robdclark(a)chromium.org> With some recent userspace work to allow more rendering to be merged into a single SUBMIT ioctl, I realized we have some sharp edges around running out of free ringbuffer space. 1) Currently we only flush once all the cmds (or rather IBs to the cmd buffer) are written into the ringbuffer. Which places a restriction that the submit must fit in the rb. Which means slightly less than 2k cmds per submit, after accounting for some of the other packets needed. 2) Currently, for devices that use RPTR shadow, we only write the CP_WHERE_AM_I packet at the end of the submit, so we aren't seeing partial progress that the GPU is making chewing through previous large submits 3) We spin for up to 1sec waiting for rb space, and then give up and proceed to overwrite the packets that that CP is currently chewing on.. which goes badly. If userspace is submitting >1sec of work per submit ioctl, this means we spin for a long time, and then corrupt the rb anyways. This patchset doesn't completely address #1. And in general we don't want to be uninteruptably blocking for so much time.. but this will require some more extensive changes. What it does do is address #2 by periodically emitting a CP_WHERE_AM_I, and #3 by adding detection and error handling for rb overflow, returning -ENOSPC when that happens. Rob Clark (2): drm/msm: Handle ringbuffer overflow drm/msm: Periodically update RPTR shadow drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 32 ++++++++++++++++++++---- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 30 +++++++++++++++++----- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 24 +++++++++++++++++- drivers/gpu/drm/msm/msm_gem_submit.c | 7 +++++- drivers/gpu/drm/msm/msm_gpu.c | 33 +++++++++++++++++++++++-- drivers/gpu/drm/msm/msm_gpu.h | 2 +- drivers/gpu/drm/msm/msm_ringbuffer.h | 5 ++++ 7 files changed, 117 insertions(+), 16 deletions(-) -- 2.30.2

4 5

[PATCH 1/3] drm/msm/dpu1: Add DMA2, DMA3 clock control to enum
by AngeloGioacchino Del Regno 25 Nov '21

25 Nov '21

The enum dpu_clk_ctrl_type misses DPU_CLK_CTRL_DMA{2,3} even though this driver does actually handle both, if present: add the two in preparation for adding support for SoCs having them. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)somainline.org> --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h index d2a945a27cfa..059e1402b7d0 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h @@ -432,6 +432,8 @@ enum dpu_clk_ctrl_type { DPU_CLK_CTRL_RGB3, DPU_CLK_CTRL_DMA0, DPU_CLK_CTRL_DMA1, + DPU_CLK_CTRL_DMA2, + DPU_CLK_CTRL_DMA3, DPU_CLK_CTRL_CURSOR0, DPU_CLK_CTRL_CURSOR1, DPU_CLK_CTRL_INLINE_ROT0_SSPP, -- 2.32.0

4 14

[PATCH 0/5] xen: cleanup detection of non-essential pv devices
by Juergen Gross 25 Nov '21

25 Nov '21

Today the non-essential pv devices are hard coded in the xenbus driver and this list is lacking multiple entries. This series reworks the detection logic of non-essential devices by adding a flag for that purpose to struct xenbus_driver. Juergen Gross (5): xen: add "not_essential" flag to struct xenbus_driver xen: flag xen_drm_front to be not essential for system boot xen: flag hvc_xen to be not essential for system boot xen: flag pvcalls-front to be not essential for system boot xen: flag xen_snd_front to be not essential for system boot drivers/gpu/drm/xen/xen_drm_front.c | 1 + drivers/input/misc/xen-kbdfront.c | 1 + drivers/tty/hvc/hvc_xen.c | 1 + drivers/video/fbdev/xen-fbfront.c | 1 + drivers/xen/pvcalls-front.c | 1 + drivers/xen/xenbus/xenbus_probe_frontend.c | 14 +++----------- include/xen/xenbus.h | 1 + sound/xen/xen_snd_front.c | 1 + 8 files changed, 10 insertions(+), 11 deletions(-) -- 2.26.2

5 10

[PATCH v4 0/3] Add ilitek ili9341 panel driver
by dillon.minfei＠gmail.com 25 Nov '21

25 Nov '21

From: Dillon Min <dillon.minfei(a)gmail.com> Since the st,sf-tc240t-9370-t dts binding already exist in stm32f429-disco.dts but, the panel driver didn't get accepted from mainline. it's time to submit patch fot it. This driver can support two different interface by different dts bindings: - spi+dpi, use spi to configure register, dpi for graphic data. st,sf-tc240t-9370-t - only spi, just like tiny/ili9341.c (actually, this part is copy from tiny) adafruit,yx240qv29 I was submited the first patch last year, you can find it at [1]. this patch has one major difference from that one, which is replace the low level communication way, from spi_sync() to mipi_dbi_{command, command_stackbuf}() interface, referred from Linus's patch [2]. both the two dpi/dbi interface was tested on stm32f429-disco board, if anyone want to verify this patch, you need apply the clk patch for this board first, you can get it from [3]. [1] "drm/panel: Add ilitek ili9341 panel driver" https://lore.kernel.org/lkml/1590378348-8115-7-git-send-email-dillon.minfei… [2] "drm/panel: s6e63m0: Switch to DBI abstraction for SPI" https://lore.kernel.org/dri-devel/20210611214243.669892-1-linus.walleij@lin… [3] https://lore.kernel.org/lkml/1590378348-8115-6-git-send-email-dillon.minfei… v4: - fix m68k-allmodconfig build error which reported by lkp, thanks. - add Copyright 2018 David Lechner <david(a)lechnology.com>. v3 link: https://lore.kernel.org/lkml/1627013203-23099-1-git-send-email-dillon.minfe… v3: - add Fixes tags. - collect reviewed-by tags from linus and jagan. - replace DRM_ERROR() with dev_err() or drm_err(). - remove kernel-doc markers from struct ili9341_config{}. - reorder include headers. - remove the struct device *dev from struct ili9341{}. - restructure the ili9341_probe() function, add two ili9341_{dbi,dpi)_probe() to make it more readable according to jagan's suggestion, thanks. for the full drm driver exist in drm/panel need Sam and Laurent's feedback. so, not cover this part at this time, will be update later. v2 link: https://lore.kernel.org/lkml/1626853288-31223-1-git-send-email-dillon.minfe… v2: - replace vcc regulator to bulk regulators in driver, from linus suggestion. - fix dtbs_check warnings on ili9341 dts binding check. - add bulk regulation node in ilitek,ili9341.yaml. v1 link: https://lore.kernel.org/lkml/1626430843-23823-1-git-send-email-dillon.minfe… Dillon Min (3): dt-bindings: display: panel: Add ilitek ili9341 panel bindings ARM: dts: stm32: fix dtbs_check warning on ili9341 dts binding drm/panel: Add ilitek ili9341 panel driver .../bindings/display/panel/ilitek,ili9341.yaml | 78 ++ arch/arm/boot/dts/stm32f429-disco.dts | 2 +- drivers/gpu/drm/panel/Kconfig | 12 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 792 +++++++++++++++++++++ 5 files changed, 884 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9341.c -- 1.9.1

5 12

[PATCH v2 00/13] replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
by Claudio Suarez 25 Nov '21

25 Nov '21

Changelog: v2: - no helper function - A separate patch is made for amdgpu - zte patch is removed because that driver no longer exists [Why] Copy&paste from Documentation/gpu/todo.rst === Replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi --------------------------------------------------------------- Once EDID is parsed, the monitor HDMI support information is available through drm_display_info.is_hdmi. Many drivers still call drm_detect_hdmi_monitor() to retrieve the same information, which is less efficient. Audit each individual driver calling drm_detect_hdmi_monitor() and switch to drm_display_info.is_hdmi if applicable. ===== [How] I did it in two steps: - check that drm_display_info has a correct value. - in that case, replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi Almost all occurrences of drm_detect_hdmi_monitor() could be changed. Some small inconsistencies have been solved. Stats: drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +- drivers/gpu/drm/bridge/sii902x.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- drivers/gpu/drm/drm_edid.c | 11 +++++------ drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++++-- drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 3 ++- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 6 ++++-- drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +- drivers/gpu/drm/i915/display/intel_sdvo.c | 3 ++- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 ++-- drivers/gpu/drm/nouveau/dispnv50/head.c | 8 +------- drivers/gpu/drm/radeon/atombios_encoders.c | 6 +++--- drivers/gpu/drm/radeon/radeon_connectors.c | 15 +++++++++------ drivers/gpu/drm/radeon/radeon_display.c | 2 +- drivers/gpu/drm/radeon/radeon_encoders.c | 4 ++-- drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ++-- drivers/gpu/drm/rockchip/rk3066_hdmi.c | 2 +- drivers/gpu/drm/sti/sti_hdmi.c | 10 ++++++---- drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 4 ++-- drivers/gpu/drm/tegra/hdmi.c | 6 +----- drivers/gpu/drm/vc4/vc4_hdmi.c | 6 +++--- 22 files changed, 55 insertions(+), 55 deletions(-) Best regards. Claudio Suarez

4 29

← Newer
1
...
8
9
10
11
12
13
14
...
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