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.
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.
allocated by the AGP driver in the case of Intel chipset graphics.
This is different from the patch by Yorick Hardy circulated a while ago
in that it doesn't change the semantics of reference counting within
the (3rd-party) DRM code -- it just bypasses it.
Needless to say that it is uglier, but it eases future updates to
the DRM code because the change there is just 2 LOC.
Imo, a cleaner solution for all that would be to attach "agp" to "vga"
in the intel chipset graphics case, which better reflects how the hardware
is structured. This would still need a hack to the DRM code, but
it would be confined to childs of the "vga" device, without need for
global variables.
Since there is a variety of intel chipsets with AGP and/or builtin
graphics options, this would need a considerable testing effort.
break functionality. I've tested this on a PCIE R423 (X800).
- In drm_drv.c, check that the requested context lock matches the holder
of the lock.
- Unify radeon offset checking. (r300_cmdbuf.c, radeon_drv.h, radeon_state.c)
[Replace r300_check_offset() with generic radeon_check_offset(), which doesn't
reject valid offsets when the framebuffer area is at the very end of the card's
32 bit address space. Make radeon_check_and_fixup_offset() use
radeon_check_offset() as well.
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=7697]
NOTE: There is another AGP fix that I didn't have time to merge
that I thought might help with getting this to work on macppc.
Contact me if you're interested. Hi macallan@! ;)
radeon_cp.c, radeon_drv.h: (GIT id: bb5f2158dbd30dbbffa3881fac75b71d71ecaaf9)
- set the address to access the aperture on the CPU side correctly
[This code relied on the CPU and GPU address for the aperture being the same,
On some r5xx hardware I was playing with I noticed that this isn't always true.
I wonder if this will fix some of those r4xx DRI issues we've seen in the past.]
- Commit the ring after earch partial texture. (radeon_state.c)
(GIT ID: ac8406420ea80ffe5ccaadc1ff0124f95709a23d)
[Commit the ring after each partial texture upload blit.
This makes sure each blit starts as early as possible, which may improve
texture upload performance in some cases.]
If anyone's having any issues in particular--especially those which
can be _teased apart from AGP driver issues--please let me know
and I'll investigate. Thanks. There are also tons of fixes for the i915,
but I don't want to change too much at once.
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.
