Re: [PATCH] omap: boards w/ wl12xx should select REGULATOR_FIXED_VOLTAGE
Hi Tony, On Wed, Nov 24, 2010 at 12:04 PM, Ohad Ben-Cohen wrote: > Power to the wl12xx wlan device is controlled by a fixed regulator. > > Boards that have the wl12xx should select REGULATOR_FIXED_VOLTAGE so > users will not be baffled. Not sure if you picked this up ? We need it because otherwise new wl12xx users can spend many hours until they figure out what's the problem.. Please tell me if there's any problem with this one. Thanks, Ohad. > > Signed-off-by: Ohad Ben-Cohen > --- > arch/arm/mach-omap2/Kconfig | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index fc3a181..cc386da 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -190,6 +190,7 @@ config MACH_OMAP3_PANDORA > depends on ARCH_OMAP3 > default y > select OMAP_PACKAGE_CBB > + select REGULATOR_FIXED_VOLTAGE > > config MACH_OMAP3_TOUCHBOOK > bool "OMAP3 Touch Book" > @@ -235,6 +236,7 @@ config MACH_OMAP_ZOOM2 > select SERIAL_8250 > select SERIAL_CORE_CONSOLE > select SERIAL_8250_CONSOLE > + select REGULATOR_FIXED_VOLTAGE > > config MACH_OMAP_ZOOM3 > bool "OMAP3630 Zoom3 board" > @@ -244,6 +246,7 @@ config MACH_OMAP_ZOOM3 > select SERIAL_8250 > select SERIAL_CORE_CONSOLE > select SERIAL_8250_CONSOLE > + select REGULATOR_FIXED_VOLTAGE > > config MACH_CM_T35 > bool "CompuLab CM-T35 module" > -- > 1.7.0.4 > > -- 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 v4 0/5] omap: mailbox: hwmod support
Tested on 3430, based of pm-core branch. Patches affecting mailbox code may require rebase once the mailbox git pull is made. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39719.html ** v4 ** - Merged device latency info with previous patch in series. - Removed usage of omap_device_enable_clocks and replaced for omap_device_[enable|disable]_hwmods to handle sysc setup and clocks. - Fixed pm_runtime usage by adding its enable/disable functions, and now handling sysc register with it, because of changes in device latency functions. - For pm_runtime, instead of adding a global variable to make use of pdev->dev, use 'parent' inside of 'dev' returned by device_create and which is stored inside omap_mbox struct, in future cleanup consider cleaning omap_mbox struct. ** v3 ** - Taken mailbox hwmod as is from Benoit original branch. - Put back numbers for irq, addresses instead of considering them as magic numbers. - Follow the declaration layout for omap4 hwmods. - Using pm_runtime to enable the clocks. ** v2 ** - Added omap4 hwmod support. - Moved "mailbox_ick" from hwmod to hwmod_if (omap 2/3) - Declared sysc classes for omap 2/3 ** v1 ** 1. omap: mailbox: initial hwmod support for omap3 Changes were made to: - Rebase to latest code. - Detect the hwmod by filling prcm union for omap2, without this it was unable to build the hwmod at runtime. - Replace magic number for defines. - Use ioremap again instead of relying on the one made by hwmod, as noted in http://patchwork.kernel.org/patch/101661/ 2. omap: mailbox: initial hwmod support for omap2 Was only compiled tested!! Unfortunately I don't have the HW for it. Benoit Cousson (1): OMAP4: hwmod data: add mailbox data Felipe Contreras (2): OMAP3: hwmod data: add mailbox data OMAP: mailbox: build device using omap_device/omap_hwmod Omar Ramirez Luna (1): OMAP: mailbox: use runtime pm for clk and sysc handling omar ramirez (1): OMAP2: hwmod data: add mailbox data arch/arm/mach-omap2/devices.c | 102 ++-- arch/arm/mach-omap2/mailbox.c | 27 ++-- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 73 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 72 +++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 71 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 67 ++ 6 files changed, 308 insertions(+), 104 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 v4 1/5] OMAP2: hwmod data: add mailbox data
From: omar ramirez
Mailbox hwmod data for omap2430 and 2420.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 73
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 72 +++
2 files changed, 145 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index ce5d890..64f8f8b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -778,6 +778,76 @@ static struct omap_hwmod omap2420_gpio4_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap2420_gpio4_slaves),
.class = &omap242x_gpio_hwmod_class,
.dev_attr = &gpio_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+};
+
+/*
+ * 'mailbox' class
+ * mailbox module allowing communication between the on-chip processors
+ * using a queued mailbox-interrupt mechanism.
+ */
+
+static struct omap_hwmod_class_sysconfig omap2420_mailbox_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_mailbox_hwmod_class = {
+ .name = "mailbox",
+ .sysc = &omap2420_mailbox_sysc,
+};
+
+/* mailbox */
+static struct omap_hwmod omap2420_mailbox_hwmod;
+static struct omap_hwmod_irq_info omap2420_mailbox_irqs[] = {
+ { .name = "dsp", .irq = 26, },
+ { .name = "iva", .irq = 34, },
+};
+
+static struct omap_hwmod_addr_space omap2420_mailbox_addrs[] = {
+ {
+ .pa_start = 0x48094000,
+ .pa_end = 0x480941ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+/* l4_core -> mailbox */
+static struct omap_hwmod_ocp_if omap2420_l4_core__mailbox = {
+ .master = &omap2420_l4_core_hwmod,
+ .slave = &omap2420_mailbox_hwmod,
+ .clk= "mailboxes_ick",
+ .addr = omap2420_mailbox_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_mailbox_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mailbox slave ports */
+static struct omap_hwmod_ocp_if *omap2420_mailbox_slaves[] = {
+ &omap2420_l4_core__mailbox,
+};
+
+static struct omap_hwmod omap2420_mailbox_hwmod = {
+ .name = "mailbox",
+ .class = &omap2420_mailbox_hwmod_class,
+ .mpu_irqs = omap2420_mailbox_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_mailbox_irqs),
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_MAILBOXES_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_MAILBOXES_SHIFT,
+ },
+ },
+ .slaves = omap2420_mailbox_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_mailbox_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
};
@@ -799,6 +869,9 @@ static __initdata struct omap_hwmod *omap2420_hwmods[] = {
&omap2420_gpio2_hwmod,
&omap2420_gpio3_hwmod,
&omap2420_gpio4_hwmod,
+
+ /* mailbox class */
+ &omap2420_mailbox_hwmod,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 0f87736..939af19 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -839,6 +839,75 @@ static struct omap_hwmod omap2430_gpio5_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap2430_gpio5_slaves),
.class = &omap243x_gpio_hwmod_class,
.dev_attr = &gpio_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+};
+
+/*
+ * 'mailbox' class
+ * mailbox module allowing communication between the on-chip processors
+ * using a queued mailbox-interrupt mechanism.
+ */
+
+static struct omap_hwmod_class_sysconfig omap2430_mailbox_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_mailbox_hwmod_class = {
+ .name = "mailbox",
+ .sysc = &omap2430_mailbox_sysc,
+};
+
+/* mailbox */
+static struct omap_hwmod omap2430_mailbox_hwmod;
+static struct omap_hwmod_irq_info omap2430_mailbox_irqs[] = {
+ { .name = "dsp
[PATCH v4 3/5] OMAP4: hwmod data: add mailbox data
From: Benoit Cousson
Mailbox hwmod data for omap4.
Signed-off-by: Benoit Cousson
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 67
1 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7367648..f14b01c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1740,6 +1740,70 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'mailbox' class
+ * mailbox module allowing communication between the on-chip processors
+ * using a queued mailbox-interrupt mechanism.
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_mailbox_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_mailbox_hwmod_class = {
+ .name = "mailbox",
+ .sysc = &omap44xx_mailbox_sysc,
+};
+
+/* mailbox */
+static struct omap_hwmod omap44xx_mailbox_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mailbox_irqs[] = {
+ { .name = "mbox", .irq = 26 + OMAP44XX_IRQ_GIC_START, },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mailbox_addrs[] = {
+ {
+ .pa_start = 0x4a0f4000,
+ .pa_end = 0x4a0f41ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+/* l4_cfg -> mailbox */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__mailbox = {
+ .master = &omap44xx_l4_cfg_hwmod,
+ .slave = &omap44xx_mailbox_hwmod,
+ .clk= "l4_div_ck",
+ .addr = omap44xx_mailbox_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_mailbox_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mailbox slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_mailbox_slaves[] = {
+ &omap44xx_l4_cfg__mailbox,
+};
+
+static struct omap_hwmod omap44xx_mailbox_hwmod = {
+ .name = "mailbox",
+ .class = &omap44xx_mailbox_hwmod_class,
+ .mpu_irqs = omap44xx_mailbox_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_mailbox_irqs),
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L4CFG_MAILBOX_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_mailbox_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_mailbox_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
&omap44xx_dmm_hwmod,
@@ -1798,6 +1862,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
&omap44xx_wd_timer2_hwmod,
&omap44xx_wd_timer3_hwmod,
+ /* mailbox class */
+ &omap44xx_mailbox_hwmod,
+
NULL,
};
--
1.7.1
--
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 v4 2/5] OMAP3: hwmod data: add mailbox data
From: Felipe Contreras
Mailbox hwmod data for omap3.
Signed-off-by: Felipe Contreras
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 71
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 8eb81b4..9ce347e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1089,6 +1089,74 @@ static struct omap_hwmod omap3xxx_gpio6_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap3xxx_gpio6_slaves),
.class = &omap3xxx_gpio_hwmod_class,
.dev_attr = &gpio_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+/*
+ * 'mailbox' class
+ * mailbox module allowing communication between the on-chip processors
+ * using a queued mailbox-interrupt mechanism.
+ */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_mailbox_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_mailbox_hwmod_class = {
+ .name = "mailbox",
+ .sysc = &omap3xxx_mailbox_sysc,
+};
+
+static struct omap_hwmod omap3xxx_mailbox_hwmod;
+static struct omap_hwmod_irq_info omap3xxx_mailbox_irqs[] = {
+ { .name = "dsp", .irq = 26, },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_mailbox_addrs[] = {
+ {
+ .pa_start = 0x48094000,
+ .pa_end = 0x480941ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+/* l4_core -> mailbox */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__mailbox = {
+ .master = &omap3xxx_l4_core_hwmod,
+ .slave = &omap3xxx_mailbox_hwmod,
+ .clk= "mailboxes_ick",
+ .addr = omap3xxx_mailbox_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_mailbox_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mailbox slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_mailbox_slaves[] = {
+ &omap3xxx_l4_core__mailbox,
+};
+
+static struct omap_hwmod omap3xxx_mailbox_hwmod = {
+ .name = "mailbox",
+ .class = &omap3xxx_mailbox_hwmod_class,
+ .mpu_irqs = omap3xxx_mailbox_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_mailbox_irqs),
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP3430_EN_MAILBOXES_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP3430_ST_MAILBOXES_SHIFT,
+ },
+ },
+ .slaves = omap3xxx_mailbox_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_mailbox_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
@@ -1115,6 +1183,9 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_gpio4_hwmod,
&omap3xxx_gpio5_hwmod,
&omap3xxx_gpio6_hwmod,
+
+ /* mailbox class */
+ &omap3xxx_mailbox_hwmod,
NULL,
};
--
1.7.1
--
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 v4 5/5] OMAP: mailbox: use runtime pm for clk and sysc handling
Use runtime pm APIs to enable/disable mailbox clocks and
to configure SYSC register.
Based on the patch sent by Felipe Contreras:
https://patchwork.kernel.org/patch/101662/
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/mailbox.c | 27 +--
1 files changed, 5 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 40ddeca..f5f72ba 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -34,12 +35,8 @@
#define MAILBOX_IRQ_NOTFULL(m) (1 << (2 * (m) + 1))
/* SYSCONFIG: register bit definition */
-#define AUTOIDLE (1 << 0)
#define SOFTRESET (1 << 1)
-#define SMARTIDLE (2 << 3)
#define OMAP4_SOFTRESET(1 << 0)
-#define OMAP4_NOIDLE (1 << 2)
-#define OMAP4_SMARTIDLE(2 << 2)
/* SYSSTATUS: register bit definition */
#define RESETDONE (1 << 0)
@@ -70,8 +67,6 @@ struct omap_mbox2_priv {
unsigned long irqdisable;
};
-static struct clk *mbox_ick_handle;
-
static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
omap_mbox_type_t irq);
@@ -91,13 +86,8 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
u32 l;
unsigned long timeout;
- mbox_ick_handle = clk_get(NULL, "mailboxes_ick");
- if (IS_ERR(mbox_ick_handle)) {
- printk(KERN_ERR "Could not get mailboxes_ick: %ld\n",
- PTR_ERR(mbox_ick_handle));
- return PTR_ERR(mbox_ick_handle);
- }
- clk_enable(mbox_ick_handle);
+ pm_runtime_enable(mbox->dev->parent);
+ pm_runtime_get_sync(mbox->dev->parent);
if (cpu_is_omap44xx()) {
mbox_write_reg(OMAP4_SOFTRESET, MAILBOX_SYSCONFIG);
@@ -130,12 +120,6 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
l = mbox_read_reg(MAILBOX_REVISION);
pr_debug("omap mailbox rev %d.%d\n", (l & 0xf0) >> 4, (l & 0x0f));
- if (cpu_is_omap44xx())
- l = OMAP4_SMARTIDLE;
- else
- l = SMARTIDLE | AUTOIDLE;
- mbox_write_reg(l, MAILBOX_SYSCONFIG);
-
omap2_mbox_enable_irq(mbox, IRQ_RX);
return 0;
@@ -143,9 +127,8 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
static void omap2_mbox_shutdown(struct omap_mbox *mbox)
{
- clk_disable(mbox_ick_handle);
- clk_put(mbox_ick_handle);
- mbox_ick_handle = NULL;
+ pm_runtime_put_sync(mbox->dev->parent);
+ pm_runtime_disable(mbox->dev->parent);
}
/* Mailbox FIFO handle functions */
--
1.7.1
--
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 v4 4/5] OMAP: mailbox: build device using omap_device/omap_hwmod
From: Felipe Contreras
Remove static platform_device and resource data within
omap mailbox driver; use the one defined in the hwmod
database along with omap_device framework for device
build and registration.
Add device latency functions to be used, so clock can be
enabled and sysconfig is configured.
Signed-off-by: Felipe Contreras
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/devices.c | 102 -
1 files changed, 20 insertions(+), 82 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index b5cafd3..7493c30 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -142,95 +142,33 @@ static inline void omap_init_camera(void)
#endif
#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
-
-#define MBOX_REG_SIZE 0x120
-
-#ifdef CONFIG_ARCH_OMAP2
-static struct resource omap2_mbox_resources[] = {
- {
- .start = OMAP24XX_MAILBOX_BASE,
- .end= OMAP24XX_MAILBOX_BASE + MBOX_REG_SIZE - 1,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = INT_24XX_MAIL_U0_MPU,
- .flags = IORESOURCE_IRQ,
- .name = "dsp",
- },
- {
- .start = INT_24XX_MAIL_U3_MPU,
- .flags = IORESOURCE_IRQ,
- .name = "iva",
- },
-};
-static int omap2_mbox_resources_sz = ARRAY_SIZE(omap2_mbox_resources);
-#else
-#define omap2_mbox_resources NULL
-#define omap2_mbox_resources_sz0
-#endif
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct resource omap3_mbox_resources[] = {
- {
- .start = OMAP34XX_MAILBOX_BASE,
- .end= OMAP34XX_MAILBOX_BASE + MBOX_REG_SIZE - 1,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = INT_24XX_MAIL_U0_MPU,
- .flags = IORESOURCE_IRQ,
- .name = "dsp",
- },
-};
-static int omap3_mbox_resources_sz = ARRAY_SIZE(omap3_mbox_resources);
-#else
-#define omap3_mbox_resources NULL
-#define omap3_mbox_resources_sz0
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-
-#define OMAP4_MBOX_REG_SIZE0x130
-static struct resource omap4_mbox_resources[] = {
- {
- .start = OMAP44XX_MAILBOX_BASE,
- .end= OMAP44XX_MAILBOX_BASE +
- OMAP4_MBOX_REG_SIZE - 1,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP44XX_IRQ_MAIL_U0,
- .flags = IORESOURCE_IRQ,
- .name = "mbox",
+static struct omap_device_pm_latency mbox_latencies[] = {
+ [0] = {
+ .activate_func = omap_device_enable_hwmods,
+ .deactivate_func = omap_device_idle_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
},
};
-static int omap4_mbox_resources_sz = ARRAY_SIZE(omap4_mbox_resources);
-#else
-#define omap4_mbox_resources NULL
-#define omap4_mbox_resources_sz0
-#endif
-
-static struct platform_device mbox_device = {
- .name = "omap-mailbox",
- .id = -1,
-};
static inline void omap_init_mbox(void)
{
- if (cpu_is_omap24xx()) {
- mbox_device.resource = omap2_mbox_resources;
- mbox_device.num_resources = omap2_mbox_resources_sz;
- } else if (cpu_is_omap34xx()) {
- mbox_device.resource = omap3_mbox_resources;
- mbox_device.num_resources = omap3_mbox_resources_sz;
- } else if (cpu_is_omap44xx()) {
- mbox_device.resource = omap4_mbox_resources;
- mbox_device.num_resources = omap4_mbox_resources_sz;
- } else {
- pr_err("%s: platform not supported\n", __func__);
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+
+ oh = omap_hwmod_lookup("mailbox");
+ if (!oh) {
+ pr_err("%s: unable to find hwmod\n", __func__);
+ return;
+ }
+
+ od = omap_device_build("omap-mailbox", -1, oh,
+ NULL, 0,
+ mbox_latencies, ARRAY_SIZE(mbox_latencies),
+ 0);
+ if (!od) {
+ pr_err("%s: could not build device\n", __func__);
return;
}
- platform_device_register(&mbox_device);
}
#else
static inline void omap_init_mbox(void) { }
--
1.7.1
--
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: pm-core broken
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Nishanth Menon > Sent: Thursday, December 16, 2010 7:57 AM > To: Kevin H; linux-omap@vger.kernel.org > Subject: pm-core broken > > Hi Kevin, > > Just fyi, I tested pm-core(no patches of mine) against SDP3430(ES3.1) > and Beagle Rev C1(ES3.0) (that is the only board I could dig up): both > fail - I think basically <3630 is broken atm!. > [Hiremath, Vaibhav] Nishant, I am also seeing similar behavior on OMAP3EVM (AM/DM3730), where it does fail with message "Powerdomain (core_pwrdm) didn't enter target state 0". But somehow I am not seeing issues with DSS power domain, not sure what could be happening. Thanks, Vaibhav > Beagleboard: > with omap2plus_defconfig + MLO, u-boot.bin from > http://www.angstrom-distribution.org/demo/beagleboard/ > filesystem is a minimal busybox that I had built and init=/bin/sh to > prevent any other apps running in the background - I use the same on > SDP3630 and 3430 platforms. > > branch: pm-core (from your tree). > defconfig: omap2plus_defconfig - no changes other than disable RM680 > board - currently causes a build failure. > > test script - same one I had send to ML earlier today > replica here: http://pastebin.mozilla.org/889933 > > log: > # ./suspend-idle.sh > > mount: no /proc/mounts > > [ 12.493682] PM: Syncing filesystems ... done. > > [ 12.749114] Freezing user space processes ... (elapsed 0.01 seconds) > done. > [ 12.774780] Freezing remaining freezable tasks ... (elapsed 0.02 > seconds) don > e. > > [ 12.807891] Suspending console(s) (use no_console_suspend to debug) > > [ 12.930480] PM: suspend of devices complete after 111.450 msecs > > [ 12.933990] omap_device: i2c_omap.1: new worst case deactivate > latency 0: 152 > 587 > > [ 12.934234] PM: late suspend of devices complete after 3.692 msecs > > [ 12.934295] Disabling non-boot CPUs ... > > [ 12.934906] PM: Resume timer in 5.000 secs (163840 ticks at 32768 > ticks/sec.) > [ 12.935119] omap_device: omap-hsuart.1: new worst case deactivate > latency 0: > 30517 > > [ 17.848388] omap_device: omap-hsuart.0: new worst case activate > latency 0: 91 > 552 > > [ 17.848541] Powerdomain (core_pwrdm) didn't enter target state 0 > > [ 17.848571] Powerdomain (dss_pwrdm) didn't enter target state 0 > > [ 17.848602] Could not enter target state in pm_suspend > > [ 17.850952] PM: early resume of devices complete after 1.983 msecs > > [ 18.238128] PM: resume of devices complete after 386.688 msecs > > [ 18.321746] Restarting tasks ... done. > > SUSPEND:OFF test | FAIL | OFF: 0->0| RET:0 ->0 (6 sec) > > [ 19.755401] PM: Syncing filesystems ... done. > > [ 19.801116] Freezing user space processes ... (elapsed 0.02 seconds) > done. > [ 19.829406] Freezing remaining freezable tasks ... (elapsed 0.02 > seconds) don > e. > > [ 19.861419] Suspending console(s) (use no_console_suspend to debug) > > [ 19.984863] PM: suspend of devices complete after 112.487 msecs > > [ 19.988281] PM: late suspend of devices complete after 3.387 msecs > > [ 19.988311] Disabling non-boot CPUs ... > > [ 19.988616] PM: Resume timer in 5.000 secs (163840 ticks at 32768 > ticks/sec.) > [ 24.853942] Powerdomain (core_pwrdm) didn't enter target state 1 > > [ 24.853942] Powerdomain (dss_pwrdm) didn't enter target state 1 > > [ 24.853973] Could not enter target state in pm_suspend > > [ 24.855926] PM: early resume of devices complete after 1.739 msecs > > [ 25.243804] PM: resume of devices complete after 387.634 msecs > > [ 25.303649] Restarting tasks ... done. > > SUSPEND:RET test | FAIL | OFF: 0->0| RET:0 ->0 (7 sec) > > IDLE:OFF test | FAIL | OFF: 0->0| RET:0 ->0 (21 sec) > > IDLE:RET test | FAIL | OFF: 0->0| RET:0 ->0 (21 sec) > > usbhost_pwrdm > (RET),OFF:2,RET:3,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > sgx_pwrdm > (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > per_pwrdm > (ON),OFF:15,RET:22,INA:0,ON:38,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > dss_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > > cam_pwrdm > (RET),OFF:2,RET:3,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > core_pwrdm > (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-ME > MBANK2-OFF:0 > > neon_pwrdm (ON),OFF:15,RET:30,INA:0,ON:46,RET-LOGIC-OFF:0 > > mpu_pwrdm > (ON),OFF:15,RET:30,INA:0,ON:46,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 > iva2_pwrdm > (RET),OFF:2,RET:3,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-M > EMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 > > per_clkdm->per_pwrdm (9) > > usbhost_clkdm->usbhost_pwrdm (0) > > cam_clkdm->cam_pwrdm (0) > > dss_clkdm->dss_pwrdm (0) > > core_l4_clkdm->core_pwrdm (11) > > core_l3_clkdm->core_pwrdm (4) > > d2d_clkdm->core_pwrdm (0) > > sgx_clkdm->sgx_pwrdm (0) > > iva2_clkdm->iva2_pwrdm (0) > > neon_clkdm->neon_pwrdm (0) > > mpu_clkdm->mpu_pw
pm-core broken
Hi Kevin, Just fyi, I tested pm-core(no patches of mine) against SDP3430(ES3.1) and Beagle Rev C1(ES3.0) (that is the only board I could dig up): both fail - I think basically <3630 is broken atm!. Beagleboard: with omap2plus_defconfig + MLO, u-boot.bin from http://www.angstrom-distribution.org/demo/beagleboard/ filesystem is a minimal busybox that I had built and init=/bin/sh to prevent any other apps running in the background - I use the same on SDP3630 and 3430 platforms. branch: pm-core (from your tree). defconfig: omap2plus_defconfig - no changes other than disable RM680 board - currently causes a build failure. test script - same one I had send to ML earlier today replica here: http://pastebin.mozilla.org/889933 log: # ./suspend-idle.sh mount: no /proc/mounts [ 12.493682] PM: Syncing filesystems ... done. [ 12.749114] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 12.774780] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) don e. [ 12.807891] Suspending console(s) (use no_console_suspend to debug) [ 12.930480] PM: suspend of devices complete after 111.450 msecs [ 12.933990] omap_device: i2c_omap.1: new worst case deactivate latency 0: 152 587 [ 12.934234] PM: late suspend of devices complete after 3.692 msecs [ 12.934295] Disabling non-boot CPUs ... [ 12.934906] PM: Resume timer in 5.000 secs (163840 ticks at 32768 ticks/sec.) [ 12.935119] omap_device: omap-hsuart.1: new worst case deactivate latency 0: 30517 [ 17.848388] omap_device: omap-hsuart.0: new worst case activate latency 0: 91 552 [ 17.848541] Powerdomain (core_pwrdm) didn't enter target state 0 [ 17.848571] Powerdomain (dss_pwrdm) didn't enter target state 0 [ 17.848602] Could not enter target state in pm_suspend [ 17.850952] PM: early resume of devices complete after 1.983 msecs [ 18.238128] PM: resume of devices complete after 386.688 msecs [ 18.321746] Restarting tasks ... done. SUSPEND:OFF test | FAIL | OFF: 0->0| RET:0 ->0 (6 sec) [ 19.755401] PM: Syncing filesystems ... done. [ 19.801116] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 19.829406] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) don e. [ 19.861419] Suspending console(s) (use no_console_suspend to debug) [ 19.984863] PM: suspend of devices complete after 112.487 msecs [ 19.988281] PM: late suspend of devices complete after 3.387 msecs [ 19.988311] Disabling non-boot CPUs ... [ 19.988616] PM: Resume timer in 5.000 secs (163840 ticks at 32768 ticks/sec.) [ 24.853942] Powerdomain (core_pwrdm) didn't enter target state 1 [ 24.853942] Powerdomain (dss_pwrdm) didn't enter target state 1 [ 24.853973] Could not enter target state in pm_suspend [ 24.855926] PM: early resume of devices complete after 1.739 msecs [ 25.243804] PM: resume of devices complete after 387.634 msecs [ 25.303649] Restarting tasks ... done. SUSPEND:RET test | FAIL | OFF: 0->0| RET:0 ->0 (7 sec) IDLE:OFF test | FAIL | OFF: 0->0| RET:0 ->0 (21 sec) IDLE:RET test | FAIL | OFF: 0->0| RET:0 ->0 (21 sec) usbhost_pwrdm (RET),OFF:2,RET:3,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_pwrdm (ON),OFF:15,RET:22,INA:0,ON:38,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:2,RET:3,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-ME MBANK2-OFF:0 neon_pwrdm (ON),OFF:15,RET:30,INA:0,ON:46,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:15,RET:30,INA:0,ON:46,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:2,RET:3,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-M EMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 per_clkdm->per_pwrdm (9) usbhost_clkdm->usbhost_pwrdm (0) cam_clkdm->cam_pwrdm (0) dss_clkdm->dss_pwrdm (0) core_l4_clkdm->core_pwrdm (11) core_l3_clkdm->core_pwrdm (4) d2d_clkdm->core_pwrdm (0) sgx_clkdm->sgx_pwrdm (0) iva2_clkdm->iva2_pwrdm (0) neon_clkdm->neon_pwrdm (0) mpu_clkdm->mpu_pwrdm (0) prm_clkdm->wkup_pwrdm (0) cm_clkdm->core_pwrdm (0) SUSPEND:OFF test | FAIL | OFF: 0->0| RET:0 ->0 (6 sec) SUSPEND:RET test | FAIL | OFF: 0->0| RET:0 ->0 (7 sec) IDLE:OFF test | FAIL | OFF: 0->0| RET:0 ->0 (21 sec) IDLE:RET test | FAIL | OFF: 0->0| RET:0 ->0 (21 sec) # cat /sys/kernel/debug/pm_debug/registers/current MOD: CM_IVA2 (48014000) 04 => 0037 20 => 0001 34 => 0001 40 => 0009680c 44 => 0001 48 => 0003 MOD: CM_OCP (48004800) 00 => 0010 10 => 0001 MOD: CM_MPU (48004900) 04 => 0037 24 => 0001 34 => 0001 40 => 0011f40c 44 => 0001 48 => 0003 4c => 0001 MOD: CM_CORE (48004a00) 00 => 6000 10 => 0103e042 20 => 9fbd 24 => 001f 2
Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if < ES1.2
Nishanth Menon had written, on 12/15/2010 06:05 PM, the following:
Kevin Hilman had written, on 12/15/2010 05:47 PM, the following:
I agree that this additional check in sram_idle should be removed, but
as long as I handle it in omap3_pm_off_mode_enable where the next
states are configured, is'nt that enough or am I missing something?
Setting the next states only sets the default states, but CPUidle
changes them.
Looking closer at omap3_pm_off_mode_enable() though, it already calls
into CPUidle and disables the valid bit for any states that have
*either* MPU or core off.You'll probably just need to extend this
approach to disable only CORE off state(s).
Thx. it is clear now. let me see how to clean this up.
k. Does the attached look any better now :)? I have removed the check
logic from sram_idle path instead made omap3_cpuidle_update_states
little more generic, updated validity of C state based on errata. This
now disables just those C states with core OFF on 3630
in a map, this will now look as follows:
+---+---+---+---++
| MPU | Core | OFF | OFF Enable-36xx|
| Dom | Dom | +---++
C state | State | State | Dis | ES1.1 | ES 1.2 |
+---+---+---+---++
1 | ON| ON| YES | YES | YES|
2 | ON| ON| YES | YES | YES|
3 | RET | ON| YES | YES | YES|
4 | OFF | ON| NO| YES | YES|
5 | RET | RET | YES | YES | YES|
6 | OFF | RET | NO| YES | YES|
7 | OFF | OFF | NO| NO| YES|
+---+---+---+---++
--
Regards,
Nishanth Menon
>From bd3d8decf922d7425b9bc9025c7709a9414ad380 Mon Sep 17 00:00:00 2001
From: Nishanth Menon
Date: Wed, 15 Dec 2010 18:40:29 -0600
Subject: [PATCH 1/2] OMAP3: PM: make omap3_cpuidle_update_states independent of enable_off_mode
Currently omap3_cpuidle_update_states makes whole sale decision
on which C states to update based on enable_off_mode variable
Instead, achieve the same functionality by independently providing
mpu and core deepest states the system is allowed to achieve and
update the idle states accordingly.
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/cpuidle34xx.c | 19 ++-
arch/arm/mach-omap2/pm.h |3 ++-
arch/arm/mach-omap2/pm34xx.c |2 +-
3 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 0d50b45..f80d3f6 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -293,25 +293,26 @@ select_state:
DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
/**
- * omap3_cpuidle_update_states - Update the cpuidle states.
+ * omap3_cpuidle_update_states() - Update the cpuidle states
+ * @mpu_deepest_state: Enable states upto and including this for mpu domain
+ * @core_deepest_state: Enable states upto and including this for core domain
*
- * Currently, this function toggles the validity of idle states based upon
- * the flag 'enable_off_mode'. When the flag is set all states are valid.
- * Else, states leading to OFF state set to be invalid.
+ * This goes through the list of states available and enables and disables the
+ * validity of C states based on deepest state that can be achieved for the
+ * variable domain
*/
-void omap3_cpuidle_update_states(void)
+void omap3_cpuidle_update_states(u32 mpu_deepest_state, u32 core_deepest_state)
{
int i;
for (i = OMAP3_STATE_C1; i < OMAP3_MAX_STATES; i++) {
struct omap3_processor_cx *cx = &omap3_power_states[i];
- if (enable_off_mode) {
+ if ((cx->mpu_state >= mpu_deepest_state) &&
+ (cx->core_state >= core_deepest_state)) {
cx->valid = 1;
} else {
- if ((cx->mpu_state == PWRDM_POWER_OFF) ||
-(cx->core_state == PWRDM_POWER_OFF))
-cx->valid = 0;
+ cx->valid = 0;
}
}
}
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index aff39d0..3597591 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -58,7 +58,8 @@ extern u32 sleep_while_idle;
#endif
#if defined(CONFIG_CPU_IDLE)
-extern void omap3_cpuidle_update_states(void);
+extern void omap3_cpuidle_update_states(u32 core_deepest_state,
+ u32 core_deepest_state);
#endif
#if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 21707c9..84ef71b 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -916,7 +916,7 @@ void omap3_pm_off_mode_enable(int enable)
state = PWRDM_POWER_RET;
#ifdef CONFIG_CPU_IDLE
- omap3_cpuidle_update_states();
+ omap3_cpuidle_update_states(state, state);
#endif
list_for_each_entry(pwrst, &pwrst_list, node) {
--
1.6.3.3
>From e085afb8523ca52e52b7a631c2b63e2bd6d91661 Mon Sep 17 00:00:00 2001
From: Eduardo Valentin
Date: W
Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if < ES1.2
Kevin Hilman had written, on 12/15/2010 05:47 PM, the following: I agree that this additional check in sram_idle should be removed, but as long as I handle it in omap3_pm_off_mode_enable where the next states are configured, is'nt that enough or am I missing something? Setting the next states only sets the default states, but CPUidle changes them. Looking closer at omap3_pm_off_mode_enable() though, it already calls into CPUidle and disables the valid bit for any states that have *either* MPU or core off.You'll probably just need to extend this approach to disable only CORE off state(s). Thx. it is clear now. let me see how to clean this up. -- 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: [PATCH 3/5 v3] OMAP3630: PM: Erratum i608: disable RTA
Nishanth Menon writes:
> Kevin Hilman had written, on 12/13/2010 09:28 PM, the following:
>> Nishanth Menon writes:
>>
>>> Erratum id: i608
>>> RTA (Retention Till Access) feature is not supported and leads to device
>>> stability issues when enabled. This impacts modules with embedded memories
>>> on OMAP3630
>>>
>>> Workaround is to disable RTA on boot and coming out of core off.
>>> For disabling rta coming out of off mode, we do this by overriding the
>>> restore pointer for 3630 to allow us restore handler as the first point of
>>> entry before caches are touched and is common for GP and HS devices.
>>> to disable earlier than this could be possible by modifying the ppa for HS
>>> devices, but not for GP devices.
>>>
>>> Cc: Kevin Hilman
>>> Cc: Tony Lindgren
>>>
>>> [ambr...@ti.com: co-developer]
>>> Signed-off-by: Ambresh K
>>> Signed-off-by: Nishanth Menon
>>
>> [...]
>>
>>> @@ -1045,6 +1057,15 @@ static int __init omap3_pm_init(void)
>>> pm_idle = omap3_pm_idle;
>>> omap3_idle_init();
>>> + /*
>>> +* RTA is disabled during initialization as per erratum i608
>>> +* it is safer to disable rta by the bootloader, but we would like
>>> +* to be doubly sure here and prevent any mishaps.
>>> +*/
>>> + if (IS_PM34XX_ERRATUM(RTA_ERRATUM_i608))
>>> + omap_ctrl_writel(OMAP36XX_RTA_DISABLE,
>>> + OMAP36XX_CONTROL_MEM_RTA_CTRL);
>>> +
>>
>> Minor nit: we've been trying to clean up control module access. So,
>> rather than directly writing control module registers, could you create
>> an API for this like was done for omap3_ctrl_write_boot_mode().
> looks like the cleanups are somewhere in -next and not in k.org
> tree. basing the change similar to
> http://marc.info/?l=linux-omap&m=129168623011464&w=2 does the
> attached(based on 2.6.37-rc5) looks like how you'd like to see it?
Yes, but minor comment below...
> If i need to rebase to any particular tree which already has this
> change instead of k.org, do let me know.
The above is currently only in Paul's queue, which is included in my
pm-core, so you can base there for testing if you prefer.
> --
> Regards,
> Nishanth Menon
> From 5cf295fa3fe8d423323500fb8ddb49650f797edd Mon Sep 17 00:00:00 2001
> From: Nishanth Menon
> Date: Mon, 6 Sep 2010 10:26:08 +0530
> Subject: [PATCH] OMAP3630: PM: Erratum i608: disable RTA
>
> Erratum id: i608
> RTA (Retention Till Access) feature is not supported and leads to device
> stability issues when enabled. This impacts modules with embedded memories
> on OMAP3630
>
> Workaround is to disable RTA on boot and coming out of core off.
> For disabling rta coming out of off mode, we do this by overriding the
> restore pointer for 3630 to allow us restore handler as the first point of
> entry before caches are touched and is common for GP and HS devices.
> to disable earlier than this could be possible by modifying the ppa for HS
> devices, but not for GP devices.
>
> Signed-off-by: Ambresh K
> Signed-off-by: Nishanth Menon
> ---
> arch/arm/mach-omap2/control.c | 13 -
> arch/arm/mach-omap2/control.h |7 ++-
> arch/arm/mach-omap2/pm34xx.c| 20
> arch/arm/mach-omap2/sleep34xx.S | 26 ++
> 4 files changed, 64 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
> index 1fa3294..7c415bc 100644
> --- a/arch/arm/mach-omap2/control.c
> +++ b/arch/arm/mach-omap2/control.c
> @@ -241,7 +241,10 @@ void omap3_save_scratchpad_contents(void)
>
> /* Populate the Scratchpad contents */
> scratchpad_contents.boot_config_ptr = 0x0;
> - if (omap_rev() != OMAP3430_REV_ES3_0 &&
> + if (cpu_is_omap3630())
> + scratchpad_contents.public_restore_ptr =
> + virt_to_phys(get_omap3630_restore_pointer());
> + else if (omap_rev() != OMAP3430_REV_ES3_0 &&
> omap_rev() != OMAP3430_REV_ES3_1)
> scratchpad_contents.public_restore_ptr =
> virt_to_phys(get_restore_pointer());
> @@ -474,4 +477,12 @@ void omap3_control_restore_context(void)
> omap_ctrl_writel(control_context.csi, OMAP343X_CONTROL_CSI);
> return;
> }
> +
> +void omap3630_disable_rta(void)
Let's call this omap3630_control_disable_rta() to match the naming that
Paul was using in his patch too.
Thanks,
Kevin
> +{
> + if (!cpu_is_omap36xx())
> + return;
> + omap_ctrl_writel(OMAP36XX_RTA_DISABLE, OMAP36XX_CONTROL_MEM_RTA_CTRL);
> +}
> +
> #endif /* CONFIG_ARCH_OMAP3 && CONFIG_PM */
> diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
> index b6c6b7c..13771cc 100644
> --- a/arch/arm/mach-omap2/control.h
> +++ b/arch/arm/mach-omap2/control.h
> @@ -204,6 +204,10 @@
> #define OMAP343X_CONTROL_WKUP_DEBOBS3 (OMAP343X_CONTROL_GENERAL_WKUP + 0x014)
> #define OMAP343X_CONTROL_WKUP_DEBOBS4 (OMAP343X_CONTROL_GENERAL_WK
Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if < ES1.2
Nishanth Menon writes:
> Kevin Hilman had written, on 12/13/2010 09:42 PM, the following:
>> Nishanth Menon writes:
>>
>>> Vishwanath Sripathy had written, on 12/13/2010 08:58 AM, the following:
>>> [...]
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
> omap2/pm34xx.c
> index ba3c0d6..da12a56 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -932,8 +932,15 @@ void omap3_pm_off_mode_enable(int enable)
> #endif
>
> list_for_each_entry(pwrst, &pwrst_list, node) {
> - pwrst->next_state = state;
> - omap_set_pwrdm_state(pwrst->pwrdm, state);
> + if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
> &&
> + pwrst->pwrdm == core_pwrdm) {
> + pwrst->next_state = PWRDM_POWER_RET;
> + pr_err("%s: cannot enable Core OFF due to
i583\n",
> + __func__);
You probably need to throw up this warning only if state
== PWRDM_POWER_OFF. Otherwise this code looks fine to me.
>>> Thanks for the review. added it. will post a v4 later today if no one
>>> cribs with this approach. I will retain the logic in sram_idle as well
>>> as a backup measure.
>>
>> This logic doesn't belong in SRAM idle. To handle the idle case, you
>> should also disable the 'valid' bit for any C-state that has CORE off (I
>> think there's only one.)
> Apologies, but I dont think I get your point. Do you intend to state
> that we dynamically add the C7 state in cpuidle34xx.c if this
> condition is met?
Yes. More precisely, dynamically set the 'valid' bit of C7 based on
this condition.
> I agree that this additional check in sram_idle should be removed, but
> as long as I handle it in omap3_pm_off_mode_enable where the next
> states are configured, is'nt that enough or am I missing something?
Setting the next states only sets the default states, but CPUidle
changes them.
Looking closer at omap3_pm_off_mode_enable() though, it already calls
into CPUidle and disables the valid bit for any states that have
*either* MPU or core off.You'll probably just need to extend this
approach to disable only CORE off state(s).
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 1/5] OMAP4: PM: Use the lowpwrstatechange feature on OMAP4
Rajendra Nayak writes:
> Hi Kevin,
>
> ..
>
>> >if (pwrdm_read_pwrst(pwrdm) < PWRDM_POWER_ON) {
>> > + if ((pwrdm_read_pwrst(pwrdm) > state) &&
>> > + (pwrdm->flags & PWRDM_HAS_LOWPOWERSTATECHANGE)) {
>> > + ret = pwrdm_set_next_pwrst(pwrdm, state);
>> > + pwrdm_set_lowpwrstchange(pwrdm);
>> > + pwrdm_wait_transition(pwrdm);
>> > + pwrdm_state_switch(pwrdm);
>> > + return ret;
>>
>> Personally, I'd prefer if this function flowed through better instead of
>> the early return in order to emphasize the common code.
>>
>> Rather than the return here, can you just set the low-power state change
>> bit here (and put the clkdm_wakeup + sleep_switch = 1 into the else
>> clause?
>>
>> Or, does the next state have to be set before the low-power state change
>> bit?
>
> Yes, that sequencing is needed.
>
>>
>> Basically, what I'm getting at is this should be a single function with
>> common flow. The conditional code based on low-power state change
>> should be isolated instead of having a special path.
>
> I get your point. See if the below approach looks better.
> If it looks fine, I'll do some more testing (currently only tested
> on OMAP4430sdp) and repost the 2 patches.
Yes, this approach leads to better readability IMO.
Thanks,
Kevin
> From 5d206ba908071edafae6c044bd3ef6ad8a9c32e7 Mon Sep 17 00:00:00 2001
> From: Rajendra Nayak
> Date: Thu, 25 Nov 2010 14:26:51 +0530
> Subject: [PATCH 1/5] OMAP4: PM: Use the low-power state change feature on
> OMAP4
>
> For pwrdm's which support LOWPOWERSTATECHANGE, do not try waking
> up the domain to put it back to deeper sleep state.
>
> Signed-off-by: Rajendra Nayak
> Signed-off-by: Santosh Shilimkar
> Acked-by: Benoit Cousson
> ---
> arch/arm/mach-omap2/pm.c | 28 ++--
> 1 file changed, 22 insertions(+), 6 deletions(-)
>
> Index: linux/arch/arm/mach-omap2/pm.c
> ===
> --- linux.orig/arch/arm/mach-omap2/pm.c 2010-12-15 17:29:42.361228780
> +0530
> +++ linux/arch/arm/mach-omap2/pm.c2010-12-15 20:19:48.321228780
> +0530
> @@ -89,6 +89,10 @@
> }
> }
>
> +/* Types of sleep_switch used in omap_set_pwrdm_state */
> +#define FORCEWAKEUP_SWITCH 0
> +#define LOWPOWERSTATE_SWITCH 1
> +
> /*
> * This sets pwrdm state (other than mpu & core. Currently only ON &
> * RET are supported. Function is assuming that clkdm doesn't have
> @@ -114,9 +118,14 @@
> return ret;
>
> if (pwrdm_read_pwrst(pwrdm) < PWRDM_POWER_ON) {
> - omap2_clkdm_wakeup(pwrdm->pwrdm_clkdms[0]);
> - sleep_switch = 1;
> - pwrdm_wait_transition(pwrdm);
> + if ((pwrdm_read_pwrst(pwrdm) > state) &&
> + (pwrdm->flags & PWRDM_HAS_LOWPOWERSTATECHANGE)) {
> + sleep_switch = LOWPOWERSTATE_SWITCH;
> + } else {
> + omap2_clkdm_wakeup(pwrdm->pwrdm_clkdms[0]);
> + pwrdm_wait_transition(pwrdm);
> + sleep_switch = FORCEWAKEUP_SWITCH;
> + }
> }
>
> ret = pwrdm_set_next_pwrst(pwrdm, state);
> @@ -126,12 +135,19 @@
> goto err;
> }
>
> - if (sleep_switch) {
> + switch (sleep_switch) {
> + case FORCEWAKEUP_SWITCH:
> omap2_clkdm_allow_idle(pwrdm->pwrdm_clkdms[0]);
> - pwrdm_wait_transition(pwrdm);
> - pwrdm_state_switch(pwrdm);
> + break;
> + case LOWPOWERSTATE_SWITCH:
> + pwrdm_set_lowpwrstchange(pwrdm);
> + break;
> + default:
> + return ret;
> }
>
> + pwrdm_wait_transition(pwrdm);
> + pwrdm_state_switch(pwrdm);
> err:
> return ret;
> }
>
>
>>
>> Kevin
>>
>> > + }
>> >omap2_clkdm_wakeup(pwrdm->pwrdm_clkdms[0]);
>> >sleep_switch = 1;
>> >pwrdm_wait_transition(pwrdm);
--
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] west bridge device driver changes to use gpmc configuration functions
On Wed, Dec 15, 2010 at 03:03:45PM -0800, Sutharsan wrote: > > This patch contains changes to west bridge device controller driver in > staging area. > The west bridge device controller driver is modified to use gpmc > configuration functions instead of directly modifying gpmc registers. > This patch is continuation of David Cross' earlier > patch "[PATCH] gpmc, EXPORT_SYMBOLS, west bridge related" Please line-wrap your changelog entries to be sane. > This patch depends on "[PATCH] adding gpmc configuration functions, west > bridge related". I no longer have this patch in my queue, sorry. And, as it's only for a staging driver, shouldn't that patch be in the staging/westbridge/ subdirectory as well? Otherwise you need to get it approved by the proper arm subsystem maintainer. > Thanks, > Sutharsan. Don't put this within a changelog entry. Ideally I should be able to take your email, edit nothing, and apply it as-is. This one would require a lot of editing :( Care to redo it, and resend the other one? thanks, greg k-h -- 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] west bridge device driver changes to use gpmc configuration functions
This patch contains changes to west bridge device controller driver in staging
area.
The west bridge device controller driver is modified to use gpmc configuration
functions instead of directly modifying gpmc registers.
This patch is continuation of David Cross' earlier
patch "[PATCH] gpmc, EXPORT_SYMBOLS, west bridge related"
This patch depends on "[PATCH] adding gpmc configuration functions, west bridge
related".
Thanks,
Sutharsan.
Signed-off-by: Sutharsan Ramamoorthy
---
diff -uprN -X linux-2.6.37_vanilla/Documentation/dontdiff
linux-2.6.37_vanilla/drivers/staging/westbridge/astoria/arch/arm/mach-omap2/cyashalomap_kernel.c
linux-2.6.37-cywb/drivers/staging/westbridge/astoria/arch/arm/mach-omap2/cyashalomap_kernel.c
---
linux-2.6.37_vanilla/drivers/staging/westbridge/astoria/arch/arm/mach-omap2/cyashalomap_kernel.c
2010-11-29 20:42:04.0 -0800
+++
linux-2.6.37-cywb/drivers/staging/westbridge/astoria/arch/arm/mach-omap2/cyashalomap_kernel.c
2010-12-14 15:37:02.770286377 -0800
@@ -129,6 +129,13 @@ static uint8_t pnand_16bit;
#define PGMPAGE_B2 0x10
/*
+ * following macros are used in ./arch/arm/mach-omap2/usb-cywb-pnand.c
+ * so move them to common header
+ */
+#define GPMC_16BIT_MODE 0
+#define GPMC_RETIME 1
+
+/*
* The type of DMA operation, per endpoint
*/
typedef enum cy_as_hal_dma_type {
@@ -303,55 +310,22 @@ static u16 omap_cfg_reg_L(u32 pad_func_i
*/
void cy_as_hal_gpmc_enable_16bit_bus(bool dbus16_enabled)
{
- uint32_t tmp32;
-
- /*
-* disable gpmc CS4 operation 1st
-*/
- tmp32 = gpmc_cs_read_reg(AST_GPMC_CS,
- GPMC_CS_CONFIG7) & ~GPMC_CONFIG7_CSVALID;
- gpmc_cs_write_reg(AST_GPMC_CS, GPMC_CS_CONFIG7, tmp32);
-
- /*
-* GPMC NAND data bus can be 8 or 16 bit wide
-*/
- if (dbus16_enabled) {
- DBGPRN("enabling 16 bit bus\n");
- gpmc_cs_write_reg(AST_GPMC_CS, GPMC_CS_CONFIG1,
- (GPMC_CONFIG1_DEVICETYPE(2) |
- GPMC_CONFIG1_WAIT_PIN_SEL(2) |
- GPMC_CONFIG1_DEVICESIZE_16)
- );
- } else {
- DBGPRN(KERN_INFO "enabling 8 bit bus\n");
- gpmc_cs_write_reg(AST_GPMC_CS, GPMC_CS_CONFIG1,
- (GPMC_CONFIG1_DEVICETYPE(2) |
- GPMC_CONFIG1_WAIT_PIN_SEL(2))
- );
- }
-
- /*
-* re-enable astoria CS operation on GPMC
-*/
-gpmc_cs_write_reg(AST_GPMC_CS, GPMC_CS_CONFIG7,
- (tmp32 | GPMC_CONFIG7_CSVALID));
-
/*
*remember the state
*/
pnand_16bit = dbus16_enabled;
+ cywb_pnand_platform_retime(GPMC_16BIT_MODE, dbus16_enabled);
}
static int cy_as_hal_gpmc_init(void)
{
u32 tmp32;
- int err;
- struct gpmc_timings timings;
+
/*
* get GPMC i/o registers base(already been i/o mapped
* in kernel, no need for separate i/o remap)
*/
- gpmc_base = phys_to_virt(OMAP34XX_GPMC_BASE);
+ gpmc_base = (u32)ioremap_nocache(OMAP34XX_GPMC_BASE, BLKSZ_4K);
DBGPRN(KERN_INFO "kernel has gpmc_base=%x , val@ the base=%x",
gpmc_base, __raw_readl(gpmc_base)
);
@@ -363,109 +337,7 @@ static int cy_as_hal_gpmc_init(void)
naddr_reg_vma = GPMC_VMA(AST_GPMC_NAND_ADDR);
ndata_reg_vma = GPMC_VMA(AST_GPMC_NAND_DATA);
- /*
-* request GPMC CS for ASTORIA request
-*/
- if (gpmc_cs_request(AST_GPMC_CS, SZ_16M, (void *)&csa_phy) < 0) {
- cy_as_hal_print_message(KERN_ERR "error failed to request"
- "ncs4 for ASTORIA\n");
- return -1;
- } else {
- DBGPRN(KERN_INFO "got phy_addr:%x for "
- "GPMC CS%d GPMC_CFGREG7[CS4]\n",
-csa_phy, AST_GPMC_CS);
- }
-
- /*
-* request VM region for 4K addr space for chip select 4 phy address
-* technically we don't need it for NAND devices, but do it anyway
-* so that data read/write bus cycle can be triggered by reading
-* or writing this mem region
-*/
- if (!request_mem_region(csa_phy, BLKSZ_4K, "AST_OMAP_HAL")) {
- err = -EBUSY;
- cy_as_hal_print_message(KERN_ERR "error MEM region "
- "request for phy_addr:%x failed\n",
- csa_phy);
- goto out_free_cs;
- }
-
- /*
-* REMAP mem region associated with our CS
-*/
- gpmc_data_vma = (u32)ioremap_nocache(csa_phy, BLKSZ_4K);
- if (!gpmc_data_vma) {
- err = -ENOMEM;
- cy_as_hal_print_message(KERN_ERR "error- ioremap()"
-
[GIT PULL] OMAP: mailbox and iommu changes: for-next for v2.6.38
Hi Tony, The following changes since commit e8a7e48bb248a1196484d3f8afa53bded2b24e71: Linus Torvalds (1): Linux 2.6.37-rc4 are available in the git repository at: git://gitorious.org/iommu_mailbox/iommu_mailbox.git for_2.6.38 Felipe Contreras (1): OMAP: iommu: make iva2 iommu selectable Fernando Guzman Lugo (1): OMAP: mailbox: change full flag per mailbox queue instead of global Guzman Lugo, Fernando (4): OMAP: iovmm: no gap checking for fixed address OMAP: iovmm: add superpages support to fixed da address OMAP: iovmm: replace __iounmap with iounmap OMAP: iommu: create new api to set valid da range Kanigeri, Hari (3): OMAP: mailbox: fix checkpatch warnings OMAP: mailbox: send message in process context OMAP: mailbox: add notification support for multiple readers Omar Ramirez Luna (2): OMAP: mailbox: remove unreachable return OMAP: mailbox: fix detection for previously supported chips arch/arm/mach-omap2/mailbox.c | 19 +++-- arch/arm/mach-omap2/omap-iommu.c | 10 ++- arch/arm/plat-omap/Kconfig|3 + arch/arm/plat-omap/include/plat/iommu.h |5 + arch/arm/plat-omap/include/plat/mailbox.h |8 +- arch/arm/plat-omap/iommu.c| 24 + arch/arm/plat-omap/iovmm.c| 81 ++ arch/arm/plat-omap/mailbox.c | 130 + 8 files changed, 179 insertions(+), 101 deletions(-) The above patch set is dependent on the following 2 Russell's patches. ARM: io: make iounmap() a simple macro ARM: io: simplify ioremap* and iounmap definitions Ref: http://www.spinics.net/lists/linux-omap/msg42023.html Thank you, Best regards, Hari Kanigeri -- 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 3/5 v3] OMAP3630: PM: Erratum i608: disable RTA
Kevin Hilman had written, on 12/13/2010 09:28 PM, the following:
Nishanth Menon writes:
Erratum id: i608
RTA (Retention Till Access) feature is not supported and leads to device
stability issues when enabled. This impacts modules with embedded memories
on OMAP3630
Workaround is to disable RTA on boot and coming out of core off.
For disabling rta coming out of off mode, we do this by overriding the
restore pointer for 3630 to allow us restore handler as the first point of
entry before caches are touched and is common for GP and HS devices.
to disable earlier than this could be possible by modifying the ppa for HS
devices, but not for GP devices.
Cc: Kevin Hilman
Cc: Tony Lindgren
[ambr...@ti.com: co-developer]
Signed-off-by: Ambresh K
Signed-off-by: Nishanth Menon
[...]
@@ -1045,6 +1057,15 @@ static int __init omap3_pm_init(void)
pm_idle = omap3_pm_idle;
omap3_idle_init();
+ /*
+* RTA is disabled during initialization as per erratum i608
+* it is safer to disable rta by the bootloader, but we would like
+* to be doubly sure here and prevent any mishaps.
+*/
+ if (IS_PM34XX_ERRATUM(RTA_ERRATUM_i608))
+ omap_ctrl_writel(OMAP36XX_RTA_DISABLE,
+ OMAP36XX_CONTROL_MEM_RTA_CTRL);
+
Minor nit: we've been trying to clean up control module access. So,
rather than directly writing control module registers, could you create
an API for this like was done for omap3_ctrl_write_boot_mode().
looks like the cleanups are somewhere in -next and not in k.org tree.
basing the change similar to
http://marc.info/?l=linux-omap&m=129168623011464&w=2 does the
attached(based on 2.6.37-rc5) looks like how you'd like to see it? If i
need to rebase to any particular tree which already has this change
instead of k.org, do let me know.
--
Regards,
Nishanth Menon
>From 5cf295fa3fe8d423323500fb8ddb49650f797edd Mon Sep 17 00:00:00 2001
From: Nishanth Menon
Date: Mon, 6 Sep 2010 10:26:08 +0530
Subject: [PATCH] OMAP3630: PM: Erratum i608: disable RTA
Erratum id: i608
RTA (Retention Till Access) feature is not supported and leads to device
stability issues when enabled. This impacts modules with embedded memories
on OMAP3630
Workaround is to disable RTA on boot and coming out of core off.
For disabling rta coming out of off mode, we do this by overriding the
restore pointer for 3630 to allow us restore handler as the first point of
entry before caches are touched and is common for GP and HS devices.
to disable earlier than this could be possible by modifying the ppa for HS
devices, but not for GP devices.
Signed-off-by: Ambresh K
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/control.c | 13 -
arch/arm/mach-omap2/control.h |7 ++-
arch/arm/mach-omap2/pm34xx.c| 20
arch/arm/mach-omap2/sleep34xx.S | 26 ++
4 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 1fa3294..7c415bc 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -241,7 +241,10 @@ void omap3_save_scratchpad_contents(void)
/* Populate the Scratchpad contents */
scratchpad_contents.boot_config_ptr = 0x0;
- if (omap_rev() != OMAP3430_REV_ES3_0 &&
+ if (cpu_is_omap3630())
+ scratchpad_contents.public_restore_ptr =
+ virt_to_phys(get_omap3630_restore_pointer());
+ else if (omap_rev() != OMAP3430_REV_ES3_0 &&
omap_rev() != OMAP3430_REV_ES3_1)
scratchpad_contents.public_restore_ptr =
virt_to_phys(get_restore_pointer());
@@ -474,4 +477,12 @@ void omap3_control_restore_context(void)
omap_ctrl_writel(control_context.csi, OMAP343X_CONTROL_CSI);
return;
}
+
+void omap3630_disable_rta(void)
+{
+ if (!cpu_is_omap36xx())
+ return;
+ omap_ctrl_writel(OMAP36XX_RTA_DISABLE, OMAP36XX_CONTROL_MEM_RTA_CTRL);
+}
+
#endif /* CONFIG_ARCH_OMAP3 && CONFIG_PM */
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index b6c6b7c..13771cc 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -204,6 +204,10 @@
#define OMAP343X_CONTROL_WKUP_DEBOBS3 (OMAP343X_CONTROL_GENERAL_WKUP + 0x014)
#define OMAP343X_CONTROL_WKUP_DEBOBS4 (OMAP343X_CONTROL_GENERAL_WKUP + 0x018)
+/* 36xx-only RTA - Retention till Accesss control registers and bits */
+#define OMAP36XX_CONTROL_MEM_RTA_CTRL 0x40C
+#define OMAP36XX_RTA_DISABLE 0x0
+
/* 34xx D2D idle-related pins, handled by PM core */
#define OMAP3_PADCONF_SAD2D_MSTANDBY 0x250
#define OMAP3_PADCONF_SAD2D_IDLEACK0x254
@@ -347,10 +351,11 @@ extern void omap3_save_scratchpad_contents(void);
extern void omap3_clear_scratchpad_contents(void);
extern u32 *get_restore_pointer(void);
extern u32 *get_es3_restore_pointer(void);
+extern u32 *get_omap3630_restore_pointer(void);
extern u32 omap3_arm_context[128];
extern void omap3_control_save_context(void);
extern void omap3_control
Re: [PATCH 0/5 v3] OMAP: idle path errata fixes
Kevin Hilman had written, on 12/13/2010 09:49 PM, the following: Hi Nishanth, Nishanth Menon writes: as discussed in [1], here is step 2 - idle path errata fixes. this is the next rev incorporating comments from V2 post of this series. I had a couple small comments on individual patches. In addition, in the next series, can you report the platforms it was tested on, and how it was tested (retention idle/suspend, off idle/suspend, CPUidle enabled?, etc.) I tested this series (and Jean's cleanup patch) on 34xx/n900 with retention idle & suspend and off idle & suspend with and without CPUidle enabled.) Also, when posting an updated series, can you update the version of all patches in the series, even if they are unchanged? This makes more more explicit versioning, keeps things clearer in patchwork and avoids problems with dumb mailers who thread by subject only. Also, please Cc linux-arm-kernel when posting the next version. ok will do. for reference, I wrote a script to make things easy for all - attached. With the pm-fixes being merged to master, I tested today with latest kernel.org master commit: 0fcdcfb against omap2plus_defconfig without any of my patches applied: Results: SDP3630: Log: http://pastebin.mozilla.org/889642 Summary: SUSPEND:OFF test | PASS | OFF: 0->1| RET:0 ->0 (8 sec) SUSPEND:RET test | PASS | OFF: 1->1| RET:0 ->1 (8 sec) IDLE:OFF test | PASS | OFF: 1->24| RET:1 ->1 (21 sec) IDLE:RET test | PASS | OFF: 24->| RET:1 ->23 (21 sec) SDP3430 (ES3.1): Log: http://pastebin.mozilla.org/889643 Summary: SUSPEND:OFF test | FAIL | OFF: 0->0| RET:0 ->0 (7 sec) SUSPEND:RET test | FAIL | OFF: 0->0| RET:0 ->0 (6 sec) IDLE:OFF test | FAIL | OFF: 0->0| RET:0 ->0 (21 sec) IDLE:RET test | FAIL | OFF: 0->0| RET:0 ->0 (21 sec) Core never hits OFF/retention. -- Regards, Nishanth Menon suspend-idle.sh Description: Bourne shell script
Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if < ES1.2
Kevin Hilman had written, on 12/13/2010 09:42 PM, the following:
Nishanth Menon writes:
Vishwanath Sripathy had written, on 12/13/2010 08:58 AM, the following:
[...]
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
omap2/pm34xx.c
index ba3c0d6..da12a56 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -932,8 +932,15 @@ void omap3_pm_off_mode_enable(int enable)
#endif
list_for_each_entry(pwrst, &pwrst_list, node) {
- pwrst->next_state = state;
- omap_set_pwrdm_state(pwrst->pwrdm, state);
+ if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
&&
+ pwrst->pwrdm == core_pwrdm) {
+ pwrst->next_state = PWRDM_POWER_RET;
+ pr_err("%s: cannot enable Core OFF due to
i583\n",
+ __func__);
You probably need to throw up this warning only if state
== PWRDM_POWER_OFF. Otherwise this code looks fine to me.
Thanks for the review. added it. will post a v4 later today if no one
cribs with this approach. I will retain the logic in sram_idle as well
as a backup measure.
This logic doesn't belong in SRAM idle. To handle the idle case, you
should also disable the 'valid' bit for any C-state that has CORE off (I
think there's only one.)
Apologies, but I dont think I get your point. Do you intend to state
that we dynamically add the C7 state in cpuidle34xx.c if this condition
is met?
I agree that this additional check in sram_idle should be removed, but
as long as I handle it in omap3_pm_off_mode_enable where the next states
are configured, is'nt that enough or am I missing something?
--
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: [PATCH 2/2] arm: mach-omap2: Kconfig: devkit8000 should select needed options
Hi Aaro, * Aaro Koskinen [101215 04:48]: > It's not possible to compile a kernel for this board without I2C, > MFD_SUPPORT and TWL4030_CORE, so those should be selected. This will > prevent build errors when trying out different configurations. This one I'm not so convinced about. We should be able to compile support for each board and enable and disable these kind of options just fine if CONFIG_ARCH_OMAP2PLUS_TYPICAL is disabled. In the long run we really want to have just a minimal kernel and have everything else as modules for the default configs and boot using initramfs. Probably the best way to deal with issues like this is to have omap generic platform init code for the common devices that gets built if those options are selected. Otherwise we'll end up with ifdefs all over the board-*.c files. Regards, Tony > Signed-off-by: Aaro Koskinen > --- > arch/arm/mach-omap2/Kconfig |4 > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index db20351..bb32f35 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -129,6 +129,10 @@ config MACH_DEVKIT8000 > default y > select OMAP_PACKAGE_CUS > select OMAP_MUX > + select I2C > + select I2C_OMAP > + select MFD_SUPPORT > + select TWL4030_CORE > > config MACH_OMAP_LDP > bool "OMAP3 LDP board" > -- > 1.5.6.5 > -- 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: UbiFS + HWECC(?) + BeagleBoard = fail
On Wednesday 15 December 2010 17:13:42 Charles Manning wrote:
> On Thursday 09 December 2010 21:30:48 Luca Ceresoli wrote:
> > Charles Manning wrote:
> > > Luca, I have been having similar problems on a hacked Overo kernel.
> > >
> > > I have no problems with 2.6.35.
> > >
> > > I tried just commenting out the define and disabling PREFETCH and did
> > > not get a good boot due to ubi not finding the volume info.
> > >
> > > Are you loading up a UBI image with uboot?
> > >
> > > Are you using the ubi volume as rootfs?
> >
> > To make it work again, I did from u-boot:
> > - nand scrub (*completely* wipe the NAND)
> > - ubi part nand0,3 (recreate partitions)
> > - ubi create rootfs 40
> > - ...create other partitions...
> > - ubi write ... (to rewrite rootfs)
> > - finally, boot with the kernel having the define commented and PREFETCH
> > off.
> >
> > Not all of these may be needed, but this way I got the board up and
> > running again.
> >
> > Luca
>
> What branch are you working from?
>
> I tried working from a reasonably recent master on
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
>
> I found that reads via the prefetch eengine work, but reads via
> ioread16_rep(nand->IO_ADDR_R, buf, len / 2)
> do not.
>
> Perhaps this is due to the address not being set up properly. Any clues?
>
> I found that I can make everything work by realigning all accesses in
> nand_base.c to be 4-byte aligned.
>
This change does what I need.
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -245,6 +245,18 @@ static void omap_read_buf_pref(struct mtd_info *mtd,
u_char *buf, int len)
int ret = 0;
u32 *p = (u32 *)buf;
+ /* u32 align the buffer and read */
+ /* NB: This assumes the buf ptr can be aligned *down* which is a
valid.
+* Assumption when dealing with ecc buffers etc.
+*/
+ u32 addr = (u32)p;
+
+ int diff = addr & 3;
+ addr -= diff;
+ len += diff;
+ len = (len + 3) & ~3;
+ p = (u32 *)addr;
+
/* take care of subpage reads */
if (len % 4) {
if (info->nand.options & NAND_BUSWIDTH_16)
Charles
--
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: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera
On Wed, Dec 15, 2010 at 12:39:20PM +, Catalin Marinas wrote:
> On 13 December 2010 16:29, Russell King - ARM Linux
> wrote:
> > On Mon, Dec 13, 2010 at 03:52:20PM +, Catalin Marinas wrote:
> >> On 10 December 2010 17:03, Russell King - ARM Linux
> >> wrote:
> >> > On Fri, Dec 10, 2010 at 12:03:07PM +0100, Janusz Krzysztofik wrote:
> >> >> void __init omap1_camera_init(void *info)
> >> >> {
> >> >> struct platform_device *dev = &omap1_camera_device;
> >> >> + dma_addr_t paddr = omap1_camera_phys_mempool_base;
> >> >> + dma_addr_t size = omap1_camera_phys_mempool_size;
> >> >> int ret;
> >> >>
> >> >> dev->dev.platform_data = info;
> >> >>
> >> >> + if (paddr) {
> >> >> + if (dma_declare_coherent_memory(&dev->dev, paddr, paddr,
> >> >> size,
> >> >> + DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE))
> >> >
> >> > Although this works, you're ending up with SDRAM being mapped via
> >> > ioremap, which uses MT_DEVICE - so what is SDRAM ends up being
> >> > mapped as if it were a device.
> >>
> >> BTW, does the generic dma_declare_coherent_memory() does the correct
> >> thing in using ioremap()?
> >
> > I argue it doesn't, as I said above. It means we map SDRAM as device
> > memory, and as I understand the way interconnects work, it's entirely
> > possible that this may not result in the SDRAM being accessible.
> [...]
> > So, not only does this fail the kernel's own rules, but as we already know,
> > it fails the architecture's restrictions with multiple mappings of memory
> > when used with SDRAM, and it also maps main memory as a device. I wonder
> > how many more things this broken API needs to do wrong before it's current
> > implementation is consigned to the circular filing cabinet.
>
> Should we not try to fix the generic code and still allow platforms to
> use dma_declare_coherent_memory() in a safer way? I guess it may need
> some arguing/explanation on linux-arch.
I think so - one of the issues with dma_declare_coherent_memory() is that
it's original intention (as I understand it) was to allow drivers to use
on-device dma coherent memory.
Eg, a network controller with its own local SRAM which it can fetch DMA
descriptors from, which tells it where in the bus address space to fetch
packets from. This SRAM is not part of the hosts memory, but is on the
peripheral's bus, and so ioremap() (or maybe ioremap_wc()) would be
appropriate for it.
However, ioremap() on system RAM (even that which has been taken out on
the memory map) may be problematical.
I think the correct solution would be to revise the interface so it takes
a void * pointer, which can be handed out by dma_alloc_coherent() directly
without the API having to worry about how to map the memory. IOW, push
the mapping of that memory up a level to the caller of
dma_declare_coherent_memory().
We can then sanely do preallocations via dma_coherent_alloc() and caching
them back into dma_declare_coherent_memory() without creating additional
mappings which cause architectural violations.
--
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 13/14] OMAP2/3: PRCM: split OMAP2/3-specific PRCM code into OMAP2/3-specific files
On Tue, Dec 14, 2010 at 10:50 PM, Paul Walmsley wrote:
> Hi,
>
> On Mon, 6 Dec 2010, Paul Walmsley wrote:
>
>> In preparation for adding OMAP4-specific PRCM accessor/mutator
>> functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific
>> files. Most of what was in mach-omap2/{cm,prm}.{c,h} has now been
>> moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was
>> OMAP2xxx/3xxx-specific.
>>
>> This process also requires the #includes in each of these files to be
>> changed to reference the new file name. As part of doing so, add some
>> comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use
>> "sideways includes", to indicate that these users of the PRM/CM includes
>> should not be doing so.
>
> This patch has been updated to also take care of getting DSPBridge to
> build again. Omar, Felipe, could you please take a look at the
> mach-omap2/dsp.c and _tiomap.h changes and ack them?
...
> diff --git a/arch/arm/mach-omap2/dsp.c b/arch/arm/mach-omap2/dsp.c
> index 6feeeae..a8b62d7 100644
> --- a/arch/arm/mach-omap2/dsp.c
> +++ b/arch/arm/mach-omap2/dsp.c
> @@ -9,11 +9,16 @@
> * 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
> * published by the Free Software Foundation.
> + *
> + * XXX The function pointers to the PRM/CM functions are incorrect and
> + * should be removed. No device driver should be changing PRM/CM bits
> + * directly; that's a layering violation -- those bits are the responsibility
> + * of the OMAP PM core code.
> */
>
> #include
> -#include "prm.h"
> -#include "cm.h"
> +#include "cm2xxx_3xxx.h"
> +#include "prm2xxx_3xxx.h"
> #ifdef CONFIG_BRIDGE_DVFS
> #include
> #endif
I don't have a preference, I guess part of the license header makes
them even more noticeable.
> diff --git a/drivers/staging/tidspbridge/core/_tiomap.h
> b/drivers/staging/tidspbridge/core/_tiomap.h
> index 1c1f157..7fac488 100644
> --- a/drivers/staging/tidspbridge/core/_tiomap.h
> +++ b/drivers/staging/tidspbridge/core/_tiomap.h
> @@ -21,6 +21,12 @@
>
> #include
> #include
> +/*
> + * XXX These mach-omap2/ includes are wrong and should be removed. No
> + * driver should read or write to PRM/CM registers directly; they
> + * should rely on OMAP core code to do this.
> + */
> +#include
> #include
> #include
> #include
Acked-by: Omar Ramirez Luna
Just in case someone is wondering, there is a plan to use hwmod and
move start/stop/monitor functions to dsp.c code, so, the driver can
call them through pdata.
Regards,
Omar
--
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/7 v2] OMAP: McSPI: Hwmod adaptation + runtime conversion
"Govindraj.R" writes: > Changes invloves: > > 1) Addition of hwmod data for omap2/3/4. > 1) McSPI driver hwmod adaptation with cleanup of base address >macros and using omap-device API's. > 2) Runtime Conversion of McSPI driver > > Changes from v1: > --- > 1) Fixing patch 5/5 comments for hwmod+runtime >Split the patch 5/5 to hwmod adaptation >and then runtime conversion >http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33387.html > > Testing Updates: > > Was tested using data transfer test module available at: > http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=blob;f=mcspi/test_code/ > utils/mcspi_modules/omap_mcspi_datatest.c; > h=e42ec10c5c844abdde6a7175a268b379fbbdb655; > hb=5d9a755d50e58de861c5e8991f2f607bc49b5dc3 Can you summarize what this test does? On what platforms was this tested? How was it tested for OMAP1 and OMAP2? Kevin > System wide suspend and ret/off counts observation, > ensured that no behavioral difference with and without > this patch series. > > Benoit Cousson (1): > OMAP4: hwmod data: Add McSPI > > Charulatha V (5): > OMAP2420: hwmod data: Add McSPI > OMAP2430: hwmod data: Add McSPI > OMAP3: hwmod data: Add McSPI > OMAP3: clocks: Update clock domain name for mcspi fck > OMAP: devices: Modify McSPI device to adapt to hwmod framework > > Govindraj.R (1): > OMAP: runtime: McSPI driver runtime conversion > > arch/arm/mach-omap2/clock3xxx_data.c |4 + > arch/arm/mach-omap2/devices.c | 189 --- > arch/arm/mach-omap2/omap_hwmod_2420_data.c | 156 > arch/arm/mach-omap2/omap_hwmod_2430_data.c | 219 ++ > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 280 > > arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 267 ++ > arch/arm/plat-omap/include/plat/mcspi.h| 11 + > drivers/spi/omap2_mcspi.c | 225 +++--- > 8 files changed, 1051 insertions(+), 300 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 -- 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 v1 4/9] OMAP2430: hwmod data: add system DMA
On Wed, Dec 15, 2010 at 08:14:49AM -0700, Paul Walmsley wrote:
> On Wed, 15 Dec 2010, G, Manjunath Kondaiah wrote:
>
> > On Tue, Dec 14, 2010 at 07:27:33PM -0700, Paul Walmsley wrote:
> > > On Sat, 4 Dec 2010, G, Manjunath Kondaiah wrote:
> > >
> > > > Add OMAP2430 DMA hwmod data and also add required
> > > > DMA device attributes.
> > >
> > > ...
> > >
> > > > +/* dma_system -> L3 */
> > > > +static struct omap_hwmod_ocp_if omap2430_dma_system__l3 = {
> > > > + .master = &omap2430_dma_system_hwmod,
> > > > + .slave = &omap2430_l3_main_hwmod,
> > > > + .clk= "l3_div_ck",
> > >
> > > This clock does not exist on OMAP2430. Did you test this on OMAP2430?
> >
> > Yes. I have tested this on SDP2430. For confirmation, I tested again now.
> > It boots up without any issues and all DMA test cases are passing.
>
> Don't you see warnings in the boot messages that this clock cannot be
> found?
No. I don't see any warnings in boot log. May missing during early
prints?
-Manjunath
--
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 v1 3/9] OMAP2420: hwmod data: add system DMA]
On Wed, 15 Dec 2010, G, Manjunath Kondaiah wrote:
> On Wed, Dec 15, 2010 at 04:39:17PM +0530, G, Manjunath Kondaiah wrote:
> > On Tue, Dec 14, 2010 at 07:25:23PM -0700, Paul Walmsley wrote:
> > > On Sat, 4 Dec 2010, G, Manjunath Kondaiah wrote:
> > >
> > > > Add OMAP2420 DMA hwmod data and also add required
> > > > DMA device attributes.
> > > >
> > > > Signed-off-by: G, Manjunath Kondaiah
> > > > Cc: Benoit Cousson
> > > > Cc: Kevin Hilman
> > > > Cc: Santosh Shilimkar
> > > >
> > > > +/* dma_system -> L3 */
> > > > +static struct omap_hwmod_ocp_if omap2420_dma_system__l3 = {
> > > > + .master = &omap2420_dma_system_hwmod,
> > > > + .slave = &omap2420_l3_main_hwmod,
> > > > + .clk= "l3_div_ck",
> > >
> > > This clock does not exist on OMAP2420. Did you test this patch on 2420?
> >
> > ok. will be replaced with "sdma_ick". I don't have 2420 for testing. I
> > tested it on 2430. My understanding is that, DMA clock interface is same
> > for 2420 and 2430. Correct me if am wrong.
>
> Looking into omap3/omap4 structures, this entry takes core l3 clock.
>
> This should be "sdma_fck" since it's parent is core_l3_ck.
The OMAP2xxx SDMA data can use either sdma_fck or core_l3_ck for its
functional clock. At some point we will probably remove sdma_fck from the
2xxx data. That's a relic of the pre-clkdev days, so you might as well
just use core_l3_ck. Maybe just stick with sdma_ick for the interface
clock for right now.
- Paul
--
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] OMAP: pm.c correct the initcall for an early init.
>>-Original Message- >>From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >>Sent: Tuesday, December 14, 2010 6:37 AM >>To: Gopinath, Thara >>Cc: linux-omap@vger.kernel.org >>Subject: Re: [PATCH] OMAP: pm.c correct the initcall for an early init. >> >>"Gopinath, Thara" writes: >> >-Original Message- >From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: Thursday, December 02, 2010 7:03 PM >To: Gopinath, Thara >Cc: linux-omap@vger.kernel.org >Subject: Re: [PATCH] OMAP: pm.c correct the initcall for an early init. > >Thara Gopinath writes: > >> omap2_common_pm_init is the API where generic system devices like >> mpu, l3 etc get initialized. This has to happen really early on >> during the boot and not at a later time. This is especially important >> with the new opp changes as these devices need to be built before the >> opp tables init happen. Today both are device initcalls and it works >> just because of the order of compilation > >Why postcore? there are several other inicalls earlier than >device_initcall. >>> >>> Because the init in omap_device is a core_initcall. With respect >>> to opp layer, making this anything above device_initcall will work. But >>> then tomorrow some other module needs these generic devices in their >>init, >>> we will again have to bump up the init priority of this fn. >>> It is a good thing to do this early on in the boot cycle rather >>> than later. >> >>OK, please describe this in more detail the changelog. Ok Will repost Regards Thara -- 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
[GIT PULL] OMAP DSS fixes for next rc
Hi Paul, Two OMAP DSS fixes for the next rc. Tomi The following changes since commit cf7d7e5a1980d1116ee152d25dac382b112b9c17: Linux 2.6.37-rc5 (2010-12-06 20:09:04 -0800) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git for-paul-rc Tomi Valkeinen (2): OMAP: DSS: VRAM: Align start & size of vram to 2M OMAP: OMAPFB: disable old omapfb for OMAP4 builds drivers/video/omap/Kconfig |4 ++-- drivers/video/omap2/vram.c |4 ++-- 2 files changed, 4 insertions(+), 4 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
RE: [PATCH 1/5] OMAP4: PM: Use the lowpwrstatechange feature on OMAP4
Hi Kevin,
..
> > if (pwrdm_read_pwrst(pwrdm) < PWRDM_POWER_ON) {
> > + if ((pwrdm_read_pwrst(pwrdm) > state) &&
> > + (pwrdm->flags & PWRDM_HAS_LOWPOWERSTATECHANGE)) {
> > + ret = pwrdm_set_next_pwrst(pwrdm, state);
> > + pwrdm_set_lowpwrstchange(pwrdm);
> > + pwrdm_wait_transition(pwrdm);
> > + pwrdm_state_switch(pwrdm);
> > + return ret;
>
> Personally, I'd prefer if this function flowed through better instead of
> the early return in order to emphasize the common code.
>
> Rather than the return here, can you just set the low-power state change
> bit here (and put the clkdm_wakeup + sleep_switch = 1 into the else
> clause?
>
> Or, does the next state have to be set before the low-power state change
> bit?
Yes, that sequencing is needed.
>
> Basically, what I'm getting at is this should be a single function with
> common flow. The conditional code based on low-power state change
> should be isolated instead of having a special path.
I get your point. See if the below approach looks better.
If it looks fine, I'll do some more testing (currently only tested
on OMAP4430sdp) and repost the 2 patches.
>From 5d206ba908071edafae6c044bd3ef6ad8a9c32e7 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak
Date: Thu, 25 Nov 2010 14:26:51 +0530
Subject: [PATCH 1/5] OMAP4: PM: Use the low-power state change feature on
OMAP4
For pwrdm's which support LOWPOWERSTATECHANGE, do not try waking
up the domain to put it back to deeper sleep state.
Signed-off-by: Rajendra Nayak
Signed-off-by: Santosh Shilimkar
Acked-by: Benoit Cousson
---
arch/arm/mach-omap2/pm.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
Index: linux/arch/arm/mach-omap2/pm.c
===
--- linux.orig/arch/arm/mach-omap2/pm.c 2010-12-15 17:29:42.361228780
+0530
+++ linux/arch/arm/mach-omap2/pm.c 2010-12-15 20:19:48.321228780
+0530
@@ -89,6 +89,10 @@
}
}
+/* Types of sleep_switch used in omap_set_pwrdm_state */
+#define FORCEWAKEUP_SWITCH 0
+#define LOWPOWERSTATE_SWITCH 1
+
/*
* This sets pwrdm state (other than mpu & core. Currently only ON &
* RET are supported. Function is assuming that clkdm doesn't have
@@ -114,9 +118,14 @@
return ret;
if (pwrdm_read_pwrst(pwrdm) < PWRDM_POWER_ON) {
- omap2_clkdm_wakeup(pwrdm->pwrdm_clkdms[0]);
- sleep_switch = 1;
- pwrdm_wait_transition(pwrdm);
+ if ((pwrdm_read_pwrst(pwrdm) > state) &&
+ (pwrdm->flags & PWRDM_HAS_LOWPOWERSTATECHANGE)) {
+ sleep_switch = LOWPOWERSTATE_SWITCH;
+ } else {
+ omap2_clkdm_wakeup(pwrdm->pwrdm_clkdms[0]);
+ pwrdm_wait_transition(pwrdm);
+ sleep_switch = FORCEWAKEUP_SWITCH;
+ }
}
ret = pwrdm_set_next_pwrst(pwrdm, state);
@@ -126,12 +135,19 @@
goto err;
}
- if (sleep_switch) {
+ switch (sleep_switch) {
+ case FORCEWAKEUP_SWITCH:
omap2_clkdm_allow_idle(pwrdm->pwrdm_clkdms[0]);
- pwrdm_wait_transition(pwrdm);
- pwrdm_state_switch(pwrdm);
+ break;
+ case LOWPOWERSTATE_SWITCH:
+ pwrdm_set_lowpwrstchange(pwrdm);
+ break;
+ default:
+ return ret;
}
+ pwrdm_wait_transition(pwrdm);
+ pwrdm_state_switch(pwrdm);
err:
return ret;
}
>
> Kevin
>
> > + }
> > omap2_clkdm_wakeup(pwrdm->pwrdm_clkdms[0]);
> > sleep_switch = 1;
> > pwrdm_wait_transition(pwrdm);
--
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 v1 4/9] OMAP2430: hwmod data: add system DMA
On Wed, 15 Dec 2010, G, Manjunath Kondaiah wrote:
> On Tue, Dec 14, 2010 at 07:27:33PM -0700, Paul Walmsley wrote:
> > On Sat, 4 Dec 2010, G, Manjunath Kondaiah wrote:
> >
> > > Add OMAP2430 DMA hwmod data and also add required
> > > DMA device attributes.
> >
> > ...
> >
> > > +/* dma_system -> L3 */
> > > +static struct omap_hwmod_ocp_if omap2430_dma_system__l3 = {
> > > + .master = &omap2430_dma_system_hwmod,
> > > + .slave = &omap2430_l3_main_hwmod,
> > > + .clk= "l3_div_ck",
> >
> > This clock does not exist on OMAP2430. Did you test this on OMAP2430?
>
> Yes. I have tested this on SDP2430. For confirmation, I tested again now.
> It boots up without any issues and all DMA test cases are passing.
Don't you see warnings in the boot messages that this clock cannot be
found?
- Paul
--
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] OMAP: DSS2: Fix build breaks for rfbi.c and dsi.c
On Wed, 2010-12-15 at 08:46 +0530, ext Archit Taneja wrote:
> The following patches caused compilation errors in rfbi.c and dsi.c:
> OMAP: DSS2: Introduce omap_channel argument to DISPC functions used by
> interface drivers
> OMAP: DSS2: Change remaining DISPC functions for new omap_channel argument
>
> Signed-off-by: Archit Taneja
Thanks, looks fine.
Tomi
> ---
> drivers/video/omap2/dss/dsi.c |2 +-
> drivers/video/omap2/dss/dss.h |2 +-
> drivers/video/omap2/dss/rfbi.c |2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> index f00ebb3..ddf3a05 100644
> --- a/drivers/video/omap2/dss/dsi.c
> +++ b/drivers/video/omap2/dss/dsi.c
> @@ -2990,7 +2990,7 @@ static int dsi_configure_dsi_clocks(struct
> omap_dss_device *dssdev)
> cinfo.regm = dssdev->phy.dsi.div.regm;
> cinfo.regm3 = dssdev->phy.dsi.div.regm3;
> cinfo.regm4 = dssdev->phy.dsi.div.regm4;
> - r = dsi_calc_clock_rates(&cinfo);
> + r = dsi_calc_clock_rates(dssdev, &cinfo);
> if (r) {
> DSSERR("Failed to calc dsi clocks\n");
> return r;
> diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
> index dd51d3f..b394951 100644
> --- a/drivers/video/omap2/dss/dss.h
> +++ b/drivers/video/omap2/dss/dss.h
> @@ -431,7 +431,7 @@ void rfbi_dump_regs(struct seq_file *s);
>
> int rfbi_configure(int rfbi_module, int bpp, int lines);
> void rfbi_enable_rfbi(bool enable);
> -void rfbi_transfer_area(omap_dss_device *dssdev, u16 width,
> +void rfbi_transfer_area(struct omap_dss_device *dssdev, u16 width,
> u16 height, void (callback)(void *data), void *data);
> void rfbi_set_timings(int rfbi_module, struct rfbi_timings *t);
> unsigned long rfbi_get_max_tx_rate(void);
> diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
> index c20a185..10a2ffe 100644
> --- a/drivers/video/omap2/dss/rfbi.c
> +++ b/drivers/video/omap2/dss/rfbi.c
> @@ -301,7 +301,7 @@ void omap_rfbi_write_pixels(const void __iomem *buf, int
> scr_width,
> }
> EXPORT_SYMBOL(omap_rfbi_write_pixels);
>
> -void rfbi_transfer_area(omap_dss_device *dssdev, u16 width,
> +void rfbi_transfer_area(struct omap_dss_device *dssdev, u16 width,
> u16 height, void (*callback)(void *data), void *data)
> {
> u32 l;
--
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] OMAP: omap_device: use pdev as parameter to get rt_va
On Wed, 15 Dec 2010, Russell King - ARM Linux wrote: > No it doesn't - this is not a valid reason to bugger about with drivers > to make them non-standard. > > omap_ioremap() can be improved to retain its re-use of static mappings > by having some kind of tree structure or something like that - ioremap > is after all not a performance critical path. There's no need to start > passing virtual addresses to drivers. OK, that's the approach we'll take then, when or if that needs to happen. Omar, please ignore my earlier post and just call ioremap() directly from your driver code. - Paul -- 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 v2 5/6] OMAP2+: hwmod: Add wakeup support for new OMAP4 IPs
The new OMAP4 IPs introduced a new idle mode named smart-idle with wakeup.
This new idlemode replaces the enawakeup for the new IPs but seems to
coexist as well for some legacy IPs (UART, GPIO, MCSPI...)
Add the new SIDLE_SMART_WKUP flag to mark the IPs that support this
capability.
The omap_hwmod_44xx_data.c will have to be updated to add this new flag.
Enable this new mode when applicable in _enable_wakeup, _enable_sysc and
_idle_sysc.
Signed-off-by: Benoit Cousson
Tested-by: Sebastien Guiriec
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/omap_hwmod.c | 16 ++--
arch/arm/plat-omap/include/plat/omap_hwmod.h |5 -
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index c576121..03ffa3b 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -393,7 +393,8 @@ static int _enable_wakeup(struct omap_hwmod *oh, u32 *v)
u32 wakeup_mask;
if (!oh->class->sysc ||
- !(oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP))
+ !((oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP) ||
+ (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP)))
return -EINVAL;
if (!oh->class->sysc->sysc_fields) {
@@ -405,6 +406,9 @@ static int _enable_wakeup(struct omap_hwmod *oh, u32 *v)
*v |= wakeup_mask;
+ if (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP)
+ _set_slave_idlemode(oh, HWMOD_IDLEMODE_SMART_WKUP, v);
+
/* XXX test pwrdm_get_wken for this hwmod's subsystem */
oh->_int_flags |= _HWMOD_WAKEUP_ENABLED;
@@ -424,7 +428,8 @@ static int _disable_wakeup(struct omap_hwmod *oh, u32 *v)
u32 wakeup_mask;
if (!oh->class->sysc ||
- !(oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP))
+ !((oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP) ||
+ (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP)))
return -EINVAL;
if (!oh->class->sysc->sysc_fields) {
@@ -436,6 +441,9 @@ static int _disable_wakeup(struct omap_hwmod *oh, u32 *v)
*v &= ~wakeup_mask;
+ if (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP)
+ _set_slave_idlemode(oh, HWMOD_IDLEMODE_SMART, v);
+
/* XXX test pwrdm_get_wken for this hwmod's subsystem */
oh->_int_flags &= ~_HWMOD_WAKEUP_ENABLED;
@@ -832,6 +840,10 @@ static void _idle_sysc(struct omap_hwmod *oh)
_set_master_standbymode(oh, idlemode, &v);
}
+ /* If slave is in SMARTIDLE, also enable wakeup */
+ if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE))
+ _enable_wakeup(oh, &v);
+
_write_sysconfig(v, oh);
}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index ab99b8c..619877c 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -76,6 +76,8 @@ extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type2;
#define HWMOD_IDLEMODE_FORCE (1 << 0)
#define HWMOD_IDLEMODE_NO (1 << 1)
#define HWMOD_IDLEMODE_SMART (1 << 2)
+/* Slave idle mode flag only */
+#define HWMOD_IDLEMODE_SMART_WKUP (1 << 3)
/**
* struct omap_hwmod_irq_info - MPU IRQs used by the hwmod
@@ -227,11 +229,12 @@ struct omap_hwmod_ocp_if {
/* Macros for use in struct omap_hwmod_sysconfig */
/* Flags for use in omap_hwmod_sysconfig.idlemodes */
-#define MASTER_STANDBY_SHIFT 2
+#define MASTER_STANDBY_SHIFT 4
#define SLAVE_IDLE_SHIFT 0
#define SIDLE_FORCE(HWMOD_IDLEMODE_FORCE << SLAVE_IDLE_SHIFT)
#define SIDLE_NO (HWMOD_IDLEMODE_NO << SLAVE_IDLE_SHIFT)
#define SIDLE_SMART(HWMOD_IDLEMODE_SMART << SLAVE_IDLE_SHIFT)
+#define SIDLE_SMART_WKUP (HWMOD_IDLEMODE_SMART_WKUP << SLAVE_IDLE_SHIFT)
#define MSTANDBY_FORCE (HWMOD_IDLEMODE_FORCE << MASTER_STANDBY_SHIFT)
#define MSTANDBY_NO(HWMOD_IDLEMODE_NO << MASTER_STANDBY_SHIFT)
#define MSTANDBY_SMART (HWMOD_IDLEMODE_SMART << MASTER_STANDBY_SHIFT)
--
1.7.0.4
--
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 v2 2/6] OMAP2+: hwmod: Mark functions used only during initialization with __init
_register, _find_mpu_port_index and _find_mpu_rt_base are static APIs
that will be used only during the omap_hwmod initialization phase.
There is no need to keep them for runtime.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 298fc3b..1a0dd56 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -673,7 +673,7 @@ static void _disable_optional_clocks(struct omap_hwmod *oh)
* Returns the array index of the OCP slave port that the MPU
* addresses the device on, or -EINVAL upon error or not found.
*/
-static int _find_mpu_port_index(struct omap_hwmod *oh)
+static int __init _find_mpu_port_index(struct omap_hwmod *oh)
{
int i;
int found = 0;
@@ -707,7 +707,7 @@ static int _find_mpu_port_index(struct omap_hwmod *oh)
* Return the virtual address of the base of the register target of
* device @oh, or NULL on error.
*/
-static void __iomem *_find_mpu_rt_base(struct omap_hwmod *oh, u8 index)
+static void __iomem * __init _find_mpu_rt_base(struct omap_hwmod *oh, u8 index)
{
struct omap_hwmod_ocp_if *os;
struct omap_hwmod_addr_space *mem;
@@ -1435,7 +1435,7 @@ static int _setup(struct omap_hwmod *oh, void *data)
* that the copy process would be relatively complex due to the large number
* of substructures.
*/
-static int _register(struct omap_hwmod *oh)
+static int __init _register(struct omap_hwmod *oh)
{
int ret, ms_id;
@@ -1587,7 +1587,7 @@ int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh,
void *data),
* listed in @ohs that are valid for this chip. Returns -EINVAL if
* omap_hwmod_init() has already been called or 0 otherwise.
*/
-int omap_hwmod_init(struct omap_hwmod **ohs)
+int __init omap_hwmod_init(struct omap_hwmod **ohs)
{
struct omap_hwmod *oh;
int r;
--
1.7.0.4
--
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 v2 4/6] OMAP2+: hwmod: Disable clocks when hwmod enable fails
From: Rajendra Nayak
In cases where a module (hwmod) does not become accesible on enabling
the main clocks (can happen if there are external clocks needed
for the module to become accesible), make sure the clocks are not
left enabled.
This ensures that when the requisite external dependencies are met
a omap_hwmod_enable and omap_hwmod_idle/shutdown would rightly enable
and disable clocks using clk framework. Leaving the clocks enabled in
the error case causes additional usecounting at the clock framework
level leaving the clock enabled forever.
Signed-off-by: Rajendra Nayak
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 91b011e..c576121 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1233,6 +1233,7 @@ static int _enable(struct omap_hwmod *oh)
_enable_sysc(oh);
}
} else {
+ _disable_clocks(oh);
pr_debug("omap_hwmod: %s: _wait_target_ready: %d\n",
oh->name, r);
}
--
1.7.0.4
--
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 v2 3/6] OMAP2+: hwmod: Remove omap_hwmod_mutex
The hwmod list will be built are init time and never
be modified at runtime. There is no need anymore to protect
the list from concurrent accesses using a mutex.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod.c | 26 --
1 files changed, 4 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 1a0dd56..91b011e 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -159,8 +159,6 @@
/* omap_hwmod_list contains all registered struct omap_hwmods */
static LIST_HEAD(omap_hwmod_list);
-static DEFINE_MUTEX(omap_hwmod_mutex);
-
/* mpu_oh: used to add/remove MPU initiator from sleepdep list */
static struct omap_hwmod *mpu_oh;
@@ -872,7 +870,6 @@ static void _shutdown_sysc(struct omap_hwmod *oh)
* @name: find an omap_hwmod by name
*
* Return a pointer to an omap_hwmod by name, or NULL if not found.
- * Caller must hold omap_hwmod_mutex.
*/
static struct omap_hwmod *_lookup(const char *name)
{
@@ -1443,14 +1440,10 @@ static int __init _register(struct omap_hwmod *oh)
(oh->_state != _HWMOD_STATE_UNKNOWN))
return -EINVAL;
- mutex_lock(&omap_hwmod_mutex);
-
pr_debug("omap_hwmod: %s: registering\n", oh->name);
- if (_lookup(oh->name)) {
- ret = -EEXIST;
- goto ohr_unlock;
- }
+ if (_lookup(oh->name))
+ return -EEXIST;
ms_id = _find_mpu_port_index(oh);
if (!IS_ERR_VALUE(ms_id)) {
@@ -1468,8 +1461,6 @@ static int __init _register(struct omap_hwmod *oh)
ret = 0;
-ohr_unlock:
- mutex_unlock(&omap_hwmod_mutex);
return ret;
}
@@ -1538,9 +1529,7 @@ struct omap_hwmod *omap_hwmod_lookup(const char *name)
if (!name)
return NULL;
- mutex_lock(&omap_hwmod_mutex);
oh = _lookup(name);
- mutex_unlock(&omap_hwmod_mutex);
return oh;
}
@@ -1566,13 +1555,11 @@ int omap_hwmod_for_each(int (*fn)(struct omap_hwmod
*oh, void *data),
if (!fn)
return -EINVAL;
- mutex_lock(&omap_hwmod_mutex);
list_for_each_entry(temp_oh, &omap_hwmod_list, node) {
ret = (*fn)(temp_oh, data);
if (ret)
break;
}
- mutex_unlock(&omap_hwmod_mutex);
return ret;
}
@@ -2112,9 +2099,8 @@ int omap_hwmod_read_hardreset(struct omap_hwmod *oh,
const char *name)
* @fn: callback function pointer to call for each hwmod in class @classname
* @user: arbitrary context data to pass to the callback function
*
- * For each omap_hwmod of class @classname, call @fn. Takes
- * omap_hwmod_mutex to prevent the hwmod list from changing during the
- * iteration. If the callback function returns something other than
+ * For each omap_hwmod of class @classname, call @fn.
+ * If the callback function returns something other than
* zero, the iterator is terminated, and the callback function's return
* value is passed back to the caller. Returns 0 upon success, -EINVAL
* if @classname or @fn are NULL, or passes back the error code from @fn.
@@ -2133,8 +2119,6 @@ int omap_hwmod_for_each_by_class(const char *classname,
pr_debug("omap_hwmod: %s: looking for modules of class %s\n",
__func__, classname);
- mutex_lock(&omap_hwmod_mutex);
-
list_for_each_entry(temp_oh, &omap_hwmod_list, node) {
if (!strcmp(temp_oh->class->name, classname)) {
pr_debug("omap_hwmod: %s: %s: calling callback fn\n",
@@ -2145,8 +2129,6 @@ int omap_hwmod_for_each_by_class(const char *classname,
}
}
- mutex_unlock(&omap_hwmod_mutex);
-
if (ret)
pr_debug("omap_hwmod: %s: iterator terminated early: %d\n",
__func__, ret);
--
1.7.0.4
--
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 v2 6/6] OMAP4: hwmod data: Add SIDLE_SMART_WKUP modes to several IPs
uart, gpio, wd_timer and i2c does support the new smart-idle with wakeup
added in OMAP4.
Add the flag to allow the hwmod core to enable this mode when applicable.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index aaeb3e3..f877cbe 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -665,7 +665,8 @@ static struct omap_hwmod_class_sysconfig omap44xx_gpio_sysc
= {
.sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP |
SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
SYSS_HAS_RESET_STATUS),
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
.sysc_fields= &omap_hwmod_sysc_type1,
};
@@ -1009,7 +1010,8 @@ static struct omap_hwmod_class_sysconfig
omap44xx_i2c_sysc = {
.sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
.sysc_fields= &omap_hwmod_sysc_type1,
};
@@ -1391,7 +1393,8 @@ static struct omap_hwmod_class_sysconfig
omap44xx_uart_sysc = {
.sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP |
SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
SYSS_HAS_RESET_STATUS),
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
.sysc_fields= &omap_hwmod_sysc_type1,
};
@@ -1621,7 +1624,8 @@ static struct omap_hwmod_class_sysconfig
omap44xx_wd_timer_sysc = {
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_SIDLEMODE |
SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
.sysc_fields= &omap_hwmod_sysc_type1,
};
--
1.7.0.4
--
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 v2 1/6] OMAP2+: hwmod: Make omap_hwmod_register private and remove omap_hwmod_unregister
Do not allow omap_hwmod_register to be used outside the core
hwmod code. An omap_hwmod should be registered only at init time.
Remove the omap_hwmod_unregister that is not used today since the
hwmod list will be built once at init time and never be modified
at runtime.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod.c | 137 ++---
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 -
2 files changed, 55 insertions(+), 84 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 81c1097..298fc3b 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1418,60 +1418,8 @@ static int _setup(struct omap_hwmod *oh, void *data)
return 0;
}
-
-
-/* Public functions */
-
-u32 omap_hwmod_read(struct omap_hwmod *oh, u16 reg_offs)
-{
- if (oh->flags & HWMOD_16BIT_REG)
- return __raw_readw(oh->_mpu_rt_va + reg_offs);
- else
- return __raw_readl(oh->_mpu_rt_va + reg_offs);
-}
-
-void omap_hwmod_write(u32 v, struct omap_hwmod *oh, u16 reg_offs)
-{
- if (oh->flags & HWMOD_16BIT_REG)
- __raw_writew(v, oh->_mpu_rt_va + reg_offs);
- else
- __raw_writel(v, oh->_mpu_rt_va + reg_offs);
-}
-
-/**
- * omap_hwmod_set_slave_idlemode - set the hwmod's OCP slave idlemode
- * @oh: struct omap_hwmod *
- * @idlemode: SIDLEMODE field bits (shifted to bit 0)
- *
- * Sets the IP block's OCP slave idlemode in hardware, and updates our
- * local copy. Intended to be used by drivers that have some erratum
- * that requires direct manipulation of the SIDLEMODE bits. Returns
- * -EINVAL if @oh is null, or passes along the return value from
- * _set_slave_idlemode().
- *
- * XXX Does this function have any current users? If not, we should
- * remove it; it is better to let the rest of the hwmod code handle this.
- * Any users of this function should be scrutinized carefully.
- */
-int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh, u8 idlemode)
-{
- u32 v;
- int retval = 0;
-
- if (!oh)
- return -EINVAL;
-
- v = oh->_sysc_cache;
-
- retval = _set_slave_idlemode(oh, idlemode, &v);
- if (!retval)
- _write_sysconfig(v, oh);
-
- return retval;
-}
-
/**
- * omap_hwmod_register - register a struct omap_hwmod
+ * _register - register a struct omap_hwmod
* @oh: struct omap_hwmod *
*
* Registers the omap_hwmod @oh. Returns -EEXIST if an omap_hwmod
@@ -1487,7 +1435,7 @@ int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh,
u8 idlemode)
* that the copy process would be relatively complex due to the large number
* of substructures.
*/
-int omap_hwmod_register(struct omap_hwmod *oh)
+static int _register(struct omap_hwmod *oh)
{
int ret, ms_id;
@@ -1525,6 +1473,57 @@ ohr_unlock:
return ret;
}
+
+/* Public functions */
+
+u32 omap_hwmod_read(struct omap_hwmod *oh, u16 reg_offs)
+{
+ if (oh->flags & HWMOD_16BIT_REG)
+ return __raw_readw(oh->_mpu_rt_va + reg_offs);
+ else
+ return __raw_readl(oh->_mpu_rt_va + reg_offs);
+}
+
+void omap_hwmod_write(u32 v, struct omap_hwmod *oh, u16 reg_offs)
+{
+ if (oh->flags & HWMOD_16BIT_REG)
+ __raw_writew(v, oh->_mpu_rt_va + reg_offs);
+ else
+ __raw_writel(v, oh->_mpu_rt_va + reg_offs);
+}
+
+/**
+ * omap_hwmod_set_slave_idlemode - set the hwmod's OCP slave idlemode
+ * @oh: struct omap_hwmod *
+ * @idlemode: SIDLEMODE field bits (shifted to bit 0)
+ *
+ * Sets the IP block's OCP slave idlemode in hardware, and updates our
+ * local copy. Intended to be used by drivers that have some erratum
+ * that requires direct manipulation of the SIDLEMODE bits. Returns
+ * -EINVAL if @oh is null, or passes along the return value from
+ * _set_slave_idlemode().
+ *
+ * XXX Does this function have any current users? If not, we should
+ * remove it; it is better to let the rest of the hwmod code handle this.
+ * Any users of this function should be scrutinized carefully.
+ */
+int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh, u8 idlemode)
+{
+ u32 v;
+ int retval = 0;
+
+ if (!oh)
+ return -EINVAL;
+
+ v = oh->_sysc_cache;
+
+ retval = _set_slave_idlemode(oh, idlemode, &v);
+ if (!retval)
+ _write_sysconfig(v, oh);
+
+ return retval;
+}
+
/**
* omap_hwmod_lookup - look up a registered omap_hwmod by name
* @name: name of the omap_hwmod to look up
@@ -1604,8 +1603,8 @@ int omap_hwmod_init(struct omap_hwmod **ohs)
oh = *ohs;
while (oh) {
if (omap_chip_is(oh->omap_chip)) {
- r = omap_hwmod_register(oh);
- WARN(r, "omap_hwmod: %s: omap_hwmod_register returned "
+ r = _register(oh);
+ WARN(r, "
[PATCH v2 0/6] OMAP: hwmod core fix and cleanup for 2.6.38
Hi Paul, Here is a small series that just remove the omap_hwmod_mutex and move functions not needed at runtime to the __init section. It fix as well a bug discovered during the on-going hwmod migration of device that does have a functional clock external (mcpdm). It extends as well the fix Kevin did for wakeup for OMAP4 IP with smart idle with wakeup support. The series is based on my for_2.6.38/hwmod_data branch and is available here: git://gitorious.org/omap-pm/linux.git for_2.6.38/hwmod Tested on sdp4430 ES2.0 with omap2plus_defconfig. It still requires some test on OMAP3 and OMAP2. Thanks to Seb Guiriec for testing the SIDLE_SMART_WKUP fix. Regards, Benoit Changes since v1: http://www.spinics.net/lists/linux-omap/msg40580.html: - Add SIDLE_SMART_WKUP flag support for OMAP4 Benoit Cousson (5): OMAP2+: hwmod: Make omap_hwmod_register private and remove omap_hwmod_unregister OMAP2+: hwmod: Mark functions used only during initialization with __init OMAP2+: hwmod: Remove omap_hwmod_mutex OMAP2+: hwmod: Add wakeup support for new OMAP4 IPs OMAP4: hwmod data: Add SIDLE_SMART_WKUP modes to several IPs Rajendra Nayak (1): OMAP2+: hwmod: Disable clocks when hwmod enable fails arch/arm/mach-omap2/omap_hwmod.c | 172 +++--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12 ++- arch/arm/plat-omap/include/plat/omap_hwmod.h |7 +- 3 files changed, 82 insertions(+), 109 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] MTD: NAND: ams-delta: drop omap_read/write, use ioremap
There is a common requirement for not using OMAP specific omap_readw() /
omap_writew() function calls in drivers/, but replace them with
readw() / writew() on ioremap()ped addresses passed from arch/ instead.
The patch implements this idea for the Amstrad Delta NAND driver. To be
able to use the modified driver, the board file is updated with the
platform device I/O resource declaration, which is passed from there.
Created and tested against linux-2.6.37-rc5, on top of recent patch
'MTD: NAND: ams-delta: convert to platform driver'.
Signed-off-by: Janusz Krzysztofik
---
There is one issue indicated by checkpatch.pl --strict:
ERROR: space prohibited after that '-' (ctx:WxW)
#120: FILE: arch/arm/mach-omap1/board-ams-delta.c:188:
+ OMAP_MPUIO_IO_CNTL + sizeof(u32) - 1,
^
but this looks like a false positive to me.
arch/arm/mach-omap1/board-ams-delta.c | 13 -
drivers/mtd/nand/ams-delta.c | 49 +-
2 files changed, 55 insertions(+), 7 deletions(-)
--- linux-2.6.37-rc5/drivers/mtd/nand/ams-delta.c.orig 2010-12-14
20:58:37.0 +0100
+++ linux-2.6.37-rc5/drivers/mtd/nand/ams-delta.c 2010-12-15
15:36:36.0 +0100
@@ -5,6 +5,7 @@
*
* Derived from drivers/mtd/toto.c
* Converted to platform driver by Janusz Krzysztofik
+ * Partially stolen from drivers/mtd/nand/plat_nand.c
*
* 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
@@ -63,9 +64,10 @@ static struct mtd_partition partition_in
static void ams_delta_write_byte(struct mtd_info *mtd, u_char byte)
{
struct nand_chip *this = mtd->priv;
+ void __iomem *io_base = this->priv;
- omap_writew(0, (OMAP1_MPUIO_BASE + OMAP_MPUIO_IO_CNTL));
- omap_writew(byte, this->IO_ADDR_W);
+ writew(0, io_base + OMAP_MPUIO_IO_CNTL);
+ writew(byte, this->IO_ADDR_W);
ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_NWE, 0);
ndelay(40);
ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_NWE,
@@ -76,11 +78,12 @@ static u_char ams_delta_read_byte(struct
{
u_char res;
struct nand_chip *this = mtd->priv;
+ void __iomem *io_base = this->priv;
ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_NRE, 0);
ndelay(40);
- omap_writew(~0, (OMAP1_MPUIO_BASE + OMAP_MPUIO_IO_CNTL));
- res = omap_readw(this->IO_ADDR_R);
+ writew(~0, io_base + OMAP_MPUIO_IO_CNTL);
+ res = readw(this->IO_ADDR_R);
ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_NRE,
AMS_DELTA_LATCH2_NAND_NRE);
@@ -155,8 +158,13 @@ static int ams_delta_nand_ready(struct m
static int __devinit ams_delta_init(struct platform_device *pdev)
{
struct nand_chip *this;
+ struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ void __iomem *io_base;
int err = 0;
+ if (!res)
+ return -ENXIO;
+
/* Allocate memory for MTD device structure and private data */
ams_delta_mtd = kmalloc(sizeof(struct mtd_info) +
sizeof(struct nand_chip), GFP_KERNEL);
@@ -178,9 +186,25 @@ static int __devinit ams_delta_init(stru
/* Link the private data with the MTD structure */
ams_delta_mtd->priv = this;
+ if (!request_mem_region(res->start, resource_size(res),
+ dev_name(&pdev->dev))) {
+ dev_err(&pdev->dev, "request_mem_region failed\n");
+ err = -EBUSY;
+ goto out_free;
+ }
+
+ io_base = ioremap(res->start, resource_size(res));
+ if (io_base == NULL) {
+ dev_err(&pdev->dev, "ioremap failed\n");
+ err = -EIO;
+ goto out_release_io;
+ }
+
+ this->priv = io_base;
+
/* Set address of NAND IO lines */
- this->IO_ADDR_R = (OMAP1_MPUIO_BASE + OMAP_MPUIO_INPUT_LATCH);
- this->IO_ADDR_W = (OMAP1_MPUIO_BASE + OMAP_MPUIO_OUTPUT);
+ this->IO_ADDR_R = io_base + OMAP_MPUIO_INPUT_LATCH;
+ this->IO_ADDR_W = io_base + OMAP_MPUIO_OUTPUT;
this->read_byte = ams_delta_read_byte;
this->write_buf = ams_delta_write_buf;
this->read_buf = ams_delta_read_buf;
@@ -196,6 +220,8 @@ static int __devinit ams_delta_init(stru
this->chip_delay = 30;
this->ecc.mode = NAND_ECC_SOFT;
+ platform_set_drvdata(pdev, io_base);
+
/* Set chip enabled, but */
ams_delta_latch2_write(NAND_MASK, AMS_DELTA_LATCH2_NAND_NRE |
AMS_DELTA_LATCH2_NAND_NWE |
@@ -215,6 +241,11 @@ static int __devinit ams_delta_init(stru
goto out;
out_mtd:
+ platform_set_drvdata(pdev, NULL);
+ iounmap(io_base);
+out_release_io:
+ release_mem_region(res->start, resource_siz
Re: [PATCH v7] OMAP4:keypad: PM runtime
On Wed, Dec 15, 2010 at 2:28 PM, Varadarajan, Charulatha wrote: > Shubhro, > > On Wed, Dec 15, 2010 at 13:24, Datta, Shubhrajyoti > wrote: >> On Wed, Dec 15, 2010 at 11:01 AM, Varadarajan, Charulatha >> wrote: >>> * Shubhrajyoti D [2010-12-15 09:39:58 +0530]: >>> From: Abraham Arce Enable Runtime PM functionality in OMAP4 driver based on the following assumptions A minimal pm runtime get/put approach is implemented in probe/remove calls respectively. - Keyboard controller in wakeup domain so it is always on and power impact may be minimal - In OMAP4 the device control is at module/device level and ick/fclk level control is difficult so cutting of clocks will prevent interrupts. Signed-off-by: Abraham Arce Cc: Kevin Hilman >>> >>> This patch is sent thrice (once with a different subject) but the >>> version numbers are the same. It is not clear what is the intention of this >>> patch without hwmod database update. Am I missing any more patch here? >> Yes missed the version. >> I have updated the change logs to be more descriptive and the subject line. >> >> >> Regarding the hwmod database update. That I deffered for reasons >> - The clock changes need to be there as the update would mean reset of >> clocks. >> - Thought of completing the drivers/input before the hwmod database >> and the board changes. >> - Also currently the driver relies on the uboot settings for clock >> this might remove that dependency. > > I wish to differ here. This patch would not fix the above issues because > pm runtime APIs (for OMAP) purely rely on omap_device and the keypad > driver is not yet hwmod adapted. Atleast put a dependency on any > hwmod series if you had sent them before. OK will send a series with both patches mentioning the dependency. > > -V Charulatha > -- 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 v2 6/7] OMAP2+: omap_hwmod: fix wakeup enable/disable for consistency
From: Kevin Hilman
In the omap_hwmod core, most of the SYSCONFIG register helper
functions do not directly write the register, but instead just modify
a value passed in.
This patch converts the _enable_wakeup() and _disable_wakeup() helper
functions to take a value argument and only modify it instead of
actually writing the register. This makes the wakeup helpers
consistent with the other helper functions and avoids unintentional
problems like the following.
This problem was found after discovering that GPIO wakeups were no
longer functional. The root cause was that the ENAWAKEUP bit of the
SYSCONFIG register was being unintentionaly overwritten, leaving
wakeups disabled after the following two commits were combined:
commit: 9980ce53c97392a3dbdc9d1ac3e455d79b4167ed
OMAP: hwmod: Enable module wakeup if in smartidle
commit: 78f26e872f77b6312273216de1a8f836c6f2e143
OMAP: hwmod: Set autoidle after smartidle during _sysc_enable
There resulting in code in _enable_sysc() was this:
/*
* XXX The clock framework should handle this, by
* calling into this code. But this must wait until the
* clock structures are tagged with omap_hwmod entries
*/
if ((oh->flags & HWMOD_SET_DEFAULT_CLOCKACT) &&
(sf & SYSC_HAS_CLOCKACTIVITY))
_set_clockactivity(oh, oh->class->sysc->clockact, &v);
_write_sysconfig(v, oh);
so here, 'v' has wakeups disabled.
/* If slave is in SMARTIDLE, also enable wakeup */
if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE))
_enable_wakeup(oh);
Here wakeup is enabled in the SYSCONFIG register (but 'v' is not updated)
/*
* Set the autoidle bit only after setting the smartidle bit
* Setting this will not have any impact on the other modules.
*/
if (sf & SYSC_HAS_AUTOIDLE) {
idlemode = (oh->flags & HWMOD_NO_OCP_AUTOIDLE) ?
0 : 1;
_set_module_autoidle(oh, idlemode, &v);
_write_sysconfig(v, oh);
}
And here, SYSCONFIG is updated again using 'v', which does not have
wakeups enabled, resulting in ENAWAKEUP being cleared.
Special thanks to Benoit Cousson for pointing out that wakeups were
supposed to be automatically enabled when a hwmod is enabled, and thus
helping target the root cause of this problem.
Signed-off-by: Paul Walmsley
Cc: Benoit Cousson
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod.c | 32 +---
1 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 12856eb..81c1097 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -390,9 +390,9 @@ static int _set_module_autoidle(struct omap_hwmod *oh, u8
autoidle,
* Allow the hardware module @oh to send wakeups. Returns -EINVAL
* upon error or 0 upon success.
*/
-static int _enable_wakeup(struct omap_hwmod *oh)
+static int _enable_wakeup(struct omap_hwmod *oh, u32 *v)
{
- u32 v, wakeup_mask;
+ u32 wakeup_mask;
if (!oh->class->sysc ||
!(oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP))
@@ -405,9 +405,7 @@ static int _enable_wakeup(struct omap_hwmod *oh)
wakeup_mask = (0x1 << oh->class->sysc->sysc_fields->enwkup_shift);
- v = oh->_sysc_cache;
- v |= wakeup_mask;
- _write_sysconfig(v, oh);
+ *v |= wakeup_mask;
/* XXX test pwrdm_get_wken for this hwmod's subsystem */
@@ -423,9 +421,9 @@ static int _enable_wakeup(struct omap_hwmod *oh)
* Prevent the hardware module @oh to send wakeups. Returns -EINVAL
* upon error or 0 upon success.
*/
-static int _disable_wakeup(struct omap_hwmod *oh)
+static int _disable_wakeup(struct omap_hwmod *oh, u32 *v)
{
- u32 v, wakeup_mask;
+ u32 wakeup_mask;
if (!oh->class->sysc ||
!(oh->class->sysc->sysc_flags & SYSC_HAS_ENAWAKEUP))
@@ -438,9 +436,7 @@ static int _disable_wakeup(struct omap_hwmod *oh)
wakeup_mask = (0x1 << oh->class->sysc->sysc_fields->enwkup_shift);
- v = oh->_sysc_cache;
- v &= ~wakeup_mask;
- _write_sysconfig(v, oh);
+ *v &= ~wakeup_mask;
/* XXX test pwrdm_get_wken for this hwmod's subsystem */
@@ -788,11 +784,11 @@ static void _enable_sysc(struct omap_hwmod *oh)
(sf & SYSC_HAS_CLOCKACTIVITY))
_set_clockactivity(oh, oh->class->sysc->clockact, &v);
- _write_sysconfig(v, oh);
-
/* If slave is in SMARTIDLE, also enable wakeup */
if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE))
- _enable_wakeup(oh);
+ _enable_wakeup(oh, &v);
+
+ _write_sysconfig(v, oh);
/*
* Set the autoidle bit only after setting the smartidle bit
@@ -2011,13 +2007,16 @@ int omap_hwmod_del_initiator_dep
[PATCH v2 3/7] OMAP4: hwmod data: Fix missing address in DMM and EMIF_FW
The DMM is a piece of interconnect that need to be configured properly
for the tiler functionnality. It thus exposes some configuration registers
that were missing previously.
Signed-off-by: Benoit Cousson
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 26 +++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 00a670d..afc35d0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -71,7 +71,15 @@ static struct omap_hwmod_ocp_if omap44xx_l3_main_1__dmm = {
.master = &omap44xx_l3_main_1_hwmod,
.slave = &omap44xx_dmm_hwmod,
.clk= "l3_div_ck",
- .user = OCP_USER_MPU | OCP_USER_SDMA,
+ .user = OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space omap44xx_dmm_addrs[] = {
+ {
+ .pa_start = 0x4e00,
+ .pa_end = 0x4e0007ff,
+ .flags = ADDR_TYPE_RT
+ },
};
/* mpu -> dmm */
@@ -79,7 +87,9 @@ static struct omap_hwmod_ocp_if omap44xx_mpu__dmm = {
.master = &omap44xx_mpu_hwmod,
.slave = &omap44xx_dmm_hwmod,
.clk= "l3_div_ck",
- .user = OCP_USER_MPU | OCP_USER_SDMA,
+ .addr = omap44xx_dmm_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_dmm_addrs),
+ .user = OCP_USER_MPU,
};
/* dmm slave ports */
@@ -119,12 +129,22 @@ static struct omap_hwmod_ocp_if omap44xx_dmm__emif_fw = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_addr_space omap44xx_emif_fw_addrs[] = {
+ {
+ .pa_start = 0x4a20c000,
+ .pa_end = 0x4a20c0ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
/* l4_cfg -> emif_fw */
static struct omap_hwmod_ocp_if omap44xx_l4_cfg__emif_fw = {
.master = &omap44xx_l4_cfg_hwmod,
.slave = &omap44xx_emif_fw_hwmod,
.clk= "l4_div_ck",
- .user = OCP_USER_MPU | OCP_USER_SDMA,
+ .addr = omap44xx_emif_fw_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_emif_fw_addrs),
+ .user = OCP_USER_MPU,
};
/* emif_fw slave ports */
--
1.7.0.4
--
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 v2 7/7] OMAP2430: hwmod data: Use common dev_attr for i2c1 and i2c2
Since i2c1 and i2c2 are using the same data, remove the two previous
instances and use a common i2c_dev_attr one.
Moreover, that will fix the following warning:
arch/arm/mach-omap2/omap_hwmod_2430_data.c:485:
warning: 'i2c_dev_attr' defined but not used
Signed-off-by: Benoit Cousson
Acked-by: Rajendra Nayak
Cc: Paul Walmsley
Cc: Charulatha V
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 16 +---
1 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 0f87736..eb73e5c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -482,14 +482,12 @@ static struct omap_hwmod_class i2c_class = {
.sysc = &i2c_sysc,
};
-static struct omap_i2c_dev_attr i2c_dev_attr;
-
-/* I2C1 */
-
-static struct omap_i2c_dev_attr i2c1_dev_attr = {
+static struct omap_i2c_dev_attr i2c_dev_attr = {
.fifo_depth = 8, /* bytes */
};
+/* I2C1 */
+
static struct omap_hwmod_irq_info i2c1_mpu_irqs[] = {
{ .irq = INT_24XX_I2C1_IRQ, },
};
@@ -530,16 +528,12 @@ static struct omap_hwmod omap2430_i2c1_hwmod = {
.slaves = omap2430_i2c1_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_i2c1_slaves),
.class = &i2c_class,
- .dev_attr = &i2c1_dev_attr,
+ .dev_attr = &i2c_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
/* I2C2 */
-static struct omap_i2c_dev_attr i2c2_dev_attr = {
- .fifo_depth = 8, /* bytes */
-};
-
static struct omap_hwmod_irq_info i2c2_mpu_irqs[] = {
{ .irq = INT_24XX_I2C2_IRQ, },
};
@@ -572,7 +566,7 @@ static struct omap_hwmod omap2430_i2c2_hwmod = {
.slaves = omap2430_i2c2_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_i2c2_slaves),
.class = &i2c_class,
- .dev_attr = &i2c2_dev_attr,
+ .dev_attr = &i2c_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
--
1.7.0.4
--
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 v2 5/7] OMAP4: hwmod & clock data: Fix GPIO opt_clks and ocp_if iclk
Fix opt clocks name in clock framework and hwmod.
Add the missing iclk in the ocp_if structure.
Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flag to ensure
the the GPIO optional clock is enable during reset.
Signed-off-by: Benoit Cousson
Tested-by: Charulatha V
Signed-off-by: Paul Walmsley
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/clock44xx_data.c | 12 ++--
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 23 +--
2 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index a807adc..94a1eb3 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3110,17 +3110,17 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, "emif2_fck",&emif2_fck,
CK_443X),
CLK(NULL, "fdif_fck", &fdif_fck,
CK_443X),
CLK(NULL, "fpka_fck", &fpka_fck,
CK_443X),
- CLK(NULL, "gpio1_dbck", &gpio1_dbclk,
CK_443X),
+ CLK(NULL, "gpio1_dbclk", &gpio1_dbclk,
CK_443X),
CLK(NULL, "gpio1_ick",&gpio1_ick,
CK_443X),
- CLK(NULL, "gpio2_dbck", &gpio2_dbclk,
CK_443X),
+ CLK(NULL, "gpio2_dbclk", &gpio2_dbclk,
CK_443X),
CLK(NULL, "gpio2_ick",&gpio2_ick,
CK_443X),
- CLK(NULL, "gpio3_dbck", &gpio3_dbclk,
CK_443X),
+ CLK(NULL, "gpio3_dbclk", &gpio3_dbclk,
CK_443X),
CLK(NULL, "gpio3_ick",&gpio3_ick,
CK_443X),
- CLK(NULL, "gpio4_dbck", &gpio4_dbclk,
CK_443X),
+ CLK(NULL, "gpio4_dbclk", &gpio4_dbclk,
CK_443X),
CLK(NULL, "gpio4_ick",&gpio4_ick,
CK_443X),
- CLK(NULL, "gpio5_dbck", &gpio5_dbclk,
CK_443X),
+ CLK(NULL, "gpio5_dbclk", &gpio5_dbclk,
CK_443X),
CLK(NULL, "gpio5_ick",&gpio5_ick,
CK_443X),
- CLK(NULL, "gpio6_dbck", &gpio6_dbclk,
CK_443X),
+ CLK(NULL, "gpio6_dbclk", &gpio6_dbclk,
CK_443X),
CLK(NULL, "gpio6_ick",&gpio6_ick,
CK_443X),
CLK(NULL, "gpmc_ick", &gpmc_ick,
CK_443X),
CLK(NULL, "gpu_fck", &gpu_fck,
CK_443X),
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 8524d92..aaeb3e3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -699,6 +699,7 @@ static struct omap_hwmod_addr_space omap44xx_gpio1_addrs[]
= {
static struct omap_hwmod_ocp_if omap44xx_l4_wkup__gpio1 = {
.master = &omap44xx_l4_wkup_hwmod,
.slave = &omap44xx_gpio1_hwmod,
+ .clk= "l4_wkup_clk_mux_ck",
.addr = omap44xx_gpio1_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_gpio1_addrs),
.user = OCP_USER_MPU | OCP_USER_SDMA,
@@ -710,7 +711,7 @@ static struct omap_hwmod_ocp_if *omap44xx_gpio1_slaves[] = {
};
static struct omap_hwmod_opt_clk gpio1_opt_clks[] = {
- { .role = "dbclk", .clk = "sys_32k_ck" },
+ { .role = "dbclk", .clk = "gpio1_dbclk" },
};
static struct omap_hwmod omap44xx_gpio1_hwmod = {
@@ -750,6 +751,7 @@ static struct omap_hwmod_addr_space omap44xx_gpio2_addrs[]
= {
static struct omap_hwmod_ocp_if omap44xx_l4_per__gpio2 = {
.master = &omap44xx_l4_per_hwmod,
.slave = &omap44xx_gpio2_hwmod,
+ .clk= "l4_div_ck",
.addr = omap44xx_gpio2_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_gpio2_addrs),
.user = OCP_USER_MPU | OCP_USER_SDMA,
@@ -761,12 +763,13 @@ static struct omap_hwmod_ocp_if *omap44xx_gpio2_slaves[]
= {
};
static struct omap_hwmod_opt_clk gpio2_opt_clks[] = {
- { .role = "dbclk", .clk = "sys_32k_ck" },
+ { .role = "dbclk", .clk = "gpio2_dbclk" },
};
static struct omap_hwmod omap44xx_gpio2_hwmod = {
.name = "gpio2",
.class = &omap44xx_gpio_hwmod_class,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap44xx_gpio2_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio2_irqs),
.main_clk = "gpio2_ick",
@@ -801,6 +804,7 @@ static struct omap_hwmod_addr_space omap44xx_gpio3_addrs[]
= {
static struct omap_hwmod_ocp_if omap44xx_l4_per__gpio3 = {
.master = &omap44xx_l4_per_hwmod,
.slave = &omap44xx_gpio3_hwmod,
+ .clk= "l4_div_ck"
[PATCH v2 1/7] OMAP4: hwmod data: Fix hwmod entries order
The original OMAP4 hwmod data files is fully generated from HW
database. But since the file is introduced incrementaly along
with driver that uses the data, it has to be splitted by the driver
owner and then re-merged by the maintainer.
Because of the similarity of the data, git is completely lost
during such merge and thus the data does not look like the original one
at the end.
Re-order properly the structures to stay in sync with original data set.
This makes it much easier to diff the autogenerated script output with
what's in mainline, see differences, and generate patches for those
diffs. The goal is to stay in sync with the autogenerated data from now
on.
Add a comment that does contain all the IPs that can have a hwmod, but
do not have it in the file for the moment. It gives a good indication
of the progress.
Signed-off-by: Benoit Cousson
[p...@pwsan.com: updated to apply against current core integration branch,
commit message slightly amplified; fixed opt_clks_cnt whitespace]
Signed-off-by: Paul Walmsley
Cc: Rajendra Nayak
Cc: Govindraj.R
Cc: Charulatha V
Cc: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 1004 +++-
1 files changed, 554 insertions(+), 450 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ae14bd5..872d360 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -171,6 +171,7 @@ static struct omap_hwmod omap44xx_l3_instr_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/* l3_main_1 interface data */
/* l3_main_2 -> l3_main_1 */
static struct omap_hwmod_ocp_if omap44xx_l3_main_2__l3_main_1 = {
.master = &omap44xx_l3_main_2_hwmod,
@@ -387,6 +388,464 @@ static struct omap_hwmod omap44xx_l4_wkup_hwmod = {
};
/*
+ * 'mpu_bus' class
+ * instance(s): mpu_private
+ */
+static struct omap_hwmod_class omap44xx_mpu_bus_hwmod_class = {
+ .name = "mpu_bus",
+};
+
+/* mpu_private interface data */
+/* mpu -> mpu_private */
+static struct omap_hwmod_ocp_if omap44xx_mpu__mpu_private = {
+ .master = &omap44xx_mpu_hwmod,
+ .slave = &omap44xx_mpu_private_hwmod,
+ .clk= "l3_div_ck",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mpu_private slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_mpu_private_slaves[] = {
+ &omap44xx_mpu__mpu_private,
+};
+
+static struct omap_hwmod omap44xx_mpu_private_hwmod = {
+ .name = "mpu_private",
+ .class = &omap44xx_mpu_bus_hwmod_class,
+ .slaves = omap44xx_mpu_private_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_mpu_private_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/*
+ * Modules omap_hwmod structures
+ *
+ * The following IPs are excluded for the moment because:
+ * - They do not need an explicit SW control using omap_hwmod API.
+ * - They still need to be validated with the driver
+ * properly adapted to omap_hwmod / omap_device
+ *
+ * aess
+ * bandgap
+ * c2c
+ * c2c_target_fw
+ * cm_core
+ * cm_core_aon
+ * counter_32k
+ * ctrl_module_core
+ * ctrl_module_pad_core
+ * ctrl_module_pad_wkup
+ * ctrl_module_wkup
+ * debugss
+ * dma_system
+ * dmic
+ * dsp
+ * dss
+ * dss_dispc
+ * dss_dsi1
+ * dss_dsi2
+ * dss_hdmi
+ * dss_rfbi
+ * dss_venc
+ * efuse_ctrl_cust
+ * efuse_ctrl_std
+ * elm
+ * emif1
+ * emif2
+ * fdif
+ * gpmc
+ * gpu
+ * hdq1w
+ * hsi
+ * ipu
+ * iss
+ * iva
+ * kbd
+ * mailbox
+ * mcasp
+ * mcbsp1
+ * mcbsp2
+ * mcbsp3
+ * mcbsp4
+ * mcpdm
+ * mcspi1
+ * mcspi2
+ * mcspi3
+ * mcspi4
+ * mmc1
+ * mmc2
+ * mmc3
+ * mmc4
+ * mmc5
+ * mpu_c0
+ * mpu_c1
+ * ocmc_ram
+ * ocp2scp_usb_phy
+ * ocp_wp_noc
+ * prcm
+ * prcm_mpu
+ * prm
+ * scrm
+ * sl2if
+ * slimbus1
+ * slimbus2
+ * smartreflex_core
+ * smartreflex_iva
+ * smartreflex_mpu
+ * spinlock
+ * timer1
+ * timer10
+ * timer11
+ * timer2
+ * timer3
+ * timer4
+ * timer5
+ * timer6
+ * timer7
+ * timer8
+ * timer9
+ * usb_host_fs
+ * usb_host_hs
+ * usb_otg_hs
+ * usb_phy_cm
+ * usb_tll_hs
+ * usim
+ */
+
+/*
+ * 'gpio' class
+ * general purpose io module
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_gpio_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0114,
+ .sysc_flags = (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_gpio_hwmod_class = {
+ .name = "gpio",
+ .sysc = &omap44xx_gpio_sysc,
+ .rev = 2,
+};
+
+/* gpio dev_attr */
+static struct omap_gpio_dev_attr gpio_dev_attr = {
+ .bank_width = 32,
+
[PATCH v2 2/7] OMAP4: hwmod data: Add SYSS_HAS_RESET_STATUS flag
Update the data for GPIO, UART, WD_TIMER and I2C in order to
support the new reset status flag introduce in the following
commit:
commit 2cb068149c365f1c2b10f2ece6786139527dcc16
OMAP: hwmod: Fix softreset status check for some new OMAP4 IPs
Without this flag properly set, the reset is done, but the hwmod
core code will not wait for the reset completion to continue its
excecution.
Signed-off-by: Benoit Cousson
Tested-by: Charulatha V
Signed-off-by: Paul Walmsley
Cc: Rajendra Nayak
Cc: Govindraj.R
Cc: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 872d360..00a670d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -521,8 +521,9 @@ static struct omap_hwmod_class_sysconfig omap44xx_gpio_sysc
= {
.rev_offs = 0x,
.sysc_offs = 0x0010,
.syss_offs = 0x0114,
- .sysc_flags = (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
- SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= &omap_hwmod_sysc_type1,
};
@@ -855,7 +856,7 @@ static struct omap_hwmod_class_sysconfig omap44xx_i2c_sysc
= {
.syss_offs = 0x0090,
.sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
- SYSC_HAS_SOFTRESET),
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= &omap_hwmod_sysc_type1,
};
@@ -1127,7 +1128,8 @@ static struct omap_hwmod_class_sysconfig
omap44xx_uart_sysc = {
.sysc_offs = 0x0054,
.syss_offs = 0x0058,
.sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP |
- SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= &omap_hwmod_sysc_type1,
};
@@ -1357,7 +1359,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_wd_timer_sysc = {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_SIDLEMODE |
- SYSC_HAS_SOFTRESET),
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= &omap_hwmod_sysc_type1,
};
--
1.7.0.4
--
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 v2 4/7] OMAP4: hwmod data: Add IVA and DSP
Add IVA and DSP hwmods in order to allow the pm code to
initialize properly the processors devices during
omap2_init_processor_devices.
It will avoid the following warnings.
_init_omap_device: could not find omap_hwmod for iva
_init_omap_device: could not find omap_hwmod for dsp
Signed-off-by: Benoit Cousson
Signed-off-by: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 243 +++-
1 files changed, 241 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index afc35d0..8524d92 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -40,7 +40,9 @@
/* Backward references (IPs with Bus Master capability) */
static struct omap_hwmod omap44xx_dmm_hwmod;
+static struct omap_hwmod omap44xx_dsp_hwmod;
static struct omap_hwmod omap44xx_emif_fw_hwmod;
+static struct omap_hwmod omap44xx_iva_hwmod;
static struct omap_hwmod omap44xx_l3_instr_hwmod;
static struct omap_hwmod omap44xx_l3_main_1_hwmod;
static struct omap_hwmod omap44xx_l3_main_2_hwmod;
@@ -170,6 +172,14 @@ static struct omap_hwmod_class omap44xx_l3_hwmod_class = {
};
/* l3_instr interface data */
+/* iva -> l3_instr */
+static struct omap_hwmod_ocp_if omap44xx_iva__l3_instr = {
+ .master = &omap44xx_iva_hwmod,
+ .slave = &omap44xx_l3_instr_hwmod,
+ .clk= "l3_div_ck",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l3_main_3 -> l3_instr */
static struct omap_hwmod_ocp_if omap44xx_l3_main_3__l3_instr = {
.master = &omap44xx_l3_main_3_hwmod,
@@ -180,6 +190,7 @@ static struct omap_hwmod_ocp_if
omap44xx_l3_main_3__l3_instr = {
/* l3_instr slave ports */
static struct omap_hwmod_ocp_if *omap44xx_l3_instr_slaves[] = {
+ &omap44xx_iva__l3_instr,
&omap44xx_l3_main_3__l3_instr,
};
@@ -192,6 +203,14 @@ static struct omap_hwmod omap44xx_l3_instr_hwmod = {
};
/* l3_main_1 interface data */
+/* dsp -> l3_main_1 */
+static struct omap_hwmod_ocp_if omap44xx_dsp__l3_main_1 = {
+ .master = &omap44xx_dsp_hwmod,
+ .slave = &omap44xx_l3_main_1_hwmod,
+ .clk= "l3_div_ck",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l3_main_2 -> l3_main_1 */
static struct omap_hwmod_ocp_if omap44xx_l3_main_2__l3_main_1 = {
.master = &omap44xx_l3_main_2_hwmod,
@@ -218,6 +237,7 @@ static struct omap_hwmod_ocp_if omap44xx_mpu__l3_main_1 = {
/* l3_main_1 slave ports */
static struct omap_hwmod_ocp_if *omap44xx_l3_main_1_slaves[] = {
+ &omap44xx_dsp__l3_main_1,
&omap44xx_l3_main_2__l3_main_1,
&omap44xx_l4_cfg__l3_main_1,
&omap44xx_mpu__l3_main_1,
@@ -232,6 +252,14 @@ static struct omap_hwmod omap44xx_l3_main_1_hwmod = {
};
/* l3_main_2 interface data */
+/* iva -> l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_iva__l3_main_2 = {
+ .master = &omap44xx_iva_hwmod,
+ .slave = &omap44xx_l3_main_2_hwmod,
+ .clk= "l3_div_ck",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l3_main_1 -> l3_main_2 */
static struct omap_hwmod_ocp_if omap44xx_l3_main_1__l3_main_2 = {
.master = &omap44xx_l3_main_1_hwmod,
@@ -250,6 +278,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_2
= {
/* l3_main_2 slave ports */
static struct omap_hwmod_ocp_if *omap44xx_l3_main_2_slaves[] = {
+ &omap44xx_iva__l3_main_2,
&omap44xx_l3_main_1__l3_main_2,
&omap44xx_l4_cfg__l3_main_2,
};
@@ -311,6 +340,14 @@ static struct omap_hwmod_class omap44xx_l4_hwmod_class = {
};
/* l4_abe interface data */
+/* dsp -> l4_abe */
+static struct omap_hwmod_ocp_if omap44xx_dsp__l4_abe = {
+ .master = &omap44xx_dsp_hwmod,
+ .slave = &omap44xx_l4_abe_hwmod,
+ .clk= "ocp_abe_iclk",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l3_main_1 -> l4_abe */
static struct omap_hwmod_ocp_if omap44xx_l3_main_1__l4_abe = {
.master = &omap44xx_l3_main_1_hwmod,
@@ -329,6 +366,7 @@ static struct omap_hwmod_ocp_if omap44xx_mpu__l4_abe = {
/* l4_abe slave ports */
static struct omap_hwmod_ocp_if *omap44xx_l4_abe_slaves[] = {
+ &omap44xx_dsp__l4_abe,
&omap44xx_l3_main_1__l4_abe,
&omap44xx_mpu__l4_abe,
};
@@ -459,7 +497,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* debugss
* dma_system
* dmic
- * dsp
* dss
* dss_dispc
* dss_dsi1
@@ -479,7 +516,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* hsi
* ipu
* iss
- * iva
* kbd
* mailbox
* mcasp
@@ -533,6 +569,91 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
*/
/*
+ * 'dsp' class
+ * dsp sub-system
+ */
+
+static struct omap_hwmod_class omap44xx_dsp_hwmod_class = {
+ .name = "d
[PATCH v2 0/7] OMAP4: hwmod data fixes and update
Hi Paul, Here is a small set of OMAP4 hwmod data updates. Re-order properly the data that were a little bit shuffled during the previous merge window. Add the new reset flags introduced in 2.6.37 and that were not used in the hwmod data. The OMAP2 and OMAP3 fixes should come soon... ...maybe not that soon :-) Fix some missing field in the GPIO OMAP4 hwmod data that I missed during the review. IVA and DSP are added just to allow the processors device creation at boot time and avoid the warnings. Thanks to Charu for testing the GPIO / WD_TIMER changes. Thanks to Govindraj for testing the UART changes. The series is based on your clk_a_2.6.38 branch from your integration tree (git://git.pwsan.com/linux-integration) and is available here: git://gitorious.org/omap-pm/linux.git for_2.6.38/hwmod_data Please note that there is a slight dependency with the following patch due to the name change of the iva fclk: OMAP4: clock data: Add missing DPLL x2 clock node https://patchwork.kernel.org/patch/396612/ Tested on sdp4430 + ES2.0/ES2.1. Regards, Benoit Changes since v1: http://www.spinics.net/lists/arm-kernel/msg107082.html: - Include the changelog fixes from Paul - Fix the order of the dsp hwmod data - Fix OMAP2430 i2c dev_attr warning (minor fix, but not tested) - Include Kevin's patch to fix wakeup in hwmod core Benoit Cousson (6): OMAP4: hwmod data: Fix hwmod entries order OMAP4: hwmod data: Add SYSS_HAS_RESET_STATUS flag OMAP4: hwmod data: Fix missing address in DMM and EMIF_FW OMAP4: hwmod data: Add IVA and DSP OMAP4: hwmod & clock data: Fix GPIO opt_clks and ocp_if iclk OMAP2430: hwmod data: Use common dev_attr for i2c1 and i2c2 Kevin Hilman (1): OMAP2+: omap_hwmod: fix wakeup enable/disable for consistency arch/arm/mach-omap2/clock44xx_data.c | 12 +- arch/arm/mach-omap2/omap_hwmod.c | 32 +- arch/arm/mach-omap2/omap_hwmod_2430_data.c | 16 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 1258 ++-- 4 files changed, 845 insertions(+), 473 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
Re: [PATCH 1/5] OMAP4: hwmod data: Fix hwmod entries order
Hi Paul, On 12/15/2010 2:09 AM, Paul Walmsley wrote: I had to modify this patch in order to apply it. Following is the updated patch. Please let me know if this patch doesn't result in the correct file. - Paul From: Benoit Cousson Date: Tue, 14 Dec 2010 17:37:24 -0700 Subject: [PATCH] OMAP4: hwmod data: Fix hwmod entries order The original OMAP4 hwmod data files is fully generated from HW database. But since the file is introduced incrementaly along with driver that uses the data, it has to be splitted by the driver owner and then re-merged by the maintainer. Because of the similarity of the data, git is completely lost during such merge and thus the data does not look like the original one at the end. Re-order properly the structures to stay in sync with original data set. This makes it much easier to diff the autogenerated script output with what's in mainline, see differences, and generate patches for those diffs. The goal is to stay in sync with the autogenerated data from now on. Add a comment that does contain all the IPs that can have a hwmod, but do not have it in the file for the moment. It gives a good indication of the progress. Signed-off-by: Benoit Cousson [p...@pwsan.com: updated to apply against current core integration branch, commit message slightly amplified; fixed opt_clks_cnt whitespace] It looks like this fix is not in the integration branch. The commit id does have the new changelog but not the opt_clks_cnt fix: e4912451c076b082b5a427fc2541c29fdc93e715. Maybe I didn't use the right branch. Since I have a new hwmod_data patch, I will re-send my series with this fix included just in case. Thanks, Benoit -- 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: twl4030_usb porting advice
On 12/15/10 12:39, Felipe Balbi wrote: On Wed, Dec 15, 2010 at 12:27:10PM +, Tomasz Mloduchowski wrote: I would gladly welcome any pointers that could help me solve this issue. you're connecting a FS/LS device to EHCI port, that doesn't work. OMAP can't handle port handoff to companion OHCI controller, then it fails not being able to enumerate the device. Try remuxing your port to OHCI controller and disabling EHCI from Kconfig. It actually is a HS device (it's a 4-port hub) - when booting the vendor supplied kernel (based off 2.6.32, i.e. pre -IR redesign), the device identifies as follows: Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB with the following boot messages: usb 1-2: new high speed USB device using ehci-omap and address 2 usb 1-2: New USB device found, idVendor=05e3, idProduct=0608 usb 1-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-2: Product: USB2.0 Hub hub 1-2:1.0: USB hub found hub 1-2:1.0: 4 ports detected I've pasted the boot log for my kernel: http://pastie.org/1379102 And the boot log for the original kernel: http://pastie.org/1379100 It could be a bug on the reset sequence on ehci-omap.c, do you have anything connected to any of the hub ports ? Please enable CONFIG_USB_DEBUG on your kernel config and grab a bit more information. Also, boot the machine without the device attached and after booting run: # dmesg -c then attach the device, then grab the output of dmesg. I don't have the ability to disconnect the hub - it's integrated on the board :( I've also made a mistake describing the pastebins - the working, PSP kernel boot log is here: http://pastie.org/1379102 while the non-working git kernel messages are here (with CONFIG_USB_DEBUG): http://pastie.org/1379100 Cheers, Tomasz -- 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/5] omap: dsp: fixes for 2.6.37-rc1
Hi, On Wed, Dec 15, 2010 at 8:00 AM, Paul Walmsley wrote: > I am reviewing these patches for merging, and would appreciate your help. > > On Sun, 7 Nov 2010, Felipe Contreras wrote: > >> Paul already sent these, but I did some minor modifications, mostly to >> minimize >> the amount of changes. >> >> Also, I'm re-sending my memblock patch so that the driver can actually be >> compiled. > > It looks like the memblock change has been applied already. > >> With these, and reverting the iommu patches[1], the driver should be >> working. I >> don't see a more straight-forward way to achieve that. >> >> Paul Walmsley (4): >> omap: control: add functions for DSP boot >> omap: pm: use control functions in DSP reset code >> omap: dsp: add boot control functions >> staging: tidspbridge: use boot control functions > > It seems that we still need to apply these. Could you please rebase these > against the 'integration-2.6.38-20101214-013' tag available from > git://git.pwsan.com/linux-integration? Ok, will do. > Also, a few changes are needed in the patches themselves. Here are two > that I noticed: > > First, please add my Signed-off-by: on the first > patch, "omap: control: add functions for DSP boot", as discussed > previously. Yes, I haven't got around to do so. I thought I still had time before .38 merge window. > Second, I notice that you wiped out almost my entire original commit > message from "omap: dsp: add boot control functions", and did not add a > note in brackets explaining what you did or why. I strongly object to > this. The commit message is as much a part of that patch as the code is > and I would appreciate it if you would either add it back in, or add a > bracketed note next to your Signed-off-by: explaining why the commit > message needed to be removed. Huh? Before: mach-omap2/control: --- Add two functions for OMAP2430/OMAP3 IVA2 DSP boot control. These registers wound up in the System Control Module. Other kernel code that wishes to control the DSP's boot process should now use these functions to do so; subsequent patches implement this in the two in-tree users of these functions. This patch is functionally untested; that is for the DSP/Bridge programmers to do. --- tidspbridge/core/tiomap3430.c: tidspbridge/include/dspbridge/host_os.h: --- DSPBridge currently tries to __raw_writel() to the System Control Module to control the DSP boot process. This is a layering violation; this is SoC-specific code, and belongs in a file in arch/arm/mach-omap2/*. None of those CM and PRM register accesses through struct platform_data belong under drivers/. (Nor would they belong in DSP platform init code in arch/arm/mach-omap2/* - such code must use the clock, clockdomain, powerdomain, omap_device, and omap_hwmod layers that are provided for this purpose.) The immediate problem, however, is that after commit 346a5c890a55495c718394b74214be1de9303cf6, this code can no longer compile. So to fix this immediate problem, convert the DSP boot control code to use platform_data function pointers. The DSPBridge-on-OMAP3 people also need to implement a file in arch/arm/mach-omap2/ to populate the platform_data function pointers. Such a file does not yet exist in the mainline tree, so it's unlikely that DSPBridge is usable in the mainline until this is done. --- After: mach-omap2/control: --- Add two functions for OMAP2430/OMAP3 IVA2 DSP boot control. These registers wound up in the System Control Module. Other kernel code that wishes to control the DSP's boot process should now use these functions to do so; subsequent patches implement this in the two in-tree users of these functions. --- mach-omap2/dsp: --- Would be needed to avoid using SCM directly. --- tidspbridge/core/tiomap3430.c: --- Use the new functions from SCM layer instead of handling registers directly with __raw_writel, as explained in: http://marc.info/?l=linux-omap&m=128779652429922&w=2 This fixes the build on 2.6.37 since control.h is not available for drivers any more. --- I thought it was evident that patch 1 adds some functions, and says those functions should be used to modify SCM registers, patch 2 adds callbacks to them, and patch 3 uses those callbacks instead of directly modifying the registers. I could add "Such access is a layer violation; it should be handled by the platform control (arch/arm/mach-omap2/control.c)". -- Felipe Contreras -- 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/2] arm: mach-omap2: Kconfig: devkit8000 should select needed options
It's not possible to compile a kernel for this board without I2C, MFD_SUPPORT and TWL4030_CORE, so those should be selected. This will prevent build errors when trying out different configurations. Signed-off-by: Aaro Koskinen --- arch/arm/mach-omap2/Kconfig |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index db20351..bb32f35 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -129,6 +129,10 @@ config MACH_DEVKIT8000 default y select OMAP_PACKAGE_CUS select OMAP_MUX + select I2C + select I2C_OMAP + select MFD_SUPPORT + select TWL4030_CORE config MACH_OMAP_LDP bool "OMAP3 LDP board" -- 1.5.6.5 -- 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/2] arm: mach-omap2: Kconfig: fix incorrect option
There is no MFD config option, MFD_SUPPORT should be selected instead. This will prevent build errors when trying out different configurations. Signed-off-by: Aaro Koskinen --- arch/arm/mach-omap2/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index ab784bf..db20351 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -15,7 +15,7 @@ config ARCH_OMAP2PLUS_TYPICAL select SERIAL_OMAP_CONSOLE select I2C select I2C_OMAP - select MFD + select MFD_SUPPORT select MENELAUS if ARCH_OMAP2 select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 -- 1.5.6.5 -- 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] arm: mach-omap2: hsmmc_reset: fix clk_get() error handling
clk_get() return value should be checked with IS_ERR(). Furthermore,
clocks should be put and disabled properly.
Signed-off-by: Aaro Koskinen
---
arch/arm/mach-omap2/devices.c | 44 ++--
1 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 5a0c148..1bca147 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -638,6 +638,7 @@ static struct platform_device dummy_pdev = {
static void __init omap_hsmmc_reset(void)
{
u32 i, nr_controllers;
+ struct clk *iclk, *fclk;
if (cpu_is_omap242x())
return;
@@ -647,7 +648,6 @@ static void __init omap_hsmmc_reset(void)
for (i = 0; i < nr_controllers; i++) {
u32 v, base = 0;
- struct clk *iclk, *fclk;
struct device *dev = &dummy_pdev.dev;
switch (i) {
@@ -678,19 +678,16 @@ static void __init omap_hsmmc_reset(void)
dummy_pdev.id = i;
dev_set_name(&dummy_pdev.dev, "mmci-omap-hs.%d", i);
iclk = clk_get(dev, "ick");
- if (iclk && clk_enable(iclk))
- iclk = NULL;
+ if (IS_ERR(iclk))
+ goto err1;
+ if (clk_enable(iclk))
+ goto err2;
fclk = clk_get(dev, "fck");
- if (fclk && clk_enable(fclk))
- fclk = NULL;
-
- if (!iclk || !fclk) {
- printk(KERN_WARNING
- "%s: Unable to enable clocks for MMC%d, "
- "cannot reset.\n", __func__, i);
- break;
- }
+ if (IS_ERR(fclk))
+ goto err3;
+ if (clk_enable(fclk))
+ goto err4;
omap_writel(MMCHS_SYSCONFIG_SWRESET, base + MMCHS_SYSCONFIG);
v = omap_readl(base + MMCHS_SYSSTATUS);
@@ -698,15 +695,22 @@ static void __init omap_hsmmc_reset(void)
MMCHS_SYSSTATUS_RESETDONE))
cpu_relax();
- if (fclk) {
- clk_disable(fclk);
- clk_put(fclk);
- }
- if (iclk) {
- clk_disable(iclk);
- clk_put(iclk);
- }
+ clk_disable(fclk);
+ clk_put(fclk);
+ clk_disable(iclk);
+ clk_put(iclk);
}
+ return;
+
+err4:
+ clk_put(fclk);
+err3:
+ clk_disable(iclk);
+err2:
+ clk_put(iclk);
+err1:
+ printk(KERN_WARNING "%s: Unable to enable clocks for MMC%d, "
+ "cannot reset.\n", __func__, i);
}
#else
static inline void omap_hsmmc_reset(void) {}
--
1.5.6.5
--
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: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera
On 13 December 2010 16:29, Russell King - ARM Linux
wrote:
> On Mon, Dec 13, 2010 at 03:52:20PM +, Catalin Marinas wrote:
>> On 10 December 2010 17:03, Russell King - ARM Linux
>> wrote:
>> > On Fri, Dec 10, 2010 at 12:03:07PM +0100, Janusz Krzysztofik wrote:
>> >> void __init omap1_camera_init(void *info)
>> >> {
>> >> struct platform_device *dev = &omap1_camera_device;
>> >> + dma_addr_t paddr = omap1_camera_phys_mempool_base;
>> >> + dma_addr_t size = omap1_camera_phys_mempool_size;
>> >> int ret;
>> >>
>> >> dev->dev.platform_data = info;
>> >>
>> >> + if (paddr) {
>> >> + if (dma_declare_coherent_memory(&dev->dev, paddr, paddr,
>> >> size,
>> >> + DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE))
>> >
>> > Although this works, you're ending up with SDRAM being mapped via
>> > ioremap, which uses MT_DEVICE - so what is SDRAM ends up being
>> > mapped as if it were a device.
>>
>> BTW, does the generic dma_declare_coherent_memory() does the correct
>> thing in using ioremap()?
>
> I argue it doesn't, as I said above. It means we map SDRAM as device
> memory, and as I understand the way interconnects work, it's entirely
> possible that this may not result in the SDRAM being accessible.
[...]
> So, not only does this fail the kernel's own rules, but as we already know,
> it fails the architecture's restrictions with multiple mappings of memory
> when used with SDRAM, and it also maps main memory as a device. I wonder
> how many more things this broken API needs to do wrong before it's current
> implementation is consigned to the circular filing cabinet.
Should we not try to fix the generic code and still allow platforms to
use dma_declare_coherent_memory() in a safer way? I guess it may need
some arguing/explanation on linux-arch.
--
Catalin
--
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 01/11] OMAP4: PRCM: add OMAP4-specific accessor/mutatorfunctions
On 12/15/2010 7:48 AM, Paul Walmsley wrote: Hi Rajendra On Wed, 8 Dec 2010, Rajendra Nayak wrote: Would it help if we can avoid one more level of function indirection (given that these are low level apis) and store the Partition offsets in the tables above (instead of func pointers) and do some thing like this. return __raw_readl(OMAP2_L4_IO_ADDRESS(cm_read_offset[part], module, idx)); with the table entries of cm_read_offset looking something like + [OMAP4430_PRM_PARTITION]= OMAP4430_PRM_BASE, + [OMAP4430_CM1_PARTITION]= OMAP4430_CM1_BASE, + [OMAP4430_CM2_PARTITION]= OMAP4430_CM2_BASE, I did a version of this patch without the extra level of indirection. I'm not sure if it's better or worse. The original seems conceptually cleaner to me, but this revised version is probably slightly more efficient. Do you (or anyone else) have a strong preference? I do not have a strong but a slight preference for that. It is a little bit more readable that function pointers for my point of view. On the other hand, the function pointers might allow to handle tricky differences that this solution will not. Regards, Benoit -- 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: twl4030_usb porting advice
On Wed, Dec 15, 2010 at 12:27:10PM +, Tomasz Mloduchowski wrote: I would gladly welcome any pointers that could help me solve this issue. you're connecting a FS/LS device to EHCI port, that doesn't work. OMAP can't handle port handoff to companion OHCI controller, then it fails not being able to enumerate the device. Try remuxing your port to OHCI controller and disabling EHCI from Kconfig. It actually is a HS device (it's a 4-port hub) - when booting the vendor supplied kernel (based off 2.6.32, i.e. pre -IR redesign), the device identifies as follows: Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB with the following boot messages: usb 1-2: new high speed USB device using ehci-omap and address 2 usb 1-2: New USB device found, idVendor=05e3, idProduct=0608 usb 1-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-2: Product: USB2.0 Hub hub 1-2:1.0: USB hub found hub 1-2:1.0: 4 ports detected I've pasted the boot log for my kernel: http://pastie.org/1379102 And the boot log for the original kernel: http://pastie.org/1379100 It could be a bug on the reset sequence on ehci-omap.c, do you have anything connected to any of the hub ports ? Please enable CONFIG_USB_DEBUG on your kernel config and grab a bit more information. Also, boot the machine without the device attached and after booting run: # dmesg -c then attach the device, then grab the output of dmesg. -- balbi -- 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: twl4030_usb porting advice
I would gladly welcome any pointers that could help me solve this issue. you're connecting a FS/LS device to EHCI port, that doesn't work. OMAP can't handle port handoff to companion OHCI controller, then it fails not being able to enumerate the device. Try remuxing your port to OHCI controller and disabling EHCI from Kconfig. It actually is a HS device (it's a 4-port hub) - when booting the vendor supplied kernel (based off 2.6.32, i.e. pre -IR redesign), the device identifies as follows: Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB with the following boot messages: usb 1-2: new high speed USB device using ehci-omap and address 2 usb 1-2: New USB device found, idVendor=05e3, idProduct=0608 usb 1-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-2: Product: USB2.0 Hub hub 1-2:1.0: USB hub found hub 1-2:1.0: 4 ports detected I've pasted the boot log for my kernel: http://pastie.org/1379102 And the boot log for the original kernel: http://pastie.org/1379100 Cheers, Tomasz -- 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 13/14] OMAP2/3: PRCM: split OMAP2/3-specific PRCM code into OMAP2/3-specific files
Hi,
On Wed, Dec 15, 2010 at 6:50 AM, Paul Walmsley wrote:
> On Mon, 6 Dec 2010, Paul Walmsley wrote:
>
>> In preparation for adding OMAP4-specific PRCM accessor/mutator
>> functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific
>> files. Most of what was in mach-omap2/{cm,prm}.{c,h} has now been
>> moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was
>> OMAP2xxx/3xxx-specific.
>>
>> This process also requires the #includes in each of these files to be
>> changed to reference the new file name. As part of doing so, add some
>> comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use
>> "sideways includes", to indicate that these users of the PRM/CM includes
>> should not be doing so.
>
> This patch has been updated to also take care of getting DSPBridge to
> build again. Omar, Felipe, could you please take a look at the
> mach-omap2/dsp.c and _tiomap.h changes and ack them?
I would prefer the XX comments in a separate chunk:
/*
* license notice
*/
/*
* XXX
*/
But otherwise it's ok.
--
Felipe Contreras
--
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 v1 3/9] OMAP2420: hwmod data: add system DMA]
On Wed, Dec 15, 2010 at 04:39:17PM +0530, G, Manjunath Kondaiah wrote:
> On Tue, Dec 14, 2010 at 07:25:23PM -0700, Paul Walmsley wrote:
> > Manju
> >
> > On Sat, 4 Dec 2010, G, Manjunath Kondaiah wrote:
> >
> > > Add OMAP2420 DMA hwmod data and also add required
> > > DMA device attributes.
> > >
> > > Signed-off-by: G, Manjunath Kondaiah
> > > Cc: Benoit Cousson
> > > Cc: Kevin Hilman
> > > Cc: Santosh Shilimkar
> > >
> > > +/* dma_system -> L3 */
> > > +static struct omap_hwmod_ocp_if omap2420_dma_system__l3 = {
> > > + .master = &omap2420_dma_system_hwmod,
> > > + .slave = &omap2420_l3_main_hwmod,
> > > + .clk= "l3_div_ck",
> >
> > This clock does not exist on OMAP2420. Did you test this patch on 2420?
>
> ok. will be replaced with "sdma_ick". I don't have 2420 for testing. I
> tested it on 2430. My understanding is that, DMA clock interface is same
> for 2420 and 2430. Correct me if am wrong.
Looking into omap3/omap4 structures, this entry takes core l3 clock.
This should be "sdma_fck" since it's parent is core_l3_ck.
Pls confirm.
-Manjunath
--
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: twl4030_usb porting advice
On Wed, Dec 15, 2010 at 11:55:24AM +, Tomasz Mloduchowski wrote: Hi! I'm trying to port the support patches for an OMAP3530 based development kit by Technexion. Technexion provides patches for PSP kernel trees, I need to use a kernel with modern IR stack, so I'm developing against linux-omap-2.6.git I'm mostly done with the initial port, however, I'm stuck with the following issue: [2.991973] ehci-omap ehci-omap.0: port 2 full speed --> companion [2.992034] ehci-omap ehci-omap.0: GetStatus port:2 status 003801 0 ACK POWER OWNER sig=j CONNECT [2.992095] hub 1-0:1.0: port 2 not reset yet, waiting 50ms [3.055511] asoc: twl4030-hifi <-> omap-mcbsp-dai.1 mapping ok [3.061920] ehci-omap ehci-omap.0: GetStatus port:2 status 003002 0 ACK POWER OWNER sig=se0 CSC [3.061981] hub 1-0:1.0: unable to enumerate USB device on port 2 [3.068389] hub 1-0:1.0: state 7 ports 3 chg evt 0004 I would gladly welcome any pointers that could help me solve this issue. you're connecting a FS/LS device to EHCI port, that doesn't work. OMAP can't handle port handoff to companion OHCI controller, then it fails not being able to enumerate the device. Try remuxing your port to OHCI controller and disabling EHCI from Kconfig. You should be using ohci-omap3.c driver. -- balbi -- 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
twl4030_usb porting advice
Hi! I'm trying to port the support patches for an OMAP3530 based development kit by Technexion. Technexion provides patches for PSP kernel trees, I need to use a kernel with modern IR stack, so I'm developing against linux-omap-2.6.git I'm mostly done with the initial port, however, I'm stuck with the following issue: [2.991973] ehci-omap ehci-omap.0: port 2 full speed --> companion [2.992034] ehci-omap ehci-omap.0: GetStatus port:2 status 003801 0 ACK POWER OWNER sig=j CONNECT [2.992095] hub 1-0:1.0: port 2 not reset yet, waiting 50ms [3.055511] asoc: twl4030-hifi <-> omap-mcbsp-dai.1 mapping ok [3.061920] ehci-omap ehci-omap.0: GetStatus port:2 status 003002 0 ACK POWER OWNER sig=se0 CSC [3.061981] hub 1-0:1.0: unable to enumerate USB device on port 2 [3.068389] hub 1-0:1.0: state 7 ports 3 chg evt 0004 I would gladly welcome any pointers that could help me solve this issue. Cheers, Tomasz -- 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] MTD: NAND: ams-delta: select for built-in by default
Now that the Amstrad Delta NAND driver is converted to a platform driver, which prevents it from interfering with other unrelated hardware in multiple OMAP1 cpu and machine configurations, it can be automatically configured for being built into the kernel if the Amstrad Delta board is also selected. Created against linux-2.6.37-rc5. Signed-off-by: Janusz Krzysztofik --- drivers/mtd/nand/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-2.6.37-rc5/drivers/mtd/nand/Kconfig.orig 2010-12-09 23:08:16.0 +0100 +++ linux-2.6.37-rc5/drivers/mtd/nand/Kconfig 2010-12-11 15:58:12.0 +0100 @@ -96,6 +96,7 @@ config MTD_NAND_SPIA config MTD_NAND_AMS_DELTA tristate "NAND Flash device on Amstrad E3" depends on MACH_AMS_DELTA + default y help Support for NAND flash on Amstrad E3 (Delta). -- 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 01/11] OMAP4: PRCM: add OMAP4-specific accessor/mutatorfunctions
> -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Wednesday, December 15, 2010 12:18 PM > To: Rajendra Nayak > Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > Santosh Shilimkar; Benoit Cousson > Subject: RE: [PATCH 01/11] OMAP4: PRCM: add OMAP4-specific > accessor/mutatorfunctions > > Hi Rajendra > > On Wed, 8 Dec 2010, Rajendra Nayak wrote: > > > Would it help if we can avoid one more level of function > > indirection (given that these are low level apis) and store > > the Partition offsets in the tables above (instead of func > > pointers) and do some thing like this. > > > > return __raw_readl(OMAP2_L4_IO_ADDRESS(cm_read_offset[part], > > module, idx)); > > > > with the table entries of cm_read_offset looking something like > > > + [OMAP4430_PRM_PARTITION]= OMAP4430_PRM_BASE, > > > + [OMAP4430_CM1_PARTITION]= OMAP4430_CM1_BASE, > > > + [OMAP4430_CM2_PARTITION]= OMAP4430_CM2_BASE, > > I did a version of this patch without the extra level of indirection. > I'm not sure if it's better or worse. The original seems conceptually > cleaner to me, but this revised version is probably slightly more > efficient. Do you (or anyone else) have a strong preference? > I think we need to cut down on number of indirections we need to do to reach to hardware register read/writes to be more efficient especially for low level accessory APIs. We use them in performance/latency critical path more often and having these accessory apis as fast as they can be, keeping all the needed abstraction should be ideal. Again not a very strong opinion here but I like this version than the previous just on the fact that it's cut down one indirection and still gives the same flexibility. :) > Note that the patch has not yet been boot-tested, but I think the > principle is clear. > > > - Paul > > From: Paul Walmsley > Date: Tue, 14 Dec 2010 22:23:49 -0700 > Subject: [PATCH] OMAP4: PRCM: add OMAP4-specific accessor/mutator > functions > > In some ways, the OMAP4 PRCM register layout is quite different than > the OMAP2/3 PRCM register layout. For example, on OMAP2/3, from a > register layout point of view, all CM instances were located in the CM > subsystem, and all PRM instances were located in the PRM subsystem. > OMAP4 changes this. Now, for example, some CM instances, such as > WKUP_CM and EMU_CM, are located in the system PRM subsystem. And a > "local PRCM" exists for the MPU - this PRCM combines registers that > would normally appear in both CM and PRM instances, but uses its own > register layout which matches neither the OMAP2/3 PRCM layout nor the > OMAP4 PRCM layout. > > To try to deal with this, introduce some new functions, omap4_cminst* > and omap4_prminst*. The former is to be used when writing to a CM > instance register (no matter what subsystem or hardware module it > exists in), and the latter, similarly, with PRM instance registers. > To determine which "PRCM partition" to write to, the functions take a > PRCM instance ID argument. Subsequent patches add these partition IDs > to the OMAP4 powerdomain and clockdomain definitions. > > As far as I can see, there's really no good way to handle these types > of register access inconsistencies. This patch seemed like the least > bad approach. > > Moving forward, the long-term goal is to remove all direct PRCM > register access from the PM code. PRCM register access should go > through layers such as the powerdomain and clockdomain code that can > hide the details of how to interact with the specific hardware > variant. > > While here, rename cm4xxx.c to cm44xx.c to match the naming convention > of the other OMAP4 PRCM files. > > Thanks to Santosh Shilimkar for some comments. > > Signed-off-by: Paul Walmsley > Cc: Benoīt Cousson > Cc: Rajendra Nayak > Cc: Santosh Shilimkar > --- > arch/arm/mach-omap2/Makefile |4 +- > arch/arm/mach-omap2/cm1_44xx.h |5 ++ > arch/arm/mach-omap2/cm2_44xx.h |6 ++ > arch/arm/mach-omap2/cm44xx.c | 52 +++ > arch/arm/mach-omap2/cm4xxx.c | 62 -- > arch/arm/mach-omap2/cminst44xx.c | 109 > > arch/arm/mach-omap2/cminst44xx.h | 25 +++ > arch/arm/mach-omap2/prcm.c | 26 +--- > arch/arm/mach-omap2/prcm44xx.h | 42 > arch/arm/mach-omap2/prcm_mpu44xx.c | 45 + > arch/arm/mach-omap2/prcm_mpu44xx.h |8 +++ > arch/arm/mach-omap2/prm44xx.c | 65 +++ > arch/arm/mach-omap2/prm44xx.h |6 ++ > arch/arm/mach-omap2/prminst44xx.c | 66 +++ > arch/arm/mach-omap2/prminst44xx.h | 25 +++ > arch/arm/plat-omap/include/plat/prcm.h |7 +- > 16 files changed, 462 insertions(+), 91 deletions(-) > create mode 100644 arch/arm/mach-omap2/cm44xx.c > delete mode 100644 arch
RE: [PATCH 00/11] OMAP: PRCM/powerdomain/clockdomain patches for 2.6.38,part two
> -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Wednesday, December 15, 2010 9:28 AM > To: Rajendra Nayak > Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Mark Brown; Benoit Cousson; Kevin Hilman; > Peter Ujfalusi; Santosh Shilimkar; Jarkko Nikula; Liam Girdwood > Subject: RE: [PATCH 00/11] OMAP: PRCM/powerdomain/clockdomain patches for 2.6.38,part two > > On Tue, 14 Dec 2010, Rajendra Nayak wrote: > > > Boot tested on 2430/3430/4430SDP. Tested RET/OFF mode in suspend > > on 3430SDP with minimal config (omap3_pm_defconfig). > > Thanks for testing this. Would you like me to add Tested-by:'s ? Sure, Tested-by: Rajendra Nayak > > Also, I still plan to make that change that you proposed to cause the > prminst, cminst functions to read/write directly to the registers... > soon... Thanks, already had a look. > > > - Paul -- 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 01/11] OMAP4: PRCM: add OMAP4-specific accessor/mutatorfunctions
Hi Paul, > -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Wednesday, December 15, 2010 12:18 PM > To: Rajendra Nayak > Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Santosh Shilimkar; Benoit Cousson > Subject: RE: [PATCH 01/11] OMAP4: PRCM: add OMAP4-specific accessor/mutatorfunctions > > Hi Rajendra > > On Wed, 8 Dec 2010, Rajendra Nayak wrote: > > > Would it help if we can avoid one more level of function > > indirection (given that these are low level apis) and store > > the Partition offsets in the tables above (instead of func > > pointers) and do some thing like this. > > > > return __raw_readl(OMAP2_L4_IO_ADDRESS(cm_read_offset[part], > > module, idx)); > > > > with the table entries of cm_read_offset looking something like > > > + [OMAP4430_PRM_PARTITION]= OMAP4430_PRM_BASE, > > > + [OMAP4430_CM1_PARTITION]= OMAP4430_CM1_BASE, > > > + [OMAP4430_CM2_PARTITION]= OMAP4430_CM2_BASE, > > I did a version of this patch without the extra level of indirection. > I'm not sure if it's better or worse. The original seems conceptually > cleaner to me, but this revised version is probably slightly more > efficient. Do you (or anyone else) have a strong preference? Thanks, the changes are very much in line with what I was trying to suggest. The concern was mainly performance/efficiency but otherwise I don't have a strong preference one way or the other. Regards, Rajendra > > Note that the patch has not yet been boot-tested, but I think the > principle is clear. > > > - Paul > > From: Paul Walmsley > Date: Tue, 14 Dec 2010 22:23:49 -0700 > Subject: [PATCH] OMAP4: PRCM: add OMAP4-specific accessor/mutator functions > > In some ways, the OMAP4 PRCM register layout is quite different than > the OMAP2/3 PRCM register layout. For example, on OMAP2/3, from a > register layout point of view, all CM instances were located in the CM > subsystem, and all PRM instances were located in the PRM subsystem. > OMAP4 changes this. Now, for example, some CM instances, such as > WKUP_CM and EMU_CM, are located in the system PRM subsystem. And a > "local PRCM" exists for the MPU - this PRCM combines registers that > would normally appear in both CM and PRM instances, but uses its own > register layout which matches neither the OMAP2/3 PRCM layout nor the > OMAP4 PRCM layout. > > To try to deal with this, introduce some new functions, omap4_cminst* > and omap4_prminst*. The former is to be used when writing to a CM > instance register (no matter what subsystem or hardware module it > exists in), and the latter, similarly, with PRM instance registers. > To determine which "PRCM partition" to write to, the functions take a > PRCM instance ID argument. Subsequent patches add these partition IDs > to the OMAP4 powerdomain and clockdomain definitions. > > As far as I can see, there's really no good way to handle these types > of register access inconsistencies. This patch seemed like the least > bad approach. > > Moving forward, the long-term goal is to remove all direct PRCM > register access from the PM code. PRCM register access should go > through layers such as the powerdomain and clockdomain code that can > hide the details of how to interact with the specific hardware > variant. > > While here, rename cm4xxx.c to cm44xx.c to match the naming convention > of the other OMAP4 PRCM files. > > Thanks to Santosh Shilimkar for some comments. > > Signed-off-by: Paul Walmsley > Cc: Benoīt Cousson > Cc: Rajendra Nayak > Cc: Santosh Shilimkar > --- > arch/arm/mach-omap2/Makefile |4 +- > arch/arm/mach-omap2/cm1_44xx.h |5 ++ > arch/arm/mach-omap2/cm2_44xx.h |6 ++ > arch/arm/mach-omap2/cm44xx.c | 52 +++ > arch/arm/mach-omap2/cm4xxx.c | 62 -- > arch/arm/mach-omap2/cminst44xx.c | 109 > arch/arm/mach-omap2/cminst44xx.h | 25 +++ > arch/arm/mach-omap2/prcm.c | 26 +--- > arch/arm/mach-omap2/prcm44xx.h | 42 > arch/arm/mach-omap2/prcm_mpu44xx.c | 45 + > arch/arm/mach-omap2/prcm_mpu44xx.h |8 +++ > arch/arm/mach-omap2/prm44xx.c | 65 +++ > arch/arm/mach-omap2/prm44xx.h |6 ++ > arch/arm/mach-omap2/prminst44xx.c | 66 +++ > arch/arm/mach-omap2/prminst44xx.h | 25 +++ > arch/arm/plat-omap/include/plat/prcm.h |7 +- > 16 files changed, 462 insertions(+), 91 deletions(-) > create mode 100644 arch/arm/mach-omap2/cm44xx.c > delete mode 100644 arch/arm/mach-omap2/cm4xxx.c > create mode 100644 arch/arm/mach-omap2/cminst44xx.c > create mode 100644 arch/arm/mach-omap2/cminst44xx.h > create mode 100644 arch/arm/mach-omap2/prcm44xx.h > create mode 100644 arch/arm/mach-omap2/prcm_mpu44xx.c > create mode 100644 arch/arm/mach-omap2/prminst44xx.
Re: [PATCH v1 3/9] OMAP2420: hwmod data: add system DMA
On Tue, Dec 14, 2010 at 07:25:23PM -0700, Paul Walmsley wrote:
> Manju
>
> On Sat, 4 Dec 2010, G, Manjunath Kondaiah wrote:
>
> > Add OMAP2420 DMA hwmod data and also add required
> > DMA device attributes.
> >
> > Signed-off-by: G, Manjunath Kondaiah
> > Cc: Benoit Cousson
> > Cc: Kevin Hilman
> > Cc: Santosh Shilimkar
> >
> > +/* dma_system -> L3 */
> > +static struct omap_hwmod_ocp_if omap2420_dma_system__l3 = {
> > + .master = &omap2420_dma_system_hwmod,
> > + .slave = &omap2420_l3_main_hwmod,
> > + .clk= "l3_div_ck",
>
> This clock does not exist on OMAP2420. Did you test this patch on 2420?
ok. will be replaced with "sdma_ick". I don't have 2420 for testing. I
tested it on 2430. My understanding is that, DMA clock interface is same
for 2420 and 2430. Correct me if am wrong.
>
> > +/* l4_cfg -> dma_system */
> > +static struct omap_hwmod_ocp_if omap2420_l4_core__dma_system = {
> > + .master = &omap2420_l4_core_hwmod,
> > + .slave = &omap2420_dma_system_hwmod,
> > + .clk= "l4_div_ck",
>
> Nor does this clock exist on OMAP2420.
ok. Will replace with "sdma_ick"
>
> > +static struct omap_hwmod omap2420_dma_system_hwmod = {
> > + .name = "dma",
> > + .class = &omap2420_dma_hwmod_class,
> > + .mpu_irqs = omap2420_dma_system_irqs,
> > + .mpu_irqs_cnt = ARRAY_SIZE(omap2420_dma_system_irqs),
> > + .main_clk = "l3_div_ck",
>
> And neither does this one.
This will be replaced with "sdma_fck"
>
> Please fix these and test on OMAP2420 before sending the fixed patches.
I don't have setup to test this. I will do the changes and test it on
2430SDP which has similar change.
-Manjunath
--
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 v1 4/9] OMAP2430: hwmod data: add system DMA
On Tue, Dec 14, 2010 at 07:27:33PM -0700, Paul Walmsley wrote:
> On Sat, 4 Dec 2010, G, Manjunath Kondaiah wrote:
>
> > Add OMAP2430 DMA hwmod data and also add required
> > DMA device attributes.
>
> ...
>
> > +/* dma_system -> L3 */
> > +static struct omap_hwmod_ocp_if omap2430_dma_system__l3 = {
> > + .master = &omap2430_dma_system_hwmod,
> > + .slave = &omap2430_l3_main_hwmod,
> > + .clk= "l3_div_ck",
>
> This clock does not exist on OMAP2430. Did you test this on OMAP2430?
Yes. I have tested this on SDP2430. For confirmation, I tested again now.
It boots up without any issues and all DMA test cases are passing.
>
> > +/* l4_cfg -> dma_system */
> > +static struct omap_hwmod_ocp_if omap2430_l4_core__dma_system = {
> > + .master = &omap2430_l4_core_hwmod,
> > + .slave = &omap2430_dma_system_hwmod,
> > + .clk= "l4_div_ck",
>
> This clock also does not exist on OMAP2430.
ok. I will replace with "sdma_ick" here.
>
> > +static struct omap_hwmod omap2430_dma_system_hwmod = {
> > + .name = "dma",
> > + .class = &omap2430_dma_hwmod_class,
> > + .mpu_irqs = omap2430_dma_system_irqs,
> > + .mpu_irqs_cnt = ARRAY_SIZE(omap2430_dma_system_irqs),
> > + .main_clk = "l3_div_ck",
>
> Nor does this one.
ok. will be replaced with "sdma_fck"
>
> Please fix these and test on OMAP2430 before resending.
Thanks. I will test again with above changes on SDP2430.
-Manjunath
--
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 v2] MTD: NAND: ams-delta: convert to platform driver
On Tue, 2010-12-14 at 21:09 +0100, Janusz Krzysztofik wrote: > In its current form, the driver may interfere with different hardware on > different boards if built into the kernel, hence is not suitable for > inclusion into a defconfig, inteded to be usable with multiple OMAP1 cpu and > machine types. > > Convert it to a platform driver, that should be free from this issue. > > Created and tested against linux-2.6.37-rc5 on Amstrad Delta. > > Signed-off-by: Janusz Krzysztofik Pushed to l2-mtd-2.6.git, thanks! -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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 v7] OMAP4:keypad: PM runtime
Shubhro, On Wed, Dec 15, 2010 at 13:24, Datta, Shubhrajyoti wrote: > On Wed, Dec 15, 2010 at 11:01 AM, Varadarajan, Charulatha > wrote: >> * Shubhrajyoti D [2010-12-15 09:39:58 +0530]: >> >>> From: Abraham Arce >>> >>> Enable Runtime PM functionality in OMAP4 driver based on the following >>> assumptions >>> >>> A minimal pm runtime get/put approach is implemented in probe/remove calls >>> respectively. >>> >>> - Keyboard controller in wakeup domain so it is always on and >>> power impact may be minimal >>> - In OMAP4 the device control is at module/device level and ick/fclk level >>> control is >>> difficult so cutting of clocks will prevent interrupts. >>> >>> Signed-off-by: Abraham Arce >>> Cc: Kevin Hilman >> >> This patch is sent thrice (once with a different subject) but the >> version numbers are the same. It is not clear what is the intention of this >> patch without hwmod database update. Am I missing any more patch here? > Yes missed the version. > I have updated the change logs to be more descriptive and the subject line. > > > Regarding the hwmod database update. That I deffered for reasons > - The clock changes need to be there as the update would mean reset of clocks. > - Thought of completing the drivers/input before the hwmod database > and the board changes. > - Also currently the driver relies on the uboot settings for clock > this might remove that dependency. I wish to differ here. This patch would not fix the above issues because pm runtime APIs (for OMAP) purely rely on omap_device and the keypad driver is not yet hwmod adapted. Atleast put a dependency on any hwmod series if you had sent them before. -V Charulatha -- 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] OMAP: omap_device: use pdev as parameter to get rt_va
On Tue, Dec 14, 2010 at 05:17:28PM -0700, Paul Walmsley wrote: > Hello Omar > > On Mon, 13 Dec 2010, Ramirez Luna, Omar wrote: > > > On Mon, Dec 13, 2010 at 2:12 AM, Cousson, Benoit wrote: > > > On 12/11/2010 12:45 AM, Ramirez Luna, Omar wrote: > > >> > > >> Make the parameter received by omap_device_get_mpu_rt_va > > >> consistent with the functions meant to be called by drivers. > > >> > > >> Also move its header declaration to appear in the set of > > >> functions to be used by drivers, as per the comment there. > > > > > > Please note that even if Paul submitted this API upon request from > > > Santosh, > > > we do not want driver to us it most of the time. > > > > Oh, ok. Yes, I was under the impression that this ioremap was internal > > to hwmod, and drivers should do their own one but then I noticed that > > API and since it was under the "public functions through struct > > platform data", I thought it was easier to pass pdev than od. > > > > > All drivers should us the generic Linux way to get physical mem resource > > > and > > > then ioremap it. > > > > Then I guess this function belongs to the "public for core code" and > > not for drivers along with the omap_device_get_pwrdm. > > > > > I assume that if you want to update this API, you are probably already > > > using > > > it. > > > Why cannot you use the generic way? > > > > I can leave the generic way along with ioremap, the purpose was to use > > omap_device APIs as much as possible. > > The above isn't quite it. What I'd suggest you do in your code is this: > > - In your driver-to-core-OMAP integration code in arch/arm/*omap*, call > omap_hwmod_get_mpu_rt_va(), and pass that to the driver via an entry in > the struct platform_data. > > - In your driver code in drivers/*, test to see if that struct > platform_data entry is NULL. If it is, only then should your driver > ioremap(). Otherwise, it should use the address from the struct > platform_data. > > This is because it's not guaranteed that ioremap() on OMAP will continue > to reuse the current static mapping in the future. We've heard from some > mobile OS vendors that they are under significant address space > constraints, so on those distributions it might make sense to only map > devices that are actually in use, and take the additional TLB entry cost. > > Does this make sense? No it doesn't - this is not a valid reason to bugger about with drivers to make them non-standard. omap_ioremap() can be improved to retain its re-use of static mappings by having some kind of tree structure or something like that - ioremap is after all not a performance critical path. There's no need to start passing virtual addresses to drivers. -- 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 05/12] staging:tidspbridge - set5 remove hungarian from structs
On Tue, Dec 14, 2010 at 02:33:11PM -0600, Rene Sapiens wrote: > - pfn_unload(pnode->nldr_node_obj, > + load(pnode->nldr_node_obj, > NLDR_EXECUTE); Unload got swapped with load here. This might have been easier to with Coccinelle instead of by hand... regards, dan carpenter -- 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
