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: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Need to adjust CUR_OFFSET for yorigin
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave 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: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is needed when using fractional feedback dividers on some IGP
chips.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave 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: NDave 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: NDave 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: NDave 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: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave 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: NDave Airlie <airlied@redhat.com>

If userspace sends a zero length IB, it really shouldn't have bothered
so EINVAL it.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fix this to be correct like the DDX code, looks like a typo
on transfer to the kernel.
Signed-off-by: NDave 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: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave 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: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

A bug caused a new caching state to be selected on each buffer object
validation regardless of the current caching state.
Moreover, a caching state could be selected that wasn't supported by
the memory type.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave 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: NDave 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: NDave 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: NDave 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: NDave Airlie <airlied@redhat.com>

Unsigned long is incorrect for 64-bit resources on 32-bit hw.
Signed-off-by: NDave 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: NDave Airlie <airlied@redhat.com>

Remove unused #include <linux/version.h>('s) in
 drivers/gpu/drm/ttm/ttm_bo_util.c
 drivers/gpu/drm/ttm/ttm_bo_vm.c
 drivers/gpu/drm/ttm/ttm_tt.c
Signed-off-by: NHuang Weiyi <weiyi.huang@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

TTM need to be initialized before radeon if KMS is enabled otherwise
the kernel will crash hard.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Looks like I managed to mess up most shifts when converting from bitfields. :(

The patch below works on my Thinkpad T500 (as well as on my PowerBook,
where the previous change worked as well, maybe out of luck...). I'd
appreciate more testing and eyes looking over it though.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Tested-by: NMichael Pyne <mpyne@kde.org>
Signed-off-by: NDave 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: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Might lure userspace into trying silly things otherwise.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave 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: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Sometimes both acpi video and i915 driver are compiled as modules.
And there exists the strict dependency between the two drivers.
The acpi video bus will be unloaded in course of unloading the i915 driver.
If we unload the acpi video driver, then the kernel oops will be triggered.

Add the reference count to avoid unloading the ACPI video bus twice.
The reference count should be checked before unregistering the acpi video bus.
If the reference count is already zero, it won't unregister it again.
And after the acpi video bus is already unregistered, the reference count
will be set to zero.

http://bugzilla.kernel.org/show_bug.cgi?id=13396Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Acked-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Unitialized fence register could leads to corrupted display. Problem
encountered on MacBooks (revision 1 and 2), directly booting from EFI
or through BIOS emulation.

(bug #21710 at freedestop.org)
Signed-off-by: NGrégoire Henry <henry@pps.jussieu.fr>
Signed-off-by: NEric Anholt <eric@anholt.net>

Remove wrongly added NULL_PACKETS_DURING_VSYNC setting for HDMI.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Apparently the proper way to do this is to use the LFP data pointer
block to figure out the LFP data block entry size, then use that plus
the panel index to calculate an offset into the LFP data block array.

Similar fix has already been pushed to the 2D driver to fix fdo bug
applied to the VBIOS reader, and things look sane).
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

We used load_detect_temp flag to determine whether to set tv to the test
mode. However if the TV already has a mode set, we still need to set the
test mode to determine connection.  This results in blinking, but there is
no other reliable way to determine TV connection.

freedesktop.org bug #22035
Signed-off-by: NMa Ling <ling.ma@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NKrzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NKrzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: NEric Anholt <eric@anholt.net>

Also, use the border instead of border minus one.

At the same time, make sure the horizontal border and hsync are even for
the LVDS that works in dual-channel mode. So both horizontal border and hsync
start are also changed to be even, even for the LVDS in single-channel mode.

https://bugs.freedesktop.org/show_bug.cgi?id=20951Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Previously the driver would always scale the chosen video mode to fill the
panel.  This adds 1:1 and maintain-aspect-ratio scaling modes.

v2: the drm_calloc/drm_free is replaced by kzalloc/kfree based
on Eric's suggestion.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

We need to save register state *after* idling GEM, clearing the ring,
and uninstalling the IRQ handler, or we might end up saving bogus
fence regs, for one.  Our restore ordering should already be correct,
since we do GEM, ring and IRQ init after restoring the last register
state, which prevents us from clobbering things.

I put this together to potentially address a bug, but I haven't heard
back if it fixes it yet.  However I think it stands on its own, so I'm
sending it in.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Users could accidentally enable AGP but not the Intel AGP support, and get
a DRM that doesn't probe as a result.

Bug #22358.
Signed-off-by: NEric Anholt <eric@anholt.net>

In theory now that the AGP subsystem is using struct page, we should
have on problems enabling GEM on PAE systems.
Signed-off-by: NDave Airlie <airlied@redhat.com>

just remove i variable left over from previous code.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This switches AGP to use an array of pages for tracking the
pages allocated to the GART. This should enable GEM on PAE to work
a lot better as we can pass highmem pages to the PAT code and it will
do the right thing with them.
Signed-off-by: NDave Airlie <airlied@redhat.com>