dri-devel August 2021

dri-devel@lists.freedesktop.org

324 participants
762 discussions

[PATCH v2 0/2] R-Car DU: Add DSI encoder driver for V3U
by Laurent Pinchart 28 Sep '21

28 Sep '21

Hello, This patch series adds a driver for the DSI encoder found in the R-Car V3U SoC, which is the first SoC in the family that supports DSI. The driver is based on an implementation from the BSP written by Luu Hoai, with lots of further rework. If anyone is interested in the history, a broken down v1 is available from [1]. The driver has been successfully tested on the Falcon board, which connects an SN65DSI86 to the output of the DSI encoder. Further patches are needed for the ti-sn65dsi86 driver to enable usage in plain DP (non-eDP) mode, as the Falcon board has a mini-DP connector wired to the output of the SN65DSI86. This is work in progress (see [2]). [1] https://lore.kernel.org/linux-renesas-soc/189c7a07-29cd-39f4-1dec-56aa94c11… [2] https://lore.kernel.org/linux-renesas-soc/20210322030128.2283-1-laurent.pin… LUU HOAI (1): drm: rcar-du: Add R-Car DSI driver Laurent Pinchart (1): dt-bindings: display: bridge: Add binding for R-Car MIPI DSI/CSI-2 TX .../display/bridge/renesas,dsi-csi2-tx.yaml | 118 +++ MAINTAINERS | 1 + drivers/gpu/drm/rcar-du/Kconfig | 6 + drivers/gpu/drm/rcar-du/Makefile | 1 + drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 827 ++++++++++++++++++ drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h | 172 ++++ 6 files changed, 1125 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml create mode 100644 drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_mipi_dsi_regs.h -- Regards, Laurent Pinchart

6 15

[Bug 212425] New: Kernel warning at drivers/gpu/drm/ttm/ttm_bo.c:517
by bugzilla-daemon＠bugzilla.kernel.org 28 Sep '21

28 Sep '21

