From owner-freebsd-embedded@FreeBSD.ORG Sun Dec 18 09:54:03 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 5F999106564A for ; Sun, 18 Dec 2011 09:54:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id CCACA8FC0C for ; Sun, 18 Dec 2011 09:54:02 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so5881752vcb.13 for ; Sun, 18 Dec 2011 01:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=oCGYONzh3PzSsmXxLekN2SvCkYgYtPFGFSMuAo5rQ0k=; b=Wvt2Fv7eySqbgqcL5eAlQYIuWTAwrIBI+QPqzqHnQHggI5KK9+Eqj8HFU+ASiLSLH3 Ru1sK0RFdqkPnKEmcsFTD8JvUaloeQyY6QPsoH88FQXlnvvX4Un2urHbCBZTVjC2VxP8 DWNEIB4sGxfacEGjKfMOh8Ad54doTA40Q29gw= MIME-Version: 1.0 Received: by 10.220.151.204 with SMTP id d12mr7370444vcw.40.1324202042129; Sun, 18 Dec 2011 01:54:02 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.26.50 with HTTP; Sun, 18 Dec 2011 01:54:02 -0800 (PST) In-Reply-To: References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> Date: Sun, 18 Dec 2011 01:54:02 -0800 X-Google-Sender-Auth: loz5k9LYg7GSy2TL-H7hoGLlQo8 Message-ID: From: Adrian Chadd To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 Cc: "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 09:54:03 -0000 .. and some further digging - I've flipped on the i2c_debug value and slightly modified the debug printing so each _stop call prints a newline. It makes it very clear how transactions are being handled. Anyway, there's plenty of instances (even with the transaction DELAY being 10uS) of the last byte being not acked, ie: .. all of those read transactions that aren't acked, are they ok? 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. adrian