From owner-freebsd-embedded@FreeBSD.ORG Sun Dec 18 10:17:52 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B330A106566C; Sun, 18 Dec 2011 10:17:52 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 7016F8FC0A; Sun, 18 Dec 2011 10:17:52 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 0A7B8108BD7; Sun, 18 Dec 2011 11:17:51 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Stefan Bethke In-Reply-To: Date: Sun, 18 Dec 2011 11:17:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1251.1) Cc: Oleksandr Tymoshenko , "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 10:17:52 -0000 Am 18.12.2011 um 11:11 schrieb Adrian Chadd: > On 18 December 2011 01:54, Adrian Chadd 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 Fon +49 151 14070811