summaryrefslogtreecommitdiffstats
path: root/sys/dev/drm
Commit message (Collapse)AuthorAgeFilesLines
...
* Add GET_PARAM support for Z pipes.rnoland2009-08-234-1/+19
| | | | | | This is needed for occulsion queries on rv530 chips. MFC after: 2 weeks
* Add kernel support for Radeon R6/7xx 3D.rnoland2009-08-237-19/+3125
| | | | | | | You will still need Mesa from git and possibly an updated DDX driver, but this is working fairly well now. MFC after: 2 weeks
* Add a read only sysctl tracking the hw.drm.msi tunable.rnoland2009-08-232-0/+5
| | | | MFC after: 2 weeks
* Clean up the handling of device minorsrnoland2009-08-234-12/+8
| | | | | Submitted by: Ed MFC after: 2 weeks
* Clean up the locking in drm_alloc_resource()rnoland2009-08-231-7/+15
| | | | MFC after: 2 weeks
* Temporarily revert the new-bus locking for 8.0 release. It will bejhb2009-08-201-8/+0
| | | | | | reintroduced after HEAD is reopened for commits by re@. Approved by: re (kib), attilio
* Add support for radeon RS880 IGP chips to drm.rnoland2009-08-123-5/+19
| | | | | Approved by: re (kib) MFC after: 0 days
* Add some additional radeon pci ids to drm.rnoland2009-08-121-0/+5
| | | | | Approved by: re (kib) MFC after: 0 days
* Make the newbus subsystem Giant free by adding the new newbus sxlock.attilio2009-08-021-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* Add support for Radeon HD 4770 (RV740) chips.rnoland2009-07-093-1/+40
| | | | | Approved by: re@ (kib) MFC after: 3 days
* We shouldn't need to drop and reaquire the lock here.rnoland2009-06-251-7/+5
| | | | MFC after: 3 days
* Some more cleanups for vblank code on Intel.rnoland2009-06-252-27/+18
| | | | | | | | | 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
* Initialize max_vblank_count earlier.rnoland2009-06-252-8/+12
| | | | | | Small cleanup of the error paths while I'm here. MFC after: 3 days
* Keep track of the hardware counter more aggressively while interruptsrnoland2009-06-251-0/+4
| | | | | | | are enabled. This should help to reduce cases where the hardware counter reference jumps by large amounts. MFC after: 3 days
* Fix one use of atomic for refcount missed in last commit.rnoland2009-06-251-1/+1
| | | | MFC after: 3 days
* Additional vblank cleanups.rnoland2009-06-251-26/+29
| | | | | | | | | 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
* Ensure that we always hold the lock when calling vblank_disable_fn()rnoland2009-06-251-0/+5
| | | | MFC after: 3 days
* Add some sysctl info so that we can see what is going on with vblanks.rnoland2009-06-231-0/+24
| | | | MFC after: 3 days
* Only release irq resources if we were actually using them.rnoland2009-06-231-4/+7
| | | | MFC after: 3 days
* Using signals for vblank events is prone to issues. There have neverrnoland2009-06-232-59/+1
| | | | | | | 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
* Given that vblanks generally occur 60 times a second, waiting 3 secondsrnoland2009-06-231-1/+1
| | | | | | seems rather excessive. MFC after: 3 days
* vblank[crtc].last represents the hardware counter while request.sequencernoland2009-06-231-1/+0
| | | | | | represents the software counter. Don't currupt things here. MFC after: 3 days
* Hold the lock while we save/restore register for suspend/resume.rnoland2009-06-231-0/+6
| | | | MFC after: 3 days
* The G45 docs indicate that all G4X chips use the new framecount register.rnoland2009-06-203-7/+8
| | | | | | | | | 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
* realloc() behaves identically to malloc when passed a NULL object pointerrnoland2009-06-201-26/+15
| | | | | | | If an error does occur we would have left max_context with an incorrect value. MFC after: 3 days
* Don't panic if drm_rmmap is called with a NULL map pointer.rnoland2009-06-201-0/+3
| | | | MFC after: 3 days
* Don't try to setup interrupts for drivers that don't support them.rnoland2009-04-191-19/+22
| | | | | | | | 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
* check offsets for R300_ZB_ZPASS_ADDRrnoland2009-04-071-2/+5
| | | | | Submitted by: Maciej Cencora <m.cencora@gmail.com> MFC after: 3 days
* Add regs required for occlusion queries supportrnoland2009-04-074-2/+11
| | | | | Submitted by: Maciej Cencora <m.cencora@gmail.com> MFC after: 3 days
* Add support for RV790 (HD 4890) asicsrnoland2009-04-031-0/+2
| | | | MFC after: 3 days
* A little more cleanup from AMD, if we don't have the right microcodernoland2009-04-032-38/+37
| | | | | | there is no reason to mess with the chip. MFC after: 3 days
* Simplify the radeon microcode loading.rnoland2009-03-312-213/+132
| | | | | Submitted by: Christoph Mallon MFC after: 3 days
* We don't know what these pages are going to be used for, they should bernoland2009-03-301-1/+1
| | | | | | un-cached. This got lost somewhere with all the bus_dma fixups. MFC after: 3 days
* Load the right microcode for RS780.rnoland2009-03-301-4/+4
| | | | MFC after: 3 days
* Fix up waiting on vblank again... This reverts a last minute change thatrnoland2009-03-261-5/+8
| | | | | | I made on the last patch, it seems to upset suspend/resume and shutdown. MFC after: 3 days
* Rework the management of vblank interrupts a bit.rnoland2009-03-251-22/+31
| | | | | | | | | | | | | | | When a vt switch occurs the irq handler is uninstalled. Interrupts and the state tracking of what was enabled/disabled wasn't working properly. This should resolve the reports of "slow windows" after a vt switch, among other things. The radeon 2d driver seems to work a bit more correctly than the Intel driver. With the Intel driver, vblank interrupts will be enabled at system startup and will only be disabled after an additional modeset (vt switch, dpms, randr event). With this patch, I am able to run glxgears synced to vblank and vt switch while it is running without ill effects. MFC after: 3 days
* Intel handled the management of the breadcrumb counter inconsistently.rnoland2009-03-252-11/+12
| | | | | | Make sure that we always handle it the same way. MFC after: 3 days
* The GART allocations are a propery of the gart, not of scatter-gatherrnoland2009-03-253-10/+9
| | | | | | memory. Track them in the appropriate structure. MFC after: 3 days
* Fix up the flags to bus_dmamem again. The man page incorrectly showedrnoland2009-03-222-10/+9
| | | | | | | the BUS_DMA_NOCACHE flags as being a valid flag for load instead of alloc. Discussed with: kib MFC after: 3 days
* vm_offset_t is unsigned, so compare of >= 0 is not needed.rnoland2009-03-201-1/+1
| | | | | | | Found with: Coverity Prevent(tm) CID: 2259 MFC after: 3 days
* Remove the DRM_ERROR to fix build. It didn't make any sense anyway.rnoland2009-03-201-2/+0
| | | | MFC after: 3 days
* Fix what appears to be a typo, and restore the registers correctly.rnoland2009-03-201-1/+1
| | | | | Found with: Coverity Prevent(tm) CID: 2454
* Don't deref dev->dev_private before checking that it exists.rnoland2009-03-201-2/+1
| | | | | | | Found with: Coverity Prevent(tm) CID: 2940 MFC after: 3 days
* Only issue the wakeup and store the counter if vblank is enabled onrnoland2009-03-201-4/+6
| | | | | | the pipe. MFC after: 3 days
* Add a couple of radeon pci ids.rnoland2009-03-201-0/+2
| | | | MFC after: 3 days
* Adjust the flags to bus_dmamem around here too.rnoland2009-03-201-7/+8
| | | | MFC after: 3 days
* Add some debugging so I can see when syscalls are being restartedrnoland2009-03-193-1/+12
| | | | | | | consistantly. After a lengthy irc discussion it seems like we shouldn't need to worry about them, but it's nice to know about. MFC after: 3 days
* Rework vblank handling to try to resolve some reports of "slow" windowsrnoland2009-03-191-19/+36
| | | | | | | | after vt switch or suspend. I can't really test this on Intel right now but I think I've heard reports of it on radeon as well. I can't break it on the radeon here. MFC after: 3 days
* Sync up the rest of the code that we use with what Intel is shippingrnoland2009-03-192-83/+111
| | | | | | | -Some irq/vblank related changes that hopefully will help. -A little more cleanup while I'm here. MFC after: 3 days
* Pull in some suspend / resume changes from Intel's codernoland2009-03-193-15/+69
| | | | | Tested by: mav@ MFC after: 3 days
OpenPOWER on IntegriCloud