https://bugzilla.kernel.org/show_bug.cgi?id=212425 Bug ID: 212425 Summary: Kernel warning at drivers/gpu/drm/ttm/ttm_bo.c:517 Product: Drivers Version: 2.5 Kernel Version: 5.11.9 Hardware: x86-64 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: custos.mentis(a)gmail.com Regression: No After installing today's release of kernel 5.11.9 I am getting a bunch of kernel warnings like: [ 70.902471] WARNING: CPU: 6 PID: 2147 at drivers/gpu/drm/ttm/ttm_bo.c:517 ttm_bo_release+0x2b1/0x300 [ 70.902481] Modules linked in: nls_iso8859_2 nls_cp852 vfat fat uinput ipt_REJECT nf_reject_ipv4 iptable_filter ip_tables ip6t_REJECT nf_reject_ipv6 xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6table_filter ip6_tables x_tables kvm_amd kvm pcspkr irqbypass sp5100_tco snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer lm92 lm63 it87 hwmon_vid fam15h_power nfsd k10temp auth_rpcgss fuse oid_registry lockd grace hid_logitech_hidpp hid_logitech_dj hid_generic sr_mod cdrom sd_mod megaraid_sas 8250 8250_base serial_core usbhid sunrpc dm_mod dax [ 70.902541] CPU: 6 PID: 2147 Comm: kmail Tainted: G W 5.11.9-acrux #9 [ 70.902554] Hardware name: To be filled by O.E.M. To be filled by O.E.M./SABERTOOTH 990FX R2.0, BIOS 2901 05/04/2016 [ 70.902556] RIP: 0010:ttm_bo_release+0x2b1/0x300 [ 70.902559] Code: e8 74 2b 2f 00 e9 d9 fd ff ff 48 8b 7d 88 b9 30 75 00 00 31 d2 be 01 00 00 00 e8 3a 52 2f 00 48 8b 45 d8 eb 9d 4c 89 e0 eb 98 <0f> 0b c7 85 9c 00 00 00 00 00 00 00 4c 89 ef e8 4b f2 ff ff 48 8d [ 70.902561] RSP: 0018:ffffaf4a83313bb8 EFLAGS: 00010202 [ 70.902566] RAX: 0000000000000001 RBX: ffff961b7553c500 RCX: 0000000000000008 [ 70.902568] RDX: 0000000000000001 RSI: 0000000000000246 RDI: ffffffffa1db5248 [ 70.902570] RBP: ffff961b7553c570 R08: ffff961ba14f7a38 R09: ffff9621dedaa3f8 [ 70.902571] R10: ffff961ac60c1250 R11: ffff961ac60c1240 R12: ffff961ac5fe5588 [ 70.902572] R13: ffff961b7553c400 R14: 0000000000000000 R15: ffff961ac5fe5f48 [ 70.902573] FS: 00007ff78c2f5f00(0000) GS:ffff9621ded80000(0000) knlGS:0000000000000000 [ 70.902575] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 70.902576] CR2: 00007ff691820000 CR3: 0000000203d5d000 CR4: 00000000000406e0 [ 70.902578] Call Trace: [ 70.902580] ttm_bo_move_accel_cleanup+0x19d/0x398 [ 70.902583] amdgpu_bo_move+0x15c/0x698 [ 70.902586] ? amdgpu_vram_mgr_new+0x373/0x3d8 [ 70.902587] ttm_bo_handle_move_mem+0x8c/0x170 [ 70.902590] ttm_bo_validate+0x147/0x178 [ 70.902592] amdgpu_bo_fault_reserve_notify+0xbf/0x148 [ 70.902594] amdgpu_ttm_fault+0x33/0x80 [ 70.902596] __do_fault+0x33/0x90 [ 70.902599] handle_mm_fault+0xdff/0x1498 [ 70.902601] exc_page_fault+0x1a5/0x500 [ 70.902604] ? exit_to_user_mode_prepare+0x5d/0x118 [ 70.902607] ? asm_exc_page_fault+0x8/0x30 [ 70.902609] asm_exc_page_fault+0x1e/0x30 [ 70.902611] RIP: 0033:0x7ff78d8f290d [ 70.902612] Code: 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 6f 46 bc f3 0f 6f 4e cc 4c 8b 4e dc 4c 8b 56 e4 4c 8b 5e ec 48 8b 4e f4 8b 56 fc <f3> 0f 7f 47 bc f3 0f 7f 4f cc 4c 89 4f dc 4c 89 57 e4 4c 89 5f ec [ 70.902614] RSP: 002b:00007ffdbd5bb838 EFLAGS: 00010207 [ 70.902616] RAX: 00007ff691820000 RBX: 0000000000000044 RCX: 3f80000000000000 [ 70.902617] RDX: 0000000000000000 RSI: 000055d1049acad4 RDI: 00007ff691820044 [ 70.902618] RBP: 000055d1049aca90 R08: 000055d103fd9a30 R09: 0000000000000000 [ 70.902619] R10: 000000003f800000 R11: 3f800000bf800000 R12: 0000000000000000 [ 70.902620] R13: 000055d103f58320 R14: 0000000000000000 R15: 0000000000000044 Apparently the warnings show after commit 7d09e9725b5dcc8d14e101de931e4969d033a6ad, which explains that the warning is triggered by "very likely a driver bug". -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

1 5

[PATCH linux-next] drm/nouveau/mmu/gp100-: drop unneeded assignment in the if condition.
by CGEL 28 Sep '21

28 Sep '21

From: Luo penghao <luo.penghao(a)zte.com.cn> In order to keep the code style consistency of the whole file, the 'inst' assignments should be deleted. The clang_analyzer complains as follows: drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c:499:8: warning: Although the value storedto 'inst' is used in the enclosing expression, the value is never actually read from 'inst'. Reported-by: Zeal Robot <zealci(a)zte.com.cn> Signed-off-by: Luo penghao <luo.penghao(a)zte.com.cn> --- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c index f02abd9..5d7766a 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c @@ -502,7 +502,7 @@ gp100_vmm_fault_cancel(struct nvkm_vmm *vmm, void *argv, u32 argc) args->v0.inst |= 0x80000000; if (!WARN_ON(nvkm_gr_ctxsw_pause(device))) { - if ((inst = nvkm_gr_ctxsw_inst(device)) == args->v0.inst) { + if ((nvkm_gr_ctxsw_inst(device)) == args->v0.inst) { gf100_vmm_invalidate(vmm, 0x0000001b /* CANCEL_TARGETED. */ | (args->v0.hub << 20) | -- 2.15.2

2 1

[PATCH linux-next] drm/nouveau/mmu: drop unneeded assignment in the nvkm_uvmm_mthd_page()
by CGEL 28 Sep '21

28 Sep '21

From: Luo penghao <luo.penghao(a)zte.com.cn> In order to keep the code style consistency of the whole file, the 'ret' assignments should be deleted. The clang_analyzer complains as follows: drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c:317:8:warning: Although the value storedto 'ret' is used in the enclosing expression, the value is never actually read from 'ret'. Reported-by: Zeal Robot <zealci(a)zte.com.cn> Signed-off-by: Luo penghao <luo.penghao(a)zte.com.cn> --- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c index c43b824..d9f8e11 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c @@ -314,7 +314,7 @@ nvkm_uvmm_mthd_page(struct nvkm_uvmm *uvmm, void *argv, u32 argc) page = uvmm->vmm->func->page; for (nr = 0; page[nr].shift; nr++); - if (!(ret = nvif_unpack(ret, &argv, &argc, args->v0, 0, 0, false))) { + if (!(nvif_unpack(ret, &argv, &argc, args->v0, 0, 0, false))) { if ((index = args->v0.index) >= nr) return -EINVAL; type = page[index].type; -- 2.15.2

2 1

[PATCH] drm/nouveau: avoid a use-after-free when BO init fails
by Jeremy Cline 28 Sep '21

28 Sep '21

nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code back to the caller. On failures, ttm_bo_init() invokes the provided destructor which should de-initialize and free the memory. Thus, when nouveau_bo_init() returns an error the gem object has already been released and the memory freed by nouveau_bo_del_ttm(). Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object") Cc: Thierry Reding <treding(a)nvidia.com> Signed-off-by: Jeremy Cline <jcline(a)redhat.com> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index 787d05eefd9c..d30157cc7169 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -211,10 +211,8 @@ nouveau_gem_new(struct nouveau_cli *cli, u64 size, int align, uint32_t domain, } ret = nouveau_bo_init(nvbo, size, align, domain, NULL, NULL); - if (ret) { - nouveau_bo_ref(NULL, &nvbo); + if (ret) return ret; - } /* we restrict allowed domains on nv50+ to only the types * that were requested at creation time. not possibly on -- 2.28.0

3 2

[PATCH 00/11] treewide: address gcc-11 -Wstringop-overread warnings
by Arnd Bergmann 28 Sep '21

28 Sep '21

From: Arnd Bergmann <arnd(a)arndb.de> The coming gcc release introduces a new warning for string operations reading beyond the end of a fixed-length object. After testing randconfig kernels for a while, think I have patches for any such warnings that came up on x86, arm and arm64. Most of these warnings are false-positive ones, either gcc warning about something that is entirely correct, or about something that looks suspicious but turns out to be correct after all. The two patches for the i915 driver look like something that might be actual bugs, but I am not sure about those either. We probably want some combination of workaround like the ones I post here and changes to gcc to have fewer false positives in the release. I'm posting the entire set of workaround that give me a cleanly building kernel for reference here. Arnd Arnd Bergmann (11): x86: compressed: avoid gcc-11 -Wstringop-overread warning x86: tboot: avoid Wstringop-overread-warning security: commoncap: fix -Wstringop-overread warning ath11: Wstringop-overread warning qnx: avoid -Wstringop-overread warning cgroup: fix -Wzero-length-bounds warnings ARM: sharpsl_param: work around -Wstringop-overread warning atmel: avoid gcc -Wstringop-overflow warning scsi: lpfc: fix gcc -Wstringop-overread warning drm/i915: avoid stringop-overread warning on pri_latency [RFC] drm/i915/dp: fix array overflow warning arch/arm/common/sharpsl_param.c | 4 ++- arch/x86/boot/compressed/misc.c | 2 -- arch/x86/kernel/tboot.c | 44 +++++++++++++++---------- drivers/gpu/drm/i915/display/intel_dp.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 6 ++-- drivers/net/wireless/ath/ath11k/mac.c | 2 +- drivers/net/wireless/atmel/atmel.c | 25 ++++++++------ drivers/scsi/lpfc/lpfc_attr.c | 6 ++-- fs/qnx4/dir.c | 11 +++---- kernel/cgroup/cgroup.c | 15 +++++++-- security/commoncap.c | 2 +- 11 files changed, 69 insertions(+), 50 deletions(-) Cc: x86(a)kernel.org Cc: Ning Sun <ning.sun(a)intel.com> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Kalle Valo <kvalo(a)codeaurora.org> Cc: Simon Kelley <simon(a)thekelleys.org.uk> Cc: James Smart <james.smart(a)broadcom.com> Cc: "James E.J. Bottomley" <jejb(a)linux.ibm.com> Cc: Anders Larsen <al(a)alarsen.net> Cc: Tejun Heo <tj(a)kernel.org> Cc: Serge Hallyn <serge(a)hallyn.com> Cc: Imre Deak <imre.deak(a)intel.com> Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-kernel(a)vger.kernel.org Cc: tboot-devel(a)lists.sourceforge.net Cc: intel-gfx(a)lists.freedesktop.org Cc: dri-devel(a)lists.freedesktop.org Cc: ath11k(a)lists.infradead.org Cc: linux-wireless(a)vger.kernel.org Cc: netdev(a)vger.kernel.org Cc: linux-scsi(a)vger.kernel.org Cc: cgroups(a)vger.kernel.org Cc: linux-security-module(a)vger.kernel.org -- 2.29.2

12 31

[PATCH 0/8] drm + usb-type-c: Add support for out-of-band hotplug notification (v4 resend)
by Hans de Goede 24 Sep '21

24 Sep '21

Hi all, Here is a rebased-resend of v4 of my patchset making DP over Type-C work on devices where the Type-C controller does not drive the HPD pin on the GPU, but instead we need to forward HPD events from the Type-C controller to the DRM driver. Changes in v4 resend: - Rebase on top of latest drm-tip Changes in v4: - Rebase on top of latest drm-tip - Add forward declaration for struct fwnode_handle to drm_crtc_internal.h (fixes warning reported by kernel test robot <lkp(a)intel.com>) - Add Heikki's Reviewed-by to patch 7 & 8 - Add Heikki's Tested-by to the series Changes in v3: - Base on top of latest drm-tip, which should fix the CI being unable to apply (and thus to test) the patches - Make intel_acpi_assign_connector_fwnodes() take a ref on the fwnode it stores in connector->fwnode and have drm_connector_cleanup() put this reference - Drop data argument from drm_connector_oob_hotplug_event() - Make the Type-C DP altmode code only call drm_connector_oob_hotplug_event() when the HPD bit in the status vdo changes - Drop the platform/x86/intel_cht_int33fe: Correct "displayport" fwnode reference patch, this will be merged independently through the pdx86 tree Changes in v2: - Replace the bogus "drm/connector: Make the drm_sysfs connector->kdev device hold a reference to the connector" patch with: "drm/connector: Give connector sysfs devices there own device_type" the new patch is a dep for patch 2/9 see the patches - Stop using a class-dev-iter, instead at a global connector list to drm_connector.c and use that to find the connector by the fwnode, similar to how we already do this in drm_panel.c and drm_bridge.c - Make drm_connector_oob_hotplug_event() take a fwnode pointer as argument, rather then a drm_connector pointer and let it do the lookup itself. This allows making drm_connector_find_by_fwnode() a drm-internal function and avoids code outside the drm subsystem potentially holding on the a drm_connector reference for a longer period. This series not only touches drm subsys files but it also touches drivers/usb/typec/altmodes/typec_displayport.c, that file usually does not see a whole lot of changes. So I believe it would be best to just merge the entire series through drm-misc, Assuming we can get an ack from Greg for merging the typec_displayport.c changes this way. Regards, Hans Hans de Goede (7): drm/connector: Give connector sysfs devices there own device_type drm/connector: Add a fwnode pointer to drm_connector and register with ACPI (v2) drm/connector: Add drm_connector_find_by_fwnode() function (v3) drm/connector: Add support for out-of-band hotplug notification (v3) drm/i915/dp: Add support for out-of-bound hotplug events usb: typec: altmodes/displayport: Make dp_altmode_notify() more generic usb: typec: altmodes/displayport: Notify drm subsys of hotplug events Heikki Krogerus (1): drm/i915: Associate ACPI connector nodes with connector entries (v2) drivers/gpu/drm/drm_connector.c | 79 ++++++++++++++++++ drivers/gpu/drm/drm_crtc_internal.h | 2 + drivers/gpu/drm/drm_sysfs.c | 87 +++++++++++++++++--- drivers/gpu/drm/i915/display/intel_acpi.c | 46 +++++++++++ drivers/gpu/drm/i915/display/intel_acpi.h | 3 + drivers/gpu/drm/i915/display/intel_display.c | 1 + drivers/gpu/drm/i915/display/intel_dp.c | 12 +++ drivers/usb/typec/altmodes/Kconfig | 1 + drivers/usb/typec/altmodes/displayport.c | 58 ++++++++----- include/drm/drm_connector.h | 25 ++++++ 10 files changed, 279 insertions(+), 35 deletions(-) -- 2.31.1

3 13

drm: simpledrm: fbdev emulation error with CONFIG_DRM_SIMPLEDRM enabled
by Amanoel Dawod 24 Sep '21

24 Sep '21

Hi, This started since 5.14-rc1. The following error appears in dmesg (as of 5.14-rc7) when I build the kernel with CONFIG_DRM_SIMPLEDRM=m [ 3.252275] [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0 [ 3.252298] simple-framebuffer simple-framebuffer.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-22) thanks, Amanoel

3 11

[Bug 85421] New: radeon stalled, GPU lockup, reset and failed on resume; crashed by firefox.
by bugzilla-daemon＠bugzilla.kernel.org 24 Sep '21

24 Sep '21

https://bugzilla.kernel.org/show_bug.cgi?id=85421 Bug ID: 85421 Summary: radeon stalled, GPU lockup, reset and failed on resume; crashed by firefox. Product: Drivers Version: 2.5 Kernel Version: 3.16.3 Hardware: x86-64 OS: Linux Tree: Fedora Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: htl10(a)users.sourceforge.net Regression: No Created attachment 152191 --> https://bugzilla.kernel.org/attachment.cgi?id=152191&action=edit /var/log/messages from radeon 0000:00:01.0: ring 0 stalled to reboot. I was away from the computer when the radeon dri driver crashed; I left a fair number of firefox windows on/tab, some of them may have videos (from BBC news web site) and animated gifs from another web site on; but it crashed about 5-10 minutes after I was away and I was aware of it because the laptop blipped. # lspci | grep VGA 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon R3 Graphics] some excerpt from the attached logs are: ... [ 8770.250116] radeon 0000:00:01.0: ring 0 stalled for more than 10012msec [ 8770.250128] radeon 0000:00:01.0: GPU lockup (waiting for 0x0000000000056034 last fence id 0x0000000000056031 on ring 0) [ 8770.298635] radeon 0000:00:01.0: Saved 14196 dwords of commands on ring 0. [ 8770.298663] radeon 0000:00:01.0: GPU softreset: 0x0000000C ... [ 8770.313299] radeon 0000:00:01.0: GPU reset succeeded, trying to resume ... [ 8770.339724] [drm] ring test on 0 succeeded in 3 usecs [ 8770.518568] [drm:cik_ring_test] *ERROR* radeon: ring 1 test failed (scratch(0x3010C)=0xCAFEDEAD) [ 8770.752885] [drm:cik_sdma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD) [ 8770.752892] [drm:cik_resume] *ERROR* cik startup failed on resume [ 8780.753181] radeon 0000:00:01.0: ring 0 stalled for more than 10001msec [ 8780.753193] radeon 0000:00:01.0: GPU lockup (waiting for 0x00000000000560f7 last fence id 0x0000000000056031 on ring 0) [ 8780.753199] [drm:cik_ib_test] *ERROR* radeon: fence wait failed (-35). [ 8780.753209] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-35). [ 8780.753215] radeon 0000:00:01.0: ib ring test failed (-35). [ 8780.762131] radeon 0000:00:01.0: GPU softreset: 0x0000000C ... The kernel is a largely fedora 3.16.3-200 one grabbed from the koji srpm but with the additional patch from https://bugzilla.kernel.org/show_bug.cgi?id=71051#c8 drv ati 7.4.0 , mesa 10.2.8, glamor from git 347ef4 . -- You are receiving this mail because: You are watching the assignee of the bug.

1 41

[PATCH v3 0/6] drm/vc4: hdmi: Fix CEC access while disabled
by Maxime Ripard 23 Sep '21

23 Sep '21

Hi, This series aims at fixing a complete and silent hang when one tries to use CEC while the display output is off. This can be tested with: echo off > /sys/class/drm/card0-HDMI-A-1/status cec-ctl --tuner -p 1.0.0.0 cec-compliance This series addresses it by making sure the HDMI controller is powered up as soon as the CEC device is opened by the userspace. Let me know what you think, Maxime Changes from v2: - Rebased on top of drm-misc-fixes - Fixed a build error Changes from v1: - More fixes - Added a big warning if we try to access a register while the device is disabled. - Fixed the pre_crtc_configure error path Maxime Ripard (6): drm/vc4: select PM drm/vc4: hdmi: Make sure the controller is powered up during bind drm/vc4: hdmi: Rework the pre_crtc_configure error handling drm/vc4: hdmi: Split the CEC disable / enable functions in two drm/vc4: hdmi: Make sure the device is powered with CEC drm/vc4: hdmi: Warn if we access the controller while disabled drivers/gpu/drm/vc4/Kconfig | 1 + drivers/gpu/drm/vc4/vc4_hdmi.c | 125 ++++++++++++++++++---------- drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 6 ++ 3 files changed, 90 insertions(+), 42 deletions(-) -- 2.31.1

4 14

← Newer
1
...
10
11
12
13
14
15
16
...
77
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2021