regmap: Generic I2C and SPI register map library

This is a version of a series I've been posting for most of this release cycle which abstracts out a bunch of widely duplicated code for doing register I/O on devices with control slow buses like I2C and SPI. As well as saving us code for the register I/O itself this should also make it easier to factor out further higher level code for this class of devices.

The main change in this version of the series is that I've moved the bus-specific files into the relevant drivers/ directories. Hopefully Jean, Ben and Grant will be OK with this and with some churn in this code from the regmap tree that may be created as we build out the core API and possibly refactor the interface to the bus code.

I realise it's a bit late in the cycle but it'd be really good if we could get this merged in the next merge window, or accepted for about then so we can create a stable branch we can merge into subsystem trees in order to get drivers using this merged for 3.2. As there's only one user included the series it should be pretty low risk.

The code is in a subdirectory because I'm anticipating it'll grow quite a bit as we add facilities like fancy cache mechanisms on top of it.

A more verbose cover letter:

Many I2C and SPI based devices implement register maps on top of the raw wire interface. This is generally done in a very standard fashion by devices, resulting in a lot of very similar code in drivers. For some time now ASoC has factored this code out into the subsystem but that's only useful for audio devices. The intention with this series is to generalise the concept so that it can be used throughout the kernel.

It's not intended that this be suitable for all devices - some devices have things that are hard to generalise like registers with variable size and paging which are hard to support genericly. At the minute the code is focused on the common cases. It is likely that the same code could be used with other buses with similar properties to I2C and SPI.

Currently only physical I/O is handled, the intention is that once this support has been reviewed and merged the generic register cache code that ASoC includes will also be factored out too, along with logging and diagnostic infrastructure for register maps. For devices with read heavy workloads (especially those that need a lot of read/modify/write cycles) or which don't support read at all this can provide a useful performance improvement and for sparse register maps there's a lot of benefit in relatively complex cache code.

I'm not entirely happy with the implementation currently but am fairly happy with the external interfaces.

A bunch more drivers have been converted to use this framework, including the existing ASoC register I/O code, but due to various -next dependencies these don't apply easily so I've omitted them from this posting of the series - you can see them in the mailing list archives, they've not been updated during the review.

There's a git branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next

I've also created a regmap-asoc branch there which merges current ASoC code with the regmap code.

The following changes since commit 620917de59eeb934b9f8cf35cc2d95c1ac8ed0fc:

Linux 3.0-rc7 (2011-07-11 16:51:52 -0700)

are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next

Mark Brown (4):
regmap: Add generic non-memory mapped register access API
regmap: Add I2C bus support
regmap: Add SPI bus support
regulator: Convert tps65023 to use regmap API

 MAINTAINERS                            |    7 +
 drivers/base/Kconfig                   |    2 +
 drivers/base/Makefile                  |    1 +
 drivers/base/regmap/Kconfig            |    6 +
 drivers/base/regmap/Makefile           |    1 +
 drivers/base/regmap/regmap.c           |  481 ++++++++++++++++++++++++++++++++
 drivers/i2c/Kconfig                    |    4 +
 drivers/i2c/Makefile                   |    1 +
 drivers/i2c/i2c-regmap.c               |  111 ++++++++
 drivers/regulator/Kconfig              |    1 +
 drivers/regulator/tps65023-regulator.c |   98 ++-----
 drivers/spi/Kconfig                    |    4 +
 drivers/spi/Makefile                   |    1 +
 drivers/spi/spi-regmap.c               |   76 +++++
 include/linux/regmap.h                 |   76 +++++
 15 files changed, 799 insertions(+), 71 deletions(-)
 create mode 100644 drivers/base/regmap/Kconfig
 create mode 100644 drivers/base/regmap/Makefile
 create mode 100644 drivers/base/regmap/regmap.c
 create mode 100644 drivers/i2c/i2c-regmap.c
 create mode 100644 drivers/spi/spi-regmap.c
 create mode 100644 include/linux/regmap.h

There are many places in the tree where we implement register access for devices on non-memory mapped buses, especially I2C and SPI. Since hardware designers seem to have settled on a relatively consistent set of register interfaces this can be effectively factored out into shared code. There are a standard set of formats for marshalling data for exchange with the device, with the actual I/O mechanisms generally being simple byte streams.

We create an abstraction for marshaling data into formats which can be sent on the control interfaces, and create a standard method for plugging in actual transport underneath that.

This is mostly a refactoring and renaming of the bottom level of the existing code for sharing register I/O which we have in ASoC. A subsequent patch in this series converts ASoC to use this. The main difference in interface is that reads return values by writing to a location provided by a pointer rather than in the return value, ensuring we can use the full range of the type for register data. We also use unsigned types rather than ints for the same reason.

As some of the devices can have very large register maps the existing ASoC code also contains infrastructure for managing register caches. This cache work will be moved over in a future stage to allow for separate review, the current patch only deals with the physical I/O.

