linux.git/drivers/gpu, branch v3.10.103

drm/radeon: fix firmware info version checks

2016-08-21T21:22:47+00:00

commit 3edc38a0facef45ee22af8afdce3737f421f36ab upstream.

Some of the checks didn't handle frev 2 tables properly.

Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Willy Tarreau

drm/radeon: Poll for both connect/disconnect on analog connectors

2016-08-21T21:22:47+00:00

commit 14ff8d48f2235295dfb3117693008e367b49cdb5 upstream.

DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not
disconnections. Because of this, we end up losing hotplug polling for
analog connectors once they get connected.

Easy way to reproduce:
 - Grab a machine with a radeon GPU and a VGA port
 - Plug a monitor into the VGA port, wait for it to update the connector
   from disconnected to connected
 - Disconnect the monitor on VGA, a hotplug event is never sent for the
   removal of the connector.

Originally, only using DRM_CONNECTOR_POLL_CONNECT might have been a good
idea since doing VGA polling can sometimes result in having to mess with
the DAC voltages to figure out whether or not there's actually something
there since VGA doesn't have HPD. Doing this would have the potential of
showing visible artifacts on the screen every time we ran a poll while a
VGA display was connected. Luckily, radeon_vga_detect() only resorts to
this sort of polling if the poll is forced, and DRM's polling helper
doesn't force it's polls.

Additionally, this removes some assignments to connector->polled that
weren't actually doing anything.

Cc: stable@vger.kernel.org
Signed-off-by: Lyude 
Signed-off-by: Alex Deucher 
Signed-off-by: Willy Tarreau

drm/radeon: add a delay after ATPX dGPU power off

2016-08-21T21:22:47+00:00

commit d814b24fb74cb9797d70cb8053961447c5879a5c upstream.

ATPX dGPU power control requires a 200ms delay between
power off and on.  This should fix dGPU failures on
resume from power off.

Reviewed-by: Hawking Zhang 
Acked-by: Christian König 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Willy Tarreau

drm/radeon: fix asic initialization for virtualized environments

2016-08-21T21:22:46+00:00

commit 05082b8bbd1a0ffc74235449c4b8930a8c240f85 upstream.

When executing in a PCI passthrough based virtuzliation environment, the
hypervisor will usually attempt to send a PCIe bus reset signal to the
ASIC when the VM reboots. In this scenario, the card is not correctly
initialized, but we still consider it to be posted. Therefore, in a
passthrough based environemnt we should always post the card to guarantee
it is in a good state for driver initialization.

Ported from amdgpu commit:
amdgpu: fix asic initialization for virtualized environments

Cc: Andres Rodriguez 
Cc: Alex Williamson 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Willy Tarreau

drm/fb_helper: Fix references to dev->mode_config.num_connector

2016-08-21T21:22:46+00:00

commit 255f0e7c418ad95a4baeda017ae6182ba9b3c423 upstream.

During boot, MST hotplugs are generally expected (even if no physical
hotplugging occurs) and result in DRM's connector topology changing.
This means that using num_connector from the current mode configuration
can lead to the number of connectors changing under us. This can lead to
some nasty scenarios in fbcon:

- We allocate an array to the size of dev->mode_config.num_connectors.
- MST hotplug occurs, dev->mode_config.num_connectors gets incremented.
- We try to loop through each element in the array using the new value
  of dev->mode_config.num_connectors, and end up going out of bounds
  since dev->mode_config.num_connectors is now larger then the array we
  allocated.

fb_helper->connector_count however, will always remain consistent while
we do a modeset in fb_helper.

Note: This is just polish for 4.7, Dave Airlie's drm_connector
refcounting fixed these bugs for real. But it's good enough duct-tape
for stable kernel backporting, since backporting the refcounting
changes is way too invasive.

Signed-off-by: Lyude 
[danvet: Clarify why we need this. Also remove the now unused "dev"
local variable to appease gcc.]
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-3-git-send-email-cpaul@redhat.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

drm/gma500: Fix possible out of bounds read

2016-08-21T21:22:46+00:00

commit 7ccca1d5bf69fdd1d3c5fcf84faf1659a6e0ad11 upstream.

Fix possible out of bounds read, by adding missing comma.
The code may read pass the end of the dsi_errors array
when the most significant bit (bit #31) in the intr_stat register
is set.
This bug has been detected using CppCheck (static analysis tool).

Cc: stable@vger.kernel.org
Signed-off-by: Itai Handler 
Signed-off-by: Patrik Jakobsson 
Signed-off-by: Willy Tarreau

drm/radeon: hold reference to fences in radeon_sa_bo_new (3.17 and older)

2016-06-07T08:42:50+00:00

[Backport of upstream commit f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb, with
 an additional NULL pointer guard that is required for kernels 3.17 and older.

 To be precise, any kernel that does *not* have commit 954605ca3 "drm/radeon:
 use common fence implementation for fences, v4" requires this additional
 NULL pointer guard.]

An arbitrary amount of time can pass between spin_unlock and
radeon_fence_wait_any, so we need to ensure that nobody frees the
fences from under us.

Based on the analogous fix for amdgpu.

Signed-off-by: Nicolai Hähnle 
Reviewed-by: Christian König  (v1 + fix)
Tested-by: Lutz Euler 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

drm/radeon: Don't drop DP 2.7 Ghz link setup on some cards.

2016-06-07T08:42:47+00:00

commit 459ee1c3fd097ab56ababd8ff4bb7ef6a792de33 upstream.

As observed on Apple iMac10,1, DCE-3.2, RV-730,
link rate of 2.7 Ghz is not selected, because
the args.v1.ucConfig flag setting for 2.7 Ghz
gets overwritten by a following assignment of
the transmitter to use.

Move link rate setup a few lines down to fix this.
In practice this didn't have any positive or
negative effect on display setup on the tested
iMac10,1 so i don't know if backporting to stable
makes sense or not.

Signed-off-by: Mario Kleiner 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Willy Tarreau

Revert "drm/radeon: hold reference to fences in radeon_sa_bo_new"

2016-03-09T23:31:56+00:00

This reverts commit 8d5e1e5af0c667545c202e8f4051f77aa3bf31b7 which was
commit f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb upstream.

It breaks working hardware, a backported version might be provided at
some unknown time in the future.

Reported-by: Erik Andersen 
Acked-by: Christian König 
Cc: Nicolai Hähnle 
Signed-off-by: Greg Kroah-Hartman

drm/ast: Fix incorrect register check for DRAM width

2016-03-09T23:31:54+00:00

commit 2d02b8bdba322b527c5f5168ce1ca10c2d982a78 upstream.

During DRAM initialization on certain ASpeed devices, an incorrect
bit (bit 10) was checked in the "SDRAM Bus Width Status" register
to determine DRAM width.

Query bit 6 instead in accordance with the Aspeed AST2050 datasheet v1.05.

Signed-off-by: Timothy Pearson 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman