It was the same code as for RADEON_HOST_DATA_SWAP_32BIT. This caused bus errors
on FreeBSD/PPC, but I'm not sure how it could not cause problems anywhere...
Reported-by: Andreas Tobler <andreast@fgznet.ch>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Due to some old kernel issue, height is 8 aligned insided the ddx
For buffer with height btw 57 & 63 this lead ddx to believe it can
allocate a 2D tiled surface while mesa will not align height and
will assume 1D tiled leading to disagreement and rendering issue.
This patch force buffer with height < 64 to be 1D tiled.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
If Mesa set it to 1, the DDX would not render anything = the monitor would
basically freeze.
agd5f: update emit count as well.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Deferring this could result in trying to unreference buffers from a previous
server generation, i.e. accessing freed memory.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Christian König <Christian.koenig@amd.com>
The sam440ep PPC board requires a ConnectorTable xorg.conf option, but putting
in that option causes the radeon driver to crash. I finally traced it to a
copy-and-paste bug in radeon_output.c as a result of a major rework in commit
82f12e5a40.
The actual crash occurred in RADEONPrintPortMap().
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
make sure the division is done with floats, otherwise the coordinate
can be wrong up to 1 texel.
Particularly visible with clipping and small source scaled up (since one
texel can be a shift of several pixels) but could be seen even unscaled.
Should provide more accurate coords without clipping too depending on the
scale factor probably.
Changed for r100-r600, though only tested on r300.
Use libdrm common surface code so mesa,ddx have same idea
about tiling surface and what their pitch should be and
the alignment constraint.
v2 fix remaining issue add new option to conditionaly enable
v3 fix fbcon copy and r600 exa copy path
v4 fix non tiled path 2D tiling on GPU >= R600, set it to false
as default
v5 adapt to pixel/element size split of libdrm/radeon
v6 update to properly handle falling back to 1d tiled
v6 final fix to tile split value on evergreen and newer
v7 fix default array mode on r6xx, fix height alignment issue
on evergreen
v8 fix tile split value
v9 add stencil tile split support, simplify dri2 for stencil
with evergreen
v10 Try to fix xv path regarding tiling. Adapt to libdrm API
change. Try to fix case where there is no surface which
means non tiled bo.
v11 check for proper libdrm
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
The range passed in is in pixmap coordinates, so the CRTC offset needs to be
added to the clamping limits and subtracted from the clamped range for
pre-AVIVO display engines.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The clamping could turn a previously non-empty range into an empty one.
Also, start == stop means the range is empty.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Need to use GXCopy for the src to temp copy, then
the original rop for the temp to dest copy.
Noticed by: Frank Huang
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
RADEONRestore() calls crtc->funcs->dpms() after most of the mode setting
subsystems have been restored. This function enables the CRTCs but does
more: it calls DRM pre- and post-modeset ioctls and sets up the palettes
(LUTs).
None of these two things are needed. Accessing the palette registers after
restoring the PLLs can even lead to lockups.
Thus the CRTC DPMS function is split into two parts: one that just enables
/disables the CRTC and one which wraps this function and does the rest.
Now the inner function can be called directly from RADEONRestore() as
there is no need to go thru the RandR hooks in this function while the
RandR hook uses the wrappering function so the full functionality is
preserved from an RandR point of view.
Signed-off-by: Egbert Eich <eich@freedesktop.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
The reintroduction of palette save/restore in 5efdf514 causes some
pre-AVIVO chips to lock up. An investigation revealed that accessing
palette registers when the associated PLL is not running is causing
this. With UMS the PLL setup that is saved has been done by the BIOS
typically.
A similar issue was observed when VGA palette save/restore had
been reinitroduced with 80eee856:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480312
and has been worked around for Linux without further investigation
by 87e66ce7.
To fix the issue we now
a. introduce 'on-demand' palette saving (ie the palette is
saved before it is first altered). This guarantees that
the palette register are only associated when the associated
CRTC is active and thus the PLLs are powered up and running.
b. move palette restore before PLL restore.
c. eliminate generic VGA palette save/restore which seems to be
unneeded when the palette is restored natively.
It is believed that this caused the behavior described in
https://bugs.freedesktop.org/show_bug.cgi?id=18407#c27
Signed-off-by: Egbert Eich <eich@freedesktop.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
since the driver would call RRFirstOutput without checking if randr has
been enabled, and it would crash in privates code.
reported by vereteran on #radeon
Signed-off-by: Dave Airlie <airlied@redhat.com>
Acked-on-irc-by: Michel Dänzer <michel.daenzer@amd.com>
The constants are written directly into a buffer object shared with the
card and we "forget" to swap them. This patch fixes it by doing the swap
in evergreen_set_alu_consts() in-place (ie, it modifies the buffer),
which should be fine with the way we use it in the ddx.
This makes everything work fine on my caicos card on a G5 including some
quik tests with Xv, gnome3 shell, etc...
Thanks a lot to Jerome Glisse for holding my hand through debugging that
(and finding the actual bug).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
DRM's hard limit to the number of CRTCs is 32. ATI DDX unnecessarily
clips this limit to 6 by hard coding initial assumption for
output->possible_crtcs mask to 0x7f (before it gets trimmed down to
what's really possible for a given output) and by allocating only 6
entries for for cursor_bo[] array in RADEONInfoRec.
Fix this and thus allow the ATI DDX to deal with as many CRTCs
as the DRM allows (32), so it is ready if anything with >6 CRTCs
comes out.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
