- 17 Nov, 2020 18 commits
-
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/exynos/exynos_drm_gsc.c:129: warning: Function parameter or member 'num_limits' not described in 'gsc_driverdata' Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Eunchul Kim <chulspro.kim@samsung.com> Cc: Jinyoung Jeon <jy0.jeon@samsung.com> Cc: Sangmin Lee <lsmin.lee@samsung.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201116174112.1833368-7-lee.jones@linaro.org
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/exynos/exynos_drm_fimd.c:733: warning: Function parameter or member 'ctx' not described in 'fimd_shadow_protect_win' Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/exynos/exynos7_drm_decon.c:354: warning: Function parameter or member 'ctx' not described in 'decon_shadow_protect_win' Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Akshu Agarwal <akshua@gmail.com> Cc: Ajay Kumar <ajaykumar.rs@samsung.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/drm_dp_mst_topology.c: In function ‘drm_dp_send_query_stream_enc_status’: drivers/gpu/drm/drm_dp_mst_topology.c:3263:6: warning: variable ‘len’ set but not used [-Wunused-but-set-variable] 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: dri-devel@lists.freedesktop.org Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/armada/armada_overlay.c:329:1: warning: no previous prototype for ‘armada_overlay_duplicate_state’ [-Wmissing-prototypes] Cc: Russell King <linux@armlinux.org.uk> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Paul Cercueil authored
Add support for the ShenZhen Asia Better Technology Ltd. Y030XX067A 3.0" 320x480 IPS panel. This panel can be found in the YLM RG-280M, RG-300 and RG-99 handheld gaming consoles. While being 320x480, it is actually a horizontal 4:3 panel with non-square pixels. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Signed-off-by:
Christophe Branchereau <cbranchereau@gmail.com> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201101093150.8071-5-paul@crapouillou.net
-
Paul Cercueil authored
Add media bus format for 24-bit panels that expect their pixel data to be sent serially on a 8-bit bus, in RGB ordering on odd lines, and in GBR ordering on even lines (aka delta-RGB). Signed-off-by:
-
Paul Cercueil authored
The Asia Better Technology (ABT) Y030XX067A panel is a 3.0" 320x480 24-bit IPS LCD panel. Its particularity is that it has non-square pixels (as it is 4:3 for a resolution of 320x480), and that it requires odd lines to be sent as RGB and even lines to be sent as GRB on its 8-bit bus. Signed-off-by:
-
Paul Cercueil authored
Add prefix for ShenZhen Asia Better Technology Ltd. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201101093150.8071-2-paul@crapouillou.net
-
Marc Zyngier authored
Removing the meson-dw-hdmi module and re-inserting it results in a hang as the driver writes to HDMITX_TOP_SW_RESET. Similar effects can be seen when booting with mainline u-boot and using the u-boot provided DT (which is highly desirable). The reason for the hang seem to be that the clocks are not always enabled by the time we enter meson_dw_hdmi_init(). Moving this call *after* dw_hdmi_probe() ensures that the clocks are enabled. Fixes: 1374b837 ("drm/meson: dw_hdmi: add resume/suspend hooks") Signed-off-by:
Marc Zyngier <maz@kernel.org> Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Marc Zyngier authored
Removing the meson-dw-hdmi module results in the following splat: i[ 43.340509] WARNING: CPU: 0 PID: 572 at drivers/regulator/core.c:2125 _regulator_put.part.0+0x16c/0x174 [...] [ 43.454870] CPU: 0 PID: 572 Comm: modprobe Tainted: G W E 5.10.0-rc4-00049-gd274813a4de3-dirty #2147 [ 43.465042] Hardware name: , BIOS 2021.01-rc2-00012-gde865f7ee1 11/16/2020 [ 43.471945] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--) [ 43.477896] pc : _regulator_put.part.0+0x16c/0x174 [ 43.482638] lr : regulator_put+0x44/0x60 [...] [ 43.568715] Call trace: [ 43.571132] _regulator_put.part.0+0x16c/0x174 [ 43.575529] regulator_put+0x44/0x60 [ 43.579067] devm_regulator_release+0x20/0x2c [ 43.583380] release_nodes+0x1c8/0x2b4 [ 43.587087] devres_release_all+0x44/0x6c [ 43.591056] __device_release_driver+0x1a0/0x23c [ 43.595626] driver_detach+0xcc/0x160 [ 43.599249] bus_remove_driver+0x68/0xe0 [ 43.603130] driver_unregister+0x3c/0x6c [ 43.607011] platform_driver_unregister+0x20/0x2c [ 43.611678] meson_dw_hdmi_platform_driver_exit+0x18/0x4a8 [meson_dw_hdmi] [ 43.618485] __arm64_sys_delete_module+0x1bc/0x294 as the HDMI regulator is still enabled on release. In order to address this, register a callback that will deal with the disabling when the driver is unbound, solving the problem. Fixes: 161a803f ("drm/meson: dw_hdmi: Add support for an optional external 5V regulator") Signed-off-by:
-
Marc Zyngier authored
Removing the meson DRM module results in the following splats: [ 42.689228] WARNING: CPU: 0 PID: 572 at drivers/gpu/drm/drm_irq.c:192 drm_irq_uninstall+0x130/0x160 [drm] [...] [ 42.812820] Hardware name: , BIOS 2021.01-rc2-00012-gde865f7ee1 11/16/2020 [ 42.819723] pstate: 80400089 (Nzcv daIf +PAN -UAO -TCO BTYPE=--) [ 42.825737] pc : drm_irq_uninstall+0x130/0x160 [drm] [ 42.830647] lr : drm_irq_uninstall+0xc4/0x160 [drm] [...] [ 42.917614] Call trace: [ 42.920086] drm_irq_uninstall+0x130/0x160 [drm] [ 42.924612] meson_drv_unbind+0x68/0xa4 [meson_drm] [ 42.929436] component_del+0xc0/0x180 [ 42.933058] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ 42.938576] platform_drv_remove+0x38/0x60 [ 42.942628] __device_release_driver+0x190/0x23c [ 42.947198] driver_detach+0xcc/0x160 [ 42.950822] bus_remove_driver+0x68/0xe0 [ 42.954702] driver_unregister+0x3c/0x6c [ 42.958583] platform_driver_unregister+0x20/0x2c [ 42.963243] meson_dw_hdmi_platform_driver_exit+0x18/0x4a8 [meson_dw_hdmi] [ 42.970057] __arm64_sys_delete_module+0x1bc/0x294 [ 42.974801] el0_svc_common.constprop.0+0x80/0x240 [ 42.979542] do_el0_svc+0x30/0xa0 [ 42.982821] el0_svc+0x18/0x50 [ 42.985839] el0_sync_handler+0x198/0x404 [ 42.989806] el0_sync+0x158/0x180 immediatelly followed by [ 43.002296] WARNING: CPU: 0 PID: 572 at drivers/gpu/drm/drm_mode_config.c:504 drm_mode_config_cleanup+0x2a8/0x304 [drm] [...] [ 43.128150] Hardware name: , BIOS 2021.01-rc2-00012-gde865f7ee1 11/16/2020 [ 43.135052] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--) [ 43.141062] pc : drm_mode_config_cleanup+0x2a8/0x304 [drm] [ 43.146492] lr : drm_mode_config_cleanup+0xac/0x304 [drm] [...] [ 43.233979] Call trace: [ 43.236451] drm_mode_config_cleanup+0x2a8/0x304 [drm] [ 43.241538] drm_mode_config_init_release+0x1c/0x2c [drm] [ 43.246886] drm_managed_release+0xa8/0x120 [drm] [ 43.251543] drm_dev_put+0x94/0xc0 [drm] [ 43.255380] meson_drv_unbind+0x78/0xa4 [meson_drm] [ 43.260204] component_del+0xc0/0x180 [ 43.263829] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ 43.269344] platform_drv_remove+0x38/0x60 [ 43.273398] __device_release_driver+0x190/0x23c [ 43.277967] driver_detach+0xcc/0x160 [ 43.281590] bus_remove_driver+0x68/0xe0 [ 43.285471] driver_unregister+0x3c/0x6c [ 43.289352] platform_driver_unregister+0x20/0x2c [ 43.294011] meson_dw_hdmi_platform_driver_exit+0x18/0x4a8 [meson_dw_hdmi] [ 43.300826] __arm64_sys_delete_module+0x1bc/0x294 [ 43.305570] el0_svc_common.constprop.0+0x80/0x240 [ 43.310312] do_el0_svc+0x30/0xa0 [ 43.313590] el0_svc+0x18/0x50 [ 43.316608] el0_sync_handler+0x198/0x404 [ 43.320574] el0_sync+0x158/0x180 [ 43.323852] ---[ end trace d796a3072dab01da ]--- [ 43.328561] [drm:drm_mode_config_cleanup [drm]] *ERROR* connector HDMI-A-1 leaked! both triggered by the fact that the HDMI subsystem is still active, and the DRM removal doesn't result in the connectors being torn down. Call drm_atomic_helper_shutdown() and component_unbind_all() to safely tear the module down. Fixes: 2d8f9289 ("drm/meson: Uninstall IRQ handler") Signed-off-by:
-
Marc Zyngier authored
Removing the meson DRM module results in the following splat: [ 2179.451346] Hardware name: , BIOS 2021.01-rc2-00012-gde865f7ee1 11/16/2020 [ 2179.458316] Workqueue: events drm_mode_rmfb_work_fn [drm] [ 2179.463597] pstate: 80c00009 (Nzcv daif +PAN +UAO -TCO BTYPE=--) [ 2179.469558] pc : meson_rdma_writel_sync+0x44/0xb0 [meson_drm] [ 2179.475243] lr : meson_g12a_afbcd_reset+0x34/0x60 [meson_drm] [ 2179.480930] sp : ffffffc01212bb70 [ 2179.484207] x29: ffffffc01212bb70 x28: ffffff8044f66f00 [ 2179.489469] x27: ffffff8045b13800 x26: 0000000000000001 [ 2179.494730] x25: 0000000000000000 x24: 0000000000000001 [ 2179.499991] x23: 0000000000000000 x22: 0000000000000000 [ 2179.505252] x21: 0000000000280000 x20: 0000000000001a01 [ 2179.510513] x19: ffffff8046029480 x18: 0000000000000000 [ 2179.515775] x17: 0000000000000000 x16: 0000000000000000 [ 2179.521036] x15: 0000000000000000 x14: 0000000000000000 [ 2179.526297] x13: 0040000000000326 x12: 0309030303260300 [ 2179.531558] x11: 03000000054004a0 x10: 0418054004000400 [ 2179.536820] x9 : ffffffc008fe4914 x8 : ffffff8040a1adc0 [ 2179.542081] x7 : 0000000000000000 x6 : ffffff8042aa0080 [ 2179.547342] x5 : ffffff8044f66f00 x4 : ffffffc008fe5bc8 [ 2179.552603] x3 : 0000000000010101 x2 : 0000000000000001 [ 2179.557865] x1 : 0000000000000000 x0 : 0000000000000000 [ 2179.563127] Call trace: [ 2179.565548] meson_rdma_writel_sync+0x44/0xb0 [meson_drm] [ 2179.570894] meson_g12a_afbcd_reset+0x34/0x60 [meson_drm] [ 2179.576241] meson_plane_atomic_disable+0x38/0xb0 [meson_drm] [ 2179.581966] drm_atomic_helper_commit_planes+0x1e0/0x21c [drm_kms_helper] [ 2179.588684] drm_atomic_helper_commit_tail_rpm+0x68/0xb0 [drm_kms_helper] [ 2179.595410] commit_tail+0xac/0x190 [drm_kms_helper] [ 2179.600326] drm_atomic_helper_commit+0x16c/0x390 [drm_kms_helper] [ 2179.606484] drm_atomic_commit+0x58/0x70 [drm] [ 2179.610880] drm_framebuffer_remove+0x398/0x434 [drm] [ 2179.615881] drm_mode_rmfb_work_fn+0x68/0x8c [drm] [ 2179.620575] process_one_work+0x1cc/0x49c [ 2179.624538] worker_thread+0x200/0x444 [ 2179.628246] kthread+0x14c/0x160 [ 2179.631439] ret_from_fork+0x10/0x38 caused by the fact that the RDMA buffer has already been freed, resulting in meson_rdma_writel_sync() getting a NULL pointer. Move the afbcd reset and meson_rdma_free calls after the DRM unregistration is complete so that the teardown can safely complete. Fixes: d1b5e41e ("drm/meson: Add AFBCD module driver") Signed-off-by:
-
Yang Yingliang authored
Return -ENOMEM when allocating refill memory failed. Fixes: 71e8831f ("drm/omap: DMM/TILER support for OMAP4+ platform") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201117061045.3452287-1-yangyingliang@huawei.com
-
Daniel Vetter authored
These are leftovers from 13aff184 ("drm/qxl: remove dead qxl fbdev emulation code"). v2: Somehow these structs provided the struct qxl_device pre-decl, reorder the header to not anger compilers. Acked-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: virtualization@lists.linux-foundation.org Cc: spice-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20201029133347.4088884-1-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Every since commit 6104c370 Author: Daniel Vetter <daniel.vetter@ffwll.ch> 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:
-
Daniel Vetter authored
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. 50145474 ("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 <tomi.valkeinen@ti.com> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by:
-
Yang Yingliang authored
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: b985172b ("video: atmel_lcdfb: add device tree suport") Reported-by:
-
- 16 Nov, 2020 14 commits
-
-
Mauro Carvalho Chehab authored
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 <mchehab+huawei@kernel.org> Acked-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Some identifiers have different names between their prototypes and the kernel-doc markup. Signed-off-by:
-
Peilin Ye authored
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 <daniel@ffwll.ch> Signed-off-by:
Peilin Ye <yepeilin.cs@gmail.com> Reviewed-by:
-
Peilin Ye authored
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 authored
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 authored
.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:
-
Peilin Ye authored
Recently in commit 3c4e0dff ("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 af8d3c7c ("ppp: remove the PPPIOCDETACH ioctl"). Signed-off-by:
-
Boris Brezillon authored
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: 1a11a88c ("drm/panfrost: Fix job timeout handling") Cc: <stable@vger.kernel.org> Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Steven Price <steven.price@arm.com> Signed-off-by:
-
Simon Ser authored
crtc can be NULL. connector, extracted from conn_state, can't. Fixes: e3aae683 ("drm: convert drm_atomic_uapi.c to new debug helpers") Signed-off-by:
Simon Ser <contact@emersion.fr> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Zou Wei authored
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 <zou_wei@huawei.com> Link: http://patchwork.freedesktop.org/patch/msgid/1605338173-22100-1-git-send-email-zou_wei@huawei.comSigned-off-by:
-
Viresh Kumar authored
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 <yuq825@gmail.com> Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Lee Jones authored
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 <yuq825@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: dri-devel@lists.freedesktop.org Cc: lima@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Signed-off-by:
-
Lee Jones authored
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 <yuq825@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: lima@lists.freedesktop.org Signed-off-by:
-
Liu Shixin authored
Simplify the return expression. Signed-off-by:
Liu Shixin <liushixin2@huawei.com> Signed-off-by:
-
- 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:
-
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:
-
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:
-
- 14 Nov, 2020 1 commit
-
-
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:
-
