- 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.
* 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.)
devmajor_t/devminor_t, as proposed on tech-kern.
This avoids 64-bit arithmetics and 64-bit printf formats in parts
of the kernel where it is not really useful, and helps clarity.
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.
XXX: not fully enabled yet. config(1) has a makeoptions bug
with complex conditionals. see files.drm / files.pcidrm for
some instructions on how to enable it.
round_page(x) >> PAGE_SHIFT instead.
- Add bus_space_mmap() in drm_vm.c to give a proper cookie to the device pager;
this gets rid of one of the two #ifdef macppc conditionals.
"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.
- Use macros where appropriate.
- Remove code for other operating systems -- we don't need it.
- In atomic_read/atomic_set, cast to volatile.
- Misc. cleanup.
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.
mrg