[PATCH 0/3]TWL4030 BCI patches
Hi Tony, I am resending the BCI 3 patch series after fixing the comments provided by Mikko. Regards, Madhu -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Resending - PATCH 1/3] Triton BCI driver board/device setup for OMAP3430
From: Madhusudhan Chikkature[EMAIL PROTECTED]
Device setup/board level initialization for the Triton battery charger
interface driver for the OMAP3430 SDP.
Signed-off-by: Madhusudhan Chikkature[EMAIL PROTECTED]
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/bci.c | 57 ++
arch/arm/mach-omap2/board-3430sdp.c |1
include/asm-arm/arch-omap/bci.h | 17
include/asm-arm/arch-omap/board-3430sdp.h |1
5 files changed, 78 insertions(+), 1 deletion(-)
Index: linux-omap-2.6/arch/arm/mach-omap2/Makefile
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/Makefile2008-07-22
11:58:54.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/Makefile 2008-07-22 12:01:10.0
+0530
@@ -47,7 +47,8 @@ obj-$(CONFIG_MACH_OMAP_3430SDP) += boar
hsmmc.o \
usb-musb.o \
usb-ehci.o \
- board-3430sdp-flash.o
+ board-3430sdp-flash.o \
+ bci.o
obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \
hsmmc.o \
usb-musb.o usb-ehci.o \
Index: linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/board-3430sdp.c 2008-07-22
11:58:54.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c 2008-07-22
12:01:10.0 +0530
@@ -299,6 +299,7 @@ static void __init omap_3430sdp_init(voi
ARRAY_SIZE(sdp3430_spi_board_info));
ads7846_dev_init();
sdp3430_flash_init();
+ twl4030_bci_battery_init();
omap_serial_init();
usb_musb_init();
usb_ehci_init();
Index: linux-omap-2.6/include/asm-arm/arch-omap/board-3430sdp.h
===
--- linux-omap-2.6.orig/include/asm-arm/arch-omap/board-3430sdp.h
2008-07-22
11:58:54.0 +0530
+++ linux-omap-2.6/include/asm-arm/arch-omap/board-3430sdp.h2008-07-22
12:01:10.0 +0530
@@ -31,6 +31,7 @@
extern void sdp3430_usb_init(void);
extern void sdp3430_flash_init(void);
+extern void twl4030_bci_battery_init(void);
#define DEBUG_BASE 0x0800 /* debug board */
Index: linux-omap-2.6/arch/arm/mach-omap2/bci.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-omap-2.6/arch/arm/mach-omap2/bci.c2008-07-22 12:02:39.0
+0530
@@ -0,0 +1,57 @@
+/*
+ * linux/arch/arm/mach-omap2/bci.c
+ *
+ * TWL4030 BCI platform device setup/initialization
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include asm/arch/bci.h
+
+#if defined(CONFIG_TWL4030_BCI_BATTERY) || \
+ defined(CONFIG_TWL4030_BCI_BATTERY_MODULE)
+/*
+ * Thermistor Calibration for Current Source and MADC
+ * Tolerance (for THS05-3H103F)
+ */
+static int sdp3430_batt_table[] = {
+/* 0 C*/
+30800, 29500, 28300, 27100,
+26000, 24900, 23900, 22900, 22000, 21100, 20300, 19400, 18700, 17900,
+17200, 16500, 15900, 15300, 14700, 14100, 13600, 13100, 12600, 12100,
+11600, 11200, 10800, 10400, 1, 9630, 9280, 8950, 8620, 8310,
+8020, 7730, 7460, 7200, 6950, 6710, 6470, 6250, 6040, 5830,
+5640, 5450, 5260, 5090, 4920, 4760, 4600, 4450, 4310, 4170,
+4040, 3910, 3790, 3670, 3550
+};
+
+static struct twl4030_bci_platform_data sdp3430_bci_data = {
+ .battery_tmp_tbl = sdp3430_batt_table,
+ .tblsize = ARRAY_SIZE(sdp3430_batt_table),
+};
+
+static struct platform_device twl4030_bci_battery_device = {
+ .name = twl4030-bci-battery,
+ .id = -1,
+ .dev= {
+ .platform_data = sdp3430_bci_data,
+ },
+ .num_resources = 0,
+};
+
+void __init twl4030_bci_battery_init(void)
+{
+ (void) platform_device_register(twl4030_bci_battery_device);
+}
+#else
+void __init twl4030_bci_battery_init(void)
+{
+}
+#endif
Index: linux-omap-2.6/include/asm-arm/arch-omap/bci.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-omap-2.6/include/asm-arm/arch-omap/bci.h 2008-07-22
12:01:10.0 +0530
@@ -0,0 +1,17 @@
+/*
+ *
[Resending - PATCH 3/3] Triton BCI driver for OMAP3430 - USB changes
From: Madhusudhan Chikkature[EMAIL PROTECTED]
This patch calls the functionality supported by the TWL4030 battery charger
interface driver
to enable/disable battery charging upon cable attach/detach.
Signed-off-by: Madhusudhan Chikkature[EMAIL PROTECTED]
---
drivers/i2c/chips/twl4030-usb.c |7 +--
include/linux/i2c/twl4030.h |7 +++
2 files changed, 12 insertions(+), 2 deletions(-)
Index: linux-omap-2.6/drivers/i2c/chips/twl4030-usb.c
===
--- linux-omap-2.6.orig/drivers/i2c/chips/twl4030-usb.c 2008-07-03
16:09:05.0 +0530
+++ linux-omap-2.6/drivers/i2c/chips/twl4030-usb.c 2008-07-03
17:03:30.0 +0530
@@ -601,10 +601,13 @@ static irqreturn_t twl4030_usb_irq(int i
goto done;
}
- if (val USB_PRES_RISING)
+ if (val USB_PRES_RISING) {
twl4030_phy_resume();
- else
+ twl4030charger_usb_en(1);
+ } else {
+ twl4030charger_usb_en(0);
twl4030_phy_suspend(0);
+ }
ret = IRQ_HANDLED;
Index: linux-omap-2.6/include/linux/i2c/twl4030.h
===
--- linux-omap-2.6.orig/include/linux/i2c/twl4030.h 2008-07-03
16:09:05.0 +0530
+++ linux-omap-2.6/include/linux/i2c/twl4030.h 2008-07-03 17:03:30.0
+0530
@@ -127,4 +127,11 @@ int twl4030_set_gpio_edge_ctrl(int gpio,
int twl4030_set_gpio_debounce(int gpio, int enable);
int twl4030_free_gpio(int gpio);
+#if defined(CONFIG_TWL4030_BCI_BATTERY) || \
+ defined(CONFIG_TWL4030_BCI_BATTERY_MODULE)
+ extern int twl4030charger_usb_en(int enable);
+#else
+ static inline int twl4030charger_usb_en(int enable) { return 0; }
+#endif
+
#endif /* End of __TWL4030_H */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Resending - PATCH 2/3] Triton BCI driver for OMAP3430
From: Madhusudhan Chikkature[EMAIL PROTECTED] ARM: OMAP: Triton Battery Charger Interface This patch provides a OMAP Triton battery charger interface driver to moniter the battery through power class subsystem. Signed-off-by: Madhusudhan Chikkature[EMAIL PROTECTED] --- drivers/power/Kconfig |8 drivers/power/Makefile |1 drivers/power/twl4030_bci_battery.c | 1080 3 files changed, 1089 insertions(+) Index: linux-omap-2.6/drivers/power/Kconfig === --- linux-omap-2.6.orig/drivers/power/Kconfig 2008-07-21 14:33:02.0 +0530 +++ linux-omap-2.6/drivers/power/Kconfig2008-07-22 10:47:07.0 +0530 @@ -70,4 +70,12 @@ config BATTERY_BQ27200 help Say Y here to enable support for batteries with BQ27200(I2C) chip. +config TWL4030_BCI_BATTERY + tristate OMAP TWL4030 BCI Battery driver + depends on (MACH_OMAP_2430SDP || MACH_OMAP_3430SDP) TWL4030_MADC + default y + help + Support for OMAP TWL4030 BCI Battery driver. + This driver can give support for TWL4030 Battery Charge Interface. + endif # POWER_SUPPLY Index: linux-omap-2.6/drivers/power/Makefile === --- linux-omap-2.6.orig/drivers/power/Makefile 2008-07-21 14:33:02.0 +0530 +++ linux-omap-2.6/drivers/power/Makefile 2008-07-21 14:33:35.0 +0530 @@ -21,3 +21,4 @@ obj-$(CONFIG_BATTERY_DS2760) += ds2760_b obj-$(CONFIG_BATTERY_PMU) += pmu_battery.o obj-$(CONFIG_BATTERY_OLPC) += olpc_battery.o obj-$(CONFIG_BATTERY_BQ27x00) += bq27x00_battery.o +obj-$(CONFIG_TWL4030_BCI_BATTERY) += twl4030_bci_battery.o Index: linux-omap-2.6/drivers/power/twl4030_bci_battery.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-omap-2.6/drivers/power/twl4030_bci_battery.c 2008-07-22 13:58:40.0 +0530 @@ -0,0 +1,1080 @@ +/* + * linux/drivers/power/twl4030_bci_battery.c + * + * OMAP2430/3430 BCI battery driver for Linux + * + * Copyright (C) 2008 Texas Instruments, Inc. + * Author: Texas Instruments, Inc. + * + * This package is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. + */ + +#include linux/init.h +#include linux/module.h +#include linux/device.h +#include linux/interrupt.h +#include linux/delay.h +#include linux/platform_device.h +#include linux/i2c/twl4030.h +#include linux/power_supply.h +#include asm/arch/bci.h +#include linux/i2c/twl4030-madc.h + +#define T2_BATTERY_VOLT0x04 +#define T2_BATTERY_TEMP0x06 +#define T2_BATTERY_CUR 0x08 + +/* charger constants */ +#define NO_PW_CONN 0 +#define AC_PW_CONN 0x01 +#define USB_PW_CONN0x02 + +/* TWL4030_MODULE_USB */ +#define REG_POWER_CTRL 0x0AC +#define OTG_EN 0x020 +#define REG_PHY_CLK_CTRL 0x0FE +#define REG_PHY_CLK_CTRL_STS 0x0FF +#define PHY_DPLL_CLK 0x01 + +#define REG_BCICTL10x023 +#define REG_BCICTL20x024 +#define CGAIN 0x020 +#define ITHEN 0x010 +#define ITHSENS0x007 + +/* Boot BCI flag bits */ +#define BCIAUTOWEN 0x020 +#define CONFIG_DONE0x010 +#define BCIAUTOUSB 0x002 +#define BCIAUTOAC 0x001 +#define BCIMSTAT_MASK 0x03F + +/* Boot BCI register */ +#define REG_BOOT_BCI 0x007 +#define REG_CTRL1 0x00 +#define REG_SW1SELECT_MSB 0x07 +#define SW1_CH9_SEL0x02 +#define REG_CTRL_SW1 0x012 +#define SW1_TRIGGER0x020 +#define EOC_SW10x002 +#define REG_GPCH9 0x049 +#define REG_STS_HW_CONDITIONS 0x0F +#define STS_VBUS 0x080 +#define STS_CHG0x02 +#define REG_BCIMSTATEC 0x02 +#define REG_BCIMFSTS4 0x010 +#define REG_BCIMFSTS2 0x00E +#define REG_BCIMFSTS3 0x00F +#define REG_BCIMFSTS1 0x001 +#define USBFASTMCHG0x004 +#define BATSTSPCHG 0x004 +#define BATSTSMCHG 0x040 +#define VBATOV40x020 +#define VBATOV30x010 +#define VBATOV20x008 +#define VBATOV10x004 +#define REG_BB_CFG 0x012 +#define BBCHEN 0x010 + +/* Power supply charge interrupt */ +#define REG_PWR_ISR1 0x00 +#define REG_PWR_IMR1 0x01
[PATCH] Free HDQ clocks in error path
Hi,
This patch provides the fix to free the HDQ clocks in the error path.
Regards,
Madhu
-
From: Madhusudhan Chikkature[EMAIL PROTECTED]
ARM: OMAP3: Free HDQ clocks when a read is tried with no battery connected
Signed-off-by: Madhusudhan Chikkature[EMAIL PROTECTED]
---
drivers/w1/masters/omap_hdq.c |5 -
1 files changed, 4 insertions(+), 1 deletion(-)
Index: linux-omap-ti.git-07102008/drivers/w1/masters/omap_hdq.c
===
--- linux-omap-ti.git-07102008.orig/drivers/w1/masters/omap_hdq.c
2008-07-02
20:10:38.0 +0530
+++ linux-omap-ti.git-07102008/drivers/w1/masters/omap_hdq.c2008-07-16
12:17:42.0 +0530
@@ -515,8 +515,11 @@ static u8 omap_w1_read_byte(void *data)
int ret;
ret = hdq_read_byte(val);
- if (ret)
+ if (ret) {
+ init_trans = 0;
+ omap_hdq_put();
return -1;
+ }
/* Write followed by a read, release the module */
if (init_trans) {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP3 SYS_OFF_MODE support
I am just wondering why these changes are present in smartreflex.c. These should be initialized during prcm init or PMIC init (if there are parameters dependent on PMIC) ideally. I can't think of any dependency between smartreflex and SYS_OFF_MODE feature. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter 'p2' De Schrijver Sent: Monday, July 21, 2008 9:47 PM To: linux-omap@vger.kernel.org Subject: RFC: OMAP3 SYS_OFF_MODE support The following patch set introduces support for the OMAP3 SYS_OFF_MODE signal. This will cause a properly programmed triton2 to shutdown the VDD1 and VDD2 regulators when both core and MPU powerdomain are in off state. The patches includes programming triton2 with the appropriate scripts for the SDP3430 board. By default the OMAP3 polarity of the SYS_OFF_MODE signal is inverted compared to what triton2 expects. This means the polarity needs to be changed before the triton2 scripts are activated, otherwise the system will crash. At the moment this is done in omap2_clk_init as this function is called before triton2 is initialized. Better suggestions are welcome. Thanks to Kalle Jokiniemi for doing the initial patch and test work. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: N800 problems with MMC, LM8323 on current linux-omap git head
On Tue, 22 Jul 2008 15:47:43 +0300, Riku Voipio [EMAIL PROTECTED] wrote: Hmm. I think it would be better to avoid calling the probe in first place. git diff made the attached patch look more confusing than it actually is. Personally I'd eliminate all ifdefs from those i2c_board_info structs. I did the same thing before, but then we're gonna start adding several i2c_board_info for different hw. I mean, we should just reuse the code and the driver should know when the device is not present and stop probing without any problems to the rest of the system. -- Best Regards, Felipe Balbi http://blog.felipebalbi.com [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: N800 problems with MMC, LM8323 on current linux-omap git head
Subject: [PATCH] input: add more error checks to lm8323 driver
If we can't reach the driver, we stop trying to probe
it. Useful when building kernel for n800 and n810.
n800 doesn't have lm8323, so that driver shouldn't probe
there.
Hmm. I think it would be better to avoid calling the probe
in first place. git diff made the attached patch look more
confusing than it actually is. Personally I'd eliminate
all ifdefs from those i2c_board_info structs.
--
rm -rf only sounds scary if you don't have backups
From 574835f1532f0be01e0456f98bf13ebb954bc6c3 Mon Sep 17 00:00:00 2001
From: Riku Voipio [EMAIL PROTECTED]
Date: Tue, 22 Jul 2008 00:29:31 +0300
Subject: [PATCH] Separate i2c_board_info for n800 and n810
n800 and n810 have different peripherals, on the second i2c bus
(tea5761 on n800 and lm8323 on n810). Thus they need different
i2c_board_info as well to avoid probing nonexistent devices.
---
arch/arm/mach-omap2/board-n800.c | 24 +---
1 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n800.c b/arch/arm/mach-omap2/board-n800.c
index ae85c2c..95a2727 100644
--- a/arch/arm/mach-omap2/board-n800.c
+++ b/arch/arm/mach-omap2/board-n800.c
@@ -654,13 +654,26 @@ static struct i2c_board_info __initdata_or_module
n800_i2c_board_info_2[] = {
I2C_BOARD_INFO(tea5761, 0x10),
},
#endif
-#ifdef CONFIG_MACH_NOKIA_N810
+ {
+ I2C_BOARD_INFO(tsl2563, 0x29),
+ },
+ {
+ I2C_BOARD_INFO(lp5521, 0x32),
+ },
+};
+
+static struct i2c_board_info __initdata_or_module n810_i2c_board_info_2[] = {
+#if defined (CONFIG_VIDEO_TCM825X) || defined (CONFIG_VIDEO_TCM825X_MODULE)
+ {
+ I2C_BOARD_INFO(TCM825X_NAME, TCM825X_I2C_ADDR),
+ .platform_data = n800_tcm825x_platform_data,
+ },
+#endif
{
I2C_BOARD_INFO(lm8323, 0x45),
.irq= OMAP_GPIO_IRQ(109),
.platform_data = lm8323_pdata,
},
-#endif
{
I2C_BOARD_INFO(tsl2563, 0x29),
},
@@ -690,8 +703,13 @@ void __init nokia_n800_common_init(void)
omap_serial_init();
omap_register_i2c_bus(1, 400, n800_i2c_board_info_1,
ARRAY_SIZE(n800_i2c_board_info_1));
- omap_register_i2c_bus(2, 400, n800_i2c_board_info_2,
+ if (machine_is_nokia_n800())
+ omap_register_i2c_bus(2, 400, n800_i2c_board_info_2,
ARRAY_SIZE(n800_i2c_board_info_2));
+ if (machine_is_nokia_n810())
+ omap_register_i2c_bus(2, 400, n810_i2c_board_info_2,
+ ARRAY_SIZE(n810_i2c_board_info_2));
+
mipid_dev_init();
blizzard_dev_init();
}
--
1.5.5.4
Re: N800 problems with MMC, LM8323 on current linux-omap git head
On Tue, Jul 22, 2008 at 07:52:44AM -0500, Felipe Balbi wrote: On Tue, 22 Jul 2008 15:47:43 +0300, Riku Voipio [EMAIL PROTECTED] wrote: Hmm. I think it would be better to avoid calling the probe in first place. git diff made the attached patch look more confusing than it actually is. Personally I'd eliminate all ifdefs from those i2c_board_info structs. I did the same thing before, but then we're gonna start adding several i2c_board_info for different hw. I mean, we should just reuse the code and the driver should know when the device is not present and stop probing without any problems to the rest of the system. If the different hw has different devices on the i2c bus, then different i2c_board_info struct should be provided. IIRC i2c_board_info is expected to provide a accurate picture of what i2c devices is connected to the bus. This has been used as a argument to remove detection code from .probe functions. To all the confused i2c list readers, the topic is about should we split n800_i2c_board_info_2 [0] to n800 and n810 specific structs[1] or make the lm8323 configure to err out earlier[2]. [0] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=arch/arm/mach-omap2/board-n800.c;h=ae85c2c60534820856c8bb0e019be29f2375470b;hb=HEAD#l645 [1] http://article.gmane.org/gmane.linux.ports.arm.omap/9562 [2] http://article.gmane.org/gmane.linux.ports.arm.omap/9522 rm -rf only sounds scary if you don't have backups -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [i2c] N800 problems with MMC, LM8323 on current linux-omap git head
On Tue, Jul 22, 2008 at 04:37:42PM +0300, Riku Voipio wrote: On Tue, Jul 22, 2008 at 07:52:44AM -0500, Felipe Balbi wrote: On Tue, 22 Jul 2008 15:47:43 +0300, Riku Voipio [EMAIL PROTECTED] wrote: Hmm. I think it would be better to avoid calling the probe in first place. git diff made the attached patch look more confusing than it actually is. Personally I'd eliminate all ifdefs from those i2c_board_info structs. I did the same thing before, but then we're gonna start adding several i2c_board_info for different hw. I mean, we should just reuse the code and the driver should know when the device is not present and stop probing without any problems to the rest of the system. If the different hw has different devices on the i2c bus, then different i2c_board_info struct should be provided. IIRC i2c_board_info is expected to provide a accurate picture of what i2c devices is connected to the bus. This has been used as a argument to remove detection code from .probe functions. To all the confused i2c list readers, the topic is about should we split n800_i2c_board_info_2 [0] to n800 and n810 specific structs[1] or make the lm8323 configure to err out earlier[2]. Split them into a common and then machine specfic structures, you are allowed to register more than one board per bus. [0] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=arch/arm/mach-omap2/board-n800.c;h=ae85c2c60534820856c8bb0e019be29f2375470b;hb=HEAD#l645 [1] http://article.gmane.org/gmane.linux.ports.arm.omap/9562 [2] http://article.gmane.org/gmane.linux.ports.arm.omap/9522 rm -rf only sounds scary if you don't have backups ___ i2c mailing list [EMAIL PROTECTED] http://lists.lm-sensors.org/mailman/listinfo/i2c -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [i2c] N800 problems with MMC, LM8323 on current linux-omap git head
Hi, On Tue, 22 Jul 2008 14:43:14 +0100, Ben Dooks [EMAIL PROTECTED] wrote: Split them into a common and then machine specfic structures, you are allowed to register more than one board per bus. Good to know :-) Riku, could you update your patch then ? but it anyways doesn't annul the need of a better error handling in lm8323. I think both patches will need to be applied :-) -- Best Regards, Felipe Balbi http://blog.felipebalbi.com [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP3 SYS_OFF_MODE support
Currently sr_configure_vc() is the only dedicated API to configure Voltage controller parameter. But still SYSOFF specific configuration shall be moved to prcm init. Regards, Deva -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of TK, Pratheesh Gangadhar Sent: Tuesday, July 22, 2008 5:36 PM To: Peter 'p2' De Schrijver; linux-omap@vger.kernel.org Subject: RE: OMAP3 SYS_OFF_MODE support I am just wondering why these changes are present in smartreflex.c. These should be initialized during prcm init or PMIC init (if there are parameters dependent on PMIC) ideally. I can't think of any dependency between smartreflex and SYS_OFF_MODE feature. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter 'p2' De Schrijver Sent: Monday, July 21, 2008 9:47 PM To: linux-omap@vger.kernel.org Subject: RFC: OMAP3 SYS_OFF_MODE support The following patch set introduces support for the OMAP3 SYS_OFF_MODE signal. This will cause a properly programmed triton2 to shutdown the VDD1 and VDD2 regulators when both core and MPU powerdomain are in off state. The patches includes programming triton2 with the appropriate scripts for the SDP3430 board. By default the OMAP3 polarity of the SYS_OFF_MODE signal is inverted compared to what triton2 expects. This means the polarity needs to be changed before the triton2 scripts are activated, otherwise the system will crash. At the moment this is done in omap2_clk_init as this function is called before triton2 is initialized. Better suggestions are welcome. Thanks to Kalle Jokiniemi for doing the initial patch and test work. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Resending - PATCH 1/3] Triton BCI driver board/device setup for OMAP3430
Hi Felipe, Tony, weird that we still have these prototypes in these headers. Could be some merging conflict ? Yes. I see that these prototypes are still present in the board3430 and board2430 header files in the omap tree. Anyways, please apply the attached patch. We're using usb_musb_init() and usb_ehci_init() now. You mean I should apply the attached patch you sent for local use, right? And I guess I dont need to resend this perticular BCI patch, am I correct? Regards, Madhu - Original Message - From: Felipe Balbi [EMAIL PROTECTED] To: Tony Lindgren [EMAIL PROTECTED] Cc: Madhusudhan Chikkature [EMAIL PROTECTED]; linux-omap@vger.kernel.org; [EMAIL PROTECTED] Sent: Tuesday, July 22, 2008 6:03 PM Subject: Re: [Resending - PATCH 1/3] Triton BCI driver board/device setup for OMAP3430 Hi, On Tue, 22 Jul 2008 17:25:33 +0530 (IST), Madhusudhan Chikkature [EMAIL PROTECTED] wrote: extern void sdp3430_usb_init(void); Tony, weird that we still have these prototypes in these headers. Could be some merging conflict ? Anyways, please apply the attached patch. We're using usb_musb_init() and usb_ehci_init() now. -- Best Regards, Felipe Balbi http://blog.felipebalbi.com [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/9] TWL4030 bugfixes and cleanups: version 2
[ This is the second version of these patches - they now check the SIH_CTRL.COR bit to determine whether to read or write to clear ] At boot, twl_init_irq() tries to mask off all TWL4030 secondary interrupts and clear them, since no secondary interrupt handlers are registered yet (that happens later in the boot). However, this code is flawed. MADC, BCI, keypad, and GPIO ISRs are either not cleared or are incompletely cleared. Some BCI register addresses are nonsensical. And some code attempts to clear ISRs before masking IMRs, which is race-prone (an interrupt could occur after the ISR clear, but before the mask). These problems can cause large numbers of boot messages similar to this: TWL4030 module irq 368 is disabled but can't be masked! and I2C transmit overflows, both observed during boot on the BeagleBoard here. The actual IRQ number sometimes varied depending on which interrupt was unacknowledged. This series fixes these issues and does some code cleanup, saving 272 bytes. Thanks to Philip Balister [EMAIL PROTECTED], Koen Kooi [EMAIL PROTECTED], Måns Rullgård [EMAIL PROTECTED], Steve Sakoman [EMAIL PROTECTED] and others on #beagle for help tracing these problems. Thanks also to Peter De Schrijver [EMAIL PROTECTED] for help with this second version, allowing several unnecessary I2C transactions to be elided from twl_init_irq(). Tested on BeagleBoard rev B4 (3530ES2.2). - Paul --- size: textdata bss dec hex filename 3076157 142840 104248 3323245 32b56d vmlinux.beagle.orig 3075885 142840 104248 3322973 32b45d vmlinux.beagle diffstat: drivers/i2c/chips/twl4030-core.c | 383 ++-- drivers/i2c/chips/twl4030-gpio.c | 48 - drivers/i2c/chips/twl4030-pwrirq.c | 15 + include/linux/i2c/twl4030-gpio.h | 76 +++ include/linux/i2c/twl4030-pwrirq.h | 37 +++ 5 files changed, 359 insertions(+), 200 deletions(-) create mode 100644 include/linux/i2c/twl4030-gpio.h create mode 100644 include/linux/i2c/twl4030-pwrirq.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] TWL4030: clear TWL GPIO interrupt status registers
twl_init_irq() does not clear the TWL GPIO ISR registers, but the PIH
ISR thinks that it has. This causes any previously-latched GPIO interrupts
to be stuck on until twl4030-gpio.c initializes, often drowning the console in
TWL4030 module irq 368 is disabled but can't be masked!
messages. This seems to be a particular problem when booting on Beagle.
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
---
drivers/i2c/chips/twl4030-core.c | 42 ++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/chips/twl4030-core.c b/drivers/i2c/chips/twl4030-core.c
index ff662bc..dfc3805 100644
--- a/drivers/i2c/chips/twl4030-core.c
+++ b/drivers/i2c/chips/twl4030-core.c
@@ -857,6 +857,48 @@ static void twl_init_irq(void)
return;
}
+ /* GPIO_ISR1A */
+ res = twl4030_i2c_write_u8(TWL4030_MODULE_GPIO, 0xff, 0x19);
+ if (res 0) {
+ pr_err(%s[%d][%d]\n, msg, res, __LINE__);
+ return;
+ }
+
+ /* GPIO_ISR2A */
+ res = twl4030_i2c_write_u8(TWL4030_MODULE_GPIO, 0xff, 0x1a);
+ if (res 0) {
+ pr_err(%s[%d][%d]\n, msg, res, __LINE__);
+ return;
+ }
+
+ /* GPIO_ISR3A */
+ res = twl4030_i2c_write_u8(TWL4030_MODULE_GPIO, 0xff, 0x1b);
+ if (res 0) {
+ pr_err(%s[%d][%d]\n, msg, res, __LINE__);
+ return;
+ }
+
+ /* GPIO_ISR1B */
+ res = twl4030_i2c_write_u8(TWL4030_MODULE_GPIO, 0xff, 0x1f);
+ if (res 0) {
+ pr_err(%s[%d][%d]\n, msg, res, __LINE__);
+ return;
+ }
+
+ /* GPIO_ISR2B */
+ res = twl4030_i2c_write_u8(TWL4030_MODULE_GPIO, 0xff, 0x20);
+ if (res 0) {
+ pr_err(%s[%d][%d]\n, msg, res, __LINE__);
+ return;
+ }
+
+ /* GPIO_ISR3B */
+ res = twl4030_i2c_write_u8(TWL4030_MODULE_GPIO, 0xff, 0x21);
+ if (res 0) {
+ pr_err(%s[%d][%d]\n, msg, res, __LINE__);
+ return;
+ }
+
/* install an irq handler for each of the PIH modules */
for (i = TWL4030_IRQ_BASE; i TWL4030_IRQ_END; i++) {
set_irq_chip(i, twl4030_irq_chip);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] TWL4030: use correct register addresses for BCI IMR registers
The existing code to mask and clear BCI interrupts in twl_init_irq() is
wrong. It uses the wrong register offsets, it does not mask all of the
BCI IMR registers, and it does not clear all of the BCI ISR registers.
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
---
drivers/i2c/chips/twl4030-core.c | 40 --
1 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/chips/twl4030-core.c b/drivers/i2c/chips/twl4030-core.c
index dfc3805..bb0732c 100644
--- a/drivers/i2c/chips/twl4030-core.c
+++ b/drivers/i2c/chips/twl4030-core.c
@@ -750,29 +750,57 @@ static void twl_init_irq(void)
/* POWER HACK (END) */
/* Slave address 0x4A */
- /* BCIIMR1_1 */
+ /* BCIIMR1A */
+ res = twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xFF, 0x2);
+ if (res 0) {
+ pr_err(%s[%d][%d]\n, msg, res, __LINE__);
+ return;
+ }
+
+ /* BCIIMR2A */
res = twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xFF, 0x3);
if (res 0) {
pr_err(%s[%d][%d]\n, msg, res, __LINE__);
return;
}
- /* BCIIMR1_2 */
- res = twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xFF, 0x4);
+ /* BCIIMR1B */
+ res = twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xFF, 0x6);
if (res 0) {
pr_err(%s[%d][%d]\n, msg, res, __LINE__);
return;
}
- /* BCIIMR2_1 */
+ /* BCIIMR2B */
res = twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xFF, 0x7);
if (res 0) {
pr_err(%s[%d][%d]\n, msg, res, __LINE__);
return;
}
- /* BCIIMR2_2 */
- res = twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xFF, 0x8);
+ /* BCIISR1A */
+ res = twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xFF, 0x0);
+ if (res 0) {
+ pr_err(%s[%d][%d]\n, msg, res, __LINE__);
+ return;
+ }
+
+ /* BCIISR2A */
+ res = twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xFF, 0x1);
+ if (res 0) {
+ pr_err(%s[%d][%d]\n, msg, res, __LINE__);
+ return;
+ }
+
+ /* BCIISR1B */
+ res = twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xFF, 0x4);
+ if (res 0) {
+ pr_err(%s[%d][%d]\n, msg, res, __LINE__);
+ return;
+ }
+
+ /* BCIISR2B */
+ res = twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xFF, 0x5);
if (res 0) {
pr_err(%s[%d][%d]\n, msg, res, __LINE__);
return;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/9] TWL4030: clear MADC interrupt status registers upon init
twl_init_irq() does not clear MADC interrupt status registers upon init -
fix.
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
---
drivers/i2c/chips/twl4030-core.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/chips/twl4030-core.c b/drivers/i2c/chips/twl4030-core.c
index bb0732c..9d93524 100644
--- a/drivers/i2c/chips/twl4030-core.c
+++ b/drivers/i2c/chips/twl4030-core.c
@@ -821,6 +821,20 @@ static void twl_init_irq(void)
return;
}
+ /* MADC_ISR1 */
+ res = twl4030_i2c_write_u8(TWL4030_MODULE_MADC, 0xFF, 0x61);
+ if (res 0) {
+ pr_err(%s[%d][%d]\n, msg, res, __LINE__);
+ return;
+ }
+
+ /* MADC_ISR2 */
+ res = twl4030_i2c_write_u8(TWL4030_MODULE_MADC, 0xFF, 0x63);
+ if (res 0) {
+ pr_err(%s[%d][%d]\n, msg, res, __LINE__);
+ return;
+ }
+
/* key Pad */
/* KEYPAD - IMR1 */
res = twl4030_i2c_write_u8(TWL4030_MODULE_KEYPAD, 0xFF, (0x12));
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] TWL4030: use *_SIH_CTRL.COR bit to determine whether to read or write ISR to clear
TWL4030 interrupt status register bits can be cleared in one of two ways:
either by reading from the register, or by writing a 1 to the
appropriate bit(s) in the register. This behavior can be altered at any
time by the twlmodule_SIH_CTRL.COR register bit (clear-on-read).
The TWL4030 TRM is deeply confused as to whether COR=1 means that the
registers are cleared on reads, or cleared on writes. Peter De
Schrijver peter.de-schrijver confirms that COR=1 means that the registers
are cleared on read.
So, for each TWL4030 SIH, check the value of the *_SIH_CTRL.COR bit, and if
it is 1, use reads to clear the ISRs; if it is 0, use writes.
Also, use WARN_ON() to warn if the read/write failed, and don't skip
the rest of the initialization on failure either.
Thanks to Peter for his help with this patch.
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
---
drivers/i2c/chips/twl4030-core.c | 183 ++
1 files changed, 106 insertions(+), 77 deletions(-)
diff --git a/drivers/i2c/chips/twl4030-core.c b/drivers/i2c/chips/twl4030-core.c
index 9d93524..eae0634 100644
--- a/drivers/i2c/chips/twl4030-core.c
+++ b/drivers/i2c/chips/twl4030-core.c
@@ -133,6 +133,16 @@
/* on I2C-1 for 2430SDP */
#define CONFIG_I2C_TWL4030_ID 1
+/* SIH_CTRL registers */
+#define TWL4030_INT_PWR_SIH_CTRL 0x07
+#define TWL4030_INTERRUPTS_BCISIHCTRL 0x0d
+#define TWL4030_MADC_MADC_SIH_CTRL 0x67
+#define TWL4030_KEYPAD_KEYP_SIH_CTRL 0x17
+#define TWL4030_GPIO_GPIO_SIH_CTRL 0x2d
+
+#define TWL4030_SIH_CTRL_COR_MASK (1 2)
+
+
/* Helper functions */
static int
twl4030_detect_client(struct i2c_adapter *adapter, unsigned char sid);
@@ -712,13 +722,61 @@ static int power_companion_init(void)
return e;
}
+/**
+ * twl4030_i2c_clear_isr - clear TWL4030 SIH ISR regs via read + write
+ * @mod_no: TWL4030 module number
+ * @reg: register index to clear
+ * @cor: value of the module_SIH_CTRL.COR bit (1 or 0)
+ *
+ * Either reads (cor == 1) or writes (cor == 0) to a TWL4030 interrupt
+ * status register to ensure that any prior interrupts are cleared.
+ * Returns the status from the I2C read operation.
+ */
+static int twl4030_i2c_clear_isr(u8 mod_no, u8 reg, u8 cor)
+{
+ u8 tmp;
+
+ return (cor) ? twl4030_i2c_read_u8(mod_no, tmp, reg) :
+ twl4030_i2c_write_u8(mod_no, 0xff, reg);
+}
+
+/**
+ * twl4030_read_cor_bit - are TWL module ISRs cleared by reads or writes?
+ * @mod_no: TWL4030 module number
+ * @reg: register index to clear
+ *
+ * Returns 1 if the TWL4030 SIH interrupt status registers (ISRs) for
+ * the specified TWL module are cleared by reads, or 0 if cleared by
+ * writes.
+ */
+static int twl4030_read_cor_bit(u8 mod_no, u8 reg)
+{
+ u8 tmp = 0;
+
+ WARN_ON(twl4030_i2c_read_u8(mod_no, tmp, reg) 0);
+
+ tmp = TWL4030_SIH_CTRL_COR_MASK;
+ tmp = __ffs(TWL4030_SIH_CTRL_COR_MASK);
+
+ return tmp;
+}
+
static void twl_init_irq(void)
{
int i = 0;
int res = 0;
+ int cor;
char*msg = Unable to register interrupt subsystem;
unsigned int irq_num;
+ /*
+* For each TWL4030 module with ISR/IMR registers, mask all
+* interrupts and then clear any existing interrupt status bits,
+* since we initially do not have any TWL4030 module interrupt
+* handlers present.
+*/
+
+
/* PWR_IMR1 */
res = twl4030_i2c_write_u8(TWL4030_MODULE_INT, 0xFF, 0x1);
if (res 0) {
@@ -734,20 +792,18 @@ static void twl_init_irq(void)
}
/* Clear off any other pending interrupts on power */
+
+ /* Are PWR interrupt status bits cleared by reads or writes? */
+ cor = twl4030_read_cor_bit(TWL4030_MODULE_INT,
+ TWL4030_INT_PWR_SIH_CTRL);
+ WARN_ON(cor 0);
+
/* PWR_ISR1 */
- res = twl4030_i2c_write_u8(TWL4030_MODULE_INT, 0xFF, 0x00);
- if (res 0) {
- pr_err(%s[%d][%d]\n, msg, res, __LINE__);
- return;
- }
+ WARN_ON(twl4030_i2c_clear_isr(TWL4030_MODULE_INT, 0x00, cor) 0);
/* PWR_ISR2 */
- res = twl4030_i2c_write_u8(TWL4030_MODULE_INT, 0xFF, 0x02);
- if (res 0) {
- pr_err(%s[%d][%d]\n, msg, res, __LINE__);
- return;
- }
- /* POWER HACK (END) */
+ WARN_ON(twl4030_i2c_clear_isr(TWL4030_MODULE_INT, 0x02, cor) 0);
+
/* Slave address 0x4A */
/* BCIIMR1A */
@@ -778,33 +834,22 @@ static void twl_init_irq(void)
return;
}
+ /* Are BCI interrupt status bits cleared by reads or writes? */
+ cor = twl4030_read_cor_bit(TWL4030_MODULE_INTERRUPTS,
+ TWL4030_INTERRUPTS_BCISIHCTRL);
+ WARN_ON(cor 0);
+
/* BCIISR1A */
- res = twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xFF, 0x0);
- if (res 0) {
- pr_err(%s[%d][%d]\n,
[PATCH 6/9] TWL4030: change init-time IMR mask code to WARN if error
twl_init_irq() prints error messages and returns if any interrupt mask
register writes fail. Change this to generate a warning traceback and
to continue execution rather than skipping TWL init. (These mask
writes should not fail at all unless either the I2C bus or the TWL4030
is somehow wedged.)
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
---
drivers/i2c/chips/twl4030-core.c | 100 +++---
1 files changed, 18 insertions(+), 82 deletions(-)
diff --git a/drivers/i2c/chips/twl4030-core.c b/drivers/i2c/chips/twl4030-core.c
index eae0634..99cc143 100644
--- a/drivers/i2c/chips/twl4030-core.c
+++ b/drivers/i2c/chips/twl4030-core.c
@@ -778,18 +778,10 @@ static void twl_init_irq(void)
/* PWR_IMR1 */
- res = twl4030_i2c_write_u8(TWL4030_MODULE_INT, 0xFF, 0x1);
- if (res 0) {
- pr_err(%s[%d][%d]\n, msg, res, __LINE__);
- return;
- }
+ WARN_ON(twl4030_i2c_write_u8(TWL4030_MODULE_INT, 0xff, 0x1) 0);
/* PWR_IMR2 */
- res = twl4030_i2c_write_u8(TWL4030_MODULE_INT, 0xFF, 0x3);
- if (res 0) {
- pr_err(%s[%d][%d]\n, msg, res, __LINE__);
- return;
- }
+ WARN_ON(twl4030_i2c_write_u8(TWL4030_MODULE_INT, 0xff, 0x3) 0);
/* Clear off any other pending interrupts on power */
@@ -807,32 +799,16 @@ static void twl_init_irq(void)
/* Slave address 0x4A */
/* BCIIMR1A */
- res = twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xFF, 0x2);
- if (res 0) {
- pr_err(%s[%d][%d]\n, msg, res, __LINE__);
- return;
- }
+ WARN_ON(twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xff, 0x2) 0);
- /* BCIIMR2A */
- res = twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xFF, 0x3);
- if (res 0) {
- pr_err(%s[%d][%d]\n, msg, res, __LINE__);
- return;
- }
+ /* BCIIMR2A */
+ WARN_ON(twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xff, 0x3) 0);
- /* BCIIMR1B */
- res = twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xFF, 0x6);
- if (res 0) {
- pr_err(%s[%d][%d]\n, msg, res, __LINE__);
- return;
- }
+ /* BCIIMR2A */
+ WARN_ON(twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xff, 0x6) 0);
/* BCIIMR2B */
- res = twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xFF, 0x7);
- if (res 0) {
- pr_err(%s[%d][%d]\n, msg, res, __LINE__);
- return;
- }
+ WARN_ON(twl4030_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xff, 0x7) 0);
/* Are BCI interrupt status bits cleared by reads or writes? */
cor = twl4030_read_cor_bit(TWL4030_MODULE_INTERRUPTS,
@@ -853,18 +829,10 @@ static void twl_init_irq(void)
/* MAD C */
/* MADC_IMR1 */
- res = twl4030_i2c_write_u8(TWL4030_MODULE_MADC, 0xFF, 0x62);
- if (res 0) {
- pr_err(%s[%d][%d]\n, msg, res, __LINE__);
- return;
- }
+ WARN_ON(twl4030_i2c_write_u8(TWL4030_MODULE_MADC, 0xff, 0x62) 0);
/* MADC_IMR2 */
- res = twl4030_i2c_write_u8(TWL4030_MODULE_MADC, 0xFF, 0x64);
- if (res 0) {
- pr_err(%s[%d][%d]\n, msg, res, __LINE__);
- return;
- }
+ WARN_ON(twl4030_i2c_write_u8(TWL4030_MODULE_MADC, 0xff, 0x64) 0);
/* Are MADC interrupt status bits cleared by reads or writes? */
cor = twl4030_read_cor_bit(TWL4030_MODULE_MADC,
@@ -879,11 +847,7 @@ static void twl_init_irq(void)
/* key Pad */
/* KEYPAD - IMR1 */
- res = twl4030_i2c_write_u8(TWL4030_MODULE_KEYPAD, 0xFF, (0x12));
- if (res 0) {
- pr_err(%s[%d][%d]\n, msg, res, __LINE__);
- return;
- }
+ WARN_ON(twl4030_i2c_write_u8(TWL4030_MODULE_KEYPAD, 0xff, 0x12) 0);
/* Are keypad interrupt status bits cleared by reads or writes? */
cor = twl4030_read_cor_bit(TWL4030_MODULE_KEYPAD,
@@ -895,57 +859,29 @@ static void twl_init_irq(void)
WARN_ON(twl4030_i2c_clear_isr(TWL4030_MODULE_KEYPAD, 0x11, cor) 0);
/* KEYPAD - IMR2 */
- res = twl4030_i2c_write_u8(TWL4030_MODULE_KEYPAD, 0xFF, (0x14));
- if (res 0) {
- pr_err(%s[%d][%d]\n, msg, res, __LINE__);
- return;
- }
+ WARN_ON(twl4030_i2c_write_u8(TWL4030_MODULE_KEYPAD, 0xff, 0x14) 0);
/* KEYPAD - ISR2 */
WARN_ON(twl4030_i2c_clear_isr(TWL4030_MODULE_KEYPAD, 0x13, cor) 0);
/* Slave address 0x49 */
/* GPIO_IMR1A */
- res = twl4030_i2c_write_u8(TWL4030_MODULE_GPIO, 0xFF, (0x1C));
- if (res 0) {
- pr_err(%s[%d][%d]\n, msg, res, __LINE__);
- return;
- }
+ WARN_ON(twl4030_i2c_write_u8(TWL4030_MODULE_GPIO, 0xff, 0x1c) 0);
/* GPIO_IMR2A */
- res =
