kernel/drivers/gpu/drm/cirrus/cirrus_fbdev.c, branch linux-4.1.y

drm/fb-helper: Propagate errors from initial config failure

2015-01-21T13:57:03Z

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 Cc: David Airlie Cc: Daniel Vetter Cc: Patrik Jakobsson Cc: Rob Clark Cc: Tomi Valkeinen Cc: Alex Deucher Cc: Christian König Cc: Ben Skeggs Signed-off-by: Thierry Reding Reviewed-by: Alex Deucher Reviewed-by: Patrik Jakobsson Reviewed-by: Christian König [danvet: Squash in simplification patch from kbuild.] Signed-off-by: Daniel Vetter

drm/cirrus: allow 32bpp framebuffers for cirrus drm

2014-11-20T01:42:46Z

This patch allows framebuffers for cirrus to be created with 32bpp pixel formats provided that they do not violate certain restrictions of the cirrus hardware. v2: Use pci resource length for vram size. Signed-off-by: Zach Reizner Signed-off-by: Dave Airlie

drm/cirrus: use container_of to resolve cirrus_fbdev from drm_fb_helper

2014-09-24T10:09:24Z

Use container_of instead of casting first structure member. Signed-off-by: Fabian Frederick Signed-off-by: Daniel Vetter

drm: Introduce drm_fb_helper_prepare()

2014-07-08T01:31:28Z

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 Signed-off-by: Thierry Reding Signed-off-by: Dave Airlie

drm: Constify struct drm_fb_helper_funcs

2014-07-08T01:31:15Z

There's no need for this to be modifiable. Make it const so that it can be put into the .rodata section. Reviewed-by: Daniel Vetter Signed-off-by: Thierry Reding Acked-by: Russell King Signed-off-by: Dave Airlie

drm/mgag200,ast,cirrus: fix regression with drm_can_sleep conversion

2014-02-06T01:39:03Z

I totally sign inverted my way out of this one. Cc: stable@vger.kernel.org Reported-by: "Sabrina Dubroca" Signed-off-by: Dave Airlie

drm: ast,cirrus,mgag200: use drm_can_sleep

2014-01-29T00:51:52Z

these 3 were checking in_interrupt but we have situations where calling vunmap under this could cause a BUG to be hit in smp_call_function_many. Use the drm_can_sleep macro instead, which should stop this path from been taken in this case. Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie

drm/cirrus: Fix cirrus drm driver for fbdev + qemu

2014-01-13T04:15:04Z

Xorg fbdev driver requires smem_start/smem_len, otherwise it tries to map 0 bytes as video memory. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=856760 Signed-off-by: Martin Koegler Signed-off-by: Takashi Iwai Signed-off-by: Dave Airlie

drm/cirrus: do not attempt to acquire a reservation while in an interrupt handler

2013-06-28T01:56:30Z

Mutexes should not be acquired in interrupt context. While the trylock fastpath is arguably safe on all implementations, the slowpath unlock path definitely isn't. This fixes the following lockdep splat: [ 13.044313] ------------[ cut here ]------------ [ 13.044367] WARNING: at /c/kernel-tests/src/tip/kernel/mutex.c:858 mutex_trylock+0x87/0x220() [ 13.044378] DEBUG_LOCKS_WARN_ON(in_interrupt()) [ 13.044378] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-rc4-00296-ga2963dd #20 [ 13.044379] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 [ 13.044390] 0000000000000009 ffff88000de039f8 ffffffff81fc86d5 ffff88000de03a38 [ 13.044395] ffffffff810d511b ffff880000000018 ffff88000f33c690 0000000000000001 [ 13.044398] 00000000000003f0 ffff88000f4677c8 0000000000000000 ffff88000de03a98 [ 13.044400] Call Trace: [ 13.044412] [] dump_stack+0x19/0x1b [ 13.044441] [] warn_slowpath_common+0x6b/0x90 [ 13.044445] [] warn_slowpath_fmt+0x46/0x50 [ 13.044448] [] mutex_trylock+0x87/0x220 [ 13.044482] [] cirrus_dirty_update+0x1cd/0x330 [ 13.044486] [] cirrus_imageblit+0x38/0x50 [ 13.044506] [] soft_cursor+0x22e/0x240 [ 13.044510] [] bit_cursor+0x581/0x5b0 [ 13.044525] [] ? vsnprintf+0x124/0x670 [ 13.044529] [] ? get_color.isra.16+0x43/0x130 [ 13.044532] [] fbcon_cursor+0x18a/0x1d0 [ 13.044535] [] ? update_attr.isra.2+0xa0/0xa0 [ 13.044556] [] hide_cursor+0x32/0xa0 [ 13.044565] [] vt_console_print+0x103/0x3b0 [ 13.044569] [] ? print_time+0x9c/0xb0 [ 13.044576] [] ? print_prefix+0xa0/0xc0 [ 13.044580] [] call_console_drivers.constprop.6+0x146/0x1f0 [ 13.044593] [] ? do_raw_spin_unlock+0xc8/0x100 [ 13.044597] [] console_unlock+0x2f7/0x460 [ 13.044600] [] vprintk_emit+0x59a/0x5e0 [ 13.044615] [] printk+0x4d/0x4f [ 13.044650] [] print_local_APIC+0x28/0x41c [ 13.044672] [] generic_smp_call_function_single_interrupt+0x145/0x2b0 [ 13.044688] [] smp_call_function_single_interrupt+0x27/0x40 [ 13.044697] [] call_function_single_interrupt+0x72/0x80 [ 13.044707] [] ? native_safe_halt+0x6/0x10 [ 13.044717] [] ? trace_hardirqs_on+0xd/0x10 [ 13.044738] [] default_idle+0x59/0x120 [ 13.044742] [] arch_cpu_idle+0x18/0x40 [ 13.044754] [] cpu_startup_entry+0x235/0x410 [ 13.044763] [] rest_init+0xd1/0xe0 [ 13.044766] [] ? rest_init+0x5/0xe0 [ 13.044778] [] start_kernel+0x425/0x493 [ 13.044781] [] ? repair_env_string+0x5e/0x5e [ 13.044786] [] x86_64_start_reservations+0x2a/0x2c [ 13.044789] [] x86_64_start_kernel+0xf1/0x100 [ 13.044799] ---[ end trace 113ad28772af4058 ]--- Reported-by: Fengguang Wu Signed-off-by: Maarten Lankhorst Signed-off-by: Dave Airlie

drm/cirrus: deal with bo reserve fail in dirty update path

2013-05-02T02:46:56Z

Port over the mgag200 fix to cirrus as it suffers the same issue. On F19 testing, it was noticed we get a lot of errors in dmesg about being unable to reserve the buffer when plymouth starts, this is due to the buffer being in the process of migrating, so it makes sense we can't reserve it. In order to deal with it, this adds delayed updates for the dirty updates, when the bo is unreservable, in the normal console case this shouldn't ever happen, its just when plymouth or X is pushing the console bo to system memory. Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie