aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-11-17fbcon: Drop EXPORT_SYMBOLDaniel Vetter7-11/+0
Every since commit 6104c37094e729f3d4ce65797002112735d49cd1 Author: Daniel Vetter <[email protected]> Date: Tue Aug 1 17:32:07 2017 +0200 fbcon: Make fbcon a built-time depency for fbdev these are no longer distinct loadable modules, so exporting symbols is kinda pointless. Acked-by: Thomas Zimmermann <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Jiri Slaby <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Tetsuo Handa <[email protected]> Cc: Helge Deller <[email protected]> Cc: Peilin Ye <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-17fbcon: Disable accelerated scrollingDaniel Vetter2-37/+26
So ever since syzbot discovered fbcon, we have solid proof that it's full of bugs. And often the solution is to just delete code and remove features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code"). Now the problem is that most modern-ish drivers really only treat fbcon as an dumb kernel console until userspace takes over, and Oops printer for some emergencies. Looking at drm drivers and the basic vesa/efi fbdev drivers shows that only 3 drivers support any kind of acceleration: - nouveau, seems to be enabled by default - omapdrm, when a DMM remapper exists using remapper rewriting for y/xpanning - gma500, but that is getting deleted now for the GTT remapper trick, and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA flag, so unused (and could be deleted already I think). No other driver supportes accelerated fbcon. And fbcon is the only user of this accel code (it's not exposed as uapi through ioctls), which means we could garbage collect fairly enormous amounts of code if we kill this. Plus because syzbot only runs on virtual hardware, and none of the drivers for that have acceleration, we'd remove a huge gap in testing. And there's no other even remotely comprehensive testing aside from syzbot. This patch here just disables the acceleration code by always redrawing when scrolling. The plan is that once this has been merged for well over a year in released kernels, we can start to go around and delete a lot of code. v2: - Drop a few more unused local variables, somehow I missed the compiler warnings (Sam) - Fix typo in comment (Jiri) - add a todo entry for the cleanup (Thomas) v3: Remove more unused variables (0day) Reviewed-by: Tomi Valkeinen <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Jiri Slaby <[email protected]> Cc: Bartlomiej Zolnierkiewicz <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Ben Skeggs <[email protected]> Cc: [email protected] Cc: Tomi Valkeinen <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jiri Slaby <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Cc: Tetsuo Handa <[email protected]> Cc: Peilin Ye <[email protected]> Cc: George Kennedy <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Peter Rosin <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-17video: fbdev: atmel_lcdfb: fix return error code in atmel_lcdfb_of_init()Yang Yingliang1-1/+1
If devm_kzalloc() failed after the first time, atmel_lcdfb_of_init() can't return -ENOMEM, fix this by putting the error code in loop. Fixes: b985172b328a ("video: atmel_lcdfb: add device tree suport") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Yang Yingliang <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-16drm: fix some kernel-doc markupsMauro Carvalho Chehab20-28/+32
Some identifiers have different names between their prototypes and the kernel-doc markup. Others need to be fixed, as kernel-doc markups should use this format: identifier - description Signed-off-by: Mauro Carvalho Chehab <[email protected]> Acked-by: Jani Nikula <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/12d4ca26f6843618200529ce5445063734d38c04.1605521731.git.mchehab+huawei@kernel.org
2020-11-16video: fix some kernel-doc markupsMauro Carvalho Chehab2-2/+3
Some identifiers have different names between their prototypes and the kernel-doc markup. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/21661aed9892a1bacc7ef76a5dc9f5c7b37f5d8f.1605521731.git.mchehab+huawei@kernel.org
2020-11-16fbcon: Avoid using FNTCHARCNT() and hard-coded built-in font charcountPeilin Ye3-41/+23
For user-provided fonts, the framebuffer layer is using a magic negative-indexing macro, FNTCHARCNT(), to keep track of their number of characters: #define FNTCHARCNT(fd) (((int *)(fd))[-3]) For built-in fonts, it is using hard-coded values (256). This results in something like the following: map.length = (ops->p->userfont) ? FNTCHARCNT(ops->p->fontdata) : 256; This is unsatisfactory. In fact, there is already a `charcount` field in our virtual console descriptor (see `struct console_font` inside `struct vc_data`), let us use it: map.length = vc->vc_font.charcount; Recently we added a `charcount` field to `struct font_desc`. Use it to set `vc->vc_font.charcount` properly. The idea is: - We only use FNTCHARCNT() on `vc->vc_font.data` and `p->fontdata`. Assume FNTCHARCNT() is working as intended; - Whenever `vc->vc_font.data` is set, also set `vc->vc_font.charcount` properly; - We can now replace `FNTCHARCNT(vc->vc_font.data)` with `vc->vc_font.charcount`; - Since `p->fontdata` always point to the same font data buffer with `vc->vc_font.data`, we can also replace `FNTCHARCNT(p->fontdata)` with `vc->vc_font.charcount`. In conclusion, set `vc->vc_font.charcount` properly in fbcon_startup(), fbcon_init(), fbcon_set_disp() and fbcon_do_set_font(), then replace FNTCHARCNT() with `vc->vc_font.charcount`. No more if-else between negative-indexing macros and hard-coded values. Do not include <linux/font.h> in fbcon_rotate.c and tileblit.c, since they no longer need it. Depends on patch "Fonts: Add charcount field to font_desc". Suggested-by: Daniel Vetter <[email protected]> Signed-off-by: Peilin Ye <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/e460a5780e54e3022661d5f09555144583b4cc59.1605169912.git.yepeilin.cs@gmail.com
2020-11-16parisc/sticore: Avoid hard-coding built-in font charcountPeilin Ye1-4/+4
sti_select_fbfont() and sti_cook_fonts() are hard-coding the number of characters of our built-in fonts as 256. Recently, we included that information in our kernel font descriptor `struct font_desc`, so use `fbfont->charcount` instead of hard-coded values. Depends on patch "Fonts: Add charcount field to font_desc". Signed-off-by: Peilin Ye <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/037186fb50cf3d17bb7bc9482357635b9df6076e.1605169912.git.yepeilin.cs@gmail.com
2020-11-16Fonts: Add charcount field to font_descPeilin Ye14-0/+14
Subsystems are hard-coding the number of characters of our built-in fonts as 256. Include that information in our kernel font descriptor, `struct font_desc`. Signed-off-by: Peilin Ye <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/65952296d1d9486093bd955d1536f7dcd11112c6.1605169912.git.yepeilin.cs@gmail.com
2020-11-16console: Delete dummy con_font_set() and con_font_default() callback ↵Peilin Ye2-29/+0
implementations .con_font_set and .con_font_default callbacks should not pass `struct console_font *` as a parameter, since `struct console_font` is a UAPI structure. We are trying to let them use our new kernel font descriptor, `struct font_desc` instead. To make that work slightly easier, first delete all of their no-op implementations used by dummy consoles. This will make KD_FONT_OP_SET and KD_FONT_OP_SET_DEFAULT ioctl() requests on dummy consoles start to fail and return `-ENOSYS`, which is intended, since no user should ever expect such operations to succeed on dummy consoles. Suggested-by: Daniel Vetter <[email protected]> Signed-off-by: Peilin Ye <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/9952c7538d2a32bb1a82af323be482e7afb3dedf.1605169912.git.yepeilin.cs@gmail.com
2020-11-16console: Delete unused con_font_copy() callback implementationsPeilin Ye5-25/+1
Recently in commit 3c4e0dff2095 ("vt: Disable KD_FONT_OP_COPY") we disabled the KD_FONT_OP_COPY ioctl() option. Delete all the con_font_copy() callbacks, since we no longer use them. Mark KD_FONT_OP_COPY as "obsolete" in include/uapi/linux/kd.h, just like what we have done for PPPIOCDETACH in commit af8d3c7c001a ("ppp: remove the PPPIOCDETACH ioctl"). Signed-off-by: Peilin Ye <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/c8d28007edf50de4387e1532eb3eb736db716f73.1605169912.git.yepeilin.cs@gmail.com
2020-11-16drm/panfrost: Move the GPU reset bits outside the timeout handlerBoris Brezillon3-64/+130
We've fixed many races in panfrost_job_timedout() but some remain. Instead of trying to fix it again, let's simplify the logic and move the reset bits to a separate work scheduled when one of the queue reports a timeout. v5: - Simplify panfrost_scheduler_stop() (Steven Price) - Always restart the queue in panfrost_scheduler_start() even if the status is corrupted (Steven Price) v4: - Rework the logic to prevent a race between drm_sched_start() (reset work) and drm_sched_job_timedout() (timeout work) - Drop Steven's R-b - Add dma_fence annotation to the panfrost_reset() function (Daniel Vetter) v3: - Replace the atomic_cmpxchg() by an atomic_xchg() (Robin Murphy) - Add Steven's R-b v2: - Use atomic_cmpxchg() to conditionally schedule the reset work (Steven Price) Fixes: 1a11a88cfd9a ("drm/panfrost: Fix job timeout handling") Cc: <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Steven Price <[email protected]> Signed-off-by: Steven Price <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-16drm: fix oops in drm_atomic_set_crtc_for_connectorSimon Ser1-2/+2
crtc can be NULL. connector, extracted from conn_state, can't. Fixes: e3aae683e861 ("drm: convert drm_atomic_uapi.c to new debug helpers") Signed-off-by: Simon Ser <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Daniel Vetter <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-16drm/virtio: Make virtgpu_dmabuf_ops with static keywordZou Wei1-1/+1
Fix the following sparse warning: ./virtgpu_prime.c:46:33: warning: symbol 'virtgpu_dmabuf_ops' was not declared. Should it be static? Signed-off-by: Zou Wei <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Gerd Hoffmann <[email protected]>
2020-11-16drm/lima: Unconditionally call dev_pm_opp_of_remove_table()Viresh Kumar2-6/+1
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to find the OPP table with error -ENODEV (i.e. OPP table not present for the device). And we can call dev_pm_opp_of_remove_table() unconditionally here. Reviewed-by: Qiang Yu <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/c995335d16d8b4b4ff47b1273869c33e14782b32.1603867405.git.viresh.kumar@linaro.org
2020-11-16drm/lima/lima_sched: Remove unused and unnecessary variable 'ret'Lee Jones1-2/+1
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/lima/lima_sched.c: In function ‘lima_sched_run_job’: drivers/gpu/drm/lima/lima_sched.c:227:20: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] Cc: Qiang Yu <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Sumit Semwal <[email protected]> Cc: "Christian König" <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-16drm/lima/lima_drv: Demote kernel-doc formatting abuseLee Jones1-1/+1
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/lima/lima_drv.c:264: warning: cannot understand function prototype: 'const struct drm_driver lima_drm_driver = ' Cc: Qiang Yu <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-16drm/lima: simplify the return expression of lima_devfreq_targetLiu Shixin1-6/+1
Simplify the return expression. Signed-off-by: Liu Shixin <[email protected]> Signed-off-by: Qiang Yu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-16drm/panel: s6e63m0: Set up some display infoLinus Walleij1-0/+9
Copy over the width/height in millimeters to the (somewhat redundant) display info, and set up the bus format and bus flags for the display. When used as DPI this display requires DE to be active low and pixel data to be output on the negative edge. It might be that it was previously used with a display controller that either does not support these settings or was hardcoded to use these as default. This information comes from the source code of the Samsung GT-I9070 mobile phone. Signed-off-by: Linus Walleij <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Stephan Gerhold <[email protected]> Cc: Paweł Chmiel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-16drm/panel: s6e63m0: Support 3WIRE protocolLinus Walleij1-1/+2
The panel can be connected using 3WIRE, then it is however necessary that the flag SPI_3WIRE is preserved on the device, as we set this from generic device tree parsing code (or similar). Just |= the SPI mode. Signed-off-by: Linus Walleij <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Stephan Gerhold <[email protected]> Cc: Paweł Chmiel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-16drm/panel: s6e63m0: Add some explanationsLinus Walleij1-0/+7
The SPI DCS code was a bit hard to understand as the device accepts 9-bit transfers packed into 16-bit words with the most significant bit in bit 9 of the 16-bit word. Add some clarifying comments. Signed-off-by: Linus Walleij <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Stephan Gerhold <[email protected]> Cc: Paweł Chmiel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-16drm/panel: s6e63m0: Implement reading from panelLinus Walleij1-6/+13
This code was found in the Samsung vendor tree for the Samsung GT-I9070 mobile phone. Let's support reading before we implement the 3WIRE protocol for both reading and writing. Signed-off-by: Linus Walleij <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Stephan Gerhold <[email protected]> Cc: Paweł Chmiel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-16drm/panel: s6e63m0: Simplify SPI writingLinus Walleij1-9/+2
This writing code is equivalent to the spi_write() helper in the SPI framework. Insert a comment that this will always work fine since SPI buffers are in native endianness. Signed-off-by: Linus Walleij <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Stephan Gerhold <[email protected]> Cc: Paweł Chmiel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-15drm/gma500: Remove 2D accel codePatrik Jakobsson8-319/+1
2D acceleration is only available on PSB and MRST and very slow on both platforms. CPU acceleration is faster so don't bother with 2D accel anymore. Signed-off-by: Patrik Jakobsson <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-15drm/gma500: Remove GTT roll supportPatrik Jakobsson3-137/+14
GTT roll support was used to accelerate fb panning on some machines. Unfortunately this never worked properly with multiple monitors and caused issues on others where the framebuffer wouldn't fit in stolen memory. Let's remove it! Signed-off-by: Patrik Jakobsson <[email protected]> Acked-by: Daniel Vetter <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-14drm/panel/samsung-sofef00: Add panel for OnePlus 6/T devicesCaleb Connolly3-0/+364
The OnePlus 6/T devices use different panels however they are functionally identical with the only differences being the resolution. The panels also don't seem to be used by any other devices, just combine them into one driver. The panels are: samsung,sofef00 and samsung,s6e3fc2x01 Signed-off-by: Caleb Connolly <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> [fixed checkpatch warnings] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-14dt-bindings: panel-simple-dsi: add samsung panels for OnePlus 6/TCaleb Connolly1-0/+4
Add compatibles for the samsung,sofef00 and samsung,s6e3fc2x01 panels used in the OnePlus 6 & 6T respectively. Signed-off-by: Caleb Connolly <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-14drm/panel/panel-tpo-tpg110: Correct misnaming and supply missing param ↵Lee Jones1-1/+2
description Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/panel/panel-tpo-tpg110.c:94: warning: Function parameter or member 'panel_mode' not described in 'tpg110' drivers/gpu/drm/panel/panel-tpo-tpg110.c:372: warning: Function parameter or member 'connector' not described in 'tpg110_get_modes' Cc: Linus Walleij <[email protected]> Cc: Thierry Reding <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-14drm: add debug logs for drm_mode_atomic_ioctl errorsSimon Ser1-5/+18
Be nice to user-space and log what happened when returning EINVAL in drm_mode_atomic_ioctl. v2: - Migrate to drm_dbg_atomic (Sam) - Add debug log for arg->reserved (Ville) - Drop redundant "atomic" word in log messages (Ville) Signed-off-by: Simon Ser <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Ville Syrjala <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-14drm: convert drm_atomic_uapi.c to new debug helpersSimon Ser1-47/+66
Migrate from DRM_DEBUG_ATOMIC to drm_dbg_atomic. Signed-off-by: Simon Ser <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Ville Syrjala <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-13drm/ttm: fix missing NULL check in the new page poolChristian König1-1/+1
The pool parameter can be NULL if we free through the shrinker. Signed-off-by: Christian König <[email protected]> Acked-by: Alex Deucher <[email protected]> Tested-by: Martin Peres <[email protected]> Acked-by: Martin Peres <[email protected]> Reported-by: Andy Lavr <[email protected]> Tested-by: Andy Lavr <[email protected]> Link: https://patchwork.freedesktop.org/patch/399365/
2020-11-13drm/udl: Fix missing error code in udl_handle_damage()Dan Carpenter1-1/+3
If udl_get_urb() fails then this should return a negative error code but currently it returns success. Fixes: 798ce3fe1c3a ("drm/udl: Begin/end access to imported buffers in damage-handler") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20201113101502.GD168908@mwanda
2020-11-12drm/via/via_dma: Remove set but unused variable 'agp_base'Lee Jones1-2/+0
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/via/via_dma.c: In function ‘via_cmdbuf_jump’: drivers/gpu/drm/via/via_dma.c:596:11: warning: variable ‘agp_base’ set but not used [-Wunused-but-set-variable] Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-12drm/sti/sti_hdmi: Move 'colorspace_mode_names' array to where its usedLee Jones2-6/+6
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/sti/sti_hdmi.h:36:40: warning: ‘colorspace_mode_names’ defined but not used [-Wunused-const-variable=] 36 | static const struct drm_prop_enum_list colorspace_mode_names[] = { | ^~~~~~~~~~~~~~~~~~~~~ Cc: Benjamin Gaignard <[email protected]> Cc: Vincent Abriou <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Philipp Zabel <[email protected]> Cc: [email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-12include: drm: drm_atomic: Artificially use 'crtc' to avoid 'not used' warningLee Jones1-0/+1
The precedent has already been set by other macros in the same file. Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vkms/vkms_drv.c:55:19: warning: variable ‘crtc’ set but not used [-Wunused-but-set-variable] 55 | struct drm_crtc *crtc; | ^~~~ Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Rob Clark <[email protected]> Cc: [email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-12drm/savage/savage_bci: Remove set but never used 'aper_rsrc' and 'fb_rsrc'Lee Jones1-11/+0
The comment about them (also removed) says: /* fb_rsrc and aper_rsrc aren't really used currently, but still exist * in case we decide we need information on the BAR for BSD in the * future. */ Well that was written 12 years ago in 2008. We are now in the future and they are still superfluous. We can always add them again at a later date if they are ever required. Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/savage/savage_bci.c: In function ‘savage_driver_firstopen’: drivers/gpu/drm/savage/savage_bci.c:580:24: warning: variable ‘aper_rsrc’ set but not used [-Wunused-but-set-variable] drivers/gpu/drm/savage/savage_bci.c:580:15: warning: variable ‘fb_rsrc’ set but not used [-Wunused-but-set-variable] Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-12drm/atmel-hlcdc/atmel_hlcdc_plane: Fix documentation formatting and add ↵Lee Jones1-1/+2
missing description Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c:283:6: warning: no previous prototype for ‘atmel_hlcdc_plane_setup_scaler’ [-Wmissing-prototypes] drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c:44: warning: cannot understand function prototype: 'struct atmel_hlcdc_plane_state ' Cc: Sam Ravnborg <[email protected]> Cc: Boris Brezillon <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Nicolas Ferre <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Ludovic Desroches <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-12drm/atmel-hlcdc/atmel_hlcdc_plane: Staticise local function ↵Lee Jones1-2/+2
'atmel_hlcdc_plane_setup_scaler()' Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c:283:6: warning: no previous prototype for ‘atmel_hlcdc_plane_setup_scaler’ [-Wmissing-prototypes] Cc: Sam Ravnborg <[email protected]> Cc: Boris Brezillon <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Nicolas Ferre <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Ludovic Desroches <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-12drm/atmel-hlcdc/atmel_hlcdc_crtc: Apply correct formatting to struct docsLee Jones1-3/+3
And fix-up a misnamed member description. Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c:33: warning: cannot understand function prototype: 'struct atmel_hlcdc_crtc_state ' drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c:52: warning: cannot understand function prototype: 'struct atmel_hlcdc_crtc ' Cc: Sam Ravnborg <[email protected]> Cc: Boris Brezillon <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Nicolas Ferre <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Ludovic Desroches <[email protected]> Cc: Jean-Jacques Hiblot <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-11drm/kmb: fix spelling mistakes in drm_info and drm_dbg messagesColin Ian King1-2/+2
There are two spelling mistakes of the word sync in drm_info and drm_dbg messages. Fix these. Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-11drm/kmb: Fix build warningsAnitha Chrisanthus2-32/+32
Fixed the following W=1 kernel build warnings drivers/gpu/drm/kmb/kmb_plane.h:74:18: warning: ‘kmb_formats_v’ defined but not used [-Wunused-const-variable=] drivers/gpu/drm/kmb/kmb_plane.h:61:18: warning: ‘kmb_formats_g’ defined but not used [-Wunused-const-variable=] Signed-off-by: Anitha Chrisanthus <[email protected]> Cc: Sam Ravnborg <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-11drm/nouveau: Fix out-of-bounds access when deferencing MMU typeThomas Zimmermann1-1/+4
The value of struct drm_device.ttm.type_vram can become -1 for unknown types of memory (see nouveau_ttm_init()). This leads to an out-of-bounds error when accessing struct nvif_mmu.type[]: [ 18.304116] ================================================================== [ 18.311649] BUG: KASAN: slab-out-of-bounds in nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau] [ 18.320415] Read of size 1 at addr ffff88810ffac1fe by task systemd-udevd/342 [ 18.327681] [ 18.329208] CPU: 1 PID: 342 Comm: systemd-udevd Tainted: G E 5.10.0-rc2-1-default+ #581 [ 18.338681] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS A24 10/24/2018 [ 18.346032] Call Trace: [ 18.348536] dump_stack+0xae/0xe5 [ 18.351919] print_address_description.constprop.0+0x17/0xf0 [ 18.357787] ? nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau] [ 18.363818] __kasan_report.cold+0x20/0x38 [ 18.368099] ? nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau] [ 18.374133] kasan_report+0x3a/0x50 [ 18.377789] nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau] <...> [ 18.767690] Allocated by task 342: [ 18.773087] kasan_save_stack+0x1b/0x40 [ 18.778890] __kasan_kmalloc.constprop.0+0xbf/0xd0 [ 18.785646] __kmalloc_track_caller+0x1be/0x390 [ 18.792165] kstrdup_const+0x46/0x70 [ 18.797686] kobject_set_name_vargs+0x2f/0xb0 [ 18.803992] kobject_init_and_add+0x9d/0xf0 [ 18.810117] ttm_mem_global_init+0x12c/0x210 [ttm] [ 18.816853] ttm_bo_global_init+0x4a/0x160 [ttm] [ 18.823420] ttm_bo_device_init+0x39/0x220 [ttm] [ 18.830046] nouveau_ttm_init+0x2c3/0x830 [nouveau] [ 18.836929] nouveau_drm_device_init+0x1b4/0x3f0 [nouveau] <...> [ 19.105336] ================================================================== Fix this error, by not using type_vram as an index if it's negative. Assume default values instead. The error was seen on Nvidia G72 hardware. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Michael J. Ruhl <[email protected]> Acked-by: Christian König <[email protected]> Fixes: 1cf65c45183a ("drm/ttm: add caching state to ttm_bus_placement") Cc: Christian König <[email protected]> Cc: Michael J. Ruhl <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Ben Skeggs <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Alex Deucher <[email protected]> Cc: "Christian König" <[email protected]> Cc: VMware Graphics <[email protected]> Cc: Roland Scheidegger <[email protected]> Cc: Huang Rui <[email protected]> Cc: Felix Kuehling <[email protected]> Cc: Hawking Zhang <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Likun Gao <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-11dma-buf: Document that dma-buf size is fixedJianxin Xiong1-2/+2
The fact that the size of dma-buf is invariant over the lifetime of the buffer is mentioned in the comment of 'dma_buf_ops.mmap', but is not documented at where the info is defined. Add the missing documentation. Signed-off-by: Jianxin Xiong <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-11drm/ingenic: ipu: Search for scaling coefs up to 102% of the screenPaul Cercueil1-8/+15
Increase the scaled image's theorical width/height until we find a configuration that has valid scaling coefficients, up to 102% of the screen's resolution. This makes sure that we can scale from almost every resolution possible at the cost of a very small distorsion. The CRTC_W / CRTC_H are not modified. This algorithm was already in place but would not try to go above the screen's resolution, and as a result would only work if the CRTC_W / CRTC_H were smaller than the screen resolution. It will now try until it reaches 102% of the screen's resolution. Note that this algorithm exists mostly as a band-aid for a missing functionality: it is not possible for userspace to request the closest mode that would encapsulate the provided one, because the GEM buffer is created beforehand. If there was a way to let the kernel tweak the mode, I could write a better algorithm that would result in a better looking picture. Signed-off-by: Paul Cercueil <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-11drm/radeon/ttm: use multihopDave Airlie1-106/+12
This removes the code to move resources directly between SYSTEM and VRAM in favour of using the core ttm mulithop code. Signed-off-by: Dave Airlie <[email protected]> Acked-by: Daniel Vetter <[email protected]> Reviewed-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-11drm/nouveau/ttm: use multihopDave Airlie1-99/+13
This removes the code to move resources directly between SYSTEM and VRAM in favour of using the core ttm mulithop code. Signed-off-by: Dave Airlie <[email protected]> Acked-by: Daniel Vetter <[email protected]> Reviewed-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-11drm/amdgpu/ttm: use multihopDave Airlie1-124/+12
This removes the code to move resources directly between SYSTEM and VRAM in favour of using the core ttm mulithop code. Signed-off-by: Dave Airlie <[email protected]> Acked-by: Daniel Vetter <[email protected]> Reviewed-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-11drm/ttm: add multihop infrastrucutre (v3)Dave Airlie8-16/+83
Currently drivers get called to move a buffer, but if they have to move it temporarily through another space (SYSTEM->VRAM via TT) then they can end up with a lot of ttm->driver->ttm call stacks, if the temprorary space moves requires eviction. Instead of letting the driver do all the placement/space for the temporary, allow it to report back (-EMULTIHOP) and a placement (hop) to the move code, which will then do the temporary move, and the correct placement move afterwards. This removes a lot of code from drivers, at the expense of adding some midlayering. I've some further ideas on how to turn it inside out, but I think this is a good solution to the call stack problems. v2: separate out the driver patches, add WARN for getting MULTHOP in paths we shouldn't (Daniel) v3: use memset (Christian) Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: hristian König <[email protected]> Signed-off-by: Dave Airlie <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-10Revert "drm/dp_mst: Retrieve extended DPCD caps for topology manager"Koba Ko1-4/+3
This reverts commit ad44c03208e46b83e4ae3269e32c9e524aa71cf8. Currently DRM driver assume the source device caps is higher than the MST device caps. With this commit, this statement would be broken. e.g. the source device only support DP1.2 and the mst device support DP1.4. Signed-off-by: Koba Ko <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-10drm: remove pgprot_decrypted() before calls to io_remap_pfn_range()Jason Gunthorpe2-8/+0
commit f8f6ae5d077a ("mm: always have io_remap_pfn_range() set pgprot_decrypted()") moves the pgprot_decrypted() into io_remap_pfn_range(). Delete any, now confusing, open coded calls that directly precede io_remap_pfn_range(): - drm_io_prot() is only in drm_mmap_locked() to call io_remap_pfn_range() - fb_mmap() immediately calls vm_iomap_memory() which is a convenience wrapper for io_remap_pfn_range() Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-10drm: DRM_KMB_DISPLAY should depend on ARCH_KEEMBAYGeert Uytterhoeven1-2/+2
The Intel Keem Bay display controller is only present on Intel Keem Bay SoCs. Hence add a dependency on ARCH_KEEMBAY, to prevent asking the user about this driver when configuring a kernel without Intel Keem Bay platform support. Note that: 1. The dependency on ARM is dropped, as Keem Bay SoCs are only supported in arm64 kernel builds, 2. The dependencies on OF and COMMON_CLK can be dropped for compile-testing, as the driver builds fine regardless. Fixes: ed794057b052b52a ("drm/kmb: Build files for KeemBay Display driver") Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.