smc911x driver frame alignment patch
authorValentin Yakovenkov <yakovenkov@niistt.ru>
Fri, 23 Apr 2010 05:40:23 +0000 (09:40 +0400)
committerBen Warren <biggerbadderben@gmail.com>
Mon, 3 May 2010 21:52:49 +0000 (14:52 -0700)
commitbd75db3feb9a8e4123b76006dbe582b71adbf22f
treeb4007dcf9f70ee8c46439d854bd56f2bc03693a2
parentf0588fdf921c63f84051923bb29eb4255d62a6e7
smc911x driver frame alignment patch

SMSC911x chips have alignment function to allow frame payload data
(which comes after 14-bytes ethernet header) to be aligned at some
boundary when reading it from fifo (usually - 4 bytes boundary).
This is done by inserting fake zeros bytes BEFORE actual frame data when
reading from SMSC's fifo.
This function controlled by RX_CFG register. There are bits that
represents amount of fake bytes to be inserted.

Linux uses alignment of 4 bytes. Ethernet frame header is 14 bytes long,
so we need to add 2 fake bytes to get payload data aligned at 4-bytes
boundary.
Linux driver does this by adding IP_ALIGNMENT constant (defined at
skb.h) when calculating fifo data length. All network subsystem of Linux
uses this constant too when calculating different offsets.

But u-boot does not use any packet data alignment, so we don't need to
add anything when calculating fifo data length.
Moreover, driver zeros the RX_CFG register just one line up, so chip
does not insert any fake data at the beginig. So calculated data length
is always bigger by 1 word.

It seems that at almost every packet read we get an underflow condition
at fifo and possible corruption of data. Especially at continuous
transfers, such as tftp.

Just after removing this magic addition, I've got tftp transfer speed as
it aught to be at 100Mbps. It was really slow before.

It seems that fifo underflow occurs only when using byte packing on
32-bit blackfin bus (may be because of very small delay between reads).

Signed-off-by: Valentin Yakovenkov <yakovenkov@niistt.ru>
Signed-off-by: Ben Warren <biggerbadderben@gmail.com>
drivers/net/smc911x.c