Thread (22 messages) flat view 22 messages, 4 authors, 2012-07-03
STALE5194d

[PATCH 1/3] mfd: support 88pm80x in 80x driver

From: arnd@arndb.de (Arnd Bergmann)
Date: 2012-07-02 15:58:50
Also in: linux-i2c

On Monday 02 July 2012, Qiao Zhou wrote:
On 07/02/2012 06:12 PM, Mark Brown wrote:
quoted
On Mon, Jul 02, 2012 at 06:09:57PM +0800, Qiao Zhou wrote:
quoted
On 07/02/2012 06:03 PM, Mark Brown wrote:
quoted
quoted
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.
quoted
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.

	Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help