dri-devel December 2021

dri-devel@lists.freedesktop.org

310 participants
720 discussions

[PATCH v2, 00/12] media: mtk-vcodec: support for MT8192 decoder
by Yunfei Dong 29 Dec '21

29 Dec '21

This series adds support for mt8192 h264 decoder. Firstly, need to refactor power/clock/interrupt interfaces for mt8192 is lat and core architecture. Secondly, add new functions to get frame buffer size and resolution according to decoder capability from scp side. Then add callback function to get/put capture buffer in order to enable lat and core decoder in parallel. Then add to support MT21C compressed mode and fix v4l2-compliance fail. Lastly, extract H264 request api driver to let mt8183 and mt8192 use the same code, and adds mt8192 frame based h264 driver for stateless decoder. Patches 1 refactor power/clock/interrupt interface. Patches 2~4 get frame buffer size and resolution according to decoder capability. Patches 5~6 enable lat and core decode in parallel. Patch 7~10 Add to support MT21C compressed mode and fix v4l2-compliance fail. Patch 11~12 extract h264 driver and add mt8192 frame based driver for h264 decoder. ---- Dependents on "Support multi hardware decode using of_platform_populate"[1]. This patches are the second part used to add mt8192 h264 decoder. And the base part is [1]. [1]https://patchwork.linuxtv.org/project/linux-media/cover/20211215061552.85… --- changes compared with v1: - rewrite commit message for patch 12. - rewrite cover-letter message. --- Yunfei Dong (12): media: mtk-vcodec: Add vdec enable/disable hardware helpers media: mtk-vcodec: Using firmware type to separate different firmware architecture media: mtk-vcodec: get capture queue buffer size from scp media: mtk-vcodec: Read max resolution from dec_capability media: mtk-vcodec: Call v4l2_m2m_set_dst_buffered() set capture buffer buffered media: mtk-vcodec: Refactor get and put capture buffer flow media: mtk-vcodec: Refactor supported vdec formats and framesizes media: mtk-vcodec: Add format to support MT21C media: mtk-vcodec: disable vp8 4K capability media: mtk-vcodec: Fix v4l2-compliance fail media: mtk-vcodec: Extract H264 common code media: mtk-vcodec: Add h264 decoder driver for mt8192 drivers/media/platform/mtk-vcodec/Makefile | 2 + .../platform/mtk-vcodec/mtk_vcodec_dec.c | 49 +- .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 5 - .../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 168 +++-- .../platform/mtk-vcodec/mtk_vcodec_dec_pm.h | 6 +- .../mtk-vcodec/mtk_vcodec_dec_stateful.c | 14 +- .../mtk-vcodec/mtk_vcodec_dec_stateless.c | 246 +++++-- .../platform/mtk-vcodec/mtk_vcodec_drv.h | 27 +- .../media/platform/mtk-vcodec/mtk_vcodec_fw.c | 6 + .../media/platform/mtk-vcodec/mtk_vcodec_fw.h | 1 + .../mtk-vcodec/vdec/vdec_h264_req_common.c | 303 +++++++++ .../mtk-vcodec/vdec/vdec_h264_req_common.h | 247 +++++++ .../mtk-vcodec/vdec/vdec_h264_req_if.c | 402 +----------- .../mtk-vcodec/vdec/vdec_h264_req_lat_if.c | 620 ++++++++++++++++++ .../media/platform/mtk-vcodec/vdec_drv_if.c | 28 +- .../media/platform/mtk-vcodec/vdec_drv_if.h | 1 + .../media/platform/mtk-vcodec/vdec_ipi_msg.h | 36 + .../platform/mtk-vcodec/vdec_msg_queue.c | 2 + .../media/platform/mtk-vcodec/vdec_vpu_if.c | 55 +- .../media/platform/mtk-vcodec/vdec_vpu_if.h | 15 + include/linux/remoteproc/mtk_scp.h | 2 + 21 files changed, 1680 insertions(+), 555 deletions(-) create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_common.c create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_common.h create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_lat_if.c -- 2.25.1

3 19

[PATCH] drm/bridge: sn65dsi83: Fix an error handling path in sn65dsi83_probe()
by Christophe JAILLET 29 Dec '21

29 Dec '21

sn65dsi83_parse_dt() takes a reference on 'ctx->host_node' that must be released in the error handling path of the probe. This is only done in the remove function up to now. Fixes: ceb515ba29ba ("drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver") Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> --- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c index 945f08de45f1..6edea9f8f8c4 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c @@ -673,8 +673,10 @@ static int sn65dsi83_probe(struct i2c_client *client, return ret; ctx->regmap = devm_regmap_init_i2c(client, &sn65dsi83_regmap_config); - if (IS_ERR(ctx->regmap)) - return PTR_ERR(ctx->regmap); + if (IS_ERR(ctx->regmap)) { + ret = PTR_ERR(ctx->regmap); + goto err_put_node; + } dev_set_drvdata(dev, ctx); i2c_set_clientdata(client, ctx); @@ -691,6 +693,8 @@ static int sn65dsi83_probe(struct i2c_client *client, err_remove_bridge: drm_bridge_remove(&ctx->bridge); +err_put_node: + of_node_put(ctx->host_node); return ret; } -- 2.32.0

2 1

[PATCH v2] drm/mediatek: Fix unused-but-set variable warning
by Miles Chen 29 Dec '21

29 Dec '21

Fix unused-but-set variable warning: drivers/gpu/drm/mediatek/mtk_cec.c:85:6: warning: variable 'tmp' set but not used [-Wunused-but-set-variable] Cc: CK Hu <ck.hu(a)mediatek.com> Cc: Matthias Brugger <matthias.bgg(a)gmail.com> Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support") Signed-off-by: Miles Chen <miles.chen(a)mediatek.com> --- Change since v1: add Fixes tag --- drivers/gpu/drm/mediatek/mtk_cec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c b/drivers/gpu/drm/mediatek/mtk_cec.c index e9cef5c0c8f7..cdfa648910b2 100644 --- a/drivers/gpu/drm/mediatek/mtk_cec.c +++ b/drivers/gpu/drm/mediatek/mtk_cec.c @@ -85,7 +85,7 @@ static void mtk_cec_mask(struct mtk_cec *cec, unsigned int offset, u32 tmp = readl(cec->regs + offset) & ~mask; tmp |= val & mask; - writel(val, cec->regs + offset); + writel(tmp, cec->regs + offset); } void mtk_cec_set_hpd_event(struct device *dev, -- 2.18.0

1 0

question about an intel-gfx issue (4447)
by Randy Dunlap 29 Dec '21

29 Dec '21

Hi, For https://gitlab.freedesktop.org/drm/intel/-/issues/4447, are people aware of it or do I need to make people aware of it somehow? Do I need to provide more information? If so, what? thanks. -- ~Randy

1 0

[PATCH] drm/msm/dp: add support of tps4 (training pattern 4) for HBR3
by Kuogee Hsieh 28 Dec '21

28 Dec '21

From: Kuogee Hsieh <khsieh(a)codeaurora.org> Some DP sinkers prefer to use tps4 instead of tps3 during training #2. This patch will use tps4 to perform link training #2 if sinker's DPCD supports it. Signed-off-by: Kuogee Hsieh <quic_khsieh(a)quicinc.com> --- drivers/gpu/drm/msm/dp/dp_ctrl.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c index 39558a2..c7b0657 100644 --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c @@ -1181,7 +1181,7 @@ static int dp_ctrl_link_train_2(struct dp_ctrl_private *ctrl, int *training_step) { int tries = 0, ret = 0; - char pattern; + char pattern, state_ctrl_bit; int const maximum_retries = 5; u8 link_status[DP_LINK_STATUS_SIZE]; @@ -1189,12 +1189,20 @@ static int dp_ctrl_link_train_2(struct dp_ctrl_private *ctrl, *training_step = DP_TRAINING_2; - if (drm_dp_tps3_supported(ctrl->panel->dpcd)) + if (drm_dp_tps4_supported(ctrl->panel->dpcd)) { + pattern = DP_TRAINING_PATTERN_4; + state_ctrl_bit = 4; + } + else if (drm_dp_tps3_supported(ctrl->panel->dpcd)) { pattern = DP_TRAINING_PATTERN_3; - else + state_ctrl_bit = 3; + } + else { pattern = DP_TRAINING_PATTERN_2; + state_ctrl_bit = 2; + } - ret = dp_catalog_ctrl_set_pattern(ctrl->catalog, pattern); + ret = dp_catalog_ctrl_set_pattern(ctrl->catalog, state_ctrl_bit); if (ret) return ret; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

2 1

[PATCH] drm/msm/dp: populate connector of struct dp_panel
by Kuogee Hsieh 28 Dec '21

28 Dec '21

There is kernel crashed happen due to unable to handle kernel NULL pointer dereference of dp_panel->connector while running DP link layer compliance test case 4.2.2.6 (EDIDCorruption Detection). This patch will fixed the problem by populating connector of dp_panel. Fixes: 7948fe12d47 ("drm/msm/dp: return correct edid checksum after corrupted edid checksum read") Signed-off-by: Kuogee Hsieh <quic_khsieh(a)quicinc.com> --- drivers/gpu/drm/msm/dp/dp_panel.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c b/drivers/gpu/drm/msm/dp/dp_panel.c index 71db10c..6a938a2 100644 --- a/drivers/gpu/drm/msm/dp/dp_panel.c +++ b/drivers/gpu/drm/msm/dp/dp_panel.c @@ -197,6 +197,8 @@ int dp_panel_read_sink_caps(struct dp_panel *dp_panel, kfree(dp_panel->edid); dp_panel->edid = NULL; + dp_panel->connector = connector; + dp_panel->edid = drm_get_edid(connector, &panel->aux->ddc); if (!dp_panel->edid) { -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

2 1

[Bug 214963] New: [amdgpu] resuming from suspend fails when IOMMU is missing
by bugzilla-daemon＠bugzilla.kernel.org 28 Dec '21

28 Dec '21

https://bugzilla.kernel.org/show_bug.cgi?id=214963 Bug ID: 214963 Summary: [amdgpu] resuming from suspend fails when IOMMU is missing Product: Drivers Version: 2.5 Kernel Version: 5.15.0, 5.15.1 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: spasswolf(a)web.de Regression: No On the HP bw064-ng Laptop the BIOS does not correctly initialize the IOMMU. This brakes resuming from suspend: Nov 7 23:23:02 bart kernel: [ 96.378265] kfd kfd: amdgpu: Failed to resume IOMMU for device 1002:9874 Nov 7 23:23:02 bart kernel: [ 96.378271] amdgpu 0000:00:01.0: amdgpu: amdgpu_device_ip_resume failed (-6). Nov 7 23:23:02 bart kernel: [ 96.378274] PM: dpm_run_callback(): pci_pm_resume+0x0/0x110 returns -6 Nov 7 23:23:02 bart kernel: [ 96.378283] amdgpu 0000:00:01.0: PM: failed to resume async: error -6 leading to the follow up errors: Nov 7 23:23:03 bart kernel: [ 97.580799] [drm] perform_link_training_with_retries: Link training attempt 1 of 4 failed ... Nov 7 23:23:04 bart kernel: [ 98.646241] [drm] perform_link_training_with_retries: Link training attempt 2 of 4 failed ... Nov 7 23:23:05 bart kernel: [ 99.709472] [drm] perform_link_training_with_retries: Link training attempt 3 of 4 failed Nov 7 23:23:06 bart kernel: [ 100.772840] [drm] enabling link 0 failed: 15 Nov 7 23:23:22 bart kernel: [ 106.160854] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out! Nov 7 23:23:22 bart kernel: [ 116.397484] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [CRTC:47:crtc-0] flip_done timed out Simply changing the amdgpu_device_ip function in drivers/gpu/drm/amd/amdgpu/amdgpu_device.c to static int amdgpu_device_ip_resume(struct amdgpu_device *adev) { int r; #if 0 r = amdgpu_amdkfd_resume_iommu(adev); if (r) return r; #endif r = amdgpu_device_ip_resume_phase1(adev); if (r) return r; r = amdgpu_device_fw_loading(adev); if (r) return r; r = amdgpu_device_ip_resume_phase2(adev); return r; } makes resuming from suspend work for me again. But of course this is not a viable solution as on systems with working IOMMU this is needed. One could probably add a flag so that in case of missing IOMMU amdgpu_amdkfd_resume_iommu returns 0. -- 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 2

[Bug 212019] New: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:67:crtc-0] flip_done timed out
by bugzilla-daemon＠bugzilla.kernel.org 28 Dec '21

28 Dec '21

https://bugzilla.kernel.org/show_bug.cgi?id=212019 Bug ID: 212019 Summary: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:67:crtc-0] flip_done timed out Product: Drivers Version: 2.5 Kernel Version: 5.11.0 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: clemens(a)endorphin.org Regression: No Created attachment 295569 --> https://bugzilla.kernel.org/attachment.cgi?id=295569&action=edit Hardware I get the following display freeze on my T495 AMD Thinkpad: Mar 02 09:24:50 duncan kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:67:crtc-0] flip_done timed out Mar 02 09:25:02 duncan kernel: [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:67:crtc-0] flip_done timed out Mar 02 09:36:25 duncan kernel: [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:55:plane-3] flip_done timed out followed by this stack trace: Mar 02 09:36:25 duncan kernel: WARNING: CPU: 7 PID: 1636 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7754 amdgpu_dm_atomic_commit_tail+0x238b/0x2420 [amdgpu] Mar 02 09:36:25 duncan kernel: Modules linked in: fuse ctr ccm wireguard curve25519_x86_64 libchacha20poly1305 chacha_x86_64 poly1305_x86_64 libblake2s blake2s_x86_64 ip6_udp_tunnel udp_tunnel libcurve25519_generic libchacha libblake2s_generic af_packet msr ip6table_nat iptable_nat nf_nat joydev mousedev xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip6t_rpfilter ipt_rpfilter amdgpu ip6table_raw iptable_raw xt_pkttype intel_rapl_msr nf_log_ipv6 nf_log_ipv4 nf_log_common xt_LOG xt_tcpudp wmi_bmof iwlmvm snd_hda_codec_realtek iommu_v2 mac80211 snd_hda_codec_generic gpu_sched drm_ttm_helper snd_hda_codec_hdmi ttm btusb snd_hda_intel edac_mce_amd uvcvideo btrtl btbcm libarc4 btintel edac_core videobuf2_vmalloc drm_kms_helper nls_iso8859_1 intel_rapl_common deflate videobuf2_memops evdev crc32_pclmul nls_cp437 snd_intel_dspcfg mac_hid videobuf2_v4l2 iwlwifi bluetooth ip6table_filter vfat videobuf2_common snd_hda_codec ghash_clmulni_intel fat snd_hda_core ip6_tables thinkpad_acpi videodev Mar 02 09:36:25 duncan kernel: r8169 drm snd_hwdep efi_pstore nvram rapl psmouse realtek mdio_devres ledtrig_audio mc serio_raw snd_pcm pstore cfg80211 agpgart i2c_algo_bit fb_sys_fops ecdh_generic syscopyarea snd_timer sysfillrect ecc sch_fq_codel iptable_filter sysimgblt ipmi_devintf k10temp sp5100_tco watchdog snd_rn_pci_acp3x i2c_piix4 ucsi_acpi snd_pci_acp3x libphy ipmi_msghandler rfkill snd 8250_pci typec_ucsi soundcore ac typec battery wmi video i2c_scmi backlight i2c_core pinctrl_amd tiny_power_button acpi_cpufreq button loop tun tap macvlan bridge stp llc kvm_amd kvm irqbypass efivarfs ip_tables x_tables autofs4 ext4 crc32c_generic crc16 mbcache jbd2 dm_crypt cbc sha256_ssse3 sha256_generic encrypted_keys trusted tpm rng_core rtsx_pci_sdmmc input_leds led_class mmc_core atkbd libps2 xhci_pci xhci_pci_renesas xhci_hcd crc32c_intel ehci_pci aesni_intel ehci_hcd libaes crypto_simd cryptd usbcore glue_helper nvme nvme_core rtsx_pci t10_pi usb_common crc_t10dif crct10dif_generic crct10dif_pclmul Mar 02 09:36:25 duncan kernel: crct10dif_common i8042 rtc_cmos serio dm_mod Mar 02 09:36:25 duncan kernel: CPU: 7 PID: 1636 Comm: X Not tainted 5.11.0 #1-NixOS Mar 02 09:36:25 duncan kernel: Hardware name: LENOVO 20NJCTO1WW/20NJCTO1WW, BIOS R12ET55W(1.25 ) 07/06/2020 Mar 02 09:36:25 duncan kernel: RIP: 0010:amdgpu_dm_atomic_commit_tail+0x238b/0x2420 [amdgpu] Mar 02 09:36:25 duncan kernel: Code: a8 fd ff ff 01 c7 85 a4 fd ff ff 37 00 00 00 c7 85 ac fd ff ff 20 00 00 00 e8 61 83 12 00 e9 e0 fa ff ff 0f 0b e9 30 f9 ff ff <0f> 0b e9 7f f9 ff ff 0f 0b 0f 0b e9 95 f9 ff ff 49 8b 06 41 0f b6 Mar 02 09:36:25 duncan kernel: RSP: 0018:ffffbd1043ae3928 EFLAGS: 00010002 Mar 02 09:36:25 duncan kernel: RAX: 0000000000000002 RBX: 000000000004bffc RCX: ffff976a603c9118 Mar 02 09:36:25 duncan kernel: RDX: 0000000000000001 RSI: 0000000000000297 RDI: ffff976a62660188 Mar 02 09:36:25 duncan kernel: RBP: ffffbd1043ae3c20 R08: 0000000000000005 R09: 0000000000000000 Mar 02 09:36:25 duncan kernel: R10: ffffbd1043ae3888 R11: ffffbd1043ae388c R12: 0000000000000297 Mar 02 09:36:25 duncan kernel: R13: ffff976e3132aa00 R14: ffff976a5dee9780 R15: ffff976a603c9000 Mar 02 09:36:25 duncan kernel: FS: 00007f993d92c980(0000) GS:ffff9772d8bc0000(0000) knlGS:0000000000000000 Mar 02 09:36:25 duncan kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mar 02 09:36:25 duncan kernel: CR2: 00007f30c85b5ff8 CR3: 000000013e056000 CR4: 00000000003506e0 Mar 02 09:36:25 duncan kernel: Call Trace: Mar 02 09:36:25 duncan kernel: commit_tail+0x94/0x130 [drm_kms_helper] Mar 02 09:36:25 duncan kernel: drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] Mar 02 09:36:25 duncan kernel: drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper] Mar 02 09:36:25 duncan kernel: drm_mode_setcrtc+0x1d3/0x6f0 [drm] Mar 02 09:36:25 duncan kernel: ? amdgpu_cs_wait_ioctl+0xd2/0x160 [amdgpu] Mar 02 09:36:25 duncan kernel: ? drm_mode_getcrtc+0x180/0x180 [drm] Mar 02 09:36:25 duncan kernel: drm_ioctl_kernel+0xaa/0xf0 [drm] Mar 02 09:36:25 duncan kernel: drm_ioctl+0x1ec/0x390 [drm] Mar 02 09:36:25 duncan kernel: ? drm_mode_getcrtc+0x180/0x180 [drm] Mar 02 09:36:25 duncan kernel: amdgpu_drm_ioctl+0x49/0x80 [amdgpu] Mar 02 09:36:25 duncan kernel: __x64_sys_ioctl+0x83/0xb0 Mar 02 09:36:25 duncan kernel: do_syscall_64+0x33/0x40 Mar 02 09:36:25 duncan kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Mar 02 09:36:25 duncan kernel: RIP: 0033:0x7f993dd37b07 Mar 02 09:36:25 duncan kernel: Code: c0 75 b5 48 8d 3c 2b e8 17 ff ff ff 85 c0 78 b6 48 89 d8 5b 5d 41 5c c3 66 2e 0f 1f 84 00 00 00 00 00 90 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 73 0c 00 f7 d8 64 89 01 48 Mar 02 09:36:25 duncan kernel: RSP: 002b:00007ffdd63e1ed8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 Mar 02 09:36:25 duncan kernel: RAX: ffffffffffffffda RBX: 00007ffdd63e1f10 RCX: 00007f993dd37b07 Mar 02 09:36:25 duncan kernel: RDX: 00007ffdd63e1f10 RSI: 00000000c06864a2 RDI: 000000000000000f Mar 02 09:36:25 duncan kernel: RBP: 00000000c06864a2 R08: 0000000000000000 R09: 0000000002fad090 Mar 02 09:36:25 duncan kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 Mar 02 09:36:25 duncan kernel: R13: 000000000000000f R14: 00000000021b4290 R15: 0000000000000000 Mar 02 09:36:25 duncan kernel: ---[ end trace 3bd64ee8f9aa76ff ]--- lshw and full kernel log attached. The first kernel that I saw this problem with was the 5.9. series. -- 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 3

Renesas rcar-du and DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE
by Charles Stevens 27 Dec '21

27 Dec '21

Hi All, I am working on a platform based on the Renesas RZ/G2 SoC family. This chip uses the rcar-du driver for the display. I would like to submit a patch to address the fact that the driver does not check/honor the flag DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE. My issue is that I would like to make as small a change to the driver as possible, but the panel bus_flags don't seem to even make it to the crtc driver. The crtc driver seems to use adjusted_mode to set the HSYNC and VSYNC polarity and as I said ignores the pixel clock polarity leaving it at the default of driving on the falling edge. In my investigations so far I have not figured out how to chase the pointers from the CRTC to the bridge to the panel in order to be able to look at bus_flags. My current approach also modifies the encoder initialization to cache the needed panel and then find the attached encoder during CRTC initialization to find the bus flags. This seems like a lot of work and not something that would be accepted as a patch. The OMAP DSS seems to have problems accessing this flag as well. The TI driver goes so far as to document the current approach as a HACK and suggest a fairly large change to the driver to address the problem. Am I missing something? Is there an easy way to get from a drm_crtc to a drm_panel that is in the same pipeline? Any pointers would be greatly appreciated! Thanks! -charles

1 0

[PATCH 1/2] fbdev: fbmem: add a helper to determine if an aperture is used by a fw fb
by Alex Deucher 27 Dec '21

27 Dec '21

Add a function for drivers to check if the a firmware initialized fb is corresponds to their aperture. This allows drivers to check if the device corresponds to what the firmware set up as the display device. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=215203 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1840 Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> --- drivers/video/fbdev/core/fbmem.c | 47 ++++++++++++++++++++++++++++++++ include/linux/fb.h | 1 + 2 files changed, 48 insertions(+) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index 826175ad88a2..0fa7ede94fa6 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -1762,6 +1762,53 @@ int remove_conflicting_framebuffers(struct apertures_struct *a, } EXPORT_SYMBOL(remove_conflicting_framebuffers); +/** + * is_firmware_framebuffer - detect if firmware-configured framebuffer matches + * @a: memory range, users of which are to be checked + * + * This function checks framebuffer devices (initialized by firmware/bootloader) + * which use memory range described by @a. If @a matchesm the function returns + * true, otherwise false. + */ +bool is_firmware_framebuffer(struct apertures_struct *a) +{ + bool do_free = false; + bool found = false; + int i; + + if (!a) { + a = alloc_apertures(1); + if (!a) + return false; + + a->ranges[0].base = 0; + a->ranges[0].size = ~0; + do_free = true; + } + + mutex_lock(&registration_lock); + /* check all firmware fbs and kick off if the base addr overlaps */ + for_each_registered_fb(i) { + struct apertures_struct *gen_aper; + + if (!(registered_fb[i]->flags & FBINFO_MISC_FIRMWARE)) + continue; + + gen_aper = registered_fb[i]->apertures; + if (fb_do_apertures_overlap(gen_aper, a)) { + found = true; + break; + } + } + mutex_unlock(&registration_lock); + + if (do_free) + kfree(a); + + return found; +} +EXPORT_SYMBOL(is_firmware_framebuffer); + /** * remove_conflicting_pci_framebuffers - remove firmware-configured framebuffers for PCI devices * @pdev: PCI device diff --git a/include/linux/fb.h b/include/linux/fb.h index 6f3db99ab990..3da95842b207 100644 --- a/include/linux/fb.h +++ b/include/linux/fb.h @@ -610,6 +610,7 @@ extern int remove_conflicting_pci_framebuffers(struct pci_dev *pdev, const char *name); extern int remove_conflicting_framebuffers(struct apertures_struct *a, const char *name, bool primary); +extern bool is_firmware_framebuffer(struct apertures_struct *a); extern int fb_prepare_logo(struct fb_info *fb_info, int rotate); extern int fb_show_logo(struct fb_info *fb_info, int rotate); extern char* fb_get_buffer_offset(struct fb_info *info, struct fb_pixmap *buf, u32 size); -- 2.33.1

1 1

← Newer
1
...
21
22
23
24
25
26
27
...
72
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel December 2021