<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers, branch v3.11.3</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>cw1200: Don't perform SPI transfers in interrupt context</title>
<updated>2013-10-01T16:41:02+00:00</updated>
<author>
<name>Solomon Peachy</name>
<email>pizza@shaftnet.org</email>
</author>
<published>2013-08-28T00:29:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2236ad2913d353ecb1d78231600372def5c94473'/>
<id>2236ad2913d353ecb1d78231600372def5c94473</id>
<content type='text'>
commit aec8e88c947b7017e2b4bbcb68a4bfc4a1f8ad35 upstream.

When we get an interrupt from the hardware, the first thing the driver does
is tell the device to mask off the interrupt line.  Unfortunately this
involves a SPI transaction in interrupt context.  Some (most?) SPI
controllers perform the transfer asynchronously and try to sleep.
This is bad, and triggers a BUG().

So, work around this by using adding a hwbus hook for the cw1200 driver
core to call.  The cw1200_spi driver translates this into
irq_disable()/irq_enable() calls instead, which can safely be called in
interrupt context.

Apparently the platforms I used to develop the cw1200_spi driver used
synchronous spi_sync() implementations, which is why this didn't surface
until now.

Many thanks to Dave Sizeburns for the inital bug report and his services
as a tester.

Signed-off-by: Solomon Peachy &lt;pizza@shaftnet.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit aec8e88c947b7017e2b4bbcb68a4bfc4a1f8ad35 upstream.

When we get an interrupt from the hardware, the first thing the driver does
is tell the device to mask off the interrupt line.  Unfortunately this
involves a SPI transaction in interrupt context.  Some (most?) SPI
controllers perform the transfer asynchronously and try to sleep.
This is bad, and triggers a BUG().

So, work around this by using adding a hwbus hook for the cw1200 driver
core to call.  The cw1200_spi driver translates this into
irq_disable()/irq_enable() calls instead, which can safely be called in
interrupt context.

Apparently the platforms I used to develop the cw1200_spi driver used
synchronous spi_sync() implementations, which is why this didn't surface
until now.

Many thanks to Dave Sizeburns for the inital bug report and his services
as a tester.

Signed-off-by: Solomon Peachy &lt;pizza@shaftnet.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>cw1200: Prevent a lock-related hang in the cw1200_spi driver</title>
<updated>2013-10-01T16:41:02+00:00</updated>
<author>
<name>Solomon Peachy</name>
<email>pizza@shaftnet.org</email>
</author>
<published>2013-08-28T00:29:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=524a992af32af99a4fa8521640ba5bb38fde41d1'/>
<id>524a992af32af99a4fa8521640ba5bb38fde41d1</id>
<content type='text'>
commit 85ba8f529c57ac6e2fca9be0d9e17920a1afb2e8 upstream.

The cw1200_spi driver tries to mirror the cw1200_sdio driver's lock
API, which relies on sdio_claim_host/sdio_release_host to serialize
hardware operations across multiple threads.

Unfortunately the implementation was flawed, as it lacked a way to wake
up the lock requestor when there was contention, often resulting in a
hang.

This problem was uncovered while trying to fix the
spi-transfers-in-interrupt-context BUG() corrected in the previous
patch.  Many thanks to Dave Sizeburns for his assistance in fixing this.

Signed-off-by: Solomon Peachy &lt;pizza@shaftnet.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 85ba8f529c57ac6e2fca9be0d9e17920a1afb2e8 upstream.

The cw1200_spi driver tries to mirror the cw1200_sdio driver's lock
API, which relies on sdio_claim_host/sdio_release_host to serialize
hardware operations across multiple threads.

Unfortunately the implementation was flawed, as it lacked a way to wake
up the lock requestor when there was contention, often resulting in a
hang.

This problem was uncovered while trying to fix the
spi-transfers-in-interrupt-context BUG() corrected in the previous
patch.  Many thanks to Dave Sizeburns for his assistance in fixing this.

Signed-off-by: Solomon Peachy &lt;pizza@shaftnet.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>skge: fix broken driver</title>
<updated>2013-10-01T16:41:01+00:00</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2013-09-19T18:13:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=80a96c500ef5de9f3ceca4bdb02a3155b43297a8'/>
<id>80a96c500ef5de9f3ceca4bdb02a3155b43297a8</id>
<content type='text'>
commit c194992cbe71c20bb3623a566af8d11b0bfaa721 upstream.

