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>
index | next in thread | previous in thread | raw e-mail
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? Adrianhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomZeHEyue4eaNGm%2Bw67uDBsOH_2bqocXjBGxyxHXStZ_A>