Updated switch/glue patch?

[Stefan Bethke]

Am 20.12.2011 um 04:53 schrieb Adrian Chadd:

> Hi,
> 
> I've just dumped some more locking fixes into -HEAD. I've also changed
> iicbb.c a little so it has a configurable udelay. Sorry Stefan, you're
> going to have to rebase your iicbb changes. :)
> 
> With the default per-bit sleep of 10uS, a rough calculation is:
> 
> * 3 sleeps per bit: 30uS per bit
> * 8 bits per byte
> * 1 bit for ACK
> * == 12 bits per byte: 360uS a byte
> 
> Each transaction is what, 5 bytes or 6 btyes total? I'll say 6 bytes,
> to be conservative. That's 2.1ms a transaction. Say thirty register
> accesses a second (for 5 switch PHY ports) - 63mS. I still think
> that's a bit low. But that's minimum 63mS of DELAY(), each second.
> Nothing else occurs during that.
> 
> I've dropped the udelay parameter from 10 to 2 and had things work
> successfully. It still wastes a significant fraction of 100mS of CPU
> time each second.

I2C runs at 100kHz, so a total delay per bit of 10 microseconds should always work.  The datasheet for the RTL8366S shows that 4 microseconds for SCL high and low, respectively, are the minimum, so it's even a bit faster.

Register access transfers 5 bytes (command, address*2, data*2) plus the ack bits, plus start and stop, for a total of 5*(8+1) + 2 = 47 clock cycles. At 100 kHz, that's 470 microseconds, with a delay of 8 ms per cycle it's 376 microseconds.

We could try and see how much quicker we can make the transaction, but I think even at an order of magnitude faster, polling 2*5 PHY registers, it's taking up too much CPU.  And looking at the MIB stats registers, we're facing the same question.

> Sorry, but there has to be a better way to do this. Is it possible to
> just only poll a minimal set of PHY registers each second, rather than
> polling them all?


There is RTL8366RB_PLSR_BASE which has a byte per port, giving link status and speed.  We could either forgo the generic PHY code completely, or do just the status check ourselves.

I'm of two minds whether reusing the miibus code really is a good idea.  The problem I have with it is mainly that it assumes that there is a struct ifnet that the miibus is attached to, and that that ifnet has exactly one running phy.  So in my current implementation, I've simply created one ifnet for each of the five ports that have PHYs on them.

On the other hand, I would hate to duplicate media handling code from ukphy and that infrastrucure inside the switch driver.

At any rate, we should make PHY status polling and the MIB stats polling optional (e.g. off, on demand, periodic), so users can decide if and when they need it.

I'll try and catch up with your git branch today.


Stefan

-- 
Stefan Bethke <stb at lassitu.de>   Fon +49 151 14070811