[PATCH] drm/nouveau/hwmon: Convert sysfs sprintf/snprintf family to sysfs_emit

Fix the following coccicheck warning: drivers/gpu/drm/nouveau/nouveau_hwmon.c:44:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/nouveau/nouveau_hwmon.c:57:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/nouveau/nouveau_hwmon.c:90:8-16: WARNING: use scnprintf or sprintf

[PATCH] drm/panel: panel-dsi-cm: Convert sysfs sprintf/snprintf family to sysfs_emit

Fix the following coccicheck warning: drivers/gpu/drm/panel/panel-dsi-cm.c:271:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/panel/panel-dsi-cm.c:251:8-16: WARNING: use scnprintf or sprintf Signed-off-by: Tian Tao --- drivers/gpu/drm/panel/panel-dsi-cm.c | 4 ++-- 1 file changed, 2

Request for assistance

Greetings I'm running a Debian testing (11) system using Nouveau as a driver for 2 graphics cards: 1. Nvidia 1050 Ti (GP107) and a Nvidia 570 (GF110) driving 5 monitors 1 - 3840x2160 and 4 - 1920x1080s. The 5th monitor was added some about 8 weeks ago and since life got interesting. Previously I

[pull] drm/msm: drm-msm-next for 5.13

Hi Dave, This time around a bit larger than usual, but a large part of that is Dmitry's dsi phy/pll refactor (which is itself a pretty large negative diffstat). The dsi phy/pll refactor includes a couple clk patches a-b the maintainer. (For folks actually trying to boot msm-next, there is one

[PATCH v1 1/3] drm/msm/dpu: merge dpu_hw_intr_get_interrupt_statuses into dpu_hw_intr_dispatch_irqs

There is little sense in reading interrupt statuses and right after that going after the array of statuses to dispatch them. Merge both loops into single function doing read and dispatch. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 10 +--

[PATCH v1 3/3] drm/msm/dpu: simplify interrupt managing

Change huge lookup table to contain just sensible entries. IRQ index is now not an index in the table, but just register id (multiplied by 32, the amount of IRQs in the register) plus offset in the register. This allows us to remove all the "reserved" entries from dpu_irq_map. The table is now

[PATCH v1 2/3] drm/msm/dpu: hw_intr: always call dpu_hw_intr_clear_intr_status_nolock

Always call dpu_hw_intr_clear_intr_status_nolock() from the dpu_hw_intr_dispatch_irqs(). This simplifies the callback function (which call clears the interrupts anyway) and enforces clearing the hw interrupt status. Signed-off-by: Dmitry Baryshkov ---

[PATCH v1 0/3] drm/msm/dpu: rework irq handling

Simplify IRQ handling. dpu_irq_map is a huge table consisting of all possible IRQ entries (including a plenty of 'reserved' = not existing IRQs). It is always used to lookup the interrupt index (in the table) and then to use this index to lookup related interrupt register and mask. For the long

[PATCH] drm/msm/dsi: fix msm_dsi_phy_get_clk_provider return code

msm_dsi_phy_get_clk_provider() always returns two provided clocks, so return 0 instead of returning incorrect -EINVAL error code. Fixes: 5d13459650b3 ("drm/msm/dsi: push provided clocks handling into a generic code") Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2

Re: [PATCH] vt_ioctl: make VT_RESIZEX behave like VT_RESIZE

On Sun, Apr 11, 2021 at 2:43 PM Maciej W. Rozycki wrote: > > So it does trigger with vgacon and my old server, which I have started > experimenting with and for a start I have switched to a new kernel for an > unrelated purpose (now that I have relieved it from all its usual tasks > except for

Re: [syzbot] general protection fault in drm_client_buffer_vunmap

syzbot suspects this issue was fixed by commit: commit 874a52f9b693ed8bf7a92b3592a547ce8a684e6f Author: Tong Zhang Date: Sun Feb 28 04:46:25 2021 + drm/fb-helper: only unmap if buffer not null bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10c27b7ed0 start commit:

Re: [syzbot] general protection fault in drm_client_buffer_vunmap

#syz fix: drm/fb-helper: only unmap if buffer not null Am 11.04.21 um 14:01 schrieb syzbot: #syz fix: drm/fb-helper: only unmap if buffer not null -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG