Commit Graph

74 Commits

Author SHA1 Message Date
Ben Skeggs
ecf24de071 drm/nouveau: fix fbcon not being accelerated after suspend
This does *not* (and is not intended to) fix the issue reported by
Christoph Rudorff on the nouveau mailinglist.

The patch proposed (which is similar to this one, but also reorders
whether we disable accel or call fb_set_suspend first), papers over
another problem entirely by avoiding touching the framebuffer.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-03-26 14:08:13 +10:00
Ben Skeggs
46ea16884c drm/nouveau/fbcon: bracket entrypoints with a per-device enabled check
We don't necessarily have fbcon on all devices these days.

Fixes suspend on (at least) Quadro NVS 450.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08 15:39:56 +10:00
David Herrmann
55fb74adc6 drm/nouveau: embed gem object in nouveau_bo
There is no reason to keep the gem object separately allocated. nouveau is
the last user of gem_obj->driver_private, so if we embed it, we can get
rid of 8bytes per gem-object.

The implementation follows the radeon driver. bo->gem is only valid, iff
the bo was created via the gem helpers _and_ iff the user holds a valid
gem reference. That is, as the gem object holds a reference to the
nouveau_bo. If you use nouveau_ref() to gain a bo reference, you are not
guaranteed to also hold a gem reference. The gem object might get
destroyed after the last user drops the gem-ref via
drm_gem_object_unreference(). Use drm_gem_object_reference() to gain a
gem-reference.

For debugging, we can use bo->gem.filp != NULL to test whether a gem-bo is
valid. However, this shouldn't be used for real functionality to avoid
gem-internal dependencies.

Note that the implementation follows the previous style. However, we no
longer can check for bo->gem != NULL to test for a valid gem object. This
wasn't done before, so we should be safe now.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-10-09 14:37:55 +10:00
Ben Skeggs
fc1620883a drm/nouveau/kms: enable for non-vga pci classes
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-09-18 00:16:29 +10:00
Maarten Lankhorst
8a258353ed drm/nouveau: fix null pointer dereference in poll_changed
Fixes vgaswitcheroo on a card without display.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-07-30 13:04:19 +10:00
Maarten Lankhorst
fdfb833265 drm/nouveau: fix some error-path leaks in fbcon handling code
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-07-10 10:47:28 +10:00
Dave Airlie
f7d452f4fd Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next
- Various fixes that make surviving concurrent piglit more possible.
- Buffer object deletion no longer synchronous
- Context/register initialisation updates that have been reported to
solve some stability issues (particularly on some problematic GF119
chips)
- Kernel side support for VP2 video decoding engines

* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (44 commits)
  drm/nvd0-/disp: handle case where display engine is missing/disabled
  drm/gr/nvc0-: merge nvc0/nve0 ucode, and use cpp instead of m4
  drm/nouveau/bsp/nv84: initial vp2 engine implementation
  drm/nouveau/vp/nv84: initial vp2 engine implementation
  drm/nouveau/core: xtensa engine base class implementation
  drm/nouveau/vdec: fork vp3 implementations from vp2
  drm/nouveau/core: move falcon class to engine/
  drm/nouveau/kms: don't fail if there's no dcb table entries
  drm/nouveau: remove limit on gart
  drm/nouveau/vm: perform a bar flush when flushing vm
  drm/nvc0/gr: cleanup register lists, and add nvce/nvcf to switches
  drm/nvc8/gr: update initial register/context values
  drm/nvc4/gr: update initial register/context values
  drm/nvc1/gr: update initial register/context values
  drm/nvc3/gr: update initial register/context values
  drm/nvc0/gr: update initial register/context values
  drm/nvd9/gr: update initial register/context values
  drm/nve4/gr: update initial register/context values
  drm/nvc0-/gr: bump maximum gpc/tpc limits
  drm/nvf0/gr: initial register/context setup
  ...
