| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This reverts commit f51dc37d75b0b1b8e5636f8f2c201e29986517ea.
Conflicts:
tests/modedemo/demo.c
|
|
Fixup the minor number allocation scheme to use an idr and move the control
nodes up higher.
|
|
|
|
On many chipsets, the checks for DPLL enable or VGA mode will prevent the
pipeconf regs from being restored, which could result in a blank display or X
failing to come back after resume. So restore them unconditionally along with
actually restoring pipe B's palette correctly.
|
|
|
|
and fixup the demos
|
|
This reverts commit 7af1bb874d9b8b1b8760ad200cee587c41c23434.
|
|
Make sure we have enough room for all the GR registers or we'll end up
clobbering the AR index register (which should actually be harmless
unless the BIOS is making an assumption about it).
|
|
On resume, if the interrupt state isn't restored correctly, we may end
up with a flood of unexpected or ill-timed interrupts, which could cause
the kernel to disable the interrupt or vblank events to happen at the
wrong time. So save/restore them properly.
|
|
There were two problems with the existing callback code: the vblank
enable callback happened multiple times per disable, making drivers more
complex than they had to be, and there was a race between the final
decrement of the vblank usage counter and the next enable call, which
could have resulted in a put->schedule disable->get->enable->disable
sequence, which would be bad.
So add a new vblank_enabled array to track vblank enable on per-pipe
basis, and add a lock to protect it along with the refcount +
enable/disable calls to fix the race.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
since a breadcrumb may actually turn up before a corresponding fence object
has been placed on the fence ring.
|
|
|
|
|
|
|
|
And make nv30_graph_init a bit more like mmio-traces
|
|
- Moved the fix from the ddx to drm, because it seemed more appropriate.
- Don't be shy, report if it works for you or not.
|
|
sequence number may actually turn up before the corresponding fence
object has been queued on the ring.
Fence drivers can use this member to determine whether a
sequence number must be re-reported.
|
|
|
|
waiting types.
Add a "command_stream_barrier" method to the bo driver.
|
|
|
|
|
|
With some luck the drm-side will be OK now for this chipset.
|
|
bug 14289
|
|
In hibernate, we may end up calling the VGA save regs function twice, so we
need to make sure it's idempotent. That means leaving ARX in index mode after
the first save operation. Fixes hibernate on 965.
|
|
|
|
|
|
This adds support for configuring the RS690 GART.
|
|
don't disable vblank interrupts (similar to r128)
|
|
|
|
|
|
Conflicts:
linux-core/drm_bo.c
linux-core/drm_drv.c
shared-core/drm.h
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
shared-core/radeon_irq.c
|
|
Should be 0x08 rather than 0xa0, and shouldn't use typedefs.
|
|
This requires updated Mesa to handle the new relocation format.
|
|
We need to return an accurate vblank count to the callers of
->get_vblank_counter, and in the Intel case the actual frame count
register isn't udpated until the next active line is displayed, so we
need to return one more than the frame count register if we're currently
in a vblank period.
However, none of the various ways of doing this is working yet, so
disable the logic for now. This may result in a few missed events, but
should fix the hangs some people have seen due to the current code
tripping the wraparound logic in drm_update_vblank_count.
|
