From owner-freebsd-embedded@FreeBSD.ORG Wed Dec 28 06:54:35 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 28CE0106566C for ; Wed, 28 Dec 2011 06:54:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id BE4C68FC12 for ; Wed, 28 Dec 2011 06:54:34 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so16722603vcb.13 for ; Tue, 27 Dec 2011 22:54:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HMoyTMg5skoE1yR01HXbrdVebsMS+noxPGDajT/48sA=; b=OodDQ1qvkkCW0tq4JX1Uus6KIIIdAs6W1/5OCK4h97o7YjLY9/HflpqQfEiEy6wDcY 7HE9apjrV0TtElXeIvF0H8kVTbcFPWaScnlcQr+6QMrvbaI6K+SEorTwFokqMJLNIwg3 SR0i/35W+0w77GLdHcpmd+/DQoP35GEy9ikuA= MIME-Version: 1.0 Received: by 10.220.213.200 with SMTP id gx8mr18065124vcb.13.1325055274028; Tue, 27 Dec 2011 22:54:34 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Tue, 27 Dec 2011 22:54:33 -0800 (PST) In-Reply-To: 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> Date: Tue, 27 Dec 2011 22:54:33 -0800 X-Google-Sender-Auth: qaTAV-xJ06CQKfzwbe0ne18ZXl8 Message-ID: From: Adrian Chadd To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-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 06:54:35 -0000 Hi, I have a few questions: * are you testing this all out with the -HEAD debugging enabled? ie, witness, invariants, etc? * Why'd you rename the mutex in the rtl8366rb driver from sc->sc_mtx to sc->smi_mtx ? * 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. * Are this smi_*_lockheld() functions designed to be called with sc_smi_mtx held? If so, add a lock assertion macro there. * 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).. * 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 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. 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? Adrian