viadrm0 at vga1: VIA P4M900 / VN896
viadrm0: AGP at 0xf0000000 128MB
viadrm0: Initialized via 2.11.1 20070202
xf86-video-openchrome seems happy with it, although 3d acceleration isn't
supported on the P4M900 so I can't test that part.
("(boundary & (boundary - 1)) == 0") triggers with i915drm in recent -5 kernel
Read the comment in the code for a detailed explanation. This should be fixed
properly in the i386 bus code, but it is too intrusive to do for -5.
XXX: pullup for 5.x
all the files attached to dev->files. we check for one per "open_count"
that is above 1. could perhaps assert() that we are empty afterwards.
this fixes restarting X + drm after actually using drm.
- call drm_rmmap() in radeon_do_cleanup_cp on the two maps created
- in several vblank functions, check to make sure we have mappings
enabled before doing something that might blow up. fixes PR#41715.
with our changes and the work recently done by Arto Huusko
<arto.huusko@pp2.inet.fi> and FUKAUMI Naoki <fun@naobsd.org>.
it includes all the changes arto provided from both mesa-drm and
the r6xx-r7xx-support branch. it does not yet include code to
handle the (deleted) drm_pciids.h file, but i'll probably just
check in a generated one for now.
i have not yet merged the changes from outside this dir.
from arto's messages to tech-x11:
The important change that was needed is that drm_scatter.c was
fixed to return pointer to all allocated pages, not just the
beginning of the allocated segments.
Other changes:
- drm_scatter maps COHERENT memory
- drm_drawable: drawable handle allocation is done
inside lock
- drm_memory: when mapping "agp" memory, store offset
of mapped area, so that new requests to same offset
return the same area instead of trying to remap
and fail
- drm_vm: use bus_space_mmap for frame buffer and registers
- r600_cp.c: ioremapfree allocated gart range
- radeon_cp.c: use mtsleep
- some memset calls I had added had their args swapped,
and no memory was cleared
parameters or result where they should have been the corresponding enums.
gcc won't bitch on them but conceptually they are different and could be
stored in a different width. Compiling with pcc brought this to light.
revision 1.17
date: 2009/03/29 19:50:17; author: mrg; state: Exp; lines: +7 -7
drm_addmap():
- for _DRM_CONSISTENT mappings, keep the handle.
- use DRM_HANDLE_NEEDS_MASK()
drm_mapbufs():
- use DRM_HANDLE_NEEDS_MASK()
drm_mmap():
- use DRM_HANDLE_NEEDS_MASK()
- for _DRM_SCATTER_GATHER and _DRM_SHM, use vtophys() on the
adjusted offset. XXX
this is gets radeon working on amd64 with an older PCI 9250 card.
XXX: need to excise vtophys() usage.
XXX: need to finish porting these fixes to external.
yay! this takes care of one of the XXX's. still not quite working.
- fix a DEBUG message
- apply from sys/dev:
revision 1.20
date: 2009/01/18 10:04:35; author: mrg; state: Exp; lines: +6 -2
Don't attempt to unload a DRM device that's in use. (Note:
Unloading doesn't work right in any case -- it doesn't clean up the
sysctl tree, among other things. This code needs Work, but at least
this prevents it crashing randomly due to autounload while X is
running.) Also, fix the dependency list for radeondrm.
contributed anonymously.
revision 1.11
date: 2009/03/29 19:50:17; author: mrg; state: Exp; lines: +9 -6
drm_addmap():
- for _DRM_CONSISTENT mappings, keep the handle.
- use DRM_HANDLE_NEEDS_MASK()
drm_mapbufs():
- use DRM_HANDLE_NEEDS_MASK()
drm_mmap():
- use DRM_HANDLE_NEEDS_MASK()
- for _DRM_SCATTER_GATHER and _DRM_SHM, use vtophys() on the
adjusted offset. XXX
this is gets radeon working on amd64 with an older PCI 9250 card.
XXX: need to excise vtophys() usage.
XXX: need to finish porting these fixes to external.
however, this doesn't get radeon working on amd64 here :(
revision 1.14
date: 2009/03/29 19:39:10; author: mrg; state: Exp; lines: +4 -3
include the size in a falled allocation message.
- use BUS_DMA_ALLOCNOW in bus_dmamap_create() call
- remove a redundant check for NULL
revision 1.33
date: 2009/03/29 17:00:50; author: mrg; state: Exp; lines: +12 -4
add a comment explaining DRM_NETBSD_ADDR2HANDLE/DRM_NETBSD_HANDLE2ADDR:
* This hack strips the top bit from amd64 addresses, which avoid
* udv_attach() returning NULL for "negative" offset.
* A better hack would be to encode the offset of some kernel data
* structure..
add a new DRM_HANDLE_NEEDS_MASK macro to check whether the above need to
be applied for various mapping types (_DRM_SHM and _DRM_SCATTER_GATHER.)
also:
- use IPL_VM for now
- use a lot of bus_space
- struct drm_device now has a pointer to the device_t
revision 1.12
date: 2009/03/29 19:37:25; author: mrg; state: Exp; lines: +9 -3
XXX: for now, add the DRM_NETBSD_HANDLE2ADDR() hack in a few places.
update a debug message.
flags to the compiler so it obeys the same ABI as the rest of the kernel.
Remove the hacks used to work around the abi differences (using %s7 as
curlwp) intruduced for the binary hal.
NB: These were not imported properly. The Id RCS keyword lines were not
cleaned up, and there were no NetBSD keywords added. Perhaps Re-import
correctly?
