<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/gpu/drm, branch v3.0.44</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/gpu/drm?h=v3.0.44</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/gpu/drm?h=v3.0.44'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2012-10-02T16:47:40Z</updated>
<entry>
<title>drm/i915: HDMI - Clear Audio Enable bit for Hot Plug</title>
<updated>2012-10-02T16:47:40Z</updated>
<author>
<name>Wang Xingchao</name>
<email>xingchao.wang@intel.com</email>
</author>
<published>2012-09-12T23:43:22Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e2471ec3e86a473ec354b4707e8e2d2367d1af00'/>
<id>urn:sha1:e2471ec3e86a473ec354b4707e8e2d2367d1af00</id>
<content type='text'>
commit b98b60167279df3acac9422c3c9820d9ebbcf9fb upstream.

Clear Audio Enable bit to trigger unsolicated event to notify Audio
Driver part the HDMI hot plug change. The patch fixed the bug when
remove HDMI cable the bit was not cleared correctly.

In intel_hdmi_dpms(), if intel_hdmi-&gt;has_audio been true, the "Audio enable bit" will
be set to trigger unsolicated event to notify Alsa driver the change.

intel_hdmi-&gt;has_audio will be reset to false from intel_hdmi_detect() after
remove the hdmi cable, here's debug log:

[  187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2
[  187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0

so when comes back to intel_hdmi_dpms(), the "Audio enable bit" will not be cleared. And this
cause the eld infomation and pin presence doesnot update accordingly in alsa driver side.

This patch will also trigger unsolicated event to alsa driver to notify the hot plug event:

[  187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1
[  187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0

Signed-off-by: Wang Xingchao &lt;xingchao.wang@intel.com&gt;
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/kms: extend the Fujitsu D3003-S2 board connector quirk to cover later silicon stepping</title>
<updated>2012-10-02T16:47:40Z</updated>
<author>
<name>Tvrtko Ursulin</name>
<email>tvrtko.ursulin@onelan.co.uk</email>
</author>
<published>2012-08-20T14:16:04Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=062a59eeb37259c1cb09bf2cfd1388e729265815'/>
<id>urn:sha1:062a59eeb37259c1cb09bf2cfd1388e729265815</id>
<content type='text'>
commit 52e9b39d9a89ae33662596bd30e62dd56bddbe73 upstream.

There is a more recent APU stepping with a new PCI ID
shipping in the same board by Fujitsu which needs the
same quirk to correctly mark the back plane connectors.

Signed-off-by: Tvrtko Ursulin &lt;tvrtko.ursulin@onelan.co.uk&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/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot</title>
<updated>2012-09-14T17:00:51Z</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2012-08-29T01:40:51Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=839b995a17f8f16528e6e01a6c2b65fbc2ce8733'/>
<id>urn:sha1:839b995a17f8f16528e6e01a6c2b65fbc2ce8733</id>
<content type='text'>
commit c4903429a92be60e6fe59868924a65eca4cd1a38 upstream.

This will cause udev to load vmwgfx instead of waiting for X
to do it.

Reviewed-by: Jakob Bornecrantz &lt;jakob@vmware.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/radeon: do not reenable crtc after moving vram start address</title>
<updated>2012-08-26T22:12:11Z</updated>
<author>
<name>Jerome Glisse</name>
<email>jglisse@redhat.com</email>
</author>
<published>2012-07-27T20:32:24Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f5a5aa3a1f996962d9a2a9fe0bb2c096a8b06f37'/>
<id>urn:sha1:f5a5aa3a1f996962d9a2a9fe0bb2c096a8b06f37</id>
<content type='text'>
commit 81ee8fb6b52ec69eeed37fe7943446af1dccecc5 upstream.

It seems we can not update the crtc scanout address. After disabling
crtc, update to base address do not take effect after crtc being
reenable leading to at least frame being scanout from the old crtc
base address. Disabling crtc display request lead to same behavior.

So after changing the vram address if we don't keep crtc disabled
we will have the GPU trying to read some random system memory address
with some iommu this will broke the crtc engine and will lead to
broken display and iommu error message.

So to avoid this, disable crtc. For flicker less boot we will need
to avoid moving the vram start address.

This patch should also fix :

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

Signed-off-by: Jerome Glisse &lt;jglisse@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: correctly order the ring init sequence</title>
<updated>2012-08-26T22:12:11Z</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2012-08-07T07:54:14Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=413b13d9dd468992591bafb55e849c87fb68341c'/>
<id>urn:sha1:413b13d9dd468992591bafb55e849c87fb68341c</id>
<content type='text'>
commit 0d8957c8a90bbb5d34fab9a304459448a5131e06 upstream.

We may only start to set up the new register values after having
confirmed that the ring is truely off. Otherwise the hw might lose the
newly written register values. This is caught later on in the init
sequence, when we check whether the register writes have stuck.

Reviewed-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
Tested-by: Yang Guang &lt;guang.a.yang@intel.com&gt;
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: on hotplug force link training to happen (v2)</title>
<updated>2012-08-09T15:27:50Z</updated>
<author>
<name>Jerome Glisse</name>
<email>jglisse@redhat.com</email>
</author>
<published>2012-07-19T21:25:55Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=073271315cd11ae149fde728a8c0d96fb2ad03eb'/>
<id>urn:sha1:073271315cd11ae149fde728a8c0d96fb2ad03eb</id>
<content type='text'>
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 &lt;jglisse@redhat.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/radeon: fix hotplug of DP to DVI|HDMI passive adapters (v2)</title>
<updated>2012-08-09T15:27:50Z</updated>
<author>
<name>Jerome Glisse</name>
<email>jglisse@redhat.com</email>
</author>
<published>2012-07-19T21:15:56Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a0283f9072a2c289926a8bafb99a231a55eb7517'/>
<id>urn:sha1:a0283f9072a2c289926a8bafb99a231a55eb7517</id>
<content type='text'>
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 &lt;jglisse@redhat.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/radeon: fix non revealent error message</title>
<updated>2012-08-09T15:27:50Z</updated>
<author>
<name>Jerome Glisse</name>
<email>jglisse@redhat.com</email>
</author>
<published>2012-07-17T21:17:16Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ea07d57bea33b7004d1773db115bf62bb7788c99'/>
<id>urn:sha1:ea07d57bea33b7004d1773db115bf62bb7788c99</id>
<content type='text'>
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 &lt;jglisse@redhat.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/radeon: Try harder to avoid HW cursor ending on a multiple of 128 columns.</title>
<updated>2012-08-09T15:27:50Z</updated>
<author>
<name>Michel Dänzer</name>
<email>michel.daenzer@amd.com</email>
</author>
<published>2012-07-17T17:02:09Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4826f249d0b09bb6d8969277b43df9ffc3bccfe5'/>
<id>urn:sha1:4826f249d0b09bb6d8969277b43df9ffc3bccfe5</id>
<content type='text'>
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 &lt;michel.daenzer@amd.com&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: Fix eDP blank screen after S3 resume on HP desktops</title>
<updated>2012-07-16T15:47:39Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2012-06-21T13:30:41Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=9370dd38fdf9c18618efa68cb09daa5bab9885bb'/>
<id>urn:sha1:9370dd38fdf9c18618efa68cb09daa5bab9885bb</id>
<content type='text'>
commit 6db65cbb941f9d433659bdad02b307f6d94465df upstream.

This patch fixes the problem on some HP desktop machines with eDP
which give blank screens after S3 resume.

It turned out that BLC_PWM_CPU_CTL must be written after
BLC_PWM_CPU_CTL2.  Otherwise it doesn't take effect on these
SNB machines.

Tested with 3.5-rc3 kernel.

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

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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