#
bcb48185 |
|
12-Jul-2023 |
Jiri Slaby <jirislaby@kernel.org> |
tty: sysrq: switch sysrq handlers from int to u8 The passed parameter to sysrq handlers is a key (a character). So change the type from 'int' to 'u8'. Let it specifically be 'u8' for two reasons: * unsigned: unsigned values come from the upper layers (devices) and the tty layer assumes unsigned on most places, and * 8-bit: as that what's supposed to be one day in all the layers built on the top of tty. (Currently, we use mostly 'unsigned char' and somewhere still only 'char'. (But that also translates to the former thanks to -funsigned-char.)) Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: WANG Xuerui <kernel@xen0n.name> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: "David S. Miller" <davem@davemloft.net> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Len Brown <len.brown@intel.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: "Paul E. McKenney" <paulmck@kernel.org> Cc: Frederic Weisbecker <frederic@kernel.org> Cc: Neeraj Upadhyay <quic_neeraju@quicinc.com> Cc: Joel Fernandes <joel@joelfernandes.org> Cc: Josh Triplett <josh@joshtriplett.org> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Lai Jiangshan <jiangshanlai@gmail.com> Cc: Zqiang <qiang.zhang1211@gmail.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> # DRM Acked-by: WANG Xuerui <git@xen0n.name> # loongarch Acked-by: Paul E. McKenney <paulmck@kernel.org> Acked-by: Daniel Thompson <daniel.thompson@linaro.org> Link: https://lore.kernel.org/r/20230712081811.29004-3-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
43049f17 |
|
30-May-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/i915: Implement dedicated fbdev I/O helpers Implement dedicated fbdev helpers for framebuffer I/O instead of using DRM's helpers. Use an fbdev generator macro for deferred I/O to create the fbdev callbacks. i915 was the only caller of the DRM helpers, so remove them from the helper module. i915's fbdev emulation is still incomplete as it doesn't implement deferred I/O and damage handling for mmaped pages. v4: * generate deferred-I/O helpers * use initializer macros for fb_ops v2: * use FB_IO_HELPERS options Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230530151228.22979-14-tzimmermann@suse.de
|
#
c6baad68 |
|
30-May-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fbdev-generic: Implement dedicated fbdev I/O helpers Implement dedicated fbdev helpers for framebuffer I/O instead of using DRM's helpers. Use an fbdev generator macro for deferred I/O to create the callbacks. Fbdev-generic was the only caller of the DRM helpers, so remove them from the helper module. v4: * generate deferred-I/O helpers * use initializer macros for fb_ops v2: * use FB_SYS_HELPERS_DEFERRED option Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <suijingfeng@loongson.cn> Reviewed-by: Sui Jingfeng <suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230530151228.22979-13-tzimmermann@suse.de
|
#
c51b3620 |
|
30-May-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Export helpers for marking damage areas Export drm_fb_helper_damage() and drm_fb_helper_damage_range(), which handle damage areas for fbdev emulation. This is a temporary export that allows to move the DRM I/O helpers for fbdev into drivers. Only fbdev-generic and i915 need them. Both will be updated to implement damage handling by themselves and the exported functions will be removed. v4: * update interfaces Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230530151228.22979-11-tzimmermann@suse.de
|
#
e79d85c6 |
|
23-May-2023 |
Geert Uytterhoeven <geert+renesas@glider.be> |
drm/fb-helper: Fix height, width, and accel_flags in fb_var Fbtest contains some very simple validation of the fbdev userspace API contract. When used with shmob-drm, it reports the following warnings and errors: height changed from 68 to 0 height was rounded down width changed from 111 to 0 width was rounded down accel_flags changed from 0 to 1 The first part happens because __fill_var() resets the physical dimensions of the first connector, as filled in by drm_setup_crtcs_fb(). Fix this by retaining the original values. The last part happens because __fill_var() forces the FB_ACCELF_TEXT flag on, while fbtest disables all acceleration on purpose, so it can draw safely to the frame buffer. Fix this by setting accel_flags to zero, as DRM does not implement any text console acceleration. Note that this issue can also be seen in the output of fbset, which reports "accel true". Fixes: ee4cce0a8f03a333 ("drm/fb-helper: fix input validation gaps in check_var") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Sui Jingfeng <suijingfeng@loongson.cn> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/57e6b334dae8148b1b8ae6ef308ce9a83810a850.1684854344.git.geert+renesas@glider.be
|
#
04408952 |
|
28-Apr-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Use fb_{cfb,sys}_{read, write}() Implement DRM fbdev helpers for reading and writing framebuffer memory with the respective fbdev functions. Removes duplicate code. v2: * rename fb_cfb_() to fb_io_() (Geert) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <suijingfeng@loongson.cn> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Helge Deller <deller@gmx.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230428122452.4856-20-tzimmermann@suse.de
|
#
c8687694 |
|
19-Apr-2023 |
Sui Jingfeng <suijingfeng@loongson.cn> |
drm/fbdev-generic: prohibit potential out-of-bounds access The fbdev test of IGT may write after EOF, which lead to out-of-bound access for drm drivers with fbdev-generic. For example, run fbdev test on a x86+ast2400 platform, with 1680x1050 resolution, will cause the linux kernel hang with the following call trace: Oops: 0000 [#1] PREEMPT SMP PTI [IGT] fbdev: starting subtest eof Workqueue: events drm_fb_helper_damage_work [drm_kms_helper] [IGT] fbdev: starting subtest nullptr RIP: 0010:memcpy_erms+0xa/0x20 RSP: 0018:ffffa17d40167d98 EFLAGS: 00010246 RAX: ffffa17d4eb7fa80 RBX: ffffa17d40e0aa80 RCX: 00000000000014c0 RDX: 0000000000001a40 RSI: ffffa17d40e0b000 RDI: ffffa17d4eb80000 RBP: ffffa17d40167e20 R08: 0000000000000000 R09: ffff89522ecff8c0 R10: ffffa17d4e4c5000 R11: 0000000000000000 R12: ffffa17d4eb7fa80 R13: 0000000000001a40 R14: 000000000000041a R15: ffffa17d40167e30 FS: 0000000000000000(0000) GS:ffff895257380000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa17d40e0b000 CR3: 00000001eaeca006 CR4: 00000000001706e0 Call Trace: <TASK> ? drm_fbdev_generic_helper_fb_dirty+0x207/0x330 [drm_kms_helper] drm_fb_helper_damage_work+0x8f/0x170 [drm_kms_helper] process_one_work+0x21f/0x430 worker_thread+0x4e/0x3c0 ? __pfx_worker_thread+0x10/0x10 kthread+0xf4/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK> CR2: ffffa17d40e0b000 ---[ end trace 0000000000000000 ]--- The is because damage rectangles computed by drm_fb_helper_memory_range_to_clip() function is not guaranteed to be bound in the screen's active display area. Possible reasons are: 1) Buffers are allocated in the granularity of page size, for mmap system call support. The shadow screen buffer consumed by fbdev emulation may also choosed be page size aligned. 2) The DIV_ROUND_UP() used in drm_fb_helper_memory_range_to_clip() will introduce off-by-one error. For example, on a 16KB page size system, in order to store a 1920x1080 XRGB framebuffer, we need allocate 507 pages. Unfortunately, the size 1920*1080*4 can not be divided exactly by 16KB. 1920 * 1080 * 4 = 8294400 bytes 506 * 16 * 1024 = 8290304 bytes 507 * 16 * 1024 = 8306688 bytes line_length = 1920*4 = 7680 bytes 507 * 16 * 1024 / 7680 = 1081.6 off / line_length = 507 * 16 * 1024 / 7680 = 1081 DIV_ROUND_UP(507 * 16 * 1024, 7680) will yeild 1082 memcpy_toio() typically issue the copy line by line, when copy the last line, out-of-bound access will be happen. Because: 1082 * line_length = 1082 * 7680 = 8309760, and 8309760 > 8306688 Note that userspace may still write to the invisiable area if a larger buffer than width x stride is exposed. But it is not a big issue as long as there still have memory resolve the access if not drafting so far. - Also limit the y1 (Daniel) - keep fix patch it to minimal (Daniel) - screen_size is page size aligned because of it need mmap (Thomas) - Adding fixes tag (Thomas) Signed-off-by: Sui Jingfeng <suijingfeng@loongson.cn> Fixes: aa15c677cc34 ("drm/fb-helper: Fix vertical damage clipping") Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/dri-devel/ad44df29-3241-0d9e-e708-b0338bf3c623@189.cn/ Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230420030500.1578756-1-suijingfeng@loongson.cn
|
#
ee4cce0a |
|
04-Apr-2023 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: fix input validation gaps in check_var Apparently drivers need to check all this stuff themselves, which for most things makes sense I guess. And for everything else we luck out, because modern distros stopped supporting any other fbdev drivers than drm ones and I really don't want to argue anymore about who needs to check stuff. Therefore fixing all this just for drm fbdev emulation is good enough. Note that var->active is not set or validated. This is just control flow for fbmem.c and needs to be validated in there as needed. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230404194038.472803-3-daniel.vetter@ffwll.ch
|
#
36e239b5 |
|
04-Apr-2023 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: drop redundant pixclock check from drm_fb_helper_set_par() The fb_check_var hook is supposed to validate all this stuff. Any errors from fb_set_par are considered driver/hw issues and resulting in dmesg warnings. Luckily we do fix up the pixclock already, so this is all fine. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230404194038.472803-2-daniel.vetter@ffwll.ch
|
#
1935f0de |
|
04-Apr-2023 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var Drivers are supposed to fix this up if needed if they don't outright reject it. Uncovered by 6c11df58fd1a ("fbmem: Check virtual screen sizes in fb_set_var()"). Reported-by: syzbot+20dcf81733d43ddff661@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=c5faf983bfa4a607de530cd3bb008888bf06cefc Cc: stable@vger.kernel.org # v5.4+ Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230404194038.472803-1-daniel.vetter@ffwll.ch
|
#
a51c7663 |
|
20-Mar-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Consolidate CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM Consolidate all handling of CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM by making the module parameter optional in drm_fb_helper.c. Without the config option, modules can set smem_start in struct fb_info for internal usage, but not export if to userspace. The address can only be exported by enabling the option and setting the module parameter. Also update the comment. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Zack Rusin <zackr@vmware.com> Tested-by: Sui Jingfeng<suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230320150751.20399-8-tzimmermann@suse.de
|
#
24dc4f4c |
|
20-Mar-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Support smem_len in deferred I/O The size of the framebuffer can either be stored in screen_info or smem_len. Take both into account in the deferred I/O code. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Sui Jingfeng <suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230320150751.20399-5-tzimmermann@suse.de
|
#
6a4fef21 |
|
20-Mar-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Export drm_fb_helper_release_info() Export the fb_info release code as drm_fb_helper_release_info(). Will help with cleaning up failed fbdev probing. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Zack Rusin <zackr@vmware.com> Tested-by: Sui Jingfeng<suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230320150751.20399-4-tzimmermann@suse.de
|
#
3fb1f62f |
|
16-Feb-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Remove drm_fb_helper_unprepare() from drm_fb_helper_fini() Move drm_fb_helper_unprepare() from drm_fb_helper_fini() into the calling fbdev implementation. Avoids a possible stale mutex with generic fbdev code. As indicated by its name, drm_fb_helper_prepare() prepares struct drm_fb_helper before setting up the fbdev support with a call to drm_fb_helper_init(). In legacy fbdev emulation, this happens next to each other. If successful, drm_fb_helper_fini() later tear down the fbdev device and also unprepare via drm_fb_helper_unprepare(). Generic fbdev emulation prepares struct drm_fb_helper immediately after allocating the instance. It only calls drm_fb_helper_init() as part of processing a hotplug event. If the hotplug-handling fails, it runs drm_fb_helper_fini(). This unprepares the fb-helper instance and the next hotplug event runs on stale data. Solve this by moving drm_fb_helper_unprepare() from drm_fb_helper_fini() into the fbdev implementations. Call it right before freeing the fb-helper instance. Fixes: 643231b28380 ("drm/fbdev-generic: Minimize hotplug error handling") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230216140620.17699-1-tzimmermann@suse.de
|
#
6c80a93b |
|
25-Jan-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Initialize fb-helper's preferred BPP in prepare function Initialize the fb-helper's preferred_bpp field early from within drm_fb_helper_prepare(); instead of the later client hot-plugging callback. This simplifies the generic fbdev setup function. No real changes, but all drivers' fbdev code has to be adapted. v3: * build with CONFIG_DRM_FBDEV_EMULATION unset (kernel test bot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125200415.14123-7-tzimmermann@suse.de
|
#
ec9361a1 |
|
25-Jan-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Remove preferred_bpp parameter from fbdev internals Store the console's preferred BPP value in struct drm_fb_helper and remove the respective function parameters from the internal fbdev code. The BPP value is only required as a fallback and will now always be available in the fb-helper instance. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125200415.14123-6-tzimmermann@suse.de
|
#
4825797c |
|
25-Jan-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Introduce drm_fb_helper_unprepare() Move the fb-helper clean-up code into drm_fb_helper_unprepare(). No functional changes. v2: * declare as static inline (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125200415.14123-4-tzimmermann@suse.de
|
#
8c8743db |
|
19-Dec-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Do not allocate unused apertures structure The apertures field in struct fb_info is not used by DRM drivers. Do not allocate it. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-7-tzimmermann@suse.de
|
#
d3533a8a |
|
05-Jan-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Replace bpp/depth parameter by color mode Replace the combination of bpp and depth with a single color-mode argument. Handle special cases in simpledrm and ofdrm. Hard-code XRGB8888 as fallback format for cases where no given format works. The color-mode argument accepts the same values as the kernel's video parameter. These are mostly bpp values between 1 and 32. The exceptions are 15, which has a color depth of 15 and a bpp value of 16; and 32, which has a color depth of 24 and a bpp value of 32. v4: * add back lost test for bpp_specified (Maira) * add Fixes tag (Daniel) v3: * fix ofdrm build (Maxime) v2: * minimize changes (Daniel) * use drm_driver_legacy_fb_format() (Daniel) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Maíra Canal <mcanal@igalia.com> # vc4 and vkms Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: 37c90d589dc0 ("drm/fb-helper: Fix single-probe color-format selection") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230106112324.22055-1-tzimmermann@suse.de
|
#
37c90d58 |
|
01-Jan-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Fix single-probe color-format selection Fix the color-format selection of the single-probe helper. Go through all user-specified values and test each for compatibility with the driver. If none is supported, use the driver-provided default. This guarantees that the console is always available in any color format at least. Until now, the format selection of the single-probe helper tried to either use a user-specified format or a 32-bit default format. If the user-specified format was not supported by the driver, the selection failed and the display remained blank. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230102112927.26565-12-tzimmermann@suse.de
|
#
cff84bac |
|
01-Jan-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fh-helper: Split fbdev single-probe helper Split the single-probe helper's implementation into multiple functions and get locking and overallocation out of the way of the surface setup. Simplifies later changes to the setup code. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230102112927.26565-11-tzimmermann@suse.de
|
#
e3ddd2d2 |
|
18-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
Revert "drm/fb-helper: Perform damage handling in deferred-I/O helper" This reverts commit 5fc586a058babc71c82a038477581b7bfe1c6e2a. Needed to restore the fbdev damage worker. There have been bug reports about locking order [1] and incorrectly takens branches. [2] Restore the damage worker until these problems have been resovled. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://intel-gfx-ci.01.org/tree/drm-tip/fi-kbl-8809g.html # 1 Link: https://lore.kernel.org/dri-devel/20221115115819.23088-6-tzimmermann@suse.de/T/#m06eedc0a468940e4cbbd14ca026733b639bc445a # 2 Link: https://patchwork.freedesktop.org/patch/msgid/20221118133535.9739-4-tzimmermann@suse.de
|
#
8b83e1a4 |
|
18-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
Revert "drm/fb-helper: Schedule deferred-I/O worker after writing to framebuffer" This reverts commit 7f5cc4a3e5e4c5a38e5748defc952e45278f7a70. Needed to restore the fbdev damage worker. There have been bug reports about locking order [1] and incorrectly takens branches. [2] Restore the damage worker until these problems have been resovled. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://intel-gfx-ci.01.org/tree/drm-tip/fi-kbl-8809g.html # 1 Link: https://lore.kernel.org/dri-devel/20221115115819.23088-6-tzimmermann@suse.de/T/#m06eedc0a468940e4cbbd14ca026733b639bc445a # 2 Link: https://patchwork.freedesktop.org/patch/msgid/20221118133535.9739-3-tzimmermann@suse.de
|
#
7aa3d63e |
|
18-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
Revert "drm/fb-helper: Remove damage worker" This reverts commit 27c3e9452d552ea86369a94f23287a9675f2d7a1. Needed to restore the fbdev damage worker. There have been bug reports about locking order [1] and incorrectly takens branches. [2] Restore the damage worker until these problems have been resovled. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://intel-gfx-ci.01.org/tree/drm-tip/fi-kbl-8809g.html # 1 Link: https://lore.kernel.org/dri-devel/20221115115819.23088-6-tzimmermann@suse.de/T/#m06eedc0a468940e4cbbd14ca026733b639bc445a # 2 Link: https://patchwork.freedesktop.org/patch/msgid/20221118133535.9739-2-tzimmermann@suse.de
|
#
d1d51014 |
|
15-Jan-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Set framebuffer for vga-switcheroo clients Set the framebuffer info for drivers that support VGA switcheroo. Only affects the amdgpu and nouveau drivers, which use VGA switcheroo and generic fbdev emulation. For other drivers, this does nothing. This fixes a potential regression in the console code. Both, amdgpu and nouveau, invoked vga_switcheroo_client_fb_set() from their internal fbdev code. But the call got lost when the drivers switched to the generic emulation. Fixes: 087451f372bf ("drm/amdgpu: use generic fb helpers instead of setting up AMD own's.") Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Evan Quan <evan.quan@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Cc: Likun Gao <Likun.Gao@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Stanley Yang <Stanley.Yang@amd.com> Cc: "Tianci.Yin" <tianci.yin@amd.com> Cc: Xiaojian Du <Xiaojian.Du@amd.com> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Cc: YiPeng Chai <YiPeng.Chai@amd.com> Cc: Somalapuram Amaranath <Amaranath.Somalapuram@amd.com> Cc: Bokun Zhang <Bokun.Zhang@amd.com> Cc: Guchun Chen <guchun.chen@amd.com> Cc: Hamza Mahfooz <hamza.mahfooz@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Solomon Chiu <solomon.chiu@amd.com> Cc: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: "Marek Olšák" <marek.olsak@amd.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Hans de Goede <hdegoede@redhat.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.17+ Link: https://patchwork.freedesktop.org/patch/msgid/20230116115425.13484-3-tzimmermann@suse.de
|
#
b02897e5 |
|
18-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
Revert "drm/fb-helper: Perform damage handling in deferred-I/O helper" This reverts commit 5fc586a058babc71c82a038477581b7bfe1c6e2a. Needed to restore the fbdev damage worker. There have been bug reports about locking order [1] and incorrectly takens branches. [2] Restore the damage worker until these problems have been resovled. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://intel-gfx-ci.01.org/tree/drm-tip/fi-kbl-8809g.html # 1 Link: https://lore.kernel.org/dri-devel/20221115115819.23088-6-tzimmermann@suse.de/T/#m06eedc0a468940e4cbbd14ca026733b639bc445a # 2 Link: https://patchwork.freedesktop.org/patch/msgid/20221118133535.9739-4-tzimmermann@suse.de (cherry picked from commit e3ddd2d25533d1cc6f9fea421e4a5f16b60b3434)
|
#
1ab4de28 |
|
18-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
Revert "drm/fb-helper: Schedule deferred-I/O worker after writing to framebuffer" This reverts commit 7f5cc4a3e5e4c5a38e5748defc952e45278f7a70. Needed to restore the fbdev damage worker. There have been bug reports about locking order [1] and incorrectly takens branches. [2] Restore the damage worker until these problems have been resovled. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://intel-gfx-ci.01.org/tree/drm-tip/fi-kbl-8809g.html # 1 Link: https://lore.kernel.org/dri-devel/20221115115819.23088-6-tzimmermann@suse.de/T/#m06eedc0a468940e4cbbd14ca026733b639bc445a # 2 Link: https://patchwork.freedesktop.org/patch/msgid/20221118133535.9739-3-tzimmermann@suse.de (cherry picked from commit 8b83e1a455382dc667898a525a93f4eb6716cc41)
|
#
713befe8 |
|
18-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
Revert "drm/fb-helper: Remove damage worker" This reverts commit 27c3e9452d552ea86369a94f23287a9675f2d7a1. Needed to restore the fbdev damage worker. There have been bug reports about locking order [1] and incorrectly takens branches. [2] Restore the damage worker until these problems have been resovled. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://intel-gfx-ci.01.org/tree/drm-tip/fi-kbl-8809g.html # 1 Link: https://lore.kernel.org/dri-devel/20221115115819.23088-6-tzimmermann@suse.de/T/#m06eedc0a468940e4cbbd14ca026733b639bc445a # 2 Link: https://patchwork.freedesktop.org/patch/msgid/20221118133535.9739-2-tzimmermann@suse.de (cherry picked from commit 7aa3d63e1ad56c174536a5aba76d8a54c4c5acb4)
|
#
27c3e945 |
|
14-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Remove damage worker The fbdev damage worker is unused, so remove it. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-7-tzimmermann@suse.de
|
#
7f5cc4a3 |
|
14-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Schedule deferred-I/O worker after writing to framebuffer Schedule the deferred-I/O worker instead of the damage worker after writing to the fbdev framebuffer. The deferred-I/O worker then performs the dirty-fb update. The fbdev emulation will initialize deferred I/O for all drivers that require damage updates. It is therefore a valid assumption that the deferred-I/O worker is present. It would be possible to perform the damage handling directly from within the write operation. But doing this could increase the overhead of the write or interfere with a concurrently scheduled deferred-I/O worker. Instead, scheduling the deferred-I/O worker with its regular delay of 50 ms removes load off the write operation and allows the deferred-I/O worker to handle multiple write operations that arrived during the delay time window. v3: * remove unused variable (lkp) v2: * keep drm_fb_helper_damage() (Daniel) * use fb_deferred_io_schedule_flush() (Daniel) * clarify comments (Daniel) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-6-tzimmermann@suse.de
|
#
5fc586a0 |
|
14-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Perform damage handling in deferred-I/O helper Call fb_dirty directly from drm_fb_helper_deferred_io() to avoid the latency of running the damage worker. The deferred-I/O helper drm_fb_helper_deferred_io() runs in a worker thread at regular intervals as part of writing to mmaped framebuffer memory. It used to schedule the fbdev damage worker to flush the framebuffer. Changing this to flushing the framebuffer directly avoids the latency introduced by the damage worker. v2: * remove fb_dirty from defio in separate patch (Daniel) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-5-tzimmermann@suse.de
|
#
9b723240 |
|
14-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Remove test for fb_dirty callback from deferred-I/O helper The helper for processing deferred I/O on pages has no dependency on the fb_dirty damge-handling callback; so remove the test. In practice, deferred I/O is only used with damage handling and the damage worker already guarantees the presence of the fb_dirty callback. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-4-tzimmermann@suse.de
|
#
17d64f15 |
|
14-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Move dirty-fb update into helper function Move the dirty-fb update from the damage-worker callback into the new helper drm_fb_helper_fb_dirty(), so that it can run outside the damage worker. This change will help to remove the damage worker entirely. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-3-tzimmermann@suse.de
|
#
b1be5ba2 |
|
14-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Set damage-clip area in helper Set the damage area in the new helper drm_fb_helper_add_damage_clip(). It can now be updated without scheduling the damage worker. This change will help to remove the damage worker entirely. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-2-tzimmermann@suse.de
|
#
78a77c9f |
|
03-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Clarify use of last_close and output_poll_changed Clarify documentation in the use of struct drm_driver.last_close and struct drm_mode_config_funcs.output_poll_changed. Those callbacks should not be said for fbdev implementations on top of struct drm_client_funcs. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-24-tzimmermann@suse.de
|
#
8ab59da2 |
|
03-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Move generic fbdev emulation into separate source file Move the generic fbdev implementation into its own source and header file. Adapt drivers. No functional changes, but some of the internal helpers have been renamed to fit into the drm_fbdev_ naming scheme. v3: * rename drm_fbdev.{c,h} to drm_fbdev_generic.{c,h} * rebase onto vmwgfx changes * rebase onto xlnx changes * fix include statements in amdgpu Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-22-tzimmermann@suse.de
|
#
e7c5c29a |
|
03-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Set flag in struct drm_fb_helper for leaking physical addresses Uncouple the parameter drm_leak_fbdev_smem from the implementation by setting a flag in struct drm_fb_helper. This will help to move the generic fbdev emulation into its own source file, while keeping the parameter in drm_fb_helper.c. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-21-tzimmermann@suse.de
|
#
7ce19535 |
|
03-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Always initialize generic fbdev emulation Initialize the generic fbdev emulation even if it has been disabled on the kernel command line. The hotplug and mode initialization will fail accordingly. The kernel parameter can still be changed at runtime and the emulation will initialize after hotplugging the connector. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-20-tzimmermann@suse.de
|
#
93e81e38 |
|
03-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb_helper: Minimize damage-helper overhead Pull the test for fb_dirty into the caller to avoid extra work if no callback has been set. In this case no damage handling is required and no damage area needs to be computed. Print a warning if the damage worker runs without getting an fb_dirty callback. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-19-tzimmermann@suse.de
|
#
98378091 |
|
03-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Perform all fbdev I/O with the same implementation Implement the fbdev's read/write helpers with the same functions. Use the generic fbdev's code as template. Convert all drivers. DRM's fb helpers must implement regular I/O functionality in struct fb_ops and possibly perform a damage update. Handle all this in the same functions and convert drivers. The functionality has been used as part of the generic fbdev code for some time. The drivers don't set struct drm_fb_helper.fb_dirty, so they will not be affected by damage handling. For I/O memory, fb helpers now provide drm_fb_helper_cfb_read() and drm_fb_helper_cfb_write(). Several drivers require these. Until now tegra used I/O read and write, although the memory buffer appears to be in system memory. So use _sys_ helpers now. v3: * fix docs (Javier) v2: * rebase onto vmwgfx changes Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-18-tzimmermann@suse.de
|
#
3add5f97 |
|
03-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Call fb_sync in I/O functions Call struct fb_ops.fb_sync in drm_fbdev_{read,write}() to mimic the behavior of fbdev. Fbdev implementations of fb_read and fb_write in struct fb_ops invoke fb_sync to synchronize with outstanding operations before I/O. Doing the same in DRM implementations will allow us to use them throughout DRM drivers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-17-tzimmermann@suse.de
|
#
f231af49 |
|
03-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Disconnect damage worker from update logic The fbdev helpers implement a damage worker that forwards fbdev updates to the DRM driver. The worker's update logic depends on the generic fbdev emulation. Separate the two via function pointer. The generic fbdev emulation sets struct drm_fb_helper_funcs.fb_dirty, a new callback that hides the update logic from the damage worker. It's not possible to use the generic logic with other fbdev emulation, because it contains additional code for the shadow buffering that the generic emulation employs. DRM drivers with internal fbdev emulation can set fb_dirty to their own implementation if they require damage handling; although no such drivers currently exist. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-16-tzimmermann@suse.de
|
#
afb0ff78 |
|
03-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Rename drm_fb_helper_unregister_fbi() to use _info postfix Rename drm_fb_helper_unregister_fbi() to drm_fb_helper_unregister_info() as part of unifying the naming within fbdev helpers. Adapt drivers. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-15-tzimmermann@suse.de
|
#
7fd50bc3 |
|
03-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Rename drm_fb_helper_alloc_fbi() to use _info postfix Rename drm_fb_helper_alloc_fbi() to drm_fb_helper_alloc_info() as part of unifying the naming within fbdev helpers. Adapt drivers. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-14-tzimmermann@suse.de
|
#
9877d8f6 |
|
03-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb_helper: Rename field fbdev to info in struct drm_fb_helper Rename struct drm_fb_helper.fbdev to info. The current name is misleading as it overlaps with generic fbdev naming conventions. Adapt to the usual naming in fbdev drivers by calling the field 'info'. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-13-tzimmermann@suse.de
|
#
ba715932 |
|
08-Jul-2022 |
Geert Uytterhoeven <geert@linux-m68k.org> |
drm/fb-helper: Add support for DRM_FORMAT_C[124] Add support for color-indexed frame buffer formats with two, four, and sixteen colors to the DRM framebuffer helper functions: 1. Add support for 1, 2, and 4 bits per pixel to the damage helper, 2. For color-indexed modes, the length of the color bitfields must be set to the color depth, else the logo code may pick a logo with too many colors. Drop the incorrect DAC width comment, which originates from the i915 driver. 3. Accept C[124] modes when validating or filling in struct fb_var_screeninfo, and use the correct number of bits per pixel. 4. Set the visual to FB_VISUAL_PSEUDOCOLOR for all color-indexed modes. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/db3e80b445df661ff0cd7e698507a8d24a4c867e.1657294931.git.geert@linux-m68k.org
|
#
ae25885b |
|
20-Jun-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Fix out-of-bounds access Clip memory range to screen-buffer size to avoid out-of-bounds access in fbdev deferred I/O's damage handling. Fbdev's deferred I/O can only track pages. From the range of pages, the damage handler computes the clipping rectangle for the display update. If the fbdev screen buffer ends near the beginning of a page, that page could contain more scanlines. The damage handler would then track these non-existing scanlines as dirty and provoke an out-of-bounds access during the screen update. Hence, clip the maximum memory range to the size of the screen buffer. While at it, rename the variables min/max to min_off/max_off in drm_fb_helper_deferred_io(). This avoids confusion with the macros of the same name. Reported-by: Nuno Gonçalves <nunojpg@gmail.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Nuno Gonçalves <nunojpg@gmail.com> Fixes: 67b723f5b742 ("drm/fb-helper: Calculate damaged area in separate helper") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: <stable@vger.kernel.org> # v5.18+ Link: https://patchwork.freedesktop.org/patch/msgid/20220621104617.8817-1-tzimmermann@suse.de
|
#
720cf96d |
|
13-Jun-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm: Drop drm_framebuffer.h from drm_crtc.h drm_crtc.h has no need for drm_frambuffer.h, so don't include it. Avoids useless rebuilds of the entire universe when touching drm_framebuffer.h. Quite a few placs do currently depend on drm_framebuffer.h without actually including it directly. All of those need to be fixed up. v2: Fix up msm some more v2: Deal with ingenic and shmobile as well Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220614095449.29311-1-ville.syrjala@linux.intel.com Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Jani Nikula <jani.nikula@intel.com>
|
#
e80eec1b |
|
28-Apr-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev: Rename pagelist to pagereflist for deferred I/O Rename various instances of pagelist to pagereflist. The list now stores pageref structures, so the new name is more appropriate. In their write-back helpers, several fbdev drivers refer to the pageref list in struct fb_deferred_io instead of using the one supplied as argument to the function. Convert them over to the supplied one. It's the same instance, so no change of behavior occurs. v4: * fix commit message (Javier) Suggested-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220429100834.18898-5-tzimmermann@suse.de
|
#
56c134f7 |
|
28-Apr-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev: Track deferred-I/O pages in pageref struct Store the per-page state for fbdev's deferred I/O in struct fb_deferred_io_pageref. Maintain a list of pagerefs for the pages that have to be written back to video memory. Update all affected drivers. As with pages before, fbdev acquires a pageref when an mmaped page of the framebuffer is being written to. It holds the pageref in a list of all currently written pagerefs until it flushes the written pages to video memory. Writeback occurs periodically. After writeback fbdev releases all pagerefs and builds up a new dirty list until the next writeback occurs. Using pagerefs has a number of benefits. For pages of the framebuffer, the deferred I/O code used struct page.lru as an entry into the list of dirty pages. The lru field is owned by the page cache, which makes deferred I/O incompatible with some memory pages (e.g., most notably DRM's GEM SHMEM allocator). struct fb_deferred_io_pageref now provides an entry into a list of dirty framebuffer pages, freeing lru for use with the page cache. Drivers also assumed that struct page.index is the page offset into the framebuffer. This is not true for DRM buffers, which are located at various offset within a mapped area. struct fb_deferred_io_pageref explicitly stores an offset into the framebuffer. struct page.index is now only the page offset into the mapped area. These changes will allow DRM to use fbdev deferred I/O without an intermediate shadow buffer. v3: * use pageref->offset for sorting * fix grammar in comment v2: * minor fixes in commit message Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220429100834.18898-3-tzimmermann@suse.de
|
#
59055851 |
|
28-Apr-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev: Put mmap for deferred I/O into drivers The fbdev mmap function fb_mmap() unconditionally overrides the driver's implementation if deferred I/O has been activated. This makes it hard to implement mmap with anything but a vmalloc()'ed software buffer. That is specifically a problem for DRM, where video memory is maintained by a memory manager. Leave the mmap handling to drivers and expect them to call the helper for deferred I/O by thmeselves. v4: * unlock mm_lock in fb_mmap() error path (Dan) v3: * fix warning if fb_mmap is missing (kernel test robot) v2: * print a helpful error message if the defio setup is incorrect (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220429100834.18898-2-tzimmermann@suse.de
|
#
cccd73d6 |
|
16-Feb-2022 |
Lucas De Marchi <lucas.demarchi@intel.com> |
iosys-map: Add offset to iosys_map_memcpy_to() In certain situations it's useful to be able to write to an offset of the mapping. Add a dst_offset to iosys_map_memcpy_to(). Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220216174147.3073235-2-lucas.demarchi@intel.com
|
#
ded74caf |
|
09-Feb-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Clip damage area horizontally Clip the damage area horizontally if only a single scanline has been changed. This is helpful to reduce the memcpy overhead for small writes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220209161617.3553-6-tzimmermann@suse.de
|
#
fe23b56f |
|
09-Feb-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Clip damage area to written memory range Write helpers used to mark the complete screen as dirty. This is wasteful for writes that only change a small portion of the screen. Fix the problem by computing the damaged area from the written memory range and perform damage handling accordingly. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220209161617.3553-5-tzimmermann@suse.de
|
#
67b723f5 |
|
09-Feb-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Calculate damaged area in separate helper Add drm_fb_helper_memory_range_to_clip(), a helper function that accepts an linear range of video memory and converts it into a rectangle. The computed rectangle describes the damaged area in terms of scanlines and pixels per scanline. While at it, make the code more readable by using struct drm_rect and related helpers. The code was previously part of the deferred I/O helpers, but is also useful for damage handling of regular write operations. Update the deferred I/O code to use the new function. v2: * rename helper (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220209161617.3553-4-tzimmermann@suse.de
|
#
aa15c677 |
|
09-Feb-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Fix vertical damage clipping Don't clip the damage rectangle against the viewport. This only works if the viewport is located at the beginning of the video memory and the video memory doesn't extend the screen (i.e., if there's no overallocation). Fbdev emulation transfers data from write operations into a possible shadow buffer, then into a GEM buffer object, and finally via graphics driver onto the screen. If callers write outside the currently visible area, clipping the damage rectangle against the viewport will loose these updates in the shadow buffer and the fbdev's buffer object will contain stale data. Panning the viewport to the stale area of the buffer will display obsolete data. Instead, mark all written areas as damaged, so that the damage handler updates the buffer object from the shadow buffer for all such areas. The graphics driver's later has the option of clipping the damaged area against the viewport when updating the screen from the buffer object. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220209161617.3553-3-tzimmermann@suse.de
|
#
a3c286dc |
|
09-Feb-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Fix clip rectangle height Computing the clip rectangle is prone to off-by-one errors when writes happen near the end of a memory page. Point the end of the memory area to the first trailing byte, so that (end - start) returns the area's length. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220209161617.3553-2-tzimmermann@suse.de
|
#
7938f421 |
|
04-Feb-2022 |
Lucas De Marchi <lucas.demarchi@intel.com> |
dma-buf-map: Rename to iosys-map Rename struct dma_buf_map to struct iosys_map and corresponding APIs. Over time dma-buf-map grew up to more functionality than the one used by dma-buf: in fact it's just a shim layer to abstract system memory, that can be accessed via regular load and store, from IO memory that needs to be acessed via arch helpers. The idea is to extend this API so it can fulfill other needs, internal to a single driver. Example: in the i915 driver it's desired to share the implementation for integrated graphics, which uses mostly system memory, with discrete graphics, which may need to access IO memory. The conversion was mostly done with the following semantic patch: @r1@ @@ - struct dma_buf_map + struct iosys_map @r2@ @@ ( - DMA_BUF_MAP_INIT_VADDR + IOSYS_MAP_INIT_VADDR | - dma_buf_map_set_vaddr + iosys_map_set_vaddr | - dma_buf_map_set_vaddr_iomem + iosys_map_set_vaddr_iomem | - dma_buf_map_is_equal + iosys_map_is_equal | - dma_buf_map_is_null + iosys_map_is_null | - dma_buf_map_is_set + iosys_map_is_set | - dma_buf_map_clear + iosys_map_clear | - dma_buf_map_memcpy_to + iosys_map_memcpy_to | - dma_buf_map_incr + iosys_map_incr ) @@ @@ - #include <linux/dma-buf-map.h> + #include <linux/iosys-map.h> Then some files had their includes adjusted and some comments were update to remove mentions to dma-buf-map. Since this is not specific to dma-buf anymore, move the documentation to the "Bus-Independent Device Accesses" section. v2: - Squash patches v3: - Fix wrong removal of dma-buf.h from MAINTAINERS - Move documentation from dma-buf.rst to device-io.rst v4: - Change documentation title and level Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220204170541.829227-1-lucas.demarchi@intel.com
|
#
cd9f7f7a |
|
31-Jan-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Mark screen buffers in system memory with FBINFO_VIRTFB Mark screen buffers in system memory with FBINFO_VIRTFB. Otherwise, fbdev deferred I/O marks mmap'ed areas of system memory with VM_IO. (There's an inverse relationship between the two flags.) For shadow buffers, also set the FBINFO_READS_FAST hint. v3: * change FB_ to FBINFO_ in commit description v2: * updated commit description (Daniel) * added Fixes tag Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: d536540f304c ("drm/fb-helper: Add generic fbdev emulation .fb_probe function") Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.19+ Link: https://patchwork.freedesktop.org/patch/msgid/20220201115305.9333-1-tzimmermann@suse.de
|
#
18ac700d |
|
10-Nov-2021 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Allocate shadow buffer of surface height Allocating a shadow buffer of the height of the buffer object does not support fbdev overallocation. Use surface height instead. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211110103702.374-7-tzimmermann@suse.de
|
#
842470c4 |
|
20-Oct-2021 |
Javier Martinez Canillas <javierm@redhat.com> |
Revert "drm/fb-helper: improve DRM fbdev emulation device names" This reverts commit b3484d2b03e4c940a9598aa841a52d69729c582a. That change attempted to improve the DRM drivers fbdev emulation device names to avoid having confusing names like "simpledrmdrmfb" in /proc/fb. But unfortunately, there are user-space programs such as pm-utils that match against the fbdev names and so broke after the mentioned commit. Since the names in /proc/fb are used by tools that consider it an uAPI, let's restore the old names even when this lead to silly names like the one mentioned above. Fixes: b3484d2b03e4 ("drm/fb-helper: improve DRM fbdev emulation device names") Reported-by: Johannes Stezenbach <js@sig21.net> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020165740.3011927-1-javierm@redhat.com
|
#
76fd2c37 |
|
02-Oct-2021 |
Sean Paul <seanpaul@chromium.org> |
Revert "drm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()" This reverts commit 7c5f2eecc21f44fba1b1f13ce09c2533db9d781a. This patchset breaks on intel platforms and was previously NACK'd by Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fernando Ramos <greenfoo@u92.eu> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-13-sean@poorly.run
|
#
7c5f2eec |
|
24-Sep-2021 |
Fernando Ramos <greenfoo@u92.eu> |
drm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() As requested in Documentation/gpu/todo.rst, replace driver calls to drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and DRM_MODESET_LOCK_ALL_END() Signed-off-by: Fernando Ramos <greenfoo@u92.eu> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-5-greenfoo@u92.eu
|
#
b693e429 |
|
05-Oct-2021 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fbdev: Clamp fbdev surface size if too large Clamp the fbdev surface size of the available maximumi height to avoid failing to init console emulation. An example error is shown below. bad framebuffer height 2304, should be >= 768 && <= 768 [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0 simple-framebuffer simple-framebuffer.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-22) This is especially a problem with drivers that have very small screen sizes and cannot over-allocate at all. v2: * reduce warning level (Ville) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 11e8f5fd223b ("drm: Add simpledrm driver") Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reported-by: Amanoel Dawod <kernel@amanoeldawod.com> Reported-by: Zoltán Kővágó <dirty.ice.hu@gmail.com> Reported-by: Michael Stapelberg <michael+lkml@stapelberg.ch> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maxime Ripard <maxime@cerno.tech> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.14+ Link: https://patchwork.freedesktop.org/patch/msgid/20211005070355.7680-1-tzimmermann@suse.de Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
0ae865ef |
|
30-Jul-2021 |
Cai Huoqing <caihuoqing@baidu.com> |
drm: Fix typo in comments fix typo for drm v1->v2: respin with the change "iff ==> implies that" Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210730132729.376-1-caihuoqing@baidu.com
|
#
b3484d2b |
|
25-May-2021 |
Javier Martinez Canillas <javierm@redhat.com> |
drm/fb-helper: improve DRM fbdev emulation device names Framebuffer devices that are registered by DRM drivers for fbdev emulation have a "drmfb" suffix in their name. But makes them to be quite confusing for drivers that already have "drm" in their name: $ cat /proc/fb 0 rockchipdrmdrmfb $ cat /proc/fb 0 simpledrmdrmfb Also, there isn't a lot of value in adding these "drmfb" suffices to their names, since users shouldn't really care if the FB devices were registered by a real fbdev driver or a DRM driver using the fbdev emulation. What programs should be interested about is if there's a DRM device, and there are better ways to query that info than reading this procfs entry. So let's just remove the suffix, which leads to much better device names: $ cat /proc/fb 0 rockchipdrm $ cat /proc/fb 0 simpledrm Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210525151313.3379622-1-javierm@redhat.com
|
#
874a52f9 |
|
27-Feb-2021 |
Tong Zhang <ztong0001@gmail.com> |
drm/fb-helper: only unmap if buffer not null drm_fbdev_cleanup() can be called when fb_helper->buffer is null, hence fb_helper->buffer should be checked before calling drm_client_buffer_vunmap(). This buffer is also checked in drm_client_framebuffer_delete(), so we should also do the same thing for drm_client_buffer_vunmap(). [ 199.128742] RIP: 0010:drm_client_buffer_vunmap+0xd/0x20 [ 199.129031] Code: 43 18 48 8b 53 20 49 89 45 00 49 89 55 08 5b 44 89 e0 41 5c 41 5d 41 5e 5d c3 0f 1f 00 53 48 89 fb 48 8d 7f 10 e8 73 7d a1 ff <48> 8b 7b 10 48 8d 73 18 5b e9 75 53 fc ff 0 f 1f 44 00 00 48 b8 00 [ 199.130041] RSP: 0018:ffff888103f3fc88 EFLAGS: 00010282 [ 199.130329] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffffffff8214d46d [ 199.130733] RDX: 1ffffffff079c6b9 RSI: 0000000000000246 RDI: ffffffff83ce35c8 [ 199.131119] RBP: ffff888103d25458 R08: 0000000000000001 R09: fffffbfff0791761 [ 199.131505] R10: ffffffff83c8bb07 R11: fffffbfff0791760 R12: 0000000000000000 [ 199.131891] R13: ffff888103d25468 R14: ffff888103d25418 R15: ffff888103f18120 [ 199.132277] FS: 00007f36fdcbb6a0(0000) GS:ffff88815b400000(0000) knlGS:0000000000000000 [ 199.132721] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 199.133033] CR2: 0000000000000010 CR3: 0000000103d26000 CR4: 00000000000006f0 [ 199.133420] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 199.133807] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 199.134195] Call Trace: [ 199.134333] drm_fbdev_cleanup+0x179/0x1a0 [ 199.134562] drm_fbdev_client_unregister+0x2b/0x40 [ 199.134828] drm_client_dev_unregister+0xa8/0x180 [ 199.135088] drm_dev_unregister+0x61/0x110 [ 199.135315] mgag200_pci_remove+0x38/0x52 [mgag200] [ 199.135586] pci_device_remove+0x62/0xe0 [ 199.135806] device_release_driver_internal+0x148/0x270 [ 199.136094] driver_detach+0x76/0xe0 [ 199.136294] bus_remove_driver+0x7e/0x100 [ 199.136521] pci_unregister_driver+0x28/0xf0 [ 199.136759] __x64_sys_delete_module+0x268/0x300 [ 199.137016] ? __ia32_sys_delete_module+0x300/0x300 [ 199.137285] ? call_rcu+0x3e4/0x580 [ 199.137481] ? fpregs_assert_state_consistent+0x4d/0x60 [ 199.137767] ? exit_to_user_mode_prepare+0x2f/0x130 [ 199.138037] do_syscall_64+0x33/0x40 [ 199.138237] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 199.138517] RIP: 0033:0x7f36fdc3dcf7 Signed-off-by: Tong Zhang <ztong0001@gmail.com> Fixes: 763aea17bf57 ("drm/fb-helper: Unmap client buffer during shutdown") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Maxime Ripard <mripard@kernel.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.11+ Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210228044625.171151-1-ztong0001@gmail.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
#
bf22c9ec |
|
02-Feb-2021 |
Christoph Hellwig <hch@lst.de> |
drm: remove drm_fb_helper_modinit drm_fb_helper_modinit has a lot of boilerplate for what is not very simple functionality. Just open code it in the only caller using IS_ENABLED and IS_MODULE, and skip the find_module check as a request_module is harmless if the module is already loaded (and not other caller has this find_module check either). Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jessica Yu <jeyu@kernel.org>
|
#
14c1e12b |
|
11-Dec-2020 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Add a FIXME that generic_setup is very confusing I tried to fix this for real, but it's very sprawling and lots of drivers get this mildly wrong one way or the other. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-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: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201211161113.3350061-2-daniel.vetter@ffwll.ch
|
#
1b897743 |
|
11-Dec-2020 |
Tomi Valkeinen <tomi.valkeinen@ti.com> |
drm: add legacy support for using degamma for gamma The DRM core handles legacy gamma-set ioctl by setting GAMMA_LUT and clearing CTM and DEGAMMA_LUT. This works fine on HW where we have either: degamma -> ctm -> gamma -> out or ctm -> gamma -> out However, if the HW has gamma table before ctm, the atomic property should be DEGAMMA_LUT, and thus we have: degamma -> ctm -> out This is fine for userspace which sets gamma table using the properties, as the userspace can check for the existence of gamma & degamma, but the legacy gamma-set ioctl does not work. Change the DRM core to use DEGAMMA_LUT instead of GAMMA_LUT when the latter is unavailable. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201211114237.213288-3-tomi.valkeinen@ti.com
|
#
0a260e73 |
|
03-Dec-2020 |
Chuhong Yuan <hslester96@gmail.com> |
drm/fb-helper: Add missed unlocks in setcmap_legacy() setcmap_legacy() does not call drm_modeset_unlock_all() in some exits, add the missed unlocks with goto to fix it. Fixes: 964c60063bff ("drm/fb-helper: separate the fb_setcmap helper into atomic and legacy paths") Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201203144248.418281-1-hslester96@gmail.com
|
#
32228ff5 |
|
20-Nov-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Acquire modeset lock around shadow-buffer flushing Flushing the fbdev's shadow buffer requires vmap'ing the BO memory, which in turn requires pinning the BO. While being pinned, the BO cannot be moved into VRAM for scanout. Consequently, a concurrent modeset operation that involves the fbdev framebuffer would likely fail. Resolve this problem be acquiring the modeset lock of the planes that use the fbdev framebuffer. On non-atomic drivers, also acquire the mode-config lock. This serializes the flushing of the framebuffer with concurrent modeset operations. v2: * only acquire struct drm_fb_helper.lock in damage blitter (Daniel, Christian) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Maxime Ripard <mripard@kernel.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-11-tzimmermann@suse.de
|
#
7d4d269c |
|
20-Nov-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Copy dma-buf map before flushing shadow fb Copy the vmap()'ed instance of struct dma_buf_map before modifying it, in case the implementation of vunmap() depends on the exact address. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Maxime Ripard <mripard@kernel.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-10-tzimmermann@suse.de
|
#
4270d6f6 |
|
20-Nov-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Restore damage area upon errors If the damage handling fails, restore the damage area. The next invocation of the damage worker will then perform the update. v3: * Use drm_WARN_ONCE() with an error message to print warning v2: * print a single warning if dirty callback fails (Daniel, Sebastian) * update comment Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Maxime Ripard <mripard@kernel.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-9-tzimmermann@suse.de
|
#
1d46491d |
|
20-Nov-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Move damage blit code and its setup into separate routine Introduce a separate function for the blit code and its vmap setup. Done in preparation of additional changes. No functional changes are made. v3: * Use drm_WARN_ONCE() with an error message to print warning v2: * print a single warning if damage blitter fails Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-8-tzimmermann@suse.de
|
#
fd2d8565 |
|
20-Nov-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Separate shadow-buffer flushing and calling dirty callback Flushing the shadow framebuffer and invoking the dirty callback are two separate operations, so do them separately. The flush operation is paired with calls to vmap and vunmap. They are not needed for the dirty callback, which performs its own invocations if necessary. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-7-tzimmermann@suse.de
|
#
2b5f31aa |
|
20-Nov-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Return early in damage worker Returning early in the damage worker if no update is required. Makes the code more readable. No functional changes are being made. v3: * s/dirty/damage in commit message (Sam) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-6-tzimmermann@suse.de
|
#
9622349e |
|
20-Nov-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Rename dirty worker to damage worker The dirty worker handles all damage updates, instead of just calling the framebuffer's dirty callback. Rename it to damage worker. Also rename related variables accordingly. No functional changes are made. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-5-tzimmermann@suse.de
|
#
763aea17 |
|
20-Nov-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Unmap client buffer during shutdown The fbdev helper's generic probe function establishes a mapping for framebuffers without shadow buffer. The clean-up function did not unmap the buffer object. Add the unmap operation. As fbdev devices are usally released during system shutdown, this has not been a problem in practice. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-3-tzimmermann@suse.de
|
#
a102172c |
|
20-Nov-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Call dirty helper after writing to fbdev If fbdev uses a shadow framebuffer, call the damage handler. Otherwise the update might not make it to the screen. v2: * mark virtual screen as dirty (Ville) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 222ec45f4c69 ("drm/fb_helper: Support framebuffers in I/O memory") Acked-by: Maxime Ripard <mripard@kernel.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: virtualization@lists.linux-foundation.org Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-2-tzimmermann@suse.de
|
#
a3230bd7 |
|
10-Nov-2020 |
Geert Uytterhoeven <geert+renesas@glider.be> |
drm/fb_helper: Use min_t() to handle size_t and unsigned long On arm32: drivers/gpu/drm/drm_fb_helper.c: In function ‘fb_read_screen_base’: include/linux/minmax.h:18:28: warning: comparison of distinct pointer types lacks a cast ... drivers/gpu/drm/drm_fb_helper.c:2041:22: note: in expansion of macro ‘min’ 2041 | size_t alloc_size = min(count, PAGE_SIZE); | ^~~ drivers/gpu/drm/drm_fb_helper.c: In function ‘fb_write_screen_base’: include/linux/minmax.h:18:28: warning: comparison of distinct pointer types lacks a cast ... drivers/gpu/drm/drm_fb_helper.c:2115:22: note: in expansion of macro ‘min’ 2115 | size_t alloc_size = min(count, PAGE_SIZE); | ^~~ Indeed, on 32-bit size_t is "unsigned int", not "unsigned long". Fixes: 222ec45f4c69dfa8 ("drm/fb_helper: Support framebuffers in I/O memory") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201110090119.2667326-1-geert+renesas@glider.be
|
#
222ec45f |
|
03-Nov-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb_helper: Support framebuffers in I/O memory At least sparc64 requires I/O-specific access to framebuffers. This patch updates the fbdev console accordingly. For drivers with direct access to the framebuffer memory, the callback functions in struct fb_ops test for the type of memory and call the rsp fb_sys_ of fb_cfb_ functions. Read and write operations are implemented internally by DRM's fbdev helper. For drivers that employ a shadow buffer, fbdev's blit function retrieves the framebuffer address as struct dma_buf_map, and uses dma_buf_map interfaces to access the buffer. The bochs driver on sparc64 uses a workaround to flag the framebuffer as I/O memory and avoid a HW exception. With the introduction of struct dma_buf_map, this is not required any longer. The patch removes the rsp code from both, bochs and fbdev. v7: * use min_t(size_t,) (kernel test robot) * return the number of bytes read/written, if any (fbdev testcase) v5: * implement fb_read/fb_write internally (Daniel, Sam) v4: * move dma_buf_map changes into separate patch (Daniel) * TODO list: comment on fbdev updates (Daniel) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Tested-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-11-tzimmermann@suse.de
|
#
a8595556 |
|
03-Nov-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/gem: Store client buffer mappings as struct dma_buf_map Kernel DRM clients now store their framebuffer address in an instance of struct dma_buf_map. Depending on the buffer's location, the address refers to system or I/O memory. Callers of drm_client_buffer_vmap() receive a copy of the value in the call's supplied arguments. It can be accessed and modified with dma_buf_map interfaces. v6: * don't call page_to_phys() on framebuffers in I/O memory; warn instead (Daniel) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-9-tzimmermann@suse.de
|
#
a76fa354 |
|
07-Oct-2020 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Add locking to sysrq handling We didn't take the kernel_fb_helper_lock mutex, which protects that code. While at it, simplify the code - inline the function (originally shared with kgdb I think) - drop the error tracking and all the complications - drop the pointless early out, it served nothing Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> 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> Link: https://patchwork.freedesktop.org/patch/msgid/20201007133036.1541639-1-daniel.vetter@ffwll.ch
|
#
a27eb0cb |
|
18-Aug-2020 |
Andrzej Pietrasiewicz <andrzej.p@collabora.com> |
tty/sysrq: Extend the sysrq_key_table to cover capital letters All slots in sysrq_key_table[] are either used, reserved or at least commented with their intended use. This patch adds capital letter versions available, which means adding 26 more entries. For already existing SysRq operations the user presses Alt-SysRq-<key>, and for the newly added ones Alt-Shift-SysRq-<key>. Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20200818112825.6445-2-andrzej.p@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
2a1658bf |
|
09-Jul-2020 |
Sam Ravnborg <sam@ravnborg.org> |
drm/drm_fb_helper: fix fbdev with sparc64 Recent kernels have been reported to panic using the bochs_drm framebuffer under qemu-system-sparc64 which was bisected to commit 7a0483ac4ffc ("drm/bochs: switch to generic drm fbdev emulation"). The backtrace indicates that the shadow framebuffer copy in drm_fb_helper_dirty_blit_real() is trying to access the real framebuffer using a virtual address rather than use an IO access typically implemented using a physical (ASI_PHYS) access on SPARC. The fix is to replace the memcpy with memcpy_toio() from io.h. memcpy_toio() uses writeb() where the original fbdev code used sbus_memcpy_toio(). The latter uses sbus_writeb(). The difference between writeb() and sbus_memcpy_toio() is that writeb() writes bytes in little-endian, where sbus_writeb() writes bytes in big-endian. As endian does not matter for byte writes they are the same. So we can safely use memcpy_toio() here. Note that this only fixes bochs, in general fbdev helpers still have issues with mixing up system memory and __iomem space. Fixing that will require a lot more work. v3: - Improved changelog (Daniel) - Added FIXME to fbdev_use_iomem (Daniel) v2: - Added missing __iomem cast (kernel test robot) - Made changelog readable and fix typos (Mark) - Add flag to select iomem - and set it in the bochs driver Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reported-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reported-by: kernel test robot <lkp@intel.com> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: sparclinux@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200709193016.291267-1-sam@ravnborg.org Link: https://patchwork.freedesktop.org/patch/msgid/20200725191012.GA434957@ravnborg.org
|
#
8f9fcb34 |
|
07-Jul-2020 |
Suraj Upadhyay <usuraj35@gmail.com> |
drm: fb-helper: Convert logging to drm_* functions. Change logging information from dev_info() to drm_info(). Signed-off-by: Suraj Upadhyay <usuraj35@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/0d37c7a614eb0885f0f0bed18e48a4d26b345a8e.1594136880.git.usuraj35@gmail.com
|
#
dc5bdb68 |
|
24-Jun-2020 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Fix vt restore In the past we had a pile of hacks to orchestrate access between fbdev emulation and native kms clients. We've tried to streamline this, by always preferring the kms side above fbdev calls when a drm master exists, because drm master controls access to the display resources. Unfortunately this breaks existing userspace, specifically Xorg. When exiting Xorg first restores the console to text mode using the KDSET ioctl on the vt. This does nothing, because a drm master is still around. Then it drops the drm master status, which again does nothing, because logind is keeping additional drm fd open to be able to orchestrate vt switches. In the past this is the point where fbdev was restored, as part of the ->lastclose hook on the drm side. Now to fix this regression we don't want to go back to letting fbdev restore things whenever it feels like, or to the pile of hacks we've had before. Instead try and go with a minimal exception to make the KDSET case work again, and nothing else. This means that if userspace does a KDSET call when switching between graphical compositors, there will be some flickering with fbcon showing up for a bit. But a) that's not a regression and b) userspace can fix it by improving the vt switching dance - logind should have all the information it needs. While pondering all this I'm also wondering wheter we should have a SWITCH_MASTER ioctl to allow race-free master status handover. But that's for another day. v2: Somehow forgot to cc all the fbdev people. v3: Fix typo Alex spotted. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208179 Cc: shlomo@fastmail.com Reported-and-Tested-by: shlomo@fastmail.com Cc: Michel Dänzer <michel@daenzer.net> Fixes: 64914da24ea9 ("drm/fbdev-helper: don't force restores") Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.7+ Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Nathan Chancellor <natechancellor@gmail.com> Cc: Qiujun Huang <hqjagain@gmail.com> Cc: Peter Rosin <peda@axentia.se> Cc: linux-fbdev@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200624092910.3280448-1-daniel.vetter@ffwll.ch
|
#
c1a01f29 |
|
13-May-2020 |
Emil Velikov <emil.l.velikov@gmail.com> |
drm: constify sysrq_key_op With earlier commits, the API no longer discards the const-ness of the sysrq_key_op. As such we can add the notation. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: linux-kernel@vger.kernel.org Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Link: https://lore.kernel.org/r/20200513214351.2138580-8-emil.l.velikov@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
1aed9509 |
|
08-Apr-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Remove return value from drm_fbdev_generic_setup() Generic fbdev emulation is a DRM client. Drivers should invoke the setup function, but not depend on its success. Hence remove the return value. v3: * document stricter requirements for call sequence v2: * warn if fbdev device has not been registered yet * document the new behavior * convert the existing warning to the new dev_ interface Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200408082641.590-11-tzimmermann@suse.de
|
#
1a8bf67d |
|
26-Mar-2020 |
Hans de Goede <hdegoede@redhat.com> |
drm/fb-helper: Add TODO for making drm_fb_helper_alloc_fbi fill apertures Currently drivers using drm_fbdev_generic_setup() end up with a single empty aperture in their fb_info struct. Not having the proper info in the apertures list causes register_framebuffer to not remove conflicting framebuffers, which some drivers currently workaround by manually calling drm_fb_helper_remove_conflicting_pci_framebuffers(). Add a TODO as a reminder that we need to fix this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200326151009.102377-1-hdegoede@redhat.com
|
#
2dea2d11 |
|
05-Mar-2020 |
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> |
drm: Remove unused arg from drm_fb_helper_init The max connector argument for drm_fb_helper_init() isn't used anymore hence remove it. All the drm_fb_helper_init() calls are modified with below sementic patch. @@ expression E1, E2, E3; @@ - drm_fb_helper_init(E1,E2, E3) + drm_fb_helper_init(E1,E2) Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-2-pankaj.laxminarayan.bharadiya@intel.com
|
#
c368ec19 |
|
04-Feb-2020 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/client: Rename _force to _locked Plus extend the kerneldoc a bit to explain how this should be used. With the previous patch to drop the force restore the main user of this function is not emphasis on the "I hold the internal master lock already" aspect, so rename the function to match. Suggested by Noralf. Cc: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204150146.2006481-4-daniel.vetter@ffwll.ch
|
#
64914da2 |
|
04-Feb-2020 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fbdev-helper: don't force restores Instead check for master status, in case we've raced. This is the last exception to the general rule that we restore fbcon only when there's no master active. Compositors are supposed to drop their master status before they switch to a different console back to text mode (or just switch to text mode directly, without a vt switch). This is known to break some subtests of kms_fbcon_fbt in igt, but they're just wrong - it does a graphics/text mode switch for the vt without updating the master status. Also add a comment to the drm_client->restore hook that this is expected going forward from all clients (there's currently just one). v2: Also drop the force in pan_display v3: Restore the _force to pan_display, this actually means _locked in that path. Spotted by Noralf. Cc: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204150146.2006481-3-daniel.vetter@ffwll.ch
|
#
f30e2777 |
|
30-Dec-2019 |
Geert Uytterhoeven <geert+renesas@glider.be> |
drm/fb-helper: Round up bits_per_pixel if possible When userspace requests a video mode parameter value that is not supported, frame buffer device drivers should round it up to a supported value, if possible, instead of just rejecting it. This allows applications to quickly scan for supported video modes. Currently this rule is not followed for the number of bits per pixel, causing e.g. "fbset -depth N" to fail, if N is smaller than the current number of bits per pixel. Fix this by returning an error only if bits per pixel is too large, and setting it to the current value otherwise. See also Documentation/fb/framebuffer.rst, Section 2 (Programmer's View of /dev/fb*"). Fixes: 865afb11949e5bf4 ("drm/fb-helper: reject any changes to the fbdev") Cc: stable@vger.kernel.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191230132734.4538-1-geert+renesas@glider.be
|
#
8c4ebd0d |
|
11-Dec-2019 |
Manasi Navare <manasi.d.navare@intel.com> |
drm: Handle connector tile support only for modes that match tile size DRM Fb driver expects multiple CRTCs if it sees connector->has_tile is set, but we need to handle tile support and look for multiple CRTCs only for the modes that match the tile size. The other modes should be able to be displayed without tile support or uisng single CRTC. This patch adds the check to match the tile size with requested mode to handle the tile support. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191211212433.18185-1-manasi.d.navare@intel.com
|
#
f33b9730 |
|
10-Dec-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/fb-helper: convert to drm device based logging Prefer drm_dbg_kms(), drm_info(), and drm_err() over all other logging. This is about KMS so switch to the KMS category while at it. Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191210123050.8799-3-jani.nikula@intel.com
|
#
b6ff753a |
|
03-Dec-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm: constify fb ops across all drivers Now that the fbops member of struct fb_info is const, we can start making the ops const as well. Cc: dri-devel@lists.freedesktop.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/59b43629ac60031c5bbf961d8c49695019bc9c6f.1575390740.git.jani.nikula@intel.com
|
#
57778075 |
|
28-Nov-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/fb-helper: don't preserve fb_ops across deferred IO use Deferred IO now preserves the fb_ops. v2: Remove the no-op vfree, drop a local var (Noralf) Cc: Noralf Trønnes <noralf@tronnes.org> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1eae0b23d4724d5702b886b6a061ec8219eb9284.1575022735.git.jani.nikula@intel.com
|
#
6821603a |
|
14-Nov-2019 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Remove drm_fb_helper_unlink_fbi() There are no callers of drm_fb_helper_unlink_fbi() left. Remove the function. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191114125106.28347-3-tzimmermann@suse.de
|
#
47734835 |
|
12-Nov-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: unexport drm_fb_helper_generic_probe Not sure we don't yet have this as a patch somewhere ... Motivation is that the automatic lifetime management of the generic fbdev code is quite tricky, and it'll get even more tricky. Allowing drivers to just use the fb_probe looks like a recipe for disaster. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191112175048.1581-1-daniel.vetter@ffwll.ch
|
#
8204f235 |
|
06-Nov-2019 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Remove drm_fb_helper_fbdev_{setup, teardown}() Both functions are unused and can be removed. Drivers should use drm_fbdev_generic_setup() instead. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191106124727.11641-3-tzimmermann@suse.de
|
#
8e86dee0 |
|
25-Oct-2019 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Remove drm_fb_helper_defio_init() and update docs There are no users of drm_fb_helper_defio_init(), so we can remove it. The documentation around defio support is a bit misleading and should mention compatibility issues with SHMEM helpers. Clarify this. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191025092759.13069-2-tzimmermann@suse.de
|
#
7baa77f1 |
|
10-Jul-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/fb-helper: Include prototype for drm_fb_helper_modinit() Sparse complains: drivers/gpu/drm/drm_fb_helper.c:2409:12: warning: symbol 'drm_fb_helper_modinit' was not declared. Should it be static? Include the header with the correct prototype. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190710125143.9965-1-ville.syrjala@linux.intel.com Reviewed-by: Sean Paul <sean@poorly.run>
|
#
01b947af |
|
05-Jul-2019 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Instanciate shadow FB if configured in device's mode_config Generic framebuffer emulation uses a shadow buffer for framebuffers with dirty() function. If drivers want to use the shadow FB without such a function, they can now set prefer_shadow or prefer_shadow_fbdev in their mode_config structures. The former flag is exported to userspace, the latter flag is fbdev-only. v3: * only schedule dirty worker if fbdev uses shadow fb * test shadow fb settings with boolean operators * use bool for struct drm_mode_config.prefer_shadow_fbdev * fix documentation comments Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/315834/ Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
#
87e281f8 |
|
03-Jul-2019 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Map DRM client buffer only when required This patch changes DRM clients to not map the buffer by default. The buffer, like any buffer object, should be mapped and unmapped when needed. An unmapped buffer object can be evicted to system memory and does not consume video ram until displayed. This allows to use generic fbdev emulation with drivers for low-memory devices, such as ast and mgag200. This change affects the generic framebuffer console. HW-based consoles map their console buffer once and keep it mapped. Userspace can mmap this buffer into its address space. The shadow-buffered framebuffer console only needs the buffer object to be mapped during updates. While not being updated from the shadow buffer, the buffer object can remain unmapped. Userspace will always mmap the shadow buffer. v2: * change DRM client to not map buffer by default * manually map client buffer for fbdev with HW framebuffer Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/315830/ Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
#
f458579e |
|
05-Jul-2019 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Instanciate shadow FB if configured in device's mode_config Generic framebuffer emulation uses a shadow buffer for framebuffers with dirty() function. If drivers want to use the shadow FB without such a function, they can now set prefer_shadow or prefer_shadow_fbdev in their mode_config structures. The former flag is exported to userspace, the latter flag is fbdev-only. v3: * only schedule dirty worker if fbdev uses shadow fb * test shadow fb settings with boolean operators * use bool for struct drm_mode_config.prefer_shadow_fbdev * fix documentation comments Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/315834/
|
#
cf1ca9ae |
|
03-Jul-2019 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fb-helper: Map DRM client buffer only when required This patch changes DRM clients to not map the buffer by default. The buffer, like any buffer object, should be mapped and unmapped when needed. An unmapped buffer object can be evicted to system memory and does not consume video ram until displayed. This allows to use generic fbdev emulation with drivers for low-memory devices, such as ast and mgag200. This change affects the generic framebuffer console. HW-based consoles map their console buffer once and keep it mapped. Userspace can mmap this buffer into its address space. The shadow-buffered framebuffer console only needs the buffer object to be mapped during updates. While not being updated from the shadow buffer, the buffer object can remain unmapped. Userspace will always mmap the shadow buffer. v2: * change DRM client to not map buffer by default * manually map client buffer for fbdev with HW framebuffer Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/315830/
|
#
a99076e8 |
|
18-Jun-2019 |
Maxime Ripard <mripard@kernel.org> |
drm/client: Change drm_client_panel_rotation name The drm_client_panel_rotation function has been used so far to set the default rotation based on the panel orientation. However, we can have more sources of information to make that decision, starting with the command line that we will introduce later in this series. Change the name to remove the panel mention. Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/8cb0f0d9569d41685bbf30a1538da6578cd2769b.1560783090.git-series.maxime.ripard@bootlin.com
|
#
1ff30dd8 |
|
11-Jun-2019 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm: Reverse lock order in pan_display_legacy() Acquiring drm_client_dev.modeset_mutex after the locks in drm_fb_helper.dev creates a deadlock with drm_setup_crtcs() as shown below: [ 4.959319] fbcon: radeondrmfb (fb0) is primary device [ 4.993952] Console: switching to colour frame buffer device 240x67 [ 4.994040] [ 4.994041] ====================================================== [ 4.994041] WARNING: possible circular locking dependency detected [ 4.994042] 5.2.0-rc4-1-default+ #39 Tainted: G E [ 4.994043] ------------------------------------------------------ [ 4.994043] systemd-udevd/369 is trying to acquire lock: [ 4.994044] 00000000fb622acb (&client->modeset_mutex){+.+.}, at: drm_fb_helper_pan_display+0x103/0x1f0 [drm_kms_helper] [ 4.994055] [ 4.994055] but task is already holding lock: [ 4.994055] 0000000028767ae4 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_lock+0x42/0xf0 [drm] [ 4.994072] [ 4.994072] which lock already depends on the new lock. [ 4.994072] [ 4.994072] [ 4.994072] the existing dependency chain (in reverse order) is: [ 4.994073] [ 4.994073] -> #3 (crtc_ww_class_mutex){+.+.}: [ 4.994076] lock_acquire+0x9e/0x170 [ 4.994079] __ww_mutex_lock.constprop.18+0x97/0xf40 [ 4.994080] ww_mutex_lock+0x30/0x90 [ 4.994091] drm_modeset_lock+0x42/0xf0 [drm] [ 4.994102] drm_modeset_lock_all_ctx+0x1f/0xe0 [drm] [ 4.994113] drm_modeset_lock_all+0x5e/0x1a0 [drm] [ 4.994163] intel_modeset_init+0x60b/0xda0 [i915] .. [ 4.994253] [ 4.994253] -> #2 (crtc_ww_class_acquire){+.+.}: [ 4.994255] lock_acquire+0x9e/0x170 [ 4.994270] drm_modeset_acquire_init+0xcc/0x100 [drm] [ 4.994280] drm_modeset_lock_all+0x44/0x1a0 [drm] [ 4.994320] intel_modeset_init+0x60b/0xda0 [i915] .. [ 4.994403] [ 4.994403] -> #1 (&dev->mode_config.mutex){+.+.}: [ 4.994405] lock_acquire+0x9e/0x170 [ 4.994408] __mutex_lock+0x62/0x8c0 [ 4.994413] drm_setup_crtcs+0x17c/0xc50 [drm_kms_helper] [ 4.994418] __drm_fb_helper_initial_config_and_unlock+0x34/0x530 [drm_kms_helper] [ 4.994450] radeon_fbdev_init+0x110/0x130 [radeon] .. [ 4.994535] [ 4.994535] -> #0 (&client->modeset_mutex){+.+.}: [ 4.994537] __lock_acquire+0xa85/0xe90 [ 4.994538] lock_acquire+0x9e/0x170 [ 4.994540] __mutex_lock+0x62/0x8c0 [ 4.994545] drm_fb_helper_pan_display+0x103/0x1f0 [drm_kms_helper] [ 4.994547] fb_pan_display+0x92/0x120 [ 4.994549] bit_update_start+0x1a/0x40 [ 4.994550] fbcon_switch+0x392/0x580 [ 4.994552] redraw_screen+0x12c/0x220 [ 4.994553] do_bind_con_driver.cold.30+0xe1/0x10d [ 4.994554] do_take_over_console+0x113/0x190 [ 4.994555] do_fbcon_takeover+0x58/0xb0 [ 4.994557] notifier_call_chain+0x47/0x70 [ 4.994558] blocking_notifier_call_chain+0x44/0x60 [ 4.994559] register_framebuffer+0x231/0x310 [ 4.994564] __drm_fb_helper_initial_config_and_unlock+0x2fd/0x530 [drm_kms_helper] [ 4.994590] radeon_fbdev_init+0x110/0x130 [radeon] .. This problem was introduced in d81294afe drm/fb-helper: Remove drm_fb_helper_crtc Reversing the lock ordering in pan_display_legacy() fixes the issue. Fixes: d81294afeecd ("drm/fb-helper: Remove drm_fb_helper_crtc") Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190611115716.7052-1-tzimmermann@suse.de
|
#
cf13909a |
|
08-Jun-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Move out modeset config code No functional changes, just moving code as-is and fixing includes. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190608152657.36613-4-noralf@tronnes.org
|
#
aafa9e06 |
|
08-Jun-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Prepare to move out modeset config code This prepares the modeset code so it can be moved out as-is in the next patch. v3: Remove stray newline Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190608152657.36613-3-noralf@tronnes.org
|
#
e5852bee |
|
08-Jun-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Remove drm_fb_helper_connector All drivers add all their connectors so there's no need to keep around an array of available connectors. Instead we just put the useable (not writeback) connectors in a temporary array using drm_client_for_each_connector_iter() everytime we probe the outputs. Other places where it's necessary to look at the connectors, we just iterate over them using the same iterator function. Rename functions which signature is changed since they will be moved to drm_client in a later patch. v6: Improve commit message (Sam Ravnborg) Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190608152657.36613-2-noralf@tronnes.org
|
#
aec3925f |
|
31-May-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Move out commit code Move the modeset commit code to drm_client_modeset. No changes except exporting API. v7: Export drm_client_panel_rotation() (Gerd Hoffmann) v2: Move to drm_client_modeset.c instead of drm_client.c Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190531140117.37751-5-noralf@tronnes.org
|
#
eade2a17 |
|
31-May-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Prepare to move out commit code This makes the necessary changes so the commit code can be moved out to drm_client as-is in the next patch. It's split up to ease review. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190531140117.37751-4-noralf@tronnes.org
|
#
d81294af |
|
31-May-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Remove drm_fb_helper_crtc struct drm_fb_helper_crtc is now just a wrapper around drm_mode_set so use that directly instead and attach it as a modeset array onto drm_client_dev. drm_fb_helper will use this array to store its modesets which means it will always initialize a drm_client, but it will not register the client (callbacks) unless it's the generic fbdev emulation. Code will later be moved to drm_client, so add code there in a new file drm_client_modeset.c with MIT license to match drm_fb_helper.c. The modeset connector array size is hardcoded for the cloned case to avoid having to pass in a value from the driver. A value of 8 is chosen to err on the safe side. This means that the max connector argument for drm_fb_helper_init() and drm_fb_helper_fbdev_setup() isn't used anymore, a todo entry for this is added. In pan_display_atomic() restore_fbdev_mode_force() is used instead of restore_fbdev_mode_atomic() because that one will later become internal to drm_client_modeset. Locking order: 1. drm_fb_helper->lock 2. drm_master_internal_acquire 3. drm_client_dev->modeset_mutex v6: Improve commit message (Sam Ravnborg) v3: - Use full drm_client_init/release for the modesets (Daniel Vetter) - drm_client_for_each_modeset: use lockdep_assert_held (Daniel Vetter) - Hook up to Documentation/gpu/drm-client.rst (Daniel Vetter) v2: - Add modesets array to drm_client (Daniel Vetter) - Use a new file for the modeset code (Daniel Vetter) - File has to be MIT licensed (Emmanuel Vadot) - Add copyrights from drm_fb_helper.c Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190531140117.37751-3-noralf@tronnes.org
|
#
0500c04e |
|
26-May-2019 |
Sam Ravnborg <sam@ravnborg.org> |
drm: drop use of drmP.h in drm/* The use of the drmP.h header file is deprecated. Remove use from all files in drm/* so people do not look there and follow a bad example. Build tested allyesconfig,allmodconfig on x86, arm etc. Including alpha that is as always more challenging than the rest. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Daniel Vetter <daniel@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Link: https://patchwork.freedesktop.org/patch/msgid/20190526173535.32701-8-sam@ravnborg.org
|
#
b0f986b4 |
|
15-May-2019 |
Maxime Ripard <mripard@kernel.org> |
drm: Remove users of drm_format_info_plane_cpp drm_format_info_plane_cpp() basically just returns the cpp array content found in the drm_format_info structure. Since it's pretty trivial, let's remove the function and have the users use the array directly Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/c0a78c87cd0410a1819edad2794ad06543c85bb5.1558002671.git-series.maxime.ripard@bootlin.com
|
#
24c478ea |
|
15-May-2019 |
Maxime Ripard <mripard@kernel.org> |
drm/fourcc: Pass the format_info pointer to drm_format_plane_cpp So far, the drm_format_plane_cpp function was operating on the format's fourcc and was doing a lookup to retrieve the drm_format_info structure and return the cpp. However, this is inefficient since in most cases, we will have the drm_format_info pointer already available so we shouldn't have to perform a new lookup. Some drm_fourcc functions also already operate on the drm_format_info pointer for that reason, so the API is quite inconsistent there. Let's follow the latter pattern and remove the extra lookup while being a bit more consistent. In order to be extra consistent, also rename that function to drm_format_info_plane_cpp and to a static function in the header to match the current policy. Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/32aa13e53dbc98a90207fd290aa8e79f785fb11e.1558002671.git-series.maxime.ripard@bootlin.com
|
#
05865769 |
|
15-May-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Fix drm_fb_helper_hotplug_event() NULL ptr argument drm_fb_helper_hotplug_event() should tolerate the fb_helper argument being NULL. Commit 03a9606e7fee ("drm/fb-helper: Avoid race with DRM userspace") introduced a fb_helper dereference before the NULL check. Fixup by moving the dereference after the NULL check. Fixes: 03a9606e7fee ("drm/fb-helper: Avoid race with DRM userspace") Reported-by: kbuild test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190515132925.48867-1-noralf@tronnes.org
|
#
c8de0d5f |
|
06-May-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Remove drm_fb_helper_crtc->{x, y, desired_mode} The values are already present in the modeset. This is done in preparation for the removal of struct drm_fb_helper_crtc. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190506180139.6913-5-noralf@tronnes.org
|
#
bc934755 |
|
06-May-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: No need to cache rotation and sw_rotations Getting rotation info is cheap so we can do it on demand. This is done in preparation for the removal of struct drm_fb_helper_crtc. Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190506180139.6913-4-noralf@tronnes.org
|
#
03a9606e |
|
06-May-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Avoid race with DRM userspace drm_fb_helper_is_bound() is used to check if DRM userspace is in control. This is done by looking at the fb on the primary plane. By the time fb-helper gets around to committing, it's possible that the facts have changed. Avoid this race by holding the drm_device->master_mutex lock while committing. When DRM userspace does its first open, it will now wait until fb-helper is done. The helper will stay away if there's a master. Two igt tests fail with the new 'bail out if master' rule. Work around this by relaxing this rule for drm_fb_helper_restore_fbdev_mode_unlocked() until the tests have been fixed. Add todo entry for this. Locking rule: Always take the fb-helper lock first. v5: drm_fb_helper_restore_fbdev_mode_unlocked(): Use restore_fbdev_mode_force() v2: - Remove drm_fb_helper_is_bound() (Daniel Vetter) - No need to check fb_helper->dev->master in drm_fb_helper_single_fb_probe(), restore_fbdev_mode() has the check. Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190506180139.6913-3-noralf@tronnes.org
|
#
1de72592 |
|
23-Apr-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Fix drm_fb_helper_firmware_config() NULL pointer deref Non-atomic drivers like ast doesn't have connector->state set resulting in a NULL pointer deref: [ 29.609593] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [ 29.609619] Call Trace: [ 29.609630] ? drm_helper_probe_single_connector_modes+0x27f/0x680 [ 29.609640] drm_setup_crtcs+0x431/0xd80 [drm_kms_helper] [ 29.753065] __drm_fb_helper_initial_config_and_unlock+0x6f/0x6a0 [ 29.753160] ? drm_modeset_unlock_all+0x31/0x50 [drm] [ 29.765758] ast_fbdev_init+0xa8/0xc0 [ast] [ 29.765762] ast_driver_load.cold.7+0x2b3/0xe11 [ast] [ 29.765775] drm_dev_register+0x111/0x150 [drm] Fix by bailing out if the driver does not support atomic modesetting. Fixes: 09ded8af57bc ("drm/i915/fbdev: Move intel_fb_initial_config() to fbdev helper") Reported-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190423145353.30158-1-noralf@tronnes.org
|
#
abbc0697 |
|
24-Apr-2019 |
Dave Airlie <airlied@redhat.com> |
drm/fb: revert the i915 Actually configure untiled displays from master This code moved in here in master, so revert it the same way. This is the same revert as 9fa246256e09 ("Revert "drm/i915/fbdev: Actually configure untiled displays"") in drm-fixes. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
09ded8af |
|
07-Apr-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/i915/fbdev: Move intel_fb_initial_config() to fbdev helper It is generic code and having it in the helper will let other drivers benefit from it. One change was necessary assuming this to be true: INTEL_INFO(dev_priv)->num_pipes == dev->mode_config.num_crtc Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190407165243.54043-4-noralf@tronnes.org
|
#
e33898a2 |
|
03-Apr-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/client: Rename drm_client_add() to drm_client_register() This is done to stay consistent with our naming scheme of _register() = others can start calling us from any thread. Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190403125658.32389-1-noralf@tronnes.org
|
#
6e3f17ee |
|
01-Apr-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: generic: Call drm_client_add() after setup is done Hotplug can happen while drm_fbdev_generic_setup() is running so move drm_client_add() call after setup is done to avoid drm_fbdev_client_hotplug() running in two threads at the same time. Fixes: 9060d7f49376 ("drm/fb-helper: Finish the generic fbdev emulation") Cc: stable@vger.kernel.org Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190401141358.25309-1-noralf@tronnes.org
|
#
65a102f6 |
|
26-Mar-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: dpms_legacy(): Only set on connectors in use For each enabled crtc the functions sets dpms on all registered connectors. Limit this to only doing it once and on the connectors actually in use. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Fixes: 023eb571a1d0 ("drm: correctly update connector DPMS status in drm_fb_helper") Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190326175546.18126-3-noralf@tronnes.org
|
#
b9ed8cff |
|
26-Mar-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Remove unused gamma_size variable The gamma_size variable has not been used since commit 4abe35204af8 ("drm/kms/fb: use slow work mechanism for normal hotplug also.") While in the area move a comment back to its code block. They got separated by commit d50ba256b5f1 ("drm/kms: start adding command line interface using fb."). Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190326175546.18126-2-noralf@tronnes.org
|
#
ec8bf194 |
|
27-Mar-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Fixup fill_info cleanup I forgot the !CONFIG_FBDEV case. Also some kerneldoc needed more adjusting. Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Alex Deucher <alexander.deucher@amd.com> Reported-by: kbuild test robot <lkp@intel.com> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190327125819.16478-1-daniel.vetter@ffwll.ch
|
#
168b85e9 |
|
26-Mar-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Unexport fill_{var,info} Not used by drivers anymore. v2: Rebase Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-21-daniel.vetter@ffwll.ch
|
#
ecbfc474 |
|
26-Mar-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb_helper: set info->par in fill_info() The fbdev emulation helpers pretty much assume that this is set. Let's do it for everyone. Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-3-daniel.vetter@ffwll.ch
|
#
f1eca684 |
|
26-Mar-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: set fbi->fix.id in fill_info() Looking at the oldest/most popular drivers ${driver}drmfb seems to be the standard, except i915.ko went with "inteldrmfb". I guess renaming that for consistency won't hurt, it definitely confused me when I started with kms 10 years ago. I hope this never became uapi ... worst case drivers can overwrite it after having called fill_info(). Since subsequent patches change this for some drivers later on in the series, here's the exhaustive list of where all fix.id is used: - /proc/fb which prints the minor number and fix.id name. - per-fb sysfs name file - getfix ioctl, which is used by fbset only to print out the name when dumping information - lots and lots of places in dmesg, anytime anything happens with an fbdev really I think minimal to 0 chances that changing this will screw up a config script or something, since outside of informational message it's not used by anything to identify which fbdev maps to which minor. After all the last fbset release is from 1999, and that predates even devfs I think. v2: Rebase and amend commit message, thanks to Ilia for pointing out that this needs to be spelled out. Cc: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-2-daniel.vetter@ffwll.ch
|
#
3df3116a |
|
26-Mar-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Add fill_info() functions The fbdev split between fix and var information is kinda pointless for drm drivers since everything is fixed: The fbdev emulation doesn't support changing modes at all. Create a new simplified helper and use it in the generic fbdev helper code. Follow-up patches will beef it up more and roll it out to all drivers. v2: We need to keep sizes, since they might not match the fb dimensions (Noralf) v3: Fix typo in commit message and remove extraneous line in kerneldoc (Noralf) Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-1-daniel.vetter@ffwll.ch
|
#
8782c647 |
|
27-Nov-2018 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fbdev: Make skip_vt_switch the default KMS drivers really should all be able to restore their display state on resume without fbcon helping out. So make this the default. Since I'm not entirely foolish, make it only a default, which drivers can still override. That way when the inevitable regression report happens I can fix things up with a one-liner plus FIXME comment that someone should fix up the suspend/resume code in that driver. But at least all new drivers won't be broken by accident as soon as you turn off fbcon because "suspend/resume worked when I tested it". v2: Keep this for radeon because of commit 18c437caa5b18a235dd65cec224eab54bebcee65 Author: Alex Deucher <alexander.deucher@amd.com> Date: Tue Nov 14 17:19:29 2017 -0500 Revert "drm/radeon: dont switch vt on suspend" Thanks to Michel Dänzer for pointing this one out. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Michel Dänzer <michel@daenzer.net> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Sandy Huang <hjc@rock-chips.com> Cc: "Heiko Stübner" <heiko@sntech.de> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Samuel Li <Samuel.Li@amd.com> Cc: "Michel Dänzer" <michel.daenzer@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Junwei Zhang <Jerry.Zhang@amd.com> Cc: Huang Rui <ray.huang@amd.com> Cc: Shirish S <shirish.s@amd.com> Cc: Daniel Stone <daniels@collabora.com> Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: intel-gfx@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Samuel Li <samuel.li@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181127173424.301-1-daniel.vetter@ffwll.ch
|
#
b6a36e5d |
|
14-Mar-2019 |
Dave Airlie <airlied@redhat.com> |
drm/fb: avoid setting 0 depth. If the downscaling fails and we end up with a best_depth of 0, then ignore it. This actually works around a cascade of failure, but it the simplest fix for now. The scaling patch broke the udl driver, as the udl driver doesn't expose planes at all, so gets the two default 32-bit formats, but the udl driver then ask for 16bpp fbdev, and the scaling code falls over. This fixes the udl driver since the scaled depth support was added. Fixes: f4bd542bcaee ("drm/fb-helper: Scale back depth to supported maximum") Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190315014621.21816-2-airlied@gmail.com
|
#
6ab20a05 |
|
10-Feb-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: generic: Don't take module ref for fbcon It's now safe to let fbcon unbind automatically on fbdev unregister. The crash problem was fixed in commit 2122b40580dd ("fbdev: fbcon: Fix unregister crash when more than one framebuffer") Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190210131039.52664-13-noralf@tronnes.org
|
#
1e55a53a |
|
01-Feb-2019 |
Matt Roper <matthew.d.roper@intel.com> |
drm: Trivial comment grammar cleanups Most of these are just cases where code comments used contractions (it's, who's) where they actually mean to use a possessive pronoun (its, whose) or vice-versa. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190202012326.20096-1-matthew.d.roper@intel.com
|
#
78de14c2 |
|
25-Jan-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: generic: Fix drm_fbdev_client_restore() If fbdev setup has failed, lastclose will give a NULL pointer deref: [ 77.794295] [drm:drm_lastclose] [ 77.794414] [drm:drm_lastclose] driver lastclose completed [ 77.794660] Unable to handle kernel NULL pointer dereference at virtual address 00000014 [ 77.809460] pgd = b376b71b [ 77.818275] [00000014] *pgd=175ba831, *pte=00000000, *ppte=00000000 [ 77.830813] Internal error: Oops: 17 [#1] ARM [ 77.840963] Modules linked in: mi0283qt mipi_dbi tinydrm raspberrypi_hwmon gpio_backlight backlight snd_bcm2835(C) bcm2835_rng rng_core [ 77.865203] CPU: 0 PID: 527 Comm: lt-modetest Tainted: G C 5.0.0-rc1+ #1 [ 77.879525] Hardware name: BCM2835 [ 77.889185] PC is at restore_fbdev_mode+0x20/0x164 [ 77.900261] LR is at drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0x9c [ 78.002446] Process lt-modetest (pid: 527, stack limit = 0x7a3d5c14) [ 78.291030] Backtrace: [ 78.300815] [<c04f2d0c>] (restore_fbdev_mode) from [<c04f4708>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0x9c) [ 78.319095] r9:d8a8a288 r8:d891acf0 r7:d7697910 r6:00000000 r5:d891ac00 r4:d891ac00 [ 78.334432] [<c04f46b4>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c04f47e8>] (drm_fbdev_client_restore+0x18/0x20) [ 78.353296] r8:d76978c0 r7:d7697910 r6:d7697950 r5:d7697800 r4:d891ac00 r3:c04f47d0 [ 78.368689] [<c04f47d0>] (drm_fbdev_client_restore) from [<c051b6b4>] (drm_client_dev_restore+0x7c/0xc0) [ 78.385982] [<c051b638>] (drm_client_dev_restore) from [<c04f8fd0>] (drm_lastclose+0xc4/0xd4) [ 78.402332] r8:d76978c0 r7:d7471080 r6:c0e0c088 r5:d8a85e00 r4:d7697800 [ 78.416688] [<c04f8f0c>] (drm_lastclose) from [<c04f9088>] (drm_release+0xa8/0x10c) [ 78.431929] r5:d8a85e00 r4:d7697800 [ 78.442989] [<c04f8fe0>] (drm_release) from [<c02640c4>] (__fput+0x104/0x1c8) [ 78.457740] r8:d5ccea10 r7:d96cfb10 r6:00000008 r5:d74c1b90 r4:d8a8a280 [ 78.472043] [<c0263fc0>] (__fput) from [<c02641ec>] (____fput+0x18/0x1c) [ 78.486363] r10:00000006 r9:d7722000 r8:c01011c4 r7:00000000 r6:c0ebac6c r5:d892a340 [ 78.501869] r4:d8a8a280 [ 78.512002] [<c02641d4>] (____fput) from [<c013ef1c>] (task_work_run+0x98/0xac) [ 78.527186] [<c013ee84>] (task_work_run) from [<c010cc54>] (do_work_pending+0x4f8/0x570) [ 78.543238] r7:d7722030 r6:00000004 r5:d7723fb0 r4:00000000 [ 78.556825] [<c010c75c>] (do_work_pending) from [<c0101034>] (slow_work_pending+0xc/0x20) [ 78.674256] ---[ end trace 70d3a60cf739be3b ]--- Fix by using drm_fb_helper_lastclose() which checks if fbdev is in use. Fixes: 9060d7f49376 ("drm/fb-helper: Finish the generic fbdev emulation") Cc: stable@vger.kernel.org Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125150300.33268-1-noralf@tronnes.org
|
#
2de304b4 |
|
14-Jan-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/cma-helper: Remove unused fbdev code CMA helper drivers have been converted to drm_fbdev_generic_setup() so the fbdev code can be removed. v3: Remove CMA specific conditional in the generic fbdev client v2: Clean up the includes some more (Laurent) Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114121059.20704-1-noralf@tronnes.org
|
#
f4bd542b |
|
09-Jan-2019 |
Linus Walleij <linus.walleij@linaro.org> |
drm/fb-helper: Scale back depth to supported maximum The following happened when migrating an old fbdev driver to DRM: The Integrator/CP PL111 supports 16BPP but only ARGB1555/ABGR1555 or XRGB1555/XBGR1555 i.e. the maximum depth is 15. This makes the initialization of the framebuffer fail since the code in drm_fb_helper_single_fb_probe() assigns the same value to sizes.surface_bpp and sizes.surface_depth. I.e. it simply assumes a 1-to-1 mapping between BPP and depth, which is true in most cases but not for this hardware that only support odd formats. To support the odd case of a driver supporting 16BPP with only 15 bits of depth, this patch will make the code loop over the formats supported on the primary plane on each CRTC managed by the FB helper and cap the depth to the maximum supported on any primary plane. On the PL110 Integrator, this makes drm_mode_legacy_fb_format() select DRM_FORMAT_XRGB1555 which is acceptable for this driver, and thus we get framebuffer, penguin and console on the Integrator/CP. Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190110114049.10618-1-linus.walleij@linaro.org
|
#
66a8d5bf |
|
07-Jan-2019 |
Ivan Mironov <mironov.ivan@gmail.com> |
drm/fb-helper: Ignore the value of fb_var_screeninfo.pixclock Strict requirement of pixclock to be zero breaks support of SDL 1.2 which contains hardcoded table of supported video modes with non-zero pixclock values[1]. To better understand which pixclock values are considered valid and how driver should handle these values, I briefly examined few existing fbdev drivers and documentation in Documentation/fb/. And it looks like there are no strict rules on that and actual behaviour varies: * some drivers treat (pixclock == 0) as "use defaults" (uvesafb.c); * some treat (pixclock == 0) as invalid value which leads to -EINVAL (clps711x-fb.c); * some pass converted pixclock value to hardware (uvesafb.c); * some are trying to find nearest value from predefined table (vga16fb.c, video_gx.c). Given this, I believe that it should be safe to just ignore this value if changing is not supported. It seems that any portable fbdev application which was not written only for one specific device working under one specific kernel version should not rely on any particular behaviour of pixclock anyway. However, while enabling SDL1 applications to work out of the box when there is no /etc/fb.modes with valid settings, this change affects the video mode choosing logic in SDL. Depending on current screen resolution, contents of /etc/fb.modes and resolution requested by application, this may lead to user-visible difference (not always): image will be displayed in a right way, but it will be aligned to the left instead of center. There is no "right behaviour" here as well, as emulated fbdev, opposing to old fbdev drivers, simply ignores any requsts of video mode changes with resolutions smaller than current. The easiest way to reproduce this problem is to install sdl-sopwith[2], remove /etc/fb.modes file if it exists, and then try to run sopwith from console without X. At least in Fedora 29, sopwith may be simply installed from standard repositories. [1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c, vesa_timings [2] http://sdl-sopwith.sourceforge.net/ Signed-off-by: Ivan Mironov <mironov.ivan@gmail.com> Cc: stable@vger.kernel.org Fixes: 79e539453b34e ("DRM: i915: add mode setting support") Fixes: 771fe6b912fca ("drm/radeon: introduce kernel modesetting for radeon hardware") Fixes: 785b93ef8c309 ("drm/kms: move driver specific fb common code to helper functions (v2)") Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-3-mironov.ivan@gmail.com
|
#
62d85b3b |
|
07-Jan-2019 |
Ivan Mironov <mironov.ivan@gmail.com> |
drm/fb-helper: Partially bring back workaround for bugs of SDL 1.2 SDL 1.2 sets all fields related to the pixel format to zero in some cases[1]. Prior to commit db05c48197759 ("drm: fb-helper: Reject all pixel format changing requests"), there was an unintentional workaround for this that existed for more than a decade. First in device-specific DRM drivers, then here in drm_fb_helper.c. Previous code containing this workaround just ignores pixel format fields from userspace code. Not a good thing either, as this way, driver may silently use pixel format different from what client actually requested, and this in turn will lead to displaying garbage on the screen. I think that returning EINVAL to userspace in this particular case is the right option, so I decided to left code from problematic commit untouched instead of just reverting it entirely. Here is the steps required to reproduce this problem exactly: 1) Compile fceux[2] with SDL 1.2.15 and without GTK or OpenGL support. SDL should be compiled with fbdev support (which is on by default). 2) Create /etc/fb.modes with following contents (values seems not used, and just required to trigger problematic code in SDL): mode "test" geometry 1 1 1 1 1 timings 1 1 1 1 1 1 1 endmode 3) Create ~/.fceux/fceux.cfg with following contents: SDL.Hotkeys.Quit = 27 SDL.DoubleBuffering = 1 4) Ensure that screen resolution is at least 1280x960 (e.g. append "video=Virtual-1:1280x960-32" to the kernel cmdline for qemu/QXL). 5) Try to run fceux on VT with some ROM file[3]: # ./fceux color_test.nes [1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c, FB_SetVideoMode() [2] http://www.fceux.com [3] Example ROM: https://github.com/bokuweb/rustynes/blob/master/roms/color_test.nes Reported-by: saahriktu <mail@saahriktu.org> Suggested-by: saahriktu <mail@saahriktu.org> Cc: stable@vger.kernel.org Fixes: db05c48197759 ("drm: fb-helper: Reject all pixel format changing requests") Signed-off-by: Ivan Mironov <mironov.ivan@gmail.com> [danvet: Delete misleading comment.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-2-mironov.ivan@gmail.com Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-2-mironov.ivan@gmail.com
|
#
00eb5b0d |
|
22-Dec-2018 |
Peter Wu <peter@lekensteyn.nl> |
drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup After drm_fb_helper_fbdev_setup calls drm_fb_helper_init, "dev->fb_helper" will be initialized (and thus drm_fb_helper_fini will have some effect). After that, drm_fb_helper_initial_config is called which may call the "fb_probe" driver callback. This driver callback may call drm_fb_helper_defio_init (as is done by drm_fb_helper_generic_probe) or set a framebuffer (as is done by bochs) as documented. These are normally cleaned up on exit by drm_fb_helper_fbdev_teardown which also calls drm_fb_helper_fini. If an error occurs after "fb_probe", but before setup is complete, then calling just drm_fb_helper_fini will leak resources. This was triggered by df2052cc922 ("bochs: convert to drm_fb_helper_fbdev_setup/teardown"): [ 50.008030] bochsdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to support this framebuffer [ 50.009436] bochs-drm 0000:00:02.0: [drm:drm_fb_helper_fbdev_setup] *ERROR* fbdev: Failed to set configuration (ret=-38) [ 50.011456] [drm] Initialized bochs-drm 1.0.0 20130925 for 0000:00:02.0 on minor 2 [ 50.013604] WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x280/0x2a0 [ 50.016175] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G T 4.20.0-rc7 #1 [ 50.017732] EIP: drm_mode_config_cleanup+0x280/0x2a0 ... [ 50.023155] Call Trace: [ 50.023155] ? bochs_kms_fini+0x1e/0x30 [ 50.023155] ? bochs_unload+0x18/0x40 This can be reproduced with QEMU and CONFIG_FB_LITTLE_ENDIAN=n. Link: https://lkml.kernel.org/r/20181221083226.GI23332@shao2-debian Link: https://lkml.kernel.org/r/20181223004315.GA11455@al Fixes: 8741216396b2 ("drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()") Reported-by: kernel test robot <rong.a.chen@intel.com> Cc: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Peter Wu <peter@lekensteyn.nl> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181223005507.28328-1-peter@lekensteyn.nl
|
#
6e1490cf |
|
05-Jan-2019 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: generic: Fix setup error path If register_framebuffer() fails during fbdev setup we will leak the framebuffer, the GEM buffer and the shadow buffer for defio. This is because drm_fb_helper_fbdev_setup() just calls drm_fb_helper_fini() on error not taking into account that register_framebuffer() can fail. Since the generic emulation uses DRM client for its framebuffer and backing buffer in addition to a shadow buffer, it's necessary to open code drm_fb_helper_fbdev_setup() to properly handle the error path. Error cleanup is removed from .fb_probe and is handled by one function for all paths. Fixes: 9060d7f49376 ("drm/fb-helper: Finish the generic fbdev emulation") Reported-by: Peter Wu <peter@lekensteyn.nl> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190105181846.26495-1-noralf@tronnes.org
|
#
b31a3ca7 |
|
03-Dec-2018 |
Wei Yongjun <weiyongjun1@huawei.com> |
drm/fb-helper: Fix typo in parameter description Fix typo in parameter description. Fixes: 4be9bd10e22d ("drm/fb_helper: Allow leaking fbdev smem_start") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/1543905135-35293-1-git-send-email-weiyongjun1@huawei.com
|
#
8fd3b903 |
|
15-Nov-2018 |
Paul Kocialkowski <paul.kocialkowski@bootlin.com> |
drm/fb-helper: Blacklist writeback when adding connectors to fbdev Writeback connectors do not produce any on-screen output and require special care for use. Such connectors are hidden from enumeration in DRM resources by default, but they are still picked-up by fbdev. This makes rather little sense since fbdev is not really adapted for dealing with writeback. Moreover, this is also a source of issues when userspace disables the CRTC (and associated plane) without detaching the CRTC from the connector (which is hidden by default). In this case, the connector is still using the CRTC, leading to am "enabled/connectors mismatch" and eventually the failure of the associated atomic commit. This situation happens with VC4 testing under IGT GPU Tools. Filter out writeback connectors in the fbdev helper to solve this. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com> Tested-by: Maxime Ripard <maxime.ripard@bootlin.com> Fixes: 935774cd71fe ("drm: Add writeback connector type") Cc: <stable@vger.kernel.org> # v4.19+ Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181115163248.21168-1-paul.kocialkowski@bootlin.com
|
#
042bf753 |
|
01-Nov-2018 |
Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com> |
drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info For some pixel formats .cpp structure in drm_format info it's not enough to describe the peculiarities of the pixel layout, for example tiled formats or packed formats at bit level. What's implemented here is to add three new members to drm_format_info that could describe such formats: - char_per_block[3] - block_w[3] - block_h[3] char_per_block will be put in a union alongside cpp, for transparent compatibility with the existing format descriptions. Regarding, block_w and block_h they are intended to be used through their equivalent getters drm_format_info_block_width / drm_format_info_block_height, the reason of the getters is to abstract the fact that for normal formats block_w and block_h will be unset/0, but the methods will be returning 1. Additionally, convenience function drm_format_info_min_pitch had been added that computes the minimum required pitch for a given pixel format and buffer width. Using that the following drm core functions had been updated to generically handle both block and non-block formats: - drm_fb_cma_get_gem_addr: for block formats it will just return the beginning of the block. - framebuffer_check: Use the newly added drm_format_info_min_pitch. - drm_gem_fb_create_with_funcs: Use the newly added drm_format_info_min_pitch. - In places where is not expecting to handle block formats, like fbdev helpers I just added some warnings in case the block width/height are greater than 1. Changes since v3: - Add helper function for computing the minimum required pitch. - Improve/cleanup documentation Changes since v8: - Fixed build on 32bits arm architectures, with: - return DIV_ROUND_UP((u64)buffer_width * info->char_per_block[plane], + return DIV_ROUND_UP_ULL((u64)buffer_width * info->char_per_block[plane], Reviewed-by: Brian Starkey <brian.starkey@arm.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181101170055.5433-1-alexandru-cosmin.gheorghe@arm.com
|
#
db05c481 |
|
03-Oct-2018 |
Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> |
drm: fb-helper: Reject all pixel format changing requests drm fbdev emulation doesn't support changing the pixel format at all, so reject all pixel format changing requests. Cc: stable@vger.kernel.org Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181003164538.5534-1-Eugeniy.Paltsev@synopsys.com
|
#
4be9bd10 |
|
28-Sep-2018 |
Neil Armstrong <narmstrong@baylibre.com> |
drm/fb_helper: Allow leaking fbdev smem_start Since "drm/fb: Stop leaking physical address", the default behaviour of the DRM fbdev emulation is to set the smem_base to 0 and pass the new FBINFO_HIDE_SMEM_START flag. The main reason is to avoid leaking physical addresse to user-space, and it follows a general move over the kernel code to avoid user-space to manipulate physical addresses and then use some other mechanisms like dma-buf to transfer physical buffer handles over multiple subsystems. But, a lot of devices depends on closed sources binaries to enable OpenGL hardware acceleration that uses this smem_start value to pass physical addresses to out-of-tree modules in order to render into these physical adresses. These should use dma-buf buffers allocated from the DRM display device instead and stop relying on fbdev overallocation to gather DMA memory (some HW vendors delivers GBM and Wayland capable binaries, but older unsupported devices won't have these new binaries and are doomed until an Open Source solution like Lima finalizes). Since these devices heavily depends on this kind of software and because the smem_start population was available for years, it's a breakage to stop leaking smem_start without any alternative solutions. This patch adds a Kconfig depending on the EXPERT config and an unsafe kernel module parameter tainting the kernel when enabled. A clear comment and Kconfig help text was added to clarify why and when this patch should be reverted, but in the meantime it's a necessary feature to keep. Cc: Dave Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Eric Anholt <eric@anholt.net> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Rob Clark <robdclark@gmail.com> Cc: Ben Skeggs <skeggsb@gmail.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com> Tested-by: Maxime Ripard <maxime.ripard@bootlin.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/1538136355-15383-1-git-send-email-narmstrong@baylibre.com
|
#
4d4c2d89 |
|
01-Oct-2018 |
Noralf Trønnes <noralf@tronnes.org> |
drm/cma-helper: Fix crash in fbdev error path Sergey Suloev reported a crash happening in drm_client_dev_hotplug() when fbdev had failed to register. [ 9.124598] vc4_hdmi 3f902000.hdmi: ASoC: Failed to create component debugfs directory [ 9.147667] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok [ 9.155184] vc4_hdmi 3f902000.hdmi: ASoC: no DMI vendor name! [ 9.166544] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4]) [ 9.173840] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4]) [ 9.181029] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4]) [ 9.188519] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4]) [ 9.195690] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 9.203523] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 9.215032] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 9.274785] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4]) [ 9.290246] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0 [ 9.297464] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 9.304600] [drm] Driver supports precise vblank timestamp query. [ 9.382856] vc4-drm soc:gpu: [drm:drm_fb_helper_fbdev_setup [drm_kms_helper]] *ERROR* Failed to set fbdev configuration [ 10.404937] Unable to handle kernel paging request at virtual address 00330a656369768a [ 10.441620] [00330a656369768a] address between user and kernel address ranges [ 10.449087] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 10.454762] Modules linked in: brcmfmac vc4 drm_kms_helper cfg80211 drm rfkill smsc95xx brcmutil usbnet drm_panel_orientation_quirks raspberrypi_hwmon bcm2835_dma crc32_ce pwm_bcm2835 bcm2835_rng virt_dma rng_core i2c_bcm2835 ip_tables x_tables ipv6 [ 10.477296] CPU: 2 PID: 45 Comm: kworker/2:1 Not tainted 4.19.0-rc5 #3 [ 10.483934] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 10.489966] Workqueue: events output_poll_execute [drm_kms_helper] [ 10.596515] Process kworker/2:1 (pid: 45, stack limit = 0x000000007e8924dc) [ 10.603590] Call trace: [ 10.606259] drm_client_dev_hotplug+0x5c/0xb0 [drm] [ 10.611303] drm_kms_helper_hotplug_event+0x30/0x40 [drm_kms_helper] [ 10.617849] output_poll_execute+0xc4/0x1e0 [drm_kms_helper] [ 10.623616] process_one_work+0x1c8/0x318 [ 10.627695] worker_thread+0x48/0x428 [ 10.631420] kthread+0xf8/0x128 [ 10.634615] ret_from_fork+0x10/0x18 [ 10.638255] Code: 54000220 f9401261 aa1303e0 b4000141 (f9400c21) [ 10.644456] ---[ end trace c75b4a4b0e141908 ]--- The reason for this is that drm_fbdev_cma_init() removes the drm_client when fbdev registration fails, but it doesn't remove the client from the drm_device client list. So the client list now has a pointer that points into the unknown and we have a 'use after free' situation. Split drm_client_new() into drm_client_init() and drm_client_add() to fix removal in the error path. Fixes: 894a677f4b3e ("drm/cma-helper: Use the generic fbdev emulation") Reported-by: Sergey Suloev <ssuloev@orpaltech.com> Cc: Stefan Wahren <stefan.wahren@i2se.com> Cc: Eric Anholt <eric@anholt.net> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181001194536.57756-1-noralf@tronnes.org
|
#
6129369a |
|
08-Sep-2018 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Improve error reporting in setup Improve error reporting in drm_fb_helper_fbdev_setup() by printing the error code. This is useful for drivers that choose to not fall over just because fbdev doesen't work, but still wants clues to why it failed. This way they don't have to provide an error message themselves. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180908134648.2582-2-noralf@tronnes.org
|
#
6ee67e35 |
|
11-Sep-2018 |
YueHaibing <yuehaibing@huawei.com> |
drm/fb-helper: Remove set but not used variable 'connector_funcs' Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/drm_fb_helper.c: In function 'drm_pick_crtcs': drivers/gpu/drm/drm_fb_helper.c:2373:43: warning: variable 'connector_funcs' set but not used [-Wunused-but-set-variable] Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1536722130-108819-1-git-send-email-yuehaibing@huawei.com
|
#
6be8f3bd |
|
22-Aug-2018 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb: Stop leaking physical address For buffer sharing, use dma-buf instead. We can't set smem_start to 0 unconditionally since that's used by the fbdev mmap default implementation. And we have plenty of userspace which would like to keep that working. This might break legit userspace - if it does we need to look at a case-by-cases basis how to handle that. Worst case I expect overrides for only specific drivers, since anything remotely modern should be using dma-buf/prime now (which is about 7 years old now for DRM drivers). This issue was uncovered because Noralf's rework to implement a generic fb_probe also implements it's own fb_mmap callback. Which means smem_start didn't have to be set anymore, which blew up some blob in userspace rather badly. Acked-by: Sean Paul <seanpaul@chromium.org> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: John Stultz <john.stultz@linaro.org> Cc: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180822085405.10787-4-daniel.vetter@ffwll.ch
|
#
c10802b6 |
|
06-Sep-2018 |
Peter Wu <peter@lekensteyn.nl> |
drm/fb-helper: improve documentation and print warnings Clarify the relation between drm_fb_helper_fbdev_setup/teardown. Clarify requirements for the new generic fbdev emulation API and log some more details in case the driver does something wrong. Fix related typos. Cc: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Peter Wu <peter@lekensteyn.nl> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20180906221810.20170-5-peter@lekensteyn.nl Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
#
9060d7f4 |
|
03-Jul-2018 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Finish the generic fbdev emulation This adds a drm_fbdev_generic_setup() function that sets up generic fbdev emulation with client callbacks for restore, hotplug and unregister. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180703160354.59955-7-noralf@tronnes.org
|
#
d536540f |
|
03-Jul-2018 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Add generic fbdev emulation .fb_probe function This is the first step in getting generic fbdev emulation. A drm_fb_helper_funcs.fb_probe function is added which uses the DRM client API to get a framebuffer backed by a dumb buffer. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180703160354.59955-3-noralf@tronnes.org
|
#
83aefbb8 |
|
28-Jun-2018 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm: Add drm_connector_for_each_possible_encoder() Add a convenience macro for iterating connector->encoder_ids[]. Isolates the users from the implementation details. Note that we don't seem to pass the file_priv down to drm_encoder_find() because encoders apparently don't get leased. No idea why drm_encoder_finc() even takes the file_priv actually. Also use ARRAY_SIZE() when populating the array to avoid spreading knowledge about the array size all over. v2: Hide the drm_encoder_find() in the macro, and rename the macro appropriately (Daniel) v3: Fix kernel docs (Daniel) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180628131315.14156-4-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0d998891 |
|
28-Jun-2018 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/fb-helper: Eliminate the .best_encoder() usage Instead of using the .best_encoder() hook to figure out whether a given connector+crtc combo will work, let's instead do what userspace does and just iterate over all the encoders for the connector, and then check each crtc against each encoder's possible_crtcs bitmask. v2: Avoid oopsing on NULL encoders (Daniel) s/connector_crtc_ok/connector_has_possible_crtc/ Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180628131315.14156-2-ville.syrjala@linux.intel.com
|
#
e00fb856 |
|
25-May-2018 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm: Stop updating plane->crtc/fb/old_fb on atomic drivers Stop playing around with plane->crtc/fb/old_fb with atomic drivers. Make life a lot simpler when we don't have to do the magic old_fb vs. fb dance around plane updates. That way we can't risk plane->fb getting out of sync with plane->state->fb and we're less likely to leak any refcounts as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-14-ville.syrjala@linux.intel.com Reviewed-by: Sinclair Yeh <syeh@vmware.com>
|
#
d104328c |
|
24-May-2018 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Fix typo on kerneldoc Copypasta mistake. Fixes: 742547b73d27 ("drm/fb_helper: Create wrappers for blit, copyarea and fillrect funcs") Cc: Archit Taneja <architt@codeaurora.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Acked-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180524090105.21196-1-daniel.vetter@ffwll.ch
|
#
222ec161 |
|
08-May-2018 |
Shashank Sharma <shashank.sharma@intel.com> |
drm: Add aspect ratio parsing in DRM layer Current DRM layer functions don't parse aspect ratio information while converting a user mode->kernel mode or vice versa. This causes modeset to pick mode with wrong aspect ratio, eventually causing failures in HDMI compliance test cases, due to wrong VIC. This patch adds aspect ratio information in DRM's mode conversion and mode comparision functions, to make sure kernel picks mode with right aspect ratio (as per the VIC). Background: This patch was once reviewed and merged, and later reverted due to lack of DRM cap protection. This is a re-spin of this patch, this time with DRM cap protection, to avoid aspect ratio information, when the client doesn't request for it. Review link: https://pw-emeril.freedesktop.org/patch/104068/ Background discussion: https://patchwork.kernel.org/patch/9379057/ Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Lin, Jia <lin.a.jia@intel.com> Signed-off-by: Akashdeep Sharma <akashdeep.sharma@intel.com> Reviewed-by: Jim Bride <jim.bride@linux.intel.com> (V2) Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> (V4) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> V3: modified the aspect-ratio check in drm_mode_equal as per new flags provided by Ville. https://patchwork.freedesktop.org/patch/188043/ V4: rebase V5: rebase V6: As recommended by Ville, avoided matching of aspect-ratio in drm_fb_helper, while trying to find a common mode among connectors for the target clone mode. V7: rebase V8: rebase V9: rebase V10: rebase V11: rebase V12: rebase V13: rebase V14: rebase Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-10-git-send-email-ankit.k.nautiyal@intel.com
|
#
11b83e3f |
|
23-Feb-2018 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm: Remove now pointelss blob->data casts Now that blob->data is void* again we don't need the casts anymore. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180223192506.29992-2-ville.syrjala@linux.intel.com Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8d44e9e6 |
|
20-Dec-2017 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/framebuffer: Print task that allocated the fb in debug info. This is is very useful to finding sources of leaked framebufers. The fbcon fb is annotated with [fbcon], to give it a better name than kworker. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171220093545.613-3-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
48c9571c |
|
15-Dec-2017 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Add drm_fb_helper_defio_init() Add helper for initializing fbdev deferred I/O. The cleanup could have happened in drm_fb_helper_fini(), but that would have required me to set fb_info->fbdefio to NULL in a couple of drivers before they call _fini() to avoid double defio cleanup. The problem is that one of those is vboxvideo which lives in Greg's staging tree. So I put the cleanup in drm_fb_helper_fbdev_teardown(), not perfect but not that bad either. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171215175119.36181-6-noralf@tronnes.org
|
#
95b0137f |
|
15-Dec-2017 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Update DOC with new helpers Promote new helpers for dealing with fbdev emulation. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171215175119.36181-5-noralf@tronnes.org
|
#
87412163 |
|
15-Dec-2017 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown() Add helpers to setup and teardown fbdev emulation. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171215175119.36181-3-noralf@tronnes.org
|
#
89f3f356 |
|
05-Dec-2017 |
Gustavo A. R. Silva <garsilva@embeddedor.com> |
drm/fb-helper: Fix potential NULL pointer dereference fb_helper is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after fb_helper has been null checked. This issue was detected with the help of Coccinelle. Fixes: c777990fb45b ("drm/fb-helper: Handle function NULL argument") Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171205174628.GA31189@embeddedor.com
|
#
8f0cb418 |
|
25-Nov-2017 |
Hans de Goede <j.w.r.degoede@gmail.com> |
drm/fb-helper: Apply panel orientation connector prop to the primary plane, v6. Apply the "panel orientation" drm connector prop to the primary plane so that fbcon and fbdev using userspace programs display the right way up. Changes in v3: -Use a rotation member in struct drm_fb_helper_crtc and set that from drm_setup_crtcs instead of looping over all crtc's to find the right one later -Since we now no longer look at rotation quirks directly in the fbcon code, set fb_info.fbcon_rotate_hint when the panel is not mounted upright and we cannot use hardware rotation Changes in v4: -Make drm_fb_helper_init() init drm_fb_helper_crtc.rotation to DRM_MODE_ROTATE_0 for all crtcs, so that we do not end up setting the plane_state's rotation to an invalid value for disabled crtcs (caught by Fi.CI) Changes in v5: -Only use hardware (crtc primary plane) rotation for DRM_ROTATE_180, 90 / 270 degree rotation requires special handling which we lack atm -Add a TODO comment for 90 / 270 degree hardware rotation -Add some comments to better document the default case when mapping sw_rotations to fbcon_rotate_hints Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=94894 Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171125193553.23986-5-hdegoede@redhat.com
|
#
52dd0650 |
|
27-Nov-2017 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/fb_helper: Disable all crtc's when initial setup fails. Some drivers like i915 start with crtc's enabled, but with deferred fbcon setup they were no longer disabled as part of fbdev setup. Headless units could no longer enter pc3 state because the crtc was still enabled. Fix this by calling restore_fbdev_mode when we would have called it otherwise once during initial fbdev setup. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup") Cc: <stable@vger.kernel.org> # v4.14+ Reported-by: Thomas Voegtle <tv@lio96.de> Tested-by: Thomas Voegtle <tv@lio96.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171128111603.62757-1-maarten.lankhorst@linux.intel.com
|
#
b5f05388 |
|
15-Oct-2017 |
Dave Airlie <airlied@redhat.com> |
drm/fb: add support for not enabling fbcon on non-desktop displays [v2] We don't want fbcon to get used on non-desktop dislays, don't pass them as enabled connectors to the fb helper setup. This prevents my HMD from getting disorted fbcon, and from affecting other displays console. v2: Change description from non-standard to non-desktop Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
304a4f6a |
|
30-Oct-2017 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Add .last_close and .output_poll_changed helpers This adds helpers for the drm_driver->last_close and the drm_mode_config_funcs->output_poll_changed callbacks. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171030153951.56269-4-noralf@tronnes.org
|
#
29ad20b22 |
|
30-Oct-2017 |
Noralf Trønnes <noralf@tronnes.org> |
drm: Add drm_device->fb_helper pointer drm_fb_helper is *the* way of doing fbdev emulation so add a pointer to struct drm_device. This makes it possible to add callback helpers for .last_close and .output_poll_changed further reducing fbdev emulation footprint in drivers. The pointer is set by drm_fb_helper_init() and cleared by drm_fb_helper_fini(). Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171030153951.56269-3-noralf@tronnes.org
|
#
c777990f |
|
30-Oct-2017 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Handle function NULL argument Make functions tolerate that the drm_fb_helper argument is NULL. This is useful for drivers that continue probing when fbdev emulation fails and not having to do this check themselves. Update docs for functions that already handles this. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171030153951.56269-2-noralf@tronnes.org
|
#
4b947b1c |
|
13-Oct-2017 |
Harsha Sharma <harshasharmaiitr@gmail.com> |
drm: Replace kzalloc with kcalloc Prefer kcalloc over kzalloc to allocate an array. This patch fixes checkcpatch issue. Signed-off-by: Harsha Sharma <harshasharmaiitr@gmail.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20171013073747.29877-1-harshasharmaiitr@gmail.com Link: https://patchwork.freedesktop.org/patch/msgid/20171013073747.29877-1-harshasharmaiitr@gmail.com
|
#
b52f09c4 |
|
28-Aug-2017 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Avoid NULL ptr dereference in fb_set_suspend() drm_fb_helper_resume_worker() uses fb_helper->fbdev to call fb_set_suspend() which dereferences the pointer. Move sync-canceling of the resume worker in drm_fb_helper_fini() before setting fb_helper->fbdev to NULL. Move dirty_work as well. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/1503940668-25883-2-git-send-email-noralf@tronnes.org
|
#
991a3999 |
|
04-Aug-2017 |
David Lechner <david@lechnology.com> |
drm/fb-helper: pass physical dimensions to fbdev The fbdev subsystem has a place for physical dimensions (width and height in mm) that is readable by userspace. Since DRM also knows these dimensions, pass this information to the fbdev device. This has to be done in drm_setup_crtcs_fb() instead of drm_setup_crtcs() because fb_helper->fbdev may be NULL in drm_setup_crtcs(). Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1501863924-7154-1-git-send-email-david@lechnology.com
|
#
f461bd2b |
|
03-Aug-2017 |
David Lechner <david@lechnology.com> |
drm/fb-helper: add new drm_setup_crtcs_fb() function This adds a new drm_setup_crtcs_fb() function to handle the parts of drm_setup_crtcs() that touch fb_helper->fb and fb_helper->fbdev. When drm_setup_crtcs() is called during initialization, these fields are NULL because they have not been allocated yet. There is currently a hack at the end of drm_fb_helper_single_fb_probe() that sets fb_helper->fb, so it is moved to the new drm_setup_crtcs_fb() function. This is also done in preparation for addition setup that requires access to fb_helper->fbdev. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1501777149-8310-2-git-send-email-david@lechnology.com
|
#
27a061fb |
|
02-Aug-2017 |
David Lechner <david@lechnology.com> |
drm/fb: Fix pointer dereference before null check. fb_crtc is used before a null check, so move the use after the null check. This was just identified by inspection. I haven't actually observed a crash here, so it is possible that the null check could be unnecessary. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1501696813-8807-1-git-send-email-david@lechnology.com
|
#
ca91a275 |
|
06-Jul-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Support deferred setup FB helper code falls back to a 1024x768 mode if no outputs are connected or don't report back any modes upon initialization. This can be annoying because outputs that are added to FB helper later on can't be used with FB helper if they don't support a matching mode. The fallback is in place because VGA connectors can happen to report an unknown connection status even when they are in fact connected. Some drivers have custom solutions in place to defer FB helper setup until at least one output is connected. But the logic behind these solutions is always the same and there is nothing driver-specific about it, so a better alterative is to fix the FB helper core and add support for all drivers automatically. This patch adds support for deferred FB helper setup. It checks all the connectors for their connection status, and if all of them report to be disconnected marks the FB helper as needing deferred setup. Whet setup is deferred, the FB helper core will automatically retry setup after a hotplug event, and it will keep trying until it succeeds. v2: Rebase onto my entirely reworked fbdev helper locking. One big difference is that this version again drops&reacquires the fbdev lock (which is now fb_helper->lock, but before this patch series it was mode_config->mutex), because register_framebuffer must be able to recurse back into fbdev helper code for the initial screen setup. v3: __drm_fb_helper_initial_config must hold fb_helper->lock upon return, I've fumbled that in the deferred setup case (Liviu). v4: I was blind, redo this all. __drm_fb_helper_initial_config shouldn't need to reacquire fb_helper->lock, that just confuses callers. I myself got confused by kernel_fb_helper_lock and somehow thought it's the same as fb_helper->lock. Tsk. Also simplify the logic a bit (we don't need two functions to probe connectors), we can stick much closer to the existing code. And update some comments I've spotted that are outdated. v5: Don't pass -EAGAIN to drivers, it's just an internal error code (Liviu). v6: Add _and_unlock suffix to clarify locking (Maarten) Cc: Liviu Dudau <liviu@dudau.co.uk> Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com> (v1) Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Reviewed-by: Liviu Dudau <liviu@dudau.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170706130023.28417-3-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
964c6006 |
|
13-Jul-2017 |
Peter Rosin <peda@axentia.se> |
drm/fb-helper: separate the fb_setcmap helper into atomic and legacy paths The legacy path implements setcmap in terms of crtc .gamma_set. The atomic path implements setcmap by directly updating the crtc gamma_lut property. This has a couple of benefits: - it makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get completely obsolete. They are now unused and subject for removal. - atomic drivers that support clut modes get fbdev support for those from the drm core. This includes atmel-hlcdc, but perhaps others as well? Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170713162538.22788-4-peda@axentia.se
|
#
08c992c5 |
|
03-Jul-2017 |
Peter Rosin <peda@axentia.se> |
drm/fb-helper: remove drm_fb_helper_save_lut_atomic drm_fb_helper_save_lut_atomic is redundant since the .gamma_store is now always kept up to date by drm_fb_helper_setcmap. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1499164632-5582-4-git-send-email-peda@axentia.se
|
#
a3562a0e |
|
03-Jul-2017 |
Peter Rosin <peda@axentia.se> |
drm/fb-helper: keep the .gamma_store updated in drm_fb_helper_setcmap I think the gamma_store can end up invalid on error. But the way I read it, that can happen in drm_mode_gamma_set_ioctl as well, so why should this pesky legacy fbdev stuff be any better? Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1499164632-5582-3-git-send-email-peda@axentia.se
|
#
b8e2b019 |
|
03-Jul-2017 |
Peter Rosin <peda@axentia.se> |
drm/fb-helper: factor out pseudo-palette The pseudo-palette has nothing to do with the crtc, so move it out of the crtc loop and update the palette once, then break out early. Signed-off-by: Peter Rosin <peda@axenita.se> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1499164632-5582-2-git-send-email-peda@axentia.se
|
#
6b7dc6e9 |
|
04-Jul-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Split dpms handling into legacy and atomic paths Like with panning and modesetting, and like with those, stick with simple drm_modeset_locking_all for the legacy path, and the full atomic dance for atomic drivers. This means a bit more boilerplate since setting up the atomic state machinery is rather verbose, but then this is shared code for 30+ drivers or so, so meh. After this patch there's only the LUT/cmap path which is still using drm_modeset_lock_all for an atomic driver. But Peter is already locking into reworking that, so I'll leave that code as-is for now. v2: Squash in patches from Maarten to unify all the various atomic paths into just one atomic update function for fbdev overall. On top do one s/restore_fbdev_mode/restore_fbdev_mode_atomic/ so that we have all-atomic callchains after the first check. Cc: Peter Rosin <peda@axentia.se> Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-10-daniel.vetter@ffwll.ch
|
#
e13a0583 |
|
04-Jul-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Stop using mode_config.mutex for internals Those are now all protected using fb_helper->lock. v2: We still need to hold mode_config.mutex right around calling connector->fill_modes. v3: I forgot to hold mode_config.mutex while looking at connector->status and the mode list. Also, we need to patch up the i915 ->initial_config callback to grab the locks it needs to inspect the modeset state recovered from the fw. v4: Don't reorder the probe too much (Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170705045629.31265-1-daniel.vetter@ffwll.ch
|
#
1d0c64109 |
|
04-Jul-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy Same game as with the panning function, use drm_modeset_lock_all for legacy paths, and a proper acquire ctx w/w mutex dance for atomic. Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-8-daniel.vetter@ffwll.ch
|
#
5c2e3448 |
|
04-Jul-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Push locking into pan_display_atomic|legacy For the legacy path we'll keep drm_modeset_lock_all, for the atomic one we drop the use of the magic implicit context and wire it up properly. Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-7-daniel.vetter@ffwll.ch
|
#
235d3e4f |
|
04-Jul-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Drop locking from the vsync wait ioctl code Like with the drm-native vblank wait ioctl we can entirely rely on the spinlocks in drm_vblank.c, no need at all to take expensive mutexes. The only reason we had to take mode_config.mutex was to protect the fbdev helper's data-structures, but that's now done by fb_helper->lock. Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-6-daniel.vetter@ffwll.ch
|
#
bdac4a05 |
|
04-Jul-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Push locking in fb_is_bound That function only needs to take the individual crtc locks, not all the kms locks. Push down the locking and then minimize it. Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-5-daniel.vetter@ffwll.ch
|
#
e9827d8e |
|
04-Jul-2017 |
Thierry Reding <treding@nvidia.com> |
drm/fb-helper: Add top-level lock Introduce a new top-level lock for the FB helper code. This will allow better locking granularity and avoid the need to abuse modeset locking for this purpose instead. This patch just adds the new lock everywhere we currently grab mode_config->mutex (explicitly, or through drm_modeset_lock_all). Follow-up patches will push the kms locking down into only the places that need it. v2: - use lockdep_assert_held - use drm_fb_helper_for_each_connector where possible - use the new top-level lock consistently, i.e. in all the places we're currently acquiring mode_config.mutex. - small polish to the kerneldoc Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com> (v1) Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-4-daniel.vetter@ffwll.ch
|
#
af2405af |
|
04-Jul-2017 |
Thierry Reding <treding@nvidia.com> |
drm/fb-helper: Push down modeset lock into FB helpers Move the modeset locking from drivers into FB helpers. v2: Also handle intel_connector_add_to_fbdev. v3: Prevent race in intel_dp_mst with ->detect (Maarten) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com> (v1) Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-2-daniel.vetter@ffwll.ch
|
#
7114d2e2 |
|
03-Jul-2017 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/fb-helper: Remove drm_mode_config_fb. Remove drm_mode_config_fb, I don't see the point of it. To make it clear that it's ok to use plane->fb directly, move up drm_drv_uses_atomic_modeset so the code is skipped for atomic drivers that require plane_state->fb. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170703115106.18783-1-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c2c446ad |
|
19-May-2017 |
Robert Foss <robert.foss@collabora.com> |
drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI as a convenience. Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up through the atomic API, but realizing that userspace is likely to take shortcuts and assume that the enum values are what is sent over the wire. As a result these defines are provided purely as a convenience to userspace applications. Changes since v3: - Switched away from past tense in comments - Add define name change to previously mis-spelled DRM_REFLECT_X comment - Improved the comment for the DRM_MODE_REFLECT_<axis> comment Changes since v2: - Changed define prefix from DRM_MODE_PROP_ to DRM_MODE_ - Fix compilation errors - Changed comment formatting - Deduplicated comment lines - Clarified DRM_MODE_PROP_REFLECT_ comment Changes since v1: - Moved defines from drm.h to drm_mode.h - Changed define prefix from DRM_ to DRM_MODE_PROP_ - Updated uses of the defines to the new prefix - Removed include from drm_rect.c - Stopped using the BIT() macro Signed-off-by: Robert Foss <robert.foss@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170519205017.23307-2-robert.foss@collabora.com
|
#
06324664 |
|
08-May-2017 |
Kees Cook <keescook@chromium.org> |
format-security: move static strings to const While examining output from trial builds with -Wformat-security enabled, many strings were found that should be defined as "const", or as a char array instead of char pointer. This makes some static analysis easier, by producing fewer false positives. As these are all trivial changes, it seemed best to put them all in a single patch rather than chopping them up per maintainer. Link: http://lkml.kernel.org/r/20170405214711.GA5711@beast Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Jes Sorensen <jes@trained-monkey.org> [runner.c] Cc: Tony Lindgren <tony@atomide.com> Cc: Russell King <linux@armlinux.org.uk> Cc: "Maciej W. Rozycki" <macro@linux-mips.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: Yisen Zhuang <yisen.zhuang@huawei.com> Cc: Salil Mehta <salil.mehta@huawei.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Jiri Slaby <jslaby@suse.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: James Hogan <james.hogan@imgtec.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Mugunthan V N <mugunthanvnm@ti.com> Cc: Felipe Balbi <felipe.balbi@linux.intel.com> Cc: Jarod Wilson <jarod@redhat.com> Cc: Florian Westphal <fw@strlen.de> Cc: Antonio Quartulli <a@unstable.cc> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Kejian Yan <yankejian@huawei.com> Cc: Daode Huang <huangdaode@hisilicon.com> Cc: Qianqian Xie <xieqianqian@huawei.com> Cc: Philippe Reynes <tremyfr@gmail.com> Cc: Colin Ian King <colin.king@canonical.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Christian Gromm <christian.gromm@microchip.com> Cc: Andrey Shvetsov <andrey.shvetsov@k2l.de> Cc: Jason Litzinger <jlitzingerdev@gmail.com> Cc: WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
7128645d |
|
03-Apr-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Extract _legacy kms functions The goal is to push all the kms locking down into these separate _atomic and _legacy functions, so that we can correctly pass the acquire ctx into all atomic drivers. Instead of playing games with hidden ctx in mode_config.acquire_ctx. All the fbdev state will be protected by a new fbdev private lock that Thierry is working on. This here is just prep by creating a clean split between atomic and legacy paths, which also simplifies the control flow a bit. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-16-daniel.vetter@ffwll.ch
|
#
6d124ff8 |
|
03-Apr-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm: Add acquire ctx to ->gamma_set hook Atomic helpers really want this instead of the hacked-up legacy backoff trick, which unfortunately prevents drivers from using their own private drm_modeset_locks. Aside: There's a few atomic drivers (nv50, vc4, soon vmwgfx) which don't yet use the new atomic color mgmt/gamma table stuff. Would be nice if they could switch over and just hook up drm_atomic_helper_legacy_gamma_set() instead. Cc: Dave Airlie <airlied@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Eric Anholt <eric@anholt.net> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-13-daniel.vetter@ffwll.ch
|
#
9c79e0b1 |
|
03-Apr-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Give up on kgdb for atomic drivers It just doesn't work. It probably stopped working way, way before that (e.g. i915 grabbed random mutexes all over in modeset code at least since gen6), but with atomic and all the ww_mutex stuff it's indeed hopeless. Remove ->mode_set_base_atomic from the 2 atomic drivers (i915 and nouveau) that still had one (both had dummy implementations already anyway), and shunt atomic drivers in the helpers debug_enter/leave functions. I'll leave the code in for radeon and amdgpu, but I think as soon as amdgpu is atomic we should think about just ripping it out. Only having it around for radeon and pre-nv50 is rather pointless. This would also allow us to nuke all that code from fbdev. Funny part is that _all_ kms drivers set this hook, despite that no one else provides the required ->mode_set_base_atomic implementation. The reason I'm jumping on this is that I want to wire up a full acquire ctx for the benefit of atomic drivers, everywhere. And the debug_enter/leave implementations call ->gamma_set. And there's just no way ever we can create an acquire_ctx in the nmi context of kgdb. Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-11-daniel.vetter@ffwll.ch
|
#
50021ff1 |
|
29-Mar-2017 |
Thierry Reding <treding@nvidia.com> |
drm/fb-helper: Improve code readability Add a couple of temporary variables and use shorter names for existing variables in drm_fb_helper_add_one_connector() for better readability. Tested-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170329144401.1804-4-thierry.reding@gmail.com
|
#
39b8b2ed |
|
29-Mar-2017 |
Thierry Reding <treding@nvidia.com> |
drm/fb-helper: Reshuffle code for subsequent patches An unlocked version of the drm_fb_helper_add_one_connector() function will be added in a subsequent patch. Reshuffle the code separately to make the diff more readable later on. Tested-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170329144401.1804-3-thierry.reding@gmail.com
|
#
4b4f99f5 |
|
29-Mar-2017 |
Thierry Reding <treding@nvidia.com> |
drm/fb-helper: Cleanup checkpatch warnings Fix up a couple of checkpatch warnings, such as whitespace or coding style issues. Tested-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170329144401.1804-2-thierry.reding@gmail.com
|
#
12ffed96 |
|
23-Mar-2017 |
Michel Dänzer <michel.daenzer@amd.com> |
drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again Otherwise this can also prevent modesets e.g. for switching VTs, when multiple monitors with different native resolutions are connected. The depths must match though, so keep the != test for that. Also update the DRM_DEBUG output to be slightly more accurate, this doesn't only affect requests from userspace. Bugzilla: https://bugs.freedesktop.org/99841 Fixes: 865afb11949e ("drm/fb-helper: reject any changes to the fbdev") Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170323085326.20185-1-michel@daenzer.net
|
#
0f3bbe07 |
|
28-Feb-2017 |
Maxime Ripard <mripard@kernel.org> |
drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic framebuffer emulation driver. Legacy framebuffer users like non kms/drm based OpenGL(ES)/EGL implementations may require the ioctl to synchronize drawing or buffer flip for double buffering. It is tested on the i.MX6. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b982dab1 |
|
28-Feb-2017 |
Thierry Reding <treding@nvidia.com> |
drm: Rename connector list iterator API Currently the functions that initialize and tear down a connector iterator use the _get() and _put() suffixes. However, these suffixes are typically used by reference counting functions. Make these function names a little more consistent by changing the suffixes to _begin() and _end(), which is a fairly common pattern in the rest of the Linux kernel. Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170228144643.5668-8-thierry.reding@gmail.com
|
#
ad093607 |
|
28-Feb-2017 |
Thierry Reding <treding@nvidia.com> |
drm: Introduce drm_connector_{get,put}() For consistency with other reference counting APIs in the kernel, add drm_connector_get() and drm_connector_put() functions to reference count connectors. Compatibility aliases are added to keep existing code working. To help speed up the transition, all the instances of the old functions in the DRM core are already replaced in this commit. The existing semantic patch for mode object reference count conversion is extended for these new helpers. Reviewed-by: Sean Paul <seanpaul@chromium.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170228144643.5668-4-thierry.reding@gmail.com
|
#
5f152576 |
|
15-Feb-2017 |
Xinliang Liu <xinliang.liu@linaro.org> |
drm/fb-helper: Add multi buffer support for cma fbdev This patch add a config to support to create multi buffer for cma fbdev. Such as double buffer and triple buffer. Cma fbdev is convient to add a legency fbdev. And still many Android devices use fbdev now and at least double buffer is needed for these Android devices, so that a buffer flip can be operated. It will need some time for Android device vendors to abondon legency fbdev. So multi buffer for fbdev is needed. Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org> [s.christ@phytec.de: Picking patch from https://lkml.org/lkml/2015/9/14/188] Signed-off-by: Stefan Christ <s.christ@phytec.de> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Dave Airlie <airlied@gmail.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/075ffb50cc16ab055b5d47b30163401bb356ab51.1487175046.git-series.maxime.ripard@free-electrons.com
|
#
24f76b2c |
|
06-Feb-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm: Cancel drm_fb_helper_resume_work on unload We can not allow the worker to run after its fbdev, or even the module, has been removed. Fixes: cfe63423d9be ("drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.9+ Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170207124956.14954-2-chris@chris-wilson.co.uk
|
#
f21b9a92 |
|
06-Feb-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm: Cancel drm_fb_helper_dirty_work on unload We can not allow the worker to run after its fbdev, or even the module, has been removed. Fixes: eaa434defaca ("drm/fb-helper: Add fb_deferred_io support") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.7+ Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170207124956.14954-1-chris@chris-wilson.co.uk
|
#
da7bdda2 |
|
07-Feb-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Automatically clean up fb_info Noticed that everyone duplicates the same logic here and we could safe a few lines per driver. Yay for lots of drivers to make such tiny refactors worth-while! v2: Forgot to git add everything :( v3: Actually remove release_fbi (Sean, Emil, Chris) ... Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170207161603.17611-1-daniel.vetter@ffwll.ch
|
#
ed84e254 |
|
07-Feb-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Explain unload sequence a bit better While reviewing Chris' patches to properly cancel our async workers I checked that this happens after the fbdev is already unregistered. That's the case, but I found a small gap in our docs, fill that in. Note that I don't explain what release_fbi does, because that function will disappear in the next patch ... Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170207141050.1129-1-daniel.vetter@ffwll.ch
|
#
e4563f6b |
|
02-Feb-2017 |
Gabriel Krisman Bertazi <krisman@collabora.co.uk> |
drm: Rely on mode_config data for fb_helper initialization Instead of receiving the num_crts as a parameter, we can read it directly from the mode_config structure. I audited the drivers that invoke this helper and I believe all of them initialize the mode_config struct accordingly, prior to calling the fb_helper. I used the following coccinelle hack to make this transformation, except for the function headers and comment updates. The first and second rules are split because I couldn't find a way to remove the unused temporary variables at the same time I removed the parameter. // <smpl> @r@ expression A,B,D,E; identifier C; @@ ( - drm_fb_helper_init(A,B,C,D) + drm_fb_helper_init(A,B,D) | - drm_fbdev_cma_init_with_funcs(A,B,C,D,E) + drm_fbdev_cma_init_with_funcs(A,B,D,E) | - drm_fbdev_cma_init(A,B,C,D) + drm_fbdev_cma_init(A,B,D) ) @@ expression A,B,C,D,E; @@ ( - drm_fb_helper_init(A,B,C,D) + drm_fb_helper_init(A,B,D) | - drm_fbdev_cma_init_with_funcs(A,B,C,D,E) + drm_fbdev_cma_init_with_funcs(A,B,D,E) | - drm_fbdev_cma_init(A,B,C,D) + drm_fbdev_cma_init(A,B,D) ) @@ identifier r.C; type T; expression V; @@ - T C; <... when != C - C = V; ...> // </smpl> Changes since v1: - Rebased on top of the tip of drm-misc-next. - Remove mention to sti since a proper fix got merged. Suggested-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170202162640.27261-1-krisman@collabora.co.uk
|
#
6806cdf9 |
|
24-Jan-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/kms-helpers: Use recommened kerneldoc for struct member refs I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... v2: Comments from Gustavo. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Rewiewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-2-daniel.vetter@ffwll.ch
|
#
a09759e8 |
|
06-Jan-2017 |
Vincent Abriou <vincent.abriou@st.com> |
drm: remove useless parameters from drm_pick_cmdline_mode function drm_pick_cmdline_mode width and height parameters are useless. Just remove them. Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Vincent Abriou <vincent.abriou@st.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1483721084-20278-2-git-send-email-vincent.abriou@st.com
|
#
a743d758 |
|
22-Dec-2016 |
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> |
drm: Wrap the check for atomic_commit implementation This check is useful for drivers that do not have DRIVER_ATOMIC set but have atomic modesetting internally implemented. Wrap the check into a function since this is used in many places and as a bonus, the function name helps to document what the check is for. v2: Change return type to bool (Ville) Move the function drm_atomic.h (Daniel) Fixed comment marker for documentation Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> [danvet: Move back to drmP.h because include hell.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1482396643-32456-1-git-send-email-dhinakaran.pandiyan@intel.com
|
#
c36a3254 |
|
15-Dec-2016 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm: Convert all helpers to drm_connector_list_iter Mostly nothing special (except making sure that really all error paths and friends call iter_put). v2: Don't forget the raw connector_list walking in drm_helper_move_panel_connectors_to_head. That one unfortunately can't be converted to the iterator helpers, but since it's just some list splicing best to just wrap the entire thing up in one critical section. v3: Bail out after iter_put (Harry). Cc: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161215155843.13408-1-daniel.vetter@ffwll.ch
|
#
272725c7 |
|
14-Dec-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm: Nuke fb->bits_per_pixel Replace uses of fb->bits_per_pixel with fb->format->cpp[0]*8. Less duplicated information is a good thing. Note that I didn't put parens around the cpp*8 in the below cocci script, on account of not wanting spurious parens all over the place. Instead I did the unsafe way, and tried to look over the entire diff to spot if any dangerous expressions were produced. I didn't see any. There are some cases where previously the code did X*bpp/8, so the division happened after the multiplication. Those are now just X*cpp so the division effectively happens before the multiplication, but that is perfectly fine since bpp is always a multiple of 8. @@ struct drm_framebuffer *FB; expression E; @@ drm_helper_mode_fill_fb_struct(...) { ... - FB->bits_per_pixel = E; ... } @@ struct drm_framebuffer *FB; expression E; @@ i9xx_get_initial_plane_config(...) { ... - FB->bits_per_pixel = E; ... } @@ struct drm_framebuffer *FB; expression E; @@ ironlake_get_initial_plane_config(...) { ... - FB->bits_per_pixel = E; ... } @@ struct drm_framebuffer *FB; expression E; @@ skylake_get_initial_plane_config(...) { ... - FB->bits_per_pixel = E; ... } @@ struct drm_framebuffer FB; expression E; @@ ( - E * FB.bits_per_pixel / 8 + E * FB.format->cpp[0] | - FB.bits_per_pixel / 8 + FB.format->cpp[0] | - E * FB.bits_per_pixel >> 3 + E * FB.format->cpp[0] | - FB.bits_per_pixel >> 3 + FB.format->cpp[0] | - (FB.bits_per_pixel + 7) / 8 + FB.format->cpp[0] | - FB.bits_per_pixel + FB.format->cpp[0] * 8 | - FB.format->cpp[0] * 8 != 8 + FB.format->cpp[0] != 1 ) @@ struct drm_framebuffer *FB; expression E; @@ ( - E * FB->bits_per_pixel / 8 + E * FB->format->cpp[0] | - FB->bits_per_pixel / 8 + FB->format->cpp[0] | - E * FB->bits_per_pixel >> 3 + E * FB->format->cpp[0] | - FB->bits_per_pixel >> 3 + FB->format->cpp[0] | - (FB->bits_per_pixel + 7) / 8 + FB->format->cpp[0] | - FB->bits_per_pixel + FB->format->cpp[0] * 8 | - FB->format->cpp[0] * 8 != 8 + FB->format->cpp[0] != 1 ) @@ struct drm_plane_state *state; expression E; @@ ( - E * state->fb->bits_per_pixel / 8 + E * state->fb->format->cpp[0] | - state->fb->bits_per_pixel / 8 + state->fb->format->cpp[0] | - E * state->fb->bits_per_pixel >> 3 + E * state->fb->format->cpp[0] | - state->fb->bits_per_pixel >> 3 + state->fb->format->cpp[0] | - (state->fb->bits_per_pixel + 7) / 8 + state->fb->format->cpp[0] | - state->fb->bits_per_pixel + state->fb->format->cpp[0] * 8 | - state->fb->format->cpp[0] * 8 != 8 + state->fb->format->cpp[0] != 1 ) @@ @@ - (8 * 8) + 8 * 8 @@ struct drm_framebuffer FB; @@ - (FB.format->cpp[0]) + FB.format->cpp[0] @@ struct drm_framebuffer *FB; @@ - (FB->format->cpp[0]) + FB->format->cpp[0] @@ @@ struct drm_framebuffer { ... - int bits_per_pixel; ... }; v2: Clean up the 'cpp*8 != 8' and '(8 * 8)' cases (Laurent) v3: Adjusted the semantic patch a bit and regenerated due to code changes Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1481751140-18352-1-git-send-email-ville.syrjala@linux.intel.com
|
#
b00c600e |
|
14-Dec-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm: Nuke fb->depth Replace uses of fb->depth with fb->format->depth. Less duplicate information is a good thing. @@ struct drm_framebuffer *fb; expression E; @@ drm_helper_mode_fill_fb_struct(...) { ... - fb->depth = E; ... } @@ struct nouveau_framebuffer *fb; @@ - fb->base.depth + fb->base.format->depth @@ struct drm_framebuffer fb; @@ - fb.depth + fb.format->depth @@ struct drm_framebuffer *fb; @@ - fb->depth + fb->format->depth @@ struct drm_framebuffer fb; @@ - (fb.format->depth) + fb.format->depth @@ struct drm_framebuffer *fb; @@ - (fb->format->depth) + fb->format->depth @@ @@ struct drm_framebuffer { ... - unsigned int depth; ... }; v2: Drop the vmw stuff (Daniel) Rerun spatch due to code changes Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1481751095-18249-1-git-send-email-ville.syrjala@linux.intel.com
|
#
a53ca635 |
|
28-Nov-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm: Protect fb_helper list manipulation with a mutex Though we only walk the kernel_fb_helper_list inside a panic (or single thread debugging), we still need to protect the list manipulation on creating/removing a framebuffer device in order to prevent list corruption. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20161129120217.7344-3-chris@chris-wilson.co.uk
|
#
64e94407 |
|
28-Nov-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm: Pull together probe + setup for drm_fb_helper drm_fb_helper_probe_connector_modes() is always called before drm_setup_crtcs(), so just move the call into drm_setup_crtcs for a small bit of code compaction. Note that register_framebuffer will do a modeset (when fbcon is enabled) and hence must be moved out of the critical section. A follow-up patch will add new locking for the fb list, hence move all the related registration code together. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20161129120217.7344-2-chris@chris-wilson.co.uk
|
#
966a6a13 |
|
28-Nov-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm: Hold mode_config.lock to prevent hotplug whilst setting up crtcs The fb_helper->connector_count is modified when a new connector is constructed following a hotplug event (e.g. DP-MST). This causes trouble for drm_setup_crtcs() and friends that assume that fb_helper is constant: [ 1250.872997] BUG: KASAN: slab-out-of-bounds in drm_setup_crtcs+0x320/0xf80 at addr ffff88074cdd2608 [ 1250.873020] Write of size 40 by task kworker/u8:3/480 [ 1250.873039] CPU: 2 PID: 480 Comm: kworker/u8:3 Tainted: G U 4.9.0-rc6+ #285 [ 1250.873043] Hardware name: /NUC6i3SYB, BIOS SYSKLi35.86A.0024.2015.1027.2142 10/27/2015 [ 1250.873050] Workqueue: events_unbound async_run_entry_fn [ 1250.873056] ffff88070f9d78f0 ffffffff814b72aa ffff88074e40c5c0 ffff88074cdd2608 [ 1250.873067] ffff88070f9d7918 ffffffff8124ff3c ffff88070f9d79b0 ffff88074cdd2600 [ 1250.873079] ffff88074e40c5c0 ffff88070f9d79a0 ffffffff812501e4 0000000000000005 [ 1250.873090] Call Trace: [ 1250.873099] [<ffffffff814b72aa>] dump_stack+0x67/0x9d [ 1250.873106] [<ffffffff8124ff3c>] kasan_object_err+0x1c/0x70 [ 1250.873113] [<ffffffff812501e4>] kasan_report_error+0x204/0x4f0 [ 1250.873120] [<ffffffff81698df0>] ? drm_dev_printk+0x140/0x140 [ 1250.873127] [<ffffffff81250ac3>] kasan_report+0x53/0x60 [ 1250.873134] [<ffffffff81688b40>] ? drm_setup_crtcs+0x320/0xf80 [ 1250.873142] [<ffffffff8124f18e>] check_memory_region+0x13e/0x1a0 [ 1250.873147] [<ffffffff8124f5f3>] memset+0x23/0x40 [ 1250.873154] [<ffffffff81688b40>] drm_setup_crtcs+0x320/0xf80 [ 1250.873161] [<ffffffff810be7c5>] ? wake_up_q+0x45/0x80 [ 1250.873169] [<ffffffff81b0c180>] ? mutex_lock_nested+0x5a0/0x5a0 [ 1250.873176] [<ffffffff8168a0e6>] drm_fb_helper_initial_config+0x206/0x7a0 [ 1250.873183] [<ffffffff81689ee0>] ? drm_fb_helper_set_par+0x90/0x90 [ 1250.873303] [<ffffffffa0b68690>] ? intel_fbdev_fini+0x140/0x140 [i915] [ 1250.873387] [<ffffffffa0b686b2>] intel_fbdev_initial_config+0x22/0x40 [i915] [ 1250.873391] [<ffffffff810b50ff>] async_run_entry_fn+0x7f/0x270 [ 1250.873394] [<ffffffff810a64b0>] process_one_work+0x3d0/0x960 [ 1250.873398] [<ffffffff810a641d>] ? process_one_work+0x33d/0x960 [ 1250.873401] [<ffffffff810a60e0>] ? max_active_store+0xf0/0xf0 [ 1250.873406] [<ffffffff810f6f9d>] ? do_raw_spin_lock+0x10d/0x1a0 [ 1250.873413] [<ffffffff810a767d>] worker_thread+0x8d/0x840 [ 1250.873419] [<ffffffff810a75f0>] ? create_worker+0x2e0/0x2e0 [ 1250.873426] [<ffffffff810b0454>] kthread+0x194/0x1c0 [ 1250.873432] [<ffffffff810b02c0>] ? kthread_park+0x60/0x60 [ 1250.873438] [<ffffffff810f095d>] ? trace_hardirqs_on+0xd/0x10 [ 1250.873446] [<ffffffff810b02c0>] ? kthread_park+0x60/0x60 [ 1250.873453] [<ffffffff810b02c0>] ? kthread_park+0x60/0x60 [ 1250.873457] [<ffffffff81b12277>] ret_from_fork+0x27/0x40 [ 1250.873460] Object at ffff88074cdd2608, in cache kmalloc-32 size: 32 However, when holding the mode_config.lock around the fb_helper, we have to be careful of any callbacks that may reenter the fb_helper and so try to reacquire the mode_config.lock (e.g. register_framebuffer). To avoid the mutex recursion, we have to rearrange the sequence to move the registration into the caller outside of the mode_config.lock. v2: drop the 1; following the lockdep assertion inside the for(;;), I anticipated an error that doesn't happen! Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98826 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20161129120217.7344-1-chris@chris-wilson.co.uk
|
#
c96521ee |
|
27-Nov-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm: Fix shift operations for drm_fb_helper::drm_target_preferred() smatch correctly warns: drivers/gpu/drm/drm_fb_helper.c:1960 drm_target_preferred() warn: should '1 << i' be a 64 bit type? drivers/gpu/drm/drm_fb_helper.c:2001 drm_target_preferred() warn: should '1 << i' be a 64 bit type? Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
1b99b724 |
|
13-Nov-2016 |
Stefan Christ <contact@stefanchrist.eu> |
drm/fb-helper: fix segfaults in drm_fb_helper_debug_* A drm driver that is implementing fb_debug_enter and fb_debug_leave in struct fb_ops with drm fb helper functions drm_fb_helper_debug_enter and drm_fb_helper_debug_leave must also implement the callback 'mode_set_base_atomic' in struct drm_crtc_helper_funcs. See Documentation/DocBook/kgdb.tmpl. The current implementation will segfault when 'mode_set_base_atomic' is a NULL pointer. Before this patch at least the drm drivers armada, ast, qxl, udl and virtio do not have a 'mode_set_base_atomic' implementation but using drm_fb_helper_debug_(enter|leave). So these drivers may segfault when callbacks fb_debug_(enter|leave) are called. Avoid the issue by just checking for NULL pointers. So all drivers can unconditionally implement fb_debug_(enter|leave) with the drm_fb_helper functions. If callback 'mode_set_base_atomic' is not implemented, the code in drm_fb_helper_debug_(enter|leave) does effectively nothing. Signed-off-by: Stefan Christ <contact@stefanchrist.eu> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1479078208-25221-2-git-send-email-contact@stefanchrist.eu
|
#
a2889606 |
|
26-Oct-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/fb-helper: Keep references for the current set of used connectors The fbdev helper code keeps around two lists of connectors. One is the list of all connectors it could use, and that list already holds references for all the connectors. However the other list, or rather lists, is the one actively being used. That list is tracked per-crtc and currently doesn't hold any extra references. Let's grab those extra references to avoid oopsing when the connector vanishes. The list of all possible connectors should get updated when the hpd happens, but the list of actively used connectors would not get updated until the next time the fb-helper picks through the set of possible connectors. And so we need to hang on to the connectors until that time. Since we need to clean up in drm_fb_helper_crtc_free() as well, let's pull the code to a common place. And while at it let's pull in up the modeset->mode cleanup in there as well. The case of modeset->fb is a bit less clear. I'm thinking we should probably hold a reference to it, but for now I just slapped on a FIXME. v2: Cleanup things drm_fb_helper_crtc_free() too (Chris) v3: Don't leak modeset->connectors (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Cc: Carlos Santa <carlos.santa@intel.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Tested-by: Carlos Santa <carlos.santa@intel.com> (v1) Tested-by: Kirill A. Shutemov <kirill@shutemov.name> (v1) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97666 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1477492878-4990-1-git-send-email-ville.syrjala@linux.intel.com
|
#
7dfcb36a |
|
25-Oct-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/fb-helper: Fix connector ref leak on error We need to drop the connector references already taken when we abort in the middle of drm_fb_helper_single_add_all_connectors() Cc: stable@vger.kernel.org Cc: Carlos Santa <carlos.santa@intel.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Tested-by: Carlos Santa <carlos.santa@intel.com> Tested-by: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1477472755-15288-2-git-send-email-ville.syrjala@linux.intel.com
|
#
87d3b658 |
|
20-Oct-2016 |
Takashi Iwai <tiwai@suse.de> |
drm/fb-helper: Don't call dirty callback for untouched clips Since 4.7 kernel, we've seen the error messages like kernel: [TTM] Buffer eviction failed kernel: qxl 0000:00:02.0: object_init failed for (4026540032, 0x00000001) kernel: [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate VRAM BO on QXL when switching and accessing on VT. The culprit was the generic deferred_io code (qxl driver switched to it since 4.7). There is a race between the dirty clip update and the call of callback. In drm_fb_helper_dirty(), the dirty clip is updated in the spinlock, while it kicks off the update worker outside the spinlock. Meanwhile the update worker clears the dirty clip in the spinlock, too. Thus, when drm_fb_helper_dirty() is called concurrently, schedule_work() is called after the clip is cleared in the first worker call. This patch addresses it by validating the clip before calling the dirty fb callback. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98322 Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1003298 Fixes: eaa434defaca ('drm/fb-helper: Add fb_deferred_io support') Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161020150530.5787-1-tiwai@suse.de
|
#
6686df8c |
|
21-Oct-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm: RIP mode_config->rotation_property Now that all drivers have been converted over to the per-plane rotation property, we can just nuke the global rotation property. v2: Rebase due to BIT(),__builtin_ffs() & co. Deal with superfluous code shuffling Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1477077768-4274-4-git-send-email-ville.syrjala@linux.intel.com
|
#
d138dd3c |
|
26-Sep-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm: Add support for optional per-plane rotation property Not all planes on the system may support the same rotations/reflections, so make it possible to create a separate property for each plane. This way userspace gets told exactly which rotations/reflections are possible for each plane. v2: Add drm_plane_create_rotation_property() helper v3: Drop the BIT(), __builtin_ffs(x) - 1, Moar WARNs for bad parameters Deal with superfluous code shuffling Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1474907460-10717-4-git-send-email-ville.syrjala@linux.intel.com
|
#
865afb11 |
|
11-Oct-2016 |
Stefan Agner <stefan@agner.ch> |
drm/fb-helper: reject any changes to the fbdev The current fbdev emulation does not allow to push back changes in width, height or depth to KMS, hence reject any changes with an error. This makes sure that fbdev ioctl's fail properly and user space does not assume that changes succeeded. Signed-off-by: Stefan Agner <stefan@agner.ch> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161011231504.17688-1-stefan@agner.ch
|
#
0853695c |
|
14-Oct-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm: Add reference counting to drm_atomic_state drm_atomic_state has a complicated single owner model that tracks the single reference from allocation through to destruction on another thread - or perhaps on a local error path. We can simplify this tracking by using reference counting (at a cost of a few more atomics). This is even more beneficial when the lifetime of the state becomes more convoluted than being passed to a single worker thread for the commit. v2: Double check !intel atomic_commit functions for missing gets v3: Update kerneldocs Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161014121833.439-27-chris@chris-wilson.co.uk
|
#
699fbeea |
|
19-Sep-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/fb-helper: Fix sparse warnings drm/drm_fb_helper.c:2306:12: warning: symbol 'drm_fb_helper_modinit' was not declared. Should it be static? While at it, move the lefover static inline to the right place. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1474292035-15695-4-git-send-email-ville.syrjala@linux.intel.com
|
#
28579f37 |
|
23-Aug-2016 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Make docs for fb_set_suspend wrappers consistent I figured I might as well go ocd and make them booleans and rename the locked version too. v2: Review from Noralf. Reported-by: kbuild test robot <fengguang.wu@intel.com> Cc: Noralf Trønnes <noralf@tronnes.org> Fixes: cfe63423d9be ("drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()") Acked-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160823152727.31788-1-daniel.vetter@ffwll.ch
|
#
cfe63423 |
|
23-Aug-2016 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked() This adds a function that also takes the console lock before calling fb_set_suspend() in contrast to drm_fb_helper_set_suspend() which is a plain wrapper around fb_set_suspend(). Resume is run asynchronously using a worker if the console lock is already taken. This is modelled after the i915 driver. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1471953246-29602-1-git-send-email-noralf@tronnes.org
|
#
f17b3ea3 |
|
11-Aug-2016 |
Johannes Berg <johannes.berg@intel.com> |
Revert "drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference" This reverts commit: fa7d81bb3c269 ("drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference") As Peter explained: [...] lockless_dereference() is _stronger_ than READ_ONCE(), not weaker. [...] Also, clue is in the name: 'dereference', you don't actually dereference the pointer here, only load it. My next patch breaks the compile without this revert, because it assumes you want to deference and thus also need the struct type visible (which it isn't here), so revert it. Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1470909022-687-1-git-send-email-johannes@sipsolutions.net Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
62cacc79 |
|
12-Aug-2016 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/doc: Fix more kerneldoc/sphinx warnings These are the leftovers I could only track down using keep_warnings = True. For some of them we might want to update our style guide on how to reference structures and constants, not sure ... Cc: Markus Heiser <markus.heiser@darmarit.de> Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1471034937-651-1-git-send-email-daniel.vetter@ffwll.ch
|
#
b1116f64 |
|
10-Aug-2016 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm: Remove superflous linux/fb.h includes Everyone who uses the fbdev emulation helpers doesn't need to include fb.h directly. Remove it. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1470847958-28465-3-git-send-email-daniel.vetter@ffwll.ch
|
#
31ad61e4 |
|
28-Jul-2016 |
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> |
drm: BIT(DRM_ROTATE_?) -> DRM_ROTATE_? Only property creation uses the rotation as an index, so convert the to figure the index when needed. v2: Use the new defines to build the _MASK defines (Sean) Cc: intel-gfx@lists.freedesktop.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: malidp@foss.arm.com Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Liviu Dudau <Liviu.Dudau@arm.com> Cc: Sean Paul <seanpaul@chromium.org> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1469771405-17653-1-git-send-email-joonas.lahtinen@linux.intel.com
|
#
fa7d81bb |
|
22-Jun-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference We are only documenting that the read is outside of the lock, and do not require strict ordering on the operation. In this case the more relaxed lockless_dereference() will suffice. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Julia Lawall <julia.lawall@lip6.fr> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466581572-16608-1-git-send-email-chris@chris-wilson.co.uk
|
#
95c081c1 |
|
21-Jun-2016 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm: Move master pointer from drm_minor to drm_device There can only be one current master, and it's for the overall device. Render/control minors don't support master-based auth at all. This simplifies the master logic a lot, at least in my eyes: All these additional pointer chases are just confusing. While doing the conversion I spotted some locking fail: - drm_lock/drm_auth check dev->master without holding the master_mutex. This is fallout from commit c996fd0b956450563454e7ccc97a82ca31f9d043 Author: Thomas Hellstrom <thellstrom@vmware.com> Date: Tue Feb 25 19:57:44 2014 +0100 drm: Protect the master management with a drm_device::master_mutex v3 but I honestly don't care one bit about those old legacy drivers using this. - debugfs name info should just grab master_mutex. - And the fbdev helper looked at it to figure out whether someone is using KMS. We just need a consistent value, so READ_ONCE. Aside: We should probably check if anyone has opened a control node too, but I guess current userspace doesn't really do that yet. v2: Balance locking, reported by Julia. v3: Rebase on top of Chris' oops fixes. Cc: Julia Lawall <julia.lawall@lip6.fr> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466499262-18717-1-git-send-email-daniel.vetter@ffwll.ch
|
#
d3a46183 |
|
08-Jun-2016 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm: Replace fb_helper->atomic with mode_config->atomic_commit Drivers transitioning to atomic might not yet want to enable full DRIVER_ATOMIC support when it's not entirely working. But using atomic internally makes a lot more sense earlier. Instead of spreading such flags to more places I figured it's simpler to just check for mode_config->funcs->atomic_commit, and use atomic paths if that is set. For the only driver currently transitioning (i915) this does the right thing. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465388359-8070-23-git-send-email-daniel.vetter@ffwll.ch
|
#
c61b93fe |
|
07-Jun-2016 |
Boris Brezillon <bbrezillon@kernel.org> |
drm/atomic: Fix remaining places where !funcs->best_encoder is valid Adapt drm_pick_crtcs() and update_connector_routing() to fallback to drm_atomic_helper_best_encoder() if funcs->best_encoder() is NULL so that DRM drivers can leave this hook unassigned if they know they want to use drm_atomic_helper_best_encoder(). Update the vtables documentation accordingly. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1465300095-16971-2-git-send-email-boris.brezillon@free-electrons.com
|
#
7ea77283 |
|
06-Jun-2016 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/core: Change declaration for gamma_set. Change return value to int to propagate errors from gamma_set, and remove start parameter. Updates always use the full size, and some drivers even ignore the start parameter altogether. This is needed for atomic drivers, where an atomic commit can fail with -EINTR or -ENOMEM and should be restarted. This is already and issue for drm_atomic_helper_legacy_set_gamma, which this patch fixes up. Changes since v1: - Fix compiler warning. (Emil) - Fix commit message (Daniel) Cc: Alex Deucher <alexander.deucher@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Eric Anholt <eric@anholt.net> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Mathieu Larouche <mathieu.larouche@matrox.com> Cc: Thierry Reding <treding@nvidia.com> Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [danvet: Improve commit message a bit more, mention that this fixes the helper.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/742944bc-9f41-1acb-df4f-0fd4c8a10168@linux.intel.com
|
#
fef1480d |
|
30-Mar-2016 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Remove dead code in setcolreg DRM fbdev emulation only supports pallete_color with depth == 8, and truecolor with depth > 8. Handling depth == 16 for palettes is hence dead code, let's remove it. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1459331485-28376-3-git-send-email-daniel.vetter@ffwll.ch
|
#
255f0e7c |
|
12-May-2016 |
Lyude <cpaul@redhat.com> |
drm/fb_helper: Fix references to dev->mode_config.num_connector During boot, MST hotplugs are generally expected (even if no physical hotplugging occurs) and result in DRM's connector topology changing. This means that using num_connector from the current mode configuration can lead to the number of connectors changing under us. This can lead to some nasty scenarios in fbcon: - We allocate an array to the size of dev->mode_config.num_connectors. - MST hotplug occurs, dev->mode_config.num_connectors gets incremented. - We try to loop through each element in the array using the new value of dev->mode_config.num_connectors, and end up going out of bounds since dev->mode_config.num_connectors is now larger then the array we allocated. fb_helper->connector_count however, will always remain consistent while we do a modeset in fb_helper. Note: This is just polish for 4.7, Dave Airlie's drm_connector refcounting fixed these bugs for real. But it's good enough duct-tape for stable kernel backporting, since backporting the refcounting changes is way too invasive. Cc: stable@vger.kernel.org Signed-off-by: Lyude <cpaul@redhat.com> [danvet: Clarify why we need this. Also remove the now unused "dev" local variable to appease gcc.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-3-git-send-email-cpaul@redhat.com
|
#
2dad551c |
|
11-May-2016 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Remove mention of CONFIG_FB_DEFERRED_IO in docs This was forgotten to fixup in the latest version of the deferred_io patch which made FB_DEFERRED_IO mandatory. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1462982962-10530-2-git-send-email-noralf@tronnes.org
|
#
af509d38 |
|
04-May-2016 |
Lyude <cpaul@redhat.com> |
drm/fb_helper: Fix a few typos s/modest/modeset/ s/aftert/after/ Signed-off-by: Lyude <cpaul@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1462375734-8213-3-git-send-email-cpaul@redhat.com
|
#
6e86d58b |
|
26-Apr-2016 |
Dave Airlie <airlied@redhat.com> |
drm/fb_helper: add connector reference counting. (v2) This takes a reference count when fbdev adds the connector, and drops it when it removes the connector. It also drops the now unneeded code to find connectors and remove the from the modeset as they are reference counted. v2: drop references when removing all connectors at end. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
eaa434de |
|
28-Apr-2016 |
Noralf Trønnes <noralf@tronnes.org> |
drm/fb-helper: Add fb_deferred_io support This adds deferred io support to drm_fb_helper. The fbdev framebuffer changes are flushed using the callback (struct drm_framebuffer *)->funcs->dirty() by a dedicated worker ensuring that it always runs in process context. For those wondering why we need to be able to handle atomic calling contexts: Both panic paths and cursor code and fbcon blanking can run from atomic. See commit bcb39af4486be07e896fc374a2336bad3104ae0a Author: Dave Airlie <airlied@redhat.com> Date: Thu Feb 7 11:19:15 2013 +1000 drm/udl: make usage as a console safer for where this was originally discovered. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> [danvet: Augment commit message with why we need to handle atomic contexts.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1461856717-6476-4-git-send-email-noralf@tronnes.org
|
#
15fce29d |
|
15-Feb-2016 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/fb_helper: Use add_one_connector in add_all_connectors. add_all_connectors doesn't checks whether reallocation is needed, but add_one does. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455540316-17066-2-git-send-email-maarten.lankhorst@linux.intel.com
|
#
383b2e57 |
|
15-Feb-2016 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/fb_helper: Use correct allocation count for arrays. The fb helper iterates over connectors, using fb_helper->num_connectors makes it more clear what size the allocations are. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455540316-17066-1-git-send-email-maarten.lankhorst@linux.intel.com
|
#
70412cfa |
|
21-Jan-2016 |
Rafael Antognolli <rafael.antognolli@intel.com> |
drm/kms_helper: Add a common place to call init and exit functions. The module_init and module_exit functions will start here, and call the subsequent init's and exit's. v10: - Keep __init on drm_fb_helper init function. - Move MODULE_* macros to the common file. Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1453417821-2811-2-git-send-email-rafael.antognolli@intel.com
|
#
40f8cf4b |
|
22-Jan-2016 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fbdev-helper: Explain how to debug console_lock fun Every new KMS driver writer seems to run into this and wonder how exactly drm_fb_helper_initial_config can die doing nothing at all. Set up some big warnings signs around this newbie trap to avoid future frustration and wasting everyone's time. v2: Edits from Laurent. Cc: Carlos Palminha <CARLOS.PALMINHA@synopsys.com> Cc: Xinliang Liu <xinliang.liu@linaro.org> Cc: laurent.pinchart@ideasonboard.com Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: http://patchwork.freedesktop.org/patch/msgid/1453449225-10954-1-git-send-email-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
#
7118fd9b |
|
18-Dec-2015 |
Matt Roper <matthew.d.roper@intel.com> |
drm/fb-helper: Use proper plane mask for fb cleanup pan_display_atomic() calls drm_atomic_clean_old_fb() to sanitize the legacy FB fields (plane->fb and plane->old_fb). However it was building the plane mask to pass to this function incorrectly (the bitwise OR was using plane indices rather than plane masks). The end result was that sometimes the legacy pointers would become out of sync with the atomic pointers. If another operation tried to re-set the same FB onto the plane, we might end up with the pointers back in sync, but improper reference counts, which would eventually lead to system crashes when we accessed a pointer to a prematurely-destroyed FB. The cause here was a very subtle bug introduced in commit: commit 07d3bad6c1210bd21e85d084807ef4ee4ac43a78 Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Wed Nov 11 11:29:11 2015 +0100 drm/core: Fix old_fb handling in pan_display_atomic. I found the crashes were most easily reproduced (on i915 at least) by starting X and then VT switching to a VT that wasn't running a console instance...the sequence of vt/fbcon entries that happen in that case trigger a reference count mismatch and crash the system. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93313 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
07d3bad6 |
|
11-Nov-2015 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/core: Fix old_fb handling in pan_display_atomic. Don't touch plane->old_fb/fb without having the right locks held. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447237751-9663-6-git-send-email-maarten.lankhorst@ubuntu.com
|
#
f72c6b33 |
|
11-Nov-2015 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/core: Fix old_fb handling in restore_fbdev_mode_atomic. Don't touch plane->old_fb/fb without having the right locks held. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447237751-9663-5-git-send-email-maarten.lankhorst@ubuntu.com
|
#
a0fb6ad7 |
|
16-Oct-2015 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Fix fb refcounting in pan_display_atomic In commit bbb1e52402b2a288b09ae37e8182599931c7e9df Author: Rob Clark <robdclark@gmail.com> Date: Tue Aug 25 15:35:58 2015 -0400 drm/fb-helper: atomic restore_fbdev_mode().. we've forgotten to do the plane->old_fb refcount dance for pan_display_atomic, which can result in refcount leaks if the current configuration is not from fbcon. Which apparently can happen when vt-switching - fbcon does a pan first before a set_par. OCD-align function parameters while at it. v2: Actually git add the OCD. Cc: Rob Clark <robdclark@gmail.com> Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92483 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445015490-27682-1-git-send-email-daniel.vetter@ffwll.ch Tested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
16e910df |
|
16-Oct-2015 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Set plane rotation directly The point behind standardizing properties into core drm state structures is also that internal code looks prettiers. Take advantage of that and set rotation directly in the fbdev atomic code. Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445012594-25988-1-git-send-email-daniel.vetter@ffwll.ch Acked-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
03f9abb2 |
|
30-Sep-2015 |
Alex Deucher <alexdeucher@gmail.com> |
drm: handle cursor_set2 in restore_fbdev_mode If a driver uses the cursor_set2 crtc callback rather than cursor_set, use that. This fixes the fbdev helper for drivers that use cursor_set2. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
94284037 |
|
21-Sep-2015 |
Matt Roper <matthew.d.roper@intel.com> |
drm/fbdev: Update legacy plane->fb refcounting for atomic restore Starting with commit commit 28cc504e8d52248962f5b485bdc65f539e3fe21d Author: Rob Clark <robdclark@gmail.com> Date: Tue Aug 25 15:36:00 2015 -0400 drm/i915: enable atomic fb-helper I've been seeing some panics on i915 when the DRM master shuts down that appear to be caused by using an already-freed framebuffer (i.e., we're unexpectedly dropping our initial FB's reference count to 0 and freeing it, which causes a crash when we try to restore it later). Digging deeper, the state FB refcounting is working as expected, but we seem to be missing proper refcounting on the legacy plane->fb pointers in the new atomic fbdev code. Tracking plane->old_fb and then doing a ref/unref at the end of the fbdev restore like we do in the legacy ioctl's ensures we don't miscount references on plane->fb and avoids the panics. v2 from Daniel: Really do what the atomic ioctl does: - Also update plane->fb and plane->crtc. - Clear out plane->old_fb on failures too. v3: git add everything. Oops. v4: Also clear old_fb in all other failure paths, spotted by David. Cc: Rob Clark <robdclark@gmail.com> Cc: intel-gfx@lists.freedesktop.org Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (v1) Reviewd-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
1edf0269 |
|
25-Aug-2015 |
Rob Clark <robdclark@gmail.com> |
drm/fb-helper: atomic pan_display().. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
bbb1e524 |
|
25-Aug-2015 |
Rob Clark <robdclark@gmail.com> |
drm/fb-helper: atomic restore_fbdev_mode().. Add support for using atomic code-paths for restore_fbdev_mode(). Signed-off-by: Rob Clark <robdclark@gmail.com> [danvet: Bikeshed comments slightly.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f64c5573 |
|
25-Aug-2015 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Add module option to disable fbdev emulation Faster than recompiling. Note that restore_fbdev_mode_unlocked is a bit special and the only one which returns an error code when fbdev isn't there - i915 needs that one to not fall over with some additional fbcon related restore code. Everyone else just ignores the return value or only prints a DRM_DEBUG level message. Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b7bdf0a8 |
|
25-Aug-2015 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Use -errno return in restore_mode_unlocked Using bool and returning true upon error is very uncommon. Also an int return value is actually what all the callers which did check it seem to have expected. v2: Restore hunk misplaced in a rebase, spotted by Rob. Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
cebbb739 |
|
11-Aug-2015 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/core: Set mode to NULL when connectors in a set drops to 0. Without this when a MST connector is removed drm_atomic_helper_set_config can complain about set->mode && !set->num_connectors. ------------[ cut here ]------------ WARNING: CPU: 2 PID: 2403 at drivers/gpu/drm/drm_atomic_helper.c:1673 drm_atomic_helper_set_config+0x22e/0x420() CPU: 2 PID: 2403 Comm: kms_flip Not tainted 4.2.0-rc5 #4233 Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015 ffffffff81ac75e8 ffff88004e4ffbf8 ffffffff81714c34 0000000080000000 0000000000000000 ffff88004e4ffc38 ffffffff8107bf81 ffff88004e4ffc48 ffff8800d8ca0690 ffff8800d8d7a080 ffff8800d8cc2290 ffff8800d07bc9f0 Call Trace: [<ffffffff81714c34>] dump_stack+0x4f/0x7b [<ffffffff8107bf81>] warn_slowpath_common+0x81/0xc0 [<ffffffff8107c065>] warn_slowpath_null+0x15/0x20 [<ffffffff813d9e3e>] drm_atomic_helper_set_config+0x22e/0x420 [<ffffffff813da174>] ? drm_atomic_helper_plane_set_property+0x84/0xc0 [<ffffffff813ee101>] drm_mode_set_config_internal+0x61/0x100 [<ffffffff813dc4ed>] restore_fbdev_mode+0xbd/0xe0 [<ffffffff813de1e4>] drm_fb_helper_restore_fbdev_mode_unlocked+0x24/0x70 [<ffffffffc0123d11>] intel_fbdev_restore_mode+0x21/0x80 [i915] [<ffffffffc014bf69>] i915_driver_lastclose+0x9/0x10 [i915] [<ffffffff813e2429>] drm_lastclose+0x29/0x130 [<ffffffff813e2844>] drm_release+0x314/0x500 [<ffffffff81194795>] __fput+0xe5/0x1f0 [<ffffffff811948d9>] ____fput+0x9/0x10 [<ffffffff810968d8>] task_work_run+0x88/0xb0 [<ffffffff8107d53f>] do_exit+0x37f/0xa90 [<ffffffff8127e258>] ? selinux_file_ioctl+0x48/0xc0 [<ffffffff81277dfe>] ? security_file_ioctl+0x3e/0x60 [<ffffffff8107ec80>] do_group_exit+0x40/0xa0 [<ffffffff8107ecef>] SyS_exit_group+0xf/0x10 [<ffffffff8171bdd7>] entry_SYSCALL_64_fastpath+0x12/0x6a ---[ end trace 0daf358c49351567 ]--- Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2c4124fd |
|
04-Aug-2015 |
Geert Uytterhoeven <geert+renesas@glider.be> |
drm/fb-helper: Move drm_fb_helper_force_kernel_mode() inside #ifdef If CONFIG_MAGIC_SYSRQ is not set: drivers/gpu/drm/drm_fb_helper.c:390:13: warning: 'drm_fb_helper_force_kernel_mode' defined but not used [-Wunused-function] static bool drm_fb_helper_force_kernel_mode(void) ^ Move drm_fb_helper_force_kernel_mode() inside the existing #ifdef to fix this. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3d9e35a9 |
|
04-Aug-2015 |
Geert Uytterhoeven <geert+renesas@glider.be> |
drm/fb-helper: Clarify drm_fb_helper_restore_fbdev_mode*() As of commit 5ea1f752ae04be40 ("drm: add drm_fb_helper_restore_fbdev_mode_unlocked()"), drm_fb_helper_restore_fbdev_mode() is no longer public, and drivers should call drm_fb_helper_restore_fbdev_mode_unlocked() from their ->lastclose callbacks instead. Update the documentation to reflect this, and absorb the one liner drm_fb_helper_restore_fbdev_mode() into its single caller. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
dd908c86 |
|
28-Jul-2015 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Stop using trylocks in force_restore Since the panic handling is gone this is only used for force-restoring the fbdev/fbcon from sysrq, and that's done with a work item. No need any more to do trylocks, we can just do normal locking. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
#
c50bfd08 |
|
28-Jul-2015 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fbdev: Return -EBUSY when oopsing Trying to do anything with kms drivers when oopsing has become a failing proposition. But since we can end up in the fbdev code simply due to the console unblanking that's done unconditionally just removing our panic handler isn't enough. We need to block all fbdev callbacks when oopsing. There was already one in the blank handler, but it failed silently. That makes it impossible for drivers (like i915) who subclass these functions to figure this out. Instead consistently return -EBUSY so that everyone knows that we really don't want to be bothered right now. This also allows us to remove a pile of FIXMEs from the i915 fbdev code (since due to the failure code they now won't attempt to grab dangerous locks any more). Cc: Dave Airlie <airlied@gmail.com> Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
#
fdefa58a |
|
31-Jul-2015 |
Archit Taneja <architt@codeaurora.org> |
drm/fb_helper: Create a wrapper for fb_set_suspend Some drm drivers call fb_set_suspend. Create a drm_fb_helper function that wraps around these calls. This is part of an effort to prevent drm drivers from calling fbdev functions directly, in order to make fbdev emulation a top level drm option. v3: - Fixed kerneldoc errors v2: - Added kerneldocs - Added a check for non-NULL fb_helper before proceeding. This will make the helpers work when we have a module param for fbdev emulation - Follow the drm way of aligning of arguments in func definitions Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
742547b7 |
|
31-Jul-2015 |
Archit Taneja <architt@codeaurora.org> |
drm/fb_helper: Create wrappers for blit, copyarea and fillrect funcs drm drivers that emulate fbdev populate their fb_fillrect, fb_copyarea and fb_imageblit fb_ops with the help of cfb_* or sys_* fbdev core helper functions. Create drm_fb_helper functions that wrap around these calls. This is part of an effort to prevent drm drivers from calling fbdev functions directly, in order to make fbdev emulation a top level drm option. v3: - Fixed kerneldoc errors v2: - Added kerneldocs - Follow the drm way of aligning of arguments in func definitions - Remove unnecessary checks for non NULL fb_info Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
cbb1a82e |
|
31-Jul-2015 |
Archit Taneja <architt@codeaurora.org> |
drm/fb_helper: Create wrappers for fb_sys_read/write funcs Some drm drivers populate their fb_ops with fb_sys_read/write fb sysfs ops. Create a drm_fb_helper function that wraps around these calls. This is part of an effort to prevent drm drivers from calling fbdev functions directly, in order to make fbdev emulation a top level drm option. v3: - Fix kerneldoc errors v2: - Added kerneldocs - Follow the drm way of aligning of arguments in func definitions - Remove unnecessary checks for non NULL fb_info Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
47074ab7 |
|
22-Jul-2015 |
Archit Taneja <architt@codeaurora.org> |
drm/fb_helper: Create a wrapper for unlink_framebuffer Some drm drivers call unlink_framebuffer. Create a drm_fb_helper function that wraps around these calls. This is part of an effort to prevent drm drivers from calling fbdev functions directly, in order to make fbdev emulation a top level drm option. v2: - Added kerneldocs - Added a check for non-NULL fb_helper before proceeding. This will make the helpers work when we have a module param for fbdev emulation Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b8017d6c |
|
22-Jul-2015 |
Archit Taneja <architt@codeaurora.org> |
drm/fb_helper: Add drm_fb_helper functions to manage fb_info creation Every drm driver calls framebuffer_alloc, fb_alloc_cmap, unregister_framebuffer, fb_dealloc_cmap and framebuffer_release in order to emulate fbdev support. Create drm_fb_helper functions that perform the above operations. This is part of an effort to prevent drm drivers from calling fbdev functions directly. It also removes repetitive code from drivers. There are some drivers that call alloc_apertures after framebuffer_alloc and some that don't. Make the helper always call alloc_apertures. This would make certain drivers allocate memory for apertures but not use them. Since it's a small amount of memory, it shouldn't be an issue. v2: - Added kerneldocs - Added a check for non-NULL fb_helper before proceeding. This will make the helpers work when we have a module param for fbdev emulation Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
169faeca |
|
09-Jul-2015 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fbdev-helper: Grab mode_config.mutex in drm_fb_helper_single_add_all_connectors This is now truly only duct-tape to keep locking checks happy since calling this function when hpd or polling are already enabled is a bug. The fbdev helper can't cope with hotplug changes yet at this point, only after that. Otoh a bit more robustness in this function can't hurt, and with this fbdev can actually cope with hotplug changes. And it's also more consistent with the connector hotadd/remove dp mst needs to do. Therefore document this as new official behavior. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
#
6295d607 |
|
09-Jul-2015 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm: Add modeset object iterators And roll them out across drm_* files. The point here isn't code prettification (it helps with that too) but that some of these lists aren't static any more. And having macros will gives us a convenient place to put locking checks into. I didn't add an iterator for props since that's only used by a list_for_each_entry_safe in the driver teardown code. Search&replace was done with the below cocci spatch. Note that there's a bunch more places that didn't match and which would need some manual changes, but I've intentially left these out for this mostly automated patch. iterator name drm_for_each_crtc; struct drm_crtc *crtc; struct drm_device *dev; expression head; @@ - list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) { + drm_for_each_crtc (crtc, dev) { ... } @@ iterator name drm_for_each_encoder; struct drm_encoder *encoder; struct drm_device *dev; expression head; @@ - list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) { + drm_for_each_encoder (encoder, dev) { ... } @@ iterator name drm_for_each_fb; struct drm_framebuffer *fb; struct drm_device *dev; expression head; @@ - list_for_each_entry(fb, &dev->mode_config.fb_list, head) { + drm_for_each_fb (fb, dev) { ... } @@ iterator name drm_for_each_connector; struct drm_connector *connector; struct drm_device *dev; expression head; @@ - list_for_each_entry(connector, &dev->mode_config.connector_list, head) { + drm_for_each_connector (connector, dev) { ... } Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
#
6066677c |
|
08-Jul-2015 |
Dave Airlie <airlied@redhat.com> |
drm/fb: drop panic handling This really doesn't seem to have much chance of working anymore, esp for irq context, qxl at least tries to talk to the hw, and waits for irqs, and fails. with runtime pm and other stuff I think we should just bail on this for now. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
be26a66d |
|
11-Mar-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/drm: constify all struct drm_*_helper funcs pointers They are not to be modified. Generated using the semantic patch: @@ @@ ( const struct drm_crtc_helper_funcs * | - struct drm_crtc_helper_funcs * + const struct drm_crtc_helper_funcs * ) @@ @@ ( const struct drm_encoder_helper_funcs * | - struct drm_encoder_helper_funcs * + const struct drm_encoder_helper_funcs * ) @@ @@ ( const struct drm_connector_helper_funcs * | - struct drm_connector_helper_funcs * + const struct drm_connector_helper_funcs * ) @@ @@ ( const struct drm_plane_helper_funcs * | - struct drm_plane_helper_funcs * + const struct drm_plane_helper_funcs * ) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f3af5c7d |
|
18-Mar-2015 |
Daniel Stone <daniels@collabora.com> |
drm: fb_helper: Simplify exit condition mode is always NULL at this point in the function, so make our intention clear. Signed-off-by: Daniel Stone <daniels@collabora.com> [danvet: Stop clearing mode too to enlist gcc in tracking uninitialized usage. And remove a space while at it.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0e3704c9 |
|
11-Mar-2015 |
Rob Clark <robdclark@gmail.com> |
drm/fb: handle tiled connectors better We don't want tile 0,0 to artificially constrain the size of the legacy fbdev device. Instead when reducing fb_size to be the minimum of all displays, only consider the rightmost and bottommost tiles. Signed-off-by: Rob Clark <robdclark@gmail.com> Tested-by: Hai Li <hali@codeaurora.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
675c8328 |
|
11-Mar-2015 |
Rob Clark <robdclark@gmail.com> |
drm/fb: small cleanup Flip conditional to reduce indentation level of rest of fxn, and use min/max to make the code clearer. v2: surface_width -> surface_height typo Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2148f18f |
|
26-Jan-2015 |
Rob Clark <robdclark@gmail.com> |
drm: fix fb-helper vs MST dangling connector ptrs (v2) VT switch back/forth from console to xserver (for example) has potential to go horribly wrong if a dynamic DP MST connector ends up in the saved modeset that is restored when switching back to fbcon. When removing a dynamic connector, don't forget to clean up the saved state. v1: original v2: null out set->fb if no more connectors to avoid making i915 cranky Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1184968 Cc: stable@vger.kernel.org #v3.17+ Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
01934c2a |
|
19-Dec-2014 |
Thierry Reding <treding@nvidia.com> |
drm/fb-helper: Propagate errors from initial config failure Make drm_fb_helper_initial_config() return an int rather than a bool so that the error can be properly propagated. While at it, update drivers to propagate errors further rather than just ignore them. v2: - cirrus: No cleanup is required, the top-level cirrus_driver_load() will do it as part of cirrus_driver_unload() in its cleanup path. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> [danvet: Squash in simplification patch from kbuild.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9aa609e1 |
|
15-Dec-2014 |
Rui Wang <rui.y.wang@intel.com> |
drm: fb helper should avoid sleeping in panic context There are still some places in the fb helper that need to avoid sleeping in panic context. Here's an example: [ 65.615496] bad: scheduling from the idle thread! [ 65.620747] CPU: 92 PID: 0 Comm: swapper/92 Tainted: G M E 3.18.0-rc4-7-default+ #20 [ 65.630364] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRHSXSD1.86B.0056.R01.1409242327 09/24/2014 [ 65.641923] ffff88087f693d80 ffff88087f689878 ffffffff81566db9 0000000000000000 [ 65.650226] ffff88087f693d80 ffff88087f689898 ffffffff810871ff ffff88046eb3e0d0 [ 65.658527] ffff88087f693d80 ffff88087f6898c8 ffffffff8107c1fa 000000017f6898b8 [ 65.666830] Call Trace: [ 65.669557] <#MC> [<ffffffff81566db9>] dump_stack+0x46/0x58 [ 65.675994] [<ffffffff810871ff>] dequeue_task_idle+0x2f/0x40 [ 65.682412] [<ffffffff8107c1fa>] dequeue_task+0x5a/0x80 [ 65.688345] [<ffffffff810804f3>] deactivate_task+0x23/0x30 [ 65.694569] [<ffffffff81569050>] __schedule+0x580/0x7f0 [ 65.700502] [<ffffffff81569739>] schedule_preempt_disabled+0x29/0x70 [ 65.707696] [<ffffffff8156abb6>] __ww_mutex_lock_slowpath+0xb8/0x162 [ 65.714891] [<ffffffff8156acb3>] __ww_mutex_lock+0x53/0x85 [ 65.721125] [<ffffffffa00b3a5d>] drm_modeset_lock+0x3d/0x110 [drm] [ 65.728132] [<ffffffffa00b3c2a>] __drm_modeset_lock_all+0x8a/0x120 [drm] [ 65.735721] [<ffffffffa00b3cd0>] drm_modeset_lock_all+0x10/0x30 [drm] [ 65.743015] [<ffffffffa01af8bf>] drm_fb_helper_pan_display+0x2f/0xf0 [drm_kms_helper] [ 65.751857] [<ffffffff8132bd21>] fb_pan_display+0xd1/0x1a0 [ 65.758081] [<ffffffff81326010>] bit_update_start+0x20/0x50 [ 65.764400] [<ffffffff813259f2>] fbcon_switch+0x3a2/0x550 [ 65.770528] [<ffffffff813a01c9>] redraw_screen+0x189/0x240 [ 65.776750] [<ffffffff81322f8a>] fbcon_blank+0x20a/0x2d0 [ 65.782778] [<ffffffff8137d359>] ? erst_writer+0x209/0x330 [ 65.789002] [<ffffffff810ba2f3>] ? internal_add_timer+0x63/0x80 [ 65.795710] [<ffffffff810bc137>] ? mod_timer+0x127/0x1e0 [ 65.801740] [<ffffffff813a0cd8>] do_unblank_screen+0xa8/0x1d0 [ 65.808255] [<ffffffff813a0e10>] unblank_screen+0x10/0x20 [ 65.814381] [<ffffffff812ca0d9>] bust_spinlocks+0x19/0x40 [ 65.820508] [<ffffffff81561ca7>] panic+0x106/0x1f5 [ 65.825955] [<ffffffff8102336c>] mce_panic+0x2ac/0x2e0 [ 65.831789] [<ffffffff812c796a>] ? delay_tsc+0x4a/0x80 [ 65.837625] [<ffffffff81024e1f>] do_machine_check+0xbaf/0xbf0 [ 65.844138] [<ffffffff813365d7>] ? intel_idle+0xc7/0x150 [ 65.850166] [<ffffffff8156f03f>] machine_check+0x1f/0x30 [ 65.856195] [<ffffffff813365d7>] ? intel_idle+0xc7/0x150 [ 65.862222] <<EOE>> [<ffffffff814283d5>] cpuidle_enter_state+0x55/0x170 [ 65.869823] [<ffffffff814285a7>] cpuidle_enter+0x17/0x20 [ 65.875852] [<ffffffff81097b08>] cpu_startup_entry+0x2d8/0x370 [ 65.882467] [<ffffffff8102fe29>] start_secondary+0x159/0x180 There's __drm_modeset_lock_all() which Daniel Vetter introduced for this purpose. We can leverage that without reinventing anything. This patch works with the latest kernel. Reviewed-by: Rob Clark <robdclark@gmail.com> Tested-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Rui Wang <rui.y.wang@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
b0ee9e7f |
|
20-Oct-2014 |
Dave Airlie <airlied@redhat.com> |
drm/fb: add support for tiled monitor configurations. (v2) This adds fbdev/con support for tiled monitors, so that we only set a mode on the correct half of the monitor, or span the two halves if needed. v2: remove unneeded ERROR, fix | vs || Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
e2809c7d |
|
25-Nov-2014 |
Dave Airlie <airlied@redhat.com> |
drm/fb_helper: move deferred fb checking into restore mode (v2) On MST systems the monitors don't appear when we set the fb up, but plymouth opens the drm device and holds it open while they come up, when plymouth finishes and lastclose gets called we don't do the delayed fb probe, so the monitor never appears on the console. Fix this by moving the delayed checking into the mode restore. v2: Daniel suggested that ->delayed_hotplug is set under the mode_config mutex, so we should check it under that as well, while we are in the area. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
b74c6c92 |
|
03-Nov-2014 |
Peter Hurley <peter@hurleysoftware.com> |
drm: Remove compiler BUG_ON() test modeset->num_connectors must be 0 to reach the BUG_ON() which tests for non-zero modeset->num_connectors; remove BUG_ON(). Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3a5f87c2 |
|
20-Aug-2014 |
Thomas Wood <thomas.wood@intel.com> |
drm: fix plane rotation when restoring fbdev configuration Make sure plane rotation is reset correctly when restoring the fbdev configuration by using drm_mode_plane_set_obj_prop which calls the driver's set_property callback. The rotation reset feature was introduced in commit 9783de2 (drm: Resetting rotation property) and the callback issue was originally addressed in a previous version of the patch, but the fix was not present in the final version. v2: Fix documentation warning Add some more details to the commit message (Daniel Vetter) Testcase: igt/kms_rotation_crc Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82236 Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thomas Wood <thomas.wood@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
14f476fa |
|
08-Aug-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm: Use the type of the array element when reallocating Static analysers find it 'suspicious', that we're trying to allocate memory for elements of size sizeof(struct drm_fb_helper_connector) when the array is defined as struct drm_fb_helper_connector **. Use sizeof(struct drm_fb_helper_connector *) instead. Note that the structure being defined as: struct drm_fb_helper_connector { struct drm_connector *connector; }; This was still doing the right thing, but may not in the future if additional fields are added. Cc: Todd Previte <tprevite@gmail.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
cb597bb3 |
|
27-Jul-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm: trylock modest locking for fbdev panics In the fbdev code we want to do trylocks only to avoid deadlocks and other ugly issues. Thus far we've only grabbed the overall modeset lock, but that already failed to exclude a pile of potential concurrent operations. With proper atomic support this will be worse. So add a trylock mode to the modeset locking code which attempts all locks only with trylocks, if possible. We need to track this in the locking functions themselves and can't restrict this to drivers since driver-private w/w mutexes must be treated the same way. There's still the issue that other driver private locks aren't handled here at all, but well can't have everything. With this we will at least not regress, even once atomic allows lots of concurrent kms activity. Aside: We should move the acquire context to stack-based allocation in the callers to get rid of that awful WARN_ON(kmalloc_failed) control flow which just blows up when memory is short. But that's material for separate patches. v2: - Fix logic inversion fumble in the fb helper. - Add proper kerneldoc. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9783de20 |
|
04-Aug-2014 |
Sonika Jindal <sonika.jindal@intel.com> |
drm: Resetting rotation property Reset rotation property to 0. v2: Resetting after disabling the plane Signed-off-by: Sonika Jindal <sonika.jindal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
eaf99c74 |
|
06-Aug-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm: Perform cmdline mode parsing during connector initialisation i915.ko has a custom fbdev initialisation routine that aims to preserve the current mode set by the BIOS, unless overruled by the user. The user's wishes are determined by what, if any, mode is specified on the command line (via the video= parameter). However, that command line mode is first parsed by drm_fb_helper_initial_config() which is called after i915.ko's custom initial_config() as a fallback method. So in order for us to honour it, we need to move the cmdline parser earlier. If we perform the connector cmdline parsing as soon as we initialise the connector, that cmdline mode and forced status is then available even if the fbdev helper is not compiled in or never called. We also then expose the cmdline user mode in the connector mode lists. v2: Rebase after connector->name upheaval. v3: Adapt mga200 to look for the cmdline mode in the new place. Nicely simplifies things while at that. v4: Fix checkpatch. v5: Select FB_CMDLINE to adapt to the changed fbdev patch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73154 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2) Cc: dri-devel@lists.freedesktop.org Cc: Julia Lemire <jlemire@matrox.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
65c2a89c |
|
04-Jun-2014 |
Dave Airlie <airlied@redhat.com> |
drm/fb_helper: allow adding/removing connectors later This is required to get fbcon probing to work on new connectors, callers should acquire the mode config lock before calling these. Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
10a23102 |
|
27-Jun-2014 |
Thierry Reding <treding@nvidia.com> |
drm: Introduce drm_fb_helper_prepare() To implement hotplug detection in a race-free manner, drivers must call drm_kms_helper_poll_init() before hotplug events can be triggered. Such events can be triggered right after any of the encoders or connectors are initialized. At the same time, if the drm_fb_helper_hotplug_event() helper is used by a driver, then the poll helper requires some parts of the FB helper to be initialized to prevent a crash. At the same time, drm_fb_helper_init() requires information that is not necessarily available at such an early stage (number of CRTCs and connectors), so it cannot be used yet. Add a new helper, drm_fb_helper_prepare(), that initializes the bare minimum needed to allow drm_kms_helper_poll_init() to execute and any subsequent hotplug events to be processed properly. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
50c3dc97 |
|
27-Jun-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Fix hpd vs. initial config races Some drivers need to be able to have a perfect race-free fbcon setup. Current drivers only enable hotplug processing after the call to drm_fb_helper_initial_config which leaves a tiny but important race. This race is especially noticable on embedded platforms where the driver itself enables the voltage for the hdmi output, since only then will monitors (after a bit of delay, as usual) respond by asserting the hpd pin. Most of the infrastructure is already there with the split-out drm_fb_helper_init. And drm_fb_helper_initial_config already has all the required locking to handle concurrent hpd events since commit 53f1904bced78d7c00f5d874c662ec3ac85d0f9f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Mar 20 14:26:35 2014 +0100 drm/fb-helper: improve drm_fb_helper_initial_config locking The only missing bit is making drm_fb_helper_hotplug_event save against concurrent calls of drm_fb_helper_initial_config. The only unprotected bit is the check for fb_helper->fb. With that drivers can first initialize the fb helper, then enabel hotplug processing and then set up the initial config all in a completely race-free manner. Update kerneldoc and convert i915 as a proof of concept. Feature requested by Thierry since his tegra driver atm reliably boots slowly enough to misses the hotplug event for an external hdmi screen, but also reliably boots to quickly for the hpd pin to be asserted when the fb helper calls into the hdmi ->detect function. Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
2a8c6edf |
|
19-Jun-2014 |
Liu Ying <Ying.Liu@freescale.com> |
drm/fb-helper: Remove unnecessary list empty check in drm_fb_helper_debug_enter() The following list empty check is unnecessary because we would still do nothing real and return 'val' if my_list is empty. if (list_empty(&my_list)) return val; list_for_each_entry(pos, &my_list, member) { ... } return val; This patch removes the unnecessary check in drm_fb_helper_debug_enter(). Signed-off-by: Liu Ying <Ying.Liu@freescale.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
30bfa4ee |
|
19-Jun-2014 |
Liu Ying <Ying.Liu@freescale.com> |
drm/fb-helper: Redundant info->fix.type_aux setting in drm_fb_helper_fill_fix() The variable info->fix.type_aux is set to zero twice in the function drm_fb_helper_fill_fix(). This patch removes one redundant. Signed-off-by: Liu Ying <Ying.Liu@freescale.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5ea1f752 |
|
29-May-2014 |
Rob Clark <robdclark@gmail.com> |
drm: add drm_fb_helper_restore_fbdev_mode_unlocked() All drm_fb_helper_restore_fbdev_mode() call sites, save one, do the same locking. Simplify this into drm_fb_helper_restore_fbdev_mode_unlocked(). Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
51fd371b |
|
18-Nov-2013 |
Rob Clark <robdclark@gmail.com> |
drm: convert crtc and connection_mutex to ww_mutex (v5) For atomic, it will be quite necessary to not need to care so much about locking order. And 'state' gives us a convenient place to stash a ww_ctx for any sort of update that needs to grab multiple crtc locks. Because we will want to eventually make locking even more fine grained (giving locks to planes, connectors, etc), split out drm_modeset_lock and drm_modeset_acquire_ctx to track acquired locks. Atomic will use this to keep track of which locks have been acquired in a transaction. v1: original v2: remove a few things not needed until atomic, for now v3: update for v3 of connection_mutex patch.. v4: squash in docbook v5: doc tweaks/fixes Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
25933820 |
|
03-Jun-2014 |
Jani Nikula <jani.nikula@intel.com> |
drm: replace drm_get_connector_name() with direct name field use Generated using semantic patch: @@ expression E; @@ - drm_get_connector_name(E) + E->name [airlied: regenerated] Acked-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
83c617c5 |
|
29-Apr-2014 |
Thierry Reding <treding@nvidia.com> |
drm/fb: Fix typos Fix a few trivial typos in the framebuffer helper documentation. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b77f0765 |
|
29-Apr-2014 |
Thierry Reding <treding@nvidia.com> |
drm: Try to acquire modeset lock on panic or sysrq Commit 62ff94a54921 "drm/crtc-helper: remove LOCKING from kerneldoc" causes drm_helper_crtc_in_use() and drm_helper_encoder_in_use() to complain loudly during a kernel panic or sysrq processing. This is caused by nobody acquiring the modeset lock in these code paths. This patch fixes this by trying to acquire the modeset lock for each FB helper that's forced to kernel mode. If the lock can't be acquired, it's likely that somebody else is performing a modeset. However, doing another modeset concurrently might make things even worse, so the safe option is to simply bail out in that case. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c683f427 |
|
19-Mar-2014 |
Takashi Iwai <tiwai@suse.de> |
drm: Prefer noninterlace cmdline mode unless explicitly specified Currently drm_pick_cmdline_mode() doesn't care about the interlace when the given mode line has no "i" suffix. That is, when there are multiple entries for the same resolution, an interlace mode might be picked up just depending on the assigned order, and there is no way to exclude it. This patch changes the logic for the mode selection, to prefer the noninterlace mode unless the interlace mode is explicitly given. When no matching mode is found, it still tries the interlace mode as fallback. Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
f4510a27 |
|
01-Apr-2014 |
Matt Roper <matthew.d.roper@intel.com> |
drm: Replace crtc fb with primary plane fb (v3) Now that CRTC's have a primary plane, there's no need to track the framebuffer in the CRTC. Replace all references to the CRTC fb with the primary plane's fb. This patch was generated by the Coccinelle semantic patching tool using the following rules: @@ struct drm_crtc C; @@ - (C).fb + C.primary->fb @@ struct drm_crtc *C; @@ - (C)->fb + C->primary->fb v3: Generate patch via coccinelle. Actual removal of crtc->fb has been moved to a subsequent patch. v2: Fixup several lingering crtc->fb instances that were missed in the first patch iteration. [Rob Clark] Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
|
#
e27dde3e |
|
01-Apr-2014 |
Matt Roper <matthew.d.roper@intel.com> |
drm: Add support for multiple plane types (v2) The DRM core currently only tracks "overlay"-style planes. Start refactoring the plane handling to allow other plane types (primary and cursor) to also be placed on the DRM plane list. v2: Add drm_for_each_legacy_plane() iterator to smooth transition of drivers with plane loops. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
|
#
53f1904b |
|
20-Mar-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: improve drm_fb_helper_initial_config locking The locking in drm_fb_helper_initial_config is a bit troublesome for a few reasons: - We can't just wrap the entire function up into modeset locks since the fbdev registration might call down into fbcon code, which then through our ->set_par implementation needs to be able to grab all modeset locks. So we'd have a neat deadlock. - This implies though that all current callers don't hold any modeset locks by necessity, so we have free reign to grab any modeset locks we need to grab. - The private state of the fbdev helper doesn't need any protection through locks, since once we have the fbdev registered it is mostly invariant or protected through the modeset locking in ->set_par and other callbacks. We can fully rely on driver having non-racy setup sequences here. For the initial config computation we actually may not grab locks since drivers which provide their own magic sauce (like i915) might need to grab locks themselves. - We should grab locks though when we probe outputs. Currently there's not much risk, but already now userspace could start poking at sysfs files and so probe concurrently. I expect that in the future driver init will be much more async, and since probing is really time-consuming this is a prime candidate. - We must not hold any crtc->mutex locks while calling probe functions since those might need to lock a crtc for e.g. load detection. i915 is such a driver. Also it's the probing calls which hit upon piles of new locking asserts I've recently added in commit 62ff94a5492175759546f8bc61383189d6b49122 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jan 23 22:18:47 2014 +0100 drm/crtc-helper: remove LOCKING from kerneldoc and commit 63951385052f7974155fa38f962f0f4e9847f90a Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jan 23 15:14:15 2014 +0100 drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c Hence the right fix is to grab the mode_config mutex, but only that and only right around the probe calls. It seems to be sufficient to shut up all the locking WARNINGs I see on i915 and nouveau in drm_fb_helper_initial_config. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
04cfe97e |
|
09-Mar-2014 |
Xiubo Li <Li.Xiubo@freescale.com> |
drm/fb-helper: Do the 'max_conn_count' zero check Since we cannot make sure the 'max_conn_count' will always be none zero from the users, and then if max_conn_count equals to zero, the kcalloc() will return ZERO_SIZE_PTR, which equals to ((void *)16). So this patch fix this with just doing the 'max_conn_count' zero check in the front of drm_fb_helper_init(). Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com> CC: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
366d4807 |
|
26-Feb-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/fb-helper: Use drm_fb_helper_restore_fbdev_mode() in drm_fb_helper_set_par() Use drm_fb_helper_restore_fbdev_mode() in drm_fb_helper_set_par() to make sure extra planes get disabled whenever fbcon takes over. Otherwise the code in drm_fb_helper_set_par() was already doing the exact same thing as drm_fb_helper_restore_fbdev_mode(), so this doesn't change the behaviour in any other way. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9d3de138 |
|
23-Jan-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/modes: remove drm_mode_height/width There's a neat FIXME asking whether this is really need. I'd say really no. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2f1046f3 |
|
12-Feb-2014 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm: export cmdline and preferred mode functions from fb helper This allows drivers to use them in custom initial_config functions. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
520edd13 |
|
27-Nov-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm: do not steal the display if we have a master Sometimes we want to disable all the screens on a system, because that will allow the graphics card to be put into low-power states. The problem is that, for example, while all screens are disabled, if we get a hotplug interrupt, fbcon will decide to set a mode instead of keeping everything disabled, which will remove us from our low power states. Let's assume that if there's a DRM master, it will be able to do whatever is appropriate when we get the hotplug. This problem can be reproduced by the runtime PM test program from intel-gpu-tools: we disable all the screens so the graphics device can be put into D3, then something triggers a hotplug interrupt, fbcon sets a mode and breaks our test suite. The problem can be reproduced more easily by the "i2c" subtest. Other approaches considered for the problem: - Return "false" if "bound == 0" and the caller of drm_fb_helper_is_bound is a hotplug handler. This would break the case where the machine boots with no outputs connected, then the user plugs a monitor. - Add a new IOCTL to force fbcon to not set modes. This would keep all the current applications behaving the same, but adding a new IOCTL is not always the greatest idea. - Return false only if "dev->primary->master && bound == 0". This was my first implementation, but Chris suggested we should do the check irrespective of the "bound" variable. Thanks to Daniel Vetter for the investigation, ideas and the implementation of the hotplug alternative. v2: - Do the check first, irrespective of "bound". - Cc dri-devel Cc: dri-devel@lists.freedesktop.org Credits-to: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
92b6f89f |
|
08-Oct-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm: Add separate Kconfig option for fbdev helpers For drivers which might want to disable fbdev legacy support. Select the new option in all drivers for now, so this shouldn't result in any change. Drivers need some work anyway to make fbdev support optional (if they have it implemented, that is), so the recommended way to expose this is by adding per-driver options. At least as long as most drivers don't support disabling the fbdev support. v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm driver can already take advantage of this, which allows us to build msm without any fbdev depencies in the kernel! v3: Move the MODULE_* stuff from the fbdev helper file to drm_crtc_helper.c. Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Acked-by: Dave Airlie <airlied@linux.ie> Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ecc7e6f3 |
|
09-Oct-2013 |
Dave Airlie <airlied@redhat.com> |
Revert "drm/fb-helper: don't sleep for screen unblank when an oops is in progress" This reverts commit 928c2f0c006bf7f381f58af2b2786d2a858ae311. This patch double applied, two checks for the price of one. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
51bbd276 |
|
28-Sep-2013 |
Lespiau, Damien <damien.lespiau@intel.com> |
drm: Remove unused variables in drm_fb_helper_hotplug_event() Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
86aed676 |
|
28-Sep-2013 |
Lespiau, Damien <damien.lespiau@intel.com> |
drm: Remove unused variable in drm_pick_crtcs() Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
bd89bcb0 |
|
28-Sep-2013 |
Lespiau, Damien <damien.lespiau@intel.com> |
drm: Remove unused variable in drm_fb_helper_pan_display() Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
928c2f0c |
|
13-Sep-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: don't sleep for screen unblank when an oops is in progress Otherwise the system will burn even brighter and worse, leave the user wondering what's going on exactly. Since we already have a panic handler which will (try) to restore the entire fbdev console mode, we can just bail out. Inspired by a patch from Konstantin Khlebnikov. The callchain leading to this, cut&pasted from Konstantin's original patch: callstack: panic() bust_spinlocks(1) unblank_screen() vc->vc_sw->con_blank() fbcon_blank() fb_blank() info->fbops->fb_blank() drm_fb_helper_blank() drm_fb_helper_dpms() drm_modeset_lock_all() mutex_lock(&dev->mode_config.mutex) Note that the entire locking in the fb helper around panic/sysrq and kdbg is ... non-existant. So we have a decent change of blowing up everything. But since reworking this ties in with funny concepts like the fbdev notifier chain or the impressive things which happen around console_lock while oopsing, I'll leave that as an exercise for braver souls than me. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Dave Airlie <airlied@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
04c0c569 |
|
27-May-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/fb-helper: Make load_lut and gamma_set/gamma_get hooks optional Check whether the crtc provides the load_lut callback before calling it. This allows the driver to provide the hook only for those CRTCs that actually have the hardware support for it. Also check whether the driver provided the fb_helper gamma_set/gamma_get hooks. It's a driver bug if it allows non-truecolor fbdev visuals w/o these hooks, but auditing all the drivers is too tedious. So just slap a big WARN_ON() there and bail out before things start to explode. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@gmail.com>
|
#
8391a3d5 |
|
27-May-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/fb-helper: Don't clobber the display palette when fbdev isn't bound Perform the drm_fb_helper_is_bound() check to avoid clobbering the display palette of some other KMS client. While at it, fix up the locking by grabbing all modeset locks for the duration of the fb_setcmap operation. v2: Make a note of the locking changes in the commit message Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@gmail.com>
|
#
3858bc5d |
|
03-Jun-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/fb-helper: Disable cursors and planes when restoring fbdev mode Cursors and plane can obscure whatever fbdev wants to show the user. Disable them all in drm_fb_helper_restore_fbdev_mode. After the cursors and planes have been disabled, user space needs to explicitly re-enable them to make them visible again. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@gmail.com>
|
#
89ced125 |
|
11-Apr-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Fix locking in drm_fb_helper_hotplug_event Driver's and ->fill_modes functions are allowed to grab crtc mutexes (for e.g. load detect). Hence we need to first only grab the general kms mutex, and only in a second step grab all locks to do the modesets. This prevents a deadlock on my gm45 in the tv load detect code called by drm_helper_probe_single_connector_modes. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
11e17a08 |
|
19-Feb-2013 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm: add initial_config function to fb helper Rather than building a config which may or may not work, let the driver build an initial fb config. This allows the driver to use the BIOS boot configuration for example, displaying kernel messages and the initial fb console on the same outputs the BIOS lit up at boot time. If that fails, the driver can still fall back the same way as the core. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: dri-devel@lists.freedesktop.org Acked-by: Dave Airlie <airlied@gmail.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
1b1d5397 |
|
24-Jan-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: don't sleep for screen unblank when an oopps is in progress Otherwise the system will burn even brighter and worse, leave the user wondering what's going on exactly. Since we already have a panic handler which will (try) to restore the entire fbdev console mode, we can just bail out. Inspired by a patch from Konstantin Khlebnikov. The callchain leading to this, cut&pasted from Konstantin's original patch: callstack: panic() bust_spinlocks(1) unblank_screen() vc->vc_sw->con_blank() fbcon_blank() fb_blank() info->fbops->fb_blank() drm_fb_helper_blank() drm_fb_helper_dpms() drm_modeset_lock_all() mutex_lock(&dev->mode_config.mutex) Note that the entire locking in the fb helper around panic/sysrq and kdbg is ... non-existant. So we have a decent change of blowing up everything. But since reworking this ties in with funny concepts like the fbdev notifier chain or the impressive things which happen around console_lock while oopsing, I'll leave that as an exercise for braver souls than me. v2: Drop the -EBUSY return value I've copied, we don't need it since the we'll take care of things ourselves anyway. Cc: Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Andrew Morton <akpm@linux-foundation.org> References: https://patchwork.kernel.org/patch/1878181/ Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
207fd329 |
|
20-Jan-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: improve kerneldoc Now that the fbdev helper interface for drivers is trimmed down, update the kerneldoc for all the remaining exported functions. I've tried to beat the DocBook a bit by reordering the function references a bit into a more sensible ordering. But that didn't work out at all. Hence just extend the in-code DOC: section a bit. Also remove the LOCKING: sections - especially for the setup functions they're totally bogus. But that's not a documentation problem, but simply an artifact of the current rather hazardous locking around drm init and even more so around fbdev setup ... v2: Some further improvements: - Also add documentation for drm_fb_helper_single_add_all_connectors, Dave Airlie didn't want me to kill this one from the fb helper interface. - Update docs for drm_fb_helper_fill_var/fix - they should be used from the driver's ->fb_probe callback to setup the fbdev info structure. - Clarify what the ->fb_probe callback should all do - it needs to setup both the fbdev info and allocate the drm framebuffer used as backing storage. - Add basic documentaation for the drm_fb_helper_funcs driver callback vfunc. v3: Implement clarifications Laurent Pinchart suggested in his review. v4: Fix another mispelling Laurent spotted. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8acf658a |
|
21-Jan-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: streamline drm_fb_helper_single_fb_probe No need to check whether we've allocated a new fb since we're not always doing that. Also, we always need to register the fbdev and add it to the panic notifier. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2180c3c7 |
|
21-Jan-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: directly call set_par from the hotplug handler The idea behind calling down into the driver's ->fb_probe function on each hotplug seems to be able to reallocate the backing storage (if e.g. a screen with higher resolution gets added). But that requires quite a bit of work in the fb helper itself, since currently we limit new screens to the currently allocated fb. An no kms driver supports fbdev fb resizing. So don't bother and start to simplify the code by calling drm_fb_helper_set_par directly from the fbdev hotplug function, since that's the only thing left in drm_fb_helper_single_fb_probe which does not concern itself with fb allocation and initial setup. Follow-on patches will streamline the initial setup code. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7e53f3a4 |
|
21-Jan-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: fixup set_config semantics While doing the modeset rework for drm/i915 I've noticed that the fb helper is very liberal with the semantics of the ->set_config interface: - It doesn't bother clearing stale modes (e.g. when unplugging a screen). - It unconditionally sets the fb, even if no mode will be set on a given crtc. - The initial setup is a bit fun since we need to pick crtcs to decide the desired fb size, but also should set the modeset->fb pointer. Explain what's going on in the fixup code after the fb is allocated. The crtc helper didn't really care, but the new i915 modeset infrastructure did, so I've had to add a bunch of special-cases to catch this. Fix this all up and enforce the interface by converting the checks in drm/i915/intel_display.c to BUG_ONs. v2: Fix commit message spell fail spotted by Rob Clark. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
76a39dbf |
|
20-Jan-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: don't disable everything in initial_config This should be done in the drivers for two reasons: - it gets in the way of fastboot efforts - it links the fb helpers with the crtc helpers instead of going through the real interface vfuncs, forcing i915 to fake all the ->disable callbacks used by the crtc helper to avoid ugly Oopsen v2: Resolve conflicts since drivers still call drm_fb_helper_single_add_all_connectors. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
de1ace5b |
|
20-Jan-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: unexport drm_fb_helper_single_fb_probe Not called by anyone, and really, shouldn't be. Drivers are supposed either drm_fb_helper_initial_config or drm_fb_helper_hotplug_event. Originally this was done differently, but is now consolidated in the helper functions and no longer done by drivers directly. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
43c8a849 |
|
20-Jan-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: unexport drm_fb_helper_panic It doesn't even show up in any header files and only used iternally. Originally it was (ab)used to restore the fbcon on lastclose, but that died with commit e8e7a2b8ccfdae0d4cb6bd25824bbedcd42da316 Author: Dave Airlie <airlied@redhat.com> Date: Thu Apr 21 22:18:32 2011 +0100 drm/i915: restore only the mode of this driver on lastclose (v2) Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d21bf469 |
|
20-Jan-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: kill drm_fb_helper_restore It's only used internally for the sysrq and panic handlers provided by the drm fb helper implementation. Hence just inline it, kill the export and remove the confusing kerneldoc. Driver's are supposed to call drm_fb_helper_restore_fbdev_mode on lastclose. Note that locking is totally fubar - the sysrq case doesn't take any locks at all. The panic handler probably shouldn't take any locks since it'll only make things worse. Otoh it's probably better to switch things over to the atomic modeset callbacks (and disable the panic handler for those drivers which don't implement it). But that's both better done in separate patches. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6aed8ec3 |
|
20-Jan-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm: review locking for drm_fb_helper_restore_fbdev_mode ... it's required. Fix up exynos and the cma helper, and add a corresponding WARN_ON to drm_fb_helper_restore_fbdev_mode. Note that tegra calls the fbdev cma helper restore function also from it's driver-load callback. Which is a bit against current practice, since usually the call is only from ->lastclose, and initial setup is done by drm_fb_helper_initial_config. Also add the relevant drm DocBook entry. v2: Add promised WARN to restore_fbdev_mode. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
20c60c35 |
|
16-Dec-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb_helper: check whether fbcon is bound We need to make sure that the fbcon is still bound when touching the hw, since otherwise we might corrupt the modeset state of kms clients. X mostly works around that with VT switching and setting the VT into raw mode, which disables most fbcon events. Raw kms test programs though don't do that dance, and in the future we might want to aim to abolish CONFIG_VT anyway. So improve preventive measures a bit. To do so, extract the existing logic for handling hotplug events (which X can't block with the current set of tricks) and reuse it for the fbdev blanking helper. Long-term we really need to either scrap this all and only have a OOPS console, or come up with a saner model for device ownership sharing between fbdev/fbcon and kms userspace. Reviewed-by: Rob Clark <rob@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
84849903 |
|
01-Dec-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm: add drm_modeset_lock|unlock_all This is the first step towards introducing the new modeset locking scheme. The plan is to put helper functions into place at all the right places step-by-step, so that the final patch to switch on the new locking scheme doesn't need to touch every single driver. This helper here will serve as the shotgun solutions for all places where a more fine-grained locking isn't (yet) implemented. v2: Fixup kerneldoc for unlock_all. Reviewed-by: Rob Clark <rob@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2d13b679 |
|
11-Dec-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm: encapsulate crtc->set_config calls With refcounting we need to adjust framebuffer refcounts at each callsite - much easier to do if they all call the same little helper function. Reviewed-by: Rob Clark <rob@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
58495563 |
|
11-Oct-2012 |
Rob Clark <rob@ti.com> |
drm: remove legacy drm_connector_property fxns Replace references to and remove the connector property fxns, which have been superseded with the more general object property fxns: + drm_connector_attach_property -> drm_object_attach_property + drm_connector_property_set_value -> drm_object_property_set_value + drm_connector_property_get_value -> drm_object_property_get_value Signed-off-by: Rob Clark <rob@ti.com>
|
#
d0ddc033 |
|
01-Nov-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/doc: integrate fb helper reference into docs Again only minimal changes to make kerneldoc no longer shout. Plus a little introduction in the form of a inline DOC: section to quickly explain what this is all about. v2: Fixup spelling fail. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
8c5eaca0 |
|
19-Nov-2012 |
Sachin Kamat <sachin.kamat@linaro.org> |
drm/fb_helper: Fix potential NULL pointer dereference kcalloc returns NULL on failure. Hence check for the return value and exit on error to avoid NULL pointer dereference. Fixes the following smatch errors: drivers/gpu/drm/drm_fb_helper.c:1271 drm_setup_crtcs() error: potential null dereference 'modes'. (kcalloc returns null) drivers/gpu/drm/drm_fb_helper.c:1272 drm_setup_crtcs() error: potential null dereference 'crtcs'. (kcalloc returns null) Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
96081cdf |
|
14-Nov-2012 |
Sachin Kamat <sachin.kamat@linaro.org> |
drm/drm_fb_helper: Remove unnecessary braces Remove unnecessary braces to silence the following type of checkpatch warnings: WARNING: braces {} are not necessary for single statement blocks WARNING: braces {} are not necessary for any arm of this statement Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
d56b1b9d |
|
14-Nov-2012 |
Sachin Kamat <sachin.kamat@linaro.org> |
drm/fb_helper: Convert printk to pr_* and dev_* Converted printks to pr_* and dev_* to silence checkpatch warnings. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
6c91083f |
|
14-Nov-2012 |
Sachin Kamat <sachin.kamat@linaro.org> |
drm/fb_helper: Fix checkpatch errors Fixes the following checkpatch errors: ERROR: trailing statements should be on next line 98: FILE: gpu/drm/drm_fb_helper.c:98: case DRM_FORCE_OFF: s = "OFF"; break; ERROR: trailing statements should be on next line 99: FILE: gpu/drm/drm_fb_helper.c:99: case DRM_FORCE_ON_DIGITAL: s = "ON - dig"; break; ERROR: trailing statements should be on next line 101: FILE: gpu/drm/drm_fb_helper.c:101: case DRM_FORCE_ON: s = "ON"; break; Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
760285e7 |
|
02-Oct-2012 |
David Howells <dhowells@redhat.com> |
UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/ Convert #include "..." to #include <path/...> in drivers/gpu/. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
|
#
e04190e0 |
|
07-Sep-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb helper: don't call drm_helper_connector_dpms directly Yet again a case where the fb helper is too intimate with the crtc helper and calls a crtc helepr function directly instead of going through the interface vtable. This fixes console blanking in drm/i915 with the new i915-specific modeset code. Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
78b9c353 |
|
01-Aug-2012 |
Sachin Kamat <sachin.kamat@linaro.org> |
drm: Add misssing static storage class specifier in drm_fb_helper.c file Fixes the following sparse warning: drivers/gpu/drm/drm_fb_helper.c:239:6: warning: symbol 'drm_fb_helper_force_kernel_mode' was not declared. Should it be static? Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
33faad19 |
|
12-Aug-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: don't clobber output routing in setup_crtcs Yet again the too close relationship between the fb helper and the crtc helper code strikes. This time around the fb helper resets all encoder->crtc pointers to NULL before starting to set up it's own mode. Which is total bullocks, because this will clobber the existing output routing, which the new drm/i915 code depends upon to be absolutely correct. The crtc helper itself doesn't really care about that, since it disables unused encoders in a rather roundabout way anyway. Two places call drm_setup_crts: - For the initial fb config. I've auditted all current drivers, and they all allocate their encoders with kzalloc. So there's no need to clear encoder->crtc once more. - When processing hotplug events while showing the fb console. This one is a bit more tricky, but both the crtc helper code and the new drm/i915 modeset code disable encoders if their crtc is changed and that encoder isn't part of the new config. Also, both disable any disconnected outputs, too. Which only leaves encoders that are on, connected, but for some odd reason the fb helper code doesn't want to use. That would be a bug in the fb configuration selector, since it tries to light up as many outputs as possible. v2: Kill the now unused encoders variable. Acked-by: Dave Airlie <airlied@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d3904754 |
|
11-Jul-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb helper: don't call drm_crtc_helper_set_config Go through the interface vtable instead, because not everyone might be using the crtc helper code. Cc: dri-devel@lists.freedesktop.org Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
343065a6 |
|
15-Jun-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: delay hotplug handling when partially bound Ok, this requires quite a dance to actually hit: 1) We plug in a 2nd screen, enable it in both X and (by vt-switching) in the fbcon. 2) We disable that screen again in with xrandr. 3) We vt-switch again, so that fbcon displays on the 2nd screen, but X on the first screen. This obviously needs a driver that doesn't switch off unused functions when regaining the VT. 3) When X controls the vt, we unplug that screen. Now drm_fb_helper_hotplug_event we noticed that that some crtcs are bound, but because we still have the fbcon on the 2nd screeen we also have bound set. Which means the fbcon wrongly assumes it's in control of everything an happily disables the output on the 2nd screen, but enables its fb on the first screen. Work around this issue by counting how many crtcs are bound and how many are bound to fbcon and assuming that when fbcon isn't bound to all of them, it better not touch the output configuration. Conceptually this is the same as only restoring the fbcon output configuration on the driver's ->lastclose, when we're sure that no one else is using kms. So this should be consistent with existing kms drivers. Chris has created a separate patch for the intel ddx, but I think we should fix this issue here regardless - the fbcon messing with the output config while it's not fully in control simply isn't a too polite behaviour. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50772 Tested-by: Maxim A. Nikulin <M.A.Nikulin@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
ebe0f244 |
|
17-May-2012 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm: Make the CRTC gamma_set operation optional Drivers for hardware without gamma support should not be forced to implement a no-op gamma set operation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Rob Clark <rob.clark@linaro.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
4a1b0714 |
|
17-May-2012 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm: Don't initialize local ret variable when not needed Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
f6e252ba |
|
13-Apr-2012 |
Adam Jackson <ajax@redhat.com> |
drm/edid: Allow drm_mode_find_dmt to hunt for reduced-blanking modes It won't find any, yet. Fix up callers to match: standard mode codes will look prefer r-b modes for a given size if present, EST3 mode codes will look for exactly the r-b-ness mentioned in the mode code. This might mean fewer modes matched for EST3 mode codes between now and when the DMT mode list regrows the r-b modes, but practically speaking EST3 codes don't exist in the wild. Signed-off-by: Adam Jackson <ajax@redhat.com> Tested-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
62fb376e |
|
26-Mar-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm: Validate requested virtual size against allocated fb size mplayer -vo fbdev tries to create a screen that is twice as tall as the allocated framebuffer for "doublebuffering". By default, and all in-tree users, only sufficient memory is allocated and mapped to satisfy the smallest framebuffer and the virtual size is no larger than the actual. For these users, we should therefore reject any userspace request to create a screen that requires a buffer larger than the framebuffer originally allocated. References: https://bugs.freedesktop.org/show_bug.cgi?id=38138 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
4f988d13 |
|
01-Feb-2012 |
Sascha Hauer <s.hauer@pengutronix.de> |
drm fb helper: remove unused variable crtc_id crtc_id is set but never used, so remove it from struct drm_fb_helper_crtc. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
e9ad3181 |
|
01-Feb-2012 |
Sascha Hauer <s.hauer@pengutronix.de> |
drm fb helper: remove unused variable conn_limit conn_limit is set but never used. Remove it from struct drm_fb_helper. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
3a8148c5 |
|
01-Feb-2012 |
Sascha Hauer <s.hauer@pengutronix.de> |
drm fb helper: use drm_helper_connector_dpms to do dpms drm_fb_helper_on|off currently manually searches for encoders to turn on/off. Make this simpler by using the helper function. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
a1b7736d |
|
01-Feb-2012 |
Sascha Hauer <s.hauer@pengutronix.de> |
drm drm_fb_helper: destroy modes drm_setup_crtcs allocated modes using drm_mode_duplicate. Free them in drm_fb_helper_crtc_free. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
d68752cf |
|
17-Oct-2011 |
Hugh Dickins <hughd@chromium.org> |
drm: avoid switching to text console if there is no panic timeout Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if we're going to reboot immediately, the user will not be able to see the messages anyway, and messing with the video mode may display artifacts, and certainly get into several layers of complexity (including mutexes and memory allocations) which we shall be much safer to avoid. Signed-off-by: Hugh Dickins <hughd@google.com> [ Edited commit message and modified to short-circuit panic_timeout < 0 instead of testing panic_timeout >= 0. -Mandeep ] Signed-off-by: Mandeep Singh Baines <msb@chromium.org> Acked-by: David Rientjes <rientjes@google.com> Acked-by: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
e0cd3608 |
|
30-Aug-2011 |
Paul Gortmaker <paul.gortmaker@windriver.com> |
gpu: add module.h to drivers/gpu files as required. So that we don't get build failures once the implicit module.h presence is removed. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
#
55a01f6f |
|
07-Sep-2011 |
Lin Ming <ming.m.lin@intel.com> |
drm: Remove duplicate "return" statement Remove the duplicate "return" statement in drm_fb_helper_panic(). Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
752d2635 |
|
22-Apr-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm: Take lock around probes for drm_fb_helper_hotplug_event We need to hold the dev->mode_config.mutex whilst detecting the output status. But we also need to drop it for the call into drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when attaching the fbcon. Failure to do so exposes a race with normal output probing. Detected by adding some warnings that the mutex is held to the backend detect routines: [ 17.772456] WARNING: at drivers/gpu/drm/i915/intel_crt.c:471 intel_crt_detect+0x3e/0x373 [i915]() [ 17.772458] Hardware name: Latitude E6400 [ 17.772460] Modules linked in: .... [ 17.772582] Pid: 11, comm: kworker/0:1 Tainted: G W 2.6.38.4-custom.2 #8 [ 17.772584] Call Trace: [ 17.772591] [<ffffffff81046af5>] ? warn_slowpath_common+0x78/0x8c [ 17.772603] [<ffffffffa03f3e5c>] ? intel_crt_detect+0x3e/0x373 [i915] [ 17.772612] [<ffffffffa0355d49>] ? drm_helper_probe_single_connector_modes+0xbf/0x2af [drm_kms_helper] [ 17.772619] [<ffffffffa03534d5>] ? drm_fb_helper_probe_connector_modes+0x39/0x4d [drm_kms_helper] [ 17.772625] [<ffffffffa0354760>] ? drm_fb_helper_hotplug_event+0xa5/0xc3 [drm_kms_helper] [ 17.772633] [<ffffffffa035577f>] ? output_poll_execute+0x146/0x17c [drm_kms_helper] [ 17.772638] [<ffffffff81193c01>] ? cfq_init_queue+0x247/0x345 [ 17.772644] [<ffffffffa0355639>] ? output_poll_execute+0x0/0x17c [drm_kms_helper] [ 17.772648] [<ffffffff8105b540>] ? process_one_work+0x193/0x28e [ 17.772652] [<ffffffff8105c6bc>] ? worker_thread+0xef/0x172 [ 17.772655] [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172 [ 17.772658] [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172 [ 17.772663] [<ffffffff8105f767>] ? kthread+0x7a/0x82 [ 17.772668] [<ffffffff8100a724>] ? kernel_thread_helper+0x4/0x10 [ 17.772671] [<ffffffff8105f6ed>] ? kthread+0x0/0x82 [ 17.772674] [<ffffffff8100a720>] ? kernel_thread_helper+0x0/0x10 Reported-by: Frederik Himpe <fhimpe@telenet.be> References: https://bugs.freedesktop.org/show_bug.cgi?id=36394 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
1794d257 |
|
17-Apr-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm: Export the command-line mode parser In the absence of configuration data for providing the fixed mode for a panel, I would like to be able to pass such modes along a separate module paramenter. To do so, I then need to parse a modeline from a string, which drm is already capable of. Export that capability to the drivers. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
7394371d |
|
22-Apr-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm: Take lock around probes for drm_fb_helper_hotplug_event We need to hold the dev->mode_config.mutex whilst detecting the output status. But we also need to drop it for the call into drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when attaching the fbcon. Failure to do so exposes a race with normal output probing. Detected by adding some warnings that the mutex is held to the backend detect routines: [ 17.772456] WARNING: at drivers/gpu/drm/i915/intel_crt.c:471 intel_crt_detect+0x3e/0x373 [i915]() [ 17.772458] Hardware name: Latitude E6400 [ 17.772460] Modules linked in: .... [ 17.772582] Pid: 11, comm: kworker/0:1 Tainted: G W 2.6.38.4-custom.2 #8 [ 17.772584] Call Trace: [ 17.772591] [<ffffffff81046af5>] ? warn_slowpath_common+0x78/0x8c [ 17.772603] [<ffffffffa03f3e5c>] ? intel_crt_detect+0x3e/0x373 [i915] [ 17.772612] [<ffffffffa0355d49>] ? drm_helper_probe_single_connector_modes+0xbf/0x2af [drm_kms_helper] [ 17.772619] [<ffffffffa03534d5>] ? drm_fb_helper_probe_connector_modes+0x39/0x4d [drm_kms_helper] [ 17.772625] [<ffffffffa0354760>] ? drm_fb_helper_hotplug_event+0xa5/0xc3 [drm_kms_helper] [ 17.772633] [<ffffffffa035577f>] ? output_poll_execute+0x146/0x17c [drm_kms_helper] [ 17.772638] [<ffffffff81193c01>] ? cfq_init_queue+0x247/0x345 [ 17.772644] [<ffffffffa0355639>] ? output_poll_execute+0x0/0x17c [drm_kms_helper] [ 17.772648] [<ffffffff8105b540>] ? process_one_work+0x193/0x28e [ 17.772652] [<ffffffff8105c6bc>] ? worker_thread+0xef/0x172 [ 17.772655] [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172 [ 17.772658] [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172 [ 17.772663] [<ffffffff8105f767>] ? kthread+0x7a/0x82 [ 17.772668] [<ffffffff8100a724>] ? kernel_thread_helper+0x4/0x10 [ 17.772671] [<ffffffff8105f6ed>] ? kthread+0x0/0x82 [ 17.772674] [<ffffffff8100a720>] ? kernel_thread_helper+0x0/0x10 Reported-by: Frederik Himpe <fhimpe@telenet.be> References: https://bugs.freedesktop.org/show_bug.cgi?id=36394 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
e8e7a2b8 |
|
21-Apr-2011 |
Dave Airlie <airlied@redhat.com> |
drm/i915: restore only the mode of this driver on lastclose (v2) i915 calls the panic handler function on last close to reset the modes, however this is a really bad idea for multi-gpu machines, esp shareable gpus machines. So add a new entry point for the driver to just restore its own fbcon mode. v2: move code into fb helper, fix panic code to block mode change on powered off GPUs. [airlied: this hits drm core and I wrote it and it was reviewed on intel-gfx so really I signed it off twice ;-).] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
062ac622 |
|
07-Mar-2011 |
roel <roel.kluin@gmail.com> |
drm: index i shadowed in 2nd loop Index i was already used in thhe first loop Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
9da12b6a |
|
15-Feb-2011 |
Rob Clark <rob@ti.com> |
drm: psuedocolor support for ARGB modes If there is an alpha channel, need to mask in 1's in the alpha channel to prevent the fb from being completely transparent. Signed-off-by: Rob Clark <rob@ti.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
6a108a14 |
|
20-Jan-2011 |
David Rientjes <rientjes@google.com> |
kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option is used to configure any non-standard kernel with a much larger scope than only small devices. This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes references to the option throughout the kernel. A new CONFIG_EMBEDDED option is added that automatically selects CONFIG_EXPERT when enabled and can be used in the future to isolate options that should only be considered for embedded systems (RISC architectures, SLOB, etc). Calling the option "EXPERT" more accurately represents its intention: only expert users who understand the impact of the configuration changes they are making should enable it. Reviewed-by: Ingo Molnar <mingo@elte.hu> Acked-by: David Woodhouse <david.woodhouse@intel.com> Signed-off-by: David Rientjes <rientjes@google.com> Cc: Greg KH <gregkh@suse.de> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jens Axboe <axboe@kernel.dk> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Robin Holt <holt@sgi.com> Cc: <linux-arch@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
3632ef89 |
|
14-Jan-2011 |
Dave Airlie <airlied@redhat.com> |
Revert "drm: Update fbdev fb_fix_screeninfo" This reverts commit dfe63bb0ad9810db13aab0058caba97866e0a681. This commit was causing nouveau not to work properly, for -rc1 I'd prefer it worked and we can look if this is useful for 2.6.39. Cc: James Simmons <jsimmons@infradead.org> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
dfe63bb0 |
|
23-Dec-2010 |
James Simmons <jsimmons@infradead.org> |
drm: Update fbdev fb_fix_screeninfo If you change the color depth via fbset or some other framebuffer aware userland application struct fb_fix_screeninfo is not updated to this new information. This patch fixes this issue. Also the function is changed to just pass in struct drm_framebuffer so in the future we could use more fields. I'm hoping some day fix->smem* could be set here :-) Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
3ce05168 |
|
11-Dec-2010 |
David Fries <david@fries.net> |
drm/kms: load fbcon from drm_kms_helper Kconfig says fbcon is required by drm_kms_helper. If radeon, fbcon, and drm_kms_helper are all modules, radeon is auto loaded (by PCI id?), drm_kms_helper is loaded because of the module dependency, but fbcon isn't loaded leaving the console unusable. Since fbcon is required and there isn't an explicit module dependency, request the module to be loaded from drm_kms_helper. Signed-off-by: David Fries <david@fries.net> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
57084d05 |
|
20-Dec-2010 |
James Simmons <jsimmons@infradead.org> |
drm/fb: Don't expose mmio for fbdev emulation layer For the fbdev api if the struct fb_var_screeninfo accel_flags field is set to FB_ACCELF_TEXT then userland applications can not mmap the mmio region. Since it is a bad idea for DRM drivers to expose the mmio region via the fbdev layer we always set the accel_flags to prevent this. Please apply. Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
21c74a8e |
|
13-Oct-2010 |
Jason Wessel <jason.wessel@windriver.com> |
drm, kdb, kms: Change mode_set_base_atomic() enter argument to be an enum The enter argument as implemented by commit 413d45d3627 (drm, kdb, kms: Add an enter argument to mode_set_base_atomic() API) should be more descriptive as to what it does vs just passing 1 and 0 around. There is no runtime behavior change as a result of this patch. Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Jason Wessel <jason.wessel@windriver.com> CC: David Airlie <airlied@linux.ie> CC: dri-devel@lists.freedesktop.org Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
99231028 |
|
13-Oct-2010 |
Jason Wessel <jason.wessel@windriver.com> |
kdb, kms: Save and restore the LUT on atomic KMS enter/exit When changing VTs non-atomically the kernel works in conjunction with the Xserver in user space and receives the LUT information from the Xserver via a system call. When changing modes atomically for kdb, this information must be saved and restored without disturbing user space as if nothing ever happened. There is a short cut used by this patch where gamma_store is used as the save space. If this turns out to be a problem in the future a pre-allocated chunk of memory will be required for each crtc to save and restore the LUT information. Signed-off-by: Jason Wessel <jason.wessel@windriver.com> CC: Jesse Barnes <jbarnes@virtuousgeek.org> CC: David Airlie <airlied@linux.ie> CC: dri-devel@lists.freedesktop.org Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
413d45d3 |
|
26-Sep-2010 |
Jason Wessel <jason.wessel@windriver.com> |
drm, kdb, kms: Add an enter argument to mode_set_base_atomic() API Some devices such as the radeon chips receive information from user space which needs to be saved when executing an atomic mode set operation, else the user space would have to be queried again for the information. This patch extends the mode_set_base_atomic() call to pass an argument to indicate if this is an entry or an exit from an atomic kernel mode set change. Individual drm drivers can properly save and restore state accordingly. Signed-off-by: Jason Wessel <jason.wessel@windriver.com> CC: Jesse Barnes <jbarnes@virtuousgeek.org> CC: David Airlie <airlied@linux.ie> CC: dri-devel@lists.freedesktop.org Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
1495cc9d |
|
17-Aug-2010 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
Input: sysrq - drop tty argument from sysrq ops handlers Noone is using tty argument so let's get rid of it. Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Acked-by: Jason Wessel <jason.wessel@windriver.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
|
#
09f0c489 |
|
19-Aug-2010 |
Dan Carpenter <error27@gmail.com> |
drm: move dereference below check "fb_helper_conn" is dereferenced before the check for NULL. It's never actually NULL here, so this is mostly to keep the static checkers happy. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
f90ebd9e |
|
05-Aug-2010 |
Jason Wessel <jason.wessel@windriver.com> |
drm_fb_helper: Preserve capability to use atomic kms Commit 5349ef3127c77075ff70b2014f17ae0fbcaaf199 (drm/fb: fix FBIOGET/PUT_VSCREENINFO pixel clock handling) changed the logic of when a pixclock was valid vs invalid. The atomic kernel mode setting used by the kernel debugger relies upon the drm_fb_helper_check_var() to always return -EINVAL. Until a better solution exists, this behavior will be restored. CC: David Airlie <airlied@linux.ie> CC: Jesse Barnes <jbarnes@virtuousgeek.org> CC: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
|
#
1a7aba7f |
|
05-Aug-2010 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm: add KGDB/KDB support Implement the callbacks for KDB entry/exit via the drm helpers. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
|
#
023eb571 |
|
02-Jul-2010 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm: correctly update connector DPMS status in drm_fb_helper We don't currently update the DPMS status of the connector (both in the connector itself and the connector's DPMS property) in the fb helper code. This means that if the kernel FB core has blanked the screen, sysfs will still show a DPMS status of "on". It also means that when X starts, it will try to light up the connectors, but the drm_crtc_helper code will ignore the DPMS change since according to the connector, the DPMS status is already on. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=28436 (the annoying "my screen was blanked when I started X and now it won't light up" bug). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
b829e011 |
|
10-Jun-2010 |
Adam Jackson <ajax@redhat.com> |
drm/fb: Fix video= mode computation Reduced blanking is valid only when doing CVT modes. Also, generate GTF modes unless CVT was requested; CVT devices are required to support GTF, but the reverse is not true. [airlied: fix typo] Signed-off-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
fc2362af |
|
06-Jun-2010 |
Dave Airlie <airlied@redhat.com> |
drm/fb: use printk to print out the switching to text mode error. using DRM_ERROR, results in people blaming the drm code for the oops, and not looking at the oops. (sadly yes I've gotten reports). Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
1d42bbc8 |
|
06-May-2010 |
Dave Airlie <airlied@redhat.com> |
drm/fbdev: fix cloning on fbcon Simple cloning rules compared to server: (a) single crtc (b) > 1 connector active (c) check command line mode (d) try and find 1024x768 DMT mode if no command line. (e) fail to clone Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
eb1f8e4f |
|
07-May-2010 |
Dave Airlie <airlied@redhat.com> |
drm/fbdev: rework output polling to be back in the core. (v4) After thinking it over a lot it made more sense for the core to deal with the output polling especially so it can notify X. v2: drop plans for fake connector - per Michel's comments - fix X patch sent to xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd settings. v3: add config lock take inside polling, add intel/nouveau poll init/fini calls v4: config lock was a bit agressive, only needed around connector list reading. otherwise it could re-enter. glisse: discard drm_helper_hpd_irq_event v3: Reviewed-by: Michel Dänzer <michel@daenzer.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
3da1f33e |
|
14-May-2010 |
Kirill Smelkov <kirr@landau.phys.spbu.ru> |
drm: Prefix info printk about registering panic notifier with 'drm' Recently I've studied my system dmesg and seen this: <lots of stuff before> 1 [ 0.478416] ACPI: Battery Slot [C1B4] (battery present) 2 [ 0.478648] ACPI: Battery Slot [C1B3] (battery absent) 3 [ 0.906678] [drm] initialized overlay support 4 [ 1.762304] Console: switching to colour frame buffer device 128x48 5 [ 1.765211] fb0: inteldrmfb frame buffer device 6 [ 1.765242] registered panic notifier 7 [ 1.765272] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 8 [ 1.765372] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled <lots of stuff after> and it was not evident who registered that panic notifier on line 6. I'd bought it as some low-level stuff needed by kernel itself, but the time was inappropriate -- too late for such things. So I had to study sources to see it was drm who was registering switch-to-fb on panic. Let's avoid possible confusion and mark this message as going from drm subsystem. (I'm a bit unsure whether to use '[drm]:' or 'drm:' -- the rest of the kernel just uses 'topic:', and even in drm_fb_helper.c we use 'fb%d:' without [] brackets. Either way is ok with me.) Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
b1f20198 |
|
07-Apr-2010 |
James Simmons <jsimmons@infradead.org> |
drm/fb: remove drm_fb_helper_setcolreg This patch is against the drm-fbdevfix1 branch. It removes the drm_fb_helper_setcolreg function. The reason is that fb_setcolreg is only used in the case where fb_setcmap is called and no fb_ops->fb_setcmap is used. In the drm case we always need a fb_setcmap hook to handle multiple crtcs so we don't need a fb_setcolreg hook. Please apply. Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
4abe3520 |
|
29-Mar-2010 |
Dave Airlie <airlied@redhat.com> |
drm/kms/fb: use slow work mechanism for normal hotplug also. a) slow work is always used now for any fbcon hotplug, as its not a fast task and is more suited to being ran under slow work. b) attempt to not do any fbdev changes when X is running as we'll just mess it up. This hooks set_par to hopefully do the changes once X hands control to fbdev. This also adds the nouveau/intel hotplug support. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
5c4426a7 |
|
29-Mar-2010 |
Dave Airlie <airlied@redhat.com> |
drm/kms/fb: add polling support for when nothing is connected. When we are running in a headless environment we have no idea what output the user might plug in later, we only have hotplug detect from the digital outputs. So if we detect no connected outputs at initialisation, start a slow work operation to poll every 5 seconds for an output. this is only hooked up for radeon so far, on hw where we have full hotplug detection there is no need for this. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
19b4b445 |
|
29-Mar-2010 |
Dave Airlie <airlied@redhat.com> |
drm/kms/fb: provide a 1024x768 fbcon if no outputs found. If we get no outputs setup provide a 1024x768 fbcon, with this + radeon hotplug stuff I can plug a monitor in after startup and get to see stuff. Last thing is to add some sort of timer for non-hpd outputs like VGA etc. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
0b4c0f3f |
|
29-Mar-2010 |
Dave Airlie <airlied@redhat.com> |
drm/kms/fb: separate fbdev connector list from core drm connectors This breaks the connection between the core drm connector list and the fbdev connector usage, and allows them to become disjoint in the future. It also removes the untype void* that was in the connector struct to support this. All connectors are added to the fbdev now but this could be changed in the future. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
8be48d92 |
|
29-Mar-2010 |
Dave Airlie <airlied@redhat.com> |
drm/kms/fb: move to using fb helper crtc grouping instead of core crtc list This move to using the list of crtcs in the fb helper and cleans up the whole picking code, now we store the crtc/connectors we want directly into the modeset and we use the modeset directly to set the mode. Fixes from James Simmons and Ben Skeggs. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
38651674 |
|
29-Mar-2010 |
Dave Airlie <airlied@redhat.com> |
drm/fb: fix fbdev object model + cleanup properly. The fbdev layer in the kms code should act like a consumer of the kms services and avoid having relying on information being store in the kms core structures in order for it to work. This patch a) removes the info pointer/psuedo palette from the core drm_framebuffer structure and moves it to the fbdev helper layer, it also removes the core drm keeping a list of kernel kms fbdevs. b) migrated all the fb helper functions out of the crtc helper file into the fb helper file. c) pushed the fb probing/hotplug control into the driver d) makes the surface sizes into a structure for ease of passing This changes the intel/radeon/nouveau drivers to use the new helper. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
b8c40d62 |
|
25-Mar-2010 |
Randy Dunlap <randy.dunlap@oracle.com> |
drm: fix build error when SYSRQ is disabled Fix build error when CONFIG_MAGIC_SYSRQ is not enabled: drivers/gpu/drm/drm_fb_helper.c:915: error: 'sysrq_drm_fb_helper_restore_op' undeclared (first use in this function) drivers/gpu/drm/drm_fb_helper.c:929: error: 'sysrq_drm_fb_helper_restore_op' undeclared (first use in this function) Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
5a0e3ad6 |
|
24-Mar-2010 |
Tejun Heo <tj@kernel.org> |
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
|
#
172e91f5 |
|
10-Feb-2010 |
Pavel Roskin <proski@gnu.org> |
drm/kms: fix spelling of "CLOCK" Signed-off-by: Pavel Roskin <proski@gnu.org> [clemens@ladisch.de: merged into drm_fb_helper] Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
3b40a443 |
|
02-Feb-2010 |
Andy Shevchenko <ext-andriy.shevchenko@nokia.com> |
drivers/gpu/drm/drm_fb_helper.c: don't use private implementation of atoi() Kernel has simple_strtol() which would be used as atoi(). This is quite the same fix as in 2cb96f86628d6e97fcbda5fe4d8d74876239834c ("fbdev: drop custom atoi from drivers/video/modedb.c") because code in drivers/gpu/drm/drm_fb_helper.c is based on drivers/video/modedb.c. Signed-off-by: Andy Shevchenko <ext-andriy.shevchenko@nokia.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
b5218a87 |
|
19-Jan-2010 |
Pavel Roskin <proski@gnu.org> |
drm/kms: fix spelling in error message Signed-off-by: Pavel Roskin <proski@gnu.org> [clemens@ladisch.de: merged into drm_fb_helper] Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
5fd4df4d |
|
18-Jan-2010 |
Zhenyu Wang <zhenyuw@linux.intel.com> |
drm: fix regression in fb blank handling commit 731b5a15a3b1474a41c2ca29b4c32b0f21bc852e Author: James Simmons <jsimmons@infradead.org> Date: Thu Oct 29 20:39:07 2009 +0000 drm/kms: properly handle fbdev blanking uses DRM_MODE_DPMS_ON for FB_BLANK_NORMAL, but DRM_MODE_DPMS_ON is actually for turning output on instead of blank. This makes fb blank broken on my T61, it put LVDS on but leave pipe disabled which made screen totally white or caused some 'burning' effect. [airlied: James objects to this but at this point in 2.6.33, I can't see a patch that will fix this properly like he wants coming in time and otherwise this is a regression - proper fix for 2.6.34 hopefully.] Cc: James Simmons <jsimmons@infradead.org> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
509c7d83 |
|
07-Jan-2010 |
Dave Airlie <airlied@redhat.com> |
drm/kms/fb: check for depth changes from userspace for resizing. If userspace (plymouth in this case) asks for a deeper depth, refuse it as well due to lack of resizing. This fixes an issue since < 32MB cards went to 8bpp and plymouth crashes on startup. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
7751b8cb |
|
07-Jan-2010 |
Dave Airlie <airlied@redhat.com> |
drm/kms/fb: check for depth changes from userspace for resizing. If userspace (plymouth in this case) asks for a deeper depth, refuse it as well due to lack of resizing. This fixes an issue since < 32MB cards went to 8bpp and plymouth crashes on startup. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
e89a8c90 |
|
31-Dec-2009 |
Roel Kluin <roel.kluin@gmail.com> |
drm/kms: Fix &&/|| confusion in drm_fb_helper_connector_parse_command_line() This always evaluates to true. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
b0a007dc |
|
07-Dec-2009 |
Ben Skeggs <bskeggs@redhat.com> |
drm/kms: fix fb cmap allocation to use modeset->crtc not crtc crtc may be undefined at this point. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
5349ef31 |
|
04-Nov-2009 |
Clemens Ladisch <clemens@ladisch.de> |
drm/fb: fix FBIOGET/PUT_VSCREENINFO pixel clock handling When the framebuffer driver does not publish detailed timing information for the current video mode, the correct value for the pixclock field is zero, not -1. Since pixclock is actually unsigned, the value -1 would be interpreted as 4294967295 picoseconds (i.e., about 4 milliseconds) by register_framebuffer() and userspace programs. This patch allows X.org's fbdev driver to work. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Tested-by: Paulius Zaleckas <paulius.zaleckas@gmail.com> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
3bea21b6 |
|
04-Nov-2009 |
Clemens Ladisch <clemens@ladisch.de> |
drm/kms: allocate framebuffer cmap Without an allocated colormap, FBIOGETCMAP fails. This would make programs restore an all-black colormap ("links -g") or fail to work altogether ("mplayer -vo fbdev2"). Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
cda6be1c |
|
04-Nov-2009 |
Clemens Ladisch <clemens@ladisch.de> |
drm/fb: fix FBIOGET/PUT_VSCREENINFO pixel clock handling When the framebuffer driver does not publish detailed timing information for the current video mode, the correct value for the pixclock field is zero, not -1. Since pixclock is actually unsigned, the value -1 would be interpreted as 4294967295 picoseconds (i.e., about 4 milliseconds) by register_framebuffer() and userspace programs. This patch allows X.org's fbdev driver to work. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
731b5a15 |
|
29-Oct-2009 |
James Simmons <jsimmons@infradead.org> |
drm/kms: properly handle fbdev blanking I examined several fbdev drivers and foudn the blanking code in drm_fb_helper to be wrong. This patch fixes the fbdev blanking to behave like other fbdev drivers. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
a2d49ae7 |
|
27-Oct-2009 |
James Simmons <jsimmons@infradead.org> |
drm/kms: typo fix I believe this is a typo. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
77de0846 |
|
23-Oct-2009 |
Dave Airlie <airlied@redhat.com> |
drm/kms: fix kms/fbdev colormap support properly. This sets the fbcon to use TRUECOLOR by default, it then only modifies the pseudo palette for fbcon, and only touches the real palette when in 8-bit pseudo color mode. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
c850cb78 |
|
23-Oct-2009 |
Dave Airlie <airlied@redhat.com> |
drm/kms: fix kms/fbdev colormap support properly. This sets the fbcon to use TRUECOLOR by default, it then only modifies the pseudo palette for fbcon, and only touches the real palette when in 8-bit pseudo color mode. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
b8c00ac5 |
|
05-Oct-2009 |
Dave Airlie <airlied@redhat.com> |
drm/fb: add more correct 8/16/24/32 bpp fb support. The previous patches had some unwanted side effects, I've fixed the lack of 32bpp working, and fixed up 16bpp so it should also work. this also adds the interface to allow the driver to set a preferred console depth so for example low memory rn50 can set it to 8bpp. It also catches 24bpp on cards that can't do it and forces 32bpp. Tested on r100/r600/i945. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
068143d3 |
|
04-Oct-2009 |
Dave Airlie <airlied@redhat.com> |
drm/fb: add setcmap and fix 8-bit support. This adds support for the setcmap api and fixes the 8bpp support at least on radeon hardware. It adds a new load_lut hook which can be called once the color map is setup. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
bea1d35b |
|
28-Sep-2009 |
Mikael Pettersson <mikpe@it.uu.se> |
drm: fix drm_fb_helper warning when !CONFIG_MAGIC_SYSRQ Compiling DRM throws the following warning if MAGIC_SYSRQ is disabled: drivers/gpu/drm/drm_fb_helper.c:101: warning: 'sysrq_drm_fb_helper_restore_op' defined but not used Fix: place sysrq_drm_fb_helper_restore_op and associated definitions inside #ifdef CONFIG_MAGIC_SYSRQ. Signed-off-by: Mikael Pettersson <mikpe@it.uu.se> Signed-off-by: Dave Airlie <airlied@linux.ie>
|
#
74bf2ad5 |
|
27-Sep-2009 |
Dave Airlie <airlied@linux.ie> |
drm/kms: make fb helper work for all drivers. This initialises the fb helper with the connector helper, so that the fb cmdline code works for intel as well. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
8ef8678c |
|
25-Sep-2009 |
Dave Airlie <airlied@linux.ie> |
drm/kms: protect against fb helper not being created. If drivers don't init the fb helper on the connector, the cmdline code won't work, but it shouldn't crash either. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
d50ba256 |
|
22-Sep-2009 |
Dave Airlie <airlied@linux.ie> |
drm/kms: start adding command line interface using fb. [note this requires an fb patch posted to linux-fbdev-devel already] This uses the normal video= command line option to control the kms output setup at boot time. It is used to override the autodetection done by kms. video= normally takes a framebuffer as the first parameter, in kms it will take a connector name, DVI-I-1, or LVDS-1 etc. If no output connector is specified the mode string will apply to all connectors. The mode specification used will match down the probed modes, and if no mode is found it will add a CVT mode that matches. video=1024x768 - all connectors match a 1024x768 mode or add a CVT on video=VGA-1:1024x768, VGA-1 connector gets mode only. The same strings as used in current fb modedb.c are used, except I've added three more letters, e, D, d, e = enable, D = enable Digital, d = disable, which allow a connector to be forced into a certain state. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
e87b2c42 |
|
17-Sep-2009 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm: fix drm_fb_helper handling of kernel crtcs The drm_fb_helper shouldn't mess with CRTCs that aren't enabled or in its initial config. Ideally it shouldn't even include CRTCs in its initial config if they're not in use, but my old fix for that no longer works. At any rate, this fixes a real bug I was seeing where after a console blank, both pipes would come back on, even though only one had been enabled before that. Since the other pipe had a bogus config, this led to some screen corruption. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
6fcefd56 |
|
07-Sep-2009 |
Dave Airlie <airlied@redhat.com> |
drm/kms: fix kms helper license + Kconfig Allow the KMS module to work properly, and also rename it to KMS_HELPER so its clearer what its for. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
3420e742 |
|
30-Aug-2009 |
Dave Airlie <airlied@redhat.com> |
drm: fix two issues with fb consolidation. Set accel to none, we really don't want anyone thinking fb is an accel interface. Pass pitch not depth to function for intel. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
785b93ef |
|
27-Aug-2009 |
Dave Airlie <airlied@redhat.com> |
drm/kms: move driver specific fb common code to helper functions (v2) Initially I always meant this code to be shared, but things ran away from me before I got to it. This refactors the i915 and radeon kms fbdev interaction layers out into generic helpers + driver specific pieces. It moves all the panic/sysrq enhancements to the core file, and stores a linked list of kernel fbs. This could possibly be improved to only store the fb which has fbcon on it for panics etc. radeon retains some specific codes used for a big endian workaround. changes: fix oops in v1 fix freeing path for crtc_info Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
|