From: Hein Tibosch <hein_tibosch@yahoo.es>
To: balbi@ti.com, Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Tony Lindgren <tony@atomide.com>,
linux-i2c <linux-i2c@vger.kernel.org>,
linux-omap <linux-omap@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] i2c-omap: always send stop after nack
Date: Wed, 17 Jul 2013 00:17:21 +0800 [thread overview]
Message-ID: <51E57211.2040001@yahoo.es> (raw)
In-Reply-To: <20130716130058.GD15036@arwen.pp.htv.fi>
Hi Grygorii, Filipe,
On 7/16/2013 9:00 PM, Felipe Balbi wrote:
> On Tue, Jul 16, 2013 at 03:08:04PM +0300, Grygorii Strashko wrote:
>> Hi Felipe,
>> On 07/16/2013 02:27 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Tue, Jul 16, 2013 at 02:01:11PM +0300, Grygorii Strashko wrote:
>>>>>>>> On a OMAP4460, i2c-bus-3:
>>>>>>>>
>>>>>>>> A driver (lm75) is causing many 'timeout waiting for bus ready' errors.
>>>>>>>> SDA remains high (as it should), but SCL remains low after a NACK.
>>>>>>>> The bus becomes _unusable for other clients_.
>>>>>>>>
>>>>>>>> While probing, "lm75" writes a command, followed by a read + stop,
>>>>>>>> but the write command is NACK'd. The chip does accept other writes/reads,
>>>>>>>> it just refuses to ack invalid commands.
In case the NACK may not be ignored, I believe it is correct
to break out of the loop and send a stop for 2 reasons:
1. all chips, including the target chip, will know that the
current transaction is finished
2. to set CLK high again, which prevents numerous timeouts
on subsequent transactions
As a test I've set 'I2C_M_IGNORE_NAK' for all .detect messages
sent by the lm75 driver.
Now the chip (tmp105) will provide read data as expected
after the _repeated start_, even though it NACK'd the preceding
WR command.
And also the detection trick does work now, addresses 4,5,6,7 return
the same read data as was returned from the last valid address 2.
Felipe:
> Which means your original patch starts to make a lot more sense. I
> wonder is this is really what we should be doing though - breaking out
> of the loop, I mean.
So yes, we have to break the loop as the caller is not interested
in processing any further commands.
In i2c/algos/i2c-algo-bit.c, bit_xfer() works exactly the same way:
break the loop (unless IGNORE_NAK) and call unconditionally i2c_stop().
It looks like TI's i2c-davinci will have the same problem as i2c-omap,
and will need the same change.
Grygorii, if you submit the patch, please add my
Signed-off-by: Hein Tibosch <hein_tibosch@yahoo.es>
cause you were earlier to notice and fix this problem.
Hein
next prev parent reply other threads:[~2013-07-16 16:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-16 8:19 [PATCH] i2c-omap: always send stop after nack Hein Tibosch
2013-07-16 9:03 ` Felipe Balbi
[not found] ` <20130716090300.GG8880-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
2013-07-16 9:33 ` Hein Tibosch
2013-07-16 9:42 ` Felipe Balbi
[not found] ` <20130716094212.GL8880-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
2013-07-16 11:01 ` Grygorii Strashko
2013-07-16 11:27 ` Felipe Balbi
2013-07-16 12:08 ` Grygorii Strashko
[not found] ` <51E537A4.40300-l0cyMroinI0@public.gmane.org>
2013-07-16 13:00 ` Felipe Balbi
2013-07-16 16:17 ` Hein Tibosch [this message]
[not found] ` <51E57211.2040001-mRCrAkd8dF0@public.gmane.org>
2013-08-19 12:11 ` Wolfram Sang
2013-08-19 13:57 ` Felipe Balbi
2013-08-19 14:05 ` Wolfram Sang
2013-08-20 16:39 ` Grygorii Strashko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51E57211.2040001@yahoo.es \
--to=hein_tibosch@yahoo.es \
--cc=balbi@ti.com \
--cc=grygorii.strashko@ti.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).