dri-devel February 2022

dri-devel@lists.freedesktop.org

394 participants
865 discussions

[PATCH 0/3] Migrate device coherent pages on get_user_pages()
by Alistair Popple 07 Feb '22

07 Feb '22

Device coherent pages represent memory on a coherently attached device such as a GPU which is usually under the control of a driver. These pages should not be pinned as the driver needs to be able to move pages as required. Currently this is enforced by failing any attempt to pin a device coherent page. A similar problem exists for ZONE_MOVABLE pages. In that case though the pages are migrated instead of causing failure. There is no reason the kernel can't migrate device coherent pages so this series implements migration for device coherent pages so the same strategy of migrate and pin can be used. This series depends on the series "Add MEMORY_DEVICE_COHERENT for coherent device memory mapping"[1] and should apply cleanly on top of that. [1] - https://lore.kernel.org/linux-mm/20220128200825.8623-1-alex.sierra@amd.com/ Alex Sierra (1): tools: add hmm gup test for long term pinned device pages Alistair Popple (2): migrate.c: Remove vma check in migrate_vma_setup() mm/gup.c: Migrate device coherent pages when pinning instead of failing mm/gup.c | 105 +++++++++++++++++++++++--- mm/migrate.c | 34 ++++---- tools/testing/selftests/vm/Makefile | 2 +- tools/testing/selftests/vm/hmm-tests.c | 81 ++++++++++++++++++++- 4 files changed, 194 insertions(+), 28 deletions(-) -- git-series 0.9.1

2 6

[RFC v2 0/8] Define and use reset domain for GPU recovery in amdgpu
by Andrey Grodzovsky 07 Feb '22

07 Feb '22

This patchset is based on earlier work by Boris[1] that allowed to have an ordered workqueue at the driver level that will be used by the different schedulers to queue their timeout work. On top of that I also serialized any GPU reset we trigger from within amdgpu code to also go through the same ordered wq and in this way simplify somewhat our GPU reset code so we don't need to protect from concurrency by multiple GPU reset triggeres such as TDR on one hand and sysfs trigger or RAS trigger on the other hand. As advised by Christian and Daniel I defined a reset_domain struct such that all the entities that go through reset together will be serialized one against another. TDR triggered by multiple entities within the same domain due to the same reason will not be triggered as the first such reset will cancel all the pending resets. This is relevant only to TDR timers and not to triggered resets coming from RAS or SYSFS, those will still happen after the in flight resets finishes. v2: Add handling on SRIOV configuration, the reset notify coming from host and driver already trigger a work queue to handle the reset so drop this intermidiate wq and send directly to timeout wq. (Shaoyun) [1] https://patchwork.kernel.org/project/dri-devel/patch/20210629073510.2764391… P.S Going through drm-misc-next and not amd-staging-drm-next as Boris work hasn't landed yet there. Andrey Grodzovsky (8): drm/amdgpu: Introduce reset domain drm/amdgpu: Move scheduler init to after XGMI is ready drm/amdgpu: Fix crash on modprobe drm/amdgpu: Serialize non TDR gpu recovery with TDRs drm/amd/virt: For SRIOV send GPU reset directly to TDR queue. drm/amdgpu: Drop hive->in_reset drm/amdgpu: Drop concurrent GPU reset protection for device drm/amd/virt: Drop concurrent GPU reset protection for SRIOV drivers/gpu/drm/amd/amdgpu/amdgpu.h | 9 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 206 +++++++++++---------- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 36 +--- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h | 3 +- drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 18 +- drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c | 18 +- drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 7 +- 10 files changed, 147 insertions(+), 164 deletions(-) -- 2.25.1

9 54

[PATCH] drm/sprd: remove allow_fb_modifiers setting
by Tomohito Esaki 06 Feb '22

06 Feb '22

Remove allow_fb_modifiers setting in this driver. The allow_fb_modifiers flag was removed. Signed-off-by: Tomohito Esaki <etom(a)igel.co.jp> Fixes: 3d082157a242 ("drm: remove allow_fb_modifiers") Reported-by: kernel test robot <lkp(a)intel.com> --- drivers/gpu/drm/sprd/sprd_drm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/sprd/sprd_drm.c b/drivers/gpu/drm/sprd/sprd_drm.c index a077e2d4d721..54c851bccf5b 100644 --- a/drivers/gpu/drm/sprd/sprd_drm.c +++ b/drivers/gpu/drm/sprd/sprd_drm.c @@ -43,7 +43,6 @@ static void sprd_drm_mode_config_init(struct drm_device *drm) drm->mode_config.min_height = 0; drm->mode_config.max_width = 8192; drm->mode_config.max_height = 8192; - drm->mode_config.allow_fb_modifiers = true; drm->mode_config.funcs = &sprd_drm_mode_config_funcs; drm->mode_config.helper_private = &sprd_drm_mode_config_helper; -- 2.17.1