2013-07-01 14:10:20 +10:00
Ben Skeggs
dceef5d87c drm/nouveau/fb: initialise vram controller as pfb sub-object
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-07-01 13:44:04 +10:00
Maarten Lankhorst
1e2bd5f53b drm/nouveau: fixup fbcon failure paths
Add missing calls, and fix a leak from forgetting to call the unpin function.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-06-28 11:56:00 +10:00
Daniel Vetter
cd5428a544 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>
2013-02-14 00:07:58 +01:00
Daniel Vetter
76a39dbfb2 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>
2013-02-14 00:07:53 +01:00
Daniel Vetter
362063619c 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>
2013-01-20 22:17:00 +01:00
Linus Torvalds
612a9aab56 Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux
Pull drm merge (part 1) from Dave Airlie:
 "So first of all my tree and uapi stuff has a conflict mess, its my
  fault as the nouveau stuff didn't hit -next as were trying to rebase
  regressions out of it before we merged.

  Highlights:
   - SH mobile modesetting driver and associated helpers
   - some DRM core documentation
   - i915 modesetting rework, haswell hdmi, haswell and vlv fixes, write
     combined pte writing, ilk rc6 support,
   - nouveau: major driver rework into a hw core driver, makes features
     like SLI a lot saner to implement,
   - psb: add eDP/DP support for Cedarview
   - radeon: 2 layer page tables, async VM pte updates, better PLL
     selection for > 2 screens, better ACPI interactions

  The rest is general grab bag of fixes.

  So why part 1? well I have the exynos pull req which came in a bit
  late but was waiting for me to do something they shouldn't have and it
  looks fairly safe, and David Howells has some more header cleanups
  he'd like me to pull, that seem like a good idea, but I'd like to get
  this merge out of the way so -next dosen't get blocked."

Tons of conflicts mostly due to silly include line changes, but mostly
mindless.  A few other small semantic conflicts too, noted from Dave's
pre-merged branch.

* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (447 commits)
  drm/nv98/crypt: fix fuc build with latest envyas
  drm/nouveau/devinit: fixup various issues with subdev ctor/init ordering
  drm/nv41/vm: fix and enable use of "real" pciegart
  drm/nv44/vm: fix and enable use of "real" pciegart
  drm/nv04/dmaobj: fixup vm target handling in preparation for nv4x pcie
  drm/nouveau: store supported dma mask in vmmgr
  drm/nvc0/ibus: initial implementation of subdev
  drm/nouveau/therm: add support for fan-control modes
  drm/nouveau/hwmon: rename pwm0* to pmw1* to follow hwmon's rules
  drm/nouveau/therm: calculate the pwm divisor on nv50+
  drm/nouveau/fan: rewrite the fan tachometer driver to get more precision, faster
  drm/nouveau/therm: move thermal-related functions to the therm subdev
  drm/nouveau/bios: parse the pwm divisor from the perf table
  drm/nouveau/therm: use the EXTDEV table to detect i2c monitoring devices
  drm/nouveau/therm: rework thermal table parsing
  drm/nouveau/gpio: expose the PWM/TOGGLE parameter found in the gpio vbios table
  drm/nouveau: fix pm initialization order
  drm/nouveau/bios: check that fixed tvdac gpio data is valid before using it
  drm/nouveau: log channel debug/error messages from client object rather than drm client
  drm/nouveau: have drm debugging macros build on top of core macros
  ...
2012-10-03 23:29:23 -07:00
Ben Skeggs
77145f1cbd drm/nouveau: port remainder of drm code, and rip out compat layer
v2: Ben Skeggs <bskeggs@redhat.com>
- fill in nouveau_pm.dev to prevent oops
- fix ppc issues (build + OF shadow)

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-10-03 13:12:59 +10:00
Ben Skeggs
ebb945a94b drm/nouveau: port all engines to new engine module format
This is a HUGE commit, but it's not nearly as bad as it looks - any problems
can be isolated to a particular chipset and engine combination.  It was
simply too difficult to port each one at a time, the compat layers are
*already* ridiculous.

Most of the changes here are simply to the glue, the process for each of the
engine modules was to start with a standard skeleton and copy+paste the old
code into the appropriate places, fixing up variable names etc as needed.

v2: Marcin Slusarz <marcin.slusarz@gmail.com>
- fix find/replace bug in license header

v3: Ben Skeggs <bskeggs@redhat.com>
- bump indirect pushbuf size to 8KiB, 4KiB barely enough for userspace and
  left no space for kernel's requirements during GEM pushbuf submission.
- fix duplicate assignments noticed by clang

v4: Marcin Slusarz <marcin.slusarz@gmail.com>
- add sparse annotations to nv04_fifo_pause/nv04_fifo_start
- use ioread32_native/iowrite32_native for fifo control registers

v5: Ben Skeggs <bskeggs@redhat.com>
- rebase on v3.6-rc4, modified to keep copy engine fix intact
- nv10/fence: unmap fence bo before destroying
- fixed fermi regression when using nvidia gr fuc
- fixed typo in supported dma_mask checking

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-10-03 13:12:56 +10:00
Ben Skeggs
861d21074b drm/nouveau/fb: merge fb/vram and port to subdev interfaces
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-10-03 13:12:49 +10:00
Ben Skeggs
9458029940 drm/nouveau: implement module init functions in nouveau_drm.c
These currently just call the existing ones in nouveau_drv.c, but will be
extended in upcoming commits.  This needed to be separated from the current
code as there will be some header clashes until things are ported.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-10-03 13:12:44 +10:00
David Howells
760285e7e7 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>
2012-10-02 18:01:07 +01:00
David Howells
4126d5d61f 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>
2012-10-02 18:01:05 +01:00
Ben Skeggs
9bd0c15fcf drm/nouveau/fbcon: using nv_two_heads is not a good idea
nv_two_heads() was never meant to be used outside of pre-nv50 code.  The
code checks for >= NV_10 for 2 CRTCs, then downgrades a few specific
chipsets to 1 CRTC based on (pci_device & 0x0ff0).

The breakage example seen is on GTX 560Ti, with a pciid of 0x1200, which
gets detected as an NV20 (0x020x) with 1 CRTC by nv_two_heads(), causing
memory corruption because there's actually 2 CRTCs..

This switches fbcon to use the CRTC count directly from the mode_config
structure, which will also fix the same issue on Kepler boards which have
4 CRTCs.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-06-26 12:16:43 +01:00
Ben Skeggs
78df3a1c58 drm/nouveau/fbcon: use fence for sync, rather than notifier
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-05-24 16:56:15 +10:00
Ben Skeggs
6d59702775 drm/nouveau: use the same packet header macros as userspace
Cosmetic cleanup only.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-05-24 16:31:49 +10:00
Sascha Hauer
fb2a99e15f drm: do not set fb_info->pixmap fields
The drm drivers set the fb_info->pixmap fields without setting
fb_info->pixmap.addr. If this is not set the fb core will overwrite
these all fb_info->pixmap fields anyway, so there is not much point
in setting them in the first place.

[airlied: dropped nvidiafb piece - not mine]

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-09 10:34:43 +00:00
Ben Skeggs
cf41d53bf5 drm/nouveau: re-jig fbcon suspend/resume process a little
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-12-21 19:01:34 +10:00
Dave Airlie
1fbe6f625f Merge tag 'v3.2-rc6' of /home/airlied/devel/kernel/linux-2.6 into drm-core-next
Merge in the upstream tree to bring in the mainline fixes.

Conflicts:
	drivers/gpu/drm/exynos/exynos_drm_fbdev.c
	drivers/gpu/drm/nouveau/nouveau_sgdma.c
2011-12-20 14:43:53 +00:00
Ville Syrjälä
01f2c7730e drm: Replace pitch with pitches[] in drm_framebuffer
Otherwise each driver would need to keep the information inside
their own framebuffer object structure. Also add offsets[]. BOs
on the other hand are driver specific, so those can be kept in
driver specific structures.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-20 10:06:27 +00:00
Jesse Barnes
308e5bcbdb drm: add an fb creation ioctl that takes a pixel format v5
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from the new drm_fourcc.h header file.  Implement the fb creation
hooks in terms of the new mode_fb_cmd2 using helpers where the old
bpp/depth values are needed.

v2: create DRM specific fourcc header file for sharing with libdrm etc
v3: fix rebase failure and use DRM fourcc codes in intel_display.c and
    update commit message
v4: make fb_cmd2 handle field into an array for multi-object formats
    pull in Ville's fix for the memcpy in drm_plane_init
    apply Ville's cleanup to zero out fb_cmd2 arg in drm_mode_addfb
