dri-devel April 2021

dri-devel@lists.freedesktop.org

317 participants
715 discussions

[PATCH 0/2] Document how userspace should use plane format list and IN_FORMATS
by Leandro Ribeiro 20 Apr '21

20 Apr '21

This patch is to emphasize how userspace should use the plane format list and the IN_FORMATS blob. The plane format list contains the formats that do not require modifiers, and the blob property has the formats that support modifiers. Note that these are not disjoint sets. If a format supports modifiers but the driver can also handle it without a modifier, it should be present in both the IN_FORMATS blob property and the plane format list. This is important for userspace, as there are situations in which we need to find out if the KMS driver can handle a certain format without any modifiers. Leandro Ribeiro (2): drm/doc: document drm_mode_get_plane drm/doc: emphasize difference between plane formats and IN_FORMATS blob drivers/gpu/drm/drm_plane.c | 4 ++++ include/uapi/drm/drm_mode.h | 22 ++++++++++++++++++++++ 2 files changed, 26 insertions(+) -- 2.31.1

5 16

[PATCH 01/12] drm/arm: Don't set allow_fb_modifiers explicitly
by Daniel Vetter 20 Apr '21

20 Apr '21

Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski <paul.kocialkowski(a)bootlin.com> Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here for both komeda and malidp. Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: "James (Qian) Wang" <james.qian.wang(a)arm.com> Cc: Liviu Dudau <liviu.dudau(a)arm.com> Cc: Mihail Atanassov <mihail.atanassov(a)arm.com> Cc: Brian Starkey <brian.starkey(a)arm.com> --- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 1 - drivers/gpu/drm/arm/malidp_drv.c | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c index aeda4e5ec4f4..ff45f23f3d56 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c @@ -247,7 +247,6 @@ static void komeda_kms_mode_config_init(struct komeda_kms_dev *kms, config->min_height = 0; config->max_width = 4096; config->max_height = 4096; - config->allow_fb_modifiers = true; config->funcs = &komeda_mode_config_funcs; config->helper_private = &komeda_mode_config_helpers; diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c index d83c7366b348..de59f3302516 100644 --- a/drivers/gpu/drm/arm/malidp_drv.c +++ b/drivers/gpu/drm/arm/malidp_drv.c @@ -403,7 +403,6 @@ static int malidp_init(struct drm_device *drm) drm->mode_config.max_height = hwdev->max_line_size; drm->mode_config.funcs = &malidp_mode_config_funcs; drm->mode_config.helper_private = &malidp_mode_config_helpers; - drm->mode_config.allow_fb_modifiers = true; ret = malidp_crtc_init(drm); if (ret) -- 2.31.0

9 33

[PATCH 0/2 V6]Add dma-buf counter
by Peter Enderborg 20 Apr '21

20 Apr '21

The dma-buf counter is a metric for mapped memory used by it's clients. It is a shared buffer that is typically used for interprocess communication or process to hardware communication. In android we used to have ION,. but it is now replaced with dma-buf. ION had some overview metrics that was similar. V1 initial version. Add dma-buf counter V2 Fix build depencendy error suggested by Matthew Wilcox Extent commit message sugged by Köning V3 Change variable and function names. V4 Fix function name in code doc Reported-by: kernel test robot <lkp(a)intel.com> V5 Removed EXPORT_SYMBOL_GPL suggested by Muchun Song V6 Made it a patch set, Adding a addional patch for printing dma-buf counter in show_mem. Suggested by Michal Hocko.

2 3

[PATCH] efifb: Fix runtime pm calls for non PCI efifb device
by Sudeep Holla 20 Apr '21

20 Apr '21

Commit a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI D0") added runtime pm calls to probe and remove routines to ensure the PCI device for efifb stays in D0 state. However not ever efifb is based on PCI device and efifb_pci_dev can be NULL if that is the case. In such cases, we will get a boot splat like below due to NULL dereference: -->8 Console: switching to colour frame buffer device 240x67 fb0: EFI VGA frame buffer device Unable to handle kernel NULL pointer dereference at virtual address 0000000000000270 Mem abort info: ESR = 0x96000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 [0000000000000270] user address but active_mm is swapper Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc7-next-20210413 #1 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) pc : pm_runtime_drop_link+0x12c/0x338 lr : efifb_probe+0x7bc/0x7f0 Call trace: pm_runtime_drop_link+0x12c/0x338 efifb_probe+0x7bc/0x7f0 platform_probe+0x68/0xd8 really_probe+0xe4/0x3a8 driver_probe_device+0x64/0xc8 device_driver_attach+0x74/0x80 __driver_attach+0x64/0xf0 bus_for_each_dev+0x70/0xc0 driver_attach+0x24/0x30 bus_add_driver+0x150/0x1f8 driver_register+0x64/0x120 __platform_driver_register+0x28/0x38 efifb_driver_init+0x1c/0x28 do_one_initcall+0x48/0x2b0 kernel_init_freeable+0x1e8/0x258 kernel_init+0x14/0x118 ret_from_fork+0x10/0x30 Code: 88027c01 35ffffa2 17fff706 f9800051 (885f7c40) ---[ end trace 17d8da630bf8ff77 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b -->8 Fix the issue by checking for non-NULL efifb_pci_dev before dereferencing for runtime pm calls in probe and remove routines. Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI D0") Cc: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Peter Jones <pjones(a)redhat.com> Signed-off-by: Sudeep Holla <sudeep.holla(a)arm.com> --- drivers/video/fbdev/efifb.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c index f58a545b3bf3..8ea8f079cde2 100644 --- a/drivers/video/fbdev/efifb.c +++ b/drivers/video/fbdev/efifb.c @@ -575,7 +575,8 @@ static int efifb_probe(struct platform_device *dev) goto err_fb_dealoc; } fb_info(info, "%s frame buffer device\n", info->fix.id); - pm_runtime_get_sync(&efifb_pci_dev->dev); + if (efifb_pci_dev) + pm_runtime_get_sync(&efifb_pci_dev->dev); return 0; err_fb_dealoc: @@ -602,7 +603,8 @@ static int efifb_remove(struct platform_device *pdev) unregister_framebuffer(info); sysfs_remove_groups(&pdev->dev.kobj, efifb_groups); framebuffer_release(info); - pm_runtime_put(&efifb_pci_dev->dev); + if (efifb_pci_dev) + pm_runtime_put(&efifb_pci_dev->dev); return 0; } -- 2.25.1

