From owner-freebsd-embedded@FreeBSD.ORG Tue Dec 20 07:39:22 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 4A239106566B; Tue, 20 Dec 2011 07:39:22 +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 ECEB18FC0A; Tue, 20 Dec 2011 07:39:21 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id BFD4210CC4C; Tue, 20 Dec 2011 08:39:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Stefan Bethke In-Reply-To: Date: Tue, 20 Dec 2011 08:39:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Adrian Chadd X-Mailer: Apple Mail (2.1251.1) Cc: Oleksandr Tymoshenko , "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: Tue, 20 Dec 2011 07:39:22 -0000 Am 20.12.2011 um 04:53 schrieb Adrian Chadd: > Hi, >=20 > 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. :) >=20 > With the default per-bit sleep of 10uS, a rough calculation is: >=20 > * 3 sleeps per bit: 30uS per bit > * 8 bits per byte > * 1 bit for ACK > * =3D=3D 12 bits per byte: 360uS a byte >=20 > 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. >=20 > 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 =3D 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 --=20 Stefan Bethke Fon +49 151 14070811