linux-toradex.git/drivers/gpu, branch v3.2.27

drm/i915: prefer wide & slow to fast & narrow in DP configs

2012-08-09T23:25:13+00:00

commit 2514bc510d0c3aadcc5204056bb440fa36845147 upstream.

High frequency link configurations have the potential to cause trouble
with long and/or cheap cables, so prefer slow and wide configurations
instead.  This patch has the potential to cause trouble for eDP
configurations that lie about available lanes, so if we run into that we
can make it conditional on eDP.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45801
Tested-by: peter@colberg.org
Signed-off-by: Jesse Barnes 
Signed-off-by: Daniel Vetter 
Signed-off-by: Ben Hutchings

nouveau: Fix alignment requirements on src and dst addresses

2012-08-02T13:38:02+00:00

commit ce806a30470bcd846d148bf39d46de3ad7748228 upstream.

Linear copy works by adding the offset to the buffer address,
which may end up not being 16-byte aligned.

Some tests I've written for prime_pcopy show that the engine
allows this correctly, so the restriction on lowest 4 bits of
address can be lifted safely.

The comments added were by envyas, I think because I used
a newer version.

Signed-off-by: Maarten Lankhorst 
[bwh: Backported to 3.2: no # prefixes in nva3_copy.fuc]
Signed-off-by: Ben Hutchings

drm/radeon: on hotplug force link training to happen (v2)

2012-08-02T13:38:01+00:00

commit ca2ccde5e2f24a792caa4cca919fc5c6f65d1887 upstream.

To have DP behave like VGA/DVI we need to retrain the link
on hotplug. For this to happen we need to force link
training to happen by setting connector dpms to off
before asking it turning it on again.

v2: agd5f
- drop the dp_get_link_status() change in atombios_dp.c
  for now.  We still need the dpms OFF change.

Signed-off-by: Jerome Glisse 
Signed-off-by: Alex Deucher 
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings

drm/radeon: fix hotplug of DP to DVI|HDMI passive adapters (v2)

2012-08-02T13:38:01+00:00

commit 266dcba541a1ef7e5d82d9e67c67fde2910636e8 upstream.

No need to retrain the link for passive adapters.

v2: agd5f
- no passive DP to VGA adapters, update comments
- assign radeon_connector_atom_dig after we are sure
  we have a digital connector as analog connectors
  have different private data.
- get new sink type before checking for retrain.  No
  need to check if it's no longer a DP connection.

Signed-off-by: Jerome Glisse 
Signed-off-by: Alex Deucher 
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings

drm/radeon: fix non revealent error message

2012-08-02T13:38:01+00:00

commit 8d1c702aa0b2c4b22b0742b72a1149d91690674b upstream.

We want to print link status query failed only if it's
an unexepected fail. If we query to see if we need
link training it might be because there is nothing
connected and thus link status query have the right
to fail in that case.

To avoid printing failure when it's expected, move the
failure message to proper place.

Signed-off-by: Jerome Glisse 
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings

drm/radeon: fix bo creation retry path

2012-08-02T13:38:00+00:00

commit d1c7871ddb1f588b8eb35affd9ee1a3d5e11cd0c upstream.

Retry label was at wrong place in function leading to memory
leak.

Signed-off-by: Jerome Glisse 
Reviewed-by: Michel Dänzer 
Reviewed-by: Christian König 
Signed-off-by: Dave Airlie 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

drm/radeon: Try harder to avoid HW cursor ending on a multiple of 128 columns.

2012-08-02T13:37:53+00:00

commit f60ec4c7df043df81e62891ac45383d012afe0da upstream.

This could previously fail if either of the enabled displays was using a
horizontal resolution that is a multiple of 128, and only the leftmost column
of the cursor was (supposed to be) visible at the right edge of that display.

The solution is to move the cursor one pixel to the left in that case.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33183

Signed-off-by: Michel Dänzer 
Reviewed-by: Alex Deucher 
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings

drm/i915: fix operator precedence when enabling RC6p

2012-07-25T03:10:58+00:00

commit c0e2ee1bc0cf82eec89e26b7afe7e4db0561b7d9 upstream.

As noticed by Torsten Kaiser, the operator precedence can play tricks with
us here.

CC: Dave Airlie 
Signed-off-by: Eugeni Dodonov 
Signed-off-by: Jesse Barnes 
Signed-off-by: Ben Hutchings

drm/i915: do not enable RC6p on Sandy Bridge

2012-07-25T03:10:57+00:00

commit 1c8ecf80fdee4e7b23a9e7da7ff9bd59ba2dcf96 upstream.

With base on latest findings, RC6p seems to be respondible for RC6-related
issues on Sandy Bridge platform. To work-around those issues, the previous
solution was to completely disable RC6 on Sandy Bridge for the past few
releases, even if plain RC6 was not giving any issues.

What this patch does is preventing RC6p from being enabled on Sandy Bridge
even if users enable RC6 via a kernel parameter. So it won't change the
defaults in any way, but will ensure that if users do enable RC6 manually
it won't break their machines by enabling this extra state.

Proper fix for this (enabling specific RC6 states according to the GPU
generation) were proposed for the -next kernel, but we are too late in the
release process now to pick such changes.

Acked-by: Keith Packard 
Signed-off-by: Eugeni Dodonov 
Signed-off-by: Jesse Barnes 
Signed-off-by: Ben Hutchings

drm/i915: kick any firmware framebuffers before claiming the gtt

2012-07-12T03:32:07+00:00

commit 9f846a16d213523fbe6daea17e20df6b8ac5a1e5 upstream.

Especially vesafb likes to map everything as uc- (yikes), and if that
mapping hangs around still while we try to map the gtt as wc the
kernel will downgrade our request to uc-, resulting in abyssal
performance.

Unfortunately we can't do this as early as readon does (i.e. as the
first thing we do when initializing the hw) because our fb/mmio space
region moves around on a per-gen basis. So I've had to move it below
the gtt initialization, but that seems to work, too. The important
thing is that we do this before we set up the gtt wc mapping.

Now an altogether different question is why people compile their
kernels with vesafb enabled, but I guess making things just work isn't
bad per se ...

v2:
- s/radeondrmfb/inteldrmfb/
- fix up error handling

v3: Kill #ifdef X86, this is Intel after all. Noticed by Ben Widawsky.

v4: Jani Nikula complained about the pointless bool primary
initialization.

v5: Don't oops if we can't allocate, noticed by Chris Wilson.

v6: Resolve conflicts with agp rework and fixup whitespace.

This is commit e188719a2891f01b3100d in drm-next.

Backport to 3.5 -fixes queue requested by Dave Airlie - due to grub
using vesa on fedora their initrd seems to load vesafb before loading
the real kms driver. So tons more people actually experience a
dead-slow gpu. Hence also the Cc: stable.

Reported-and-tested-by: "Kilarski, Bernard R" 
Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings