| Age | Commit message (Collapse) | Author |
|---|
|
Add a file for memory move helpers, drm_bo_move.c
Implement generic memory move.
Cached, no_move and unmapped memory temporarily broken.
|
|
Untested...
|
|
It is still not working, but now we could use some 3D commands
without needed to run nvidia blob before.
|
|
* Pulled in some registers from nv10reg.h. Needed for context switching.
* Filled in nv30 graphics context (based on nv40_graph.c).
* Figure out nv30 context table, set up on context creation. Allows the cards automatic switching to work.
|
|
|
|
Conflicts:
linux-core/Makefile.kernel
|
|
|
|
|
|
Buffer object code.
|
|
|
|
|
|
0x00 EXE fence. Signals when command stream interpreter has reached the point
where the fence was emitted.
0x01 FLUSH fence. Signals when command stream interpreter has reached the point
where the fence was emitted, and all previous drawing operations have been
completed and flushed.
Implements busy wait (for fastest response time / high CPU) and
lazy wait (User interrupt or timer driven).
|
|
Add drm_fence.o to Makefile
|
|
|
|
fence objects and buffer objects:
Refcounting,
Inter-process sharing,
Synchronization
Destruction.
|
|
|
|
me)
|
|
|
|
suspend, and the DDX driver re-inits the board successfully anyway.
|
|
with BSD fix from jkim and the r300_reg.h license from Nicolai Haehnle.
Big thanks to everyone involved!
|
|
|
|
This is Egberts code, ported to Pauls framework by me..
|
|
|
|
the code for it, rather than introducing something that isn't going to
work 100% of the time.
|
|
radeonfb.
|
|
There's two choices when fb is or isn't loaded as we treat ourselves as a
PCI driver in the latter case.
If we are a PCI driver, then register the suspend/resume functions
directly. If not, then we register as a sysdev and pick up the
suspend/resume actions and pump them down into a generic *power
function.
It'll be nice when this little mess is sorted out with regard to being a
real PCI driver ;-/
|
|
New PCI command parser. Moved from via_dma.c to via_verifier.c so functions
with similar functionality are close to eachother.
Moved video related functions to via_video.c, which might be extended in
the future, as new video functionality is added.
New device-specific generic IRQ IOCTL, similar to the general VBLANK IOCTL,
but with support for multiple device IRQ sources and functionality.
Support for Unichrome Pro PM800/CN400 video DMA commands in verifier and
PCI parser.
Support for Unichrome Pro PM800/CN400 HQV IRQs in the new generic IRQ
IOCTL.
Bumped minor. New version 2.6.0.
|
|
|
|
implementation errors). Direct hardware (MMIO, BCI) access is no longer
needed in the Mesa driver. Bumped version to 2.0.0. Corresponding
changes to the DDX and Mesa drivers are being committed.
|
|
ring-buffer code somewhat to workaround hardware problems. Bumped via
minor version number.
|
|
|
|
|
|
|
|
|
|
edit files for 2.6 be sure and break the link to the 2.4 directory and
copy the cvs history.
|
|
files to the linux build but not to the BSD directories.
|
|
|
|
DRM_IOCTL_VIA_DMA_INIT DRM_IOCTL_VIA_CMDBUFFER DRM_IOCTL_VIA_FLUSH
The first ioctl sets up an area in AGP memory that will be used as the ring
buffer. The second ioctl copies a command buffer from user space memory
to the ring buffer. The third ioctl waits for engine idle until it
returns.
The motivation for this patch is to avoid the wait for engine idle call
before each buffer flush in the current DRI driver. With this patch,
the DRI driver can continue to flush its buffer as long as there is
free space in the ring buffer.
This patch adds an additional copy operation on the command buffer. This
buffer copying is necessary to support multiple DRI clients rendering
simultaneously. Otherwise, more CPU time will be spent in the busy loop
waiting for engine idle between DRI context switch. Even in the single
client case, the tradeoff is reasonable in comparision to the kernel
call to check for free buffer space for the client to render directly
to the ring buffer.
|
|
|
|
|
|
1. Fixed up PCI-id's.
2. Fixed 2.6 warning in kernel Makefile.
|
|
Added via_mm.o to export-objs:
Reported by: HMX, Via Arena Forum
|
|
|
|
|
|
|
|
|
|
kernel build system. This is based on suggestions and examples from
David Woodhouse. This approach has the advantage that the build
requirements of a wider range of standard kernels are now supported
transparently, but the disadvantage of some extra complexity to handle
building against clean vendor-distributed kernel source trees. This has
been tested with some recent Red Hat and SuSE distributions.
|
|
|
|
|
|
|
