linux-toradex.git/drivers, branch v3.2.34

sky2: Fix for interrupt handler

2012-11-16T16:47:20+00:00

commit d663d181b9e92d80c2455e460e932d34e7a2a7ae upstream.

Re-enable interrupts if it is not our interrupt

Signed-off-by: Mirko Lindner 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

r8169: use unlimited DMA burst for TX

2012-11-16T16:47:20+00:00

commit aee77e4accbeb2c86b1d294cd84fec4a12dde3bd upstream.

The r8169 driver currently limits the DMA burst for TX to 1024 bytes. I have
a box where this prevents the interface from using the gigabit line to its full
potential. This patch solves the problem by setting TX_DMA_BURST to unlimited.

The box has an ASRock B75M motherboard with on-board RTL8168evl/8111evl
(XID 0c900880). TSO is enabled.

I used netperf (TCP_STREAM test) to measure the dependency of TX throughput
on MTU. I did it for three different values of TX_DMA_BURST ('5'=512, '6'=1024,
'7'=unlimited). This chart shows the results:
http://michich.fedorapeople.org/r8169/r8169-effects-of-TX_DMA_BURST.png

Interesting points:
 - With the current DMA burst limit (1024):
   - at the default MTU=1500 I get only 842 Mbit/s.
   - when going from small MTU, the performance rises monotonically with
     increasing MTU only up to a peak at MTU=1076 (908 MBit/s). Then there's
     a sudden drop to 762 MBit/s from which the throughput rises monotonically
     again with further MTU increases.
 - With a smaller DMA burst limit (512):
   - there's a similar peak at MTU=1076 and another one at MTU=564.
 - With unlimited DMA burst:
   - at the default MTU=1500 I get nice 940 Mbit/s.
   - the throughput rises monotonically with increasing MTU with no strange
     peaks.

Notice that the peaks occur at MTU sizes that are multiples of the DMA burst
limit plus 52. Why 52? Because:
  20 (IP header) + 20 (TCP header) + 12 (TCP options) = 52

The Realtek-provided r8168 driver (v8.032.00) uses unlimited TX DMA burst too,
except for CFG_METHOD_1 where the TX DMA burst is set to 512 bytes.
CFG_METHOD_1 appears to be the oldest MAC version of "RTL8168B/8111B",
i.e. RTL_GIGA_MAC_VER_11 in r8169. Not sure if this MAC version really needs
the smaller burst limit, or if any other versions have similar requirements.

Signed-off-by: Michal Schmidt 
Acked-by: Francois Romieu 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

r8169: Fix WoL on RTL8168d/8111d.

2012-11-16T16:47:19+00:00

commit b00e69dee4ccbb3a19989e3d4f1385bc2e3406cd upstream.

This regression was spotted between Debian squeeze and Debian wheezy
kernels (respectively based on 2.6.32 and 3.2). More info about
Wake-on-LAN issues with Realtek's 816x chipsets can be found in the
following thread: http://marc.info/?t=132079219400004

Probable regression from d4ed95d796e5126bba51466dc07e287cebc8bd19;
more chipsets are likely affected.

Tested on top of a 3.2.23 kernel.

Reported-by: Florent Fourcot 
Tested-by: Florent Fourcot 
Hinted-by: Francois Romieu 
Signed-off-by: Cyril Brulebois 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

r8169: allow multicast packets on sub-8168f chipset.

2012-11-16T16:47:19+00:00

commit 0481776b7a70f09acf7d9d97c288c3a8403fbfe4 upstream.

RTL_GIGA_MAC_VER_35 includes no multicast hardware filter.

Signed-off-by: Nathan Walp 
Suggested-by: Hayes Wang 
Acked-by: Francois Romieu 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

net: usb: Fix memory leak on Tx data path

2012-11-16T16:47:16+00:00

[ Upstream commit 39707c2a3ba5011038b363f84d37c8a98d2d9db1 ]

Driver anchors the tx urbs and defers the urb submission if
a transmit request comes when the interface is suspended.
Anchoring urb increments the urb reference count. These
deferred urbs are later accessed by calling usb_get_from_anchor()
for submission during interface resume. usb_get_from_anchor()
unanchors the urb but urb reference count remains same.
This causes the urb reference count to remain non-zero
after usb_free_urb() gets called and urb never gets freed.
Hence call usb_put_urb() after anchoring the urb to properly
balance the reference count for these deferred urbs. Also,
unanchor these deferred urbs during disconnect, to free them
up.

Signed-off-by: Hemant Kumar 
Acked-by: Oliver Neukum 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

drm/vmwgfx: Fix a case where the code would BUG when trying to pin GMR memory

2012-11-16T16:47:14+00:00

commit afcc87aa6a233e52df73552dc1dc9ae3881b7cc8 upstream.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Dmitry Torokhov 
Cc: linux-graphics-maintainer@vmware.com
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings

drm/vmwgfx: Fix hibernation device reset

2012-11-16T16:47:13+00:00

commit 95e8f6a21996c4cc2c4574b231c6e858b749dce3 upstream.

The device would not reset properly when resuming from hibernation.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Dmitry Torokhov 
Cc: linux-graphics-maintainer@vmware.com
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings

drm: restore open_count if drm_setup fails

2012-11-16T16:47:10+00:00

commit 0f1cb1bd94a9c967cd4ad3de51cfdabe61eb5dcc upstream.

If drm_setup (called at first open) fails, the whole
open call has failed, so we should not keep the
open_count incremented.

Signed-off-by: Ilija Hadzic 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings

hwmon: (w83627ehf) Force initial bank selection

2012-11-16T16:47:09+00:00

commit 3300fb4f88688029fff8dfb9ec0734f6e4cba3e7 upstream.

Don't assume bank 0 is selected at device probe time. This may not be
the case. Force bank selection at first register access to guarantee
that we read the right registers upon driver loading.

Signed-off-by: Jean Delvare 
Reviewed-by: Guenter Roeck 
Signed-off-by: Ben Hutchings

DRM/Radeon: Fix Load Detection on legacy primary DAC.

2012-11-16T16:47:07+00:00

commit 83325d072185899b706de2956170b246585aaec9 upstream.

An uninitialized variable led to broken load detection.

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