[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130619194414.GF4779@arwen.pp.htv.fi>
Date: Wed, 19 Jun 2013 22:44:14 +0300
From: Felipe Balbi <balbi@...com>
To: Grygorii Strashko <grygorii.strashko@...com>
CC: <balbi@...com>, Wolfram Sang <wsa@...-dreams.de>,
Tony Lindgren <tony@...mide.com>,
<linux-kernel@...r.kernel.org>, <linux-omap@...r.kernel.org>,
<linux-i2c@...r.kernel.org>, Kevin Hilman <khilman@...aro.org>
Subject: Re: [PATCH 3/5] i2c: omap: handle all irqs befor unblocking
omap_i2c_xfer_msg()
On Wed, Jun 19, 2013 at 09:43:04PM +0300, Grygorii Strashko wrote:
> Hi Felipe,
> On 06/07/2013 10:05 PM, Felipe Balbi wrote:
> >Hi,
> >
> >On Fri, Jun 07, 2013 at 09:46:06PM +0300, Grygorii Strashko wrote:
> >>ARDY|NACK and ARDY|AL are set together in OMAP_I2C_STAT_REG, which will be
> >Have you seen that happen ever ? AL is Arbitration Lost, we never put
> >OMAP in a multi-master environment before.
> This is an example from real life:
> [ 0.271942] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 400 kHz
> [ 1.283416] omap_i2c omap_i2c.1: timeout waiting for bus ready
> [ 1.300109] OMAP_I2C DEBUG: stat=1001
> [ 1.300140] omap_i2c omap_i2c.1: Arbitration lost
> [ 1.300140] OMAP_I2C DEBUG: IE=601F
> [ 1.300140] OMAP_I2C DEBUG: STAT=1000
> [ 1.300170] OMAP_I2C DEBUG: IV=636F
> [ 1.300170] OMAP_I2C DEBUG: WE=636F
> [ 1.300170] OMAP_I2C DEBUG: SYSS=1
> [ 1.300170] OMAP_I2C DEBUG: BUF=707
> [ 1.300201] OMAP_I2C DEBUG: CNT=1
> [ 1.300201] OMAP_I2C DEBUG: DATA=1
> [ 1.300201] OMAP_I2C DEBUG: SYSC=215
> [ 1.300201] OMAP_I2C DEBUG: CON=8200
> [ 1.300231] OMAP_I2C DEBUG: OA=0
> [ 1.300231] OMAP_I2C DEBUG: SA=49
> [ 1.300231] OMAP_I2C DEBUG: PSC=9
> [ 1.300262] OMAP_I2C DEBUG: SCLL=9
> [ 1.300262] OMAP_I2C DEBUG: SCLH=3
> [ 1.300262] OMAP_I2C DEBUG: SYSTEST=1E0
> [ 1.300262] OMAP_I2C DEBUG: BUFSTAT=4000
>
> and my headache now :..(
have you looked for erratas around that ? Maybe you just found a silicon
issue. Why is AL bit being set ? Have you tried to reach the IP owner ?
If there are no other I2C masters in the system, there will be no
arbitration, hence we would never loose the arbitration.
> >ARDY | NACK I also find it a bit hard for those two to happen together
> >since ARDY will be set when you can change controller's register
> >*again*, mening that a transfer has completed.
> There are examples:
> [ 3.544952] omap_i2c 48060000.i2c: IRQ (ISR = 0x0006)
>
> [ 25.574523] omap_i2c 48350000.i2c: IRQ (ISR = 0x0014)
> [ 25.579925] omap_i2c 48350000.i2c: IRQ (ISR = 0x0012)
>
> to see it - enable debug output in omap_i2c_isr_thread:
> dev_dbg(dev->dev, "IRQ (ISR = 0x%04x)\n", stat);
then you need to figure out why that's happening, right ? What do you do
to trigger that particular condition, have you looked in the wire to see
if you find a real NACK or is the OMAP I2C controller misbehaving ?
> >Also, we need to follow what the programming model says. And, I don't
> >have docs with me right now, but IIRC it tells us to bail out if any of
> >the error conditions are met.
> >
> yep, but first of all - all IRQs need to be acked before exit.
that's alright, then fix only that... OTOH, you don't want to ack a
read while data is still sitting in the FIFO, data you haven't read out
of the FIFO, I mean. Not sure if that could happen though.
--
balbi
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists