dri-devel May 2022

dri-devel@lists.freedesktop.org

344 participants
736 discussions

[PATCH v3] drm/msm/dp: Always clear mask bits to disable interrupts at dp_ctrl_reset_irq_ctrl()
by Kuogee Hsieh 11 May '22

11 May '22

dp_catalog_ctrl_reset() will software reset DP controller. But it will not reset programmable registers to default value. DP driver still have to clear mask bits to interrupt status registers to disable interrupts after software reset of controller. This patch removes the enable flag condition checking to always clear mask bits of interrupt status registers to disable interrupts if enable flag is false. This patch also will fix the potential problem happen at system suspend where dp_ctrl_reset_irq_ctrl() was called to try to disable HPD related irqs but the irq is still unmasked unexpectedly and can come in while system are suspending. This leads to bus hangs if the irq is handled after we power down the DP hardware because we run the irq handler and access a device register assuming that no irq could ever come in if we powered down the device. We don't know when the irq will be handled though, so it's possible the irq is pending from before we disable the irq in the hardware. Changes in v2: -- add more details commit text Changes in v3: -- add synchrons_irq() -- add atomic_t suspended Fixes: ba0a422be723 ("drm/msm/dp: do not initialize phy until plugin interrupt received") Signed-off-by: Kuogee Hsieh <quic_khsieh(a)quicinc.com> --- drivers/gpu/drm/msm/dp/dp_ctrl.c | 9 +++++++-- drivers/gpu/drm/msm/dp/dp_display.c | 18 ++++++++++++++++++ 2 files changed, 25 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c index af7a80c..f3e333e 100644 --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c @@ -1389,8 +1389,13 @@ void dp_ctrl_reset_irq_ctrl(struct dp_ctrl *dp_ctrl, bool enable) dp_catalog_ctrl_reset(ctrl->catalog); - if (enable) - dp_catalog_ctrl_enable_irq(ctrl->catalog, enable); + /* + * all dp controller programmable registers will not + * be reset to default value after DP_SW_RESET + * therefore interrupt mask bits have to be updated + * to enable/disable interrupts + */ + dp_catalog_ctrl_enable_irq(ctrl->catalog, enable); } void dp_ctrl_phy_init(struct dp_ctrl *dp_ctrl) diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c index c388323..c34dbfc 100644 --- a/drivers/gpu/drm/msm/dp/dp_display.c +++ b/drivers/gpu/drm/msm/dp/dp_display.c @@ -98,6 +98,8 @@ struct dp_display_private { struct dp_ctrl *ctrl; struct dp_debug *debug; + atomic_t suspended; + struct dp_usbpd_cb usbpd_cb; struct dp_display_mode dp_mode; struct msm_dp dp_display; @@ -187,6 +189,11 @@ static int dp_add_event(struct dp_display_private *dp_priv, u32 event, int pndx; spin_lock_irqsave(&dp_priv->event_lock, flag); + if (atomic_read(&dp_priv->suspended)) { + spin_unlock_irqrestore(&dp_priv->event_lock, flag); + return -EPERM; + } + pndx = dp_priv->event_pndx + 1; pndx %= DP_EVENT_Q_MAX; if (pndx == dp_priv->event_gndx) { @@ -454,6 +461,13 @@ static void dp_display_host_deinit(struct dp_display_private *dp) dp->dp_display.connector_type, dp->core_initialized, dp->phy_initialized); + if (!dp->core_initialized) { + DRM_DEBUG_DP("DP core not initialized\n"); + return; + } + + synchronize_irq(dp->irq); + dp_ctrl_reset_irq_ctrl(dp->ctrl, false); dp_aux_deinit(dp->aux); dp_power_deinit(dp->power); @@ -1362,6 +1376,8 @@ static int dp_pm_resume(struct device *dev) dp->dp_display.connector_type, dp->core_initialized, dp->phy_initialized, dp_display->power_on); + atomic_set(&dp->suspended, 0); + /* start from disconnected state */ dp->hpd_state = ST_DISCONNECTED; @@ -1431,6 +1447,8 @@ static int dp_pm_suspend(struct device *dev) dp->dp_display.connector_type, dp->core_initialized, dp->phy_initialized, dp_display->power_on); + atomic_inc(&dp->suspended); + /* mainlink enabled */ if (dp_power_clk_status(dp->power, DP_CTRL_PM)) dp_ctrl_off_link_stream(dp->ctrl); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

