Date: Tue, 20 Dec 2011 07:25:46 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Stefan Bethke <stb@lassitu.de> Cc: Oleksandr Tymoshenko <gonzo@freebsd.org>, "freebsd-embedded@freebsd.org" <freebsd-embedded@freebsd.org> Subject: Re: Updated switch/glue patch? Message-ID: <CAJ-Vmo=ERixAN96QSOaaej8avPHYkGC28AJZErdEhO0%2B=1R0Pw@mail.gmail.com> In-Reply-To: <AFE755D6-E462-40B4-A97B-9261303B3A4F@lassitu.de> 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-VmomySBQeMqr8meQDpSLBC1%2By_%2BvMQsSt9OWFaCA67O8G=w@mail.gmail.com> <AFE755D6-E462-40B4-A97B-9261303B3A4F@lassitu.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19 December 2011 23:39, Stefan Bethke <stb@lassitu.de> wrote: > I2C runs at 100kHz, so a total delay per bit of 10 microseconds should al= ways work. =A0The datasheet for the RTL8366S shows that 4 microseconds for = SCL high and low, respectively, are the minimum, so it's even a bit faster. So that's "set SDA and toggle SCA" total? > Register access transfers 5 bytes (command, address*2, data*2) plus the a= ck bits, plus start and stop, for a total of 5*(8+1) + 2 =3D 47 clock cycle= s. At 100 kHz, that's 470 microseconds, with a delay of 8 ms per cycle it's= 376 microseconds. Right. > 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. =A0And looking at the MIB stats registers, we're f= acing the same question. Again, right. At this point we likely should just require preemption if we're going to try tinkering with this stuff. >> 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 statu= s and speed. =A0We could either forgo the generic PHY code completely, or d= o just the status check ourselves. It wouldn't be the first time that a custom PHY is used, right? :) One byte per port for link status and speed is going to be a lot nicer to deal with. The delay is still insanely long, but it's better than polling all of those status registers. So yes, it may be worthwhile just implementing a custom PHY interface in that file and using that, rather than using ukphy. Although ukphy works, it takes a long, long time to do anything. Re: MIB stats. That's going to have the same problem, but we can likely deal with it by simply doing it from userspace where the kernel _can_ interrupt. :) > I'm of two minds whether reusing the miibus code really is a good idea. = =A0The problem I have with it is mainly that it assumes that there is a str= uct ifnet that the miibus is attached to, and that that ifnet has exactly o= ne running phy. =A0So in my current implementation, I've simply created one= ifnet for each of the five ports that have PHYs on them. I personally think your current method of doing it is fine. The switch driver is small, it's reusing the media handling infrastructure; it doesn't look like you'll have to do much to write a custom PHY to replace ukphy. > On the other hand, I would hate to duplicate media handling code from ukp= hy 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 t= hey need it. > > I'll try and catch up with your git branch today. Thanks. I'll look at your subsequent email (iicbb_ack()) in a moment. I think the short-term way to move forward is to include a bare-bones replacement PHY just for that switch and disable MIB stats polling. That should be enough for the short term. I'd like to try and wrap this up so we can move onto other areas of the switch stuff - the management tool, the switch bus backend (ie, having a switch driver sit on either i2c, spi, miibus, which physical port does it hang off of, etc.) and looking at including other switch devices (ar8216/ar8316 at least to begin with.) Hm, and I also need to see whether it's worthwhile keeping the vlangroup config method, or whether the ar8216/ar8316 (and the others supported in zrouter) really want to support a set of VLANs per port. The AR8316 datasheet describes how it works - there's a table of known VLANs and a bitmap in each VLAN entry describing which ports are able to be used. There's also a way to configure port isolation, and the ingres/egres port is configured by a magic 2 byte header added to each ethernet frame. I don't know what the other switches offer. It's possible we need to support both - so we'll need a capability bit, identifying which API is to be used. So there's still lots to do. :) Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=ERixAN96QSOaaej8avPHYkGC28AJZErdEhO0%2B=1R0Pw>