All of lore.kernel.org
 help / color / mirror / Atom feed
From: Samuel Ortiz <sameo@linux.intel.com>
To: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Haojian Zhuang <haojian.zhuang@marvell.com>,
	linux-kernel@vger.kernel.org, lrg@slimlogic.co.uk,
	broonie@opensource.wolfsonmicro.com, a.zummo@towertech.it,
	khali@linux-fr.org, ben-linux@fluff.org
Subject: Re: [PATCH 3/6] mfd: 88pm860x: enhance lock on i2c transaction
Date: Fri, 13 May 2011 20:27:32 +0200	[thread overview]
Message-ID: <20110513182731.GX8970@sortiz-mobl> (raw)
In-Reply-To: <BANLkTikfh6c_kFom+2MHx+QTuZxVJH0svA@mail.gmail.com>

Hi Haojian,

On Fri, May 13, 2011 at 11:00:24PM +0800, Haojian Zhuang wrote:
> On Fri, May 13, 2011 at 10:20 PM, Samuel Ortiz <sameo@linux.intel.com> 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
> pmic.
I see. Wouldn't i2c_transfer() fix your problem then ?

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

  reply	other threads:[~2011-05-13 18:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2011050601>
2011-05-06  9:21 ` [PATCH 1/6] mfd: 88pm860x: support rtc Haojian Zhuang
2011-05-06  9:21   ` [PATCH 2/6] mfd: 88pm860x: avoid to allocate static platform data Haojian Zhuang
2011-05-06  9:21     ` [PATCH 3/6] mfd: 88pm860x: enhance lock on i2c transaction Haojian Zhuang
2011-05-06  9:21       ` [PATCH 4/6] mfd: 88pm860x: avoid to use constraint name in regulator driver Haojian Zhuang
2011-05-06  9:21         ` [PATCH 5/6] mfd: 88pm860x: remove unused parameter Haojian Zhuang
2011-05-06  9:21           ` [PATCH 6/6] mfd: max8925: remove checking on regulator[0] Haojian Zhuang
2011-05-06 11:49             ` Mark Brown
2011-05-13 14:24             ` Samuel Ortiz
2011-05-13 14:24           ` [PATCH 5/6] mfd: 88pm860x: remove unused parameter Samuel Ortiz
2011-05-06 13:06         ` [PATCH 4/6] mfd: 88pm860x: avoid to use constraint name in regulator driver Mark Brown
2011-05-13 14:21         ` Samuel Ortiz
2011-05-13 14:20       ` [PATCH 3/6] mfd: 88pm860x: enhance lock on i2c transaction Samuel Ortiz
2011-05-13 15:00         ` Haojian Zhuang
2011-05-13 18:27           ` Samuel Ortiz [this message]
2011-05-14 13:40             ` Haojian Zhuang
2011-05-13 14:14     ` [PATCH 2/6] mfd: 88pm860x: avoid to allocate static platform data Samuel Ortiz
2011-05-13 14:13   ` [PATCH 1/6] mfd: 88pm860x: support rtc Samuel Ortiz

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=20110513182731.GX8970@sortiz-mobl \
    --to=sameo@linux.intel.com \
    --cc=a.zummo@towertech.it \
    --cc=ben-linux@fluff.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=haojian.zhuang@gmail.com \
    --cc=haojian.zhuang@marvell.com \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@slimlogic.co.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.