v5: add 'flags' field for interlaced support (from Ville)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-11-15 19:53:23 +00:00
Marcin Slusarz
1e482f75f1 drm/nouveau: by default use low bpp framebuffer on low memory cards
Framebuffer's BPP is not that important but can waste significant part
of memory on low-VRAM cards. Lower it to 8bpp on < 32MB cards and to
16bpp on 64MB cards. It can still be overridden by video= option.

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-11-10 09:02:41 +10:00
Ben Skeggs
45143cb53c drm/nv50-nvc0: explicitly map fbcon fb into channel vm
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-06-23 15:59:59 +10:00
Ben Skeggs
f6d4e62145 drm/nouveau: remove 'chan' argument from nouveau_gem_new
Userspace hasn't passed us a channel_hint for a long long time now, and
there isn't actually a need to do so anymore anyway.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-06-23 15:58:56 +10:00
Marcin Slusarz
a18d89ca02 drm/nouveau: fix notifier memory corruption bug
nouveau_bo_wr32 expects offset to be in words, but we pass value in bytes,
so after commit 73412c3854 ("drm/nouveau: allocate
kernel's notifier object at end of block") we started to overwrite some memory
after notifier buffer object (previously m2mf_ntfy was always 0, so it didn't
matter it was a value in bytes).

Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
Reported-by: Nigel Cunningham <lkml@nigelcunningham.com.au>
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Pekka Paalanen <pq@iki.fi>
Cc: stable@kernel.org    [2.6.38]
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-04-20 08:51:31 +10:00
Ben Skeggs
6ba9a68317 drm/nouveau: pass domain rather than ttm flags to gem_new()
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-02-25 06:45:40 +10:00
Ben Skeggs
d550c41e4f drm/nouveau: remove no_vm/mappable flags from nouveau_bo
'mappable' isn't really used at all, nor is it necessary anymore as the
bo code is capable of moving buffers to mappable vram as required.

'no_vm' isn't necessary anymore either, any places that don't want to be
mapped into a GPU address space should allocate the VRAM directly instead.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-02-25 06:45:34 +10:00
Dave Airlie
51fda92223 Merge remote branch 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next into drm-fixes
* 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next:
  drm/nouveau: fix gpu page faults triggered by plymouthd
  drm/nouveau: greatly simplify mm, killing some bugs in the process
  drm/nvc0: enable protection of system-use-only structures in vm
  drm/nv40: initialise 0x17xx on all chipsets that have it
  drm/nv40: make detection of 0x4097-ful chipsets available everywhere
2011-01-17 12:20:31 +10:00
Ben Skeggs
f01a9720cb drm/nouveau: fix gpu page faults triggered by plymouthd
The switch to separate BAR and channel address spaces made the fbcon memory
address calculation incorrect on NV50+ boards, this commit fixes that.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-01-17 11:28:59 +10:00
Dave Airlie
3632ef8909 Revert "drm: Update fbdev fb_fix_screeninfo"
This reverts commit dfe63bb0ad.

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>
2011-01-14 16:10:28 -08:00
James Simmons
dfe63bb0ad 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>
2011-01-07 13:44:40 +10:00
Dave Airlie
1d99e5c572 Merge remote branch 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next into drm-core-next
* 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next:
  drm/nvc0: accelerate ttm buffer moves
  drm/nvc0: initial support for tiled buffer objects
  drm/nvc0: implement fbcon acceleration
  drm/nvc0: implement pgraph engine hooks
  drm/nvc0: implement pfifo engine hooks
  drm/nvc0: implement fencing
  drm/nvc0: fix channel dma init paths
  drm/nvc0: skip dma object creation for drm channel
  drm/nvc0: implement channel structure initialisation
  drm/nvc0: gpuobj_new need only check validity and init the relevant engine
  drm/nvc0: reject the notifier_alloc ioctl
  drm/nvc0: create shared channel vm
  drm/nvc0: initial vm implementation, use for bar1/bar3 management
  drm/nvc0: import initial vm backend
  drm/nouveau: modify vm to accomodate dual page tables for nvc0
  drm/nv50: add missing license header to nv50_fbcon.c
  drm/nv50: fix smatch warning in nv50_vram.c
  drm/nouveau: sizeof() vs ARRAY_SIZE()
2010-12-22 09:48:04 +10:00
Ben Skeggs
ddbaf79a8b drm/nvc0: implement fbcon acceleration
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-12-21 17:18:39 +10:00
James Simmons
57084d0537 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>
2010-12-21 12:49:44 +10:00
Ben Skeggs
4c13614298 drm/nv50: implement global channel address space on new VM code
As of this commit, it's guaranteed that if an object is in VRAM that its
GPU virtual address will be constant.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-12-08 13:48:13 +10:00
Ben Skeggs
9acc8100cb drm/nouveau: fallback to sw fbcon if we can't get mutex immediately
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-12-03 15:06:23 +10:00
Ben Skeggs
6a6b73f254 drm/nouveau: add per-channel mutex, use to lock access to drm's channel
This fixes a race condition between fbcon acceleration and TTM buffer
moves.  To reproduce:

- start X
- switch to vt and "while (true); do dmesg; done"
- switch to another vt and "sleep 2 && cat /path/to/debugfs/dri/0/evict_vram"
- switch back to vt running dmesg

We don't make use of this on any other channel yet, they're currently
protected by drm_global_mutex.  This will change in the near future.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-12-03 15:05:10 +10:00
Ben Skeggs
ceed5f30bf drm/nouveau: disallow fbcon accel if running in interrupt context
A future commit will add locking to the DRM's channel, and there's numerous
problems that come up if we allow printk from an interrupt context to be
accelerated.  It seems saner to just disallow it completely.

As a nice side-effect, all the "to accel or not to accel" logic gets moved
out of the chipset-specific code.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-12-03 15:04:20 +10:00
Dave Airlie
b7ae5056c9 Merge branch 'drm-fixes' of /home/airlied/kernel/linux-2.6 into drm-core-next
Conflicts:
	drivers/gpu/drm/i915/intel_fb.c
	drivers/gpu/drm/radeon/r600_blit_kms.c
	drivers/gpu/drm/ttm/ttm_bo.c
2010-10-19 09:48:34 +10:00
Dave Airlie
dab8dcfa3c drm: don't drop handle reference on unload
since the handle references are all tied to a file_priv, and when it disappears
all the handle refs go with it.

The fbcon ones we'd only notice on unload, but the nouveau notifier one
would would happen on reboot.

nouveau: Reported-by: Marc Dionne <marc.c.dionne@gmail.com>
nouveau: Tested-by: Marc Dionne <marc.c.dionne@gmail.com>
i915 unload: Reported-by: Keith Packard <keithp@keithp.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-10-07 14:01:17 +10:00
Chris Ball
be64c2bb47 drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS.
Tested on nv50 and nv04 HW.

Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-10-06 11:50:21 +10:00
Dave Airlie
29d08b3efd drm/gem: handlecount isn't really a kref so don't make it one.
There were lots of places being inconsistent since handle count
looked like a kref but it really wasn't.

Fix this my just making handle count an atomic on the object,
and have it increase the normal object kref.

Now i915/radeon/nouveau drivers can drop the normal reference on
userspace object creation, and have the handle hold it.

This patch fixes a memory leak or corruption on unload, because
the driver had no way of knowing if a handle had been actually
added for this object, and the fbcon object needed to know this
to clean itself up properly.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-10-01 09:17:44 +10:00
Linus Torvalds
aa9f56b66d Merge branch 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
* 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (55 commits)
  io-mapping: move asm include inside the config option
  vgaarb: drop vga.h include
  drm/radeon: Add probing of clocks from device-tree
  drm/radeon: drop old and broken mesa warning
  drm/radeon: Fix pci_map_page() error checking
  drm: Remove count_lock for calling lastclose() after 58474713 (v2)
  drm/radeon/kms: allow FG_ALPHA_VALUE on r5xx
  drm/radeon/kms: another r6xx/r7xx CS checker fix
  DRM: Replace kmalloc/memset combos with kzalloc
  drm: expand gamma_set
  drm/edid: Split mode lists out to their own header for readability
  drm/edid: Rewrite mode parse to use the generic detailed block walk
  drm/edid: Add detailed block walk for VTB extensions
  drm/edid: Add detailed block walk for CEA extensions
  drm: Remove unused fields from drm_display_info
  drm: Use ENOENT consistently for the error return for an unmatched handle.
  drm/radeon/kms: mark 3D power states as performance
  drm: Only set DPMS once on the CRTC not after every encoder.
  drm/radeon/kms: add additional quirk for Acer rv620 laptop
  drm: Propagate error code from fb_create()
  ...

Fix up trivial conflicts in drivers/gpu/drm/drm_edid.c
2010-08-12 09:21:39 -07:00
Jesse Barnes
8fd4bd2235 vt/console: try harder to print output when panicing
Jesse's initial patch commit said:

"At panic time (i.e.  when oops_in_progress is set) we should try a bit
harder to update the screen and make sure output gets to the VT, since
some drivers are capable of flipping back to it.

So make sure we try to unblank and update the display if called from a
panic context."

I've enhanced this to add a flag to the vc that console layer can set to
indicate they want this behaviour to occur.  This also adds support to
fbcon for that flag and adds an fb flag for drivers to indicate they want
to use the support.  It enables this for KMS drivers.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: James Simmons <jsimmons@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-10 13:47:40 -07:00