[PATCH] ARM: OMAP3: Make I2C bus 2 configurable for BeagleBoard
I2C2 at BeagleBoard is connected to expansion connector, i.e. unused
if nothing is connected to this connector. As internal OMAP3 pull up
resistors are not strong enough, enabled but unused I2C2 bus results
in error messages (e.g. I2C timeouts). I2C2 should be enabled only if
something is connected to I2C2 at board's expansion connector and this
extension has additional pull up resistors for I2C2 bus.
- Add configuration option for this
- Use configuration option in board-omap3beagle
- Ensure correct pin mux if I2C2 is enabled, independent of settings
done by bootloader
- While being there, add OMAP3 to OMAP I2C help text
Signed-off-by: Dirk Behme [EMAIL PROTECTED]
Subject: ARM: OMAP3: Make I2C bus 2 configurable for BeagleBoard
From: Dirk Behme [EMAIL PROTECTED]
I2C2 at BeagleBoard is connected to expansion connector, i.e. unused if
nothing is connected to this connector. As internal OMAP3 pull up resistors
are not strong enough, enabled but unused I2C2 bus results in error messages
(e.g. I2C timeouts). I2C2 should be enabled only if something is connected to
I2C2 at board's expansion connector and this extension has additional pull up
resistors for I2C2 bus.
- Add configuration option for this
- Use configuration option in board-omap3beagle
- Ensure correct pin mux if I2C2 is enabled, independent of settings done
by bootloader.
- While being there, add OMAP3 to OMAP I2C help text
Signed-off-by: Dirk Behme [EMAIL PROTECTED]
---
Index: linux-beagle/arch/arm/mach-omap2/board-omap3beagle.c
===
--- linux-beagle.orig/arch/arm/mach-omap2/board-omap3beagle.c
+++ linux-beagle/arch/arm/mach-omap2/board-omap3beagle.c
@@ -40,7 +40,9 @@ static struct omap_uart_config omap3_bea
static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, NULL, 0);
+#ifdef CONFIG_I2C2_OMAP_BEAGLE
omap_register_i2c_bus(2, 400, NULL, 0);
+#endif
omap_register_i2c_bus(3, 400, NULL, 0);
return 0;
}
Index: linux-beagle/arch/arm/mach-omap2/mux.c
===
--- linux-beagle.orig/arch/arm/mach-omap2/mux.c
+++ linux-beagle/arch/arm/mach-omap2/mux.c
@@ -231,10 +231,12 @@ MUX_CFG_34XX(K21_34XX_I2C1_SCL, 0x1ba,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX(J21_34XX_I2C1_SDA, 0x1bc,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+#ifdef CONFIG_I2C2_OMAP_BEAGLE
MUX_CFG_34XX(AF15_34XX_I2C2_SCL, 0x1be,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX(AE15_34XX_I2C2_SDA, 0x1c0,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+#endif
MUX_CFG_34XX(AF14_34XX_I2C3_SCL, 0x1c2,
OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX(AG14_34XX_I2C3_SDA, 0x1c4,
Index: linux-beagle/drivers/i2c/busses/Kconfig
===
--- linux-beagle.orig/drivers/i2c/busses/Kconfig
+++ linux-beagle/drivers/i2c/busses/Kconfig
@@ -332,10 +332,27 @@ config I2C_OMAP
default y if MACH_OMAP_H3 || MACH_OMAP_OSK
help
If you say yes to this option, support will be included for the
- I2C interface on the Texas Instruments OMAP1/2 family of processors.
- Like OMAP1510/1610/1710/5912 and OMAP242x.
+ I2C interface on the Texas Instruments OMAP1/2/3 family of
+ processors.
+ Like OMAP1510/1610/1710/5912, OMAP242x, OMAP34x and OMAP35x.
For details see http://www.ti.com/omap.
+config I2C2_OMAP_BEAGLE
+ bool Enable I2C2 for OMAP3 BeagleBoard
+ depends on ARCH_OMAP MACH_OMAP3_BEAGLE
+ select OMAP_MUX
+ default n
+ help
+ Say Y here if you want to enable I2C bus 2 at OMAP3 based
+ BeagleBoard.
+ I2C2 at BeagleBoard is connected to expansion connector, i.e. unused
+ if nothing is connected to this connector. As internal OMAP3 pull up
+ resistors are not strong enough, enabled but unused I2C2 bus results
+ in error messages (e.g. I2C timeouts). Enable this only if you have
+ something connected to I2C2 at board's expansion connector and this
+ extension has additional pull up resistors for I2C2 bus.
+
+
config I2C_PARPORT
tristate Parallel port adapter
depends on PARPORT
Re: [PATCH] ARM: OMAP3: Make I2C bus 2 configurable for BeagleBoard
On Fri, 04 Jul 2008 08:26:55 +0200 ext Dirk Behme [EMAIL PROTECTED] wrote: - Add configuration option for this - Use configuration option in board-omap3beagle - Ensure correct pin mux if I2C2 is enabled, independent of settings done by bootloader Why this CONFIG_I2C2_OMAP_BEAGLE in mux.c? Jarkko --- linux-beagle.orig/arch/arm/mach-omap2/mux.c +++ linux-beagle/arch/arm/mach-omap2/mux.c @@ -231,10 +231,12 @@ MUX_CFG_34XX(K21_34XX_I2C1_SCL, 0x1ba, OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP) MUX_CFG_34XX(J21_34XX_I2C1_SDA, 0x1bc, OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP) +#ifdef CONFIG_I2C2_OMAP_BEAGLE MUX_CFG_34XX(AF15_34XX_I2C2_SCL, 0x1be, OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP) MUX_CFG_34XX(AE15_34XX_I2C2_SDA, 0x1c0, OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP) +#endif MUX_CFG_34XX(AF14_34XX_I2C3_SCL, 0x1c2, OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP) MUX_CFG_34XX(AG14_34XX_I2C3_SDA, 0x1c4, -- 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: [PATCH] ARM: OMAP3: Make I2C bus 2 configurable for BeagleBoard
Jarkko Nikula wrote: On Fri, 04 Jul 2008 08:26:55 +0200 ext Dirk Behme [EMAIL PROTECTED] wrote: - Add configuration option for this - Use configuration option in board-omap3beagle - Ensure correct pin mux if I2C2 is enabled, independent of settings done by bootloader Why this CONFIG_I2C2_OMAP_BEAGLE in mux.c? Because bootloader, e.g. uboot, might have set other mux for these pins, e.g. GPIO168 and GPIO183. Then, if CONFIG_MUX is enabled but I2C2 isn't, don't touch the pin mux done by bootloader. But if I2C2 is enabled, make sure that the correct mux settings are done independent of bootloader. Do you think this is wrong? Thanks Dirk --- linux-beagle.orig/arch/arm/mach-omap2/mux.c +++ linux-beagle/arch/arm/mach-omap2/mux.c @@ -231,10 +231,12 @@ MUX_CFG_34XX(K21_34XX_I2C1_SCL, 0x1ba, OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP) MUX_CFG_34XX(J21_34XX_I2C1_SDA, 0x1bc, OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP) +#ifdef CONFIG_I2C2_OMAP_BEAGLE MUX_CFG_34XX(AF15_34XX_I2C2_SCL, 0x1be, OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP) MUX_CFG_34XX(AE15_34XX_I2C2_SDA, 0x1c0, OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP) +#endif MUX_CFG_34XX(AF14_34XX_I2C3_SCL, 0x1c2, OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP) MUX_CFG_34XX(AG14_34XX_I2C3_SDA, 0x1c4, -- 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: [PATCH 00/11] OMAP3 CPUidle patches
Hi Rajendra, ext Rajendra Nayak [EMAIL PROTECTED] writes: -Original Message- From: Peter 'p2' De Schrijver [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2008 9:13 PM To: ext Rajendra Nayak Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Hi Rajendra, Not sure, but you can try with my .config while I try with yours. I was doing some more testing today, and I saw a hang after a while of idle activity with OFF being attempted multiple times. Using lauterbach showed me it being stuck up in prcm_interrupt_handler trying to clear MPU_IRQSTATUS. Looks like in the PRCM interrupt handler somehow PM_WKST1_CORE is not cleared (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. Ok. I disabled OneNAND support and now I get off mode on VDD2 as well. Consumption on VDD1 is 4uA and 32uA on VDD2. Unfortunately after the first wakeup, off mode is never reached again. Do you see a hang? or OFF is never achieved? Can you try with the latest fixes that I posted. As it seems to be hard to get similiar results with these patches, could you please send me your uImage? Cheers, Peter. -- 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 -- Jouni Högander -- 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 v2] ARM: OMAP3: Make I2C bus 2 configurable for BeagleBoard
I2C2 at BeagleBoard is connected to expansion connector, i.e. unused
if nothing is connected to this connector. As internal OMAP3 pull up
resistors are not strong enough, enabled but unused I2C2 bus results
in error messages (e.g. I2C timeouts). I2C2 should be enabled only if
something is connected to I2C2 at board's expansion connector and this
extension has additional pull up resistors for I2C2 bus.
- Add configuration option for this
- Use configuration option in board-omap3beagle
- While being there, add OMAP3 to OMAP I2C help text
Signed-off-by: Dirk Behme [EMAIL PROTECTED]
Subject: ARM: OMAP3: Make I2C bus 2 configurable for BeagleBoard
From: Dirk Behme [EMAIL PROTECTED]
I2C2 at BeagleBoard is connected to expansion connector, i.e. unused if
nothing is connected to this connector. As internal OMAP3 pull up resistors
are not strong enough, enabled but unused I2C2 bus results in error messages
(e.g. I2C timeouts). I2C2 should be enabled only if something is connected to
I2C2 at board's expansion connector and this extension has additional pull up
resistors for I2C2 bus.
- Add configuration option for this
- Use configuration option in board-omap3beagle
- While being there, add OMAP3 to OMAP I2C help text
Signed-off-by: Dirk Behme [EMAIL PROTECTED]
---
Changes in v2: Incorporate Jarkko's comments. Pin mux is already done
depending on enabled busses in omap_i2c_mux_pins(int bus).
We don't have to do it manually here. Thanks!
Index: linux-beagle/arch/arm/mach-omap2/board-omap3beagle.c
===
--- linux-beagle.orig/arch/arm/mach-omap2/board-omap3beagle.c
+++ linux-beagle/arch/arm/mach-omap2/board-omap3beagle.c
@@ -40,7 +40,9 @@ static struct omap_uart_config omap3_bea
static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, NULL, 0);
+#ifdef CONFIG_I2C2_OMAP_BEAGLE
omap_register_i2c_bus(2, 400, NULL, 0);
+#endif
omap_register_i2c_bus(3, 400, NULL, 0);
return 0;
}
Index: linux-beagle/drivers/i2c/busses/Kconfig
===
--- linux-beagle.orig/drivers/i2c/busses/Kconfig
+++ linux-beagle/drivers/i2c/busses/Kconfig
@@ -332,10 +332,27 @@ config I2C_OMAP
default y if MACH_OMAP_H3 || MACH_OMAP_OSK
help
If you say yes to this option, support will be included for the
- I2C interface on the Texas Instruments OMAP1/2 family of processors.
- Like OMAP1510/1610/1710/5912 and OMAP242x.
+ I2C interface on the Texas Instruments OMAP1/2/3 family of
+ processors.
+ Like OMAP1510/1610/1710/5912, OMAP242x, OMAP34x and OMAP35x.
For details see http://www.ti.com/omap.
+config I2C2_OMAP_BEAGLE
+ bool Enable I2C2 for OMAP3 BeagleBoard
+ depends on ARCH_OMAP MACH_OMAP3_BEAGLE
+ select OMAP_MUX
+ default n
+ help
+ Say Y here if you want to enable I2C bus 2 at OMAP3 based
+ BeagleBoard.
+ I2C2 at BeagleBoard is connected to expansion connector, i.e. unused
+ if nothing is connected to this connector. As internal OMAP3 pull up
+ resistors are not strong enough, enabled but unused I2C2 bus results
+ in error messages (e.g. I2C timeouts). Enable this only if you have
+ something connected to I2C2 at board's expansion connector and this
+ extension has additional pull up resistors for I2C2 bus.
+
+
config I2C_PARPORT
tristate Parallel port adapter
depends on PARPORT
RE: [PATCH 3/3] CPU-idle trial fix + PM debug expansion
Hi,
Quick counter comments here. :P
This will leave cx-core_state to its previous value in case
of ON state. So just pwrdm_set_next_pwrst(core_pd,
cx-core_state) without if is better.
I did not really consider the logic of cpu-idle code too much, just moved
context / save functionality to omap_sram_idle. I just made suspend + dynamic
idle work.
+save_core = (pwrdm_read_next_pwrst(core_pwrdm) ==
PWRDM_POWER_OFF);
+save_per = (pwrdm_read_next_pwrst(per_pwrdm) ==
PWRDM_POWER_OFF);
Just read next states here.
I am comparing the values to PWRDM_POWER_OFF, because you will only need to
save context if you enter OFF state.
+
+if (save_core) {
+omap3_save_core_ctx();
+omap3_save_prcm_ctx();
+}
And do this if core next_st PWRDM_POWER_ON
Save is not needed if you enter PWRDM_POWER_RET.
+
+if (save_per)
+omap3_save_per_ctx();
And same here. Additionally, do this only if core next_st
PWRDM_POWER_ON.
Per domain can in theory go to OFF even if core stays on (yes, there is some
discussion about tying Core + Per because of the gpio dependencies, but we
might find something else for this.)
-omap3_save_per_ctx();
omap2_gpio_prepare_for_retention();
/* XXX This is for gpio fclk hack. Will be removed as
gpio driver
* handqles fcks correctly */
per_gpio_clk_disable();
-omap_save_uart_ctx();
+if (save_per)
+omap_save_uart_ctx();
Again, do this only if core next_st PWRDM_POWER_ON and per
next_st == PWRDM_POWER_OFF.
Same here.
+
omap_serial_enable_clocks(0);
Consider Rajendras idea to do this only if needed.
I think the idea was to access uart clocks only if we can assume that per_pwrdm
will enter ret / off? Yes good idea.
/* XXX This is for gpio fclk hack. Will be removed as
gpio driver
* handles fcks correctly */
per_gpio_clk_enable();
-omap3_restore_per_ctx();
+
+if (save_per)
+omap3_restore_per_ctx();
omap2_gpio_resume_after_retention();
Same comments to restore part as before wfi. I think you
should look at what Rajendra has done (logic in
omap3_enter_idle). You might also want to look at previous
discussion related to this. Something like this:
I have looked at this code, and I somehow consider it a bit too complicated for
the purpose. The simpler setup I have implemented in omap_sram_idle is working,
also all powerdomains have their next states set-up correctly when you reach
omap_sram_idle. Anyway, it is easy to expand the code now that it actually
works.
neon_pwrdm\n);
+if (mpu_pwrdm == NULL || neon_pwrdm == NULL ||
per_pwrdm == NULL ||
+core_pwrdm == NULL) {
+printk(KERN_ERR Failed to get pwrdm pointers\n);
Neon handling is missing.
Neon pwrdm is accessed only in the init code to make wakeup dependency from mpu
- neon. I have not tried out neon save / restore so far (just some vfp hack is
needed.)
-Tero
--
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: [PATCH 00/11] OMAP3 CPUidle patches
Let's continue this discussion in here to make sure that everybody sees it. ext Högander Jouni [EMAIL PROTECTED] writes: Hi Rajendra, ext Rajendra Nayak [EMAIL PROTECTED] writes: -Original Message- From: Peter 'p2' De Schrijver [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2008 9:13 PM To: ext Rajendra Nayak Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Hi Rajendra, Not sure, but you can try with my .config while I try with yours. I was doing some more testing today, and I saw a hang after a while of idle activity with OFF being attempted multiple times. Using lauterbach showed me it being stuck up in prcm_interrupt_handler trying to clear MPU_IRQSTATUS. Looks like in the PRCM interrupt handler somehow PM_WKST1_CORE is not cleared (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. Ok. I disabled OneNAND support and now I get off mode on VDD2 as well. Consumption on VDD1 is 4uA and 32uA on VDD2. Unfortunately after the first wakeup, off mode is never reached again. Do you see a hang? or OFF is never achieved? Can you try with the latest fixes that I posted. As it seems to be hard to get similiar results with these patches, could you please send me your uImage? So Rajendra sent his uImage and it works quite ok what comes to off mode on my sdp board. I still see problems with serial console (slow) and on boot I need to generate manually interrupts to get it to boot. Otherwise board hangs at this point: eth0: link up Sending DHCP requests ., OK IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 IP-Config: Complete: device=eth0, addr=192.168.2.101, mask=255.255.255.0, gw=192.168.2.1, host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= Looking up port of RPC 13/2 on 172.22.146.197 Looking up port of RPC 15/1 on 172.22.146.197 VFS: Mounted root (nfs filesystem). Freeing init memory: 108K Rajendra, are you still using .config file you sent to me? Are all the changes in your tree available in l-o list. Cheers, Peter. -- 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 -- Jouni Högander -- 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 -- Jouni Högander -- 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] input: keypad: General fixes to omap-twl4030keypad.c
The following patch fixes some problems in T2 keypad
driver.
Basically we're passing irq number via platform_data,
moving globals to a structure and fixing a problem
while iterating over the keymap.
Some cleanups are also done so checkpatch.pl doesn't
complain about this driver anymore.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
Signed-off-by: Timo Kokkonen [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-2430sdp.c |5 +-
arch/arm/mach-omap2/board-3430sdp.c |5 +-
drivers/input/keyboard/omap-twl4030keypad.c | 206 ---
include/asm-arm/arch-omap/keypad.h |1 +
4 files changed, 130 insertions(+), 87 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 780913e..b54a7f0 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -176,9 +176,10 @@ static int sdp2430_keymap[] = {
static struct omap_kp_platform_data sdp2430_kp_data = {
.rows = 5,
.cols = 6,
- .keymap = sdp2430_keymap,
- .keymapsize = ARRAY_SIZE(sdp2430_keymap),
+ .keymap = sdp2430_keymap,
+ .keymapsize = ARRAY_SIZE(sdp2430_keymap),
.rep= 1,
+ .irq= TWL4030_MODIRQ_KEYPAD,
};
static struct platform_device sdp2430_kp_device = {
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 7a216cc..beefae8 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -107,9 +107,10 @@ static int sdp3430_keymap[] = {
static struct omap_kp_platform_data sdp3430_kp_data = {
.rows = 5,
.cols = 6,
- .keymap = sdp3430_keymap,
- .keymapsize = ARRAY_SIZE(sdp3430_keymap),
+ .keymap = sdp3430_keymap,
+ .keymapsize = ARRAY_SIZE(sdp3430_keymap),
.rep= 1,
+ .irq= TWL4030_MODIRQ_KEYPAD,
};
static struct platform_device sdp3430_kp_device = {
diff --git a/drivers/input/keyboard/omap-twl4030keypad.c
b/drivers/input/keyboard/omap-twl4030keypad.c
index 20aeb3c..e27d2c3 100644
--- a/drivers/input/keyboard/omap-twl4030keypad.c
+++ b/drivers/input/keyboard/omap-twl4030keypad.c
@@ -31,6 +31,7 @@
#include linux/types.h
#include linux/input.h
#include linux/kernel.h
+#include linux/mutex.h
#include linux/delay.h
#include linux/bitops.h
#include linux/platform_device.h
@@ -47,52 +48,65 @@
#define KEYNUM_MASK0x00FF
/* Global variables */
-static int *keymap;
-static u16 kp_state[MAX_ROWS];
-static int n_rows, n_cols;
-static struct device *dbg_dev;
-static struct input_dev *omap_twl4030kp;
+struct omap_keypad {
+ int *keymap;
+ unsigned intkeymapsize;
+ u16 kp_state[MAX_ROWS];
+ int n_rows;
+ int n_cols;
+ int irq;
-static int twl4030_kpread(u32 module, u8 *data, u32 reg, u8 num_bytes)
+ struct device *dbg_dev;
+ struct input_dev *omap_twl4030kp;
+
+ /* sync read/write */
+ struct mutexmutex;
+};
+
+static int twl4030_kpread(struct omap_keypad *kp,
+ u32 module, u8 *data, u32 reg, u8 num_bytes)
{
int ret;
ret = twl4030_i2c_read(module, data, reg, num_bytes);
if (ret 0) {
- dev_warn(dbg_dev, Couldn't read TWL4030: %X - ret %d[%x]\n,
+ dev_warn(kp-dbg_dev,
+ Couldn't read TWL4030: %X - ret %d[%x]\n,
reg, ret, ret);
return ret;
}
return ret;
}
-static int twl4030_kpwrite_u8(u32 module, u8 data, u32 reg)
+static int twl4030_kpwrite_u8(struct omap_keypad *kp,
+ u32 module, u8 data, u32 reg)
{
int ret;
ret = twl4030_i2c_write_u8(module, data, reg);
if (ret 0) {
- dev_warn(dbg_dev, Could not write TWL4030: %X - ret %d[%x]\n,
+ dev_warn(kp-dbg_dev,
+ Could not write TWL4030: %X - ret %d[%x]\n,
reg, ret, ret);
return ret;
}
return ret;
}
-static int omap_kp_find_key(int col, int row)
+static int omap_kp_find_key(struct omap_keypad *kp, int col, int row)
{
int i, rc;
rc = KEY(col, row, 0);
- for (i = 0; keymap[i] != 0; i++)
- if ((keymap[i] ROWCOL_MASK) == rc)
- return keymap[i] KEYNUM_MASK;
+ for (i = 0; i kp-keymapsize; i++)
+ if ((kp-keymap[i] ROWCOL_MASK) == rc)
+ return kp-keymap[i] KEYNUM_MASK;
return -EINVAL;
}
-static inline u16 omap_kp_col_xlate(u8 col)
+static inline u16 omap_kp_col_xlate(struct omap_keypad *kp, u8 col)
{
/* If all bits in a row are active for all coloumns then
* we have that row line connected to gnd.
RE: [PATCH 00/11] OMAP3 CPUidle patches
-Original Message- From: Högander Jouni [mailto:[EMAIL PROTECTED] Sent: Friday, July 04, 2008 3:02 PM To: ext Rajendra Nayak Cc: 'Peter 'p2' De Schrijver'; linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Let's continue this discussion in here to make sure that everybody sees it. ext Högander Jouni [EMAIL PROTECTED] writes: Hi Rajendra, ext Rajendra Nayak [EMAIL PROTECTED] writes: -Original Message- From: Peter 'p2' De Schrijver [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2008 9:13 PM To: ext Rajendra Nayak Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Hi Rajendra, Not sure, but you can try with my .config while I try with yours. I was doing some more testing today, and I saw a hang after a while of idle activity with OFF being attempted multiple times. Using lauterbach showed me it being stuck up in prcm_interrupt_handler trying to clear MPU_IRQSTATUS. Looks like in the PRCM interrupt handler somehow PM_WKST1_CORE is not cleared (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. Ok. I disabled OneNAND support and now I get off mode on VDD2 as well. Consumption on VDD1 is 4uA and 32uA on VDD2. Unfortunately after the first wakeup, off mode is never reached again. Do you see a hang? or OFF is never achieved? Can you try with the latest fixes that I posted. As it seems to be hard to get similiar results with these patches, could you please send me your uImage? So Rajendra sent his uImage and it works quite ok what comes to off mode on my sdp board. I still see problems with serial console (slow) and on boot I need to generate manually interrupts to get it to boot. Otherwise board hangs at this point: Yes, I noticed this as well. It takes quite long to bootup if you don't generate UART interrupts. After bootup once RET/OFF is hit, it takes a few hits to come out of it as IO wakeup is missing. eth0: link up Sending DHCP requests ., OK IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 IP-Config: Complete: device=eth0, addr=192.168.2.101, mask=255.255.255.0, gw=192.168.2.1, host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= Looking up port of RPC 13/2 on 172.22.146.197 Looking up port of RPC 15/1 on 172.22.146.197 VFS: Mounted root (nfs filesystem). Freeing init memory: 108K Rajendra, are you still using .config file you sent to me? Are all the changes in your tree available in l-o list. Yes, all the changes are part of the 11 patch set + 1 rework fixes patch I sent. To debug further, can you put a few prints in omap3_enter_idle and omap3_enter_idle_bm to see what states are selected by the menu gov. We will then know if CORE RET/OFF is attempted but not achieved due to some reason, or never attempted altogether. Cheers, Peter. -- 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 -- Jouni Högander -- 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 -- Jouni Högander -- 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: [PATCH 00/11] OMAP3 CPUidle patches
ext Rajendra Nayak [EMAIL PROTECTED] writes: -Original Message- From: Högander Jouni [mailto:[EMAIL PROTECTED] Sent: Friday, July 04, 2008 3:02 PM To: ext Rajendra Nayak Cc: 'Peter 'p2' De Schrijver'; linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Let's continue this discussion in here to make sure that everybody sees it. ext Högander Jouni [EMAIL PROTECTED] writes: Hi Rajendra, ext Rajendra Nayak [EMAIL PROTECTED] writes: -Original Message- From: Peter 'p2' De Schrijver [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2008 9:13 PM To: ext Rajendra Nayak Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Hi Rajendra, Not sure, but you can try with my .config while I try with yours. I was doing some more testing today, and I saw a hang after a while of idle activity with OFF being attempted multiple times. Using lauterbach showed me it being stuck up in prcm_interrupt_handler trying to clear MPU_IRQSTATUS. Looks like in the PRCM interrupt handler somehow PM_WKST1_CORE is not cleared (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. Ok. I disabled OneNAND support and now I get off mode on VDD2 as well. Consumption on VDD1 is 4uA and 32uA on VDD2. Unfortunately after the first wakeup, off mode is never reached again. Do you see a hang? or OFF is never achieved? Can you try with the latest fixes that I posted. As it seems to be hard to get similiar results with these patches, could you please send me your uImage? So Rajendra sent his uImage and it works quite ok what comes to off mode on my sdp board. I still see problems with serial console (slow) and on boot I need to generate manually interrupts to get it to boot. Otherwise board hangs at this point: Yes, I noticed this as well. It takes quite long to bootup if you don't generate UART interrupts. After bootup once RET/OFF is hit, it takes a few hits to come out of it as IO wakeup is missing. Can you try to disable C2 state. I noticed that this state is used all the time at the point on boot where board hangs. I tried to disable and after this boot worked ok. With my image I couldn't achieve off state. eth0: link up Sending DHCP requests ., OK IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 IP-Config: Complete: device=eth0, addr=192.168.2.101, mask=255.255.255.0, gw=192.168.2.1, host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= Looking up port of RPC 13/2 on 172.22.146.197 Looking up port of RPC 15/1 on 172.22.146.197 VFS: Mounted root (nfs filesystem). Freeing init memory: 108K Rajendra, are you still using .config file you sent to me? Are all the changes in your tree available in l-o list. Yes, all the changes are part of the 11 patch set + 1 rework fixes patch I sent. To debug further, can you put a few prints in omap3_enter_idle and omap3_enter_idle_bm to see what states are selected by the menu gov. We will then know if CORE RET/OFF is attempted but not achieved due to some reason, or never attempted altogether. Ok, will send my results soon. -- Jouni Högander -- 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: [PATCH 00/11] OMAP3 CPUidle patches
So Rajendra sent his uImage and it works quite ok what comes to off mode on my sdp board. I still see problems with serial console (slow) and on boot I need to generate manually interrupts to get it to boot. Otherwise board hangs at this point: eth0: link up Sending DHCP requests ., OK IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 IP-Config: Complete: device=eth0, addr=192.168.2.101, mask=255.255.255.0, gw=192.168.2.1, host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= Looking up port of RPC 13/2 on 172.22.146.197 Looking up port of RPC 15/1 on 172.22.146.197 VFS: Mounted root (nfs filesystem). Freeing init memory: 108K Rajendra, are you still using .config file you sent to me? Are all the changes in your tree available in l-o list. I tried the same uImage here on my SDP. It goes to off nicely after bootup, but after using the console, VDD2 does not to off anymore. VDD1 does go to off. Cheers, Peter. -- 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: [PATCH 00/11] OMAP3 CPUidle patches
ext Rajendra Nayak [EMAIL PROTECTED] writes: -Original Message- From: Högander Jouni [mailto:[EMAIL PROTECTED] Sent: Friday, July 04, 2008 3:02 PM To: ext Rajendra Nayak Cc: 'Peter 'p2' De Schrijver'; linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Let's continue this discussion in here to make sure that everybody sees it. ext Högander Jouni [EMAIL PROTECTED] writes: Hi Rajendra, ext Rajendra Nayak [EMAIL PROTECTED] writes: -Original Message- From: Peter 'p2' De Schrijver [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2008 9:13 PM To: ext Rajendra Nayak Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Hi Rajendra, Not sure, but you can try with my .config while I try with yours. I was doing some more testing today, and I saw a hang after a while of idle activity with OFF being attempted multiple times. Using lauterbach showed me it being stuck up in prcm_interrupt_handler trying to clear MPU_IRQSTATUS. Looks like in the PRCM interrupt handler somehow PM_WKST1_CORE is not cleared (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. Ok. I disabled OneNAND support and now I get off mode on VDD2 as well. Consumption on VDD1 is 4uA and 32uA on VDD2. Unfortunately after the first wakeup, off mode is never reached again. Do you see a hang? or OFF is never achieved? Can you try with the latest fixes that I posted. As it seems to be hard to get similiar results with these patches, could you please send me your uImage? So Rajendra sent his uImage and it works quite ok what comes to off mode on my sdp board. I still see problems with serial console (slow) and on boot I need to generate manually interrupts to get it to boot. Otherwise board hangs at this point: Yes, I noticed this as well. It takes quite long to bootup if you don't generate UART interrupts. After bootup once RET/OFF is hit, it takes a few hits to come out of it as IO wakeup is missing. eth0: link up Sending DHCP requests ., OK IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 IP-Config: Complete: device=eth0, addr=192.168.2.101, mask=255.255.255.0, gw=192.168.2.1, host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= Looking up port of RPC 13/2 on 172.22.146.197 Looking up port of RPC 15/1 on 172.22.146.197 VFS: Mounted root (nfs filesystem). Freeing init memory: 108K Rajendra, are you still using .config file you sent to me? Are all the changes in your tree available in l-o list. Yes, all the changes are part of the 11 patch set + 1 rework fixes patch I sent. To debug further, can you put a few prints in omap3_enter_idle and omap3_enter_idle_bm to see what states are selected by the menu gov. We will then know if CORE RET/OFF is attempted but not achieved due to some reason, or never attempted altogether. It seems that I get off state also with my own binary: diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 6440515..545ce99 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -447,7 +447,9 @@ static int omap3_enter_idle(struct cpuidle_device *dev, if (cx-type OMAP3_STATE_C1) sched_clock_idle_sleep_event(); /* about to enter deep idle */ - + if (cx-type == OMAP3_STATE_C6) + printk(KERN_ERRTrying OMAP3_STATE_C6\n); + mpu_pd = pwrdm_lookup(mpu_pwrdm); core_pd = pwrdm_lookup(core_pwrdm); per_pd = pwrdm_lookup(per_pwrdm); @@ -521,6 +523,15 @@ static int omap3_enter_idle(struct cpuidle_device *dev, omap2_gpio_resume_after_retention(); } + if (!pwrdm_read_prev_pwrst(mpu_pd)) + printk(mpu off achieved\n); + if (!pwrdm_read_prev_pwrst(core_pd)) + printk(core off achieved\n); + if (!pwrdm_read_prev_pwrst(per_pd)) + printk(per off achieved\n); + if (!pwrdm_read_prev_pwrst(neon_pd)) + printk(neon off achieved\n); + And the output is this: Trying OMAP3_STATE_C6 mpu off achieved core off achieved per off achieved Neon is not printed as it is in off or ret all the time. Basically off state is achieved using Rajendras patches + config. I still see that hang on boot. I have feeling that it is related to other states than C6. I tried to disable all other states than C0 and C6 by setting valid bit to 0. After this boot works ok, but C6 state is never tried. Any idea why? There is still some occasional hangs. Seems to be related to wakeup. Cheers, Peter. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at
Re: [PATCH] input: keypad: General fixes to omap-twl4030keypad.c
On Fri, Jul 04, 2008 at 12:34:21PM +0300, Felipe Balbi wrote: + mutex_lock(kp-lock); This should be mutex, final patch is coming. -- - Balbi -- 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: [RESEND][PATCH]Separate out 3430 LCD panel support from 2430 file
Emailing the fix on behalf of Iqbal: -Original Message- [mailto:[EMAIL PROTECTED] On Behalf Of Gadiyar, Anand Subject: RE: [RESEND][PATCH]Separate out 3430 LCD panel support from 2430 file * [EMAIL PROTECTED] [EMAIL PROTECTED] [080702 15:25]: From: Iqbal Shareef [EMAIL PROTECTED] Separate out 3430 LCD panel support from 2430 SDP. Currently the support for the LCD on 3430SDP is added in the lcd_2430sdp.c file. This patch separates it out to a new file. Pushing today. Tony This one breaks compile on 3430. Will see if I can send a fix. Cut here --- From: Iqbal Shareef [EMAIL PROTECTED] Fix SDP 3430 compile error The PM_RECEIVER macro is replaced with TWL4030_MODULE_PM_RECEIVER Signed-off-by: Iqbal Shareef [EMAIL PROTECTED] --- drivers/video/omap/lcd_3430sdp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/video/omap/lcd_3430sdp.c b/drivers/video/omap/lcd_3430sdp.c index 20ac0e5..6e7a8b6 100644 --- a/drivers/video/omap/lcd_3430sdp.c +++ b/drivers/video/omap/lcd_3430sdp.c @@ -70,7 +70,7 @@ static int sdp3430_panel_enable(struct lcd_panel *panel) if (0 != twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, ENABLE_VAUX3_DEDICATED, TWL4030_VAUX3_DEDICATED)) return -EIO; - if (0 != twl4030_i2c_write_u8(PM_RECEIVER, ENABLE_VAUX3_DEV_GRP, + if (0 != twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, ENABLE_VAUX3_DEV_GRP, TWL4030_VAUX3_DEV_GRP)) return -EIO; -- 1.5.3.2 -- 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] input: keypad: General fixes to omap-twl4030keypad.c
The following patch fixes some problems in T2 keypad
driver.
Basically we're passing irq number via platform_data,
moving globals to a structure and fixing a problem
while iterating over the keymap.
It might be that we still have a few locking issues
that might be solved on a later version of this same
patch.
For now, consider this one RFC.
Comments are welcome.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-2430sdp.c |5 +-
arch/arm/mach-omap2/board-3430sdp.c |5 +-
drivers/input/keyboard/omap-twl4030keypad.c | 206 ---
include/asm-arm/arch-omap/keypad.h |1 +
4 files changed, 130 insertions(+), 87 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 780913e..b54a7f0 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -176,9 +176,10 @@ static int sdp2430_keymap[] = {
static struct omap_kp_platform_data sdp2430_kp_data = {
.rows = 5,
.cols = 6,
- .keymap = sdp2430_keymap,
- .keymapsize = ARRAY_SIZE(sdp2430_keymap),
+ .keymap = sdp2430_keymap,
+ .keymapsize = ARRAY_SIZE(sdp2430_keymap),
.rep= 1,
+ .irq= TWL4030_MODIRQ_KEYPAD,
};
static struct platform_device sdp2430_kp_device = {
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 7a216cc..beefae8 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -107,9 +107,10 @@ static int sdp3430_keymap[] = {
static struct omap_kp_platform_data sdp3430_kp_data = {
.rows = 5,
.cols = 6,
- .keymap = sdp3430_keymap,
- .keymapsize = ARRAY_SIZE(sdp3430_keymap),
+ .keymap = sdp3430_keymap,
+ .keymapsize = ARRAY_SIZE(sdp3430_keymap),
.rep= 1,
+ .irq= TWL4030_MODIRQ_KEYPAD,
};
static struct platform_device sdp3430_kp_device = {
diff --git a/drivers/input/keyboard/omap-twl4030keypad.c
b/drivers/input/keyboard/omap-twl4030keypad.c
index 20aeb3c..c60455e 100644
--- a/drivers/input/keyboard/omap-twl4030keypad.c
+++ b/drivers/input/keyboard/omap-twl4030keypad.c
@@ -31,6 +31,7 @@
#include linux/types.h
#include linux/input.h
#include linux/kernel.h
+#include linux/mutex.h
#include linux/delay.h
#include linux/bitops.h
#include linux/platform_device.h
@@ -47,52 +48,65 @@
#define KEYNUM_MASK0x00FF
/* Global variables */
-static int *keymap;
-static u16 kp_state[MAX_ROWS];
-static int n_rows, n_cols;
-static struct device *dbg_dev;
-static struct input_dev *omap_twl4030kp;
+struct omap_keypad {
+ int *keymap;
+ unsigned intkeymapsize;
+ u16 kp_state[MAX_ROWS];
+ int n_rows;
+ int n_cols;
+ int irq;
-static int twl4030_kpread(u32 module, u8 *data, u32 reg, u8 num_bytes)
+ struct device *dbg_dev;
+ struct input_dev *omap_twl4030kp;
+
+ /* sync read/write */
+ struct mutexmutex;
+};
+
+static int twl4030_kpread(struct omap_keypad *kp,
+ u32 module, u8 *data, u32 reg, u8 num_bytes)
{
int ret;
ret = twl4030_i2c_read(module, data, reg, num_bytes);
if (ret 0) {
- dev_warn(dbg_dev, Couldn't read TWL4030: %X - ret %d[%x]\n,
+ dev_warn(kp-dbg_dev,
+ Couldn't read TWL4030: %X - ret %d[%x]\n,
reg, ret, ret);
return ret;
}
return ret;
}
-static int twl4030_kpwrite_u8(u32 module, u8 data, u32 reg)
+static int twl4030_kpwrite_u8(struct omap_keypad *kp,
+ u32 module, u8 data, u32 reg)
{
int ret;
ret = twl4030_i2c_write_u8(module, data, reg);
if (ret 0) {
- dev_warn(dbg_dev, Could not write TWL4030: %X - ret %d[%x]\n,
+ dev_warn(kp-dbg_dev,
+ Could not write TWL4030: %X - ret %d[%x]\n,
reg, ret, ret);
return ret;
}
return ret;
}
-static int omap_kp_find_key(int col, int row)
+static int omap_kp_find_key(struct omap_keypad *kp, int col, int row)
{
int i, rc;
rc = KEY(col, row, 0);
- for (i = 0; keymap[i] != 0; i++)
- if ((keymap[i] ROWCOL_MASK) == rc)
- return keymap[i] KEYNUM_MASK;
+ for (i = 0; i kp-keymapsize; i++)
+ if ((kp-keymap[i] ROWCOL_MASK) == rc)
+ return kp-keymap[i] KEYNUM_MASK;
return -EINVAL;
}
-static inline u16 omap_kp_col_xlate(u8 col)
+static inline u16 omap_kp_col_xlate(struct omap_keypad *kp, u8 col)
{
/* If all bits in a row are active for all coloumns then
* we have
Re: [PATCH 1/1]smc911x Modify driver to also work with omap24xx
Arun KS wrote: net:smc911x Modify driver to also work with omap24xx Signed-off-by: Arun KS [EMAIL PROTECTED] --- drivers/net/Kconfig |2 +- drivers/net/smc911x.h |5 + 2 files changed, 6 insertions(+), 1 deletions(-) ACK but failed to apply -- 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: [RESEND][PATCH]Separate out 3430 LCD panel support from 2430 file
2008/7/2 [EMAIL PROTECTED]:
From: Iqbal Shareef [EMAIL PROTECTED]
Separate out 3430 LCD panel support from 2430 SDP.
Currently the support for the LCD on 3430SDP is added in the lcd_2430sdp.c
file. This patch separates it out to a new file.
Isn't this a bit step backwards? Code reuse is generally a good thing
if it doesn't clutter the code too much, and if you do diff -pNaur
lcd_2430sdp.c lcd_3430sdp.c in the current tree you will see that they
are very similar.
Additionally this patch leaves some of the 3430SDP code in
lcd_2430sdp.c, you will still find this:
#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO24
#define SDP3430_LCD_PANEL_ENABLE_GPIO 28
...
if (machine_is_omap_3430sdp()) {
enable_gpio= SDP3430_LCD_PANEL_ENABLE_GPIO;
backlight_gpio = SDP3430_LCD_PANEL_BACKLIGHT_GPIO;
} else {
enable_gpio= SDP2430_LCD_PANEL_ENABLE_GPIO;
backlight_gpio = SDP2430_LCD_PANEL_BACKLIGHT_GPIO;
}
...
if (machine_is_omap_3430sdp()) {
ded_reg = TWL4030_VAUX3_DEDICATED;
ded_val = ENABLE_VAUX3_DEDICATED;
grp_reg = TWL4030_VAUX3_DEV_GRP;
grp_val = ENABLE_VAUX3_DEV_GRP;
} else {
ded_reg = TWL4030_VAUX2_DEDICATED;
ded_val = ENABLE_VAUX2_DEDICATED;
grp_reg = TWL4030_VAUX2_DEV_GRP;
grp_val = ENABLE_VAUX2_DEV_GRP;
}
Another thing that isn't explained is why the GPIO numbers for
backlight and enable changed from 24 and 28 to 8 and 5.
Regards,
Andrew
--
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
