[PATCH] TWL4030: Reset header file to mainline

[PATCH] TWL4030: Reset header file to mainline

[Amit Kucheria]

Reset twl4030.h to what is upstream. Patches to restore twl4030_power
functionality will follow directly to lkml.

Compile-tested only.

Signed-off-by: Amit Kucheria <amit.kucheria@verdurent.com>
---
 include/linux/i2c/twl4030.h |   78 +++---------------------------------------
 1 files changed, 6 insertions(+), 72 deletions(-)

diff --git a/include/linux/i2c/twl4030.h b/include/linux/i2c/twl4030.h
index 87accda..0dc80ef 100644
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -243,37 +243,6 @@ int twl4030_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned num_bytes);
 #define RES_STATE_SLEEP		0x8
 #define RES_STATE_OFF		0x0
 
-/* Power resources */
-
-#define RES_VAUX1               1
-#define RES_VAUX2               2
-#define RES_VAUX3               3
-#define RES_VAUX4               4
-#define RES_VMMC1               5
-#define RES_VMMC2               6
-#define RES_VPLL1               7
-#define RES_VPLL2               8
-#define RES_VSIM                9
-#define RES_VDAC                10
-#define RES_VINTANA1            11
-#define RES_VINTANA2            12
-#define RES_VINTDIG             13
-#define RES_VIO                 14
-#define RES_VDD1                15
-#define RES_VDD2                16
-#define RES_VUSB_1V5            17
-#define RES_VUSB_1V8            18
-#define RES_VUSB_3V1            19
-#define RES_VUSBCP              20
-#define RES_REGEN               21
-#define RES_NRES_PWRON          22
-#define RES_CLKEN               23
-#define RES_SYSEN               24
-#define RES_HFCLKOUT            25
-#define RES_32KCLKOUT           26
-#define RES_RESET               27
-#define RES_Main_Ref            28
-
 /*
  * Power Bus Message Format ... these can be sent individually by Linux,
  * but are usually part of downloaded scripts that are run when various
@@ -333,19 +302,12 @@ struct twl4030_madc_platform_data {
 	int		irq_line;
 };
 
-/* Boards have uniqe mappings of {col, row} --> keycode.
- * Column and row are 4 bits, but range only from 0..7;
- * a PERSISTENT_KEY is "always on" and never reported.
- */
-#define KEY_PERSISTENT		0x00800000
-#define KEY(col, row, keycode)	(((col) << 28) | ((row) << 24) | (keycode))
-#define PERSISTENT_KEY(c, r)	KEY(c, r, KEY_PERSISTENT)
-
 struct twl4030_keypad_data {
-	unsigned rows;
-	unsigned cols;
-	unsigned *keymap;
-	unsigned short keymapsize;
+	int rows;
+	int cols;
+	int *keymap;
+	int irq;
+	unsigned int keymapsize;
 	unsigned int rep:1;
 };
 
@@ -358,34 +320,6 @@ struct twl4030_usb_data {
 	enum twl4030_usb_mode	usb_mode;
 };
 
