| ea0622cfb4c0dbf3a8e6c4b448b8636ea75e1069 |
|
14-Sep-2014 |
Fabian Frederick <fabf@skynet.be> |
drm/cirrus: use container_of to resolve cirrus_fbdev from drm_fb_helper
Use container_of instead of casting first structure member.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
| 10a231026574f9ec9761b6435394b8830b485e4e |
|
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>
|
| 3a4938799dec32783759b0c66ee3bb8c82dd9937 |
|
27-Jun-2014 |
Thierry Reding <treding@nvidia.com> |
drm: Constify struct drm_fb_helper_funcs
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 <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| 8b7ad1bb3d440da888f2a939dc870eba429b9192 |
|
05-Feb-2014 |
Dave Airlie <airlied@redhat.com> |
drm/mgag200,ast,cirrus: fix regression with drm_can_sleep conversion
I totally sign inverted my way out of this one.
Cc: stable@vger.kernel.org
Reported-by: "Sabrina Dubroca" <sd@queasysnail.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| f4b4718b61d1d5a7442a4fd6863ea80c3a10e508 |
|
24-Jan-2014 |
Dave Airlie <airlied@redhat.com> |
drm: ast,cirrus,mgag200: use drm_can_sleep
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 <airlied@redhat.com>
|
| 99d4a8ae93ead27b5a88cdbd09dc556fe96ac3a8 |
|
09-Jan-2014 |
Martin Koegler <martin.koegler@chello.at> |
drm/cirrus: Fix cirrus drm driver for fbdev + qemu
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 <martin.koegler@chello.at>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| 19d4b72c0c22c14900313f89765c5f7ef0a2718a |
|
27-Jun-2013 |
Maarten Lankhorst <m.b.lankhorst@gmail.com> |
drm/cirrus: do not attempt to acquire a reservation while in an interrupt handler
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] <IRQ> [<ffffffff81fc86d5>] dump_stack+0x19/0x1b
[ 13.044441] [<ffffffff810d511b>] warn_slowpath_common+0x6b/0x90
[ 13.044445] [<ffffffff810d51a6>] warn_slowpath_fmt+0x46/0x50
[ 13.044448] [<ffffffff81fd34d7>] mutex_trylock+0x87/0x220
[ 13.044482] [<ffffffff8186484d>] cirrus_dirty_update+0x1cd/0x330
[ 13.044486] [<ffffffff818649e8>] cirrus_imageblit+0x38/0x50
[ 13.044506] [<ffffffff8165782e>] soft_cursor+0x22e/0x240
[ 13.044510] [<ffffffff81656c31>] bit_cursor+0x581/0x5b0
[ 13.044525] [<ffffffff815de9f4>] ? vsnprintf+0x124/0x670
[ 13.044529] [<ffffffff81651333>] ? get_color.isra.16+0x43/0x130
[ 13.044532] [<ffffffff81653fca>] fbcon_cursor+0x18a/0x1d0
[ 13.044535] [<ffffffff816566b0>] ? update_attr.isra.2+0xa0/0xa0
[ 13.044556] [<ffffffff81754b82>] hide_cursor+0x32/0xa0
[ 13.044565] [<ffffffff81755bd3>] vt_console_print+0x103/0x3b0
[ 13.044569] [<ffffffff810d58ac>] ? print_time+0x9c/0xb0
[ 13.044576] [<ffffffff810d5960>] ? print_prefix+0xa0/0xc0
[ 13.044580] [<ffffffff810d63f6>] call_console_drivers.constprop.6+0x146/0x1f0
[ 13.044593] [<ffffffff815f9b38>] ? do_raw_spin_unlock+0xc8/0x100
[ 13.044597] [<ffffffff810d6f27>] console_unlock+0x2f7/0x460
[ 13.044600] [<ffffffff810d787a>] vprintk_emit+0x59a/0x5e0
[ 13.044615] [<ffffffff81fb676c>] printk+0x4d/0x4f
[ 13.044650] [<ffffffff82ba5511>] print_local_APIC+0x28/0x41c
[ 13.044672] [<ffffffff8114db55>] generic_smp_call_function_single_interrupt+0x145/0x2b0
[ 13.044688] [<ffffffff8106f9e7>] smp_call_function_single_interrupt+0x27/0x40
[ 13.044697] [<ffffffff81fd8f72>] call_function_single_interrupt+0x72/0x80
[ 13.044707] <EOI> [<ffffffff81078166>] ? native_safe_halt+0x6/0x10
[ 13.044717] [<ffffffff811425cd>] ? trace_hardirqs_on+0xd/0x10
[ 13.044738] [<ffffffff8104f669>] default_idle+0x59/0x120
[ 13.044742] [<ffffffff810501e8>] arch_cpu_idle+0x18/0x40
[ 13.044754] [<ffffffff811320c5>] cpu_startup_entry+0x235/0x410
[ 13.044763] [<ffffffff81f9e781>] rest_init+0xd1/0xe0
[ 13.044766] [<ffffffff81f9e6b5>] ? rest_init+0x5/0xe0
[ 13.044778] [<ffffffff82b93ec2>] start_kernel+0x425/0x493
[ 13.044781] [<ffffffff82b93810>] ? repair_env_string+0x5e/0x5e
[ 13.044786] [<ffffffff82b93595>] x86_64_start_reservations+0x2a/0x2c
[ 13.044789] [<ffffffff82b93688>] x86_64_start_kernel+0xf1/0x100
[ 13.044799] ---[ end trace 113ad28772af4058 ]---
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| f3b2bbdc8a87a080ccd23d27fca4b87d61340dd4 |
|
02-May-2013 |
Dave Airlie <airlied@redhat.com> |
drm/cirrus: deal with bo reserve fail in dirty update path
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 <airlied@redhat.com>
|
| cd5428a5447cc6ca77ec6547d6f86834b205eac7 |
|
21-Jan-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/<drivers>: simplify ->fb_probe callback
The fb helper lost its support for reallocating an fb completely, so
no need to return special success values any more.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
| 76a39dbfb2d1bc45219839e5a95d4ceaf6ca114f |
|
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>
|
| 362063619cf67c2c2fc2eb90951b2623cbb69a7c |
|
10-Dec-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm: revamp framebuffer cleanup interfaces
We have two classes of framebuffer
- Created by the driver (atm only for fbdev), and the driver holds
onto the last reference count until destruction.
- Created by userspace and associated with a given fd. These
framebuffers will be reaped when their assoiciated fb is closed.
Now these two cases are set up differently, the framebuffers are on
different lists and hence destruction needs to clean up different
things. Also, for userspace framebuffers we remove them from any
current usage, whereas for internal framebuffers it is assumed that
the driver has done this already.
Long story short, we need two different ways to cleanup such drivers.
Three functions are involved in total:
- drm_framebuffer_remove: Convenience function which removes the fb
from all active usage and then drops the passed-in reference.
- drm_framebuffer_unregister_private: Will remove driver-private
framebuffers from relevant lists and drop the corresponding
references. Should be called for driver-private framebuffers before
dropping the last reference (or like for a lot of the drivers where
the fbdev is embedded someplace else, before doing the cleanup
manually).
- drm_framebuffer_cleanup: Final cleanup for both classes of fbs,
should be called by the driver's ->destroy callback once the last
reference is gone.
This patch just rolls out the new interfaces and updates all drivers
(by adding calls to drm_framebuffer_unregister_private at all the
right places)- no functional changes yet. Follow-on patches will move
drm core code around and update the lifetime management for
framebuffers, so that we are no longer required to keep framebuffers
alive by locking mode_config.mutex.
I've also updated the kerneldoc already.
vmwgfx seems to again be a bit special, at least I haven't figured out
how the fbdev support in that driver works. It smells like it's
external though.
v2: The i915 driver creates another private framebuffer in the
load-detect code. Adjust its cleanup code, too.
Reviewed-by: Rob Clark <rob@ti.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
| 760285e7e7ab282c25b5e90816f7c47000557f4f |
|
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>
|
| 4126d5d61f8466be3f76c1bc4e16d46eb2c9641b |
|
02-Oct-2012 |
David Howells <dhowells@redhat.com> |
UAPI: (Scripted) Remove redundant DRM UAPI header #inclusions from drivers/gpu/.
Remove redundant DRM UAPI header #inclusions from drivers/gpu/.
Remove redundant #inclusions of core DRM UAPI headers (drm.h, drm_mode.h and
drm_sarea.h). They are now #included via drmP.h and drm_crtc.h via a preceding
patch.
Without this patch and the patch to make include the UAPI headers from the core
headers, after the UAPI split, the DRM C sources cannot find these UAPI headers
because the DRM code relies on specific -I flags to make #include "..." work
on headers in include/drm/ - but that does not work after the UAPI split without
adding more -I flags.
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>
|
| f9aa76a85248565ff13dc0e10633c4343a059f71 |
|
17-Apr-2012 |
Dave Airlie <airlied@redhat.com> |
drm/kms: driver for virtual cirrus under qemu
This is the initial driver for emulated cirrus GPU found in qemu.
This driver only supports the emulated GPU and doesn't attempt
to bind to any real cirrus GPUs.
This driver is intended to be used with xf86-video-modesetting in userspace.
It requires at least version 0.3.0
This follow the same design as ast and mgag200, and is based on work
done by Matthew Garrett previously.
This GPU has no hw cursor, and it can't scanout 32-bpp, only packed 24-bpp.
i.e. it sucks.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|