summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/mgag200/mgag200_main.c
AgeCommit message (Collapse)Author
2013-10-09drm: kill ->gem_init_object() and friendsDavid Herrmann
All drivers embed gem-objects into their own buffer objects. There is no reason to keep drm_gem_object_alloc(), gem->driver_private and ->gem_init_object() anymore. New drivers are highly encouraged to do the same. There is no benefit in allocating gem-objects separately. Cc: Dave Airlie <airlied@gmail.com> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jerome Glisse <jglisse@redhat.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Inki Dae <inki.dae@samsung.com> Cc: Ben Skeggs <skeggsb@gmail.com> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-07drm/gem: create drm_gem_dumb_destroyDaniel Vetter
All the gem based kms drivers really want the same function to destroy a dumb framebuffer backing storage object. So give it to them and roll it out in all drivers. This still leaves the option open for kms drivers which don't use GEM for backing storage, but it does decently simplify matters for gem drivers. Acked-by: Inki Dae <inki.dae@samsung.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org> Cc: Ben Skeggs <skeggsb@gmail.com> Reviwed-by: Rob Clark <robdclark@gmail.com> Cc: Alex Deucher <alexdeucher@gmail.com> Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-07-25drm/ttm: convert to unified vma offset managerDavid Herrmann
Use the new vma-manager infrastructure. This doesn't change any implementation details as the vma-offset-manager is nearly copied 1-to-1 from TTM. The vm_lock is moved into the offset manager so we can drop it from TTM. During lookup, we use the vma locking helpers to take a reference to the found object. In all other scenarios, locking stays the same as before. We always guarantee that drm_vma_offset_remove() is called only during destruction. Hence, helpers like drm_vma_node_offset_addr() are always safe as long as the node has a valid offset. This also drops the addr_space_offset member as it is a copy of vm_start in vma_node objects. Use the accessor functions instead. v4: - remove vm_lock - use drm_vma_offset_lock_lookup() to protect lookup (instead of vm_lock) Cc: Dave Airlie <airlied@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com> Cc: Martin Peres <martin.peres@labri.fr> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-06-28drm/mgag200: Added resolution and bandwidth limits for various G200e products.Julia Lemire
At the larger resolutions, the g200e series sometimes struggles with maintaining a proper output. Problems like flickering or black bands appearing on screen can occur. In order to avoid this, limitations regarding resolutions and bandwidth have been added for the different variations of the g200e series. This code was ported from the old xorg mga driver. Signed-off-by: Julia Lemire <jlemire@matrox.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-06-17drm/mgag200: Don't do full cleanup if mgag200_device_init failsChristopher Harvey
Running mgag200_driver_unload when the driver init fails early on causes functions like drm_mode_config_cleanup to be called. The problem is, drm_mode_config_cleanup crashes because the corresponding init hasn't happend yet. There really isn't anything to cleanup after mgag200_device_init, so we can just pass the error code upwards. Acked-by: Julia Lemire <jlemire@matrox.com> Signed-off-by: Christopher Harvey <charvey@matrox.com> Acked-by: Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-06-17drm/mgag200: Hardware cursor supportChristopher Harvey
G200 cards support, at best, 16 colour palleted images for the cursor so we do a conversion in the cursor_set function, and reject cursors with more than 16 colours, or cursors with partial transparency. Xorg falls back gracefully to software cursors in this case. We can't disable/enable the cursor hardware without causing momentary corruption around the cursor. Instead, once the cursor is on we leave it on, and simulate turning the cursor off by moving it offscreen. This works well. Since we can't disable -> update -> enable the cursors, we double buffer cursor icons, then just move the base address that points to the old cursor, to the new. This also works well, but uses an extra page of memory. The cursor buffers are lazily-allocated on first cursor_set. This is to make sure they don't take priority over any framebuffers in case of limited memory. Here is a representation of how the bitmap for the cursor is mapped in G200 memory : Each line of color cursor use 6 Slices of 8 bytes. Slices 0 to 3 are used for the 4bpp bitmap, slice 4 for XOR mask and slice 5 for AND mask. Each line has the following format: // Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 // // S0: P00-01 P02-03 P04-05 P06-07 P08-09 P10-11 P12-13 P14-15 // S1: P16-17 P18-19 P20-21 P22-23 P24-25 P26-27 P28-29 P30-31 // S2: P32-33 P34-35 P36-37 P38-39 P40-41 P42-43 P44-45 P46-47 // S3: P48-49 P50-51 P52-53 P54-55 P56-57 P58-59 P60-61 P62-63 // S4: X63-56 X55-48 X47-40 X39-32 X31-24 X23-16 X15-08 X07-00 // S5: A63-56 A55-48 A47-40 A39-32 A31-24 A23-16 A15-08 A07-00 // // S0 to S5 = Slices 0 to 5 // P00 to P63 = Bitmap - pixels 0 to 63 // X00 to X63 = always 0 - pixels 0 to 63 // A00 to A63 = transparent markers - pixels 0 to 63 // 1 means colour, 0 means transparent Signed-off-by: Christopher Harvey <charvey@matrox.com> Signed-off-by: Mathieu Larouche <mathieu.larouche@matrox.com> Acked-by: Julia Lemire <jlemire@matrox.com> Tested-by: Julia Lemire <jlemire@matrox.com> Signed-off-by: Dave Airlie <airlied@gmail.com>
2013-04-30drm/mgag200: Remove extra variable assignsChristopher Harvey
These two variables are set again immediately in 'mgag200_modeset_init' Signed-off-by: Christopher Harvey <charvey@matrox.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-04-12drm/mgag200: Convert to managed device resources where possibleChristopher Harvey
Signed-off-by: Christopher Harvey <charvey@matrox.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-01-20drm/<drivers>: Unified handling of unimplemented fb->create_handleDaniel Vetter
Some drivers don't have real ->create_handle callbacks. - cirrus/ast/mga200: Returns either 0 or -EINVAL. - udl: Didn't even bother with a callback, leading to a nice userspace-triggerable OOPS. - vmwgfx: This driver bothered with an implementation to return 0 as the handle (which is the canonical no-obj gem handle). All have in common that ->create_handle doesn't really make too much sense for them - that ioctl is used only for seamless fb takeover in the radeon/nouveau/i915 ddx drivers. So allow drivers to not implement this and return a consistent -ENODEV. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-01-20drm/<drivers>: reorder framebuffer init sequenceDaniel Vetter
With more fine-grained locking we can no longer rely on the big mode_config lock to prevent concurrent access to mode resources like framebuffers. Instead a framebuffer becomes accessible to other threads as soon as it is added to the relevant lookup structures. Hence it needs to be fully set up by the time drivers call drm_framebuffer_init. This patch here is the drivers part of that reorg. Nothing really fancy going on safe for three special cases. - exynos needs to be careful to properly unref all handles. - nouveau gets a resource leak fixed for free: one of the error cases didn't cleanup the framebuffer, which is now moot since the framebuffer is only registered once it is fully set up. - vmwgfx requires a slight reordering of operations, I'm hoping I didn't break anything (but it's refcount management only, so should be safe). v2: Split out exynos, since it's a bit more hairy than expected. v3: Drop bogus cirrus hunk noticed by Richard Wilbur. v4: Split out vmwgfx since there's a small change in return values. Reviewed-by: Rob Clark <rob@ti.com> (core + omapdrm) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-20drm/mgag200: remove unneeded aper->count assignment after alloc_apertures()Tommi Rantala
alloc_apertures() already does the assignment for us, so assigning the count member after the alloc_apertures() call is not needed. Signed-off-by: Tommi Rantala <tt.rantala@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-11-20drm/mgag200: free memory allocated with alloc_apertures()Tommi Rantala
Fix a memory leak by deallocating the memory we got from alloc_apertures(). Signed-off-by: Tommi Rantala <tt.rantala@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-11-20drm/mgag200: check alloc_apertures() success in mga_vram_init()Tommi Rantala
Check for alloc_apertures() memory allocation failure, and propagate an error code in case the allocation failed. Signed-off-by: Tommi Rantala <tt.rantala@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-10-02UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/David Howells
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 Howells
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-17mgag200: initial g200se driver (v2)Dave Airlie
This is a driver for the G200 server engines chips, it doesn't driver any of the Matrix G series desktop cards. It will bind to G200 SE A,B, G200EV, G200WB, G200EH and G200ER cards. Its based on previous work done my Matthew Garrett but remodelled to follow the same style and flow as the AST server driver. It also works along the same lines as the AST server driver wrt memory management. There is no userspace driver planned, xf86-video-modesetting should be used. It also appears these GPUs have no ARGB hw cursors. v2: add missing tagfifo reset + G200 SE memory bw setup pieces. Signed-off-by: Dave Airlie <airlied@redhat.com>