-struct twl4030_ins {
-	u16 pmb_message;
-	u8 delay;
-};
-
-struct twl4030_script {
-	struct twl4030_ins *script;
-	unsigned size;
-	u8 flags;
-#define TRITON_WRST_SCRIPT	(1<<0)
-#define TRITON_WAKEUP12_SCRIPT	(1<<1)
-#define TRITON_WAKEUP3_SCRIPT	(1<<2)
-#define TRITON_SLEEP_SCRIPT	(1<<3)
-};
-
-struct twl4030_resconfig {
-	u8 resource;
-	u8 devgroup;
-	u8 type;
-	u8 type2;
-};
-
-struct twl4030_power_data {
-	struct twl4030_script **scripts;
-	unsigned size;
-	const struct twl4030_resconfig *resource_config;
-};
-
 struct twl4030_platform_data {
 	unsigned				irq_base, irq_end;
 	struct twl4030_bci_platform_data	*bci;
@@ -393,7 +327,6 @@ struct twl4030_platform_data {
 	struct twl4030_madc_platform_data	*madc;
 	struct twl4030_keypad_data		*keypad;
 	struct twl4030_usb_data			*usb;
-	struct twl4030_power_data		*power;
 
 	/* LDO regulators */
 	struct regulator_init_data		*vdac;
@@ -424,6 +357,7 @@ int twl4030_sih_setup(int module);
 #define TWL4030_VAUX3_DEV_GRP		0x1F
 #define TWL4030_VAUX3_DEDICATED		0x22
 
+
 #if defined(CONFIG_TWL4030_BCI_BATTERY) || \
 	defined(CONFIG_TWL4030_BCI_BATTERY_MODULE)
 	extern int twl4030charger_usb_en(int enable);
-- 
1.6.3.1

Re: [PATCH] TWL4030: Reset header file to mainline

[Felipe Balbi]

on subject put REMOVE_OMAP_LEGACY_CODE like all the other related
patches so it's easier to track down which features we're loosing :-p

-- 
balbi

Re: [PATCH] TWL4030: Reset header file to mainline

[Tony Lindgren]

* Felipe Balbi <felipe.balbi@nokia.com> [090617 04:43]:
> 
> on subject put REMOVE_OMAP_LEGACY_CODE like all the other related
> patches so it's easier to track down which features we're loosing :-p

I actually have similar patches here already for all the I2C stuff
and the remaining twl4030 stuff.. Will push today.

Tony

Re: [PATCH] TWL4030: Reset header file to mainline

[Eugeny S. Mints]

Amit Kucheria wrote:
> Reset twl4030.h to what is upstream. Patches to restore twl4030_power
> functionality will follow directly to lkml.
>
>   
development against upstream is great. But what will be left for
this mail list if we send all patches directly to lkml?

Eugeny

Re: [PATCH] TWL4030: Reset header file to mainline

[Tony Lindgren]

* Eugeny S. Mints <eugeny.mints@gmail.com> [090617 06:46]:
> Amit Kucheria wrote:
>> Reset twl4030.h to what is upstream. Patches to restore twl4030_power
>> functionality will follow directly to lkml.
>>
>>   
> development against upstream is great. But what will be left for
> this mail list if we send all patches directly to lkml?

Anything touching arch/arm/*omap*.

Also, while waiting things to get to mainline, we can merge in various
topic branches, such as PM, DSS2. So basically linux-omap master branch
will shortly be just a queue of things going to the mainline tree while
waiting for the next merge window.

Regards,

Tony

Re: [PATCH] TWL4030: Reset header file to mainline

[Amit Kucheria]

On 09 Jun 17, Eugeny S. Mints wrote:
> Amit Kucheria wrote:
>> Reset twl4030.h to what is upstream. Patches to restore twl4030_power
>> functionality will follow directly to lkml.
>>
>>   
> development against upstream is great. But what will be left for
> this mail list if we send all patches directly to lkml?

I think the idea is that (and Tony should correct me here if I'm wrong)
core OMAP code is handled here while peripheral drivers will all go
directly to their respective susbsystem maintainers upstream.

-- 
-------------------------------------------------------------------------
Amit Kucheria,				 Kernel Developer, Verdurent
-------------------------------------------------------------------------

Re: [PATCH] TWL4030: Reset header file to mainline

[Eugeny S. Mints]

Tony Lindgren wrote:
> * Eugeny S. Mints <eugeny.mints@gmail.com> [090617 06:46]:
>   
>> Amit Kucheria wrote:
>>     
>>> Reset twl4030.h to what is upstream. Patches to restore twl4030_power
>>> functionality will follow directly to lkml.
>>>
>>>   
>>>       
>> development against upstream is great. But what will be left for
>> this mail list if we send all patches directly to lkml?
>>     
>
> Anything touching arch/arm/*omap*.
>   

I'm not sure how many non-omap based boards out there are using twl4030 
chip and if a separate mfd mail list exists.
But until any of the above is true I personally feel that twl4030 
related discussions naturally fall into omap mail list.

> Also, while waiting things to get to mainline, we can merge in various
> topic branches, such as PM, DSS2. So basically linux-omap master branch
> will shortly be just a queue of things going to the mainline tree while
> waiting for the next merge window.
>
>   
ok
> Regards,
>
> Tony
>
>   

Re: [PATCH] TWL4030: Reset header file to mainline

[Tony Lindgren]

* Amit Kucheria <amit.kucheria@verdurent.com> [090617 07:19]:
> On 09 Jun 17, Eugeny S. Mints wrote:
> > Amit Kucheria wrote:
> >> Reset twl4030.h to what is upstream. Patches to restore twl4030_power
> >> functionality will follow directly to lkml.
> >>
> >>   
> > development against upstream is great. But what will be left for
> > this mail list if we send all patches directly to lkml?
> 
> I think the idea is that (and Tony should correct me here if I'm wrong)
> core OMAP code is handled here while peripheral drivers will all go
> directly to their respective susbsystem maintainers upstream.

Yeah, so for the twl4030 patches that's mostly drivers/mfd.

If we pile up things to linux-omap, that code never goes anywhere
and keeps piling up!

And now for the first time ever, we have pretty much all we need
working in the mainline kernel! So that should be the stable base
for any distros or prodcuts starting with 2.6.31.

Tony

Re: [PATCH] TWL4030: Reset header file to mainline

[Mark Brown]

On Wed, Jun 17, 2009 at 06:20:24PM +0400, Eugeny S. Mints wrote:
> Tony Lindgren wrote:

>> Anything touching arch/arm/*omap*.

> I'm not sure how many non-omap based boards out there are using twl4030  
> chip and if a separate mfd mail list exists.
> But until any of the above is true I personally feel that twl4030  
> related discussions naturally fall into omap mail list.

While the overwhelming majority of TWL4030 specifics will only actually
be seen on OMAP systems (so CCing the OMAP list makes sense) the code
also exists in the context of the rest of the kernel.  It needs review
by subsystem maintainers and people working on non-OMAP systems may have
useful input based on their general experience of working on simiar
parts - in general Linux terms the fact that you've got, for example, a
keyboard controller is at least as relevant as the fact that it's likely
to be used on an OMAP system.

Many subsystems don't have a separate list and just use linux-kernel.

Re: [PATCH] TWL4030: Reset header file to mainline

[Kalle Valo]

Mark Brown <broonie@opensource.wolfsonmicro.com> writes:

> On Wed, Jun 17, 2009 at 06:20:24PM +0400, Eugeny S. Mints wrote:
>> Tony Lindgren wrote:
>
>>> Anything touching arch/arm/*omap*.
>
>> I'm not sure how many non-omap based boards out there are using twl4030  
>> chip and if a separate mfd mail list exists.
>> But until any of the above is true I personally feel that twl4030  
>> related discussions naturally fall into omap mail list.
>
> While the overwhelming majority of TWL4030 specifics will only actually
> be seen on OMAP systems (so CCing the OMAP list makes sense) the code
> also exists in the context of the rest of the kernel.  It needs review
> by subsystem maintainers and people working on non-OMAP systems may have
> useful input based on their general experience of working on simiar
> parts - in general Linux terms the fact that you've got, for example, a
> keyboard controller is at least as relevant as the fact that it's likely
> to be used on an OMAP system.
>
> Many subsystems don't have a separate list and just use linux-kernel.

Yes, and nobody will blame if you CCed linux-omap list twl4030, quite
the opposite. Even if all omap code is in mainline, it doesn't mean that
this list will fade away. I would anticipate even the opposite, more
people might get interested.

-- 
Kalle Valo