summaryrefslogtreecommitdiffstats
path: root/sys/dev/pci/drm/drm_drv.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* add a size argument to free. will be used soon, but for now default to 0.tedu2014-07-121-3/+3
| | | | after discussions with beck deraadt kettenis.
* Use real parameter types for u{dv,vn}_attach() instead of void *matthew2014-07-021-3/+2
| | | | ok guenther
* reduce the diff to linux for drm pci vid/pid testsjsg2014-04-071-5/+6
| | | | ok kettenis@
* Remove and shuffle some includes to reduce their number since drmP.hmpi2014-03-251-3/+7
| | | | is included by a lot of files.
* Block userland from entering drm code (and make sure it is no longer in there)kettenis2014-03-131-11/+104
| | | | | | | | before we truly start quiescing the device and don't unblock until we've finished waking the device up. Fixes issues with suspend/resume on inteldrm(4) and perhaps radeondrm(4) as well. i"it is the right place to stall" deraadt@
* remove dri1 interfacesjsg2014-03-091-126/+19
| | | | discussed with kettenis some time last year
* Give drm(4) a console locator just like wsdisplay(4) such that we can makekettenis2014-02-231-3/+17
| | | | | | sure /dev/drm0 always matches the primary display. ok mpi@
* Get rid of the simple locks; they're lies. Also get rid of the holdingkettenis2014-01-301-132/+5
| | | | | logic for uvm objects; it's not necessary anymore as far as I can tell, at least as long as we run all this code under the kernel lock.
* drm_activate() serves no purpose; ok kettenisderaadt2014-01-201-14/+2
|
* Advertise that we provide monotonic timestamps.kettenis2013-12-211-1/+4
|
* Switch generic drm modesetting code over to Linux-style negative errnokettenis2013-12-161-28/+28
| | | | | return values. Fixes at least one bug where userland would see a negative errno value and hopefully doesn't introduce any new ones.
* Rename 'struct drm_obj' to 'struct drm_gem_object' to reduce the diffs withkettenis2013-12-051-34/+34
| | | | | | Linux. ok jsg@
* Hook up gem_open/close_object methods.kettenis2013-11-271-3/+17
| | | | ok jsg@
* Replace drm_handle_create/delete with drm_gem_handle_create/delete and makekettenis2013-11-021-79/+99
| | | | | the necessary adjustments to reference counting of GEM objects. Matches what Linux does these days.
* Unstub i915_gem_dumb_destroy() and radeon_mode_dumb_destroy().kettenis2013-10-261-22/+31
|
* drmclose: don't unref objects with a mutex locked.jsg2013-09-301-1/+3
| | | | | | | | Some free functions (radeon) grab sleeping locks. Instead when we ahve taken the object off the tree we unlock and unref, then regrab before looking again. from oga in bitrig, ok kettenis@
* implement drm_pcie_get_speed_cap_mask()jsg2013-08-271-24/+24
| | | | | non integrated radeon >= r600 parts will now try to enable PCIe 2.0/3.0 speeds when the PCIe root port advertises the relevant speeds.
* stash pci chipset and bridge tags in the drm_device structjsg2013-08-271-1/+7
|
* Add a stubbed out version of drm_pcie_get_speed_cap_mask() andjsg2013-08-261-1/+53
| | | | | enable all the code in the various radeon pcie_gen2_enable() functions. no functional change
* Add a port of the TTM and Radeon DRM code from Linux 3.8.13.jsg2013-08-121-3/+37
| | | | | | | | | | | | | | Includes kernel modesetting, framebuffer console and support for newer hardware. Firmware needs to be present for acceleration and in some cases modesetting to work. It can be installed via fw_update or manually via pkg_add. With lots of help from kettenis@ some macppc bits from mpi@ and some ttm refcount/queue bits from FreeBSD. Thanks to M:Tier and the OpenBSD Foundation for sponsoring this work.
* Another major overhaul of the inteldrm(4) GEM code, bringing us considerablykettenis2013-08-071-88/+1
| | | | | | | closer to the Linux 3.8.13 codebase. Almost certainly squashes a few more bugs. ok jsg@
* Include <uvm/uvm.h> instead of <uvm/uvm_extern.h> to make surekettenis2013-06-171-2/+2
| | | | | | "struct uvm_object" gets defined on macppc as well. ok miod@, deraadt@
* Turn the allocation of GEM objects upside down and make the driverkettenis2013-06-111-9/+32
| | | | | | responsible for allocating and freeing them. This is what Linux has been doing for a while now, and will be needed for radeondrm(4) in the near future.
* Add proper mmap(2) support for drm(4)/inteldrm(4). This changes thekettenis2013-06-071-1/+116
| | | | | | | | DRM_I915_GEM_MMAP and DRM_I915_GEM_MMAP_GTT ioctls to be compatible with Linux. This also is the first step that moves us away from accessing all graphics memory through the GTT, which should make things faster. ok tedu@ (for the uvm bits)
* Put the code manipulating scatter gather mapping for the framebuffer undermpi2013-04-221-3/+6
| | | | | | ifdef to be able to compile DRM on macppc. ok kettenis@
* Take a different approach towards framebuffer accelartion. Instead of usingkettenis2013-04-141-1/+17
| | | | | | | | | | | the blitter, scroll by double-mapping the framebuffer and reprogramming the registers that determine the first visible pixel, much in the same way as the vga text console uses the 6845. This makes scrolling very fast, and since we no longer need to issue commands to any of the rings, we can enable this when X is running and safely scroll when printing panic messages or if we've entered ddb. Testes by many.
* Fix various glitches in queue macro usage.guenther2013-04-101-2/+2
| | | | ok millert@
* Return ENOENT instead of EBADF if looking up a gem object fails.kettenis2013-04-031-2/+2
| | | | | | Return EINVAL instead of EBADF if the same object is specified twice in an execbuffer2 call. This is what Linux does.
* wire up the mode object property ioctlsjsg2013-03-221-1/+7
|
* Significantly increase the wordlist for ddb hangman,jsg2013-03-181-26/+126
| | | | | | | | | | | | | and update our device independent DRM code and the Intel DRM code to be mostly in sync with Linux 3.8.3. Among other things this brings support for kernel modesetting and enables use of the rings on gen6+ Intel hardware. Based on some earlier work from matthieu@ with some hints from FreeBSD and with lots of help from kettenis@ (including a beautiful accelerated wscons framebuffer console!) Thanks to M:Tier and the OpenBSD Foundation for sponsoring this work.
* Rework how AGP memory regions are mapped and add support for AGP bridgesmpi2012-12-061-2/+4
| | | | | | | | | | | | that do not support remapping for processor accesses. Add new functions to map/unmap/mmap agp memory and let the agp layer decides how these memory regions should be accessed. It's assumed here that the bridge does not support remapping if its aperture address is 0. This is the last diff required for having drm(4) on macppc using agp(4). Joint work with and ok kettenis@
* Instead of having yet an other option to compile the drm code without agpmpi2012-09-081-1/+9
| | | | | | | support, wrap all the agp glue with 'if __OS_HAS_AGP' in such form that it is true if the agp(4) driver is present. ok kettenis@
* Use only one macro instead of two to turn debug printf on.mpi2012-08-301-4/+2
| | | | ok kettenis@
* Rip out and burn support for UVM_HIST.oga2011-07-031-5/+1
| | | | | | | | The vm hackers don't use it, don't maintain it and have to look at it all the time. About time this 800 lines of code hit /dev/null. ``never liked it'' tedu@. ariane@ was very happy when i told her i wrote this diff.
* Remove config_activate() and DVACT_ACTIVATE. PCMCIA's the only thingmatthew2011-07-031-4/+1
| | | | | | | | that's ever used it, and it's long since been changed to use DVACT_{QUIESCE,SUSPEND,RESUME} instead. ok deraadt@, dlg@; miod@ also agreed with this idea when I brought it up a few weeks ago
* M_WAITOK cleanup of two cases:mk2011-06-171-2/+3
| | | | | | | | | | | | | | | | 1) Allocating with M_WAITOK, checking for NULL, and calling panic() is pointless (malloc() will panic if it can't allocate) so remove the check and the call. 2) Allocating with M_WAITOK, checking for NULL, and then gracefully handling failure to allocate is pointless. Instead also pass M_CANFAIL so malloc() doesn't panic so we can actually handle it gracefully. 1) was done using Coccinelle. Input from oga. ok miod.
* Add $OpenBSD$ after oga said 'go ahead and fix that'weerd2011-06-021-0/+1
| | | | 'go for it' oga@
* Some extra paranoia for if we fail to attach.oga2011-05-021-1/+2
|
* Do not use NULL in integer comparisons. No functional change.miod2011-04-071-1/+1
| | | | ok matthew@ tedu@, also eyeballed by at least krw@ oga@ kettenis@ jsg@
* Kill pmap_phys_address(), and force every driver's mmap() routine to returnmiod2010-12-261-2/+2
| | | | | | | a physical address [more precisely, something suitable to pass to pmap_enter()'sphysical address argument]. This allows MI drivers to implement mmap() routines without having to know about the pmap_phys_address() implementation and #ifdef obfuscation.
* correct some bit tests spotted by -Wparentheses in newer gcc.jsg2010-11-091-2/+2
| | | | ok oga@
* Avoid double unlocking the DRM lock in drmclose(). Caught by thematthew2010-09-211-3/+2
| | | | | | strict locking diff. ok oga@
* Support from vblank events in drm.oga2010-07-181-3/+140
| | | | | | | | | | | | | | | 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.
* Remove the drm drivers that are not enabled (and have never been so).oga2010-05-241-30/+1
| | | | | | | | | | | | | | | | | | 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.
* Right now, if anything internal changes with a uvm object, diverseoga2010-04-301-5/+1
| | | | | | | | | | | | 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.
* The locking rework/fix that I promised when I commited GEM.oga2010-04-251-37/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* DRM memory management for inteldrm(4) using the Graphics Executionoga2010-04-081-2/+463
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Manager api. This is currently disabled by default under ifdef INTELDRM_GEM (option INTELDRM_GEM in a kernel config or a patch to i915_drv.h needed to enable), mostly because the intel X driver currently in tree does not always play well with GEM and needs to be switched to UXA accelmethod (which is the only option on later drivers). While based on the intel drm code in the linux kernel this has come cleanups and some obvious behaviour changes: 1) mmap through the GTT is entirely coherent with the gpu cache, removing mappings whenever the cache dirties so you can not race with userland to write to memory at the same time as the gpu. 2) pread/pwrite access is tiling-correct, so userland does not need to tile manually (mesa has already been fixed for this a while ago). The straw that broke the camels back here was the bit17 swizzling stuff on some mobile gpus meansing that while userland did the swizzle itself, the kernel had to do *extra* swizzling, this was frankly retarded so the option was dropped. 3) there is no option to map via the cpu from userland, again due to coherency issues. 4) additional integer overflow checking in some areas. 5) we only support the newer EXECBUFFER2 command submission ioctl. the old one is not supported at all (libdrm was fixed WRT over a week ago). now the TODOs: 1) the locking is funky and is only correct due to biglock. it does however work due to that. This will be fixed in tree, the design in formulating in my head as I type. 2) there are currently no memory limits on drm memory, this needs to be changed. 3) we really need PAT support for the machines where MTRRs are useless, else drm uses quite a lot of cpu (this is a bug that continues from the older code though, nothing new). 4) gpu resetting support on other than 965 is not written yet. 5) currently a lot of the code is in inteldrm, when memory management comes to other chipset common code will be factored out into the drm midlayer. Tested on: 855 (x40), GM965 and 915 by me. 945 by armani@ and jkmeuser@, gm45 by armani@ and marco@. More testing is needed before I enable this by default though. Others also provided testing by what they tested escapes me right now. In order to test this enable INTELDRM_GEM in a kernel and add the following line to the driver section in xorg.conf (I am working on a patch to autodetect the X stuff): Option "AccelMethod" "UXA"
* Get rid of devact enum, substitute it with an int and coresponding defines.pirofti2009-10-131-2/+2
| | | | | | This is needed for the addition of further suspend/resume actions. Okay deraadt@, marco@.
* Never return nonzero in a device activate method invoked with DVACT_ACTIVATE,miod2009-08-021-1/+0
| | | | | for this prevents it to be invoked with DVACT_DEACTIVATE later. This had been sweeped some time ago already, but bad constructs crept in again.
* mechanical rename of ``priv'' to ``file_priv'' in the one function whereoga2009-06-061-18/+18
| | | | it had to be fucking different. This has been irritating me.
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.