update drm to linux 5.10.47

hardware support changes include
inteldrm: better support for tiger lake
amdgpu: support for navi12, navi21 "sienna_cichlid", arcturus
amdgpu: support for cezanne "green

update drm to linux 5.10.47

hardware support changes include
inteldrm: better support for tiger lake
amdgpu: support for navi12, navi21 "sienna_cichlid", arcturus
amdgpu: support for cezanne "green sardine" ryzen 5000 apu

Thanks to the OpenBSD Foundation for sponsoring this work,
patrick@ for helping adapt rockchip drm, kettenis@ and mpi@
for uvm discussions and various testers.

show more ...

update drm to linux 5.7

adds kernel support for
amdgpu: vega20, raven2, renoir, navi10, navi14
inteldrm: icelake, tigerlake

Thanks to the OpenBSD Foundation for sponsoring this work, kettenis@ for

update drm to linux 5.7

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.

show more ...

Add $OpenBSD$ after oga said 'go ahead and fix that'

'go for it' oga@

Remove the drm drivers that are not enabled (and have never been so).

For now they are unmaintained, and work on kernel modesetting has very
large inferface changes needing to be made. Also, when th

Remove the drm drivers that are not enabled (and have never been so).

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.

show more ...

Remove the lock_time member from the hardware lock. It's not that
useful, and driver shouldn't need to know about ``ticks''.

Instead of using a width-1 bitfield for storing the driver capabilities
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
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
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
filling in a pre-allocated one on each attach.

Makes the code a bunch nicer, shrinks a kernel by about 1.5k on amd64,

Move dev->driver over to being a pointer to a const struct, instead of stupidly
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.

show more ...

Rework the drm locking to be at least halfway sane. The freebsd code
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,

Rework the drm locking to be at least halfway sane. The freebsd code
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.

show more ...

Kill some unneeded defines and struct members.

Kill the stats data structures and noop some other parts. Nothing in
userland asks for these stats, and we stopped recording anything
interesting a while back.

detypedef some more. No functional change.

Apply a light paddling with the knf stick. No binary change.

Change the drm_lock*() api to take a pointer to the struct as a
parameter, this makes things a little cleaner and removes the need to
pass in the softc for some functions.

The current drm_locked_task*() code sometimes tries to sleep in an
interrupt handler.

This is bad and wrong. So change it so that if we can't immediately grab
the hardware lock, to just leave the ta

The current drm_locked_task*() code sometimes tries to sleep in an
interrupt handler.

This is bad and wrong. So change it so that if we can't immediately grab
the hardware lock, to just leave the task flagged so that we can run it
when we release the lock. The linux implementation uses a similar
scheme.

Tested by guenther@, landry@ and bernd@. Also tested by many a while
ago as part of a larger diff.

show more ...

Kill the silly ``drm_device_t'' and ``drm_file_t'' typedefs. just use
``struct drm_device'' and ``struct drm_file'' respectively. Since i'm
changing a lot of prototypes anyway, remove all parameter n

Kill the silly ``drm_device_t'' and ``drm_file_t'' typedefs. just use
``struct drm_device'' and ``struct drm_file'' respectively. Since i'm
changing a lot of prototypes anyway, remove all parameter names from
prototypes, in accordance with style(9) (and sanity).

show more ...

destatic the static functions, they only make debugging harder.
While i'm here:
remove a couple of debug printfs that shouldn't have gone in anyway.
trowel on some KNF (I really need to get around to

destatic the static functions, they only make debugging harder.
While i'm here:
remove a couple of debug printfs that shouldn't have gone in anyway.
trowel on some KNF (I really need to get around to sending some of this upstream).
remove some netbsd specific code that netbsd doesn't have anymore.

ok tedu.

show more ...

Initial import of the DRM (direct rendering manager).

This is the kernel part necessary for DRI support in X. Disabled for now
because it still has a few bugs, but now I can work on it in tree. Also

Initial import of the DRM (direct rendering manager).

This is the kernel part necessary for DRI support in X. Disabled for now
because it still has a few bugs, but now I can work on it in tree. Also
requires the requisite bits in X, which are currently under discussion
on how to deal with them with privsep. ported from a combination of the
free and netbsd implementations.

Known bugs:
1) only the first occurence of X in any session will have dri, after
that something prevents it working.
2) if the machine does not have a dri capable card, the kernel panics.
Something's up in one of the probe functions. I haven't been able to
find it though.
3) radeon cards need to be forced to use PCI mode otherwise they get
into an infinite loop.

This is known to at least kinda work with SiS, radeons in pci mode and
intel cards.

ok deraadt, kinda ok art, a few other people had a quick look.

show more ...