Immediate readback seems faulty on some chips.  I
suspect it takes a while to get through the fifo
to the actual register backbone.  There's no need
to read it back, so, just write the driver's copy
of the register's value directly.

Should fix bug 24535 and possibly 24218
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

When we are evicting from VRAM->RAM we allocate the ttm object,
but we don't set the caching policy on it before blitting into it.
This means on AGP we end up blitting into cached pages, and
the CPU later flushes out on top of them. This was mostly seen as
font corruption.

The other question is why we don't evict VRAM->GTT in a lot of cases,
this would save us some cache transitions since a lot of objects
that are evicted from VRAM will probably end up being pulled back in
a few operations later, and evicting them to system memory involves
2 unnecessary cache transitions.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fixes suspend/resume on my rc410 motherboard, it restores
the memory controller setup before posting the GPU, since it seems
to need the MC_FB_LOCATION setup correctly.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Doesn't have a tv-out port
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Make sure we have an LVDS encoder before casting enc_priv.

[airlied: also fix two missing cpu_to_le16 casts we noticed on irc]
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

I believe this is a typo.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Make the struct card_info, which is a per struct radeon_device dataset, a
struct member of the radeon device instead of a static per kernel module
value. This should avoid potential problems with two radeon cards installed in
one system.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

DVO in 12 bit mode (which seems to be the most common
config) requires 2x ppll.

Fixes fdo bug 21857.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Limiting the pll output range is a good thing generally as
it limits the number of possible pll combinations for a given
frequency presumably to the ones that work best on each card.
That's why the limits are in the bios tables. However, certain
duallink DVI monitors seem to like pll combinations that would
be limited by this at least on pre-DCE 3.0 r6xx hardware.  This
might need to be adjusted per family or per clock range in the
future.

See fdo bug 24727.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Try to enable msi on chips that support it.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Spread spectrum is a periodic disturbance added
to the feedback divider to change the pixel clock
periodically to reduce interference.

Only enabled on LVDS.

v2: add support for r4xx and fix DCE 3
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The *_HIGH regs are reversed. The secondary ones are in the
primary block and vice versa.

We currently only use a 32 bit internal address, so these are
0 for now.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch only changes this is the swap path, where it doesn't loop.
Signed-off-by: NRobert Noland <rnoland@2hip.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

- Reduce the chance of error and avoid a bit of overhead.
  - Use switch to assign color and format
Signed-off-by: NRobert Noland <rnoland@2hip.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Where supported use ulMinPixelClockPLL_Output rather than
usMinPixelClockPLL_Output for pll_out_min.  This seems to
improve pll selection on some boards.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

doesn't have a tv-out port
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The problem boils down to the order when the bit11
of the texture size is or'ed to the original width.
In the end each mipmap level has the same width or
height because of that 11 bit is ored to the scaled
down lod with and thus blows up the size again to the
full size or more due to the power of two rounding
afterwards.

The attached patch changes this order so that the
texture sizes are computed correct. Also the on error
the yet missing inputs to the size computation are
printed which helped me to find out where it really breaks.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This sets the fbcon to use TRUECOLOR by default, it then
only modifies the pseudo palette for fbcon, and only touches
the real palette when in 8-bit pseudo color mode.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Original radeon didn't have a connector table in the
bios.  Check for the CRT table and if we have one,
add a VGA connector.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Need to check the return type for the quirk function
to decide whether we add the connectors and encoders.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Sometimes we will get the incorrect display modeline when parsing the detailed
timing in EDID. For example:
   >hsync/vsync width is zero
   >sync is beyond the blank.

So add the basic check for the detailed timing in EDID to avoid the incorrect
display modeline.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NMatt Turner <mattst88@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

fixes fdo bug 24496
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

D1MODE_INTERLEAVE_EN was getting set in some cases
in the encoder quirks function due to the changes in
5a9bcaccSigned-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Based partly on a patch from
Christian Koenig <deathsimple@vodafone.de>

- fix several memory leaks in radeon_connector->edid handling
- store edid in radeon_connector->edid in detect() or get_modes()
- switch hdmi detect code to use radeon_connector->edid
- add support for oem boards multiple connectors that share
a ddc line.
- short circuit lvds_detect() if have a stored edid
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

- crtc 0 routing was wrong
- need to clear various timing bits in FP_GEN_CNTL
- need to set FP_H/V2_SYNC_STRT_WID regs for crtc 1
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

radeon_encoder->active_device defines the active routing
between the encoder and connector.  The encoder fixup and
dpms functions need to know the active_device to function
properly.  Setting active_device in the prepare hook was
too late in some cases.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

drm modes are objects with indentifiers.  Make sure to preserve
the mode id when copying mode params.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

With the adjust table introduction, we need to fill out index
before getting the table version.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This reverts commit 49c458e5. It
seems to have some side effects in the non-kms cases.
Signed-off-by: NDave Airlie <airlied@redhat.com>

In case the system has bad native mode info but
valid edid.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This reduces the number of mode format conversions needed
and makes native panel mode support cleaner.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

- clean up tv timing handling
- unify SetCRTC_Timing and SetCRTC_UsingDTDTiming
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

DCE3+ has an AdjustDisplayPll that will adjust the pixel
clock accordingly based on the encoder/transmitter to
handle special hw requirements.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Based on recommendation from bios docs.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If the panel data is bogus this can lead to problems
later when the hardware trys to set the mode.  If the
data is invalid, report LVDS as disconnected.

Should fix fdo bug 24247.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

While investigating the cause of CRTC FIFO underruns, I noticed that when
converting the memory bandwidth calculation from the userspace X driver code,
an instance of '8.0' was apparently accidentally converted to '80'.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The hook may change the number of bytes per pixel being scanned out, which
affects the CRTC memory bandwidth requirements. E.g. booting in 8bpp and then
running X in 32bpp would result in the bandwidth requirements being
underestimated for the latter and consequently in CRTC FIFO underruns causing
visible artifacts with 3D intensive workloads.

ATOM changes only compile-tested.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The fb binding might be happening in a subsequent crtc setup call.

gets rid of some lut issues.
Signed-off-by: NDave Airlie <airlied@redhat.com>