From owner-freebsd-arm@FreeBSD.ORG Sat May 3 02:22:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A0F74EE for ; Sat, 3 May 2014 02:22:39 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B7A4A1511 for ; Sat, 3 May 2014 02:22:38 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id cc10so3197650wib.14 for ; Fri, 02 May 2014 19:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2pxJUMQeFe29MQt7RwK+ydcb+50apQhwomhDquackr4=; b=iHtEiI80hj5q/7APdv6WPPHmfbu2tXr+FoVjZMUW/QhmIm3nPeG2rD5pov1vzUblcH sl282IDYK+Y+COirPCJsbNbxuQDnzEouT6C+88JliTz6mTFwnUFN+lH9Bz95o24e0UuF uflg/h9Ci9QkRBGcXWulH+fJora0OLHkDKQsRq1sFWUY9uf+bgCtArIk27YWWERjbWUt 5G8GqxHxitouoQlo1WvJmO1XlCOP+SCsK1S4I/fCw7P4mF11dDSasVHI/N67yadPqixW GQk9VGnN/vANBJ4CBjoSYW7V/7TzkgsrgCVDYDxpkpLLp2l7ETTs4aABFGFD5XO71KJg IEMA== MIME-Version: 1.0 X-Received: by 10.194.222.227 with SMTP id qp3mr16357984wjc.37.1399083756580; Fri, 02 May 2014 19:22:36 -0700 (PDT) Received: by 10.217.10.195 with HTTP; Fri, 2 May 2014 19:22:36 -0700 (PDT) In-Reply-To: <20140503000946.GK52252@cicely7.cicely.de> References: <53633440.3070702@hot.ee> <20140503000946.GK52252@cicely7.cicely.de> Date: Fri, 2 May 2014 22:22:36 -0400 Message-ID: Subject: Re: BBB/I2C: Read PMIC data From: Winston Smith To: ticso@cicely.de Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 02:22:39 -0000 On Fri, May 2, 2014 at 8:09 PM, Bernd Walter wrote: > So you get valid data. > Sounds like the interupt handler is working for what it needs, but not > closing an interrupt down. > Since most part of acknowleging an interrupt to the hardware is the > same for all interrupt sources I expect the IIC controller isn't > made aware that an interrupt was processed. > One wild guess - without knowing the Sitara IIC controller at all: > You write and read in one transaction, the controller may issue > an interrupt on read and write, but only the read is handled, so > the write interrupt stays active. > It could also bee that the controler signals other states, which are > unhandled - e.g. addressed device acknowledge. > Just read in the datasheet what kind of interrupts it can send. > Usually it is a flag register. > Read and printf it in the int service and check if one of the signalled > interrupts is unhandled. > Some interrupt sources might need manual shutdown, while others do > not - e.g. data ready is often automatically done when reading the > data register and other need to be cleared by writing into a register. In my testing, the "interrupt storm" warning only occurs if the transfer size exceeds the FIFO size (which is set at 4). I'm still working through the code and the datasheet, but I think it might be related to how the drain feature works.