Age | Commit message (Collapse) | Author |
|
When batch buffers are executing, the ring may be stuck for a long time.
Monitor the ACTHD pointer which will show if the execution engine is
actually hung.
|
|
|
|
|
|
This function submits a gem-based execbuffer to the ring.
It doesn't work yet.
|
|
|
|
Names are just another unique integer set (from another idr object).
Names are removed when the user refernces (handles) are all destroyed --
this required that handles for objects be counted separately from
internal kernel references (so that we can tell when the handles are all
gone).
|
|
Now that drm_gem_object has a drm_driver * in it, functions don't need both
parameters.
|
|
|
|
When pinning buffers, or using execbuffer, allow the application to specify
the necessary aperture allocation alignment constraints.
|
|
mixed 32/64 bit systems need 'special' help for ioctl where the user-space
and kernel-space datatypes differ. Fixing the datatypes to be the same size,
and align the same way for both 32 and 64-bit ppc and x86 environments will
elimiante the need to have magic 32/64-bit ioctl translation code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
No solid idea about what these 2 bits do, but nv50 can now survive a few
PGRAPH exceptions just as nv40 does :)
|
|
|
|
This is possibly temporary. I can trigger an unending IRQ storm on G8x
in some circumstances, and have no idea how to handle that particular PFIFO
exception correctly yet.
|
|
Doesn't fix any issue I've seen, but is a potential issue if a FIFO IRQ
occurs during channel creation/takedown.
|
|
The IRQ handling stuff really is a mess.. On the TODO :)
|
|
|
|
I swore I'd actually do this properly and not go the horrible route
we did with nv4x, but I won't get around to it just yet with so many
*actually* interesting things to do first.. One day.
Since someone already added nv86, why not!
|
|
|
|
|
|
|
|
Turns out it's important to save/restore AR14 in particular.
|
|
|
|
Make both crtc and the command argument 32 bits to avoid any 32-on-64 compat
issues.
|
|
Enum can be of pretty much any size since C leaves the choice of size up to the implementation. So avoid using it in new interfaces like the vblank pre- & post-modeset ioctl. Thanks to hch for spotting this.
|
|
|
|
|
|
|
|
|
|
From Jesse and Zhenyu originally.
|
|
The vblank tasklet update code must build 2D blt commands with the
appropriate tiled flags.
|
|
The batchbuffer submission paths were fixed to use the 965-specific command,
but the vblank tasklet was not. When the older version is sent, the 965 will
lock up.
|
|
|
|
|
|
|
|
dude kernel moduless use kernel errors :)
this fixes an oops on init when this codepath hits.
|
|
|
|
- Note that this may not work for all nv86.
|
|
This interface was defined completely wrong, however userspace has only
ever used 4 values from it (0x1, 0x2, 0x3 and 0x6), so fix the interface to do what userspace actually expected but define new defines for new users to use
it properly.
|
|
Previously, the R300_CMD_WAIT command would write the passed directly to the
hardware. However this is incorrect because the R300_WAIT_* values used are
internal interface values that do not map directly to the hardware.
The new function I have added translates the R300_WAIT_* values into appropriate
values for the hardware before writing the register.
Thanks to John Bridgman for pointing this out. :-)
|
|
The wait functions depend on PTIMER, so write the old (incorrect, but working) values for uninitialised hw
|
|
Kernel bug 10289.
|
|
|
|
|
|
More or less a workaround for issues on some chipsets where a context
switch results in critical data in PRAMIN being overwritten by the GPU.
The correct fix is known, but may take some time before it's a feasible
option.
|