Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 2 May 2014 22:22:36 -0400
From:      Winston Smith <smith.winston.101@gmail.com>
To:        ticso@cicely.de
Cc:        FreeBSD ARM <freebsd-arm@freebsd.org>
Subject:   Re: BBB/I2C: Read PMIC data
Message-ID:  <CADH-AwFy3Cb-QiOc3hBT1tr2C0FgqTAnc0RvFHPYbm=hBxykJg@mail.gmail.com>
In-Reply-To: <20140503000946.GK52252@cicely7.cicely.de>
References:  <CADH-AwGbnqzGqbzpV9YMgdOciLpoy3fqxF1RtCmMPZtgc%2BAcXg@mail.gmail.com> <53633440.3070702@hot.ee> <CADH-AwHKKXDTotrk_tQMsZ0WToyk55JgZEmLk0AkHJzGLiGKvA@mail.gmail.com> <C419C325-4354-4490-B7A8-29F4A606FD47@bsdimp.com> <CADH-AwER3hMhwY2i%2BJh4Fe04ZLYcRQ-e0gy==eotPgyZ0ZOnDA@mail.gmail.com> <20140503000946.GK52252@cicely7.cicely.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 2, 2014 at 8:09 PM, Bernd Walter <ticso@cicely7.cicely.de> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADH-AwFy3Cb-QiOc3hBT1tr2C0FgqTAnc0RvFHPYbm=hBxykJg>