RE: Bridge issue #3! dma_alloc_coherent causing crash - pm branch
Kevin, > > > > I enabled all the above options, do I need to add some boot > options to > > enable Debug messages? I am not seeing any debug > information displayed in the cosole by default. > > Looks like I am mising some thing :( . Any comments? > > > > You'll only see extra messages when the kerel hits a BUG() or > a WARN(). If you don't see anything more verbose with all > these options enabled, then the kernel is not detecting any problems. Thank you. Regards Ramesh-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2.6.29-rc8-omap] twl4030 power scripts, initsection fixups
From: David Brownell
Remove section mismatch warnings from twl4030 power script
declaration ... unfortunately, this use-once data can't live
in initdata sections (or initconst) until some driver stacks
(starting with I2C) have better support for non-hotpluggable
componentry.
Signed-off-by: David Brownell
---
arch/arm/mach-omap2/board-3430sdp.c | 16
arch/arm/mach-omap2/board-ldp.c | 16
arch/arm/mach-omap2/twl4030-generic-scripts.c | 12 ++--
3 files changed, 22 insertions(+), 22 deletions(-)
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -394,7 +394,7 @@ static struct twl4030_madc_platform_data
};
-static struct twl4030_ins __initdata sleep_on_seq[] = {
+static struct twl4030_ins sleep_on_seq[] = {
/*
* Turn off VDD1 and VDD2.
*/
@@ -409,13 +409,13 @@ static struct twl4030_ins __initdata sle
#endif
};
-static struct twl4030_script sleep_on_script __initdata = {
+static struct twl4030_script sleep_on_script = {
.script = sleep_on_seq,
.size = ARRAY_SIZE(sleep_on_seq),
.flags = TRITON_SLEEP_SCRIPT,
};
-static struct twl4030_ins wakeup_seq[] __initdata = {
+static struct twl4030_ins wakeup_seq[] = {
#ifndef CONFIG_DISABLE_HFCLK
/*
* Wakeup VDD1 and VDD2.
@@ -435,13 +435,13 @@ static struct twl4030_ins wakeup_seq[] _
#endif /* #ifndef CONFIG_DISABLE_HFCLK */
};
-static struct twl4030_script wakeup_script __initdata = {
+static struct twl4030_script wakeup_script = {
.script = wakeup_seq,
.size = ARRAY_SIZE(wakeup_seq),
.flags = TRITON_WAKEUP12_SCRIPT | TRITON_WAKEUP3_SCRIPT,
};
-static struct twl4030_ins wrst_seq[] __initdata = {
+static struct twl4030_ins wrst_seq[] = {
/*
* Reset twl4030.
* Reset VDD1 regulator.
@@ -457,19 +457,19 @@ static struct twl4030_ins wrst_seq[] __i
{MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
{MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
};
-static struct twl4030_script wrst_script __initdata = {
+static struct twl4030_script wrst_script = {
.script = wrst_seq,
.size = ARRAY_SIZE(wakeup_seq),
.flags = TRITON_WRST_SCRIPT,
};
-static struct twl4030_script *twl4030_scripts[] __initdata = {
+static struct twl4030_script *twl4030_scripts[] = {
&sleep_on_script,
&wakeup_script,
&wrst_script,
};
-static struct twl4030_power_data sdp3430_t2scripts_data __initdata = {
+static struct twl4030_power_data sdp3430_t2scripts_data = {
.scripts= twl4030_scripts,
.size = ARRAY_SIZE(twl4030_scripts),
};
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -374,7 +374,7 @@ static int ldp_batt_table[] = {
4040, 3910, 3790, 3670, 3550
};
-static struct twl4030_ins __initdata sleep_on_seq[] = {
+static struct twl4030_ins sleep_on_seq[] = {
/*
* Turn off VDD1 and VDD2.
*/
@@ -389,13 +389,13 @@ static struct twl4030_ins __initdata sle
#endif
};
-static struct twl4030_script sleep_on_script __initdata = {
+static struct twl4030_script sleep_on_script = {
.script = sleep_on_seq,
.size = ARRAY_SIZE(sleep_on_seq),
.flags = TRITON_SLEEP_SCRIPT,
};
-static struct twl4030_ins wakeup_seq[] __initdata = {
+static struct twl4030_ins wakeup_seq[] = {
#ifndef CONFIG_DISABLE_HFCLK
/*
* Wakeup VDD1 and VDD2.
@@ -415,13 +415,13 @@ static struct twl4030_ins wakeup_seq[] _
#endif /* #ifndef CONFIG_DISABLE_HFCLK */
};
-static struct twl4030_script wakeup_script __initdata = {
+static struct twl4030_script wakeup_script = {
.script = wakeup_seq,
.size = ARRAY_SIZE(wakeup_seq),
.flags = TRITON_WAKEUP12_SCRIPT | TRITON_WAKEUP3_SCRIPT,
};
-static struct twl4030_ins wrst_seq[] __initdata = {
+static struct twl4030_ins wrst_seq[] = {
/*
* Reset twl4030.
* Reset VDD1 regulator.
@@ -438,19 +438,19 @@ static struct twl4030_ins wrst_seq[] __i
{MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
};
-static struct twl4030_script wrst_script __initdata = {
+static struct twl4030_script wrst_script = {
.script = wrst_seq,
.size = ARRAY_SIZE(wakeup_seq),
.flags = TRITON_WRST_SCRIPT,
};
-static struct twl4030_script *twl4030_scripts[] __initdata = {
+static struct twl4030_script *twl4030_scripts[] = {
&sleep_on_script,
&wakeup_script,
&wrst_script,
};
-static struct twl4030_power_data sdp3430_t2scripts_data __initdata = {
+static struct twl4030_power_data sdp3430_t2scripts_data = {
.scripts= twl4030_scripts,
.size = ARRAY_SIZE(twl4030_scripts),
};
--- a/arch/arm/mach-omap2/twl4030-generic-scripts.c
+++ b/arch/arm/mach-omap2/twl4030-generic-scripts.c
@@ -35,14 +35,14 @@
* resources to sleep and then all the other resources.
*/
-static struct twl4030_ins sleep_on_seq[] __initdata = {
[PATCH 1/1] Group and resource assignments for TWL4030 (v3)
From: "Peter 'p2' De Schrijver"
Subject: Group and resource assignments for TWL4030
Introduce support for board specific group assignments of TWL4030
power resources. The resource type and type2 fields can also be
specified.
Most such power resources are regulators; this hook can be used
to ensure regulators that will never be used get properly disabled,
regardless of what the bootloader does. Other resources include
control signals like CLKREQ and REGEN; this can properly couple
TWL CLKREQ (out) to OMAP SYSCLK_REQ (in) so retention mode works.
[ dbrown...@users.sourceforge.net: cosmetic and doc updates;
use the RES_* constants in the regulator driver; fix buildbug ]
Signed-off-by: Peter 'p2' De Schrijver
Signed-off-by: David Brownell
---
Removes the build bug ... and now depends on the VPLL2 patch
that I just posted (sorry).
drivers/mfd/Kconfig | 14 +++-
drivers/mfd/twl4030-power.c | 94
drivers/regulator/twl4030-regulator.c | 40 ++---
include/linux/i2c/twl4030.h | 39 +
4 files changed, 162 insertions(+), 25 deletions(-)
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -107,13 +107,17 @@ config TWL4030_CORE
versions) and many other features.
config TWL4030_POWER
- bool "Support power sequencing scripts on TWL4030/TPS659x0"
+ bool "Support power resources on TWL4030 family chips"
depends on TWL4030_CORE
help
- Say yes here if you want to use the power sequencing scripts on
- the TWL4030/TPS659x0. These scripts control which regulators or
- oscillators are switched off or on or reset when a sleep, wakeup
- or warm reset event occurs.
+ Say yes here if you want to use the power resources on the
+ TWL4030 family chips. Most of these resources are regulators,
+ which have a separate driver; some are control signals, such
+ as clock request handshaking.
+
+ This driver uses board-specific data to initialize the resources
+ and load scripts controling which resources are switched off/on
+ or reset when a sleep, wakeup or warm reset event occurs.
config MFD_TMIO
bool
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -38,6 +38,8 @@ static u8 triton_next_free_address = 0x2
#define PHY_TO_OFF_PM_MASTER(p)(p - 0x36)
#define PHY_TO_OFF_PM_RECEIVER(p) (p - 0x5b)
+#define NUM_OF_RESOURCES 28
+
/* resource - hfclk */
#define R_HFCLKOUT_DEV_GRP PHY_TO_OFF_PM_RECEIVER(0xe6)
@@ -66,6 +68,42 @@ static u8 triton_next_free_address = 0x2
#define KEY_1 0xC0
#define KEY_2 0x0C
+/* resource configuration registers */
+
+#define DEVGROUP_OFFSET0
+#define TYPE_OFFSET1
+
+static u8 res_config_addrs[] = {
+ [RES_VAUX1] = 0x17,
+ [RES_VAUX2] = 0x1b,
+ [RES_VAUX3] = 0x1f,
+ [RES_VAUX4] = 0x23,
+ [RES_VMMC1] = 0x27,
+ [RES_VMMC2] = 0x2b,
+ [RES_VPLL1] = 0x2f,
+ [RES_VPLL2] = 0x33,
+ [RES_VSIM] = 0x37,
+ [RES_VDAC] = 0x3b,
+ [RES_VINTANA1] = 0x3f,
+ [RES_VINTANA2] = 0x43,
+ [RES_VINTDIG] = 0x47,
+ [RES_VIO] = 0x4b,
+ [RES_VDD1] = 0x55,
+ [RES_VDD2] = 0x63,
+ [RES_VUSB_1V5] = 0x71,
+ [RES_VUSB_1V8] = 0x74,
+ [RES_VUSB_3V1] = 0x77,
+ [RES_VUSBCP]= 0x7a,
+ [RES_REGEN] = 0x7f,
+ [RES_NRES_PWRON] = 0x82,
+ [RES_CLKEN] = 0x85,
+ [RES_SYSEN] = 0x88,
+ [RES_HFCLKOUT] = 0x8b,
+ [RES_32KCLKOUT] = 0x8e,
+ [RES_RESET] = 0x91,
+ [RES_Main_Ref] = 0x94,
+};
+
static int __init twl4030_write_script_byte(u8 address, u8 byte)
{
int err;
@@ -219,6 +257,53 @@ static int __init config_warmreset_seque
return err;
}
+void twl4030_configure_resource(struct twl4030_resconfig *rconfig)
+{
+ int rconfig_addr;
+ u8 type;
+
+ if (rconfig->resource > NUM_OF_RESOURCES) {
+ printk(KERN_ERR
+ "TWL4030 Resource %d does not exist\n",
+ rconfig->resource);
+ return;
+ }
+
+ rconfig_addr = res_config_addrs[rconfig->resource];
+
+ /* Set resource group */
+
+ if (rconfig->devgroup >= 0)
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ rconfig->devgroup << 5,
+ rconfig_addr + DEVGROUP_OFFSET);
+
+ /* Set resource types */
+
+ if (twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER,
+ &type,
+ rconfig_addr + TYPE_OFFSET) < 0) {
+ printk(KERN_ERR
+ "TWL4030 Resource %d type could not read\n",
+
Re: Hi David Brownell. I have a question for twl4030 driver.
On Friday 13 February 2009, Kyungmin Park wrote: > >> So I could use VPLL2 after I get rid of those annotations. > >> I wonder why did you annotate for VPLL2. > >> Does using VPLL2 has some problems? > > > > I didn't have any use case for managing VPLL2 in Linux > > software at runtime, except maybe in conjunction with > > the power management code. > > > > What's your use case? > > It's used for graphics power. Without it. we can only see the limited colors. > Yes there's too much example related with it. so we want to know exact usage. > Now workaround we simply enable it at bootloader. Right, I seem to have overlooked that. Even Beagle boards use VPLL2 to power the digital video (LCD, DVI) output. So I'm sending a patch to let it be manipulated using the regulator framework. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] twl4030-regulator: expose VPLL2
From: David Brownell
Add VPLL2 to the set of twl4030-family regulators exposed for
use by various drivers. It's commonly used to power the digital
video outputs (e.g. LCD or DVI displays) on OMAP3 systems.
Signed-off-by: David Brownell
---
Please apply to regulator-next and linux-omap ... I'll send
some patches configuring various OMAP boards to use this.
drivers/mfd/twl4030-core.c|2 --
drivers/regulator/twl4030-regulator.c |2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -613,11 +613,9 @@ add_children(struct twl4030_platform_dat
/* maybe add LDOs that are omitted on cost-reduced parts */
if (twl_has_regulator() && !(features & TPS_SUBSET)) {
- /*
child = add_regulator(TWL4030_REG_VPLL2, pdata->vpll2);
if (IS_ERR(child))
return PTR_ERR(child);
- */
child = add_regulator(TWL4030_REG_VMMC2, pdata->vmmc2);
if (IS_ERR(child))
--- a/drivers/regulator/twl4030-regulator.c
+++ b/drivers/regulator/twl4030-regulator.c
@@ -404,8 +404,8 @@ static struct twlreg_info twl4030_regs[]
TWL_ADJUSTABLE_LDO(VMMC2, 0x2b, 6),
/*
TWL_ADJUSTABLE_LDO(VPLL1, 0x2f, 7),
- TWL_ADJUSTABLE_LDO(VPLL2, 0x33, 8),
*/
+ TWL_ADJUSTABLE_LDO(VPLL2, 0x33, 8),
TWL_ADJUSTABLE_LDO(VSIM, 0x37, 9),
TWL_ADJUSTABLE_LDO(VDAC, 0x3b, 10),
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Group and resource assignments for TWL4030
On Friday 13 March 2009, Peter 'p2' De Schrijver wrote:
> struct twl4030_power_data {
> struct twl4030_script **scripts;
> - unsigned size;
> + unsigned scripts_size;
And that little bit breaks builds ... since the various
bits of code that initialize a twl4030_power_data have
not been changed.
I'll send an updated version of this patch soonish.
> + struct twl4030_resconfig *resource_config;
> };
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Clean-up for rx51
Here's one more patch to fix checkpatch.pl warnings.
Tony
From f1d42da50bfdb9e952882f32e2e95f9e9621ce00 Mon Sep 17 00:00:00 2001
From: Tony Lindgren
Date: Fri, 13 Mar 2009 15:30:06 -0700
Subject: [PATCH] rx51: Clean-up for checkpatch.pl
rx51: Clean-up for checkpatch.pl
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/configs/rx51_defconfig b/arch/arm/configs/rx51_defconfig
index 53f6a79..2672a70 100644
--- a/arch/arm/configs/rx51_defconfig
+++ b/arch/arm/configs/rx51_defconfig
@@ -43,7 +43,7 @@ CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
-CONFIG_LOG_BUF_SHIFT
+CONFIG_LOG_BUF_SHIFT
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_RT_GROUP_SCHED is not set
@@ -194,7 +194,7 @@ CONFIG_OMAP_MCBSP=y
# CONFIG_OMAP_MBOX_FWK is not set
# CONFIG_OMAP_MPU_TIMER is not set
CONFIG_OMAP_32K_TIMER=y
-CONFIG_OMAP_32K_TIMER_HZ8
+CONFIG_OMAP_32K_TIMER_HZ=128
CONFIG_OMAP_TICK_GPTIMER=1
CONFIG_OMAP_DM_TIMER=y
# CONFIG_OMAP_LL_DEBUG_UART1 is not set
@@ -262,7 +262,7 @@ CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC000
# CONFIG_PREEMPT is not set
-CONFIG_HZ8
+CONFIG_HZ=128
CONFIG_AEABI=y
# CONFIG_OABI_COMPAT is not set
CONFIG_ARCH_FLATMEM_HAS_HOLES=y
@@ -639,8 +639,8 @@ CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
-CONFIG_BLK_DEV_RAM_COUNT
-CONFIG_BLK_DEV_RAM_SIZE384
+CONFIG_BLK_DEV_RAM_COUNT=16
+CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
@@ -1686,7 +1686,7 @@ CONFIG_NLS_ISO8859_1=y
CONFIG_PRINTK_TIME=y
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
-CONFIG_FRAME_WARN24
+CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index b86e94d..6e23587 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -98,19 +98,19 @@ static int rx51_keymap[] = {
KEY(0, 7, KEY_I),
KEY(1, 0, KEY_O),
KEY(1, 1, KEY_D),
- KEY(1, 2, KEY_DOT ),
+ KEY(1, 2, KEY_DOT),
KEY(1, 3, KEY_V),
- KEY(1, 4, KEY_DOWN ),
+ KEY(1, 4, KEY_DOWN),
KEY(2, 0, KEY_P),
KEY(2, 1, KEY_F),
- KEY(2, 2, KEY_UP ),
+ KEY(2, 2, KEY_UP),
KEY(2, 3, KEY_B),
- KEY(2, 4, KEY_RIGHT ),
- KEY(3, 0, KEY_COMMA ),
+ KEY(2, 4, KEY_RIGHT),
+ KEY(3, 0, KEY_COMMA),
KEY(3, 1, KEY_G),
- KEY(3, 2, KEY_ENTER ),
+ KEY(3, 2, KEY_ENTER),
KEY(3, 3, KEY_N),
- KEY(4, 0, KEY_BACKSPACE ),
+ KEY(4, 0, KEY_BACKSPACE),
KEY(4, 1, KEY_H),
KEY(4, 3, KEY_M),
KEY(4, 4, KEY_LEFTCTRL),
@@ -122,7 +122,7 @@ static int rx51_keymap[] = {
KEY(6, 1, KEY_K),
KEY(6, 2, KEY_X),
KEY(6, 3, KEY_SPACE),
- KEY(6, 4, KEY_FN ),
+ KEY(6, 4, KEY_FN),
KEY(7, 0, KEY_S),
KEY(7, 1, KEY_L),
KEY(7, 2, KEY_C),
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 98dfde1..c90120c 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -14,6 +14,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -30,10 +32,6 @@
#include
#include
-#include
-#include
-
-
static struct omap_uart_config rx51_uart_config = {
.enabled_uarts = ((1 << 0) | (1 << 1) | (1 << 2)),
};
[PATCH 2/4] ARM: OMAP3: Add ADS7846 touchscreen support to Overo platform
From: Steve Sakoman
An upcoming Overo expansion board includes an ADS7846 touchscreen controller.
This patch adds support via the ads7846 driver when enabled in the
kernel config.
Signed-off-by: Steve Sakoman
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-overo.c | 61 +
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index fbe1ce0..c057958 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -116,6 +116,66 @@ static inline void __init overo_init_smsc911x(void)
static inline void __init overo_init_smsc911x(void) { return; }
#endif
+#if defined(CONFIG_TOUCHSCREEN_ADS7846) || \
+ defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
+
+#include
+#include
+#include
+
+static struct omap2_mcspi_device_config ads7846_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1,/* 0: slave, 1: master */
+};
+
+
+static int ads7846_get_pendown_state(void)
+{
+ return !gpio_get_value(OVERO_GPIO_PENDOWN);
+}
+
+static struct ads7846_platform_data ads7846_config = {
+ .x_max = 0x0fff,
+ .y_max = 0x0fff,
+ .x_plate_ohms = 180,
+ .pressure_max = 255,
+ .debounce_max = 10,
+ .debounce_tol = 3,
+ .debounce_rep = 1,
+ .get_pendown_state = ads7846_get_pendown_state,
+ .keep_vref_on = 1,
+};
+
+static struct spi_board_info overo_spi_board_info[] __initdata = {
+ {
+ .modalias = "ads7846",
+ .bus_num= 1,
+ .chip_select= 0,
+ .max_speed_hz = 150,
+ .controller_data= &ads7846_mcspi_config,
+ .irq= OMAP_GPIO_IRQ(OVERO_GPIO_PENDOWN),
+ .platform_data = &ads7846_config,
+ }
+};
+
+static void __init overo_ads7846_init(void)
+{
+ if ((gpio_request(OVERO_GPIO_PENDOWN, "ADS7846_PENDOWN") == 0) &&
+ (gpio_direction_input(OVERO_GPIO_PENDOWN) == 0)) {
+ gpio_export(OVERO_GPIO_PENDOWN, 0);
+ } else {
+ printk(KERN_ERR "could not obtain gpio for ADS7846_PENDOWN\n");
+ return;
+ }
+
+ spi_register_board_info(overo_spi_board_info,
+ ARRAY_SIZE(overo_spi_board_info));
+}
+
+#else
+static inline void __init overo_ads7846_init(void) { return; }
+#endif
+
static struct mtd_partition overo_nand_partitions[] = {
{
.name = "xloader",
@@ -290,6 +350,7 @@ static void __init overo_init(void)
overo_flash_init();
usb_musb_init();
overo_init_smsc911x();
+ overo_ads7846_init();
if ((gpio_request(OVERO_GPIO_W2W_NRESET,
"OVERO_GPIO_W2W_NRESET") == 0) &&
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: OMAP3: Add SMSC911X support to Overo platform (V2)
From: Steve Sakoman
Gumstix will soon be shipping a variant of their Summit board that
includes an SMSC LAN9221 ethernet interface. This patch provides
support via the smsc911x driver when enabled in kernel config.
The Overo defconfig is not updated since the LAN9221 is an option
not present on all systems.
Signed-off-by: Steve Sakoman
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-overo.c | 65 +
1 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index d785aa8..fbe1ce0 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -52,6 +52,70 @@
#define GPMC_CS0_BASE 0x60
#define GPMC_CS_SIZE 0x30
+#define OVERO_SMSC911X_CS 5
+#define OVERO_SMSC911X_GPIO176
+
+#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
+
+#include
+
+static struct resource overo_smsc911x_resources[] = {
+ {
+ .name = "smsc911x-memory",
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
+ },
+};
+
+static struct smsc911x_platform_config overo_smsc911x_config = {
+ .irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
+ .irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
+ .flags = SMSC911X_USE_32BIT ,
+ .phy_interface = PHY_INTERFACE_MODE_MII,
+};
+
+static struct platform_device overo_smsc911x_device = {
+ .name = "smsc911x",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(overo_smsc911x_resources),
+ .resource = &overo_smsc911x_resources,
+ .dev= {
+ .platform_data = &overo_smsc911x_config,
+ },
+};
+
+static inline void __init overo_init_smsc911x(void)
+{
+ unsigned long cs_mem_base;
+
+ if (gpmc_cs_request(OVERO_SMSC911X_CS, SZ_16M, &cs_mem_base) < 0) {
+ printk(KERN_ERR "Failed request for GPMC mem for smsc911x\n");
+ return;
+ }
+
+ overo_smsc911x_resources[0].start = cs_mem_base + 0x0;
+ overo_smsc911x_resources[0].end = cs_mem_base + 0xff;
+
+ if ((gpio_request(OVERO_SMSC911X_GPIO, "SMSC911X IRQ") == 0) &&
+ (gpio_direction_input(OVERO_SMSC911X_GPIO) == 0)) {
+ gpio_export(OVERO_SMSC911X_GPIO, 0);
+ } else {
+ printk(KERN_ERR "could not obtain gpio for SMSC911X IRQ\n");
+ return;
+ }
+
+ overo_smsc911x_resources[1].start = OMAP_GPIO_IRQ(OVERO_SMSC911X_GPIO);
+ overo_smsc911x_resources[1].end = 0;
+
+ platform_device_register(&overo_smsc911x_device);
+}
+
+#else
+static inline void __init overo_init_smsc911x(void) { return; }
+#endif
+
static struct mtd_partition overo_nand_partitions[] = {
{
.name = "xloader",
@@ -225,6 +289,7 @@ static void __init overo_init(void)
twl4030_mmc_init(mmc);
overo_flash_init();
usb_musb_init();
+ overo_init_smsc911x();
if ((gpio_request(OVERO_GPIO_W2W_NRESET,
"OVERO_GPIO_W2W_NRESET") == 0) &&
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Omap board updates for merge window after 2.6.29
Hi all, Here are some board updates and few new boards. Regards, Tony --- Lauri Leukkunen (1): ARM OMAP3: Initial support for Nokia RX-51 Steve Sakoman (2): ARM: OMAP3: Add ADS7846 touchscreen support to Overo platform ARM: OMAP3: Add SMSC911X support to Overo platform (V2) Syed Mohammed Khasim (1): ARM: OMAP3: Add support for 3430 SDP arch/arm/configs/omap_3430sdp_defconfig | 2061 ++ arch/arm/configs/rx51_defconfig | 1821 +++ arch/arm/mach-omap2/Kconfig | 10 arch/arm/mach-omap2/Makefile |6 arch/arm/mach-omap2/board-3430sdp.c | 514 ++ arch/arm/mach-omap2/board-overo.c| 126 ++ arch/arm/mach-omap2/board-rx51-peripherals.c | 419 + arch/arm/mach-omap2/board-rx51.c | 96 + 8 files changed, 5052 insertions(+), 1 deletions(-) create mode 100644 arch/arm/configs/omap_3430sdp_defconfig create mode 100644 arch/arm/configs/rx51_defconfig create mode 100644 arch/arm/mach-omap2/board-3430sdp.c create mode 100644 arch/arm/mach-omap2/board-rx51-peripherals.c create mode 100644 arch/arm/mach-omap2/board-rx51.c -- Signature -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3] PM: Start C-state definitions from base 0
Sanjeev Premi writes:
> The current definition of C-states starts from base 1.
> Whereas, the cpuidle driver uses base 0. This patch
> eliminates need for explicit mapping (add/ sbutract)
> due to different base values.
>
> Signed-off-by: Sanjeev Premi
> ---
> arch/arm/mach-omap2/cpuidle34xx.c | 16
> 1 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
> b/arch/arm/mach-omap2/cpuidle34xx.c
> index 62fbb2e..04119e4 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -33,13 +33,13 @@
>
> #ifdef CONFIG_CPU_IDLE
>
> -#define OMAP3_MAX_STATES 7
> -#define OMAP3_STATE_C1 1 /* C1 - MPU WFI + Core active */
> -#define OMAP3_STATE_C2 2 /* C2 - MPU CSWR + Core active */
> -#define OMAP3_STATE_C3 3 /* C3 - MPU OFF + Core active */
> -#define OMAP3_STATE_C4 4 /* C4 - MPU RET + Core RET */
> -#define OMAP3_STATE_C5 5 /* C5 - MPU OFF + Core RET */
> -#define OMAP3_STATE_C6 6 /* C6 - MPU OFF + Core OFF */
> +#define OMAP3_MAX_STATES 6
> +#define OMAP3_STATE_C1 0 /* C1 - MPU WFI + Core active */
> +#define OMAP3_STATE_C2 1 /* C2 - MPU CSWR + Core active */
> +#define OMAP3_STATE_C3 2 /* C3 - MPU OFF + Core active */
> +#define OMAP3_STATE_C4 3 /* C4 - MPU RET + Core RET */
> +#define OMAP3_STATE_C5 4 /* C5 - MPU OFF + Core RET */
> +#define OMAP3_STATE_C6 5 /* C6 - MPU OFF + Core OFF */
>
> struct omap3_processor_cx {
> u8 valid;
> @@ -244,7 +244,7 @@ int omap3_idle_init(void)
>
> dev = &per_cpu(omap3_idle_dev, smp_processor_id());
>
> - for (i = 1; i < OMAP3_MAX_STATES; i++) {
> + for (i = OMAP3_STATE_C1; i < OMAP3_MAX_STATES; i++) {
> cx = &omap3_power_states[i];
> state = &dev->states[count];
>
Thanks, pushing to PM branch after slight fixup in order to apply
after Peter's new C-state patch.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add new lower-latency C1 state take #2
"Peter 'p2' De Schrijver" writes:
> This patch introduces a new C state which allows MPU to go to WFI but keeps
> the core domain active. This offers a much better wakeup latency (3us vs
> 10s of us for the current C1) at the cost of a higher power consumption.
> Fixed the comments.
>
> Signed-off-by: Peter 'p2' De Schrijver
Thanks, pushing to PM branch.
Kevin
> ---
> arch/arm/mach-omap2/cpuidle34xx.c | 121
> -
> 1 files changed, 78 insertions(+), 43 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
> b/arch/arm/mach-omap2/cpuidle34xx.c
> index 62fbb2e..7da2fd8 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -33,13 +34,14 @@
>
> #ifdef CONFIG_CPU_IDLE
>
> -#define OMAP3_MAX_STATES 7
> +#define OMAP3_MAX_STATES 8
> #define OMAP3_STATE_C1 1 /* C1 - MPU WFI + Core active */
> -#define OMAP3_STATE_C2 2 /* C2 - MPU CSWR + Core active */
> -#define OMAP3_STATE_C3 3 /* C3 - MPU OFF + Core active */
> -#define OMAP3_STATE_C4 4 /* C4 - MPU RET + Core RET */
> -#define OMAP3_STATE_C5 5 /* C5 - MPU OFF + Core RET */
> -#define OMAP3_STATE_C6 6 /* C6 - MPU OFF + Core OFF */
> +#define OMAP3_STATE_C2 2 /* C2 - MPU WFI + Core inactive */
> +#define OMAP3_STATE_C3 3 /* C3 - MPU CSWR + Core inactive */
> +#define OMAP3_STATE_C4 4 /* C4 - MPU OFF + Core iactive */
> +#define OMAP3_STATE_C5 5 /* C5 - MPU RET + Core RET */
> +#define OMAP3_STATE_C6 6 /* C6 - MPU OFF + Core RET */
> +#define OMAP3_STATE_C7 7 /* C7 - MPU OFF + Core OFF */
>
> struct omap3_processor_cx {
> u8 valid;
> @@ -63,6 +65,18 @@ static int omap3_idle_bm_check(void)
> return 0;
> }
>
> +static int _cpuidle_allow_idle(struct powerdomain *pwrdm,
> + struct clockdomain *clkdm)
> +{
> + omap2_clkdm_allow_idle(clkdm);
> +}
> +
> +static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
> + struct clockdomain *clkdm)
> +{
> + omap2_clkdm_deny_idle(clkdm);
> +}
> +
> /**
> * omap3_enter_idle - Programs OMAP3 to enter the specified state
> * @dev: cpuidle device
> @@ -99,9 +113,19 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
> if (omap_irq_pending())
> goto return_sleep_time;
>
> + if (cx->type == OMAP3_STATE_C1) {
> + pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
> + pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
> + }
> +
> /* Execute ARM wfi */
> omap_sram_idle();
>
> + if (cx->type == OMAP3_STATE_C1) {
> + pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
> + pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
> + }
> +
> return_sleep_time:
> getnstimeofday(&ts_postidle);
> ts_idle = timespec_sub(ts_postidle, ts_preidle);
> @@ -140,79 +164,90 @@ DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
> /* omap3_init_power_states - Initialises the OMAP3 specific C states.
> *
> * Below is the desciption of each C state.
> - * C1 . MPU WFI + Core active
> - * C2 . MPU CSWR + Core active
> - * C3 . MPU OFF + Core active
> - * C4 . MPU CSWR + Core CSWR
> - * C5 . MPU OFF + Core CSWR
> - * C6 . MPU OFF + Core OFF
> + * C1 . MPU WFI + Core active
> + * C2 . MPU WFI + Core inactive
> + * C3 . MPU CSWR + Core inactive
> + * C4 . MPU OFF + Core inactive
> + * C5 . MPU CSWR + Core CSWR
> + * C6 . MPU OFF + Core CSWR
> + * C7 . MPU OFF + Core OFF
> */
> void omap_init_power_states(void)
> {
> /* C1 . MPU WFI + Core active */
> omap3_power_states[OMAP3_STATE_C1].valid = 1;
> omap3_power_states[OMAP3_STATE_C1].type = OMAP3_STATE_C1;
> - omap3_power_states[OMAP3_STATE_C1].sleep_latency = 10;
> - omap3_power_states[OMAP3_STATE_C1].wakeup_latency = 10;
> - omap3_power_states[OMAP3_STATE_C1].threshold = 30;
> + omap3_power_states[OMAP3_STATE_C1].sleep_latency = 2;
> + omap3_power_states[OMAP3_STATE_C1].wakeup_latency = 2;
> + omap3_power_states[OMAP3_STATE_C1].threshold = 5;
> omap3_power_states[OMAP3_STATE_C1].mpu_state = PWRDM_POWER_ON;
> omap3_power_states[OMAP3_STATE_C1].core_state = PWRDM_POWER_ON;
> omap3_power_states[OMAP3_STATE_C1].flags = CPUIDLE_FLAG_TIME_VALID;
>
> - /* C2 . MPU CSWR + Core active */
> + /* C2 . MPU WFI + Core inactive */
> omap3_power_states[OMAP3_STATE_C2].valid = 1;
> omap3_power_states[OMAP3_STATE_C2].type = OMAP3_STATE_C2;
> - omap3_power_states[OMAP3_STATE_C2].sleep_latency = 50;
> - omap3_power_states[OMAP3_STATE_C2].wakeup_latency = 50;
> - omap3_power_states[OMAP3_STATE_C2].threshold = 300;
> - omap3_power_states[OMAP3_STATE_C2].mpu_state = PWRDM_POWER_RET;
> + omap3_power_states[OMAP3_STATE_C2].sleep_latency = 10;
> + omap3_power_states[OMAP3_STATE_C2].wakeup_latency =
Re: [PATCH] Remove fclk check for cpuidle
"Peter 'p2' De Schrijver" writes:
> This patch removes the check to see if some functional clocks are still
> enabled before entering sleep.
>
> Signed-off-by: Peter 'p2' De Schrijver
Thanks, pushing along with updated C1 patch.
Kevin
> ---
> arch/arm/mach-omap2/pm34xx.c | 46
> --
> 1 files changed, 0 insertions(+), 46 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index e12ff2a..008a4d2 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -453,58 +453,12 @@ void omap_sram_idle(void)
> omap2_clkdm_allow_idle(mpu_pwrdm->pwrdm_clkdms[0]);
> }
>
> -/*
> - * Check if functional clocks are enabled before entering
> - * sleep. This function could be behind CONFIG_PM_DEBUG
> - * when all drivers are configuring their sysconfig registers
> - * properly and using their clocks properly.
> - */
> -static int omap3_fclks_active(void)
> -{
> - u32 fck_core1 = 0, fck_core3 = 0, fck_sgx = 0, fck_dss = 0,
> - fck_cam = 0, fck_per = 0, fck_usbhost = 0;
> -
> - fck_core1 = cm_read_mod_reg(CORE_MOD,
> - CM_FCLKEN1);
> - if (omap_rev() > OMAP3430_REV_ES1_0) {
> - fck_core3 = cm_read_mod_reg(CORE_MOD,
> - OMAP3430ES2_CM_FCLKEN3);
> - fck_sgx = cm_read_mod_reg(OMAP3430ES2_SGX_MOD,
> - CM_FCLKEN);
> - fck_usbhost = cm_read_mod_reg(OMAP3430ES2_USBHOST_MOD,
> - CM_FCLKEN);
> - } else
> - fck_sgx = cm_read_mod_reg(GFX_MOD,
> - OMAP3430ES2_CM_FCLKEN3);
> - fck_dss = cm_read_mod_reg(OMAP3430_DSS_MOD,
> - CM_FCLKEN);
> - fck_cam = cm_read_mod_reg(OMAP3430_CAM_MOD,
> - CM_FCLKEN);
> - fck_per = cm_read_mod_reg(OMAP3430_PER_MOD,
> - CM_FCLKEN);
> -
> - /* Ignore UART clocks. These are handled by UART core (serial.c) */
> - fck_core1 &= ~(OMAP3430_EN_UART1 | OMAP3430_EN_UART2);
> - fck_per &= ~OMAP3430_EN_UART3;
> -
> - /* Ignore GPIO clocks. Handled by GPIO prepare-idle hooks */
> - fck_per &= ~(OMAP3430_EN_GPIO2 | OMAP3430_EN_GPIO3 |
> - OMAP3430_EN_GPIO4 | OMAP3430_EN_GPIO5 | OMAP3430_EN_GPIO6);
> -
> - if (fck_core1 | fck_core3 | fck_sgx | fck_dss |
> - fck_cam | fck_per | fck_usbhost)
> - return 1;
> - return 0;
> -}
> -
> int omap3_can_sleep(void)
> {
> if (!enable_dyn_sleep)
> return 0;
> if (!omap_uart_can_sleep())
> return 0;
> - if (omap3_fclks_active())
> - return 0;
> if (atomic_read(&sleep_block) > 0)
> return 0;
> return 1;
> --
> 1.5.6.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/5] LDP: Add support for built-in camera
> -Original Message-
> From: stanley.miao [mailto:stanley.m...@windriver.com]
> Sent: Tuesday, March 10, 2009 3:04 AM
> To: Aguirre Rodriguez, Sergio Alberto
> Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Sakari Ailus;
> Tuukka.O Toivonen; Hiroshi DOYU; DongSoo(Nathaniel) Kim; MiaoStanley;
> Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth
> Subject: RE: [PATCH 5/5] LDP: Add support for built-in camera
>
> On Mon, 2009-03-09 at 15:24 -0500, Aguirre Rodriguez, Sergio Alberto
> wrote:
> > Hi,
> >
> > > -Original Message-
> > > From: stanley.miao [mailto:stanley.m...@windriver.com]
> >
> >
> >
> > > > +static struct i2c_board_info __initdata ldp_i2c_boardinfo_2[] = {
> > > > +#if defined(CONFIG_VIDEO_OV3640) ||
> defined(CONFIG_VIDEO_OV3640_MODULE)
> > > > + {
> > > > + I2C_BOARD_INFO("ov3640", OV3640_I2C_ADDR),
> > > > + .platform_data = &ldp_ov3640_platform_data,
> > > > + },
> > > > +#endif
> > > > +};
> > > >
> > > This new added i2c_board_info was not registered.
> > > After I added this line,
> > >
> > > omap_register_i2c_bus(2, 400, ldp_i2c_boardinfo_2,
> > > ARRAY_SIZE(ldp_i2c_boardinfo_2));
> > >
> > > the sensor was found. but the test still failed. A lot of error came
> out
> > > when I run my test program.
> > >
> > > <3>CSI2: ComplexIO Error IRQ 80
> > > CSI2: ComplexIO Error IRQ 80
> > > <3>CSI2: ComplexIO Error IRQ c2
> > > CSI2: ComplexIO Error IRQ c2
> > > <3>CSI2: ComplexIO Error IRQ c2
> > > CSI2: ComplexIO Error IRQ c2
> > > <3>CSI2: ComplexIO Error IRQ c6
> > > CSI2: ComplexIO Error IRQ c6
> > > <3>CSI2: ECC correction failed
> > > CSI2: ECC correction failed
> > > <3>CSI2: ComplexIO Error IRQ 6
> > > CSI2: ComplexIO Error IRQ 6
> > > <3>CSI2: ComplexIO Error IRQ 6
> > > CSI2: ComplexIO Error IRQ 6
> > > <3>CSI2: ComplexIO Error IRQ 6
> > > CSI2: ComplexIO Error IRQ 6
> > > <3>CSI2: ComplexIO Error IRQ 6
> > > CSI2: ComplexIO Error IRQ 6
> > >
> >
> > Oops, my mistake. Missed to add that struct there... Fixed now.
> >
> > About the CSI2 errors you're receiving... Which version of LDP are you
> using? Which Silicon revision has (ES2.1 or ES3.0)?
>
> ZOOM1 board(LDP3430-VG1.0.0-1), omap3430 ES2.1.
>
> When I use your old version patch, sometimes the test succeed, sometimes
> failed(no data was generated and no error). This version, always failed.
Stanley,
I'm working on some CSI2 fixes that could help you with this..
I'll keep you updated on this.
Also, about your board version, it is possible that you'll need a HW modfix
because of a redundant resistor in CSI2 datalanes. I'm in talks with some
people at TI to prepare a ready to publish document about this rework.
Zoom1 with ES3 silicon doesn't need this HW fix.
I'll hope to get back to you about this next week.
Regards,
Sergio
>
> Thanks.
> Stanley.
>
> >
> > Regards,
> > Sergio
> > >
> > > Stanley.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [patch 2.6.29-rc7-omap] twl4030-regulator: list more VAUX4 voltages
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: ad41b8dce8761b94dbef01e252f4f87a7c1e19ec PatchWorks http://patchwork.kernel.org/patch/10952/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=ad41b8dce8761b94dbef01e252f4f87a7c1e19ec -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Clean-up for rx51
* Tony Lindgren [090313 11:03]: > Hi all, > > Here are few patches against the l-o tree to clean-up rx51 board > files. Also catch up with the mmc-twl4030 changes, and make > the smc911x Ethernet work. Correction, smc91x that is, not smc911x or smsc911x. > Regards, > > Tony > > --- > > David Brownell (3): > Hook up twl4030 regulators to the relevant RX51 MMC slots. > Bugfix to RX51 flash support: this board has no NOR flash, > Clean-up rx51 a bit and set the regulators. > > Tony Lindgren (1): > Set the smc91x timings for rx51 > > > arch/arm/mach-omap2/board-rx51-flash.c | 58 - > arch/arm/mach-omap2/board-rx51-peripherals.c | 305 > ++ > 2 files changed, 262 insertions(+), 101 deletions(-) > > -- > Signature > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] Hook up twl4030 regulators to the relevant RX51 MMC slots.
From: David Brownell
Signed-off-by: David Brownell
Acked-by: Lauri Leukkunen
---
arch/arm/mach-omap2/board-rx51-flash.c | 23
arch/arm/mach-omap2/board-rx51-peripherals.c | 48 +-
2 files changed, 46 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-flash.c
b/arch/arm/mach-omap2/board-rx51-flash.c
index 39b0659..fe9329d 100644
--- a/arch/arm/mach-omap2/board-rx51-flash.c
+++ b/arch/arm/mach-omap2/board-rx51-flash.c
@@ -10,34 +10,11 @@
#include
#include
-#include
-
-#include "mmc-twl4030.h"
extern void __init n800_flash_init(void);
-static struct twl4030_hsmmc_info mmc[] __initdata = {
- {
- .name = "external",
- .mmc= 1,
- .wires = 4,
- .cover_only = true,
- .gpio_cd= 160,
- .gpio_wp= -EINVAL,
- },
- {
- .name = "internal",
- .mmc= 2,
- .wires = 8,
- .gpio_cd= -EINVAL,
- .gpio_wp= -EINVAL,
- },
- {} /* Terminator */
-};
-
void __init rx51_flash_init(void)
{
n800_flash_init();
- twl4030_mmc_init(mmc);
}
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 88f9f43..b86e94d 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -28,7 +28,10 @@
#include
#include
-#defineSMC91X_CS 1
+#include "mmc-twl4030.h"
+
+
+#define SMC91X_CS 1
#define SMC91X_GPIO_IRQ54
#define SMC91X_GPIO_RESET 164
#define SMC91X_GPIO_PWRDWN 86
@@ -247,6 +250,37 @@ static struct twl4030_madc_platform_data rx51_madc_data = {
.irq_line = 1,
};
+static struct twl4030_hsmmc_info mmc[] = {
+ {
+ .name = "external",
+ .mmc= 1,
+ .wires = 4,
+ .cover_only = true,
+ .gpio_cd= 160,
+ .gpio_wp= -EINVAL,
+ },
+ {
+ .name = "internal",
+ .mmc= 2,
+ .wires = 8,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ },
+ {} /* Terminator */
+};
+
+static struct regulator_consumer_supply rx51_vmmc1_supply = {
+ .supply = "vmmc",
+};
+
+static struct regulator_consumer_supply rx51_vmmc2_supply = {
+ .supply = "vmmc",
+};
+
+static struct regulator_consumer_supply rx51_vsim_supply = {
+ .supply = "vmmc_aux",
+};
+
static struct regulator_init_data rx51_vaux1 = {
.constraints = {
.name = "V28",
@@ -308,6 +342,8 @@ static struct regulator_init_data rx51_vmmc1 = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = 1,
+ .consumer_supplies = &rx51_vmmc1_supply,
};
static struct regulator_init_data rx51_vmmc2 = {
@@ -322,6 +358,8 @@ static struct regulator_init_data rx51_vmmc2 = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = 1,
+ .consumer_supplies = &rx51_vmmc2_supply,
};
static struct regulator_init_data rx51_vsim = {
@@ -335,6 +373,8 @@ static struct regulator_init_data rx51_vsim = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = 1,
+ .consumer_supplies = &rx51_vsim_supply,
};
static struct regulator_init_data rx51_vdac = {
@@ -357,7 +397,11 @@ static int rx51_twlgpio_setup(struct device *dev, unsigned
gpio, unsigned n)
gpio_request(gpio + 7, "speaker_en");
gpio_direction_output(gpio + 7, 1);
- /* FIXME connect power supplies to devices; register MMC */
+ /* set up MMC adapters, linking their regulators to them */
+ twl4030_mmc_init(mmc);
+ rx51_vmmc1_supply.dev = mmc[0].dev;
+ rx51_vmmc2_supply.dev = mmc[1].dev;
+ rx51_vsim_supply.dev = mmc[1].dev;
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] Set the smc91x timings for rx51
This could be converted into more generic smc91x init code.
Signed-off-by: Tony Lindgren
Acked-by: Lauri Leukkunen
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 105 --
1 files changed, 80 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 49c3d80..88f9f43 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -28,13 +28,14 @@
#include
#include
-#define RX51_ETHR_GPIO_IRQ 54
+#defineSMC91X_CS 1
+#define SMC91X_GPIO_IRQ54
+#define SMC91X_GPIO_RESET 164
+#define SMC91X_GPIO_PWRDWN 86
#define RX51_TSC2005_RESET_GPIO104
#define RX51_TSC2005_IRQ_GPIO 100
-#defineRX51_SMC91X_CS 1
-
static struct resource rx51_smc91x_resources[] = {
[0] = {
.flags = IORESOURCE_MEM,
@@ -71,7 +72,6 @@ static struct omap2_mcspi_device_config tsc2005_mcspi_config
= {
.single_channel = 1,
};
-
static struct spi_board_info rx51_peripherals_spi_board_info[] = {
[0] = {
.modalias = "tsc2005",
@@ -143,37 +143,92 @@ static struct platform_device *rx51_peripherals_devices[]
= {
&rx51_smc91x_device,
};
+/*
+ * Timings are taken from smsc-lan91c96-ms.pdf
+ */
+static int smc91x_init_gpmc(int cs)
+{
+ struct gpmc_timings t;
+ const int t2_r = 45;/* t2 in Figure 12.10 */
+ const int t2_w = 30;/* t2 in Figure 12.11 */
+ const int t3 = 15; /* t3 in Figure 12.10 */
+ const int t5_r = 0; /* t5 in Figure 12.10 */
+ const int t6_r = 45;/* t6 in Figure 12.10 */
+ const int t6_w = 0; /* t6 in Figure 12.11 */
+ const int t7_w = 15;/* t7 in Figure 12.11 */
+ const int t15 = 12; /* t15 in Figure 12.2 */
+ const int t20 = 185;/* t20 in Figure 12.2 */
+
+ memset(&t, 0, sizeof(t));
+
+ t.cs_on = t15;
+ t.cs_rd_off = t3 + t2_r + t5_r; /* Figure 12.10 */
+ t.cs_wr_off = t3 + t2_w + t6_w; /* Figure 12.11 */
+ t.adv_on = t3; /* Figure 12.10 */
+ t.adv_rd_off = t3 + t2_r; /* Figure 12.10 */
+ t.adv_wr_off = t3 + t2_w; /* Figure 12.11 */
+ t.oe_off = t3 + t2_r + t5_r;/* Figure 12.10 */
+ t.oe_on = t.oe_off - t6_r; /* Figure 12.10 */
+ t.we_off = t3 + t2_w + t6_w;/* Figure 12.11 */
+ t.we_on = t.we_off - t7_w; /* Figure 12.11 */
+ t.rd_cycle = t20; /* Figure 12.2 */
+ t.wr_cycle = t20; /* Figure 12.4 */
+ t.access = t3 + t2_r + t5_r;/* Figure 12.10 */
+ t.wr_access = t3 + t2_w + t6_w; /* Figure 12.11 */
+
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, GPMC_CONFIG1_DEVICESIZE_16);
+
+ return gpmc_cs_set_timings(cs, &t);
+}
+
static void __init rx51_init_smc91x(void)
{
- int eth_cs;
unsigned long cs_mem_base;
- unsigned int rate;
- struct clk *l3ck;
+ int ret;
- eth_cs = RX51_SMC91X_CS;
+ omap_cfg_reg(U8_34XX_GPIO54_DOWN);
+ omap_cfg_reg(G25_34XX_GPIO86_OUT);
+ omap_cfg_reg(H19_34XX_GPIO164_OUT);
- l3ck = clk_get(NULL, "core_l3_ck");
- if (IS_ERR(l3ck))
- rate = 1;
- else
- rate = clk_get_rate(l3ck);
-
- if (gpmc_cs_request(eth_cs, SZ_16M, &cs_mem_base) < 0) {
+ if (gpmc_cs_request(SMC91X_CS, SZ_16M, &cs_mem_base) < 0) {
printk(KERN_ERR "Failed to request GPMC mem for smc91x\n");
return;
}
- rx51_smc91x_resources[0].start = cs_mem_base + 0x0;
- rx51_smc91x_resources[0].end = cs_mem_base + 0xf;
- udelay(100);
+ rx51_smc91x_resources[0].start = cs_mem_base + 0x300;
+ rx51_smc91x_resources[0].end = cs_mem_base + 0x30f;
- if (gpio_request(RX51_ETHR_GPIO_IRQ, "SMC91X irq") < 0) {
- printk(KERN_ERR "Failed to request GPIO%d for smc91x IRQ\n",
- RX51_ETHR_GPIO_IRQ);
- return;
- }
- gpio_direction_input(RX51_ETHR_GPIO_IRQ);
- rx51_smc91x_resources[1].start = gpio_to_irq(RX51_ETHR_GPIO_IRQ);
+ smc91x_init_gpmc(SMC91X_CS);
+
+ if (gpio_request(SMC91X_GPIO_IRQ, "SMC91X irq") < 0)
+ goto free1;
+
+ gpio_direction_input(SMC91X_GPIO_IRQ);
+ rx51_smc91x_resources[1].start = gpio_to_irq(SMC91X_GPIO_IRQ);
+
+ ret = gpio_request(SMC91X_GPIO_PWRDWN, "SMC91X powerdown");
+ if (ret)
+ goto free2;
+ gpio_direction_output(SMC91X_GPIO_PWRDWN, 0);
+
+ ret = gpio_request(SMC91X_GPIO_RESET, "SMC91X reset");
+ if (ret)
+ goto free3;
+ gpio_direction_output(S
[PATCH 2/4] Bugfix to RX51 flash support: this board has no NOR flash,
From: David Brownell
Signed-off-by: David Brownell
Acked-by: Lauri Leukkunen
---
arch/arm/mach-omap2/board-rx51-flash.c | 37 +---
1 files changed, 1 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-flash.c
b/arch/arm/mach-omap2/board-rx51-flash.c
index cd030a6..39b0659 100644
--- a/arch/arm/mach-omap2/board-rx51-flash.c
+++ b/arch/arm/mach-omap2/board-rx51-flash.c
@@ -10,46 +10,12 @@
#include
#include
-#include
-#include
-#include
-#include
-
-#include
+#include
#include "mmc-twl4030.h"
-#defineRX51_FLASH_CS 0
-
-extern struct mtd_partition n800_partitions[ONENAND_MAX_PARTITIONS];
-extern int n800_onenand_setup(void __iomem *onenand_base, int freq);
extern void __init n800_flash_init(void);
-static struct flash_platform_data rx51_flash_data = {
- .map_name = "cfi_probe",
- .width = 2,
- .parts = n800_partitions,
- .nr_parts = ARRAY_SIZE(n800_partitions),
-};
-
-static struct resource rx51_flash_resource = {
- .flags = IORESOURCE_MEM,
-};
-
-static struct platform_device rx51_flash_device = {
- .name = "omapflash",
- .id = 0,
- .dev= {
- .platform_data = &rx51_flash_data,
- },
- .num_resources = 1,
- .resource = &rx51_flash_resource,
-};
-
-static struct platform_device *rx51_flash_devices[] = {
- &rx51_flash_device,
-};
-
static struct twl4030_hsmmc_info mmc[] __initdata = {
{
.name = "external",
@@ -71,7 +37,6 @@ static struct twl4030_hsmmc_info mmc[] __initdata = {
void __init rx51_flash_init(void)
{
- platform_add_devices(rx51_flash_devices,
ARRAY_SIZE(rx51_flash_devices));
n800_flash_init();
twl4030_mmc_init(mmc);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] Clean-up rx51 a bit and set the regulators.
From: David Brownell
Signed-off-by: David Brownell
Acked-by: Lauri Leukkunen
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 158 +++---
1 files changed, 139 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9da0187..49c3d80 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -1,7 +1,7 @@
/*
* linux/arch/arm/mach-omap2/board-rx51-flash.c
*
- * Copyright (C) 2008 Nokia
+ * Copyright (C) 2008-2009 Nokia
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -18,18 +18,16 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
-#include
#include
#include
-#define RX51_DEBUG_BASE0x0800 /* debug board */
-#define RX51_ETHR_STARTRX51_DEBUG_BASE
#define RX51_ETHR_GPIO_IRQ 54
#define RX51_TSC2005_RESET_GPIO104
@@ -39,13 +37,9 @@
static struct resource rx51_smc91x_resources[] = {
[0] = {
- .start = RX51_ETHR_START,
- .end= RX51_ETHR_START + SZ_4K,
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = OMAP_GPIO_IRQ(RX51_ETHR_GPIO_IRQ),
- .end= 0,
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHEDGE,
},
};
@@ -58,7 +52,7 @@ static struct platform_device rx51_smc91x_device = {
};
static struct tsc2005_platform_data tsc2005_config = {
- .reset_gpio = RX51_TSC2005_RESET_GPIO, /* not used */
+ .reset_gpio = RX51_TSC2005_RESET_GPIO, /* not used */
.ts_x_plate_ohm = 280,
.ts_hw_avg = 0,
@@ -83,8 +77,8 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] = {
.modalias = "tsc2005",
.bus_num= 1,
.chip_select= 0,
- .irq= OMAP_GPIO_IRQ(RX51_TSC2005_IRQ_GPIO),
- .max_speed_hz = 600,
+ .irq= OMAP_GPIO_IRQ(RX51_TSC2005_IRQ_GPIO),
+ .max_speed_hz = 600,
.controller_data= &tsc2005_mcspi_config,
.platform_data = &tsc2005_config,
},
@@ -140,8 +134,8 @@ static int rx51_keymap[] = {
static struct twl4030_keypad_data rx51_kp_data = {
.rows = 8,
.cols = 8,
- .keymap = rx51_keymap,
- .keymapsize = ARRAY_SIZE(rx51_keymap),
+ .keymap = rx51_keymap,
+ .keymapsize = ARRAY_SIZE(rx51_keymap),
.rep= 1,
};
@@ -179,6 +173,7 @@ static void __init rx51_init_smc91x(void)
return;
}
gpio_direction_input(RX51_ETHR_GPIO_IRQ);
+ rx51_smc91x_resources[1].start = gpio_to_irq(RX51_ETHR_GPIO_IRQ);
}
static void __init rx51_init_tsc2005(void)
@@ -193,18 +188,135 @@ static void __init rx51_init_tsc2005(void)
}
}
-static struct twl4030_usb_data rx51_usb_data = {
- .usb_mode = T2_USB_MODE_ULPI,
-};
-
static struct twl4030_madc_platform_data rx51_madc_data = {
.irq_line = 1,
};
+static struct regulator_init_data rx51_vaux1 = {
+ .constraints = {
+ .name = "V28",
+ .min_uV = 280,
+ .max_uV = 280,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct regulator_init_data rx51_vaux2 = {
+ .constraints = {
+ .name = "VCSI",
+ .min_uV = 180,
+ .max_uV = 180,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+/* VAUX3 - adds more power to VIO_18 rail */
+static struct regulator_init_data rx51_vaux3 = {
+ .constraints = {
+ .name = "VCAM_DIG_18",
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDB
[PATCH 0/4] Clean-up for rx51
Hi all, Here are few patches against the l-o tree to clean-up rx51 board files. Also catch up with the mmc-twl4030 changes, and make the smc911x Ethernet work. Regards, Tony --- David Brownell (3): Hook up twl4030 regulators to the relevant RX51 MMC slots. Bugfix to RX51 flash support: this board has no NOR flash, Clean-up rx51 a bit and set the regulators. Tony Lindgren (1): Set the smc91x timings for rx51 arch/arm/mach-omap2/board-rx51-flash.c | 58 - arch/arm/mach-omap2/board-rx51-peripherals.c | 305 ++ 2 files changed, 262 insertions(+), 101 deletions(-) -- Signature -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: iNAND on ZOOM2
Hi, The device present on Zoom2 is an eMMC. I have seen some issues with respect to eMMC on the Zoom2 platforms. I have seen the below error some times. But mostly the reads worked fine and the device was recognized but any write attempt to card used to generate DATA CRC errors. I have tested an iNAND device on an other platform with the same driver. That device seems to work fine though. Regards, Madhu -Original Message- From: Pandita, Vikram [mailto:vikram.pand...@ti.com] Sent: Friday, March 13, 2009 7:39 AM To: Kandasamy, ShankarGanesh; linux-omap@vger.kernel.org; Chikkature Rajashekar, Madhusudhan Subject: RE: iNAND on ZOOM2 Madhu Can you comment on your experience with EMMC. >-Original Message- >From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of >Kandasamy, ShankarGanesh >Sent: Friday, March 13, 2009 7:37 AM >To: linux-omap@vger.kernel.org >Subject: iNAND on ZOOM2 > >Hi all, >I am trying to access iNAND on ZOOM2 . I enabled MMC2 on kernel Config. Still, i am not able to >access iNAND. , getting error -110 whilst initializing MMC >Can anyone guide me how to enable access for iNAND on MDK-II platforms ? > >mmc0: host does not support reading read-only switch. assuming write-enable. >mmc0: new high speed SD card at address a9e9 >mmcblk0: mmc0:a9e9 SD02G 1966080KiB > mmcblk0: p1 p2 >mmc1: error -110 whilst initialising MMC card >EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended > > >PS : Kernel created from latest branch of http://git.omapzoom.org/repo/omapkernel.git > > >With Thanks & Regards , >ShankarGanesh >CSST Team-- >To unsubscribe from this list: send the line "unsubscribe linux-omap" in >the body of a message to majord...@vger.kernel.org >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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add new lower-latency C1 state take #2
This patch introduces a new C state which allows MPU to go to WFI but keeps
the core domain active. This offers a much better wakeup latency (3us vs
10s of us for the current C1) at the cost of a higher power consumption.
Fixed the comments.
Signed-off-by: Peter 'p2' De Schrijver
---
arch/arm/mach-omap2/cpuidle34xx.c | 121 -
1 files changed, 78 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 62fbb2e..7da2fd8 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -33,13 +34,14 @@
#ifdef CONFIG_CPU_IDLE
-#define OMAP3_MAX_STATES 7
+#define OMAP3_MAX_STATES 8
#define OMAP3_STATE_C1 1 /* C1 - MPU WFI + Core active */
-#define OMAP3_STATE_C2 2 /* C2 - MPU CSWR + Core active */
-#define OMAP3_STATE_C3 3 /* C3 - MPU OFF + Core active */
-#define OMAP3_STATE_C4 4 /* C4 - MPU RET + Core RET */
-#define OMAP3_STATE_C5 5 /* C5 - MPU OFF + Core RET */
-#define OMAP3_STATE_C6 6 /* C6 - MPU OFF + Core OFF */
+#define OMAP3_STATE_C2 2 /* C2 - MPU WFI + Core inactive */
+#define OMAP3_STATE_C3 3 /* C3 - MPU CSWR + Core inactive */
+#define OMAP3_STATE_C4 4 /* C4 - MPU OFF + Core iactive */
+#define OMAP3_STATE_C5 5 /* C5 - MPU RET + Core RET */
+#define OMAP3_STATE_C6 6 /* C6 - MPU OFF + Core RET */
+#define OMAP3_STATE_C7 7 /* C7 - MPU OFF + Core OFF */
struct omap3_processor_cx {
u8 valid;
@@ -63,6 +65,18 @@ static int omap3_idle_bm_check(void)
return 0;
}
+static int _cpuidle_allow_idle(struct powerdomain *pwrdm,
+ struct clockdomain *clkdm)
+{
+ omap2_clkdm_allow_idle(clkdm);
+}
+
+static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
+ struct clockdomain *clkdm)
+{
+ omap2_clkdm_deny_idle(clkdm);
+}
+
/**
* omap3_enter_idle - Programs OMAP3 to enter the specified state
* @dev: cpuidle device
@@ -99,9 +113,19 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
if (omap_irq_pending())
goto return_sleep_time;
+ if (cx->type == OMAP3_STATE_C1) {
+ pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
+ pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
+ }
+
/* Execute ARM wfi */
omap_sram_idle();
+ if (cx->type == OMAP3_STATE_C1) {
+ pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
+ pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
+ }
+
return_sleep_time:
getnstimeofday(&ts_postidle);
ts_idle = timespec_sub(ts_postidle, ts_preidle);
@@ -140,79 +164,90 @@ DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
/* omap3_init_power_states - Initialises the OMAP3 specific C states.
*
* Below is the desciption of each C state.
- * C1 . MPU WFI + Core active
- * C2 . MPU CSWR + Core active
- * C3 . MPU OFF + Core active
- * C4 . MPU CSWR + Core CSWR
- * C5 . MPU OFF + Core CSWR
- * C6 . MPU OFF + Core OFF
+ * C1 . MPU WFI + Core active
+ * C2 . MPU WFI + Core inactive
+ * C3 . MPU CSWR + Core inactive
+ * C4 . MPU OFF + Core inactive
+ * C5 . MPU CSWR + Core CSWR
+ * C6 . MPU OFF + Core CSWR
+ * C7 . MPU OFF + Core OFF
*/
void omap_init_power_states(void)
{
/* C1 . MPU WFI + Core active */
omap3_power_states[OMAP3_STATE_C1].valid = 1;
omap3_power_states[OMAP3_STATE_C1].type = OMAP3_STATE_C1;
- omap3_power_states[OMAP3_STATE_C1].sleep_latency = 10;
- omap3_power_states[OMAP3_STATE_C1].wakeup_latency = 10;
- omap3_power_states[OMAP3_STATE_C1].threshold = 30;
+ omap3_power_states[OMAP3_STATE_C1].sleep_latency = 2;
+ omap3_power_states[OMAP3_STATE_C1].wakeup_latency = 2;
+ omap3_power_states[OMAP3_STATE_C1].threshold = 5;
omap3_power_states[OMAP3_STATE_C1].mpu_state = PWRDM_POWER_ON;
omap3_power_states[OMAP3_STATE_C1].core_state = PWRDM_POWER_ON;
omap3_power_states[OMAP3_STATE_C1].flags = CPUIDLE_FLAG_TIME_VALID;
- /* C2 . MPU CSWR + Core active */
+ /* C2 . MPU WFI + Core inactive */
omap3_power_states[OMAP3_STATE_C2].valid = 1;
omap3_power_states[OMAP3_STATE_C2].type = OMAP3_STATE_C2;
- omap3_power_states[OMAP3_STATE_C2].sleep_latency = 50;
- omap3_power_states[OMAP3_STATE_C2].wakeup_latency = 50;
- omap3_power_states[OMAP3_STATE_C2].threshold = 300;
- omap3_power_states[OMAP3_STATE_C2].mpu_state = PWRDM_POWER_RET;
+ omap3_power_states[OMAP3_STATE_C2].sleep_latency = 10;
+ omap3_power_states[OMAP3_STATE_C2].wakeup_latency = 10;
+ omap3_power_states[OMAP3_STATE_C2].threshold = 30;
+ omap3_power_states[OMAP3_STATE_C2].mpu_state = PWRDM_POWER_ON;
omap3_power_states[OMAP3_STATE_C2].core_state = PWRDM_POWER_ON;
- oma
[PATCHv3] PM: Start C-state definitions from base 0
The current definition of C-states starts from base 1.
Whereas, the cpuidle driver uses base 0. This patch
eliminates need for explicit mapping (add/ sbutract)
due to different base values.
Signed-off-by: Sanjeev Premi
---
arch/arm/mach-omap2/cpuidle34xx.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 62fbb2e..04119e4 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -33,13 +33,13 @@
#ifdef CONFIG_CPU_IDLE
-#define OMAP3_MAX_STATES 7
-#define OMAP3_STATE_C1 1 /* C1 - MPU WFI + Core active */
-#define OMAP3_STATE_C2 2 /* C2 - MPU CSWR + Core active */
-#define OMAP3_STATE_C3 3 /* C3 - MPU OFF + Core active */
-#define OMAP3_STATE_C4 4 /* C4 - MPU RET + Core RET */
-#define OMAP3_STATE_C5 5 /* C5 - MPU OFF + Core RET */
-#define OMAP3_STATE_C6 6 /* C6 - MPU OFF + Core OFF */
+#define OMAP3_MAX_STATES 6
+#define OMAP3_STATE_C1 0 /* C1 - MPU WFI + Core active */
+#define OMAP3_STATE_C2 1 /* C2 - MPU CSWR + Core active */
+#define OMAP3_STATE_C3 2 /* C3 - MPU OFF + Core active */
+#define OMAP3_STATE_C4 3 /* C4 - MPU RET + Core RET */
+#define OMAP3_STATE_C5 4 /* C5 - MPU OFF + Core RET */
+#define OMAP3_STATE_C6 5 /* C6 - MPU OFF + Core OFF */
struct omap3_processor_cx {
u8 valid;
@@ -244,7 +244,7 @@ int omap3_idle_init(void)
dev = &per_cpu(omap3_idle_dev, smp_processor_id());
- for (i = 1; i < OMAP3_MAX_STATES; i++) {
+ for (i = OMAP3_STATE_C1; i < OMAP3_MAX_STATES; i++) {
cx = &omap3_power_states[i];
state = &dev->states[count];
--
1.5.6
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bridge issue #3! dma_alloc_coherent causing crash - pm branch
"Gupta, Ramesh" writes: [...] >> > Sounds like a memory leak in the bridge driver to me. I >> suggest you >> > enable memory leak debugging. In Kconfig >> > >> >Kernel Hacking --> Kernel debugging >> > >> > Enable 'Debug slab memory allocations' and its child 'Memory leak >> > debugging'. >> > >> > Or, you could switch to the SLUB allocator which has some more >> > flexible debug options which can be controlled at boot-time >> from the cmdline. >> > >> > While you are in the Kernel debugging menu, make sure you enable >> > 'Verbose BUG()' and 'Verbose kernel errors'. This will ensure that >> > any memory leaks will be dumped with some extra debug output. > > I enabled all the above options, do I need to add some boot options to enable > Debug messages? I am not seeing any debug information displayed in the cosole > by default. > Looks like I am mising some thing :( . Any comments? > You'll only see extra messages when the kerel hits a BUG() or a WARN(). If you don't see anything more verbose with all these options enabled, then the kernel is not detecting any problems. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] Group and resource assignments for TWL4030
Signed-off-by: Peter 'p2' De Schrijver
---
drivers/mfd/twl4030-power.c | 96 ++-
include/linux/i2c/twl4030.h | 41 ++-
2 files changed, 135 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index d9d1655..f1d416c 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -38,6 +38,8 @@ static u8 triton_next_free_address = 0x2b;
#define PHY_TO_OFF_PM_MASTER(p)(p - 0x36)
#define PHY_TO_OFF_PM_RECEIVER(p) (p - 0x5b)
+#define NUM_OF_RESOURCES 28
+
/* resource - hfclk */
#define R_HFCLKOUT_DEV_GRP PHY_TO_OFF_PM_RECEIVER(0xe6)
@@ -66,6 +68,42 @@ static u8 triton_next_free_address = 0x2b;
#define KEY_1 0xC0
#define KEY_2 0x0C
+/* resource configuration registers */
+
+#define DEVGROUP_OFFSET0
+#define TYPE_OFFSET1
+
+static int res_config_addrs[] = {
+ [RES_VAUX1] = 0x17,
+ [RES_VAUX2] = 0x1b,
+ [RES_VAUX3] = 0x1f,
+ [RES_VAUX4] = 0x23,
+ [RES_VMMC1] = 0x27,
+ [RES_VMMC2] = 0x2b,
+ [RES_VPLL1] = 0x2f,
+ [RES_VPLL2] = 0x33,
+ [RES_VSIM] = 0x37,
+ [RES_VDAC] = 0x3b,
+ [RES_VINTANA1] = 0x3f,
+ [RES_VINTANA2] = 0x43,
+ [RES_VINTDIG] = 0x47,
+ [RES_VIO] = 0x4b,
+ [RES_VDD1] = 0x55,
+ [RES_VDD2] = 0x63,
+ [RES_VUSB_1v5] = 0x71,
+ [RES_VUSB_1v8] = 0x74,
+ [RES_VUSB_3v1] = 0x77,
+ [RES_VUSBCP] = 0x7a,
+ [RES_REGEN] = 0x7f,
+ [RES_NRES_PWRON] = 0x82,
+ [RES_CLKEN] = 0x85,
+ [RES_SYSEN] = 0x88,
+ [RES_HFCLKOUT] = 0x8b,
+ [RES_32KCLKOUT] = 0x8e,
+ [RES_RESET] = 0x91,
+ [RES_Main_Ref] = 0x94,
+};
+
static int __init twl4030_write_script_byte(u8 address, u8 byte)
{
int err;
@@ -219,6 +257,53 @@ static int __init config_warmreset_sequence(u8 address)
return err;
}
+void twl4030_configure_resource(struct twl4030_resconfig *rconfig)
+{
+ int rconfig_addr;
+ u8 type;
+
+ if (rconfig->resource > NUM_OF_RESOURCES) {
+ printk(KERN_ERR
+ "TWL4030 Resource %d does not exist\n",
+ rconfig->resource);
+ return;
+ }
+
+ rconfig_addr = res_config_addrs[rconfig->resource];
+
+ /* Set resource group */
+
+ if (rconfig->devgroup >= 0)
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ rconfig->devgroup << 5,
+ rconfig_addr + DEVGROUP_OFFSET);
+
+ /* Set resource types */
+
+ if (twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER,
+ &type,
+ rconfig_addr + TYPE_OFFSET) < 0) {
+ printk(KERN_ERR
+ "TWL4030 Resource %d type could not read\n",
+ rconfig->resource);
+ return;
+ }
+
+ if (rconfig->type >= 0) {
+ type &= ~7;
+ type |= rconfig->type;
+ }
+
+ if (rconfig->type2 >= 0) {
+ type &= ~(3 << 3);
+ type |= rconfig->type2 << 3;
+ }
+
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ type, rconfig_addr + TYPE_OFFSET);
+
+}
+
static int __init load_triton_script(struct twl4030_script *tscript)
{
u8 address = triton_next_free_address;
@@ -249,6 +334,7 @@ void __init twl4030_power_init(struct twl4030_power_data
*triton2_scripts)
{
int err = 0;
int i;
+ struct twl4030_resconfig *resconfig;
err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, KEY_1,
R_PROTECT_KEY);
@@ -258,12 +344,20 @@ void __init twl4030_power_init(struct twl4030_power_data
*triton2_scripts)
printk(KERN_ERR
"TWL4030 Unable to unlock registers\n");
- for (i = 0; i < triton2_scripts->size; i++) {
+ for (i = 0; i < triton2_scripts->scripts_size; i++) {
err = load_triton_script(triton2_scripts->scripts[i]);
if (err)
break;
}
+ resconfig = triton2_scripts->resource_config;
+ if (resconfig) {
+ while (resconfig->resource) {
+ twl4030_configure_resource(resconfig);
+ resconfig++;
+ }
+ }
+
if (twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0, R_PROTECT_KEY))
printk(KERN_ERR
"TWL4030 Unable to relock registers\n");
diff --git a/include/linux/i2c/twl4030.h b/include/linux/i2c/twl4030.h
index 17bd400..efa7af1 100644
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -243,6 +243,37 @@ int twl4030_i2c_read(u8 mod_no, u8 *value, u8 reg,
unsigned
[PATCH 0/1] Group and resource assignments for TWL4030
This patch introduces support for board specific group assignments of TWL4030 resources. The resource type and type2 fields can also be specified. Peter 'p2' De Schrijver (1): Group and resource assignments for TWL4030 drivers/mfd/twl4030-power.c | 96 ++- include/linux/i2c/twl4030.h | 41 ++- 2 files changed, 135 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add new lower-latency C1 state
This patch introduces a new C state which allows MPU to go to WFI but keeps
the core domain active. This offers a much better wakeup latency (3us vs
10s of us for the current C1) at the cost of a higher power consumption.
Signed-off-by: Peter 'p2' De Schrijver
---
arch/arm/mach-omap2/cpuidle34xx.c | 121 -
1 files changed, 78 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 62fbb2e..7da2fd8 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -33,13 +34,14 @@
#ifdef CONFIG_CPU_IDLE
-#define OMAP3_MAX_STATES 7
+#define OMAP3_MAX_STATES 8
#define OMAP3_STATE_C1 1 /* C1 - MPU WFI + Core active */
-#define OMAP3_STATE_C2 2 /* C2 - MPU CSWR + Core active */
-#define OMAP3_STATE_C3 3 /* C3 - MPU OFF + Core active */
-#define OMAP3_STATE_C4 4 /* C4 - MPU RET + Core RET */
-#define OMAP3_STATE_C5 5 /* C5 - MPU OFF + Core RET */
-#define OMAP3_STATE_C6 6 /* C6 - MPU OFF + Core OFF */
+#define OMAP3_STATE_C2 2 /* C2 - MPU WFI + Core inactive */
+#define OMAP3_STATE_C3 3 /* C2 - MPU CSWR + Core inactive */
+#define OMAP3_STATE_C4 4 /* C3 - MPU OFF + Core iactive */
+#define OMAP3_STATE_C5 5 /* C4 - MPU RET + Core RET */
+#define OMAP3_STATE_C6 6 /* C5 - MPU OFF + Core RET */
+#define OMAP3_STATE_C7 7 /* C6 - MPU OFF + Core OFF */
struct omap3_processor_cx {
u8 valid;
@@ -63,6 +65,18 @@ static int omap3_idle_bm_check(void)
return 0;
}
+static int _cpuidle_allow_idle(struct powerdomain *pwrdm,
+ struct clockdomain *clkdm)
+{
+ omap2_clkdm_allow_idle(clkdm);
+}
+
+static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
+ struct clockdomain *clkdm)
+{
+ omap2_clkdm_deny_idle(clkdm);
+}
+
/**
* omap3_enter_idle - Programs OMAP3 to enter the specified state
* @dev: cpuidle device
@@ -99,9 +113,19 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
if (omap_irq_pending())
goto return_sleep_time;
+ if (cx->type == OMAP3_STATE_C1) {
+ pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
+ pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
+ }
+
/* Execute ARM wfi */
omap_sram_idle();
+ if (cx->type == OMAP3_STATE_C1) {
+ pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
+ pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
+ }
+
return_sleep_time:
getnstimeofday(&ts_postidle);
ts_idle = timespec_sub(ts_postidle, ts_preidle);
@@ -140,79 +164,90 @@ DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
/* omap3_init_power_states - Initialises the OMAP3 specific C states.
*
* Below is the desciption of each C state.
- * C1 . MPU WFI + Core active
- * C2 . MPU CSWR + Core active
- * C3 . MPU OFF + Core active
- * C4 . MPU CSWR + Core CSWR
- * C5 . MPU OFF + Core CSWR
- * C6 . MPU OFF + Core OFF
+ * C1 . MPU WFI + Core active
+ * C2 . MPU WFI + Core inactive
+ * C3 . MPU CSWR + Core inactive
+ * C4 . MPU OFF + Core inactive
+ * C5 . MPU CSWR + Core CSWR
+ * C6 . MPU OFF + Core CSWR
+ * C7 . MPU OFF + Core OFF
*/
void omap_init_power_states(void)
{
/* C1 . MPU WFI + Core active */
omap3_power_states[OMAP3_STATE_C1].valid = 1;
omap3_power_states[OMAP3_STATE_C1].type = OMAP3_STATE_C1;
- omap3_power_states[OMAP3_STATE_C1].sleep_latency = 10;
- omap3_power_states[OMAP3_STATE_C1].wakeup_latency = 10;
- omap3_power_states[OMAP3_STATE_C1].threshold = 30;
+ omap3_power_states[OMAP3_STATE_C1].sleep_latency = 2;
+ omap3_power_states[OMAP3_STATE_C1].wakeup_latency = 2;
+ omap3_power_states[OMAP3_STATE_C1].threshold = 5;
omap3_power_states[OMAP3_STATE_C1].mpu_state = PWRDM_POWER_ON;
omap3_power_states[OMAP3_STATE_C1].core_state = PWRDM_POWER_ON;
omap3_power_states[OMAP3_STATE_C1].flags = CPUIDLE_FLAG_TIME_VALID;
- /* C2 . MPU CSWR + Core active */
+ /* C2 . MPU WFI + Core inactive */
omap3_power_states[OMAP3_STATE_C2].valid = 1;
omap3_power_states[OMAP3_STATE_C2].type = OMAP3_STATE_C2;
- omap3_power_states[OMAP3_STATE_C2].sleep_latency = 50;
- omap3_power_states[OMAP3_STATE_C2].wakeup_latency = 50;
- omap3_power_states[OMAP3_STATE_C2].threshold = 300;
- omap3_power_states[OMAP3_STATE_C2].mpu_state = PWRDM_POWER_RET;
+ omap3_power_states[OMAP3_STATE_C2].sleep_latency = 10;
+ omap3_power_states[OMAP3_STATE_C2].wakeup_latency = 10;
+ omap3_power_states[OMAP3_STATE_C2].threshold = 30;
+ omap3_power_states[OMAP3_STATE_C2].mpu_state = PWRDM_POWER_ON;
omap3_power_states[OMAP3_STATE_C2].core_state = PWRDM_POWER_ON;
- omap3_power_states[OMAP
Re: [alsa-devel] [PATCH] SoC: Move headset jack registration to device initialization for SDP3430
On Thu, Mar 12, 2009 at 09:45:27PM -0500, Lopez Cruz, Misael wrote: > the card is registed. As a consequence of jack device registered > properly, the jack is detected as an input device. > Signed-off-by: Misael Lopez Cruz Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: iNAND on ZOOM2
Madhu Can you comment on your experience with EMMC. >-Original Message- >From: linux-omap-ow...@vger.kernel.org >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of >Kandasamy, ShankarGanesh >Sent: Friday, March 13, 2009 7:37 AM >To: linux-omap@vger.kernel.org >Subject: iNAND on ZOOM2 > >Hi all, >I am trying to access iNAND on ZOOM2 . I enabled MMC2 on kernel Config. Still, >i am not able to >access iNAND. , getting error -110 whilst initializing MMC >Can anyone guide me how to enable access for iNAND on MDK-II platforms ? > >mmc0: host does not support reading read-only switch. assuming write-enable. >mmc0: new high speed SD card at address a9e9 >mmcblk0: mmc0:a9e9 SD02G 1966080KiB > mmcblk0: p1 p2 >mmc1: error -110 whilst initialising MMC card >EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended > > >PS : Kernel created from latest branch of >http://git.omapzoom.org/repo/omapkernel.git > > >With Thanks & Regards , >ShankarGanesh >CSST Team-- >To unsubscribe from this list: send the line "unsubscribe linux-omap" in >the body of a message to majord...@vger.kernel.org >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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
iNAND on ZOOM2
Hi all, I am trying to access iNAND on ZOOM2 . I enabled MMC2 on kernel Config. Still, i am not able to access iNAND. , getting error -110 whilst initializing MMC Can anyone guide me how to enable access for iNAND on MDK-II platforms ? mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new high speed SD card at address a9e9 mmcblk0: mmc0:a9e9 SD02G 1966080KiB mmcblk0: p1 p2 mmc1: error -110 whilst initialising MMC card EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended PS : Kernel created from latest branch of http://git.omapzoom.org/repo/omapkernel.git With Thanks & Regards , ShankarGanesh CSST Team-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Regarding OMAP-3430 LCD Display
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Sabine Käß > Sent: Friday, March 13, 2009 1:50 PM > To: linux-omap@vger.kernel.org > Subject: Re: Regarding OMAP-3430 LCD Display > I have a similar problem which I won't explicate here because this list is > for > Linux on OMAP ;-) ... but can you tell me, WHO I may ask something about > programming the OMAP without operating system?? > Please contact your technical representative within TI for the same. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regarding OMAP-3430 LCD Display
Iqbal ti.com> writes: > > > Debadatta.Mishra aricent.com > > > > Hi All, > > > > I am having a OMAP-3430 board.I want to test that the LCD is > > working or not. It doesn't have any OS ported on it. Please > > Guide me to display a JPEG image on that LCD. > > This list is only for linux OS on OMAP, may be you will have talk to a different team with in TI. > > > Regards, > > Deba Hello, I have a similar problem which I won't explicate here because this list is for Linux on OMAP ;-) ... but can you tell me, WHO I may ask something about programming the OMAP without operating system?? Thanks & Best regards, Sabine -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add new C state
On Tue, Mar 10, 2009 at 6:01 PM, Peter 'p2' De Schrijver wrote: > This patch introduces a new C state which allows MPU to go to WFI but keeps > the core domain active. This offers a much better wakeup latency (3us vs > 10s of us for the current C1) at the cost of a higher power consumption. > > Signed-off-by: Peter 'p2' De Schrijver > --- > arch/arm/mach-omap2/cpuidle34xx.c | 119 +++- > 1 files changed, 76 insertions(+), 43 deletions(-) > > diff --git a/arch/arm/mach-omap2/cpuidle34xx.c > b/arch/arm/mach-omap2/cpuidle34xx.c > index 62fbb2e..5565aa7 100644 > --- a/arch/arm/mach-omap2/cpuidle34xx.c > +++ b/arch/arm/mach-omap2/cpuidle34xx.c > @@ -26,6 +26,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -33,13 +34,14 @@ > > #ifdef CONFIG_CPU_IDLE > > -#define OMAP3_MAX_STATES 7 > +#define OMAP3_MAX_STATES 8 > #define OMAP3_STATE_C1 1 /* C1 - MPU WFI + Core active */ > -#define OMAP3_STATE_C2 2 /* C2 - MPU CSWR + Core active */ > -#define OMAP3_STATE_C3 3 /* C3 - MPU OFF + Core active */ > -#define OMAP3_STATE_C4 4 /* C4 - MPU RET + Core RET */ > -#define OMAP3_STATE_C5 5 /* C5 - MPU OFF + Core RET */ > -#define OMAP3_STATE_C6 6 /* C6 - MPU OFF + Core OFF */ > +#define OMAP3_STATE_C2 2 /* C2 - MPU WFI + Core inactive */ > +#define OMAP3_STATE_C3 3 /* C2 - MPU CSWR + Core inactive */ > +#define OMAP3_STATE_C4 4 /* C3 - MPU OFF + Core iactive */ > +#define OMAP3_STATE_C5 5 /* C4 - MPU RET + Core RET */ > +#define OMAP3_STATE_C6 6 /* C5 - MPU OFF + Core RET */ > +#define OMAP3_STATE_C7 7 /* C6 - MPU OFF + Core OFF */ Comments don't match the defines here. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/10] OMAP: HSMMC: Fix MMC3 dma
From 6cdb22ab764bf852097674c26d521d3e8a1e5581 Mon Sep 17 00:00:00 2001
From: Grazvydas Ignotas
Date: Sat, 3 Jan 2009 10:36:13 +
Subject: [PATCH] OMAP: HSMMC: Fix MMC3 dma
Data transfers on third OMAP3 MMC controller don't work
because DMA line numbers are only defined for MMC1 and MMC2.
Fix that and store line numbers in mmc_omap_host structure
to reduce code size.
Tested on OMAP3 pandora board.
Signed-off-by: Grazvydas Ignotas
---
This time with Grazvydas Ignotas email address fixed.
drivers/mmc/host/omap_hsmmc.c | 36 +---
1 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 0e47073..91381f4 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -100,6 +100,7 @@
*/
#define OMAP_MMC1_DEVID 0
#define OMAP_MMC2_DEVID 1
+#define OMAP_MMC3_DEVID2
#define MMC_TIMEOUT_MS 20
#define OMAP_MMC_MASTER_CLOCK 9600
@@ -147,6 +148,7 @@ struct mmc_omap_host {
int irq;
int carddetect;
int use_dma, dma_ch;
+ int dma_line_tx, dma_line_rx;
int slot_id;
int dbclk_enabled;
int response_busy;
@@ -652,17 +654,10 @@ static int mmc_omap_get_dma_sync_dev(struct mmc_omap_host
*host,
{
int sync_dev;
- if (data->flags & MMC_DATA_WRITE) {
- if (host->id == OMAP_MMC1_DEVID)
- sync_dev = OMAP24XX_DMA_MMC1_TX;
- else
- sync_dev = OMAP24XX_DMA_MMC2_TX;
- } else {
- if (host->id == OMAP_MMC1_DEVID)
- sync_dev = OMAP24XX_DMA_MMC1_RX;
- else
- sync_dev = OMAP24XX_DMA_MMC2_RX;
- }
+ if (data->flags & MMC_DATA_WRITE)
+ sync_dev = host->dma_line_tx;
+ else
+ sync_dev = host->dma_line_rx;
return sync_dev;
}
@@ -1134,6 +1129,25 @@ static int __init omap_mmc_probe(struct platform_device
*pdev)
omap_hsmmc_init(host);
+ /* Select DMA lines */
+ switch (host->id) {
+ case OMAP_MMC1_DEVID:
+ host->dma_line_tx = OMAP24XX_DMA_MMC1_TX;
+ host->dma_line_rx = OMAP24XX_DMA_MMC1_RX;
+ break;
+ case OMAP_MMC2_DEVID:
+ host->dma_line_tx = OMAP24XX_DMA_MMC2_TX;
+ host->dma_line_rx = OMAP24XX_DMA_MMC2_RX;
+ break;
+ case OMAP_MMC3_DEVID:
+ host->dma_line_tx = OMAP34XX_DMA_MMC3_TX;
+ host->dma_line_rx = OMAP34XX_DMA_MMC3_RX;
+ break;
+ default:
+ dev_err(mmc_dev(host->mmc), "Invalid MMC id\n");
+ goto err_irq;
+ }
+
/* Request IRQ for MMC operations */
ret = request_irq(host->irq, mmc_omap_irq, IRQF_DISABLED,
mmc_hostname(mmc), host);
--
1.5.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Bridge issue #3! dma_alloc_coherent causing crash - pm branch
Kevin, > -Original Message- > From: Menon, Nishanth > Sent: Friday, March 13, 2009 1:35 PM > To: Kevin Hilman > Cc: linux-omap@vger.kernel.org; Gupta, Ramesh > Subject: RE: Bridge issue #3! dma_alloc_coherent causing > crash - pm branch > > > -Original Message- > > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > > Sent: Friday, March 13, 2009 2:35 AM > > > > Sounds like a memory leak in the bridge driver to me. I > suggest you > > enable memory leak debugging. In Kconfig > > > >Kernel Hacking --> Kernel debugging > > > > Enable 'Debug slab memory allocations' and its child 'Memory leak > > debugging'. > > > > Or, you could switch to the SLUB allocator which has some more > > flexible debug options which can be controlled at boot-time > from the cmdline. > > > > While you are in the Kernel debugging menu, make sure you enable > > 'Verbose BUG()' and 'Verbose kernel errors'. This will ensure that > > any memory leaks will be dumped with some extra debug output. I enabled all the above options, do I need to add some boot options to enable Debug messages? I am not seeing any debug information displayed in the cosole by default. Looks like I am mising some thing :( . Any comments? Thanks Ramesh Gupta G -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suspend/Resume support with Omap2fb
On Fri, 2009-03-13 at 10:17 +0100, ext Hiremath, Vaibhav wrote: > > > > Hi, > > > > > > > > On Thu, 2009-03-12 at 19:26 +0100, ext Hiremath, Vaibhav wrote: > > > > > Hi, > > > > > > > > > > Finally I could able to find the root-cause, actually some of > > the > > > > previous observations miss-led me to dig into power management, > > > > suspend/resume path and clock structure. But after bit debugging > > and > > > > with the help of Sanjeev, we got the rid of it. > > > > > > > > > > The issue is with DSS2 library, inside function > > > > "dpi_display_suspend". It calls dispc_enable_lcd_out(0), but > > doesn't > > > > wait till the frame-done interrupt. And due to this I was > > getting > > > > some abrupt behavior in suspend/resume path. > > > > > Actually in the beginning I overlooked legacy frame-buffer > > driver, > > > > which handles this scenario perfectly. > > > > > > > > dispc_enable_lcd_out(0) waits for FRAMEDONE. Please use the > > latest > > > > DSS2 > > > > version from my git repository =). > > > > > > > [Hiremath, Vaibhav] Ohhh great, but I think yesterday only I > > pulled changes from your repository, and it was not there. > > > > > > Ok, but it's great that you merged the change. > > > > No, it's been there for quite a while... (weeks, months, I don't > > remember). > > > [Hiremath, Vaibhav] May be I looked into wrong branch, can you please provide > in which branch of yours the change is? So that I can validate my changes and > make it more close to yours, it will be easy for me to migrate in the future. All the latest DSS2 stuff is in the master branch. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suspend/Resume support with Omap2fb
Thanks, Vaibhav Hiremath > -Original Message- > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > Sent: Friday, March 13, 2009 2:44 PM > To: Hiremath, Vaibhav > Cc: linux-omap@vger.kernel.org > Subject: RE: Suspend/Resume support with Omap2fb > > On Fri, 2009-03-13 at 10:10 +0100, ext Hiremath, Vaibhav wrote: > > > > Thanks, > > Vaibhav Hiremath > > > > > -Original Message- > > > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > > > Sent: Friday, March 13, 2009 2:01 PM > > > To: Hiremath, Vaibhav > > > Cc: linux-omap@vger.kernel.org > > > Subject: RE: Suspend/Resume support with Omap2fb > > > > > > Hi, > > > > > > On Thu, 2009-03-12 at 19:26 +0100, ext Hiremath, Vaibhav wrote: > > > > Hi, > > > > > > > > Finally I could able to find the root-cause, actually some of > the > > > previous observations miss-led me to dig into power management, > > > suspend/resume path and clock structure. But after bit debugging > and > > > with the help of Sanjeev, we got the rid of it. > > > > > > > > The issue is with DSS2 library, inside function > > > "dpi_display_suspend". It calls dispc_enable_lcd_out(0), but > doesn't > > > wait till the frame-done interrupt. And due to this I was > getting > > > some abrupt behavior in suspend/resume path. > > > > Actually in the beginning I overlooked legacy frame-buffer > driver, > > > which handles this scenario perfectly. > > > > > > dispc_enable_lcd_out(0) waits for FRAMEDONE. Please use the > latest > > > DSS2 > > > version from my git repository =). > > > > > [Hiremath, Vaibhav] Ohhh great, but I think yesterday only I > pulled changes from your repository, and it was not there. > > > > Ok, but it's great that you merged the change. > > No, it's been there for quite a while... (weeks, months, I don't > remember). > [Hiremath, Vaibhav] May be I looked into wrong branch, can you please provide in which branch of yours the change is? So that I can validate my changes and make it more close to yours, it will be easy for me to migrate in the future. > Tomi > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suspend/Resume support with Omap2fb
On Fri, 2009-03-13 at 10:10 +0100, ext Hiremath, Vaibhav wrote: > > Thanks, > Vaibhav Hiremath > > > -Original Message- > > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > > Sent: Friday, March 13, 2009 2:01 PM > > To: Hiremath, Vaibhav > > Cc: linux-omap@vger.kernel.org > > Subject: RE: Suspend/Resume support with Omap2fb > > > > Hi, > > > > On Thu, 2009-03-12 at 19:26 +0100, ext Hiremath, Vaibhav wrote: > > > Hi, > > > > > > Finally I could able to find the root-cause, actually some of the > > previous observations miss-led me to dig into power management, > > suspend/resume path and clock structure. But after bit debugging and > > with the help of Sanjeev, we got the rid of it. > > > > > > The issue is with DSS2 library, inside function > > "dpi_display_suspend". It calls dispc_enable_lcd_out(0), but doesn't > > wait till the frame-done interrupt. And due to this I was getting > > some abrupt behavior in suspend/resume path. > > > Actually in the beginning I overlooked legacy frame-buffer driver, > > which handles this scenario perfectly. > > > > dispc_enable_lcd_out(0) waits for FRAMEDONE. Please use the latest > > DSS2 > > version from my git repository =). > > > [Hiremath, Vaibhav] Ohhh great, but I think yesterday only I pulled changes > from your repository, and it was not there. > > Ok, but it's great that you merged the change. No, it's been there for quite a while... (weeks, months, I don't remember). Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suspend/Resume support with Omap2fb
Thanks,
Vaibhav Hiremath
> -Original Message-
> From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
> Sent: Friday, March 13, 2009 2:01 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org
> Subject: RE: Suspend/Resume support with Omap2fb
>
> Hi,
>
> On Thu, 2009-03-12 at 19:26 +0100, ext Hiremath, Vaibhav wrote:
> > Hi,
> >
> > Finally I could able to find the root-cause, actually some of the
> previous observations miss-led me to dig into power management,
> suspend/resume path and clock structure. But after bit debugging and
> with the help of Sanjeev, we got the rid of it.
> >
> > The issue is with DSS2 library, inside function
> "dpi_display_suspend". It calls dispc_enable_lcd_out(0), but doesn't
> wait till the frame-done interrupt. And due to this I was getting
> some abrupt behavior in suspend/resume path.
> > Actually in the beginning I overlooked legacy frame-buffer driver,
> which handles this scenario perfectly.
>
> dispc_enable_lcd_out(0) waits for FRAMEDONE. Please use the latest
> DSS2
> version from my git repository =).
>
[Hiremath, Vaibhav] Ohhh great, but I think yesterday only I pulled changes
from your repository, and it was not there.
Ok, but it's great that you merged the change.
> Tomi
>
> >
> > For Display sub-system we have 2 interface clocks coming, L3_ICLK
> and L4_ICLK. Out of these, L4_ICLK goes to Display register access
> and L3_ICLK goes to DMA register. In our suspend call we are
> disabling clocks for L3_ICLK (we don't control L4_ICLK), and due to
> this L4_ICLK stays attached with GFX. You will only be able to find
> out this by looking to CM_CLKSTST_DSS.CLKACTIVITY_DSS, which is set
> 1 and indicates some interface clock is still active in DSS domain.
> >
> > Below is the patch which will explain the change
> >
> >
> > +#include
> > +#include
> >
> > +static void dpi_display_isr(void *arg, unsigned int irqstatus)
> > +{
> > + struct omap_display *display = (struct omap_display *)arg;
> > +
> > + complete(&display->frame_done);
> > +}
> >
> > static int dpi_display_suspend(struct omap_display *display)
> > {
> > + void *handle = NULL;
> > +
> > if (display->state != OMAP_DSS_DISPLAY_ACTIVE)
> > return -EINVAL;
> >
> > if (display->panel->suspend)
> > display->panel->suspend(display);
> >
> > + /*
> > +* Wait for frame done interrupt
> > +*/
> > + handle = omap_dispc_register_isr(dpi_display_isr, display,
> > + DISPC_IRQ_FRAMEDONE);
> > + if (!handle)
> > + return -EINVAL;
> > +
> > + init_completion(&display->frame_done);
> > +
> > dispc_enable_lcd_out(0);
> > + if (!wait_for_completion_timeout(&display->frame_done,
> > + msecs_to_jiffies(500))) {
> > + printk("timeout waiting for FRAME DONE\n");
> > + }
> >
> > Still I need to test this thoroughly, I may hit some another issue
> (Already I am seeing some crashes also when off state is enabled). I
> will create consolidated patch for this and will submit to list.
> >
> > Thanks,
> > Vaibhav Hiremath
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suspend/Resume support with Omap2fb
Hi,
On Thu, 2009-03-12 at 19:26 +0100, ext Hiremath, Vaibhav wrote:
> Hi,
>
> Finally I could able to find the root-cause, actually some of the previous
> observations miss-led me to dig into power management, suspend/resume path
> and clock structure. But after bit debugging and with the help of Sanjeev, we
> got the rid of it.
>
> The issue is with DSS2 library, inside function "dpi_display_suspend". It
> calls dispc_enable_lcd_out(0), but doesn't wait till the frame-done
> interrupt. And due to this I was getting some abrupt behavior in
> suspend/resume path.
> Actually in the beginning I overlooked legacy frame-buffer driver, which
> handles this scenario perfectly.
dispc_enable_lcd_out(0) waits for FRAMEDONE. Please use the latest DSS2
version from my git repository =).
Tomi
>
> For Display sub-system we have 2 interface clocks coming, L3_ICLK and
> L4_ICLK. Out of these, L4_ICLK goes to Display register access and L3_ICLK
> goes to DMA register. In our suspend call we are disabling clocks for L3_ICLK
> (we don't control L4_ICLK), and due to this L4_ICLK stays attached with GFX.
> You will only be able to find out this by looking to
> CM_CLKSTST_DSS.CLKACTIVITY_DSS, which is set 1 and indicates some interface
> clock is still active in DSS domain.
>
> Below is the patch which will explain the change
>
>
> +#include
> +#include
>
> +static void dpi_display_isr(void *arg, unsigned int irqstatus)
> +{
> + struct omap_display *display = (struct omap_display *)arg;
> +
> + complete(&display->frame_done);
> +}
>
> static int dpi_display_suspend(struct omap_display *display)
> {
> + void *handle = NULL;
> +
> if (display->state != OMAP_DSS_DISPLAY_ACTIVE)
> return -EINVAL;
>
> if (display->panel->suspend)
> display->panel->suspend(display);
>
> + /*
> +* Wait for frame done interrupt
> +*/
> + handle = omap_dispc_register_isr(dpi_display_isr, display,
> + DISPC_IRQ_FRAMEDONE);
> + if (!handle)
> + return -EINVAL;
> +
> + init_completion(&display->frame_done);
> +
> dispc_enable_lcd_out(0);
> + if (!wait_for_completion_timeout(&display->frame_done,
> + msecs_to_jiffies(500))) {
> + printk("timeout waiting for FRAME DONE\n");
> + }
>
> Still I need to test this thoroughly, I may hit some another issue (Already I
> am seeing some crashes also when off state is enabled). I will create
> consolidated patch for this and will submit to list.
>
> Thanks,
> Vaibhav Hiremath
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Bridge issue #3! dma_alloc_coherent causing crash - pm branch
> -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Friday, March 13, 2009 2:35 AM > Sounds like a memory leak in the bridge driver to me. I suggest you > enable memory leak debugging. In Kconfig > >Kernel Hacking --> Kernel debugging > > Enable 'Debug slab memory allocations' and its child 'Memory leak > debugging'. > > Or, you could switch to the SLUB allocator which has some more flexible > debug options which can be controlled at boot-time from the cmdline. > > While you are in the Kernel debugging menu, make sure you enable > 'Verbose BUG()' and 'Verbose kernel errors'. This will ensure that > any memory leaks will be dumped with some extra debug output. Thanks. Yep, it does sound like a mem leak... will keep the list posted as we progress. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