The patch 136d8f377e1575463b47840bc5f1b22d94bf8f63 broke the skge driver.
Note this part of the patch:
+               if (skge_rx_setup(skge, e, nskb, skge-&gt;rx_buf_size) &lt; 0) {
+                       dev_kfree_skb(nskb);
+                       goto resubmit;
+               }
+
                pci_unmap_single(skge-&gt;hw-&gt;pdev,
                                 dma_unmap_addr(e, mapaddr),
                                 dma_unmap_len(e, maplen),
                                 PCI_DMA_FROMDEVICE);
                skb = e-&gt;skb;
                prefetch(skb-&gt;data);
-               skge_rx_setup(skge, e, nskb, skge-&gt;rx_buf_size);

The function skge_rx_setup modifies e-&gt;skb to point to the new skb. Thus,
after this change, the new buffer, not the old, is returned to the
networking stack.

This bug is present in kernels 3.11, 3.11.1 and 3.12-rc1. The patch should
be queued for 3.11-stable.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Reported-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Reported-by: Vasiliy Glazov &lt;vascom2@gmail.com&gt;
Tested-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c194992cbe71c20bb3623a566af8d11b0bfaa721 upstream.

The patch 136d8f377e1575463b47840bc5f1b22d94bf8f63 broke the skge driver.
Note this part of the patch:
+               if (skge_rx_setup(skge, e, nskb, skge-&gt;rx_buf_size) &lt; 0) {
+                       dev_kfree_skb(nskb);
+                       goto resubmit;
+               }
+
                pci_unmap_single(skge-&gt;hw-&gt;pdev,
                                 dma_unmap_addr(e, mapaddr),
                                 dma_unmap_len(e, maplen),
                                 PCI_DMA_FROMDEVICE);
                skb = e-&gt;skb;
                prefetch(skb-&gt;data);
-               skge_rx_setup(skge, e, nskb, skge-&gt;rx_buf_size);

The function skge_rx_setup modifies e-&gt;skb to point to the new skb. Thus,
after this change, the new buffer, not the old, is returned to the
networking stack.

This bug is present in kernels 3.11, 3.11.1 and 3.12-rc1. The patch should
be queued for 3.11-stable.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Reported-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Reported-by: Vasiliy Glazov &lt;vascom2@gmail.com&gt;
Tested-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: avoid UVD corruptions on AGP cards</title>
<updated>2013-10-01T16:41:01+00:00</updated>
<author>
<name>Christian König</name>
<email>christian.koenig@amd.com</email>
</author>
<published>2013-09-15T11:31:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0160ad17164c340a6b83d69e481624b2509f64c6'/>
<id>0160ad17164c340a6b83d69e481624b2509f64c6</id>
<content type='text'>
commit 4f66c59922cbcda14c9e103e6c7f4ee616360d43 upstream.

Putting everything into VRAM seems to help.

Signed-off-by: Christian König &lt;christian.koenig@amd.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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4f66c59922cbcda14c9e103e6c7f4ee616360d43 upstream.

Putting everything into VRAM seems to help.

Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: fix panel scaling with eDP and LVDS bridges</title>
<updated>2013-10-01T16:41:01+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2013-09-13T22:33:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ec44008171fd346c31d8f54ff2e05748fa3b88f7'/>
<id>ec44008171fd346c31d8f54ff2e05748fa3b88f7</id>
<content type='text'>
commit 855f5f1d882a34e4e9dd27b299737cd3508a5624 upstream.

We were using the wrong set_properly callback so we always
ended up with Full scaling even if something else (Center or
Full aspect) was selected.

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

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 855f5f1d882a34e4e9dd27b299737cd3508a5624 upstream.

We were using the wrong set_properly callback so we always
ended up with Full scaling even if something else (Center or
Full aspect) was selected.

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

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon/dpm/rs780: don't enable sclk scaling if not required</title>
<updated>2013-10-01T16:41:01+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2013-09-13T14:55:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a6ec1251f171fe06eda183ea40ac975336fa6a52'/>
<id>a6ec1251f171fe06eda183ea40ac975336fa6a52</id>
<content type='text'>
commit e40210cca98068835acd5a4fe760bf96b3a1aa48 upstream.

If the low and high sclks are the same, there is no need to
enable sclk scaling.  This causes display stability issues on
certain boards.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60857

Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e40210cca98068835acd5a4fe760bf96b3a1aa48 upstream.

If the low and high sclks are the same, there is no need to
enable sclk scaling.  This causes display stability issues on
certain boards.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60857

Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon/dpm: fix fallback for empty UVD clocks</title>
<updated>2013-10-01T16:41:01+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2013-09-10T13:40:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=93a6c524b6c1822501d825c501fc778a7eb22fed'/>
<id>93a6c524b6c1822501d825c501fc778a7eb22fed</id>
<content type='text'>
commit 84f3d9f7b4781dea6e11dcaf7f81367c1b39fef0 upstream.

Some older 6xx-7xx boards didn't always fill in the
UVD clocks properly in the UVD power states.  This
leads to the driver trying to set a 0 clock which
results in slow or broken UVD playback.

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

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

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 84f3d9f7b4781dea6e11dcaf7f81367c1b39fef0 upstream.

Some older 6xx-7xx boards didn't always fill in the
UVD clocks properly in the UVD power states.  This
leads to the driver trying to set a 0 clock which
results in slow or broken UVD playback.

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

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

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon/dpm: handle bapm on trinity</title>
<updated>2013-10-01T16:41:01+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2013-09-09T22:56:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2777fa045530884335b9d570b4db51df753a768d'/>
<id>2777fa045530884335b9d570b4db51df753a768d</id>
<content type='text'>
commit ef4e03658420bbf91365647615460668c2510e79 upstream.

bapm is a power management feature for handling the
power budget between the CPU and GPU on APUs.  This
patch adds support for enabling or disabling it.
For now disable it by default.  Enabling it properly
requires quite a bit more work and will be addressed
in a separate patch.

This patch fixes hangs on boot on certain trinity
laptops when the system is on battery power.

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

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ef4e03658420bbf91365647615460668c2510e79 upstream.

bapm is a power management feature for handling the
power budget between the CPU and GPU on APUs.  This
patch adds support for enabling or disabling it.
For now disable it by default.  Enabling it properly
requires quite a bit more work and will be addressed
in a separate patch.

This patch fixes hangs on boot on certain trinity
laptops when the system is on battery power.

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

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon/atom: workaround vbios bug in transmitter table on rs880 (v2)</title>
<updated>2013-10-01T16:41:01+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2013-09-09T14:54:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=00a9b0b1970d5a818cb57ae03d8213c71a460738'/>
<id>00a9b0b1970d5a818cb57ae03d8213c71a460738</id>
<content type='text'>
commit 91f3a6aaf280294b07c05dfe606e6c27b7ba3c72 upstream.

The OUTPUT_ENABLE action jumps past the point in the coder where
the data_offset is set on certain rs780 cards.  This worked
previously because the OUTPUT_ENABLE action is always called
immediately after the ENABLE action so the data_offset remained
set.  In 6f8bbaf568c7f2c497558bfd04654c0b9841ad57
(drm/radeon/atom: initialize more atom interpretor elements to 0),
we explictly reset data_offset to 0 between atom calls which then
caused this to fail.  The fix is to just skip calling the
OUTPUT_ENABLE action on the problematic chipsets.  The ENABLE
action does the same thing and more.  Ultimately, we could
probably drop the OUTPUT_ENABLE action all together on DCE3
asics.

fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60791

v2: only rs880 seems to be affected

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

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 91f3a6aaf280294b07c05dfe606e6c27b7ba3c72 upstream.

The OUTPUT_ENABLE action jumps past the point in the coder where
the data_offset is set on certain rs780 cards.  This worked
previously because the OUTPUT_ENABLE action is always called
immediately after the ENABLE action so the data_offset remained
set.  In 6f8bbaf568c7f2c497558bfd04654c0b9841ad57
(drm/radeon/atom: initialize more atom interpretor elements to 0),
we explictly reset data_offset to 0 between atom calls which then
caused this to fail.  The fix is to just skip calling the
OUTPUT_ENABLE action on the problematic chipsets.  The ENABLE
action does the same thing and more.  Ultimately, we could
probably drop the OUTPUT_ENABLE action all together on DCE3
asics.

fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60791

v2: only rs880 seems to be affected

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

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon/r6xx: add a stubbed out set_uvd_clocks callback</title>
<updated>2013-10-01T16:41:01+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2013-09-05T13:52:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4a22ee8332dbbc138917e6838fafc5bddac4f906'/>
<id>4a22ee8332dbbc138917e6838fafc5bddac4f906</id>
<content type='text'>
commit 1b9ba70a49ba92e910d8e5df702edf8c1858cecf upstream.

Certain r6xx boards use the same power state for both UVD
and other things.  Since we don't support UVD on r6xx boards
at the moment, there was no callback installed for setting
the UVD clocks, however, on systems that use the same power
state, this leads to a NULL pointer dereference.  Fill
in a stubbed out implementation for now to avoid the crash.

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

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

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1b9ba70a49ba92e910d8e5df702edf8c1858cecf upstream.

Certain r6xx boards use the same power state for both UVD
and other things.  Since we don't support UVD on r6xx boards
at the moment, there was no callback installed for setting
the UVD clocks, however, on systems that use the same power
state, this leads to a NULL pointer dereference.  Fill
in a stubbed out implementation for now to avoid the crash.

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

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

</pre>
</div>
</content>
</entry>
</feed>
