Date: Sun, 18 Dec 2011 11:17:50 +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: <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> In-Reply-To: <CAJ-VmokQxQs2DUKL=ONyxnnS7Q28ytmwZJ_thqvc4SvMkmS=cQ@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 18.12.2011 um 11:11 schrieb Adrian Chadd: > On 18 December 2011 01:54, Adrian Chadd <adrian@freebsd.org> wrote: >=20 >> Just as a side note - reducing the udelay value from 10 to 1 in my = git >> tree doesn't stop the huge CPU use. I'm going to next try removing = the >> locking, as I note that each GPIO access involves a mutex lock and I >> bet the witness code is taking a freaking beating here. >=20 > .. yup. Not compiling in witness helps hugely. I wish I had PMC > working at this point - I bet lots of lock overhead would creep up. >=20 > Basically, a lock is acquired for each GPIO pin set, clear and > reconfigure. The gpiobus code itself doesn't do this - that's what > gpiobus_lock_bus and gpiobus_unlock_bus is for - but the ar71xx gpio > code however does. And so does the gpioiic code - it's locking and > unlocking the bus for each scl/sda line operation. >=20 > Erm, surely that's a bit ridiculous.. surely the locking doesn't need > to be that fine grained _and_ multi-levelled. There has to be a better > way to do this. :) Exactly. I've reimplemented iicbb.c to be slightly more protocol compliant, and = to be able to tune transfer speeds to the actual hardware capabilities. = I've timed a single GETSCL (with WITNESS) to 8.7 microseconds, clearly = that won't do. I think I'll look at gpio next, as you have, and see if the overhead can = be reduced. 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?18CABB46-9B9A-41CB-8742-6723C5FF4D67>