2 1

[pull] amdgpu drm-fixes-5.18
by Alex Deucher 11 May '22

11 May '22

Hi Dave, Daniel, Fixes for 5.18. The following changes since commit 5727375215b0915f28806c337a7ba9835efd340b: Merge tag 'drm-msm-fixes-2022-04-30' of https://gitlab.freedesktop.org/drm/msm into drm-fixes (2022-05-06 11:22:03 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.18-2022-05-11 for you to fetch changes up to c65b364c52ba352177dde6944f5efaa29bd40b52: drm/amdgpu/ctx: only reset stable pstate if the user changed it (v2) (2022-05-11 11:50:43 -0400) ---------------------------------------------------------------- amd-drm-fixes-5.18-2022-05-11: amdgpu: - Disable ASPM for VI boards on ADL platforms - S0ix DCN3.1 display fix - Resume regression fix - Stable pstate fix ---------------------------------------------------------------- Alex Deucher (2): Revert "drm/amd/pm: keep the BACO feature enabled for suspend" drm/amdgpu/ctx: only reset stable pstate if the user changed it (v2) Eric Yang (1): drm/amd/display: undo clearing of z10 related function pointers Richard Gong (1): drm/amdgpu: vi: disable ASPM on Intel Alder Lake based systems drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 5 +++++ drivers/gpu/drm/amd/amdgpu/vi.c | 17 ++++++++++++++++- drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c | 5 ----- drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 8 +------- 4 files changed, 22 insertions(+), 13 deletions(-)

1 0

[PATCH v2 1/3] dt-bindings: vendor-prefixes: Add prefix for EBBG
by Joel Selvaraj 11 May '22

11 May '22

Add a prefix for EBBG. They manufacture displays which are used in some Xiaomi phones, but I could not find much details about the company. Signed-off-by: Joel Selvaraj <jo(a)jsfamily.in> --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 80e80fa53f8a..effd1cb995cf 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -337,6 +337,8 @@ patternProperties: description: Embedded Artists AB "^ebang,.*": description: Zhejiang Ebang Communication Co., Ltd + "^ebbg,.*": + description: EBBG "^ebs-systart,.*": description: EBS-SYSTART GmbH "^ebv,.*": -- 2.36.1

2 2

[PATCH v5, 0/5] Cooperate with DSI RX devices to modify dsi funcs and delay mipi high to cooperate with panel sequence
by xinlei.lee＠mediatek.com 11 May '22

11 May '22

From: Xinlei Lee <xinlei.lee(a)mediatek.com> In upstream-v5.8, dsi_enable will operate panel_enable, but this modification has been moved in v5.9. In order to ensure the timing of dsi_power_on/off and the timing of pulling up/down the MIPI signal, the modification of v5.9 is synchronized in this series of patches. Changes since v4: 1. Dsi func modified to atomic operation. 2. Added fix tag. 3. Removed lane_ready print statement. Changes since v3: 1. Rebase kernel-5.18-rc1. 2. Added dsi_enable protection. 3. Encapsulates the dsi_lane_ready function. Changes since v2: 1. Rebase linux-next. Changes since v1: 1. Dsi sequence marked with patch adjustment. 2. Fixes: mtk_dsi: Use the drm_panel_bridge. Jitao Shi (3): drm/mediatek: Adjust the timing of mipi signal from LP00 to LP11 drm/mediatek: Separate poweron/poweroff from enable/disable and define new funcs drm/mediatek: keep dsi as LP00 before dcs cmds transfer Xinlei Lee (2): drm/mediatek: Modify dsi funcs to atomic operations drm/mediatek: Add pull-down MIPI operation in mtk_dsi_poweroff function drivers/gpu/drm/mediatek/mtk_dsi.c | 94 ++++++++++++++++++++---------- 1 file changed, 64 insertions(+), 30 deletions(-) -- 2.18.0

2 6

[PATCH] drm/bridge: cdns-dsi: Add support for pre_enable and post_enable control functions.
by Jayshri Pawar 11 May '22

11 May '22

From: jpawar <jpawar(a)cadence.com> Add support for pre_enable and post_enable drm bridge control functions. Making sure that host to be prepared before panel is powered up, for the panels like TC358762. Signed-off-by: jpawar <jpawar(a)cadence.com> --- drivers/gpu/drm/bridge/cdns-dsi.c | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c b/drivers/gpu/drm/bridge/cdns-dsi.c index 829e1a144656..20bece84ff8c 100644 --- a/drivers/gpu/drm/bridge/cdns-dsi.c +++ b/drivers/gpu/drm/bridge/cdns-dsi.c @@ -462,6 +462,7 @@ struct cdns_dsi { struct reset_control *dsi_p_rst; struct clk *dsi_sys_clk; bool link_initialized; + bool phy_initialized; struct phy *dphy; }; @@ -711,11 +712,21 @@ static void cdns_dsi_bridge_disable(struct drm_bridge *bridge) pm_runtime_put(dsi->base.dev); } +static void cdns_dsi_bridge_post_disable(struct drm_bridge *bridge) +{ + struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge); + struct cdns_dsi *dsi = input_to_dsi(input); + + pm_runtime_put(dsi->base.dev); +} + static void cdns_dsi_hs_init(struct cdns_dsi *dsi) { struct cdns_dsi_output *output = &dsi->output; u32 status; + if (dsi->phy_initialized) + return; /* * Power all internal DPHY blocks down and maintain their reset line * asserted before changing the DPHY config. @@ -739,6 +750,7 @@ static void cdns_dsi_hs_init(struct cdns_dsi *dsi) writel(DPHY_CMN_PSO | DPHY_ALL_D_PDN | DPHY_C_PDN | DPHY_CMN_PDN | DPHY_D_RSTB(output->dev->lanes) | DPHY_C_RSTB, dsi->regs + MCTL_DPHY_CFG0); + dsi->phy_initialized = true; } static void cdns_dsi_init_link(struct cdns_dsi *dsi) @@ -914,11 +926,25 @@ static void cdns_dsi_bridge_enable(struct drm_bridge *bridge) writel(tmp, dsi->regs + MCTL_MAIN_EN); } +static void cdns_dsi_bridge_pre_enable(struct drm_bridge *bridge) +{ + struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge); + struct cdns_dsi *dsi = input_to_dsi(input); + + if (WARN_ON(pm_runtime_get_sync(dsi->base.dev) < 0)) + return; + + cdns_dsi_init_link(dsi); + cdns_dsi_hs_init(dsi); +} + static const struct drm_bridge_funcs cdns_dsi_bridge_funcs = { .attach = cdns_dsi_bridge_attach, .mode_valid = cdns_dsi_bridge_mode_valid, .disable = cdns_dsi_bridge_disable, + .pre_enable = cdns_dsi_bridge_pre_enable, .enable = cdns_dsi_bridge_enable, + .post_disable = cdns_dsi_bridge_post_disable, }; static int cdns_dsi_attach(struct mipi_dsi_host *host, -- 2.30.2

3 2

[PATCH 0/4] Remove support for Hyper-V 2008 and 2008R2/Win7
by Michael Kelley 11 May '22

11 May '22

Linux code for running as a Hyper-V guest includes special cases for the first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These versions were very thinly used for running Linux guests when first released more than 12 years ago, and they are now out of support (except for extended security updates). As initial versions, they lack the performance features needed for effective production usage of Linux guests. In total, there's no need to continue to support the latest Linux kernels on these versions of Hyper-V. Simplify the code for running on Hyper-V by removing the special cases. This includes removing the negotiation of the VMbus protocol versions for 2008 and 2008R2, and the special case code based on those VMbus protocol versions. Changes are in the core VMbus code and several drivers for synthetic VMbus devices. Some drivers have driver-specific protocols with the Hyper-V host and may have versions of those protocols that are limited to 2008 and 2008R2. This patch set does the clean-up only for the top-level VMbus protocol versions, and not the driver-specific protocols. Cleaning up the driver-specific protocols can be done with follow-on patches. There's no specific urgency to removing the special case code for 2008 and 2008R2, so if the broader Linux kernel community surfaces a reason why this clean-up should not be done now, we can wait. But I think we want to eventually stop carrying around this extra baggage, and based on discussions with the Hyper-V team within Microsoft, we're already past the point that it has any value. Michael Kelley (4): Drivers: hv: vmbus: Remove support for Hyper-V 2008 and Hyper-V 2008R2/Win7 scsi: storvsc: Remove support for Hyper-V 2008 and 2008R2/Win7 video: hyperv_fb: Remove support for Hyper-V 2008 and 2008R2/Win7 drm/hyperv: Remove support for Hyper-V 2008 and 2008R2/Win7 drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 23 ++++-------- drivers/hv/channel_mgmt.c | 29 ++++++--------- drivers/hv/connection.c | 6 ++-- drivers/hv/vmbus_drv.c | 60 +++++++------------------------ drivers/scsi/storvsc_drv.c | 36 +++++-------------- drivers/video/fbdev/hyperv_fb.c | 23 ++---------- include/linux/hyperv.h | 10 ++++-- 7 files changed, 52 insertions(+), 135 deletions(-) -- 1.8.3.1

6 11

[PATCH 1/3] drm/virtio: .release ops for virtgpu fence release
by Dongwon Kim 11 May '22

11 May '22

virtio_gpu_fence_release is added to free virtio-gpu-fence upon release of dma_fence. Cc: Gurchetan Singh <gurchetansingh(a)chromium.org> Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Vivek Kasireddy <vivek.kasireddy(a)intel.com> Signed-off-by: Dongwon Kim <dongwon.kim(a)intel.com> --- drivers/gpu/drm/virtio/virtgpu_fence.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c b/drivers/gpu/drm/virtio/virtgpu_fence.c index f28357dbde35..ba659ac2a51d 100644 --- a/drivers/gpu/drm/virtio/virtgpu_fence.c +++ b/drivers/gpu/drm/virtio/virtgpu_fence.c @@ -63,12 +63,20 @@ static void virtio_gpu_timeline_value_str(struct dma_fence *f, char *str, (u64)atomic64_read(&fence->drv->last_fence_id)); } +static void virtio_gpu_fence_release(struct dma_fence *f) +{ + struct virtio_gpu_fence *fence = to_virtio_gpu_fence(f); + + kfree(fence); +} + static const struct dma_fence_ops virtio_gpu_fence_ops = { .get_driver_name = virtio_gpu_get_driver_name, .get_timeline_name = virtio_gpu_get_timeline_name, .signaled = virtio_gpu_fence_signaled, .fence_value_str = virtio_gpu_fence_value_str, .timeline_value_str = virtio_gpu_timeline_value_str, + .release = virtio_gpu_fence_release, }; struct virtio_gpu_fence *virtio_gpu_fence_alloc(struct virtio_gpu_device *vgdev, -- 2.20.1

3 4

[PATCH v3 0/4] fbdev: Fix use-after-free caused by wrong fb_info cleanup in drivers
by Javier Martinez Canillas 11 May '22

11 May '22

Hello, This series contains patches suggested by Daniel Vetter to fix a use-after-free error in the fb_release() function, due a fb_info associated with a fbdev being freed too early while a user-space process still has the fbdev dev node opened. That is caused by a wrong management of the struct fb_info lifetime in drivers, but the fbdev core can also be made more resilient about it an leak This can easily be reproduced with the simplefb driver doing the following: $ cat < /dev/fb0 & $ echo simple-framebuffer.0 > /sys/bus/platform/drivers/simple-framebuffer/unbind $ kill %1 [ 257.490471] ------------[ cut here ]------------ ... [ 257.495125] refcount_t: underflow; use-after-free. [ 257.495222] WARNING: CPU: 0 PID: 975 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x144 ... [ 257.637482] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 257.644441] pc : refcount_warn_saturate+0xf4/0x144 [ 257.649226] lr : refcount_warn_saturate+0xf4/0x144 [ 257.654009] sp : ffff80000a06bbf0 [ 257.657315] x29: ffff80000a06bbf0 x28: 000000000000000a x27: 000000000000000a [ 257.664448] x26: 0000000000000000 x25: ffff470b88c6a180 x24: 000000000000000a [ 257.671581] x23: ffff470b81706480 x22: ffff470b808c2160 x21: ffff470b8922ba20 [ 257.678713] x20: ffff470b891f5810 x19: ffff470b891f5800 x18: ffffffffffffffff [ 257.685846] x17: 3a725f7463656a62 x16: ffffbb18c6465fd4 x15: 0720072007200720 [ 257.692978] x14: 0720072d072d072d x13: 0a2e656572662d72 x12: 657466612d657375 [ 257.700110] x11: 203b776f6c667265 x10: 646e75203a745f74 x9 : ffffbb18c58f6c90 [ 257.707242] x8 : 75203b776f6c6672 x7 : 65646e75203a745f x6 : 0000000000000001 [ 257.714373] x5 : ffff470bff8ec418 x4 : 0000000000000000 x3 : 0000000000000027 [ 257.721506] x2 : 0000000000000000 x1 : 0000000000000027 x0 : 0000000000000026 [ 257.728638] Call trace: [ 257.731075] refcount_warn_saturate+0xf4/0x144 [ 257.735513] put_fb_info+0x70/0x7c [ 257.738916] fb_release+0x60/0x74 [ 257.742225] __fput+0x88/0x240 [ 257.745276] ____fput+0x1c/0x30 [ 257.748410] task_work_run+0xc4/0x21c [ 257.752066] do_exit+0x170/0x370 [ 257.755288] do_group_exit+0x40/0xb4 [ 257.758858] get_signal+0x8e0/0x90c [ 257.762339] do_signal+0x1a0/0x280 [ 257.765733] do_notify_resume+0xc8/0x390 [ 257.769650] el0_da+0xe8/0xf0 [ 257.772613] el0t_64_sync_handler+0xe8/0x130 [ 257.776877] el0t_64_sync+0x190/0x194 [ 257.780534] ---[ end trace 0000000000000000 ]--- Patch #1 adds a WARN_ON() to framebuffer_release() to prevent the use-after-free to happen. Patch #2, #3 and #4 fix the simplefb, efifb and vesafb drivers respectively, to free the resources at the correct place. Changes in v3: - Add Fixes: tag (Daniel Vetter). - Include in commit message a note that drivers are still broken but at least reverts to the previous behavior (Daniel Vetter). - Only move framebuffer_release() and don't do any other change (Daniel Vetter). Changes in v2: - Also do the change for vesafb (Thomas Zimmermann). Daniel Vetter (1): fbdev: Prevent possible use-after-free in fb_release() Javier Martinez Canillas (3): fbdev: simplefb: Cleanup fb_info in .fb_destroy rather than .remove fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove fbdev: vesafb: Cleanup fb_info in .fb_destroy rather than .remove drivers/video/fbdev/core/fbsysfs.c | 4 ++++ drivers/video/fbdev/efifb.c | 9 ++++++++- drivers/video/fbdev/simplefb.c | 8 +++++++- drivers/video/fbdev/vesafb.c | 8 +++++++- 4 files changed, 26 insertions(+), 3 deletions(-) -- 2.35.1

5 29

[PATCH v2] drm/tegra: Stop using iommu_present()
by Robin Murphy 11 May '22

11 May '22

Refactor the confusing logic to make it both clearer and more robust. If the host1x parent device does have an IOMMU domain then iommu_present() is redundantly true, while otherwise for the 32-bit DMA mask case it still doesn't say whether the IOMMU driver actually knows about the DRM device or not. Signed-off-by: Robin Murphy <robin.murphy(a)arm.com> --- v2: Fix logic for older SoCs and clarify. drivers/gpu/drm/tegra/drm.c | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index 9464f522e257..4f2bdab31064 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -1092,6 +1092,19 @@ static bool host1x_drm_wants_iommu(struct host1x_device *dev) struct host1x *host1x = dev_get_drvdata(dev->dev.parent); struct iommu_domain *domain; + /* For starters, this is moot if no IOMMU is available */ + if (!device_iommu_mapped(&dev->dev)) + return false; + + /* + * Tegra20 and Tegra30 don't support addressing memory beyond the + * 32-bit boundary, so the regular GATHER opcodes will always be + * sufficient and whether or not the host1x is attached to an IOMMU + * doesn't matter. + */ + if (host1x_get_dma_mask(host1x) <= DMA_BIT_MASK(32)) + return true; + /* * If the Tegra DRM clients are backed by an IOMMU, push buffers are * likely to be allocated beyond the 32-bit boundary if sufficient @@ -1122,14 +1135,13 @@ static bool host1x_drm_wants_iommu(struct host1x_device *dev) domain = iommu_get_domain_for_dev(dev->dev.parent); /* - * Tegra20 and Tegra30 don't support addressing memory beyond the - * 32-bit boundary, so the regular GATHER opcodes will always be - * sufficient and whether or not the host1x is attached to an IOMMU - * doesn't matter. + * At the moment, the exact type of domain doesn't actually matter. + * Only for 64-bit kernels might this be a managed DMA API domain, and + * then only on newer SoCs using arm-smmu, since tegra-smmu doesn't + * support default domains at all, and since those SoCs are the same + * ones with extended GATHER support, even if it's a passthrough domain + * it can still work out OK. */ - if (!domain && host1x_get_dma_mask(host1x) <= DMA_BIT_MASK(32)) - return true; - return domain != NULL; } @@ -1149,7 +1161,7 @@ static int host1x_drm_probe(struct host1x_device *dev) goto put; } - if (host1x_drm_wants_iommu(dev) && iommu_present(&platform_bus_type)) { + if (host1x_drm_wants_iommu(dev)) { tegra->domain = iommu_domain_alloc(&platform_bus_type); if (!tegra->domain) { err = -ENOMEM; -- 2.28.0.dirty

2 4

[PATCH] drm/todo: Add entry for converting kselftests to kunit
by Javier Martinez Canillas 11 May '22

11 May '22

Many of the kselftests in DRM can be converted to kunit tests instead, since that framework is more suitable for unit testing. Suggested-by: Maxime Ripard <maxime(a)cerno.tech> Signed-off-by: Javier Martinez Canillas <javierm(a)redhat.com> --- Documentation/gpu/todo.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 10bfb50908d1..513b20ccef1e 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -617,6 +617,17 @@ Contact: Javier Martinez Canillas <javierm(a)redhat.com> Level: Intermediate +Convert Kernel Selftests (kselftest) to KUnit tests when appropriate +-------------------------------------------------------------------- + +Many of the `Kselftest <https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html>`_ +tests in DRM could be converted to Kunit tests instead, since that framework +is more suitable for unit testing. + +Contact: Javier Martinez Canillas <javierm(a)redhat.com> + +Level: Starter + Enable trinity for DRM ---------------------- -- 2.35.1

2 2

← Newer
1
...
49
50
51
52
53
54
55
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2022