<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu, branch v3.14.76</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.14.76</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.14.76'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2016-07-27T16:55:50+00:00</updated>
<entry>
<title>drm/i915/ilk: Don't disable SSC source if it's in use</title>
<updated>2016-07-27T16:55:50+00:00</updated>
<author>
<name>Lyude</name>
<email>cpaul@redhat.com</email>
</author>
<published>2016-06-14T15:04:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3a70dcaee04b82960f7c9d0047459b9e50da4f46'/>
<id>urn:sha1:3a70dcaee04b82960f7c9d0047459b9e50da4f46</id>
<content type='text'>
commit 476490a945e1f0f6bd58e303058d2d8ca93a974c upstream.

Thanks to Ville Syrjälä for pointing me towards the cause of this issue.

Unfortunately one of the sideaffects of having the refclk for a DPLL set
to SSC is that as long as it's set to SSC, the GPU will prevent us from
powering down any of the pipes or transcoders using it. A couple of
BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL
configurations. This causes issues on the first modeset, since we don't
expect SSC to be left on and as a result, can't successfully power down
the pipes or the transcoders using it. Here's an example from this Dell
OptiPlex 990:

[drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says disabled
[drm:intel_modeset_init] 2 display pipes available.
[drm:intel_update_cdclk] Current CD clock rate: 400000 kHz
[drm:intel_update_max_cdclk] Max CD clock rate: 400000 kHz
[drm:intel_update_max_cdclk] Max dotclock rate: 360000 kHz
vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[drm:intel_crt_reset] crt adpa set to 0xf40000
[drm:intel_dp_init_connector] Adding DP connector on port C
[drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1
[drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0
[drm:ironlake_init_pch_refclk] Disabling SSC entirely
… later we try committing the first modeset …
[drm:intel_dump_pipe_config] [CRTC:26][modeset] config ffff88041b02e800 for pipe A
[drm:intel_dump_pipe_config] cpu_transcoder: A
…
[drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, fp0: 0x20e08, fp1: 0x30d07
[drm:intel_dump_pipe_config] planes on this crtc
[drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled
[drm:intel_dump_pipe_config]     FB:42, fb = 800x600 format = 0x34325258
[drm:intel_dump_pipe_config]     scaler:0 src (0, 0) 800x600 dst (0, 0) 800x600
[drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, scaler_id = 0
[drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, scaler_id = 0
[drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A
[drm:intel_get_shared_dpll] using PCH DPLL A for pipe A
[drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A
[drm:intel_disable_pipe] disabling pipe A
------------[ cut here ]------------
WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 intel_disable_pipe+0x297/0x2d0 [i915]
pipe_off wait timed out
…
---[ end trace 94fc8aa03ae139e8 ]---
[drm:intel_dp_link_down]
[drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A

Later modesets succeed since they reset the DPLL's configuration anyway,
but this is enough to get stuck with a big fat warning in dmesg.

A better solution would be to add refcounts for the SSC source, but for
now leaving the source clock on should suffice.

Changes since v4:
 - Fix calculation of final for systems with LVDS panels (fixes BUG() on
   CI test suite)
Changes since v3:
 - Move temp variable into loop
 - Move checks for using_ssc_source to after we've figured out has_ck505
 - Add using_ssc_source to debug output
Changes since v2:
 - Fix debug output for when we disable the CPU source
Changes since v1:
 - Leave the SSC source clock on instead of just shutting it off on all
   of the DPLL configurations.

Reviewed-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Signed-off-by: Lyude &lt;cpaul@redhat.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/1465916649-10228-1-git-send-email-cpaul@redhat.com
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/radeon: fix asic initialization for virtualized environments</title>
<updated>2016-07-27T16:55:50+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2016-06-13T19:37:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=617ef55b39a3799d9f44811326735037c2dd04cf'/>
<id>urn:sha1:617ef55b39a3799d9f44811326735037c2dd04cf</id>
<content type='text'>
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 &lt;andres.rodriguez@amd.com&gt;
Cc: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/fb_helper: Fix references to dev-&gt;mode_config.num_connector</title>
<updated>2016-06-08T00:21:58+00:00</updated>
<author>
<name>Lyude</name>
<email>cpaul@redhat.com</email>
</author>
<published>2016-05-12T14:56:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4bb87c0487e7b7c009d195310f8aeda63d61e2c5'/>
<id>urn:sha1:4bb87c0487e7b7c009d195310f8aeda63d61e2c5</id>
<content type='text'>
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-&gt;mode_config.num_connectors.
- MST hotplug occurs, dev-&gt;mode_config.num_connectors gets incremented.
- We try to loop through each element in the array using the new value
  of dev-&gt;mode_config.num_connectors, and end up going out of bounds
  since dev-&gt;mode_config.num_connectors is now larger then the array we
  allocated.

fb_helper-&gt;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 &lt;cpaul@redhat.com&gt;
[danvet: Clarify why we need this. Also remove the now unused "dev"
local variable to appease gcc.]
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-3-git-send-email-cpaul@redhat.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/gma500: Fix possible out of bounds read</title>
<updated>2016-06-08T00:21:58+00:00</updated>
<author>
<name>Itai Handler</name>
<email>itai_handler@hotmail.com</email>
</author>
<published>2015-11-02T22:20:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=369168dfae6fded212a7c43c9df8e58b604d9160'/>
<id>urn:sha1:369168dfae6fded212a7c43c9df8e58b604d9160</id>
<content type='text'>
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).

Signed-off-by: Itai Handler &lt;itai_handler@hotmail.com&gt;
Signed-off-by: Patrik Jakobsson &lt;patrik.r.jakobsson@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: Bail out of pipe config compute loop on LPT</title>
<updated>2016-05-19T00:03:59+00:00</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2016-05-03T08:33:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dfc2079ba67e4bd5b3ee88d59952a174a7f1272f'/>
<id>urn:sha1:dfc2079ba67e4bd5b3ee88d59952a174a7f1272f</id>
<content type='text'>
commit 2700818ac9f935d8590715eecd7e8cadbca552b6 upstream.

LPT is pch, so might run into the fdi bandwidth constraint (especially
since it has only 2 lanes). But right now we just force pipe_bpp back
to 24, resulting in a nice loop (which we bail out with a loud
WARN_ON). Fix this.

Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
References: https://bugs.freedesktop.org/show_bug.cgi?id=93477
Signed-off-by: Daniel Vetter &lt;daniel.vetter@intel.com&gt;
Tested-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/1462264381-7573-1-git-send-email-daniel.vetter@ffwll.ch
(cherry picked from commit f58a1acc7e4a1f37d26124ce4c875c647fbcc61f)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/radeon: fix PLL sharing on DCE6.1 (v2)</title>
<updated>2016-05-19T00:03:59+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>dev@lynxeye.de</email>
</author>
<published>2016-05-05T14:16:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9e3f55f5045c542a48c560c503f949b8e80adcf4'/>
<id>urn:sha1:9e3f55f5045c542a48c560c503f949b8e80adcf4</id>
<content type='text'>
commit e3c00d87845ab375f90fa6e10a5e72a3a5778cd3 upstream.

On DCE6.1 PPLL2 is exclusively available to UNIPHYA, so it should not
be taken into consideration when looking for an already enabled PLL
to be shared with other outputs.

This fixes the broken VGA port (TRAVIS DP-&gt;VGA bridge) on my Richland
based laptop, where the internal display is connected to UNIPHYA through
a TRAVIS DP-&gt;LVDS bridge.

Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=78987

v2: agd: add check in radeon_get_shared_nondp_ppll as well, drop
    extra parameter.

Signed-off-by: Lucas Stach &lt;dev@lynxeye.de&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/qxl: fix cursor position with non-zero hotspot</title>
<updated>2016-05-04T21:51:24+00:00</updated>
<author>
<name>John Keeping</name>
<email>john@metanate.com</email>
</author>
<published>2015-11-18T11:17:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0824da19fbad3ffcf53be9a20a2cf40af4c06a25'/>
<id>urn:sha1:0824da19fbad3ffcf53be9a20a2cf40af4c06a25</id>
<content type='text'>
commit d59a1f71ff1aeda4b4630df92d3ad4e3b1dfc885 upstream.

The SPICE protocol considers the position of a cursor to be the location
of its active pixel on the display, so the cursor is drawn with its
top-left corner at "(x - hot_spot_x, y - hot_spot_y)" but the DRM cursor
position gives the location where the top-left corner should be drawn,
with the hotspot being a hint for drivers that need it.

This fixes the location of the window resize cursors when using Fluxbox
with the QXL DRM driver and both the QXL and modesetting X drivers.

Signed-off-by: John Keeping &lt;john@metanate.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/1447845445-2116-1-git-send-email-john@metanate.com
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/radeon: hold reference to fences in radeon_sa_bo_new (3.17 and older)</title>
<updated>2016-04-20T06:40:45+00:00</updated>
<author>
<name>Nicolai Hähnle</name>
<email>nicolai.haehnle@amd.com</email>
</author>
<published>2016-03-15T17:56:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4e8190cf1e6f2213f76a038132e7ad19014214d4'/>
<id>urn:sha1:4e8190cf1e6f2213f76a038132e7ad19014214d4</id>
<content type='text'>
[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 &lt;nicolai.haehnle@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt; (v1 + fix)
Tested-by: Lutz Euler &lt;lutz.euler@freenet.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Revert bad backport of "drm/radeon: hold reference to fences in radeon_sa_bo_new"</title>
<updated>2016-04-20T06:40:45+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2016-04-18T01:31:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8ac960dc06ca2d618c40206d8839180a5703552f'/>
<id>urn:sha1:8ac960dc06ca2d618c40206d8839180a5703552f</id>
<content type='text'>
This reverts commit 50353e6f86eb2ac46ffe3cc0b9f9a11ddc8a9410, which is
commit f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb upstream, as it was
backported to the 3.14-stable tree incorrectly.  A correct fix will
happen next.

Reported-by: Nicolai Hähnle &lt;nicolai.haehnle@amd.com&gt;
Cc: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>drm/radeon: add a dpm quirk for all R7 370 parts</title>
<updated>2016-04-20T06:40:40+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2016-03-28T14:21:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c59ffbe17b2b6c9f68bf4f101e4d6b16b5254aa5'/>
<id>urn:sha1:c59ffbe17b2b6c9f68bf4f101e4d6b16b5254aa5</id>
<content type='text'>
commit 0e5585dc870af947fab2af96a88c2d8b4270247c upstream.

Higher mclk values are not stable due to a bug somewhere.
Limit them for now.

Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
