Commit Graph

23 Commits

Author SHA1 Message Date
John Baldwin
c2a51a4b0e Remove compatibility shims for FreeBSD versions older than 8.0. 2015-06-04 20:36:16 +00:00
Andriy Gapon
d009878bb9 fix atomic_set_xxx misuse in drm
It seems that atomic_set_xxx and atomic_store_xxx were confused.

Reviewed by:	jhb
MFC after:	3 weeks
2010-12-11 10:18:05 +00:00
Robert Noland
2642e635f2 Keep track of the hardware counter more aggressively while interrupts
are enabled.  This should help to reduce cases where the hardware
counter reference jumps by large amounts.

MFC after:	3 days
2009-06-25 15:47:32 +00:00
Robert Noland
a429bdf087 Fix one use of atomic for refcount missed in last commit.
MFC after:	3 days
2009-06-25 15:36:11 +00:00
Robert Noland
1f3c8cf88f Additional vblank cleanups.
Use the vbl_lock when maniputlating the refcount.  Eventually I want to
convert this to use our internal refcount code.  Continue to use atomic
ops for manipulating vblank count since we access it often just for
reading.

MFC after:	3 days
2009-06-25 15:30:25 +00:00
Robert Noland
a708803975 Ensure that we always hold the lock when calling vblank_disable_fn()
MFC after:	3 days
2009-06-25 14:15:45 +00:00
Robert Noland
179ab71fdd Using signals for vblank events is prone to issues. There have never
been any consumers and likely will never be.  Furthermore, we have
never enabled the code for it, so just get rid of it.

MFC after:	3 days
2009-06-23 18:09:35 +00:00
Robert Noland
a2d33c4900 Given that vblanks generally occur 60 times a second, waiting 3 seconds
seems rather excessive.

MFC after:	3 days
2009-06-23 17:52:41 +00:00
Robert Noland
3a5185e13a vblank[crtc].last represents the hardware counter while request.sequence
represents the software counter.  Don't currupt things here.

MFC after:	3 days
2009-06-23 17:50:35 +00:00
Robert Noland
b0f6d6b6bb Fix up waiting on vblank again... This reverts a last minute change that
I made on the last patch, it seems to upset suspend/resume and shutdown.

MFC after:	3 days
2009-03-26 02:10:18 +00:00
Robert Noland
24c6d24b27 Rework the management of vblank interrupts a bit.
When a vt switch occurs the irq handler is uninstalled.  Interrupts
and the state tracking of what was enabled/disabled wasn't working
properly.  This should resolve the reports of "slow windows" after a
vt switch, among other things.  The radeon 2d driver seems to work a
bit more correctly than the Intel driver.  With the Intel driver,
vblank interrupts will be enabled at system startup and will only
be disabled after an additional modeset (vt switch, dpms, randr event).

With this patch, I am able to run glxgears synced to vblank and
vt switch while it is running without ill effects.

MFC after:	3 days
2009-03-25 01:50:56 +00:00
Robert Noland
c20a7fc9f6 Only issue the wakeup and store the counter if vblank is enabled on
the pipe.

MFC after:	3 days
2009-03-20 04:53:12 +00:00
Robert Noland
ea196ecaaa Rework vblank handling to try to resolve some reports of "slow" windows
after vt switch or suspend.  I can't really test this on Intel right now
but I think I've heard reports of it on radeon as well.  I can't break
it on the radeon here.

MFC after:	3 days
2009-03-19 08:34:04 +00:00
Robert Noland
51e39089c9 Initialize the vblank structures at load time. Previously we did this
at irq install/uninstall time, but when we vt switch, we uninstall the
irq handler.  When the irq handler is reinstalled, the modeset ioctl
happens first.  The modeset ioctl is supposed to tell us that we can
disable vblank interrupts if there are no active consumers.  This will
fail after a vt switch until another modeset ioctl is called via dpms
or xrandr.  Leading to cases where either interrupts are on and can't
be disabled, or worse, no interrupts at all.

MFC after:	2 weeks
2009-02-28 02:37:55 +00:00
Robert Noland
bbc33a7d31 Turn on MSI if the card supports it. There is a blacklist for chips
which report that they are capable of MSI, but don't work correctly.

MFC after:	2 weeks
2009-02-25 18:54:35 +00:00
Robert Noland
82369f9166 Add some vblank related debugging and replace the DRM_WAIT_ON macro
with a localized version.