2 3

[v1 0/3] drm: Add support for backlight control of eDP panel on ti-sn65dsi86 bridge
by Rajeev Nandan 20 Apr '21

20 Apr '21

The backlight level of an eDP panel can be controlled through the AUX channel using DPCD registers of the panel. The capability for the Source device to adjust backlight characteristics within the panel, using the Sink device DPCD registers is indicated by the TCON_BACKLIGHT_ADJUSTMENT_CAPABLE bit in the EDP_GENERAL_CAPABILITY_1 register (DPCD Address 701h, bit0). In this configuration, the eDP TCON receives the backlight level information from the host, through the AUX channel. The changes in this patch series do the following: - Add drm_dp_aux_backlight_ APIs to support backlight control using DPCD registers on the DisplayPort AUX channel. The current version only supports backlight brightness control by the EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB registers (DPCD Addresses 722h-723h). - Add support for backlight control of the eDP panel connected to the ti-sn65dsi86 bridge. Rajeev Nandan (3): drm/dp: Add DisplayPort aux backlight control support dt-bindings: drm/bridge: ti-sn65dsi86: Document use-aux-backlight drm/bridge: ti-sn65dsi86: Add DisplayPort aux backlight support .../bindings/display/bridge/ti,sn65dsi86.yaml | 8 + drivers/gpu/drm/Kconfig | 8 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/bridge/Kconfig | 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 26 +++ drivers/gpu/drm/drm_dp_aux_backlight.c | 191 +++++++++++++++++++++ include/drm/drm_dp_aux_backlight.h | 29 ++++ 7 files changed, 264 insertions(+) create mode 100644 drivers/gpu/drm/drm_dp_aux_backlight.c create mode 100644 include/drm/drm_dp_aux_backlight.h -- 2.7.4

