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

drm: add a check for x/y in drm_mode_setcrtc

2015-08-03T16:29:45+00:00

commit 01447e9f04ba1c49a9534ae6a5a6f26c2bb05226 upstream.

legacy setcrtc ioctl does take a 32 bit value which might indeed
overflow

the checks of crtc_req->x > INT_MAX and crtc_req->y > INT_MAX aren't
needed any more with this

v2: -polish the annotation according to Daniel's comment

Cc: Daniel Vetter 
Signed-off-by: Zhao Junwang 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: Don't flush the GART TLB if rdev->gart.ptr == NULL

2015-08-03T16:29:45+00:00

commit 233709d2cd6bbaaeda0aeb8d11f6ca7f98563b39 upstream.

This can be the case when the GPU is powered off, e.g. via vgaswitcheroo
or runpm. When the GPU is powered up again, radeon_gart_table_vram_pin
flushes the TLB after setting rdev->gart.ptr to non-NULL.

Fixes panic on powering off R7xx GPUs.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61529
Reviewed-by: Christian König 
Signed-off-by: Michel Dänzer 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: take the mode_config mutex when dealing with hpds (v2)

2015-08-03T16:29:45+00:00

commit 39fa10f7e21574a70cecf1fed0f9b36535aa68a0 upstream.

Since we are messing with state in the worker.

v2: drop the changes in the mst worker

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/qxl: Do not cause spice-server to clean our objects

2015-08-03T16:29:45+00:00

commit 2fa19535ca6abcbfd1ccc9ef694db52f49f77747 upstream.

If objects are moved back from system memory to VRAM (and spice id
created again) memory is already initialized so we need to set flag
to not clear memory.
If you don't do it after a while using desktop many images turns to
black or transparents.

Signed-off-by: Frediano Ziglio 
Reviewed-by: Dave Airlie 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/mgag200: Reject non-character-cell-aligned mode widths

2015-06-29T19:08:34+00:00

commit 25161084b1c1b0c29948f6f77266a35f302196b7 upstream.

Turns out 1366x768 does not in fact work on this hardware.

Signed-off-by: Adam Jackson 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix DDC probe for passive adapters

2015-06-22T23:55:54+00:00

commit 3f5f1554ee715639e78d9be87623ee82772537e0 upstream.

Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
devices, as they do not have a sink device in them to respond to any AUX
traffic. When probing these dongles over the DDC, sometimes they will
NAK the first attempt even though the transaction is valid and they
support the DDC protocol. The retry loop inside of
drm_do_probe_ddc_edid() would normally catch this case and try the
transaction again, resulting in success.

That, however, was thwarted by the fix for [1]:

commit 9292f37e1f5c79400254dca46f83313488093825
Author: Eugeni Dodonov 
Date:   Thu Jan 5 09:34:28 2012 -0200

    drm: give up on edid retries when i2c bus is not responding

This added code to exit immediately if the return code from the
i2c_transfer function was -ENXIO in order to reduce the amount of time
spent in waiting for unresponsive or disconnected devices. That was
possible because the underlying i2c bit banging algorithm had retries of
its own (which, of course, were part of the reason for the bug the
commit fixes).

Since its introduction in

commit f899fc64cda8569d0529452aafc0da31c042df2e
Author: Chris Wilson 
Date:   Tue Jul 20 15:44:45 2010 -0700

    drm/i915: use GMBUS to manage i2c links

we've been flipping back and forth enabling the GMBUS transfers, but
we've settled since then. The GMBUS implementation does not do any
retries, however, bailing out of the drm_do_probe_ddc_edid() retry loop
on first encounter of -ENXIO. This, combined with Eugeni's commit, broke
the retry on -ENXIO.

Retry GMBUS once on -ENXIO on first message to mitigate the issues with
passive adapters.

This patch is based on the work, and commit message, by Todd Previte
.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=41059

v2: Don't retry if using bit banging.

v3: Move retry within gmbux_xfer, retry only on first message.

v4: Initialize GMBUS0 on retry (Ville).

v5: Take index reads into account (Ville).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924
Cc: Todd Previte 
Tested-by: Oliver Grafe  (v2)
Tested-by: Jim Bride 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid}

2015-06-06T06:19:53+00:00

commit 8f375e10ee47b9d7b9b3aefcf67854c6e92708be upstream.

Description:
intel_gmbus_is_forced_bit is no extern as its body is right below.
Likewise for intel_gmbus_is_port_valid.

This fixes a compilation issue with clang. An initial version of this patch
was developed by PaX Team .
This is respin of this patch.

20130509: v2: (re-)add inline upon request.

Signed-off-by: Jan-Simon Möller 
CC: pageexec@freemail.hu
CC: daniel.vetter@ffwll.ch
CC: airlied@linux.ie
CC: intel-gfx@lists.freedesktop.org
CC: dri-devel@lists.freedesktop.org
CC: linux-kernel@vger.kernel.org
[danvet: Bikeshed commit message.]
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Add missing MacBook Pro models with dual channel LVDS

2015-05-17T16:51:32+00:00

commit 3916e3fd81021fb795bfbdb17f375b6b3685bced upstream.

Single channel LVDS maxes out at 112 MHz. The 15" pre-retina models
shipped with 1440x900 (106 MHz) by default or 1680x1050 (119 MHz)
as a BTO option, both versions used dual channel LVDS even though
the smaller one would have fit into a single channel.

Notes:
  Bug report showing that the MacBookPro8,2 with 1440x900 uses dual
  channel LVDS (this lead to it being hardcoded in intel_lvds.c by
  Daniel Vetter with commit 618563e3945b9d0864154bab3c607865b557cecc):
    https://bugzilla.kernel.org/show_bug.cgi?id=42842

  If i915.lvds_channel_mode=2 is missing even though the machine needs
  it, every other vertical line is white and consequently, only the left
  half of the screen is visible (verified by myself on a MacBookPro9,1).

  Forum posting concerning a MacBookPro6,2 with 1440x900, author is
  using i915.lvds_channel_mode=2 on the kernel command line, proving
  that the machine uses dual channels:
    https://bbs.archlinux.org/viewtopic.php?id=185770

  Chi Mei N154C6-L04 with 1440x900 is a replacement panel for all
  MacBook Pro "A1286" models, and that model number encompasses the
  MacBookPro6,2 / 8,2 / 9,1. Page 17 of the panel's datasheet shows it's
  driven with dual channel LVDS:
    http://www.ebay.com/itm/-/400690878560
    http://www.everymac.com/ultimate-mac-lookup/?search_keywords=A1286
    http://www.taopanel.com/chimei/datasheet/N154C6-L04.pdf

  Those three 15" models, MacBookPro6,2 / 8,2 / 9,1, are the only ones
  with i915 graphics and dual channel LVDS, so that list should be
  complete. And the 8,2 is already in intel_lvds.c.

  Possible motivation to use dual channel LVDS even on the 1440x900
  models: Reduce the number of different parts, i.e. use identical logic
  boards and display cabling on both versions and the only differing
  component is the panel.

Signed-off-by: Lukas Wunner 
Acked-by: Jani Nikula 
[Jani: included notes in the commit message for posterity]
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: cope with large i2c transfers

2015-05-06T19:56:27+00:00

commit 9535c4757b881e06fae72a857485ad57c422b8d2 upstream.

The hardware, according to the specs, is limited to 256 byte transfers,
and current driver has no protections in case users attempt to do larger
transfers. The code will just stomp over status register and mayhem
ensues.

Let's split larger transfers into digestable chunks. Doing this allows
Atmel MXT driver on Pixel 1 function properly (it hasn't since commit
9d8dc3e529a19e427fd379118acd132520935c5d "Input: atmel_mxt_ts -
implement T44 message handling" which tries to consume multiple
touchscreen/touchpad reports in a single transaction).

Reviewed-by: Chris Wilson 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix doublescan modes (v2)

2015-05-06T19:56:27+00:00

commit fd99a0943ffaa0320ea4f69d09ed188f950c0432 upstream.

Use the correct flags for atom.

v2: handle DRM_MODE_FLAG_DBLCLK

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman