| Age | Commit message (Collapse) | Author |
|---|
|
ok oga@
|
|
- rework auich_halt_pipe() and use it to ensure AUICH_RR is
set only after DMA is halted (spec says to do so)
- rework auich_calibrate(): clear interrupt and event bits in
AUICH_STS and ensure CIV counter is not changed.
- in the interrupt handler, set LVI to (qptr - 1) rather than
the max value (bug introduced by previous commit)
All fixes are from Christopher Zimmermann <madroach at zakweb.de>,
Thanks!
tested on two different intel-based auich devices,
ok jakemsr
|
|
|
|
arithmetic shift on signed integers.
|
|
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.
|
|
- save about 26K of kernel memory by giving scsi
subsystem a hint that we won't be using more than
one lun per target;
- remove a debugging leftover.
from Mike Belopuhov <mkb@crypt.org.ru>
|
|
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.
|
|
Tested by Brad on: BCM5706, BCM5708C
Tested by me on: BCM5716 (BCM5709 PHY)
|
|
|
|
|
|
ahci_ata_cmd is called with might be the state of the xfer that
ahci set previously. this stops ahci_ata_cmd from checking the
state of ata_xfers its given, and instead trusts that atascsi is
doing the right thing.
reported and fix tested by matthew dempsky, who also did an awesome
job of tracing the problem.
|
|
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.
|
|
|
|
low-hanging splbio/splx pairs that are no longer needed and see if
this reveals any hidden scsi flaws.
ok dlg@
|
|
ok krw@
|
|
ok kevlo@, krw@
|
|
based on information in the linux driver.
ok claudio@
|
|
|
|
|
|
bus_dmamem_alloc(, BUS_DMA_ZERO);
"ok on all the ones with my copyright" marco@
|
|
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!
|
|
do not attach to the Gen2b devices yet as it is not clear wether or
not they have their own hardware revision type.
|
|
|
|
|
|
|
|
Tested (and initial tweaked diff) from Erik Mugele; thanks!
|
|
|
|
Tested (and inital patch that I tweaked) 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@
|
|
things that there really isn't a decent api for elsewhere.
Since on recent intel IGPs the gtt aperture is too big (256meg is not
uncommon) to be mapped on a kva-constrained arch like i386, introduce an agp
mapping api that does things depending on arch.
On amd64 which can afford the space (and will use the direct mapping
again soon)just do bus_space_map() on init, then parcels things out
using bus_space_subregion(), thus avoiding map/unmap overhead on every
call (this is how inteldrm does things right now).
On i386, we do bus_space_map() and bus_space_unmap as appropriate. Linux
has some tricks here involving ``atomic'' maps that are on only one cpu
and that you may not sleep with to avoid the ipi overhead for tlb
flushing. For now we don't go down that route but it is being
considered.
I am also considering if it is worth abstracting this a little more,
improving the api and making it a general MD interface.
Tested by myself on i386 and amd64 and by drahn@ (who has one of the
machines with an aperture that is too big) on i386.
|
|
Tested by Jan Stary; thanks!
|
|
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@
|
|
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.
|
