| Message ID | 1245238182-11697-1-git-send-email-amit.kucheria@verdurent.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
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
* 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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);
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(-)