- 16 Nov, 2020 1 commit
-
-
Liu Shixin authored
Simplify the return expression. Signed-off-by:
Liu Shixin <liushixin2@huawei.com> Signed-off-by:
Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200919100850.1639111-1-liushixin2@huawei.com
-
- 15 Nov, 2020 7 commits
-
-
Linus Walleij authored
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 <linus.walleij@linaro.org> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201110234653.2248594-6-linus.walleij@linaro.org
-
Linus Walleij authored
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 authored
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 authored
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 authored
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:
-
Patrik Jakobsson authored
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 <patrik.r.jakobsson@gmail.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201115175420.32167-1-patrik.r.jakobsson@gmail.com
-
Patrik Jakobsson authored
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:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
- 14 Nov, 2020 5 commits
-
-
Caleb Connolly authored
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 <caleb@connolly.tech> Signed-off-by:
-
Caleb Connolly authored
Add compatibles for the samsung,sofef00 and samsung,s6e3fc2x01 panels used in the OnePlus 6 & 6T respectively. Signed-off-by:
-
Lee Jones authored
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 <linus.walleij@linaro.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Simon Ser authored
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 <contact@emersion.fr> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by:
-
Simon Ser authored
Migrate from DRM_DEBUG_ATOMIC to drm_dbg_atomic. Signed-off-by:
-
- 13 Nov, 2020 2 commits
-
-
Christian König authored
The pool parameter can be NULL if we free through the shrinker. Signed-off-by:
Christian König <christian.koenig@amd.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Tested-by:
Martin Peres <martin.peres@mupuf.org> Acked-by:
Andy Lavr <andy.lavr@gmail.com> Tested-by:
-
Dan Carpenter authored
If udl_get_urb() fails then this should return a negative error code but currently it returns success. Fixes: 798ce3fe ("drm/udl: Begin/end access to imported buffers in damage-handler") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 12 Nov, 2020 7 commits
-
-
Lee Jones authored
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 <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Lee Jones authored
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 <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: dri-devel@lists.freedesktop.org Signed-off-by: -
Lee Jones authored
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 <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Rob Clark <robdclark@gmail.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Lee Jones authored
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 <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Lee Jones authored
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 <sam@ravnborg.org> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by:
-
Lee Jones authored
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 <sam@ravnborg.org> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by:
-
Lee Jones authored
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 <sam@ravnborg.org> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Jean-Jacques Hiblot <jjhiblot@traphandler.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by:
-
- 11 Nov, 2020 9 commits
-
-
Colin Ian King authored
There are two spelling mistakes of the word sync in drm_info and drm_dbg messages. Fix these. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Anitha Chrisanthus authored
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 <anitha.chrisanthus@intel.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Thomas Zimmermann authored
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:
Michael J. Ruhl <michael.j.ruhl@intel.com> Acked-by:
-
Jianxin Xiong authored
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 <jianxin.xiong@intel.com> Signed-off-by:
-
Paul Cercueil authored
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 <paul@crapouillou.net> Acked-by:
-
Dave Airlie authored
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 <airlied@redhat.com> Acked-by:
-
Dave Airlie authored
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 authored
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 authored
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:
-
- 10 Nov, 2020 9 commits
-
-
Koba Ko authored
This reverts commit ad44c032. 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 <koba.ko@canonical.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Jason Gunthorpe authored
commit f8f6ae5d ("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 <jgg@nvidia.com> Signed-off-by:
-
Geert Uytterhoeven authored
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: ed794057 ("drm/kmb: Build files for KeemBay Display driver") Signed-off-by:Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Geert Uytterhoeven authored
If CONFIG_DRM_MIPI_DSI=n: aarch64-linux-gnu-ld: drivers/gpu/drm/kmb/kmb_dsi.o: in function `kmb_dsi_host_unregister': kmb_dsi.c:(.text+0xa48): undefined reference to `mipi_dsi_host_unregister' aarch64-linux-gnu-ld: drivers/gpu/drm/kmb/kmb_dsi.o: in function `kmb_dsi_host_bridge_init': kmb_dsi.c:(.text+0xb14): undefined reference to `mipi_dsi_host_register' Fix this be selecting DRM_MIPI_DSI, like other drivers do. Fixes: ed794057 ("drm/kmb: Build files for KeemBay Display driver") Signed-off-by: -
Thomas Zimmermann authored
We need commit f8f6ae5d ("mm: always have io_remap_pfn_range() set pgprot_decrypted()") to be able to merge Jason's cleanup patch. Signed-off-by:
-
Daniel Abrecht authored
This will make sure applications which use the IN_FORMATS blob to figure out which modifiers they can use will pick up the linear modifier which is needed by mxsfb. Such applications will not work otherwise if an incompatible implicit modifier ends up being selected. Before commit ae1ed009 ("drm: mxsfb: Stop using DRM simple display pipeline helper"), the DRM simple display pipeline helper took care of this. Signed-off-by:
Daniel Abrecht <public@danielabrecht.ch> Fixes: ae1ed009 ("drm: mxsfb: Stop using DRM simple display pipeline helper") Signed-off-by:
-
Deepak R Varma authored
idr_init() uses base 0 which is an invalid identifier. The new function idr_init_base allows IDR to set the ID lookup from base 1. This avoids all lookups that otherwise starts from 0 since 0 is always unused. References: commit 6ce711f2 ("idr: Make 1-based IDRs more efficient") Signed-off-by:
Deepak R Varma <mh12gx2825@gmail.com> Signed-off-by:
-
Daniel Vetter authored
We need commit f8f6ae5d ("mm: always have io_remap_pfn_range() set pgprot_decrypted()") to be able to merge Jason's cleanup patch. Signed-off-by:
-
Dinghao Liu authored
pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. However, users of its direct wrappers in omapdrm assume that PM usage counter will not change on error. Thus a pairing decrement is needed on the error handling path for these wrappers to keep the counter balanced. Signed-off-by:
Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200822065743.13671-1-dinghao.liu@zju.edu.cn
-
