| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
MFC after: 2 weeks
|
|
|
|
|
|
|
| |
This is required for the VIA driver and at least some parts are needed
for GEM.
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces d_mmap() with the d_mmap2() implementation and also
changes the type of offset to vm_ooffset_t.
Purge d_mmap2().
All driver modules will need to be rebuilt since D_VERSION is also
bumped.
Reviewed by: jhb@
MFC after: Not in this lifetime...
|
|
|
|
| |
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
| |
- Don't bother to assign vb until we know we have enough space
- Add variables for sx2, sy2, dx2, dy2 so that these aren't
calculated over and over, also reduce chance of errors.
- Use switch to assign color/format
MFC after: 3 days
|
|
|
|
|
|
|
| |
* Fix the main loop to search all buffers before sleeping.
* Remove dead code
MFC after: 3 days
|
|
|
|
|
|
|
|
|
| |
- We don't need to check malloc return values with M_WAITOK
- remove variables that we don't really need
- cleanup the error paths by just calling drm_sg_cleanup()
- fix drm_sg_cleanup() to be safe to call at any time
MFC after: 2 weeks
|
| |
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
| |
PR: 138383
Submitted by: Patroklos Argyroudis <argp@census-labs.com>
Reviewed by: rnoland
MFC after: 1 week
|
|
|
|
|
| |
Submitted by: Artyom Mirgorodsky <man@email.com.ua>
MFC after: 3 days
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
|
|
| |
sync up with what amd is shipping.
MFC after: 1 week
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
|
|
|
| |
- max tex height is 8192
- increment src/dst by the full transfer amount
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
| |
This is needed for occulsion queries on rv530 chips.
MFC after: 2 weeks
|
|
|
|
|
|
|
| |
You will still need Mesa from git and possibly an updated DDX driver,
but this is working fairly well now.
MFC after: 2 weeks
|
|
|
|
| |
MFC after: 2 weeks
|
|
|
|
|
| |
Submitted by: Ed
MFC after: 2 weeks
|
|
|
|
| |
MFC after: 2 weeks
|
|
|
|
|
|
| |
reintroduced after HEAD is reopened for commits by re@.
Approved by: re (kib), attilio
|
|
|
|
|
| |
Approved by: re (kib)
MFC after: 0 days
|
|
|
|
|
| |
Approved by: re (kib)
MFC after: 0 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The newbus lock is responsible for protecting newbus internIal structures,
device states and devclass flags. It is necessary to hold it when all
such datas are accessed. For the other operations, softc locking should
ensure enough protection to avoid races.
Newbus lock is automatically held when virtual operations on the device
and bus are invoked when loading the driver or when the suspend/resume
take place. For other 'spourious' operations trying to access/modify
the newbus topology, newbus lock needs to be automatically acquired and
dropped.
For the moment Giant is also acquired in some key point (modules subsystem)
in order to avoid problems before the 8.0 release as module handlers could
make assumptions about it. This Giant locking should go just after
the release happens.
Please keep in mind that the public interface can be expanded in order
to provide more support, if there are really necessities at some point
and also some bugs could arise as long as the patch needs a bit of
further testing.
Bump __FreeBSD_version in order to reflect the newbus lock introduction.
Reviewed by: ed, hps, jhb, imp, mav, scottl
No answer by: ariff, thompsa, yongari
Tested by: pho,
G. Trematerra <giovanni dot trematerra at gmail dot com>,
Brandon Gooch <jamesbrandongooch at gmail dot com>
Sponsored by: Yahoo! Incorporated
Approved by: re (ksmith)
|
|
|
|
|
| |
Approved by: re@ (kib)
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
|
|
| |
The Intel 2d driver calls modeset before reinstalling the handler on
a vt switch. This means that vblank status ends up getting cleared
after it has been setup. Restore saved values for the pipestat registers
rather than just wiping them out.
MFC after: 3 days
|
|
|
|
|
|
| |
Small cleanup of the error paths while I'm here.
MFC after: 3 days
|
|
|
|
|
|
|
| |
are enabled. This should help to reduce cases where the hardware
counter reference jumps by large amounts.
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
seems rather excessive.
MFC after: 3 days
|
|
|
|
|
|
| |
represents the software counter. Don't currupt things here.
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
If an error does occur we would have left max_context with an incorrect
value.
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
|
| |
This causes sis and probably a couple of other driver to panic and fail.
Tested by: cpghost <cpghost@cordula.ws>
PR: 133554
MFC after: 3 days
|
|
|
|
|
| |
Submitted by: Maciej Cencora <m.cencora@gmail.com>
MFC after: 3 days
|
|
|
|
|
| |
Submitted by: Maciej Cencora <m.cencora@gmail.com>
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
| |
there is no reason to mess with the chip.
MFC after: 3 days
|
|
|
|
|
| |
Submitted by: Christoph Mallon
MFC after: 3 days
|
|
|
|
|
|
| |
un-cached. This got lost somewhere with all the bus_dma fixups.
MFC after: 3 days
|