public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: zhouqiao@marvell•com (Qiao Zhou)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 1/3] mfd: support 88pm80x in 80x driver
Date: Tue, 03 Jul 2012 10:28:39 +0800	[thread overview]
Message-ID: <4FF258D7.8050109@marvell.com> (raw)
In-Reply-To: <201207021558.51246.arnd@arndb.de>

On 07/02/2012 11:58 PM, Arnd Bergmann wrote:
> On Monday 02 July 2012, Qiao Zhou wrote:
>> On 07/02/2012 06:12 PM, Mark Brown wrote:
>>> On Mon, Jul 02, 2012 at 06:09:57PM +0800, Qiao Zhou wrote:
>>>> On 07/02/2012 06:03 PM, Mark Brown wrote:
>>>
>>>>> What do you mean by pages?  regmap has paging support which just maps
>>>>> everything into a single flat register map from the point of view of
>>>>> callers.
>>>
>>>> Mark, let me explain: the 88pm800 chip has three i2c address
>>>> internally, which we called different page instead. it confuses you
>>>> with the register page_read/write operation. there are registers in
>>>> each i2c address domain, and we need to use different i2c client to
>>>> access reg in different domain. such as some common regs are in the
>>>> page of i2c_addr = 0x30, and power related regs are in the page of
>>>> i2c_addr = 0x31, and gpadc related regs are in the page of 0x32.
>>>
>>> These aren't what people normally call pages, those are just separate
>>> I2C devices from a Linux point of view.
>>>
>> Mark, surely I'll pay attention to the terms used. thanks!
>> due to there separate I2C devices, does it make sense to export separate
>> r/w interface for them? do you have suggestion in such case?
>
> (adding the i2c mailing list to get more insight)
>
> I think in case of device tree based probing, it would be straightforward
> to represent 88pm800 as a single device with three addresses in the "reg"
> property, while the natural linux representation would be one regular
> i2c_client device with two dummies. Do we or should we have any
> infrastructure to deal with this?
>
> If this is a common scenario, we could probably let regmap handle it
> entirely internally and represent the i2c client with its dummies
> as a single regmap.
actually there are many drivers under mfd which have this common issue, 
which has i2c dummy devices, such as max77693.c, max8925-i2c.c, 
ab3100-core.c, max8997.c, max8998.c, s5m-core.c etc. some use regmap 
handle directly as param in exported r/w api, some add extra param to 
differentiate i2c dummy. it seems to be a common scenario. how do we 
handle the API in short term and long term?
>
> 	Arnd
>


-- 

Best Regards
Qiao

  reply	other threads:[~2012-07-03  2:28 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-28  3:13 [PATCH 0/3 V1] add 88pm80x mfd driver Qiao Zhou
2012-06-28  3:13 ` [PATCH 1/3] mfd: support 88pm80x in 80x driver Qiao Zhou
2012-06-28 11:21   ` Arnd Bergmann
2012-06-28 11:46     ` Mark Brown
2012-06-28 14:32       ` Arnd Bergmann
2012-06-29  1:18         ` Haojian Zhuang
2012-06-29  1:29           ` Mark Brown
2012-06-29 14:18           ` Arnd Bergmann
2012-06-29  2:56     ` Qiao Zhou
2012-06-29 13:58       ` Arnd Bergmann
2012-07-02  7:50         ` Qiao Zhou
2012-07-02  9:22           ` Qiao Zhou
2012-07-02 10:03             ` Mark Brown
2012-07-02 10:09               ` Qiao Zhou
2012-07-02 10:12                 ` Mark Brown
2012-07-02 10:15                   ` Qiao Zhou
2012-07-02 15:58                     ` Arnd Bergmann
2012-07-03  2:28                       ` Qiao Zhou [this message]
2012-06-29 14:21   ` Arnd Bergmann
2012-06-30 12:02     ` Mark Brown
2012-06-28  3:13 ` [PATCH 2/3] rtc: add rtc support to 88PM80X PMIC Qiao Zhou
2012-06-28  3:13 ` [PATCH 3/3] input: add onkey " Qiao Zhou
  -- strict thread matches above, loose matches on Subject: below --
2012-06-13  9:04 [PATCH 0/3 V0] add 88pm80x mfd driver Qiao Zhou
2012-06-13  9:04 ` [PATCH 1/3] mfd: support 88pm80x in 80x driver Qiao Zhou
2012-06-14 12:27   ` Arnd Bergmann
2012-06-14 18:43     ` Mark Brown
2012-06-15  5:23       ` Qiao Zhou
2012-06-15  3:17     ` Qiao Zhou

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=4FF258D7.8050109@marvell.com \
    --to=zhouqiao@marvell$(echo .)com \
    --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