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@

The drm_* allocation functions have been #defined to not use most of
their arguments for a while. Actually go through the code and remove the
extraneous arguments. Makes things easier to read.

convert drm_scatter code over to using the new dmamem api.

removes the custom code in there, so shrinks the kernel by a few bytes.
Convert other code to deal with data structure changes.

pass in the dmat when we attach the drm driver. reduces pci dependancy.

detypedef some more. No functional change.

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

Check for zero in drm_calloc() to prevent divide-by-zero. Also rearrange
the two calls to drm_calloc() that had nmemb and size the wrong way
around.

Switch all instances of malloc/free in the DRM to drm_alloc, drm_free
and drm_calloc.

With the recent change to check overflow in drm_calloc, this means that
all allocations that require multiplicat

Switch all instances of malloc/free in the DRM to drm_alloc, drm_free
and drm_calloc.

With the recent change to check overflow in drm_calloc, this means that
all allocations that require multiplication are now checked. Also use
drm_calloc() when zeroing is needed and drop the bzero/memset
afterwards. Finally, make drm_free() check for NULL, so we don't need
to do so every time.

ok miod@, deraadt@

show more ...

Don't try to free a non-malloced address. Somehow this bit of code escaped
deletion when i killed the ifdefs around it.

Problem noticed by Jason Meltzer and ckuethe@, thanks!

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 ...

Kill the rest of the ifdef maze in drm_*.c

I was going to do this per file, but decided all it would achieve was
artificially increasing my commit count.

>Kill the ifdef maze. I've been considering

Kill the rest of the ifdef maze in drm_*.c

I was going to do this per file, but decided all it would achieve was
artificially increasing my commit count.

>Kill the ifdef maze. I've been considering doing this for months, it
>doesn't make getting changes to and from upstream much easier, and just
>makes the code hard to read.

show more ...

The mmap offsets for memory buffers currently are the kernel virtual
address. This is just plain wrong. scatter/gather on amd64 didn't work
here, since char device mmap doesn't take negative offsets

The mmap offsets for memory buffers currently are the kernel virtual
address. This is just plain wrong. scatter/gather on amd64 didn't work
here, since char device mmap doesn't take negative offsets so higher
kvas fail.

Instead, prematurely import drm_memrange which is needed for the memory
managers (GEM or TTM), and is used to manage GART space. Then, horribly
abuse it to allocate mmap offsets, fixes up the issues.

"just commit it" art@.

show more ...

Kill vtophys in drm.

The code we inherited from FreeBSD used vtophys is a fair few places,
nuke that and replace with bus_dma. technically _DRM_SHM should be
managed with uao_create(), but until we

Kill vtophys in drm.

The code we inherited from FreeBSD used vtophys is a fair few places,
nuke that and replace with bus_dma. technically _DRM_SHM should be
managed with uao_create(), but until we move away from mmap and into an
ioctl to map, this will do.

This also paves the way for amd64 support (it lacks vtophys).

ok kettenis, miod looked at it a while back too.

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 ...