Commit Graph

21 Commits

Author SHA1 Message Date
Robert Noland
9c03c0d88c Rework how drm maps are handled.
* On 32 bit platforms we steal the upper 4 bits of the map handle
   to store a unique map id.
 * On 64 bit platforms we steal the upper 24 bits.

Resolves issues where the offsets that are handed to mmap may overlap the VRAM on some cards.

Tested on: radeon, intel, mga, and via.

This will break nouveau.  I will spin new patches shortly.
2010-04-22 18:21:25 +00:00
Robert Noland
3db57ca311 We shouldn't need to drop and reaquire the lock here.
MFC after:	3 days
2009-06-25 19:23:25 +00:00
Robert Noland
e23637d17b The G45 docs indicate that all G4X chips use the new framecount register.
Intel agrees with my reading of the docs, make it so for all G4X chips.

The new register also has a 32 bit width as opposed to 24 bits.  Fix
things up so that the counters roll over properly.

MFC after:	3 days
2009-06-20 16:45:14 +00:00
Robert Noland
a13575a303 Intel handled the management of the breadcrumb counter inconsistently.
Make sure that we always handle it the same way.

MFC after:	3 days
2009-03-25 01:44:16 +00:00
Robert Noland
324a23e9a2 Sync up the rest of the code that we use with what Intel is shipping
-Some irq/vblank related changes that hopefully will help.
	-A little more cleanup while I'm here.

MFC after:	3 days
2009-03-19 08:28:36 +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
23b90efbcf The GM45 handles vblank differently. Pull the changes from Intel in.
MFC after:	2 Weeks
2009-02-25 20:24:13 +00:00
Robert Noland
dc5c632deb This was part of a sync to the code that Intel is shipping in linux.
- Remove the old TTM interface
	- Move register definitions to i915_reg.h
	- Overhaul the irq handler

MFC after:	2 weeks
2009-02-25 18:44:50 +00:00
Robert Noland
c148ca706e The vblank_swap ioctl was fundamentally race prone. Get rid of it.
MFC after:	2 weeks
2009-02-25 18:22:57 +00:00
Robert Noland
c85e91464a Don't report GEM capability until we actually have GEM support.
This was causing the newer Intel video drivers to fail and abort X.

Approved by:	jhb (mentor)
2008-10-27 21:16:07 +00:00
Robert Noland
bee8d4f213 drm/i915: fix ioremap of a user address for non-root (CVE-2008-3831)
Olaf Kirch noticed that the i915_set_status_page() function of the i915
kernel driver calls ioremap with an address offset that is supplied by
userspace via ioctl. The function zeroes the mapped memory via memset
and tells the hardware about the address. Turns out that access to that
ioctl is not restricted to root so users could probably exploit that to
do nasty things. We haven't tried to write actual exploit code though.

It only affects the Intel G33 series and newer.

Approved by:	bz (secteam)
Obtained from:	Intel drm repo
Security:	CVE-2008-3831
2008-10-25 16:29:28 +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
0020a2cded We should never call drm_pci_alloc() while holding locks, due the the
calls to bus_dma.  There were multiple paths that held different locks or
no locks at all. This patch ensures that all of the calling paths drop
their lock(s) before calling drm_pci_alloc().

Reviewed by:	kib
2008-09-09 02:05:03 +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
Remko Lodder
5f185dbd84 Add the i915 GME device to DRM.
PR:		kern/121808
Submitted by:	Volker Werth <volker at vwsoft dot com>
Approved by:	imp (mentor, implicit for trivial changes)
MFC after:	3 days
2008-03-21 16:38:42 +00:00
Konstantin Belousov
046ea980e1 Properly initialize the dev_priv before calling the i915_dma_cleanup().
This fixes my rev. 1.5.

Reviewed by:	anholt
Approved by:	re (kensmith)
MFC after:	2 weeks
2007-08-21 12:52:57 +00:00
Konstantin Belousov
73f37bf31a bus_dma_tag_create() and bus_dma_mem_alloc() shall not be called with a
non-sleepable lock held. drm_pci_alloc() calls them, thus drm mutex shall
not be held during the call.

Move the drm_pci_alloc() to the start of the i915_initialize() and drop the
the drm mutex around it.

Reported by:	Ganbold <ganbold micom mng net>
Reviewed by:	anholt
Approved by:	re (hrs)
MFC after:	1 week
2007-07-12 09:02:31 +00:00
Eric Anholt
90e545e597 Merge from DRM upstream:
- Add support for Intel 965 Express chipsets.
- Add support for R200 vertex programs, along with minor bugfixes.
- Add support for vblank synchronization to pipe B of Intel hardware
  (laptop screens).
2006-09-07 23:04:47 +00:00
Eric Anholt
72ab0eff0f Update to DRM CVS as of 2006-04-09. The most notable new feature is the updated
Radeon memmap code, which with a new DDX driver and DRI drivers should fix
long-term stability issues with Radeons.  Also adds support for r200's
ATI_fragment_shader, r300 texrect support and texture caching fixes, i915
vblank support and bugfixes, and new PCI IDs.
2006-04-09 20:45:45 +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