4 6

[PATCH] drm/panel: lvds: Drop unnecessary NULL pointer checks for lvds->enable_gpio
by Liu Ying 20 Apr '21

20 Apr '21

gpiod_set_value_cansleep() does NULL pointer check for passed in gpio descriptor's pointer, so it's unnecessary to do that check before calling that function. This patch drops those checks from this panel driver. Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> 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> Signed-off-by: Liu Ying <victor.liu(a)nxp.com> --- drivers/gpu/drm/panel/panel-lvds.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-lvds.c b/drivers/gpu/drm/panel/panel-lvds.c index 59a8d99..19f11fa 100644 --- a/drivers/gpu/drm/panel/panel-lvds.c +++ b/drivers/gpu/drm/panel/panel-lvds.c @@ -50,8 +50,7 @@ static int panel_lvds_unprepare(struct drm_panel *panel) { struct panel_lvds *lvds = to_panel_lvds(panel); - if (lvds->enable_gpio) - gpiod_set_value_cansleep(lvds->enable_gpio, 0); + gpiod_set_value_cansleep(lvds->enable_gpio, 0); if (lvds->supply) regulator_disable(lvds->supply); @@ -74,8 +73,7 @@ static int panel_lvds_prepare(struct drm_panel *panel) } } - if (lvds->enable_gpio) - gpiod_set_value_cansleep(lvds->enable_gpio, 1); + gpiod_set_value_cansleep(lvds->enable_gpio, 1); return 0; } -- 2.7.4

1 0

[PATCH] video: fbdev: sm501fb: Fix deallocation of buffers order
by Aditya Pakki 20 Apr '21

20 Apr '21

The resource release in sm501fb_remove() is not in the inverse order of sm501fb_probe(), for the buffers. Release the info object after deallocating the buffers. Signed-off-by: Aditya Pakki <pakki001(a)umn.edu> --- drivers/video/fbdev/sm501fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c index 6a52eba64559..4c32c9e88850 100644 --- a/drivers/video/fbdev/sm501fb.c +++ b/drivers/video/fbdev/sm501fb.c @@ -2060,11 +2060,11 @@ static int sm501fb_remove(struct platform_device *pdev) unregister_framebuffer(fbinfo_pnl); sm501fb_stop(info); - kfree(info); framebuffer_release(fbinfo_pnl); framebuffer_release(fbinfo_crt); + kfree(info); return 0; } -- 2.25.1

2 1

[Bug 212729] New: amdgpu: WARN_ON drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:119 set_reg_field_values.constprop.0+0xbe/0xe0
by bugzilla-daemon＠bugzilla.kernel.org 20 Apr '21

20 Apr '21

https://bugzilla.kernel.org/show_bug.cgi?id=212729 Bug ID: 212729 Summary: amdgpu: WARN_ON drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:1 19 set_reg_field_values.constprop.0+0xbe/0xe0 Product: Drivers Version: 2.5 Kernel Version: 5.11.14-200.fc33.x86_64 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: benh(a)kernel.crashing.org Regression: No Created attachment 296437 --> https://bugzilla.kernel.org/attachment.cgi?id=296437&action=edit Full kernel log On Fedora 33, I recently started getting these (I haven't had a chance to bisect). Note the error that happens shortly before the WARN_ON as it might be relevant. This seem to go along with the screen occasionally not coming back from blanking when the machine is left idle. Sometimes unplugging/replugging the DP connector works, sometimes it doesn't. I *think* it's related but I'm not 100% certain. The GPU is a 6800XT. [ 4.361992] [drm] Initialized amdgpu 3.40.0 20150101 for 0000:0d:00.0 on minor 0 [ 4.668196] [drm] REG_WAIT timeout 1us * 100000 tries - mpc2_assert_idle_mpcc line:480 [ 4.800700] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none. [ 4.844273] ------------[ cut here ]------------ [ 4.844274] WARNING: CPU: 7 PID: 504 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:119 set_reg_field_values.constprop.0+0xbe/0xe0 [amdgpu] [ 4.844400] Modules linked in: amdgpu drm_ttm_helper ttm iommu_v2 gpu_sched drm_kms_helper cec crct10dif_pclmul crc32_pclmul crc32c_intel drm ghash_clmulni_intel igb ccp nvme r8169 nvme_core dca i2c_algo_bit wmi pinctrl_amd fuse [ 4.844410] CPU: 7 PID: 504 Comm: plymouthd Not tainted 5.11.14-200.fc33.x86_64 #1 [ 4.844412] Hardware name: System manufacturer System Product Name/ROG STRIX X570-E GAMING, BIOS 3603 03/19/2021 [ 4.844413] RIP: 0010:set_reg_field_values.constprop.0+0xbe/0xe0 [amdgpu] [ 4.844525] Code: 50 08 49 89 51 08 8b 08 48 8d 42 08 49 89 41 08 44 8b 02 48 8d 50 08 0f b6 c9 49 89 51 08 8b 00 45 85 c0 75 b5 0f 0b eb b1 c3 <0f> 0b e9 4d ff ff ff 49 8b 51 08 eb d1 49 8b 41 08 eb d6 66 66 2e [ 4.844526] RSP: 0018:ffffc0af00d377a0 EFLAGS: 00010246 [ 4.844528] RAX: 0000000000000000 RBX: ffffa078d4de0000 RCX: 0000000000000000 [ 4.844528] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffc0af00d377a8 [ 4.844529] RBP: ffffc0af00d37820 R08: 0000000000000001 R09: ffffc0af00d377b0 [ 4.844530] R10: 0000000000000000 R11: 00000000000039e8 R12: 0000000000000005 [ 4.844531] R13: ffffa078d80e1740 R14: 0000000000003ae0 R15: ffffa078d9bc01e8 [ 4.844532] FS: 00007fbf4f575f40(0000) GS:ffffa07fcebc0000(0000) knlGS:0000000000000000 [ 4.844533] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4.844534] CR2: 00007fd50a00d000 CR3: 0000000110d6c000 CR4: 0000000000350ee0 [ 4.844535] Call Trace: [ 4.844537] generic_reg_update_ex+0x5a/0x1c0 [amdgpu] [ 4.844646] ? dcn20_enable_plane+0x77/0x1e0 [amdgpu] [ 4.844769] dcn20_program_front_end_for_ctx+0x997/0xb20 [amdgpu] [ 4.844888] ? optc3_lock+0x9d/0xb0 [amdgpu] [ 4.845004] dc_commit_state+0x49a/0xa30 [amdgpu] [ 4.845117] ? drm_calc_timestamping_constants+0x195/0x1f0 [drm] [ 4.845135] amdgpu_dm_atomic_commit_tail+0x585/0x2600 [amdgpu] [ 4.845253] ? amdgpu_vm_bo_invalidate+0x83/0x1a0 [amdgpu] [ 4.845345] ? amdgpu_bo_move_notify+0x41/0xe0 [amdgpu] [ 4.845434] ? amdgpu_bo_move+0x2d1/0x6d0 [amdgpu] [ 4.845522] ? ttm_bo_handle_move_mem+0x90/0x180 [ttm] [ 4.845526] ? ttm_bo_validate+0x11b/0x150 [ttm] [ 4.845529] ? dm_plane_helper_prepare_fb+0x18c/0x220 [amdgpu] [ 4.845644] ? _cond_resched+0x16/0x40 [ 4.845647] ? _cond_resched+0x16/0x40 [ 4.845648] ? __wait_for_common+0x2b/0x140 [ 4.845650] commit_tail+0x94/0x130 [drm_kms_helper] [ 4.845661] drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] [ 4.845669] drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper] [ 4.845678] drm_mode_setcrtc+0x1d3/0x6f0 [drm] [ 4.845695] ? avc_has_extended_perms+0x18d/0x3e0 [ 4.845698] ? drm_mode_getcrtc+0x180/0x180 [drm] [ 4.845712] drm_ioctl_kernel+0x86/0xd0 [drm] [ 4.845730] drm_ioctl+0x20f/0x3a0 [drm] [ 4.845745] ? drm_mode_getcrtc+0x180/0x180 [drm] [ 4.845760] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] [ 4.845848] __x64_sys_ioctl+0x83/0xb0 [ 4.845850] do_syscall_64+0x33/0x40 [ 4.845853] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 4.845855] RIP: 0033:0x7fbf4f8315db [ 4.845856] Code: 89 d8 49 8d 3c 1c 48 f7 d8 49 39 c4 72 b5 e8 1c ff ff ff 85 c0 78 ba 4c 89 e0 5b 5d 41 5c c3 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 6d b8 0c 00 f7 d8 64 89 01 48 [ 4.845857] RSP: 002b:00007ffd798377a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 4.845859] RAX: ffffffffffffffda RBX: 00007ffd798377e0 RCX: 00007fbf4f8315db [ 4.845859] RDX: 00007ffd798377e0 RSI: 00000000c06864a2 RDI: 0000000000000009 [ 4.845860] RBP: 00000000c06864a2 R08: 0000000000000000 R09: 000055ca4a0613a0 [ 4.845861] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000078 [ 4.845862] R13: 0000000000000009 R14: 000055ca4a060ba0 R15: 000055ca4a060be0 [ 4.845863] ---[ end trace 4f5aa763b893d28a ]--- -- 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 0

