"cookies" for mmap. Now the radeon driver works on amd64!
- Use bus_dma for nearly all map types (carried over from prior patch).
- Plug some lock leaks in drm_bufs.c and remove superfluous locking in
drm_add_magic() (from git).
- Lower spl of mutexes to IPL_NONE (and so are now adaptive instead of
spin mutexes), save for irq_lock which is a spin mutex at IPL_VM.
Use mutex_spin_enter()/mutex_spin_exit() for irq_lock.
ok jmcneill@
o agp_ali.c: remove unused 'agp' member from agp_ali_softc.
o drm: agp_find_device() returns 'void *', not a device_t.
o Use device_t, cfdata_t instead of struct pointers.
o Don't cast void pointers in assignments.
Revert condvar changes; there seem to be other locking issues
(independent of these changes insofar as I can tell), and it will
only complicate things for now to introduce more changes.
Argh!
- Add drm_dmamem_alloc/drm_dmamem_free to drm_memory.c to nicely wrap up
the bus_dma API.
- Start using the above in drm_pci.c.
- Add DRM_NETBSD_DMA_ADDR/DRM_NETBSD_DMA_VADDR macros.
Locking:
- Use IPL_NONE for all locks except the IRQ lock, which runs at IPL_VM.
- Use IPL_VM instead of IPL_TTY with pci_intr_establish() for consistency's
sake. These two changes seem to eliminate the presistent lockups I was
having (NetBSD-current/amd64 r300).
- Start getting rid of DRM_SPININIT/DRM_SPINUNINIT and DRM_SPINLOCK/
DRM_SPINUNLOCK ... these annoy me to no end--not to mention that they
locks may or may not be spinlocks! It's a linux frob, really.
We're way beyond merging any useful bsd-core code on a large scale, which
was the only good reason to keep them around.
Memory allocation:
- Change drm_memory.c so that it contains generally useful, memory
allocation functions using kmem(9) (mostly used by the drivers
themselves). However, I expect to use this more in the future
in the "bsd core". These functions always use KM_NOSLEEP.
The new drm_dmamem_alloc function has a wait argument which
takes DRM_DMA_WAIT/DRM_DMA_NOWAIT (defined as their bus_dma
counterparts), and honors this hint in its calls to kmem(9)
and bus_dma(9) functions.
- Got rid of these functions' "area" argument--it's been deprecated for
ages. Provide macros in drmP.h to deal with the os-independent code.
- Declare these functions inline -- I believe they're used enough
by the i915 and radeon drivers to justify it. Please let me know
if I am mistaken.
NOTE: With these changes, a glxgears score which was previously
~3900fps is now ~4400fps (same setup as mentioned above). I realize
that using kmem(9) could cause problems, but I can't seem to run into
any with my test setup. If anyone smells regression, please let me
know.
since udv_attach will not accept a larger offset than signed 64-bit will
provide. Not the best fix, but good enough for now -- at least an X server
will now startup and get proper mappings.
-- detypedef drm_ati_pcigart_info
-- add support for variable sized apertures in ati_pcigart.c
-- Add support for radeon IGP adapters (untested on NetBSD)
-- Update r300_reg.h to a much newer version.
-- Miscellaneous fixes in radeon_cp.c, radeon_state.c.
TODO: r300_cmdbuf.c (?)
Please report any regressions to me. While I try to make sure the
updates are somewhat coherent, our initial code base is old enough
such that it's quite difficult to be absolutely certain. I hope to
rebase the NetBSD-specific code on the BSD code at the head of GIT
within a month or two, so this will do for now.
and IPL_NONE. MUTEX_DRIVER is no longer part of the stable API. Moreover,
IPL_TTY is now IPL_VM, and this code should not be running with such a
high ipl.
While here, add DRM_PCI_DMAADDR macro so that we set handle->busaddr
in a portable way.
Next is the more difficult [annoying] part: use bus_dma(9) with
scatter/gather buffers.
Fix the bus_dma(9) use in drm_pci.c and chnage struct drm_dma_handle_t
to match it. Remove member dmaaddr from drm_dma_handle_t as well,
as I don't see it used anywhere. Compile-tested only for now; please
report any problems to me. Thanks.
Nothing done in header files, nor in dev/pci/drm (we might not want to
touch this for the sake of merging) yet. Compile tested; please let
me know if this broke anything.
change from an adaptive to spin mutex @ IPL_TTY. This seems to mitigate
or eliminate a lot of locking-related issues (such as a hang when running
glxgears under AIGLX). Tested by me and Vincent <10.50@free.fr>.
In this code, we have three locks: irq, dma, and device. If anyone has
any thoughts on how to improve this situation, e.g. by using different
lock types/priorities/soft interrupts/etc. for different locks, please
share them with me.
NOTE: I've had the best results thusfar using Mesa 7.0.2-rc1 (r300 users
could even try the r300 driver code from the master branch) and xorg-server
1.4+patches from GIT.
operator consistent in locking macros, use mb(9) for memory barrier ops
(to be replaced with bus_space_barrier(9) at a later date; this is not
necessary for x86 but might be for e.g. mips).
More to come. Try it out! It's a lot more stable now just with the
mutex(9) changes.
platforms that don't provide these services.
In drm_mmap, don't wrap the return value with atop() if we're on macppc.
While we're here, fix:
pci_intr_establish(&dev->pa.pa_pc, ...);
to:
pci_intr_establish(dev->pa.pa_pc, ...);
The former doesn't even compile on macppc, and I'm amazed that it works at
all anywhere else.
Minor modifications by me:
-use an mi device major number
-(coarsly) divided into pci card specific and less specific parts, moved
the latter to dev/drm
-renamed autoconf attributes to reflect this
Todo:
-adapt all card frontends but i915 to drm include file location
-review the mtrr change
-make the change to agp_i810.c coexist with the fix for buggy VESA
BIOSes which is commented out temporarily
-RCS IDs etc style stuff
-LKM support (rescan support for vga)
-test
