| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
Switch relocs to using copy from user and remove index and pass buffer
handles in instead.
|
|
Should use vtotal not htotal to figure out if we're in a vblank period.
|
|
One to many parantheses...
|
|
|
|
|
|
|
|
The frame count registers don't increment until the start of the next
frame, so make sure we return an incremented count if called during the
actual vblank period.
|
|
Ack the IRQs correctly (PIPExSTAT first followed by IIR). Don't read
vblank counter registers on disabled pipes (might hang otherwise). And
deal with flipped pipe/plane mappings if present.
|
|
Conflicts:
linux-core/drmP.h
linux-core/drm_drv.c
shared-core/i915_drv.h
shared-core/i915_irq.c
shared-core/mga_irq.c
shared-core/radeon_irq.c
shared-core/via_irq.c
Mostly trivial conflicts.
mach64 support from Mathieu Bérard.
|
|
This reverts commit bfc29606e4a818897eebca46a5e23bbe7bc3ce25.
This regresses i915 here for me I can't get greater than 0.333 fps with gears
|
|
|
|
|
|
|
|
i915_flush_ttm was unconditionally executing a clflush instruction
to (obviously) flush the cache. Instead, check if the cpu supports
clflush, and if not, fall back to calling wbinvd to flush the entire
cache.
Signed-off-by: Kyle McMartin <kmcmartin@redhat.com>
|
|
|
|
This adds new chipset id in drm.
Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com>
|
|
|
|
|
|
Add rom (only combios for now) parsing and use informations
retrieve instead of hardcoded table. Shuffle code around a
bit.
|
|
This avoids a sync flush when user-space has already programmed
and MI_FLUSH in the batchbuffer.
|
|
|
|
(1 << bits) is an undefined value when bits == 32.
gcc may generate 1 with this expression
which will lead to an infinite retry loop in
drm_ht_just_insert_please.
Because of the different implement of hash_long,
this issue is more frequenly see on 64 bit system
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yes, I'm quite aware "real" nv04 doesn't support this, hopefully the GPU
will just ignore those PGRAPH_DEBUG_3 bits on that hw.
|
