From: grinberg@compulab•co.il (Igor Grinberg)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 6/7] i2c/pxa2xx: reset the chip if the bus is not free
Date: Thu, 25 Nov 2010 15:10:05 +0200 [thread overview]
Message-ID: <4CEE602D.5090501@compulab.co.il> (raw)
In-Reply-To: <4CEE5587.90109@linutronix.de>
On 11/25/10 14:24, Sebastian Andrzej Siewior wrote:
> Igor Grinberg wrote:
>> Hi,
> Hi,
>
>>>> Even you reset I2C controller, it shouldn't help you since bus isn't
>>>> free. I thinkt that you should reset I2C bus before you reseting I2C
>>>> controller.
>
> According to the register, IBB (bus busy) is cleared at this point. The
> only remaining flag is UB (unit busy) and RW mode.
>
>>> Excuse me that my previous comments are for PXA master mode.
> I am in master mode.
>
>>> I think that you're focused on pxa working on slave mode. But if pxa
>>> is working in master mode, it seems that we needn't reset I2C
>>> controller since it doesn't help.
>>
>> As for PXA3xx, the Developer Manual states:
>> "Software must ensure that the TWSI unit is not busy (ISR[UB] = 0)
>> before it asserts a reset. Software must also ensure that the TWSI bus is idle (ISR[IBB] = 0)
>> when the unit is enabled after reset."
>
> My manual says more or less the same thing. It says "unit not busy" but
> quotes the IBB bit in braces. It is probably a typo.
> The register say: ISR=00000005, ICR=000017e0, IBMR=01
> So according to this I am not allowed to reset the I2C unit while it is
> busy.
>
> I tracked it down to the following: i2cdetect tries to read a byte from
> address 47. This fails because there is no device. Then it goes for 48
> which returns 0 (there is a device). The following read always fails. So I
> guess the device at 48 is still sending data. What is general rule of
> thumb in such a case?
I don't think there is such a rule for this case, as if we "believe" the
Developer Manual, but do the opposite - we can get into trouble...
IMHO, at least we need to report a problem.
Or may be in some way reset the slave device,
if there is such an option available outside the i2c scope...
(Yeah, I know this is a crazy idea...)
>
>>> From my experience, in master mode resetting the controller
>> does not help and if the bus is busy for too much time,
>> there always was a h/w problem involved.
>
> Looks like it.
1) Well, you should check if you have a pull-up resistors on that bus.
2) Or if the slave device chip is broken, then it should be replaced.
>
> Sebastian
>
--
Regards,
Igor.
next prev parent reply other threads:[~2010-11-25 13:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-24 21:20 I2C support for Sodaville Sebastian Andrzej Siewior
2010-11-24 21:20 ` [PATCH 1/7] i2c/pxa2xx: Don't touch ISAR if not in slave mode Sebastian Andrzej Siewior
2010-11-25 23:52 ` Ben Dooks
2010-11-26 18:28 ` [sodaville] " Sebastian Andrzej Siewior
2010-11-24 21:20 ` [PATCH 2/7] arm/pxa2xx: reorganize I2C files Sebastian Andrzej Siewior
2010-11-25 23:55 ` Ben Dooks
2010-11-26 0:03 ` Russell King - ARM Linux
2010-11-26 14:11 ` Sebastian Andrzej Siewior
2010-11-24 21:20 ` [PATCH 3/7] i2c/pxa2xx: Add PCI support for PXA I2C controller Sebastian Andrzej Siewior
2010-11-25 23:59 ` Ben Dooks
2010-11-26 14:16 ` Sebastian Andrzej Siewior
2010-11-24 21:20 ` [PATCH 4/7] i2c/pxa2xx: add support for shared IRQ handler Sebastian Andrzej Siewior
2010-11-25 2:26 ` Haojian Zhuang
2010-11-25 10:48 ` Sebastian Andrzej Siewior
2010-11-24 21:20 ` [PATCH 5/7] i2c/pxa2xx: check timeout correctly Sebastian Andrzej Siewior
2010-11-24 21:20 ` [PATCH 6/7] i2c/pxa2xx: reset the chip if the bus is not free Sebastian Andrzej Siewior
2010-11-25 2:30 ` Haojian Zhuang
2010-11-25 2:49 ` Haojian Zhuang
2010-11-25 6:43 ` Igor Grinberg
2010-11-25 7:04 ` Haojian Zhuang
2010-11-25 12:24 ` Sebastian Andrzej Siewior
2010-11-25 13:10 ` Igor Grinberg [this message]
2010-11-25 13:39 ` Sebastian Andrzej Siewior
2010-11-24 21:20 ` [PATCH 7/7] i2c/pxa2xx: pass of_node from platform driver to adapter Sebastian Andrzej Siewior
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=4CEE602D.5090501@compulab.co.il \
--to=grinberg@compulab$(echo .)co.il \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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