2 1

[PATCH v2] drm/panel: JDI LT070ME05000 simplify with dev_err_probe()
by David Heidelberg 06 Feb '22

06 Feb '22

Use the dev_err_probe() helper to simplify error handling during probe. This also handle scenario, when EDEFER is returned and useless error is printed. Fixes error: panel-jdi-lt070me05000 4700000.dsi.0: cannot get enable-gpio -517 Signed-off-by: David Heidelberg <david(a)ixit.cz> --- v2: - original v1 patch name "drm/panel: JDI LT070ME05000 remove useless warning" - use dev_err_probe function --- .../gpu/drm/panel/panel-jdi-lt070me05000.c | 36 ++++++++----------- 1 file changed, 14 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c index ea0e7221e706..7069201e6cac 100644 --- a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c +++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c @@ -400,38 +400,30 @@ static int jdi_panel_add(struct jdi_panel *jdi) ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(jdi->supplies), jdi->supplies); - if (ret < 0) { - dev_err(dev, "failed to init regulator, ret=%d\n", ret); - return ret; - } + if (ret < 0) + return dev_err_probe(dev, ret, + "failed to init regulator, ret=%d\n", ret); jdi->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW); if (IS_ERR(jdi->enable_gpio)) { - ret = PTR_ERR(jdi->enable_gpio); - dev_err(dev, "cannot get enable-gpio %d\n", ret); - return ret; + return dev_err_probe(dev, PTR_ERR(jdi->enable_gpio), + "cannot get enable-gpio %d\n", ret); } jdi->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH); - if (IS_ERR(jdi->reset_gpio)) { - ret = PTR_ERR(jdi->reset_gpio); - dev_err(dev, "cannot get reset-gpios %d\n", ret); - return ret; - } + if (IS_ERR(jdi->reset_gpio)) + return dev_err_probe(dev, PTR_ERR(jdi->reset_gpio), + "cannot get reset-gpios %d\n", ret); jdi->dcdc_en_gpio = devm_gpiod_get(dev, "dcdc-en", GPIOD_OUT_LOW); - if (IS_ERR(jdi->dcdc_en_gpio)) { - ret = PTR_ERR(jdi->dcdc_en_gpio); - dev_err(dev, "cannot get dcdc-en-gpio %d\n", ret); - return ret; - } + if (IS_ERR(jdi->dcdc_en_gpio)) + return dev_err_probe(dev, PTR_ERR(jdi->dcdc_en_gpio), + "cannot get dcdc-en-gpio %d\n", ret); jdi->backlight = drm_panel_create_dsi_backlight(jdi->dsi); - if (IS_ERR(jdi->backlight)) { - ret = PTR_ERR(jdi->backlight); - dev_err(dev, "failed to register backlight %d\n", ret); - return ret; - } + if (IS_ERR(jdi->backlight)) + return dev_err_probe(dev, PTR_ERR(jdi->backlight), + "failed to register backlight %d\n", ret); drm_panel_init(&jdi->base, &jdi->dsi->dev, &jdi_panel_funcs, DRM_MODE_CONNECTOR_DSI); -- 2.34.1

1 0

[PATCH] drm/panel: JDI LT070ME05000 remove useless warning
by David Heidelberg 06 Feb '22

06 Feb '22

Do as most of panel and in case of deffered probe, don't print error. Fixes warning: panel-jdi-lt070me05000 4700000.dsi.0: cannot get enable-gpio -517 Signed-off-by: David Heidelberg <david(a)ixit.cz> --- drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c index ea0e7221e706..b5c0b51dc146 100644 --- a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c +++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c @@ -408,7 +408,8 @@ static int jdi_panel_add(struct jdi_panel *jdi) jdi->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW); if (IS_ERR(jdi->enable_gpio)) { ret = PTR_ERR(jdi->enable_gpio); - dev_err(dev, "cannot get enable-gpio %d\n", ret); + if (ret != -EPROBE_DEFER) + dev_err(dev, "cannot get enable-gpio %d\n", ret); return ret; } -- 2.34.1

2 2

[BUG] gpu: drm: radeon: two possible deadlocks involving locking and waiting
by Jia-Ju Bai 06 Feb '22

06 Feb '22

Hello, My static analysis tool reports a possible deadlock in the radeon driver in Linux 5.16: #BUG 1 radeon_dpm_change_power_state_locked() mutex_lock(&rdev->ring_lock); --> Line 1133 (Lock A) radeon_fence_wait_empty() radeon_fence_wait_seq_timeout() wait_event_timeout(rdev->fence_queue, ...) --> Line 504 (Wait X) radeon_ring_backup() mutex_lock(&rdev->ring_lock); --> Line 289(Lock A) radeon_fence_count_emitted() radeon_fence_process() wake_up_all(&rdev->fence_queue); --> Line 323 (Wake X) When radeon_dpm_change_power_state_locked() is executed, "Wait X" is performed by holding "Lock A". If radeon_ring_backup() is executed at this time, "Wake X" cannot be performed to wake up "Wait X" in radeon_dpm_change_power_state_locked(), because "Lock A" has been already hold by radeon_dpm_change_power_state_locked(), causing a possible deadlock. I find that "Wait X" is performed with a timeout MAX_SCHEDULE_TIMEOUT, to relieve the possible deadlock; but I think this timeout can cause inefficient execution. #BUG 2 radeon_ring_lock() mutex_lock(&rdev->ring_lock); --> Line 147 (Lock A) radeon_ring_alloc() radeon_fence_wait_next() radeon_fence_wait_seq_timeout() wait_event_timeout(rdev->fence_queue, ...) --> Line 504 (Wait X) radeon_ring_backup() mutex_lock(&rdev->ring_lock); --> Line 289(Lock A) radeon_fence_count_emitted() radeon_fence_process() wake_up_all(&rdev->fence_queue); --> Line 323 (Wake X) When radeon_ring_lock() is executed, "Wait X" is performed by holding "Lock A". If radeon_ring_backup() is executed at this time, "Wake X" cannot be performed to wake up "Wait X" in radeon_ring_lock(), because "Lock A" has been already hold by radeon_ring_lock(), causing a possible deadlock. I find that "Wait X" is performed with a timeout MAX_SCHEDULE_TIMEOUT, to relieve the possible deadlock; but I think this timeout can cause inefficient execution. I am not quite sure whether these possible problems are real and how to fix them if they are real. Any feedback would be appreciated, thanks :) Best wishes, Jia-Ju Bai

3 3

[PATCH] drm/panel: simple: Assign data from panel_dpi_probe() correctly
by Christoph Niedermaier 06 Feb '22

06 Feb '22

