wireguard-openbsd/sys/dev/pci/drm/drm_lock.c, branch jd/queueboosts WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/dev/pci/drm/drm_lock.c?h=jd%2Fqueueboosts 2020-06-08T04:47:57Z update drm to linux 5.7 2020-06-08T04:47:57Z jsg jsg@openbsd.org 2020-06-08T04:47:57Z urn:sha1:c349dbc7938c71a30e13c1be4acc1976165f4630 adds kernel support for amdgpu: vega20, raven2, renoir, navi10, navi14 inteldrm: icelake, tigerlake Thanks to the OpenBSD Foundation for sponsoring this work, kettenis@ for helping, patrick@ for helping adapt rockchip drm and many developers for testing. remove dri1 interfaces 2014-03-09T07:42:29Z jsg jsg@openbsd.org 2014-03-09T07:42:29Z urn:sha1:225ce0567ec6c77c28da5b603cf8cb811ec9ec35 discussed with kettenis some time last year Add $OpenBSD$ after oga said 'go ahead and fix that' 2011-06-02T18:22:00Z weerd weerd@openbsd.org 2011-06-02T18:22:00Z urn:sha1:7b8f2f1b2060cca3b6dda516e395367053cccc4b 'go for it' oga@ Remove the drm drivers that are not enabled (and have never been so). 2010-05-24T01:19:19Z oga oga@openbsd.org 2010-05-24T01:19:19Z urn:sha1:b284d24b99bece063b69bb05dba1cdb51297f72a 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. Remove the lock_time member from the hardware lock. It's not that 2009-03-29T03:27:02Z oga oga@openbsd.org 2009-03-29T03:27:02Z urn:sha1:82beb5ca254b58acd8f2e4b57f51ab52869e067b useful, and driver shouldn't need to know about ``ticks''. Instead of using a width-1 bitfield for storing the driver capabilities 2008-11-17T00:30:41Z oga oga@openbsd.org 2008-11-17T00:30:41Z urn:sha1:5f29d815bb20f6b0ef15786d88872f199df37ff5 in the callback structure, just use a bunch of ORed together bits. This has been annoying me for ages. Remove the drm_locked_tasklet interface. The only consumer that used it 2008-11-06T14:25:21Z oga oga@openbsd.org 2008-11-06T14:25:21Z urn:sha1:b39eefee1c96c52fe6e659ce19873993f5ad32dd was the i915 vblank swap ioctl, which just went kaput. If we need to call the tasklet function on unlock, we don't need to hold 2008-11-04T16:19:54Z oga oga@openbsd.org 2008-11-04T16:19:54Z urn:sha1:8f7198c38109eecc047602e40c7522d43a649464 tsk_lock (which blocks irqs) for the whole call of the function, just when we manipulate the function pointer. Move dev->driver over to being a pointer to a const struct, instead of stupidly 2008-10-07T21:59:32Z oga oga@openbsd.org 2008-10-07T21:59:32Z urn:sha1:e6d11d110aaf3750c51038832fd39ca91ac68d0d filling in a pre-allocated one on each attach. Makes the code a bunch nicer, shrinks a kernel by about 1.5k on amd64, helps with my sanity, and paves way for later changes. Tested by a few for a couple of weeks now. Rework the drm locking to be at least halfway sane. The freebsd code 2008-09-18T15:10:57Z oga oga@openbsd.org 2008-09-18T15:10:57Z urn:sha1:a253d7a3c19cc57ae844e0fdb6d5081a1e5a1a23 held a lock over all driver ioctls in order to be ``mpsafe''. Stop lying to ourselves for a start. This code is not fully mpsafe, and should not pretend to be so. Put the locking around where it should, and rely on biglock for the rest. This will need to be fixed, but avoids some of the horrible that we have right now. Tested by many over a long time and several iterations.