From owner-freebsd-embedded@FreeBSD.ORG Wed Dec 28 11:15:26 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F945106564A; Wed, 28 Dec 2011 11:15:26 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id AF09B8FC12; Wed, 28 Dec 2011 11:15:25 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 87D6B11287A; Wed, 28 Dec 2011 11:15:24 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Stefan Bethke In-Reply-To: Date: Wed, 28 Dec 2011 12:15:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <12538AED-175C-4B1E-BF05-6FD05D14CE70@lassitu.de> References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> <2CBD8651-E132-49DC-A082-37A8F5C626EA@bsdimp.com> <45529EC2-73BE-4F69-A9BE-E22D9FEAADD7@lassitu.de> <267FB3D6-830E-4A2F-8C1C-A96873EDCD31@lassitu.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1251.1) Cc: "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 11:15:26 -0000 Am 28.12.2011 um 07:54 schrieb Adrian Chadd: > Hi, >=20 > I have a few questions: >=20 > * 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: >=20 > + DELAY(RTL_IICBUS_PHYDELAY); /* chip > needs time to talk to PHY */ >=20 > .. 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=3D30 rtl8366rb register accesses. In my testing, I couln't "feel" the slowdown anymore, even with WITNESS = enabled. Stefan --=20 Stefan Bethke Fon +49 151 14070811