[PATCH] drm/msm/dsi: dsi_phy_28nm_8960: fix uninitialized variable access
by Dmitry Baryshkov 19 Apr '21

19 Apr '21

The parent_name initialization was lost in refactoring, restore it now. Fixes: 5d13459650b3 ("drm/msm/dsi: push provided clocks handling into a generic code") Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> --- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c index 582b1428f971..86e40a0d41a3 100644 --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c @@ -405,6 +405,10 @@ static int pll_28nm_register(struct dsi_pll_28nm *pll_28nm, struct clk_hw **prov if (!vco_name) return -ENOMEM; + parent_name = devm_kzalloc(dev, 32, GFP_KERNEL); + if (!parent_name) + return -ENOMEM; + clk_name = devm_kzalloc(dev, 32, GFP_KERNEL); if (!clk_name) return -ENOMEM; -- 2.30.2

2 1

[PATCH] drm/nouveau: fix an error code in nouveau_backlight_init()
by Dan Carpenter 19 Apr '21

19 Apr '21

If nouveau_get_backlight_name() fails then this should return -ENOMEM but currently it returns success. Fixes: db1a0ae21461 ("drm/nouveau/bl: Assign different names to interfaces") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- This is from static analysis. In the original commit db1a0ae21461 ("drm/nouveau/bl: Assign different names to interfaces") then returning zero seemed to be a very deliberate choice. I do think it was wrong though and -ENOMEM is the currect return. drivers/gpu/drm/nouveau/nouveau_backlight.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c b/drivers/gpu/drm/nouveau/nouveau_backlight.c index 72f35a2babcb..3786b1c85182 100644 --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c @@ -274,6 +274,7 @@ nouveau_backlight_init(struct drm_connector *connector) if (!nouveau_get_backlight_name(backlight_name, bl)) { NV_ERROR(drm, "Failed to retrieve a unique name for the backlight interface\n"); + ret = -ENOMEM; goto fail_alloc; } -- 2.30.2

2 1

← Newer
1
...
37
38
39
40
41
42
43
...
72
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2021