Date: Tue, 27 Dec 2011 22:54:33 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Stefan Bethke <stb@lassitu.de> Cc: "freebsd-embedded@freebsd.org" <freebsd-embedded@freebsd.org> Subject: Re: Updated switch/glue patch? Message-ID: <CAJ-VmomZeHEyue4eaNGm%2Bw67uDBsOH_2bqocXjBGxyxHXStZ_A@mail.gmail.com> In-Reply-To: <EC4D4397-FA60-4CB1-8635-48988215E19A@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> <AFE755D6-E462-40B4-A97B-9261303B3A4F@lassitu.de> <CAJ-VmokwSHN8U2=HJQT9kxFQ9oE-6H2h3KDb%2BMHN1Z8sur9=yw@mail.gmail.com> <45529EC2-73BE-4F69-A9BE-E22D9FEAADD7@lassitu.de> <CAJ-VmonmMASxJZBAd2doX4eV6s5TF-3kCB0pLSMrWM8r0UsCmg@mail.gmail.com> <FC8A0B08-5292-44CC-AEC0-08BF170FCEA4@lassitu.de> <267FB3D6-830E-4A2F-8C1C-A96873EDCD31@lassitu.de> <EC4D4397-FA60-4CB1-8635-48988215E19A@lassitu.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomZeHEyue4eaNGm%2Bw67uDBsOH_2bqocXjBGxyxHXStZ_A>