MFC after:	2 weeks
2009-02-25 18:48:33 +00:00
Robert Noland
67f435f03e The i915 driver was the only consumer of locked task support.
Now that it doesn't use it anymore, get right of the taskqueue
and locked task support.

MFC after:	2 weeks
2009-02-25 18:25:47 +00:00
Robert Noland
f00755f06b Rework memory allocation to allocate memory with different type names. This
will ease the identification of memory leaks as the OS will be able to track
allocations for us by malloc type.  vmstat -m will show all of the
allocations.

Convert the calls to drm_alloc() and friends, which are used in shared code
to static __inline__ while we are here.

Approved by:	jhb (mentor)
2008-10-13 18:03:27 +00:00
Robert Noland
4cd2e9581f resync to git master
This reverts a private patch which is causing issues with many Intel chipsets.
I will review that patch and see what we need to do to fix it up later, but
for the time being, we will just get these chips working again.

This update contains a lot of code cleanup and is post gem merge
(no, we don't have gem support).  It should prove much easier to read the
code now.  A lot of thanks goes to vehemens for that work.  I have adapted
the code to use cdevpriv for tracking per open file data.  That alleviates
the old ugly hack that we used to try and accomplish the task and helped to
clean up the open / close behavior a good bit.  This also replaces the hack
that was put in place a year or so ago to prevent radeons from locking up
with AIGLX enabled.  I have had a couple of radeon testers report that it
still works as expected, though I no longer have radeon hardware to test with
myself.  Other various fixes from the linux crew and Intel, many of
which are muddled in with the gem merge.

Approved by:	jhb (mentor)
Obtained from:	mesa/drm git master
MFC after:	2 weeks
2008-10-03 16:59:11 +00:00
Robert Noland
a2a2d95441 Update drm kernel drivers.
This is a sync to mesa/drm pre-gem, with a few fixes on top of that.
It also contains one local patch supplied by kib@ that I can't apply to
git.master shared code.

Approved by:	flz
Obtained from:	mesa/drm git.master
MFC after:	2 weeks
2008-08-23 20:59:12 +00:00
Paolo Pisati
ef544f6312 o break newbus api: add a new argument of type driver_filter_t to
bus_setup_intr()

o add an int return code to all fast handlers

o retire INTR_FAST/IH_FAST

For more info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=465712+0+current/freebsd-current

Reviewed by: many
Approved by: re@
2007-02-23 12:19:07 +00:00
Eric Anholt
9fb0767374 Update DRM to CVS snapshot as of 2005-11-28. Notable changes:
- S3 Savage driver ported.
- Added support for ATI_fragment_shader registers for r200.
- Improved r300 support, needed for latest r300 DRI driver.
- (possibly) r300 PCIE support, needs X.Org server from CVS.
- Added support for PCI Matrox cards.
- Software fallbacks fixed for Rage 128, which used to render badly or hang.
- Some issues reported by WITNESS are fixed.
- i915 module Makefile added, as the driver may now be working, but is untested.
- Added scripts for copying and preprocessing DRM CVS for inclusion in the
  kernel.  Thanks to Daniel Stone for getting me started on that.
2005-11-28 23:13:57 +00:00
Eric Anholt
b8aa843c63 Update to DRM CVS as of 2005-04-12, bringing many changes:
- Split core DRM routines back into their own module, rather than using the
  nasty templated system like before.
- Development-class R300 support in radeon driver (requires userland pieces, of
  course).
- Mach64 driver (haven't tested in a while -- my mach64s no longer fit in the
  testbox).  Covers Rage Pros, Rage Mobility P/M, Rage XL, and some others.
- i915 driver files, which just need to get drm_drv.c fixed to allow attachment
  to the drmsub device.  Covers i830 through i915 integrated graphics.
- savage driver files, which should require minimal changes to work.  Covers the
  Savage3D, Savage IX/MX, Savage 4, ProSavage.
- Support for color and texture tiling and HyperZ features of Radeon.

Thanks to:	scottl (much p4 handholding)
		Jung-uk Kim (helpful prodding)
PR:		[1] kern/76879, [2] kern/72548
Submitted by:	[1] Alex, lesha at intercaf dot ru
		[2] Shaun Jurrens, shaun at shamz dot net
2005-04-16 03:44:47 +00:00