Thread (22 messages) flat view 22 messages, 3 authors, 2020-03-27

Re: [PATCH V2 00/14] net: ks8851: Unify KS8851 SPI and MLL drivers

From: Marek Vasut <marex@denx.de>
Date: 2020-03-27 18:22:26

On 3/26/20 8:02 PM, Lukas Wunner wrote:
quoted hunk ↗ jump to hunk
On Wed, Mar 25, 2020 at 04:05:29PM +0100, Marek Vasut wrote:
quoted
The KS8851SNL/SNLI and KS8851-16MLL/MLLI/MLLU are very much the same pieces
of silicon, except the former has an SPI interface, while the later has a
parallel bus interface. Thus far, Linux has two separate drivers for each
and they are diverging considerably.

This series unifies them into a single driver with small SPI and parallel
bus specific parts. The approach here is to first separate out the SPI
specific parts into a separate file, then add parallel bus accessors in
another separate file and then finally remove the old parallel bus driver.
The reason for replacing the old parallel bus driver is because the SPI
bus driver is much higher quality.
With this series, ks8851.ko (SPI variant) failed to compile as a module.
I got it working by renaming ks8851.c to ks8851_common.c and applying
the following change to the Makefile:
--- a/drivers/net/ethernet/micrel/Makefile
+++ b/drivers/net/ethernet/micrel/Makefile
@@ -5,6 +5,8 @@
 
 obj-$(CONFIG_ARM_KS8695_ETHER) += ks8695net.o
 obj-$(CONFIG_KS8842) += ks8842.o
-obj-$(CONFIG_KS8851) += ks8851.o ks8851_spi.o
-obj-$(CONFIG_KS8851_MLL) += ks8851.o ks8851_par.o
+obj-$(CONFIG_KS8851) += ks8851.o
+ks8851-objs = ks8851_common.o ks8851_spi.o
+obj-$(CONFIG_KS8851_MLL) += ks8851_mll.o
+ks8851_mll-objs = ks8851_common.o ks8851_par.o
 obj-$(CONFIG_KSZ884X_PCI) += ksz884x.o
This series breaks reading the MAC address from an EEPROM attached to
the KSZ8851SNLI:
The MAC address stored in the EEPROM was c8:3e:a7:99:ef:aa.
The MAC address was read as 3e:c8:99:a7:ef:aa with this series.
Note: The MAC address starts at the third byte in the EEPROM and is
stored as aa:ef:99:a7:3e:c8, i.e. in reverse order.  (I think the
spec says something else but it appears to be wrong.)

Assigning a MAC address with "ifconfig eth1 hw ether <mac>" (which I
believe ends up calling ks8851_write_mac_addr()) worked fine.
I added fixes for those.
The performance degredation with this series is as follows:

Latency (ping) without this series:
  rtt min/avg/max/mdev = 0.982/1.776/3.756/0.027 ms, ipg/ewma 2.001/1.761 ms
With this series:
  rtt min/avg/max/mdev = 1.084/1.811/3.546/0.040 ms, ipg/ewma 2.020/1.814 ms

Throughput (scp) without this series:
  Transferred: sent 369780976, received 66088 bytes, in 202.0 seconds
  Bytes per second: sent 1830943.5, received 327.2
With this series:
  Transferred: sent 369693896, received 67588 bytes, in 210.5 seconds
  Bytes per second: sent 1755952.6, received 321.0
Maybe some iperf would be better here ?
SPI clock is 25 MHz.  The chip would allow up to 40 MHz, but the board
layout limits that.

I suspect the performance regression is not only caused by the
suboptimal 16 byte instead of 8 byte accesses (and 2x16 byte instead
of 32 byte accesses), but also because the accessor functions cannot
be inlined.  It would be better if they were included from a header
file as static inlines.  The performance regression would then likely
disappear.
I did another measurement today and I found out that while RX on the old
KS8851-MLL driver runs at ~50 Mbit/s , TX runs at ~80 Mbit/s . With this
new driver, RX still runs at ~50 Mbit/s, but TX runs also at 50 Mbit/s .
That's real bad. Any ideas how to debug/profile this one ?
I guess the good news is that it otherwise worked out of the box.
Great
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help