Updated switch/glue patch?

[Stefan Bethke]

Am 28.12.2011 um 07:54 schrieb Adrian Chadd:

> Hi,
> 
> I have a few questions:
> 
> * are you testing this all out with the -HEAD debugging enabled? ie,
> witness, invariants, etc?

Yes, just for my last test I disabled witness to run the test with max. speed.

> * Why'd you rename the mutex in the rtl8366rb driver from sc->sc_mtx
> to sc->smi_mtx ?

That's a spurious change; in an interim version, I had two mutexes (one for the callout, one for the bus access).

> * Why are you creating the callout w/out the lock now, rather than
> with a lock? non-locked callouts make it more difficult to cancel
> cleanly/atomically.

With the mutex, I had trouble.  I can't recall right now what exactly it was.

> * Are this smi_*_lockheld() functions designed to be called with
> sc_smi_mtx held? If so, add a lock assertion macro there.

Will do.

> * You call DELAY() with the lock held:
> 
> +                               DELAY(RTL_IICBUS_PHYDELAY); /* chip
> needs time to talk to PHY */
> 
> .. why not use pause() instead? I don't like how it could result in
> that particular mutex being held for far, far too long (and I'm
> starting to be weary of mutexes being used as a way of serialising
> slow device access, but I digress)..

I'll give it a shot.

> * You've implemented retries here, which make sense. How then does the
> Linux driver work? Or is it doing retries and I just don't remember.

The linux driver, as far as I can tell, never actually talks to the PHYs, unless you compile it with debugging.

> * The older iicbb code with the original timeout doesn't result in any
> timeouts at all, just FYI. I'm happy with the idea of a faster, more
> efficient iicbb where the driver also handles timeouts correctly.. I
> just wonder whether we're making it more complicated.

I'm fairly confident that the HEAD iicbb.c is slow and partially broken (the waitack function in particular).  I believe the reason you're seeing no timeouts with that code is due to it being slow, plus not reporting errors properly.

> How is it OpenWRT/Linux doesn't end up suffering from these high CPU
> spikes when doing bitbanged GPIO? Or are they seeing them but
> preemption is just masking it?

They do not talk to the PHYs.

BTW, with the newest iteration of rtl8366rb.c, the callout reads three registers, instead of five PHYs times three registers, which turns into 5*3*3=30 rtl8366rb register accesses.

In my testing, I couln't "feel" the slowdown anymore, even with WITNESS enabled.


Stefan

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