Date: Tue, 20 Dec 2011 08:39:19 +0100 From: Stefan Bethke <stb@lassitu.de> To: Adrian Chadd <adrian@freebsd.org> Cc: Oleksandr Tymoshenko <gonzo@freebsd.org>, "freebsd-embedded@freebsd.org" <freebsd-embedded@freebsd.org> Subject: Re: Updated switch/glue patch? Message-ID: <AFE755D6-E462-40B4-A97B-9261303B3A4F@lassitu.de> In-Reply-To: <CAJ-VmomySBQeMqr8meQDpSLBC1%2By_%2BvMQsSt9OWFaCA67O8G=w@mail.gmail.com> References: <CAJ-Vmon8%2BOXQ4g752zZEB-O0BR0sFWO0QUvw--xp2jsBDkx6tQ@mail.gmail.com> <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <CAJ-Vmo=Y8pp4iFnw%2B1hcPae6QXFboz=a7puwgC1kVSZ3JwMgPQ@mail.gmail.com> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> <CAJ-VmonrnJ7cC6u2LsL9AGusz_%2BkSwY62Rr1__sg5U_NynJ1SQ@mail.gmail.com> <CAJ-Vmo=WSN1oLM=B2HqSHrWyOaOD9BSwwu8=1Wys0CLRJ_N-TA@mail.gmail.com> <C637C171-A1A2-4296-84FA-6DE97137DC42@lassitu.de> <CAJ-Vmon2boy7OCh_4O0MeCi0yCdZu0OYb5dxHCEK=-%2B46zBGtg@mail.gmail.com> <CAJ-Vmoku5eLEYi5_DXVxK=0=4Ewn2aGepv3YUw4ApuVh_7y2%2Bw@mail.gmail.com> <CAJ-VmonvpnaS1rAO%2BsDRh1E5WfsrZTYE297Kc96prhfKjrM89Q@mail.gmail.com> <CAJ-VmokQxQs2DUKL=ONyxnnS7Q28ytmwZJ_thqvc4SvMkmS=cQ@mail.gmail.com> <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> <C0BF20FD-E30F-4E9C-A0FE-500BE4807B99@bsdimp.com> <CAJ-VmokgiQCEG4et3X=3o_MuCMkO9MqkKqa-fjdpEqQNucn=Lw@mail.gmail.com> <2CBD8651-E132-49DC-A082-37A8F5C626EA@bsdimp.com> <CAJ-VmomERMdiMA7bzTeQyLR5YXXiJVXyjAzJfH6O-VvexpCcmg@mail .gmail.com> <CAJ-VmomySBQeMqr8meQDpSLBC1%2By_%2BvMQsSt9OWFaCA67O8G=w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <stb@lassitu.de> Fon +49 151 14070811
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AFE755D6-E462-40B4-A97B-9261303B3A4F>