From: David Brownell <dbrownell@users.sourceforge.net>

This patch adds the core of the TWL4030 driver, which supports
chips including the TPS65950.  These chips are multi-function; see 

  http://focus.ti.com/docs/prod/folders/print/tps65950.html

Public specs are in the works.  For now, the block diagram on
the second page of the datasheet seems very informative.

Once the core is in mainline, drivers for other parts of this
chip can start heading upstream too.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
NOTE: this is the current code from the linux-omap tree.
I expect a few things still need to be updated...

 drivers/mfd/Kconfig                |   14 
 drivers/mfd/Makefile               |    2 
 drivers/mfd/twl4030-core.c         | 1255 +++++++++++++++++++++++++++++++++++
 include/linux/i2c/twl4030-gpio.h   |   76 ++
 include/linux/i2c/twl4030-madc.h   |  134 +++
 include/linux/i2c/twl4030-pwrirq.h |   37 +
 include/linux/i2c/twl4030.h        |  191 +++++
 7 files changed, 1709 insertions(+)

--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -50,6 +50,20 @@ config HTC_PASIC3
 	  HTC Magician devices, respectively. Actual functionality is
 	  handled by the leds-pasic3 and ds1wm drivers.
 
+config TWL4030_CORE
+	bool "Texas Instruments TWL4030/TPS659x0 Support"
+	depends on I2C=y && (ARCH_OMAP2 || ARCH_OMAP3)
+	help
+	  Say yes here if you have TWL4030 family chip on your board.
+	  This core driver provides register access and IRQ handling
+	  facilities, and registers devices for the various functions
+	  so that function-specific drivers can bind to them.
+
+	  These multi-function chps are found on many OMAP2 and OMAP3
+	  boards, providing power management, RTC, GPIO, keypad, a
+	  high speed USB OTG transceiver, an audio codec (on most
+	  versions) and many other features.
+
 config MFD_TMIO
 	bool
 	default n
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -12,6 +12,8 @@ obj-$(CONFIG_MFD_T7L66XB)	+= ...
[ message continues ]

Add that to Documentation/ioctl-number.txt (?)

---
~Randy
--

[ message continues ]

Indeed ... although if e e cummings could write poetry without
uppercase, surely in this modern age some literature will be

Actually one of my own review comments is that this header
should become unneccessary ... and everything associated
with it be dealt with when this Multi-channel ADC driver
gets pushed upstream.  IRQ initialization needs to be done
in the core, but none of the other MADC stuff matters here.

Thanks.


- Dave
--

[ message continues ]

This chip being used on a whole bunch of boards:

 - Gumstix Overo
 - BeagleBoard.org
 - Omap ZOOM (Labrador)
 - OMAP 2430 and 3430 SDP,
 - OMAP2 and OMAP3 EVM
 - ... more (openpandora.org ?)

which will get much closer to "usable with mainline kernels"

... ergo, some comments below.  I'll hope we won't need
too many more iterations of fixes before we get a baseline
suitable for a 2.6.28-rc0 merge.

This version was posted since it's a good milestone, with
a bunch of recent updates from Felipe and me.  I'd think
most of the comments below can be addressed pretty easily.


I suspect that's three headers-too-many, and that the fix
should (a) move register decls needed for IRQ setup into
the twl4030.h file, and (b) move other headers into the

Hardly any of this code is actually OMAP-specific.  I stuck
those dependencies in to prevent build breakage related to
how the current code expects some global IRQ symbols.  When

It could probably stand a header comment giving a bit more detail

I suspect these can/should be replaced with "0", "1", "2", and "3"
everywhere they get used, referring to the relevant I2C address
(0x48 + 0/1/2/3) used to access a given function.  :)

NUM_NUM should be reserved for lolcat usage.


And while I find the register addressing needlessly (?) confusing,
it's not a thing I'd suggest changing right away.  It *could* have
been based on a {slave, register} pairing.  Instead it's based
mapping {module, offset} to those "real" addresses.  Maybe some

IMO those IRQ registers should be moved into the twl4030.h

This __initconst stuff bothers me a bit.  On one hand
it's "not strictly correct" because the driver could
be unbound from the hardware (e.g. sysfs, or rmmod of
its i2c_adapter) ... and then need this data again if
it gets re-initialized.

On the other hand, anyone trying to break systems like
that will succeed and it's only a question of how quickly
the kablooie happens.  I'd rather just ensure the driver
can't ever be ...
[ message continues ]

Cool. I'll post some patches against mainline kernel
for booting minimal omap3 boards within next few days.
So we should get at least beagle and overo booting
to some extent, maybe with serial and musb.

Tony
--

[ message continues ]

My bad.  Openpandora just opened for preorders *today* (PST)
and sold out all 3000 units.  I'm sure I mentioned it well
after most of them were sold, so it's not my fault their

Sounds like it *should* be a nice, modest, achievable
goal, right?  Something tells me it won't be that easy!
More power to you.

- Dave

  
--

[ message continues ]

Hmm, well it's really the rest of the already posted omap2-upstream
that RMK already commented on, plus one patch for sram for 34xx,
then just the board files. So it should be doable yeah.

Tony
--

[ message continues ]