linux-stable.git/drivers/gpu/drm, branch v3.2.87

drm: Reject page_flip for !DRIVER_MODESET

2016-11-20T01:01:34+00:00

commit 6f00975c619064a18c23fd3aced325ae165a73b9 upstream.

Somehow this one slipped through, which means drivers without modeset
support can be oopsed (since those also don't call
drm_mode_config_init, which means the crtc lookup will chase an
uninitalized idr).

Reported-by: Alexander Potapenko 
Cc: Alexander Potapenko 
Signed-off-by: Daniel Vetter 
Reviewed-by: Chris Wilson 
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings

drm/radeon: fix radeon_move_blit on 32bit systems

2016-11-20T01:01:33+00:00

commit 13f479b9df4e2bbf2d16e7e1b02f3f55f70e2455 upstream.

This bug seems to be present for a very long time.

Signed-off-by: Christian König 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

drm/edid: Add 6 bpc quirk for display AEO model 0.

2016-11-20T01:01:31+00:00

commit e10aec652f31ec61d6a0b4d00d8ef8d2b66fa0fd upstream.

Bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=105331
reports that the "AEO model 0" display is driven with 8 bpc
without dithering by default, which looks bad because that
panel is apparently a 6 bpc DP panel with faulty EDID.

A fix for this was made by commit 013dd9e03872
("drm/i915/dp: fall back to 18 bpp when sink capability is unknown").

That commit triggers new regressions in precision for DP->DVI and
DP->VGA displays. A patch is out to revert that commit, but it will
revert video output for the AEO model 0 panel to 8 bpc without
dithering.

The EDID 1.3 of that panel, as decoded from the xrandr output
attached to that bugzilla bug report, is somewhat faulty, and beyond
other problems also sets the "DFP 1.x compliant TMDS" bit, which
according to DFP spec means to drive the panel with 8 bpc and
no dithering in absence of other colorimetry information.

Try to make the original bug reporter happy despite the
faulty EDID by adding a quirk to mark that panel as 6 bpc,
so 6 bpc output with dithering creates a nice picture.

Tested by injecting the edid from the fdo bug into a DP connector
via drm_kms_helper.edid_firmware and verifying the 6 bpc + dithering
is selected.

This patch should be backported to stable.

Signed-off-by: Mario Kleiner 
Cc: Jani Nikula 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Signed-off-by: Dave Airlie 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

drm/radeon: fix firmware info version checks

2016-11-20T01:01:29+00:00

commit 3edc38a0facef45ee22af8afdce3737f421f36ab upstream.

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

Signed-off-by: Alex Deucher 
Signed-off-by: Ben Hutchings

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

2016-11-20T01:01:24+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.

Signed-off-by: Lyude 
Signed-off-by: Alex Deucher 
Signed-off-by: Ben Hutchings

drm/radeon: fix asic initialization for virtualized environments

2016-08-22T21:37:14+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 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

drm/radeon: make sure vertical front porch is at least 1

2016-06-15T20:28:14+00:00

commit 3104b8128d4d646a574ed9d5b17c7d10752cd70b upstream.

hw doesn't like a 0 value.

Signed-off-by: Alex Deucher 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

drm/i915: Fix system resume if PCI device remained enabled

2016-06-15T20:28:13+00:00

commit dab9a2663f4e688106c041f7cd2797a721382f0a upstream.

During system resume we depended on pci_enable_device() also putting the
device into PCI D0 state. This won't work if the PCI device was already
enabled but still in D3 state. This is because pci_enable_device() is
refcounted and will not change the HW state if called with a non-zero
refcount. Leaving the device in D3 will make all subsequent device
accesses fail.

This didn't cause a problem most of the time, since we resumed with an
enable refcount of 0. But it fails at least after module reload because
after that we also happen to leak a PCI device enable reference: During
probing we call drm_get_pci_dev() which will enable the PCI device, but
during device removal drm_put_dev() won't disable it. This is a bug of
its own in DRM core, but without much harm as it only leaves the PCI
device enabled. Fixing it is also a bit more involved, due to DRM
mid-layering and because it affects non-i915 drivers too. The fix in
this patch is valid regardless of the problem in DRM core.

v2:
- Add a code comment about the relation of this fix to the freeze/thaw
vs. the suspend/resume phases. (Ville)
- Add a code comment about the inconsistent ordering of set power state
and device enable calls. (Chris)

CC: Ville Syrjälä
CC: Chris Wilson
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
Link: http://patchwork.freedesktop.org/patch/msgid/1460979954-14503-1-git-send-email-imre.deak@intel.com
(cherry picked from commit 44410cd0bfb26bde9288da34c190cc9267d42a20)
Signed-off-by: Jani Nikula
[bwh: Backported to 3.2:
- Return error code directly
- Adjust context]
Signed-off-by: Ben Hutchings

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

2016-04-30T22:05:17+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 
Signed-off-by: Ben Hutchings

Revert "drm/radeon: call hpd_irq_event on resume"

2016-04-01T00:54:37+00:00

commit 256faedcfd646161477d47a1a78c32a562d2e845 upstream.

This reverts commit dbb17a21c131eca94eb31136eee9a7fe5aff00d9.

It turns out that commit can cause problems for systems with multiple
GPUs, and causes X to hang on at least a HP Pavilion dv7 with hybrid
graphics.

This got noticed originally in 4.4.4, where this patch had already
gotten back-ported, but 4.5-rc7 was verified to have the same problem.

Alexander Deucher says:
 "It looks like you have a muxed system so I suspect what's happening is
  that one of the display is being reported as connected for both the
  IGP and the dGPU and then the desktop environment gets confused or
  there some sort problem in the detect functions since the mux is not
  switched to the dGPU.  I don't see an easy fix unless Dave has any
  ideas.  I'd say just revert for now"

Reported-by: Jörg-Volker Peetz 
Acked-by: Alexander Deucher 
Cc: Dave Airlie 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings