sarea_priv needs to be NULL before i915_initialized is called to
properly reset it. The stale value produces a panic any time something
opens/closes drm without calling initialize. i.e. version checking
This makes our handling of cliprects sane. drm_clip_rect always has exclusive
bottom-right corners, but the hardware expects inclusive bottom-right corners,
so we adjust this here.
This complements Michel Daenzer's commit 57aea290e1e0a26d1e74df6cff777eb9f038f1f8
to Mesa. See also http://bugs.freedesktop.org/show_bug.cgi?id=16123 .
This is around 3x or so speedup, since we would read wide rows at a time, and
clflush each tile 8 times as a result. We'll want code related to this anyway
when we do fault-based per-page clflushing for sw fallbacks.
DRAW_INDEX writes a vertex count to VAP_VF_CNTL. Docs say that behaviour
is undefined (i.e. lockups happen) when this write is not followed by the
right number of vertex indices.
Thus we used to do the wrong thing when drawing across many cliprects was
necessary, because we emitted a sequence
DRAW_INDEX, DRAW_INDEX, INDX_BUFFER, INDX_BUFFER
instead of
DRAW_INDEX, INDX_BUFFER, DRAW_INDEX, INDX_BUFFER
The latter is what we're doing now and which ought to be correct.
This resolves a panic on FreeBSD which was caused by trying
to re-initialize the swap lock. It's just much easier to
initialize all of the locks at load time. It should also
ensure that the vblank structures are available earlier.
Thanks to the reworked vblank-rework, we can just use the hardware frame
counter directly, and make the RADEON_PARAM_VBLANK_CRTC getparam just return
what was set by the corresponding setparam.
Remove the unused (and broken) "in vblank" code now that the core has
been fixed to use a counter while interrupts are enabled. Also make the
vblank pipe get/set ioctls into dumb stub functions, since with the new
code we can no longer let userspace control whether vblank interrupts
are enabled, or the core code will misbehave.
modifications to make it work correctly on my test hardware (altered the
backlight write function, made it enable the legacy backlight controller
interrupts on mobile hardware, sorted the interrupt function so we don't
get an excessive number of vblank interrupts). This lets the backlight
keys on my T61 work properly, though there's a 750msec or so delay
between the request and the brightness actually changing - this sounds
awfully like the hardware spinning waiting for a status flag to become
ready, but as far as I can tell they're all set correctly. If anyone can
figure out what's wrong here, it'd be nice to know.
Some of the functions are still stubs and just tell the hardware that
the request was successful. These can be filled in as kernel modesetting
gets integrated. I think it's worth getting this in anyway, since it's
required for backlight control to work properly on some new platforms.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Various chips have exciting interactions between the CPU and the GPU's
different ways of accessing interleaved memory, so we need some kernel
assistance in determining how it works.
Only fully tested on GM965 so far.
Alex Deucher
Mihail Zenkov
Ben Skeggs
Robert Noland
Stephane Marchesin
Dave Airlie
vehemens
root
Maarten Maathuis
Eric Anholt
Stuart Bennett
Dave Airlie
Nicolai Haehnle
Michel Dänzer
Jesse Barnes
Hong Liu