---
 MAINTAINERS                  |    7 +
 drivers/base/Kconfig         |    2 +
 drivers/base/Makefile        |    1 +
 drivers/base/regmap/Kconfig  |    6 +
 drivers/base/regmap/Makefile |    2 +
 drivers/base/regmap/regmap.c |  481 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/regmap.h       |   76 +++++++
 7 files changed, 575 insertions(+), 0 deletions(-)
 create mode 100644 drivers/base/regmap/Kconfig
 create mode 100644 drivers/base/regmap/Makefile
 create mode 100644 drivers/base/regmap/regmap.c
 create mode 100644 include/linux/regmap.h

index 187282d..b7eaf63 100644
@@ -5313,6 +5313,13 @@ L:	[email protected]
 S:	Supported
 F:	fs/reiserfs/
 
+REGISTER MAP ABSTRACTION
+M:	Mark Brown <[email protected]>
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
+S:	Supported
+F:	drivers/base/regmap/
+F:	include/linux/regmap.h
+
 RFKILL
 M:	Johannes Berg <[email protected]>
 L:	[email protected]

index d57e8d0..b605d01 100644
@@ -168,4 +168,6 @@ config SYS_HYPERVISOR
 	bool
 	default n
 
+source "drivers/base/regmap/Kconfig"
+
 endmenu

index 4c5701c..dd4f9b2 100644
@@ -18,6 +18,7 @@ ifeq ($(CONFIG_SYSFS),y)
 obj-$(CONFIG_MODULES)	+= module.o
 endif
 obj-$(CONFIG_SYS_HYPERVISOR) += hypervisor.o
+obj-$(CONFIG_REGMAP)	+= regmap/
 
 ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
 

new file mode 100644
index 0000000..fc0eb1d
@@ -0,0 +1,6 @@
+# Generic register map support.  There are no user servicable options here,
+# this is an API intended to be used by other kernel subsystems.  These
+# subsystems should select the appropriate symbols.
+
+config REGMAP
+	bool

new file mode 100644
index 0000000..1e5037e
@@ -0,0 +1,2 @@
+obj-$(CONFIG_REGMAP) += regmap.o
+

1.7.5.4

We initialise at postcore_initcall() so that we are available before users
- some users such as PMICs initialise very early. We won't actually try to use any of the bus until a device initialises a register map.

---
 drivers/base/regmap/Makefile |    1 -
 drivers/i2c/Kconfig          |    4 ++
 drivers/i2c/Makefile         |    1 +
 drivers/i2c/i2c-regmap.c     |  111 ++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 116 insertions(+), 1 deletions(-)
 create mode 100644 drivers/i2c/i2c-regmap.c

index 1e5037e..7532e13 100644
@@ -1,2 +1 @@
 obj-$(CONFIG_REGMAP) += regmap.o
-

index 30f06e9..cba758b 100644
@@ -6,6 +6,7 @@ menuconfig I2C
 	tristate "I2C support"
 	depends on HAS_IOMEM
 	select RT_MUTEXES
+	select I2C_REGMAP if REGMAP
 	---help---
 	  I2C (pronounce: I-square-C) is a slow serial bus protocol used in
 	  many micro controller applications and developed by Philips.  SMBus,

@@ -110,4 +111,7 @@ config I2C_DEBUG_BUS
 	  a problem with I2C support and want to see more of what is going
 	  on.
 
+config I2C_REGMAP
+	tristate
+
 endif # I2C

index beee6b2..85d6699 100644
@@ -7,6 +7,7 @@ obj-$(CONFIG_I2C)		+= i2c-core.o
 obj-$(CONFIG_I2C_SMBUS)		+= i2c-smbus.o
 obj-$(CONFIG_I2C_CHARDEV)	+= i2c-dev.o
 obj-$(CONFIG_I2C_MUX)		+= i2c-mux.o
+obj-$(CONFIG_I2C_REGMAP)	+= i2c-regmap.o
 obj-y				+= algos/ busses/ muxes/
 
 ccflags-$(CONFIG_I2C_DEBUG_CORE) := -DDEBUG

1.7.5.4

We initialise at postcore_initcall() so that we are available before users
- some users such as PMICs initialise very early. We won't actually try to use any of the bus until a device initialises a register map.

---
 drivers/spi/Kconfig      |    4 ++
 drivers/spi/Makefile     |    1 +
 drivers/spi/spi-regmap.c |   76 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 81 insertions(+), 0 deletions(-)
 create mode 100644 drivers/spi/spi-regmap.c

index de35c3a..1c689a8 100644
@@ -43,12 +43,16 @@ config SPI_MASTER
 #	boolean "SPI Master Support"
 	boolean
 	default SPI
+	select SPI_REGMAP if REGMAP
 	help
 	  If your system has an master-capable SPI controller (which
 	  provides the clock and chipselect), you can enable that
 	  controller and the protocol drivers for the SPI slave chips
 	  that are connected.
 
+config SPI_REGMAP
+	boolean
+
 if SPI_MASTER
 
 comment "SPI Master Controller Drivers"

index 0f8c69b..52dcf27 100644
@@ -7,6 +7,7 @@ ccflags-$(CONFIG_SPI_DEBUG) := -DDEBUG
 # small core, mostly translating board-specific
 # config declarations into driver model code
 obj-$(CONFIG_SPI_MASTER)		+= spi.o
+obj-$(CONFIG_SPI_REGMAP)		+= spi-regmap.o
 
 # SPI master controller drivers (bus)
 obj-$(CONFIG_SPI_ALTERA)		+= spi_altera.o

1.7.5.4

---
 drivers/regulator/Kconfig              |    1 +
 drivers/regulator/tps65023-regulator.c |   98 +++++++++-----------------------
 2 files changed, 28 insertions(+), 71 deletions(-)

index d7ed20f..c8dc5f0 100644
@@ -235,6 +235,7 @@ config REGULATOR_TPS6105X
 config REGULATOR_TPS65023
 	tristate "TI TPS65023 Power regulators"
 	depends on I2C
+	select REGMAP
 	help
 	  This driver supports TPS65023 voltage regulator chips. TPS65023 provides
 	  three step-down converters and two general-purpose LDO voltage regulators.

1.7.5.4

Hi Mark,

Jean Delvare

I'd be *utterly* astonished if it ever caused any issues, embedded systems like those that have regulators just don't have anything less than full I2C support, it's exceptionally rare to see any direct SMBus support in the hardware at all - the only example I can see in the tree is Blackfin and that is a proper I2C controller too, it just seems that someone overdesigned the hardware a little.

Basically, for something like a regulator it's just not an issue.

Right, so for pretty much anything except PCs the main reason for using the SMBus API is that it provides the sort of data mangling to the bus functionality that the regmap API provides. The main thing it's missing for drivers like this one is that it doesn't have a read/modify/write operation, otherwise there would be no current value in switching to the regmap API. As far as I can tell this isn't really a big deal except for those device classes like hwmon which are frequently deployed in PCs, anything else just won't care.

This should be reasonably simple to handle in the regmap API, just teach the I2C module to fall back to using the SMBus operations if the controller is limited to that. This should be done incrementally as it adds complexity, and ideally would be done by someone with some access to hardware that can use the SMBus API (I don't have any myself) so they can test.

Does that sound reasonable to you?

*Please* could people delete unneeded context from mails?

OK, alright then.

Mostly correct. There are a few other devices which can also be found on PCs: multiplexers and EEPROMs at least.

You do have access ;) The i2c core will translate SMBus to I2C as needed, so all you have to do is temporarily alter the regmap core to unconditionally translate to SMBus. This will be inefficient (regmap -> SMBus -> I2C) but should be suitable for testing.

Yes, no objection.

? There were more comments from me in the rest of the code, which is why I left it.

Jean Delvare

I did say "device classes like" for a reason :)

I have access to host controllers obviously, what I don't have is access to any client devices with suitable register maps.

You should delete all the text that isn't directly related to your comments, you appeared to have not deleted any content at all from the mail. There were pages and pages of stuff with no comments at all.

This really helpful both for finding the content (it's really easy to just page past stuff) and for those of us who read mail on mobile devices.

BTW, if this does sound reasonable are you OK with adding your ack for the I2C bus interface patch or are there any updates you want me to do?

Hi Mark,

I did not review the patch carefully, so I can't ask for updates. As none of "my" drivers will use it, I don't really feel qualified (nor interested, honestly) to review it.

I don't quite get why you put the i2c bindings into drivers/i2c/i2c-regmap.c. This means that Ben and I end up being the maintainers of that file, while it's your thing. And this module is a user of i2c, not a provider, so it doesn't really belong there anyway. Same goes with spi. And what's the rationale for putting the regmap core under drivers/base?

What's wrong with the more direct approach:
drivers/regmap/regmap-core.c
drivers/regmap/regmap-i2c.c
drivers/regmap/regmap-spi.c
?

At least you would have everything in one place and under your control. With your current plan, every update is likely to spawn cross-subsystems, which always results in delays and conflicts.

Now if you have a good reason for the current design, that's OK with me, I can live with that. Simply it seems more complex than needed.

Also, your Kconfig setup is such that all bindings will be selected as soon as any driver needs one. And the selection (module vs. built-in) will be aligned on the core setting (e.g. CONFIG_I2C) rather than the drivers which use it. I'd rather have e.g. REGULATOR_TPS65023 select REGMAP_I2C, and in turn have REGMAP_I2C select REGMAP. This should address the issues I pointed out.

Jean Delvare

Hahaha. Mark *did* do it that way and I suggested splitting up into the i2c and spi directories to keep bus specific infrastructure together. Very well, if you feel strongly about it then I withdraw my comment.

g.

This was exactly what the orginal patch set looked like, there have just been a couple of git mvs since then.

Actually you weren't the only person to suggest this, but the other suggestions were pretty weak and like you say all together was my original preference. Since we seem to have achieved consensus I'll flip everything back.

The reason for drivers/base was that this is more utility code like the firmware loader than it is an actual thing.

Yeah, the problem is that select doesn't actually work terribly well as it causes dependencies of the selected thing to get ignored which is annoying and means that the thing doing the selecting needs to select them too. The bus interfaces are small enough that I'm not really worried about the extra size and if need be we can always sort it out layer.