rs690 is r3xx 3D engine with AVIVO modesetting so we need to allow
AVIVO register for vline synchronization. This add a specific table
to rs690 to handle that. Thanks to Marc (marvin24) for debugging
this and kudos to Andre (taiu1) for spotting the origin of the bugs.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
we should align the GTT after VRAM no matter what, as we can
come back from resume and put in a different place and bad things happen.
Signed-off-by: Dave Airlie <airlied@redhat.com>
GTT object can either be cached,uncached or wc just let core ttm
pick the best mode according to how the bo driver and GTT memory
type was initialized.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Check whether index is within bounds before grabbing the element.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The incorrect size caused benchmark results to be inflated by a factor of 4.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If enabled, during initialization BO GTT->VRAM and VRAM->GTT GPU copies are
tested across the whole GTT aperture.
This has helped uncover the benchmark copy size bug and verify the maximum
aperture size supported by the AGP bridge in my PowerBook.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Blocking here isn't something the X server mouse appreciates,
avoid the block and let userspace retry the waits.
libdrm_radeon userspace library is also expecting EBUSY not ERESTART
Signed-off-by: Dave Airlie <airlied@redhat.com>
If an rn50/r100/m6/m7 GPU has < 64MB RAM, i.e. 8/16/32, the
aperture used to calculate the MC_FB_LOCATION needs to be worked
out from the CONFIG_APER_SIZE register, and not the actual vram size.
TTM VRAM size was also being initialised wrong, use actual vram size
to initialise it.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Previously we were basically always setting the GTT and VRAM flags regardless of
what userspace requested.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise if there's no GTT space we would fail the eviction, leading to
cascaded failure.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is done later in radeon_object_list_unvalidate(). Doing it twice triggers
a BUG in TTM, rendering X on KMS unusable until reboot.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fix bandwidth computation and crtc priority in memory controller
so that crtc memory request are fullfill in time to avoid display
artifact.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds new set/get tiling interfaces where the pitch
and macro/micro tiling enables can be set. Along with
a flag to decide if this object should have a surface when mapped.
The only thing we need to allocate with a mapped surface should be
the frontbuffer. Note rotate scanout shouldn't require one, and
back/depth shouldn't either, though mesa needs some fixes.
It fixes the TTM interfaces along Thomas's suggestions, and I've tested
the surface stealing code with two X servers and not seen any lockdep issues.
I've stopped tiling the fbcon frontbuffer, as I don't see there being
any advantage other than testing, I've left the testing commands in there,
just flip the fb_tiled to true in radeon_fb.c
Open: Can we integrate endian swapping in with this?
Future features:
texture tiling - need to relocate texture registers TXOFFSET* with tiling info.
This also merges Michel's cleanup surfaces regs at init time patch
even though it makes sense on its own, this patch really relies on it.
Some PowerMac firmwares set up a tiling surface at the beginning of VRAM
which messes us up otherwise.
that patch is:
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Allows us to hit dot clocks much closer, especially on
chips with non-27 Mhz reference clocks like most IGP chips.
This fixes most flickering and blanking problems with
non-exact dot clocks on these chips.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is needed when using fractional feedback dividers on some IGP
chips.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
RN50/ES1000 is a cut-down rv100 chip used in the server market.
The 3D engine on these is either not there or unverified so refuse
any attempt to configure registers on it.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Doing this like the DDX seems like the most sure fire way to avoid
having to reinvent it slowly and painfully. At the moment we keep
getting things wrong with aper vs vram, so we know the DDX does it right.
booted on PCI r100, PCIE rv370, IGP rs400.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This add support for using dma32 memory on gpus that really need it.
Currently IGPs are left without DMA32 but we might need to change
that unless we can fix rs690.
Signed-off-by: Dave Airlie <airlied@redhat.com>
For now handle it via r/g/b offsets and disallow 16 bpp modes on big endian
machines.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
On powerpc, since we aren't using any hw swappers, this will
get flipped around by default in hw.
tested on a G5 + rv515.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Noticed by Rafał Miłecki on dri-devel. On r6xx/r7xx hardware, laptop
panels can be driven by KLDSCP_LVTMA or UNIPHY.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The line mux for the connector in the bios tables
is used for enumerating drm connectors. Since
this laptop has a quirk where the same line much is
listed for both VGA and LVDS, the connectors get
combined. Setting the line mux on LVDS to an unused
value prevents both encoders from being combined into
the same connector. This should fix bko bug 13720.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Userspace sends us a special relocation type to sync video/exa
to vlines to avoid tearing, this deals with the relocation
in the kernel, it picks the correct crtc and avoids issues
where crtcs are disabled.
This version also parses the wait until to make sure it isn't
trying to do anything evil.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Normally we are free to place VRAM where we want in the GPUs
memory address space, however on IGP chips the VRAM is actual RAM,
and no special translation or aperture is used inside the GPU MC.
So when you move the VRAM aperture away from the TOM register,
you actually move it into main memory and can trash things quite badly.
This commit makes the code respect the TOM location for MC_FB_LOCATION.
Signed-off-by: Dave Airlie <airlied@redhat.com>
The crtc and cursor offsets on the legacy chips are offset from
DISPLAY_BASE_ADDR. The code worked if display base addr was at 0,
but otherwise falls to pieces.
Signed-off-by: Dave Airlie <airlied@redhat.com>
If there is a problem then this is hiding it, we shouldn't
ever need to flush the IB. Either the buffers are:
WB - caching just works.
WC - no need to do explicit flush, the MB + readback will do it
Signed-off-by: Dave Airlie <airlied@redhat.com>
1. rv370 can accept 40-bit addresses - also at 24-bit shift not 4 bits
2. rs480 table can be in 40-bit space. - 4 bit shift for top 8 bits
3. rs480 table entries can be in 40-bit space.
Signed-off-by: Dave Airlie <airlied@redhat.com>
TTM need to be initialized before radeon if KMS is enabled otherwise
the kernel will crash hard.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
Some PowerMac firmwares set up a tiling surface at the beginning of VRAM
which messes us up otherwise.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
Might lure userspace into trying silly things otherwise.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
smem.start is a physical address which kernel can remap to access
video memory of the fb buffer. We now pin the fb buffer into vram
by doing so we are loosing vram but fbdev need to be reworked to
allow change in framebuffer address.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
For security purpose we want to make sure the userspace process doesn't
access memory beyond buffer it owns. To achieve this we need to check
states the userspace program. For color buffer and zbuffer we check that
the clipping register will discard access beyond buffers set as color
or zbuffer. For vertex buffer we check that no vertex fetch will happen
beyond buffer end. For texture we check various texture states (number
of mipmap level, texture size, texture depth, ...) to compute the amount
of memory the texture fetcher might access.
The command stream checking impact the performances so far quick benchmark
shows an average of 3% decrease in fps of various applications. It can
be optimized a bit more by caching result of checking and thus avoid a
full recheck if no states changed since last check.
Note that this patch is still incomplete on checking side as it doesn't
check 2d rendering states.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It hasn't been used in ages, and having the user tell your how much
memory is being freed at free time is a recipe for disaster even if it
was ever used.
Signed-off-by: Eric Anholt <eric@anholt.net>