In the function panel_simple_probe() the pointer panel->desc is assigned to the passed pointer desc. If function panel_dpi_probe() is called panel->desc will be updated, but further on only desc will be evaluated. So update the desc pointer to be able to use the data from the function panel_dpi_probe(). Fixes: 4a1d0dbc8332 ("drm/panel: simple: add panel-dpi support") Signed-off-by: Christoph Niedermaier <cniedermaier(a)dh-electronics.com> Cc: Marek Vasut <marex(a)denx.de> Cc: Thierry Reding <thierry.reding(a)gmail.com> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> To: dri-devel(a)lists.freedesktop.org --- drivers/gpu/drm/panel/panel-simple.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 9e46db5e359c..3c08f9827acf 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -588,6 +588,7 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc) err = panel_dpi_probe(dev, panel); if (err) goto free_ddc; + desc = panel->desc; } else { if (!of_get_display_timing(dev->of_node, "panel-timing", &dt)) panel_simple_parse_panel_timing_node(dev, panel, &dt); -- 2.11.0

3 3

[Bug 201539] New: AMDGPU R9 390 automatic fan speed control in Linux 4.19
by bugzilla-daemon＠bugzilla.kernel.org 05 Feb '22

05 Feb '22

https://bugzilla.kernel.org/show_bug.cgi?id=201539 Bug ID: 201539 Summary: AMDGPU R9 390 automatic fan speed control in Linux 4.19 Product: Drivers Version: 2.5 Kernel Version: 4.19 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: 0xe2.0x9a.0x9b(a)gmail.com Regression: No GPU: R9 390 Kernel module: amdgpu Application (example): Rise of the Tomb Raider benchmark In Linux 4.18 the fan speed of the GPU gradually adapts to GPU load. Maximum pwm is 155 during the benchmark. In Linux 4.19 the overall fan speed is lower (which is more silent than 4.18, with maximum at 112) but the fan spikes to full speed (pwm=255) for 1-2 seconds which is extremely loud. The 4.18 and 4.19 kernels are using the same firmware. -- You are receiving this mail because: You are watching the assignee of the bug.

2 78

[PATCH] Revert "drm/nouveau/pmu/gm200-: avoid touching PMU outside of DEVINIT/PREOS/ACR"
by Karol Herbst 05 Feb '22

05 Feb '22

This reverts commit 1d2271d2fb85e54bfc9630a6c30ac0feb9ffb983. This fix actually causes regressions, which I could verify on my systems as well. So let's revert it and figure out a proper fix for the original problem. Cc: Ben Skeggs <bskeggs(a)redhat.com> Bug: https://gitlab.freedesktop.org/drm/nouveau/-/issues/149 Signed-off-by: Karol Herbst <kherbst(a)redhat.com> --- .../gpu/drm/nouveau/nvkm/subdev/pmu/base.c | 37 ++++++++----------- 1 file changed, 16 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/base.c b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/base.c index 455e95a89259..24382875fb4f 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/base.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/base.c @@ -94,13 +94,20 @@ nvkm_pmu_fini(struct nvkm_subdev *subdev, bool suspend) return 0; } -static void +static int nvkm_pmu_reset(struct nvkm_pmu *pmu) { struct nvkm_device *device = pmu->subdev.device; if (!pmu->func->enabled(pmu)) - return; + return 0; + + /* Inhibit interrupts, and wait for idle. */ + nvkm_wr32(device, 0x10a014, 0x0000ffff); + nvkm_msec(device, 2000, + if (!nvkm_rd32(device, 0x10a04c)) + break; + ); /* Reset. */ if (pmu->func->reset) @@ -111,37 +118,25 @@ nvkm_pmu_reset(struct nvkm_pmu *pmu) if (!(nvkm_rd32(device, 0x10a10c) & 0x00000006)) break; ); + + return 0; } static int nvkm_pmu_preinit(struct nvkm_subdev *subdev) { struct nvkm_pmu *pmu = nvkm_pmu(subdev); - nvkm_pmu_reset(pmu); - return 0; + return nvkm_pmu_reset(pmu); } static int nvkm_pmu_init(struct nvkm_subdev *subdev) { struct nvkm_pmu *pmu = nvkm_pmu(subdev); - struct nvkm_device *device = pmu->subdev.device; - - if (!pmu->func->init) - return 0; - - if (pmu->func->enabled(pmu)) { - /* Inhibit interrupts, and wait for idle. */ - nvkm_wr32(device, 0x10a014, 0x0000ffff); - nvkm_msec(device, 2000, - if (!nvkm_rd32(device, 0x10a04c)) - break; - ); - - nvkm_pmu_reset(pmu); - } - - return pmu->func->init(pmu); + int ret = nvkm_pmu_reset(pmu); + if (ret == 0 && pmu->func->init) + ret = pmu->func->init(pmu); + return ret; } static void * -- 2.34.1

1 0

[PATCH] iommu/vt-d: Remove comment reference to iommu_dev_has_feature
by Akeem G Abodunrin 05 Feb '22

05 Feb '22

iommu_dev_has_feature() api has been removed by the commit 262948f8ba573 ("iommu: Delete iommu_dev_has_feature()") - So this patch removes comment about the api to avoid any confusion. Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin(a)intel.com> Cc: Lu Baolu <baolu.lu(a)linux.intel.com> --- include/linux/iommu.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index de0c57a567c8..bea054f2bd4d 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -153,8 +153,7 @@ struct iommu_resv_region { * supported, this feature must be enabled before and * disabled after %IOMMU_DEV_FEAT_SVA. * - * Device drivers query whether a feature is supported using - * iommu_dev_has_feature(), and enable it using iommu_dev_enable_feature(). + * Device drivers enable the feature via iommu_dev_enable_feature(). */ enum iommu_dev_features { IOMMU_DEV_FEAT_AUX, -- 2.21.3

2 1

← Newer
1
...
73
74
75
76
77
78
79
...
87
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2022