summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/cirrus/cirrus_fbdev.c
AgeCommit message (Collapse)AuthorFilesLines
2016-08-12drm: Remove superflous linux/fb.h includesDaniel Vetter1-2/+0
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
2015-11-24drm: Pass the user drm_mode_fb_cmd2 as const to .fb_create()Ville Syrjälä1-1/+1
Drivers shouldn't clobber the passed in addfb ioctl parameters. i915 was doing just that. To prevent it from happening again, pass the struct around as const, starting all the way from internal_framebuffer_create(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-06drm/cirrus: Use new drm_fb_helper functionsArchit Taneja1-33/+8
Use the newly created wrapper drm_fb_helper functions instead of calling core fbdev functions directly. v3: - Don't touch remove_conflicting_framebuffers v2: - Remove stray goto label out_iounmap Cc: Thierry Reding <treding@nvidia.com> Cc: Zach Reizner <zachr@google.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Fabian Frederick <fabf@skynet.be> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-21drm/fb-helper: Propagate errors from initial config failureThierry Reding1-6/+6
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>
2014-11-20drm/cirrus: allow 32bpp framebuffers for cirrus drmZach Reizner1-1/+4
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 <zachr@google.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-09-24drm/cirrus: use container_of to resolve cirrus_fbdev from drm_fb_helperFabian Frederick1-1/+2
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>
2014-07-08drm: Introduce drm_fb_helper_prepare()Thierry Reding1-1/+3
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>
2014-07-08drm: Constify struct drm_fb_helper_funcsThierry Reding1-1/+1
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>
2014-02-06drm/mgag200,ast,cirrus: fix regression with drm_can_sleep conversionDave Airlie1-1/+1
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>
2014-01-29drm: ast,cirrus,mgag200: use drm_can_sleepDave Airlie1-1/+1
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>
2014-01-13drm/cirrus: Fix cirrus drm driver for fbdev + qemuMartin Koegler1-0/+3
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>
2013-06-28drm/cirrus: do not attempt to acquire a reservation while in an interrupt ↵Maarten Lankhorst1-2/+3
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>
2013-05-02drm/cirrus: deal with bo reserve fail in dirty update pathDave Airlie1-1/+37
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>
2013-02-14drm/<drivers>: simplify ->fb_probe callbackDaniel Vetter1-19/+3
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>
2013-02-14drm/fb-helper: don't disable everything in initial_configDaniel Vetter1-0/+4
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>
2013-01-20drm: revamp framebuffer cleanup interfacesDaniel Vetter1-0/+1
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>
2012-10-02UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/David Howells1-2/+2
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>
2012-10-02UAPI: (Scripted) Remove redundant DRM UAPI header #inclusions from drivers/gpu/.David Howells1-1/+0
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>
2012-05-17drm/kms: driver for virtual cirrus under qemuDave Airlie1-0/+307
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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-21 03:57:26 +0000