| Age | Commit message (Collapse) | Author |
|---|
|
ok oga
|
|
we disable the interrupt while we are handling it (this is required according to
intel) but instead of writing the version with the master enable bit back to the
Interrupt Enable Register, we wrote it to the Interrupt Indication Register, so
after the first interrupt we only got lucky due to shared interrupts when we
were after anything.
s/IIR/IMR/ on that one call and it works.
tested by guenther@ and marco@ and myself. Fixes hangs when waiting for
the chip which were unstuck by moving the mouse.
|
|
All the software state is in the xserver, so all we can do is save
restore the interrupt enable bits (which are expected to persist).
tested by sthen. ok deraadt@.
|
|
instead of accidentally writing zeros to ones that may not even exist on
the chipset we're running on.
problem noted by damien@, fix by me.
been in theo's tree a couple of days. ``commit'' deraadt@.
|
|
the x40 LCD to light up after unsuspend.
https://bugzilla.kernel.org/attachment.cgi?id=23409
https://bugzilla.kernel.org/show_bug.cgi?id=10985
ok oga
|
|
instead of a binary or. Found via lint.
ok oga@
|
|
Previously, if userland wanted to wait on a certain vertical blank, it
had to call an ioctl which slept. Now, they can ask for an even on the
drm fd, which is then read off, and can be poll(4)ed on. For dri2 this
fits better into the workflow since the fd gets added to the xserver
main loop, and replies to the dri2 clients happen upon recieving the
events.
This functionality is only used with xserver 1.8 (and for the intel
driver in our tree, this support is currently #if 0ed out due to bugs
with vblanks on 945 that are still being chased)
matthieu@ ok.
|
|
found by Clang static analyzer.
|
|
|
|
tested by stsp@.
|
|
From jcr
|
|
from brad
|
|
cpus) to inteldrm.
This mostly works, but the suspend/resume handler doesn't put the
registers back 100% (this is being worked on) and with the X driver code
that is in snapshots (and soon to be on tech) we don't do vt switch in a
100% sane way. Similarly there are some vblank issues that aren't solved
yet, but for most usage this works with the correct Xorg DDX.
tested on two x201's, a t510 and a t410 all work given the correct
userland. Suspend works once (due to crazy crap done in the ddx) but
doesn't come back the second time and text vts are screwed post suspend.
this will be fixed shortly when a non-sucky solution has been found. for now,
this allows non-vesa X on ironlake graphics and makes us the only accelerated
but non-kms OS that works on ironlake.
|
|
ok oga@
|
|
|
|
armani@ noticed that is was missing.
|
|
one we use to dump the software interrupt number).
For some strange reason noticed upstream, writeback doesn't seem to be
working for this value for use, so instad of using the get_scratch
functions, we fallback to a direct register read (more bus traffic, but
it actually works).
This is to be used by new mesa on r100 and r200 since they reworked
stuff for dri2, and we have local patches that prevent userland mapping
the registers in dri clients.
Tested by Josh Elsasser on a M9 (rv250), thanks very much to him.
|
|
Explain how an invaviant is satisfied and add an assertion to check
(never hit that one). As a side benefit clang doesn't bitch about a
possible NULL deref now.
|
|
that in the reading-only case we need only wait for all gpu writes to be
done and flushed), don't then wait for the full seqno anyway.
Found by Clang's static analyser where it flagged a dead store to the
seqno variable.
|
|
line with everything in the tree. No functional change.
I have wanted to do this for ages! More cleanup will be forthcoming.
|
|
We no longer support these paths, only memory managed mode is now allowed.
|
|
For now they are unmaintained, and work on kernel modesetting has very
large inferface changes needing to be made. Also, when the radeon driver
has been converted over, we will no longer support X with the DRI1
protocol, only DRI2.
When the upheaval has finished, these drivers may be brought back after
work to switch them to DRI2 style memory management and kernel
modesetting has been done, but until then they are unsupported and
probably broken (i know at least two of them have been reported broken
before now). ragedrm will likely come back as a component of radeon
(their interfaces are still fairly similar). The other drivers require
rewriting.
I have been threatening to do this for over a year. Discussed with
deraadt@ and matthieu@ at various points since then.
|
|
header.
Found by Clang static analyser.
|
|
fence execbuffer logic.
|
|
a fence.
This will stop the case where a newly untiled buffer that has been
reused will be execed as if it was tiled, causing havok.
Solves the PTE errors on mlarkin's 945. He has another bug that he is
currently bisecting for me which I am looking into.
|
|
fence register. Stops some chipsets crapping out during rendering.
Tested by Jan Stary; thanks!
|
|
Tested (and initial tweaked diff) from Erik Mugele; thanks!
|
|
This enabled GEM for the intel driver unconditionally. The legacy
codepaths will be removed in approximately one week since they are now
completely unused.
After discussion with matthieu@, drahn@, kettenis@ and marco@ (well,
mostly nagging from marco ;).
|
|
(reading back the relocation).
It doesn't add any real security and when we actually need to map the
buffer on demand to read/write it makes things cripplingly slow. The
correct way to make this utterly incorruptible is a radeon-kms-like
command checker to the command streams. This is on my todo list.
Thanks to drahn@ for additional testing.
|
|
this driver to work on machine with low kva and large apertures.
tested by myself and drahn@
|
|
Tested by Jan Stary; thanks!
|
|
If userland asks to allocate an object large enough that two that size
could not fit around the pinned objects, disallow it with EFBIG.
This prevents mmap of large objects that big and copying between them
putting the machine into infinite thrashing. with a patch to the ddx (on
my git branch) that allocates a non-accelerated pixmap when it gets that
return code, matthieu@s test huge image works happily when before it
DOSed the kernel.
The correct fix would be to fall back to mmaping the backing pages for
objects that big (radeondrm will need such ability anyway). This however
is a lot more complicated and I am still working out how to do it
correctly hence this commit for now.
|
|
We need a proper MI api for doing this (one which will fall back to
mtrrs if PAT is not available would be best), but for now this allows
inteldrm to use PAT if available. Big fat XXX mentioning the need for a
real api.
ok kettenis@, tedu@
|
|
places in the tree need to be touched to update the object
initialisation with respect to that.
So, make a function (uvm_initobj) that takes the refcount, object and
pager ops and does this initialisation for us. This should save on
maintainance in the future.
looked good to fgs@. Tedu complained about the British spelling but OKed
it anyway.
|
|
|
|
actually do so).
|
|
- pmap_kremove takes a va and a size, not a va range (unlike pmap_remove,
that gratuitious difference is nothing if not annoying).
- fix a memory leak of the bit 17 bitstring.
- fix the offset calculation when iterating through the dma segments.
Tested by Brandon Mercer, his machine now seems to be rock solid.
Remember kids, if a code path has not been tested fully, it does not work!
|
|
This was causing swizzling on bit 17 swizzling intel IGDs when not
needed. Thanks to Brandon Mercer for testing.
|
|
pointed out by Clang static analyser.
|
|
the one changed.
|
|
while (condition) {
do_stuff()
increment_condition /* this was missing */
}
To a for loop like it always should have been. I have no idea what I was
smoking when I wrote this function.
Fixes the crash on hardware that does bit 17 swizzling (turns out the
three I know of are all 945s) as soon as we first unbind an object.
Thank you very much to Brandon Mercer for actually managing to get me a
crash dump so i could debug this, and also for testing the fix.
|
|
libdrm bug recently.
Correct to what was intended.
|
|
accessed by the gpu or needing a flush). Since this implies that the object is
wanted, emit the flush then to save time.
Makes things a lot smoother than before in some GL applications, since
before we were claiming that object needing a flush were unbusy so the
next map stalled the gpu waiting on a flush.
From daniel vetter on intel-gfx.
|
|
conflicts.
|
|
If we just read access to some data that has been accessed by the gpu,
only sleep until the end of the gpus last write (which we track). So
instead of stalling the gpu until the last time accessed, both can read
at the same time (which is allowed and coherent as long as the right
invalidation happens).
Since we check offsets from userland before we exec a batchbuffer, this
helps 965 (with lots of read only relocations in the render path) quite
a lot.
|
|
Before, as well as being kinda nasty there was a very definite race, if
the last reference to an object was removed by uvm (a map going away),
then the free path happened unlocked, this could cause all kinds of
havoc.
In order to deal with this, move to fine-grained locking. Since uvm
object locks are spinlocks, and we need to sleep in operations that will
wait on the gpu, provide a DRM_BUSY flag that is set on a locked object
that then allows us to unlock and sleep (this is similar to several
things done in uvm on pages and some object types).
The rwlock stays around to ensure that execbuffer can have acces to the
whole gtt, so ioctls that bind to the gtt need a read lock, and
execuffer gets a write lock. otherwise most ioctls just need to busy the
object that they operate on. Lists also have their own locks.
Some cleanup could be done to make this a little prettier, but it is
much more correct than previously.
Tested very very vigorously on 855 (x40) and 965 (x61s), this found numerous
bugs. Also, the I can no longer crash the kernel at will.
A bunch of asserts hidden under DRMLOCKDEBUG have been left in the code for
debugging purposes.
|
|
these maps tend to be fairly long lived so it buys us nothing other than
code complexity.
|
|
Since this means the necessary gtt alignment may change. Nothing did
this already, so all it does it allows the code to be simpler.
idea from Daniel Vetter.
|
|
that kills gtt mappings.
In both of these case we want all writes to hit the bus before we do
whatever we're about to do.
Doesn't solve any problems that I know of but it may help.
|
|
When we disable tiling (for example whenever we free an object to out
userland cache), we stall the gpu so that we can get rid of the fence
register covering its bit of the gtt.
Instead, mark it as invalid and then free it on next use, leading to
less of a gpu stall if any. Leads to some slight performance improvement
on 8xx, 91x and 94x chipsets which are fence constrained.
|
