| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The UINT16LE_TO_CPU(), etc., macros are used in the AtomBios code to
fix up endian issues but they do not address bad alignment or assist
architectures that cannot perform hardware byte or word accesses.
This patch inserts use of the ldw_u(), etc., interface of the Xserver
into certain AtomBios accesses to address alignment issues.
This resolves Debian bug 572311, namely that the driver when compiled
for generic Alpha architecture (i.e. doesn't use the byte-word extension)
resulted in no display output on certain Radeon cards.
Signed-off-by: Michael Cree <mcree@orcon.net.nz>
|
|
Noticed by Pauli and Michel on IRC.
Improves GetImage performace by a factor of ~10.
|
|
|
|
Based on my initial non-working patch.
Fixes some element of fdo bug 12007
|
|
Basically a port of my kms patch. This allows us
to remove some quirks.
|
|
It doesn't seem to be used anywhere, so don't require it.
CC: Jerome Glisse <jglisse@redhat.com>
CC: Alex Deucher <alexdeucher@gmail.com>
CC: Dave Airlie <airlied@redhat.com>
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
fixes fdo bug 26897
|
|
|
|
|
|
|
|
rv740 pipe setup was fixed in 2.6.33
|
|
Also fix some RADEON_ALIGN(x, 63), which would return incorrect results
for odd x. Though this shouldn't happen, it's still not right. You
wouldn't ever write (x + 62) & ~62 which is clearly wrong (and what it
expands to).
CC: Jerome Glisse <jglisse@redhat.com>
CC: Alex Deucher <alexdeucher@gmail.com>
CC: Dave Airlie <airlied@redhat.com>
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
Also, define RADEON_BUFFER_ALIGN in terms of it, and replace some
RADEON_ALIGN(x, RADEON_BUFFER_ALIGN) with RADEON_ALIGN(x,
RADEON_GPU_PAGE_SIZE) since this is really what was intended.
CC: Jerome Glisse <jglisse@redhat.com>
CC: Alex Deucher <alexdeucher@gmail.com>
CC: Dave Airlie <airlied@redhat.com>
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
|
|
|
|
Taken from James patch on bug 24523
agd5f: adapt to the current code
|
|
Now that the screen section mapping is fixed,
Make the option per-instance and allow multiple
outputs to be specified; e.g., DVI-0 and HDMI-0
associated with instance 0 and LVDS and VGA-0
associated with instance 1.
|
|
Each screen needs to have a pointer back to its
device's entity instance, Currently Screen1 is
pointing to Screen0's instance so when it comes
to match up the screen sections with the detected
screens, Screen0 gets chosen in both cases.
See bug 24523
|
|
Needed for systems with more than two outputs.
Both KMS and non-KMS zaphod work on systems with
more than two outputs now.
|
|
|
|
matches previous behavior
|
|
- add support for pre-avivo chips
- add support for fixed post/ref dividers
- add support for non-fractional fb dividers
By default avivo chips use the new algo and
pre-avivo chips use the old algo. Use the
"NewPLL" option to toggle between them (set to
TRUE for the new algo, FALSE for the old).
|
|
System lists DVI port as HDMI.
fixes fdo bug 26605
|
|
In KMS world each cs need to fully initialize the 3D engine
when we were erasing cs in IBDiscard for r6xx we weren't
forcing reemission of default state. This patch force this
emission. Fix :
http://bugs.freedesktop.org/show_bug.cgi?id=26603
http://bugzilla.kernel.org/show_bug.cgi?id=15284
|
|
Allows users that want to use zaphod mode to select
which xrandr outputs are assigned to which head. E.g.,
Option "ZaphodHeads" "LVDS,VGA-0"
will assign LVDS to the first zaphod driver instance
and VGA-0 to the second instance.
|
|
The wrong order prevented tearing avoidance from working with EXA/DRI2.
|
|
I think these can only really work in VRAM, though right now there's probably
nothing to prevent them from getting evicted...
|
|
KMS doesn't have acceleration for upload to vram. memcpy/memmove to VRAM
directly is very slow (40M/s in benchmark) which causes visible problems
to video.
Allocating video buffer in GTT will give good performance (350-450M/s)
for memmove operation. This is nice performance boost for Xv under KMS.
Signed-off-by: Pauli Nieminen <suokkos@gmail.com>
|
|
memcpy has about 25% better performance than memmove when
destination is GTT (wc caching). Changing memmove to memcpy
in SwapCopy will reduce CPU time spent moving data between
host and GPU.
memcpy will specially help Xv when playing high resolution
videos.
The swap path doesn't support overlapping memory copies either
so extra safety is not worth the performance hit in commonly
used code path.
Signed-off-by: Pauli Nieminen <suokkos@gmail.com>
[ Michel Dänzer: Fixed up whitespace ]
|
|
|
|
Use the Xv version as it takes into account the area
covered by the op rather than just picking the largest
crtc area.
|
|
fixes fdo bug 26445
|
|
backport from a KMS fix, the rs400/480 mc idle is bit 2 not bit 4.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This module does not generate LINUXDOC documentation.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
|
|
both link and encoder must be set for linkb
|
|
We don't need to flush so often. Next step
would be to move the flushing to the drm and only
flush after each command buffer rather than each
draw.
|
|
DP CRTC clock always comes from DCPLL. This frees
up PPll1/2 for non-DP-mode PHYs and CRTCs
|
|
|
|
SetPixelClock needs to be called for DP outputs with a
valid PLL.
|
|
|
|
|
|
|
|
|
|
analog is already supported by the existing code.
|
|
|
|
|
|
|
|
|
|
|
