- we have to DRM_LOCK()/DRM_UNLOCK(), thus s/rad_dev/dev/ in a variable name
- only call into radeon_cp_{stop,resume}() if the device is active
with this my nforce4 dual core amd system is able to suspend/resume with both
X and drm active.
* * *
XXX: The internal memory tracking of ACPICA, available when
ACPI_DBG_TRACK_ALLOCATIONS is defined, has been removed
from ACPI_DEBUG.
This is due to the instability of the ABI of ACPICA.
If the memory tracking is enabled, ACPICA will insert a header
to each memory allocation. As a consequence, when ACPI specific
code is loaded as a kernel module and the running kernel has
been compiled with ACPI_DEBUG, the result is an instant panic.
This happens because of unaligned memory access when the code
tries to use ACPI_FREE for a buffer obtained via ACPI_ALLOCATE,
AcpiEvaluateObject(), and related calls.
If the involved memory statistics are required, a separate constant
ACPI_DEBUG_ALLOC is available in options(4) for ACPI_DEBUG kernels.
* * *
Discussed with, and ok'ed by, jmcneill@ and pooka@.
and non-const types, and the kernel uses both const and non-const
PMF qualifiers and device suspensors, so change the pmf_qual_t and
device_suspensor_t typedefs from "pointers to const" to non-pointer,
non-const types.
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.
