| Age | Commit message (Collapse) | Author |
|---|
|
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@
|
|
ok @damien
|
|
tsleep'ing (for example waiting for the firmware to become alive)
in iwn_init.
I believe this might fix a crash reported by dhill@
This is a temporary fix until I find something better that I will
apply to my other drivers that can tsleep in if_init (wpi, run etc...)
|
|
alternatives in a same image.
|
|
|
|
A firmware must be loaded into the device to enable it though.
|
|
troubles to some people with AR9285+AR3011 combo adapters.
|
|
provisioning bits in read cap 16
|
|
|
|
ok marco@ oga@ miod@
|
|
The ones found in gnu/ left out by intention.
ok jmc
|
|
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.
|
|
enabled (it is not enabled yet.)
|
|
|
|
|
|
and they don't make any sense (the old deprecated GCC way of marking noreturn
functions is surely not what was meant here).
ok jsg@, guenther@, marco@
|
|
|
|
|
|
disks on ATI SBx00 care is mysterious but let's keep them working.
Fix tested by Josh Elsasser, submitter of PR#6365. Thanks!
ok dlg@
|
|
|
|
|
|
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.
|
|
Makes gcc4 happier.
ok deraadt@, marco@
|
|
|
|
webcam.
ok mglocker
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
