[lkml]   [2011]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 3/6] mfd: 88pm860x: enhance lock on i2c transaction
On Fri, May 13, 2011 at 10:20 PM, Samuel Ortiz <> wrote:
> Hi Haojian,
> On Fri, May 06, 2011 at 05:21:22PM +0800, Haojian Zhuang wrote:
>> Accessing test page in 88pm860x is a sequence of read/write on i2c bus.
>> Bus lock is used in each small i2c transaction. But it may result the
>> whole sequence interrupted by other i2c client transaction.
> Sure, but what you mainly want is your MFD i2c IO calls to be serialized, and
> that's already being taken care of by the current code.
> Are other i2c clients (non MFD ones) touching the same i2c registers than the
> MFD ones ?
Other process may not access the same register. But they may access same i2c
bus. What I did is used to protect bus operation.

Even accessing one register in test page is composed by a sequence of accessing
test page.

For example, read one byte of 0xbc in test page.
1) i2c read zero byte from 0xFA
2) i2c read zero byte from 0xFB
3) i2c read zero byte from 0xFF
4) i2c read one byte from 0xbc (desired operation)
5) i2c read zero byte from 0xFC

Step #1 to #3 is used to enter test page mode. Step 4 is used to read
desired data.
Step #5 is used to exit test page mode. If all these five steps are
using standard
i2c read operation, bus lock in i2c driver will be held and released
five times. If another
process is also accessing i2c bus, it may interrupt the sequence and
import error to

So the potential issue is releasing bus lock too early. If I just add
bus lock protection
in test page operation, I'll meet dead lock issue since bus lock will
be used in standard
i2c operation. I have to implement my i2c frame and send it out directly.

Best Regards

 \ /
  Last update: 2011-05-13 17:03    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean