[PATCH] omap: Use CONFIG_SMP for test_for_ipi and test_for_ltirq belong (Re: PM branch updated to v2.6.35, SRF dropped)
* Kevin Hilman khil...@deeprootsystems.com [100806 01:48]: Also with omap_4430sdp_defconfig, I see these compile errors arch/arm/kernel/entry-armv.S: Assembler messages: arch/arm/kernel/entry-armv.S:48: Error: bad instruction `test_for_ipi r0,r6,r5,lr' arch/arm/kernel/entry-armv.S:48: Error: bad instruction `test_for_ipi r0,r6,r5,lr' make[1]: *** [arch/arm/kernel/entry-armv.o] Error 1 make: *** [arch/arm/kernel] Error 2 Doing a git log on entry-armv.S shows me a top commit which might be an issue if conflicts are'nt resolved well. commit 7b70c4275f28702b76b273c8534c38f8313812e9 Merge: ceb0885... a20df56... Author: Russell King rmk+ker...@arm.linux.org.uk Date: Sat Jul 31 14:20:16 2010 +0100 Merge branch 'devel-stable' into devel Conflicts: arch/arm/kernel/entry-armv.S arch/arm/kernel/setup.c arch/arm/mm/init.c Maybe this is an issue in Tony's for-next as well. Haven't tested it though. Yeah, I'm guessing this an issue in for-next, and probably l-o master too. Noticed that with omap3_defconfig with CONFIG_SMP enabled. Does the following work for you? Tony From: Tony Lindgren t...@atomide.com Date: Thu, 5 Aug 2010 13:18:20 +0300 Subject: [PATCH] omap: Use CONFIG_SMP for test_for_ipi and test_for_ltirq belong Otherwise we get the following error when enabling CONFIG_SMP for omap3_defconfig: arch/arm/kernel/entry-armv.S: Assembler messages: arch/arm/kernel/entry-armv.S:48: Error: bad instruction `test_for_ipi r0,r6,r5,lr' arch/arm/kernel/entry-armv.S:48: Error: bad instruction `test_for_ltirq r0,r6,r5,lr' arch/arm/kernel/entry-armv.S:48: Error: bad instruction `test_for_ipi r0,r6,r5,lr' arch/arm/kernel/entry-armv.S:48: Error: bad instruction `test_for_ltirq r0,r6,r5,lr' Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S b/arch/arm/mach-omap2/include/mach/entry-macro.S index 50fd749..06e64e1 100644 --- a/arch/arm/mach-omap2/include/mach/entry-macro.S +++ b/arch/arm/mach-omap2/include/mach/entry-macro.S @@ -177,7 +177,10 @@ omap_irq_base: .word 0 cmpne \irqnr, \tmp cmpcs \irqnr, \irqnr .endm +#endif +#endif /* MULTI_OMAP2 */ +#ifdef CONFIG_SMP /* We assume that irqstat (the raw value of the IRQ acknowledge * register) is preserved from the macro above. * If there is an IPI, we immediately signal end of interrupt @@ -205,8 +208,7 @@ omap_irq_base: .word 0 streq \irqstat, [\base, #GIC_CPU_EOI] cmp \tmp, #0 .endm -#endif -#endif /* MULTI_OMAP2 */ +#endif /* CONFIG_SMP */ .macro irq_prio_table .endm
[PATCH] omap: Fix sev instruction usage for multi-omap
* Tony Lindgren t...@atomide.com [100806 09:55]: * Kevin Hilman khil...@deeprootsystems.com [100806 01:48]: Also with omap_4430sdp_defconfig, I see these compile errors arch/arm/kernel/entry-armv.S: Assembler messages: arch/arm/kernel/entry-armv.S:48: Error: bad instruction `test_for_ipi r0,r6,r5,lr' arch/arm/kernel/entry-armv.S:48: Error: bad instruction `test_for_ipi r0,r6,r5,lr' make[1]: *** [arch/arm/kernel/entry-armv.o] Error 1 make: *** [arch/arm/kernel] Error 2 Doing a git log on entry-armv.S shows me a top commit which might be an issue if conflicts are'nt resolved well. commit 7b70c4275f28702b76b273c8534c38f8313812e9 Merge: ceb0885... a20df56... Author: Russell King rmk+ker...@arm.linux.org.uk Date: Sat Jul 31 14:20:16 2010 +0100 Merge branch 'devel-stable' into devel Conflicts: arch/arm/kernel/entry-armv.S arch/arm/kernel/setup.c arch/arm/mm/init.c Maybe this is an issue in Tony's for-next as well. Haven't tested it though. Yeah, I'm guessing this an issue in for-next, and probably l-o master too. Noticed that with omap3_defconfig with CONFIG_SMP enabled. Does the following work for you? Here's a related patch that allows CONFIG_SMP to compile with omap3_defconfig. Booting still won't work before some arm generic code is changed. Regards, Tony From f931fb147f2a3cf4c4b7646e5f270c241ab4aad1 Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Thu, 5 Aug 2010 13:28:42 +0300 Subject: [PATCH] omap: Fix sev instruction usage for multi-omap Otherwise we get the following error with omap3_defconfig and CONFIG_SMP: Error: selected processor does not support `sev' Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 63b2d88..88d3a1e 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -25,6 +25,7 @@ obj-$(CONFIG_LOCAL_TIMERS)+= timer-mpu.o obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o obj-$(CONFIG_ARCH_OMAP4) += omap44xx-smc.o omap4-common.o +AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a AFLAGS_omap44xx-smc.o :=-Wa,-march=armv7-a # Functions loaded to SRAM diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c index af3c20c..9e9f70e 100644 --- a/arch/arm/mach-omap2/omap-smp.c +++ b/arch/arm/mach-omap2/omap-smp.c @@ -102,8 +102,7 @@ static void __init wakeup_secondary(void) * Send a 'sev' to wake the secondary core from WFE. * Drain the outstanding writes to memory */ - dsb(); - set_event(); + dsb_sev(); mb(); } diff --git a/arch/arm/plat-omap/include/plat/smp.h b/arch/arm/plat-omap/include/plat/smp.h index 6a3ff65..5177a9c 100644 --- a/arch/arm/plat-omap/include/plat/smp.h +++ b/arch/arm/plat-omap/include/plat/smp.h @@ -19,13 +19,6 @@ #include asm/hardware/gic.h -/* - * set_event() is used to wake up secondary core from wfe using sev. ROM - * code puts the second core into wfe(standby). - * - */ -#define set_event()__asm__ __volatile__ (sev : : : memory) - /* Needed for secondary core boot */ extern void omap_secondary_startup(void); extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask);
Re: [PATCH v2 03/20] mmc: support embedded data field in mmc_host
2010/8/4 Ohad Ben-Cohen o...@wizery.com: On Wed, Aug 4, 2010 at 2:41 PM, Russell King - ARM Linux Why not arrange for a small piece of code to be built into the kernel when this driver is selected as a module or built-in, which handles the passing of platform data to the driver? It's interesting. The only drawback I can see is that it has an inherent limitation of having only a single wl1271 device on board, ...which is exactly what the *_board_info scheme in the spi and i2c subsystems is designed to solve. This is an established design pattern in the kernel with two precedents, what makes it so hard to implement this idea? There are plenty of examples all over the place. What mainly matters to me is that the stuff can be separated cleanly and in a nicely structured manner into board-xxx.c files in the mach-xxx dirs, which is possible also with the simpler approach so whatever... Yours, Linus Walleij -- 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-SR][PATCH 04/12] omap3: sr: device: cleanup pr_xxx
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 04/12] omap3: sr: device: cleanup pr_xxx
Strings in c dont need to be split accross multiple lines with \
. instead they can be put as abc def and it is equivalent to
abc def.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/sr_device.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index dbf7603..7d13704 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -151,8 +151,9 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
sr_dev_data-volts_supported = omap_get_voltage_table(i,
sr_dev_data-volt_data);
if (!sr_dev_data-volts_supported) {
- pr_warning(%s: No Voltage table registerd fo VDD%d.Something \
- really wrong\n\n, __func__, i + 1);
+ pr_warning(%s: No Voltage table registerd fo VDD%d.
+ Something is really wrong\n,
+ __func__, i + 1);
Taken in.
Regards
Thara
i++;
kfree(sr_data);
return 0;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 06/12] omap3: sr: device: fail sr_dev_init should return error
-Original Message- From: Menon, Nishanth Sent: Friday, August 06, 2010 3:54 AM To: linux-omap Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara Subject: [PM-SR][PATCH 06/12] omap3: sr: device: fail sr_dev_init should return error sr_dev_init should return error on error conditions Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Thara Gopinath th...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/sr_device.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c index 6f70da6..8fb60d8 100644 --- a/arch/arm/mach-omap2/sr_device.c +++ b/arch/arm/mach-omap2/sr_device.c @@ -162,7 +162,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user) __func__, i + 1); i++; kfree(sr_data); - return 0; + return -ENODATA; } sr_set_nvalues(sr_dev_data, sr_data); od = omap_device_build(name, i, oh, sr_data, sizeof(*sr_data), @@ -172,6 +172,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user) pr_warning(%s: Could not build omap_device for %s: %s.\n\n, __func__, name, oh-name); kfree(sr_data); + return PTR_ERR(od); } NAK for this change. This API is called from omap_hwmod_for_each_by_class for every smartreflex module. If This API returns an error omap_hwmod_for_each_by_class will exit without looping over rest of the smartreflex modules. This means a error for one smartreflex module will prevent rest of the smartreflex modules to be initialized. We do not want this. Hence this API returns 0 for non-availability of data for a smartreflex module. Regards Thara i++; return 0; -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 07/12] omap3: sr: device: make omap_sr_latency static
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 07/12] omap3: sr: device: make omap_sr_latency static
omap_sr_latency definition does not need to be exposed to the world
but we cant make it __init data as the pointer is stored in odev
to be used beyond basic kernel boot.
also fixes sparse warning:
arch/arm/mach-omap2/sr_device.c:32:31: warning: symbol 'omap_sr_latency' was
not declared. Should it
be static?
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/sr_device.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index 8fb60d8..e81 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -29,7 +29,7 @@
#include voltage.h
-struct omap_device_pm_latency omap_sr_latency[] = {
+static struct omap_device_pm_latency omap_sr_latency[] = {
{
.deactivate_func = omap_device_idle_hwmods,
.activate_func = omap_device_enable_hwmods,
Taken in
Regards
Thara
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 05/12] omap3: sr: device: check for dev_attr
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 05/12] omap3: sr: device: check for dev_attr
In the unlikely case that hwmod database is messed up, dont crash
report error and attempt to recover.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/sr_device.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index 7d13704..6f70da6 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -130,6 +130,12 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
}
sr_dev_data = (struct omap_sr_dev_data *)oh-dev_attr;
+ if (unlikely(!sr_dev_data)) {
+ pr_err(%s: Bad oh-dev_attr!\n, __func__);
+ kfree(sr_data);
+ return -EINVAL;
+ }
Taken in after modifications as per the reply for patch 06/12
Regards
Thara
+
/*
* OMAP3430 ES3.1 chips by default come with Efuse burnt
* with parameters required for full functionality of
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 12/12] omap3: sr: class3: make class3_data static
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 12/12] omap3: sr: class3: make class3_data static
we dont expose the structure to the world, so this should be static
however, since sr core does not take a copy of the same, we cant make
it __init data.
fixes sparse warning:
arch/arm/mach-omap2/smartreflex-class3.c:50:36: warning: symbol 'class3_data'
was not declared.
Should it be static?
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/smartreflex-class3.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index f3b766f..530b2f0 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -47,7 +47,7 @@ static int sr_class3_configure(int id)
}
/* SR class3 structure */
-struct omap_smartreflex_class_data class3_data = {
+static struct omap_smartreflex_class_data class3_data = {
.enable = sr_class3_enable,
.disable = sr_class3_disable,
.configure = sr_class3_configure,
Taken in
Regards
Thara
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3: Remove non-existent config option
Hi Hari, On Thu, 5 Aug 2010 17:12:11 +0200 ext Kanigeri, Hari h-kanige...@ti.com wrote: Hiroshi, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hiroshi DOYU Sent: Wednesday, August 04, 2010 6:20 AM To: t...@atomide.com Cc: Marathe, Yogesh; linux-omap@vger.kernel.org; Premi, Sanjeev Subject: Re: [PATCH] omap3: Remove non-existent config option From: ext Tony Lindgren t...@atomide.com Subject: Re: [PATCH] omap3: Remove non-existent config option Date: Wed, 4 Aug 2010 13:11:47 +0200 * Marathe, Yogesh yogesh_mara...@ti.com [100803 11:03]: ping.. Hiroshi ack/nak? Nak. http://www.spinics.net/lists/linux-omap/msg32869.html tidspbridge is in staging now. Can you please elaborate what this means ? Yogesh patch enables the IOMMU for BRIDGE by default and we need this as IOMMU is going to get use in 3430. Ok, I misunderstood this intention, sorry. Tony, please put this into your queue for next merge. -- 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-SR][PATCH 02/12] omap3: voltage: make required variables static
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 02/12] omap3: voltage: make required variables static
debugfs voltage_dir - used only by voltage layer and no reason for
others to add data to it, so make it static.
volt_mod have no business being exposed as global. make it static
we dont expose omap3_vp_offs to the world and is __init data,
so make it static.
This fixes sparse warnings:
arch/arm/mach-omap2/voltage.c:42:15: warning: symbol 'voltage_dir' was not
declared. Should it be
static?
arch/arm/mach-omap2/voltage.c:49:5: warning: symbol 'volt_mod' was not
declared. Should it be static?
arch/arm/mach-omap2/voltage.c:130:27: warning: symbol 'omap3_vp_offs' was not
declared. Should it be
static?
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Note: i had initially considered splitting these into three seperate patches,
but these are too trivial.
arch/arm/mach-omap2/voltage.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 3431fa3..1a3d00d 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -39,14 +39,14 @@
#define VP_TRANXDONE_TIMEOUT 300
#ifdef CONFIG_PM_DEBUG
-struct dentry *voltage_dir;
+static struct dentry *voltage_dir;
#endif
/* VP SR debug support */
u32 enable_sr_vp_debug;
/* PRM voltage module */
-u32 volt_mod;
+static u32 volt_mod;
/* Voltage processor register offsets */
struct vp_reg_offs {
@@ -127,7 +127,7 @@ static struct omap_vdd_info *vdd_info;
static int no_scalable_vdd;
/* OMAP3 VP register offsets and other definitions */
-struct __init vp_reg_offs omap3_vp_offs[] = {
+static struct __init vp_reg_offs omap3_vp_offs[] = {
This change is no longer valid after the patch converting vdd id's to
names. Rest of the two changes have been taken in.
Regards,
Thara
/* VP1 */
{
.vpconfig_reg = OMAP3_PRM_VP1_CONFIG_OFFSET,
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 01/12] omap3: voltage: cleanup pr_xxxx
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 01/12] omap3: voltage: cleanup pr_
Few more pr_ need cleanup for printing the function name and
not using multiline prints when c allows us to do .
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/voltage.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 148e4d4..3431fa3 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -253,8 +253,9 @@ static int vp_debug_set(void *data, u64 val)
u32 *option = data;
*option = val;
} else {
- pr_notice(DEBUG option not enabled!\n \
- echo 1 pm_debug/enable_sr_vp_debug - to enable\n);
+ pr_notice(%s: DEBUG option not enabled!
+ echo 1 pm_debug/enable_sr_vp_debug - to enable\n,
+ __func__);
}
I do not think this is needed as these fns get called only from user space.
Regards
Thara
return 0;
}
@@ -265,7 +266,7 @@ static int vp_volt_debug_get(void *data, u64 *val)
u8 vsel;
vsel = voltage_read_reg(info-vp_offs.voltage_reg);
- pr_notice(curr_vsel = %x\n, vsel);
+ pr_notice(%s: curr_vsel = %x\n, __func__, vsel);
*val = vsel * 12500 + 60;
return 0;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/6] TI816X: Create board support for TI816X_EVM
Kevin Hilman wrote:
Hemant Pedanekar hema...@ti.com writes:
This patch adds minimal support for TI816X EVM to enable kernel boot.
Signed-off-by: Hemant Pedanekar hema...@ti.com
[...]
+#include linux/kernel.h
+#include linux/init.h
+#include linux/device.h
+#include linux/spi/spi.h
+#include linux/spi/flash.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/i2c/pcf857x.h
+#include linux/i2c/at24.h
+#include linux/mtd/mtd.h
+#include linux/mtd/nand.h
+#include linux/mtd/partitions.h
+#include linux/mtd/physmap.h
+#include linux/phy.h
Looks like most of these headers are not needed for this minimal
support. It's preferred to have a minimal set of headers here and add
them later as needed when the devices are added.
+#include mach/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include plat/irqs.h
+#include plat/mux.h
+#include plat/board.h
+#include plat/common.h
+#include plat/timer-gp.h
+
+static void __init ti8168_evm_init_irq(void)
+{
+omap2_gp_clockevent_set_gptimer(2);
Just curious why GPT2 is used here.
+omap2_init_common_hw(NULL, NULL);
+omap_init_irq();
+}
Kevin
Currently, first timer is reserved on TI816X.
I will cleanup the includes and add timer comment.
Thanks
-
Hemant
--
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 updates for 2.6.36 merge window
Hi Linus, Please pull omap updates from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-for-linus Regards, Tony The following changes since commit be82ae0238b0453afcf4a76f0512b7dde34ba500: Merge branch 'devel' of master.kernel.org:/home/rmk/linux-2.6-arm (2010-08-03 14:31:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-for-linus Anand Gadiyar (3): OMAP3: wait on IDLEST after enabling USBTLL fclk OMAP3630: Add ES1.1 and ES1.2 detection omap: 3630: disable TLL SAR on 3630 ES1 Artem Bityutskiy (1): omap: device: improve errors handling Benoit Cousson (1): OMAP23: hwmod: Remove _hwmod prefix in name string Christoph Egger (8): Replace dead OMAP_MUX_ERRORS with OMAP_MUX_WARNINGS Removing dead OMAP_IR Removing dead OMAP_DSP Removing dead OMAP_STI Replacing LEDS_OMAP_DEBUG with OMAP_DEBUG_LEDS Removing dead APM Removing dead MACH_OMAP_H4_OTG Removing dead MACH_OMAP2_H4_USB1 Cory Maccarrone (1): omap1: omap7xx clocks, mux, serial fixes David Anders (1): omap4: Add OMAP4 Panda Support Deepak K (1): omap2/3/4: serial: errata i202: fix for MDR1 access Felipe Contreras (13): omap: mailbox: trivial cleanups omap: mailbox: reorganize structures omap: mailbox: 2420 should be detected at run-time omap: mailbox: use correct config for omap1 omap: mailbox: update omap1 probing omap: mailbox: don't export unecessary symbols omap: mailbox: remove unecessary fields omap: mailbox: add IRQ names omap: mailbox: reorganize registering omap: mailbox: simplify omap_mbox_register() omap: mailbox: only compile for configured archs omap: mailbox: standarize on 'omap-mailbox' omap: mailbox: reorganize headers Fernando Guzman Lugo (4): Mailbox: free mailbox interrupt before freeing blk queue Mailbox: flush pending deferred works before freeing blk queue Mailbox: Check valid registered callback before calling Mailbox: disable mailbox interrupt when request queue Govindraj R (1): omap3: serial: Add context save and restore for mcr Grazvydas Ignotas (3): omap3: pandora: update gpio-keys data omap3: pandora: add NAND and wifi support omap: mux: fix multipath gpio handling Hemanth V (1): OMAP4: Add GPIO LED support for SDP board Hiroshi DOYU (6): omap iommu: Introduce iopgd_is_table MACRO omap iommu: Rename iopte_[p,v]addr - iopte_page_[p,v]addr omap iommu: move iommu_disable at fault to the above layer omap iommu: Make omap-iommu.o built-in Mailbox: new mutext lock for h/w mailbox configuration omap mailbox: Set a device in logical mbox instance for traceability Jarkko Nikula (4): omap: rx51: Set regulator V28 always on omap: rx51: Add platform_data for tlv320aic3x with reset gpionumber omap: rx51: Use REGULATOR_SUPPLY macro when initializingregulator consumers omap: rx51: Add supply and data for the tpa6130a2 headphoneamplifier Jason Wang (1): omap: Fix DEBUG_LL uart to access phys addr when MMU isn't enable Kan-Ru Chen (5): OMAP2: Devkit8000: Enable DVI-D output OMAP2: Devkit8000: Setup LCD reset omap: Add new interface omap_get_die_id omap: Use omap_get_die_id() to get the DIE ids omap: Devkit8000: Use DIE id to initialize dm9000 MAC address Kanigeri, Hari (3): omap iommu: update irq mask to be specific about twl and tlb omap iommu: add functionality to get TLB miss interrupt omap iommu: update ducati mmu irq define name Kevin Hilman (8): OMAP24xx: CM: fix mask used for checking IDLEST status OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLEST OMAP: hwmod: add non-locking versions of enable and idle functions OMAP: omap_device: ensure hwmod tracks attached omap_device pointer OMAP: PM: create omap_devices for MPU, DSP, L3 OMAP: hwmod data: add class for IVA hwmods OMAP23: hwmod: Replace l3 - l3_main OMAP3: hwmod data: add data for OMAP3 IVA2 Mathias Nyman (1): omap: tsl2563 ALS support for Nokia N900 Mike Rapoport (1): omap3: introduce omap3_map_io Nishanth Menon (4): omap2/3/4: serial: remove initialization sparse warnings omap2/3/4: serial: kill dev_attr_sleep_timeout sparse warn omap2/3/4: serial: introduce errata handling omap2/3: id: fix sparse warning Ohad Ben-Cohen (6): omap: zoom2: wlan board muxing omap: zoom3: wlan board muxing omap: mailbox: convert rwlocks to spinlock omap: mailbox cleanup: split MODULE_AUTHOR line omap: mailbox: remove (un)likely macros from cold paths omap: mailbox: convert block api to kfifo Paul Walmsley (9): OMAP: clock: add kerneldoc for structures; move flags closer to structs
RE: [PATCH v4 0/4] nand prefetch-irq support and ecc layout chanage
Tony, -Original Message- From: Ghorai, Sukumar Sent: Wednesday, August 04, 2010 9:29 AM To: linux-omap@vger.kernel.org; 'Tony Lindgren' Cc: linux-arm-ker...@lists.infradead.org; linux-...@lists.infradead.org Subject: RE: [PATCH v4 0/4] nand prefetch-irq support and ecc layout chanage -Original Message- From: Ghorai, Sukumar Sent: Monday, August 02, 2010 9:20 PM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org; linux-...@lists.infradead.org; Ghorai, Sukumar Subject: [PATCH v4 0/4] nand prefetch-irq support and ecc layout chanage The following set of patches applies on top of omap-for-linus. v4: Comments incorporated v3: http://www.mail-archive.com/linux- o...@vger.kernel.org/msg32071.html Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31963.html v2: Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31471.html v1: http://www.mail-archive.com/linux- o...@vger.kernel.org/msg2.html Sukumar Ghorai (4): omap3: nand: prefetch in irq mode support omap: nand: configurable fifo threshold to gain the throughput omap: nand: ecc layout select from board file omap: nand: making ecc layout as compatible with romcode ecc arch/arm/mach-omap2/board-flash.c |5 +- arch/arm/mach-omap2/gpmc.c | 15 ++- arch/arm/plat-omap/include/plat/gpmc.h |9 +- arch/arm/plat-omap/include/plat/irqs.h |1 + arch/arm/plat-omap/include/plat/nand.h |7 + drivers/mtd/nand/Kconfig | 14 ++- drivers/mtd/nand/omap2.c | 277 --- 7 files changed, 294 insertions(+), 34 deletions(-) [Ghorai] Tony, Would you please check if you have any input further? [Ghorai] Tony, Would you please check the status of these patch(s). Regards, Ghorai -- 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: Board mux entries ignored?
* John Faith jfai...@gmail.com [100805 19:09]: On Wed, Aug 4, 2010 at 11:54 PM, Tony Lindgren t...@atomide.com wrote: * John Faith jfai...@gmail.com [100804 22:22]: Hi, I'm trying to set mux modes for a 3530, package CBC in my board.c (2.6.32 kernel) using an omap_board_mux entry: OMAP3_MUX(GPMC_WAIT1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), , but sysfs reports mode4: # grep WAIT1 /sys/kernel/debug/omap_mux/board OMAP3_MUX(GPMC_WAIT1, OMAP_PIN_INPUT | OMAP_MUX_MODE4), I tried adding to bootargs omap_mux=gpmc_wait1.gpmc_wait1=0x100, but still got MODE4. Doing echo 0x100 /sys/kernel/debug/omap_mux/gpmc_wait1 gave me MODE0, but I'd prefer to init pins in board.c. I've also noticed for pin SDMMC2_DAT3 that my OMAP3_MUX() entry specifies MODE1, but sysfs shows MODE4; it changed to MODE1 after adding: omap_mux_init_signal(mcspi3_cs0, OMAP_PIN_OUTPUT); Is just having the mode in omap_board_mux entries sufficient? Hmm that should be enough. Does dmesg | grep -i mux show any errors? You do have CONFIG_OMAP_MUX set, right? Otherwise omap_mux_init_signals does not do anything, and the mux code just builds a list of GPIO pins for PM runtime muxing (not implemented yet). Hi, Yes, CONFIG_OMAP_MUX is set. The only non-wait1 error I saw was: mux: Multiple signal paths (3) for mcspi3_cs0 With CONFIG_OMAP_MUX_DEBUG I now see that after mode0 is set, later it's set to mode4: # dmesg | grep -i wait1 mux: Setting signal gpmc_wait1.gpmc_wait1 0x0100 - 0x0100 mux: Setting signal gpmc_wait1.gpio63 0x0100 - 0x0104 The same pin was enabled for a different config, fixed with an ifdef. OK, good to hear. Tony -- 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 v4 0/4] nand prefetch-irq support and ecc layout chanage
* Ghorai, Sukumar s-gho...@ti.com [100806 11:56]: Would you please check the status of these patch(s). Need to look at these after this merge window. In general, we need to have our patches reviewed and tested and sitting in the for-next tree by -rc6. Regards, Tony -- 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] [RFC] Remove the debug print noise
* Nishanth Menon n...@ti.com [100802 16:40]:
Datta, Shubhrajyoti had written, on 08/02/2010 07:59 AM, the following:
-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
Sent: Monday, August 02, 2010 6:22 PM
To: Datta, Shubhrajyoti
Cc: linux-omap@vger.kernel.org; Tony Lindgren
Subject: Re: [PATCH] [RFC] Remove the debug print noise
Hi,
On Mon, Aug 02, 2010 at 02:47:51PM +0200, ext Shubhrajyoti D wrote:
@@ -626,7 +626,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter
*adap,
if (r 0)
return r;
if (r == 0) {
- dev_err(dev-dev, controller timed out\n);
+ dev_dbg(dev-dev, controller timed out\n);
you would better be searching for the cause of the timeout. 1 second is
enough time (or should be) for any i2c command to complete. If you have
an easy way to reproduce this problem, then better search for its
rootcause. If I remember correctly, this timeout was put here for a good
reason.
The reason I am getting the timeout is that there isn't a device
to respond in that address However # ./i2cdetect -y -r 3
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- 29 -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- 48 -- -- 4b -- -- -- --
Is more readable than 0 1 2 3 4 5 6 7 8 9 a b c
d e f
00: -- i2c_omap i2c_omap.3: controller timed out
-- -- i2c_omap i2c_omap.3: controller timed out
-- -- i2c_omap i2c_omap.3: controller timed out
-- -- i2c_omap i2c_omap.3: controller timed out
-- -- i2c_omap i2c_omap.3: controller timed out
-- -- i2c_omap i2c_omap.3: controller timed out
-- --
this is still not a debug message - dev_warn perhaps to flag that
this is indeed an error from the driver point of view?
Tony, any comments ?
Errors like this should be handled at the I2C bus level,
not at the driver level. But looks like the I2C bus does
not do anything about it.. So dev_warn sounds good to me.
Tony
--
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 03/20] mmc: support embedded data field in mmc_host
On Fri, Aug 6, 2010 at 10:07 AM, Linus Walleij
linus.ml.wall...@gmail.com wrote:
2010/8/4 Ohad Ben-Cohen o...@wizery.com:
On Wed, Aug 4, 2010 at 2:41 PM, Russell King - ARM Linux
Why not arrange for a small piece of code to be built into the kernel
when this driver is selected as a module or built-in, which handles
the passing of platform data to the driver?
It's interesting.
The only drawback I can see is that it has an inherent limitation of
having only a single wl1271 device on board,
...which is exactly what the *_board_info scheme in the spi
and i2c subsystems is designed to solve.
This is an established design pattern in the kernel with two
precedents, what makes it so hard to implement this idea?
There are plenty of examples all over the place.
How would a driver ask for the platform data of its specific device ?
Using DEVICE_ID and VENDOR_ID is wrong - those numbers do not identify
a specific device instance (think of a board with two wl1271 devices.
the only difference between them is the index of their mmc
controller).
The only sane way to uniquely identify a specific device instance is
to couple its platform data with the host controller the device is
hardwired to.
So if we want to have an external sdio_board_info table to work, it
would have to map a controller index to sdio_board_info objects.
Something in the lines of:
int sdio_get_platform_data(struct sdio_board_info *data, struct sdio_func *func)
{
if (platform_data[func-card-host-index]) {
memcpy(data, platform_data[func-card-host-index],
sizeof(*data));
return 0;
}
return -ENODEV;
}
typechecking is not preserved (the driver would have to cast
data-platform_data), and there is a possibility for the wrong driver
to pick up the data (at least as much as there was with the original
proposal).
AFAICS, the difference between SDIO and I2C/SPI in that respect, is
that SDIO devices are created dynamically when hardware is probed,
whereas I2C/SPI uses the *_board_info table to populate the device
tree. The I2C/SPI drivers then elegantly get the platform data in the
probe call. In our case, the device is created dynamically, and the
only way to couple it with the correct platform data is using the
knowledge that it is hardwired to a specific host controller.
So using an external repository of platform data objects seem to have
similar disadvantages like the original proposal, but with much more
code.
We have Russell's suggestion which is nice and simple, but it has the
1 device limitation.
Or, we can go back to the approach of creating another platform device
for that chip. That device's name should be wl1271.x where x is the
index of the controller the device is hardwired to. Later, when the
SDIO function probe is invoked, it would register the platform driver
(after dynamically sprintf()ing the name using the
func-card-host-index number), and then
wait_for_completion_interruptible_timeout() for it to probe.
That seem to settle all the concerns raised: we get typechecking, no
wrong driver getting the data, no 1 device limit, no races between the
two probes.
Thanks,
Ohad.
--
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-SR][PATCH 09/12] omap3: sr: enable/disable sr only if required
On 08/05/2010 11:51 PM, Gopinath, Thara wrote:
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 09/12] omap3: sr: enable/disable sr only if required
We dont need to go down the path of enabling/disabling the SR
if we dont need to. do some sanity check and trigger if needed
Cc: Kevin Hilmankhil...@deeprootsystems.com
Cc: Thara Gopinathth...@ti.com
Signed-off-by: Nishanth Menonn...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 19 +++
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index d63691b..9b5a10e 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -778,15 +778,26 @@ static int omap_sr_autocomp_show(void *data, u64 *val)
static int omap_sr_autocomp_store(void *data, u64 val)
{
struct omap_sr *sr_info = (struct omap_sr *) data;
+ u32 value = (u32) val;
if (!sr_info) {
pr_warning(%s: omap_sr struct for SR not found\n, __func__);
return -EINVAL;
}
- if (!val)
- sr_stop_vddautocomp(sr_info);
- else
- sr_start_vddautocomp(sr_info);
+
+ /* Sanity check */
+ if (value (value != 1)) {
+ pr_err(%s: invalid value %d\n, __func__, value);
+ return -EINVAL;
+ }
Will take this in.
+
+ /* change only if needed */
+ if (sr_info-is_autocomp_active ^ value) {
I do not think this is necessary. sr_start_vddautocomp and sr_stop_vddautocomp
will take care of
enabling and disabling intelligently.
hypothesis 1: helper level code is intelligent:
So, lets see where that intelligence exists:
in start autocomp:
static void sr_start_vddautocomp(struct omap_sr *sr)
{
if (!sr_class || !(sr_class-enable) || !(sr_class-configure)) {
dev_warn(sr-pdev-dev,
%s: smartreflex class driver not registered\n,
__func__);
return;
}
[NM - Till here we ensured we have an SR class]
sr-is_autocomp_active = 1;
[NM - aha, we already enabled autocomp]
if (sr_class-enable(sr-srid))
[NM - this is where the intelligence is - Class drivers should be now
intelligent to know if autocomp was previously enabled]
sr-is_autocomp_active = 0;
[NM - if we failed we set it then we disable autocomp_active]
}
ok now, lets dig a little further into class3 enable function - how
intelligent it really is:
static int sr_class3_enable(int id)
{
unsigned long volt = 0;
volt = get_curr_voltage(id);
if (!volt) {
pr_warning(%s: Current voltage unknown.Cannot enable
SR%d\n,
__func__, id);
return -ENODATA;
}
[NM - so far no intelligence]
omap_voltageprocessor_enable(id);
[NM - woops we renable voltage processor if we were already enabled]
return sr_enable(id, volt);
[NM - aha so we are back to Smartreflex core driver for intelligence]
}
digging futher into sr_enable for intelligent check:
int sr_enable(int srid, unsigned long volt)
{
u32 nvalue_reciprocal;
struct omap_volt_data *volt_data;
struct omap_sr *sr = _sr_lookup(srid);
int ret;
if (!sr) {
pr_warning(%s: omap_sr struct for SR%d not found\n,
__func__, srid + 1);
return -EINVAL;
}
volt_data = omap_get_volt_data(sr-srid, volt);
if (IS_ERR(volt_data)) {
dev_warn(sr-pdev-dev, %s: Unable to get voltage table
for nominal voltage %ld\n, __func__, volt);
return -ENODATA;
}
nvalue_reciprocal = volt_data-sr_nvalue;
if (!nvalue_reciprocal) {
dev_warn(sr-pdev-dev, %s: NVALUE = 0 at voltage %ld\n,
__func__, volt);
return -ENODATA;
}
[NM: So far no intelligence]
/*
* errminlimit is opp dependent and hence linked to voltage
* if the debug option is enabled, the user might have over ridden
* this parameter so do not get it from voltage table
*/
if (!enable_sr_vp_debug)
sr-err_minlimit = volt_data-sr_errminlimit;
/* Enable the clocks */
if (!sr-is_sr_enable) {
struct omap_sr_data *pdata =
sr-pdev-dev.platform_data;
if (pdata-device_enable) {
ret = pdata-device_enable(sr-pdev);
if (ret)
return ret;
} else {
dev_warn(sr-pdev-dev, %s: Not able to turn on SR
clocks during enable. So returning\n,
Re: [PM-SR][PATCH 06/12] omap3: sr: device: fail sr_dev_init should return error
On 08/06/2010 02:24 AM, Gopinath, Thara wrote: -Original Message- From: Menon, Nishanth Sent: Friday, August 06, 2010 3:54 AM To: linux-omap Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara Subject: [PM-SR][PATCH 06/12] omap3: sr: device: fail sr_dev_init should return error sr_dev_init should return error on error conditions Cc: Kevin Hilmankhil...@deeprootsystems.com Cc: Thara Gopinathth...@ti.com Signed-off-by: Nishanth Menonn...@ti.com --- arch/arm/mach-omap2/sr_device.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c index 6f70da6..8fb60d8 100644 --- a/arch/arm/mach-omap2/sr_device.c +++ b/arch/arm/mach-omap2/sr_device.c @@ -162,7 +162,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user) __func__, i + 1); i++; kfree(sr_data); - return 0; + return -ENODATA; } sr_set_nvalues(sr_dev_data, sr_data); od = omap_device_build(name, i, oh, sr_data, sizeof(*sr_data), @@ -172,6 +172,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user) pr_warning(%s: Could not build omap_device for %s: %s.\n\n, __func__, name, oh-name); kfree(sr_data); + return PTR_ERR(od); } NAK for this change. This API is called from omap_hwmod_for_each_by_class for every smartreflex module. If This API returns an error omap_hwmod_for_each_by_class will exit without looping over rest of the smartreflex modules. This means a error for one smartreflex module will prevent rest of the smartreflex modules to be initialized. We do not want this. Hence this API returns 0 for non-availability of data for a smartreflex module. why do we want this behavior(aka continue with as many modules as you can enable)? h/wmod data structure are NOT meant to be corrupted if they are, what guarentee do we have that the rest of the sr module data structures have the right hwmods(even if they passed device_build?).. if they are, what is the point in enabling SR in half the domains - we should flag this as an error to developer and get him to fix it instead of encouraging this slipping by half a dozen developers as only sr_l3 failed or something similar.. 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: [PM-SR][PATCH 05/12] omap3: sr: device: check for dev_attr
On 08/06/2010 02:27 AM, Gopinath, Thara wrote:
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 05/12] omap3: sr: device: check for dev_attr
In the unlikely case that hwmod database is messed up, dont crash
report error and attempt to recover.
Cc: Kevin Hilmankhil...@deeprootsystems.com
Cc: Thara Gopinathth...@ti.com
Signed-off-by: Nishanth Menonn...@ti.com
---
arch/arm/mach-omap2/sr_device.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index 7d13704..6f70da6 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -130,6 +130,12 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
}
sr_dev_data = (struct omap_sr_dev_data *)oh-dev_attr;
+ if (unlikely(!sr_dev_data)) {
+ pr_err(%s: Bad oh-dev_attr!\n, __func__);
+ kfree(sr_data);
+ return -EINVAL;
+ }
Taken in after modifications as per the reply for patch 06/12
I dont agree to the mod of 06/12. sorry.
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: [PM-SR][PATCH 02/12] omap3: voltage: make required variables static
On 08/06/2010 02:39 AM, Gopinath, Thara wrote:
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 02/12] omap3: voltage: make required variables static
debugfs voltage_dir - used only by voltage layer and no reason for
others to add data to it, so make it static.
volt_mod have no business being exposed as global. make it static
we dont expose omap3_vp_offs to the world and is __init data,
so make it static.
This fixes sparse warnings:
arch/arm/mach-omap2/voltage.c:42:15: warning: symbol 'voltage_dir' was not
declared. Should it be
static?
arch/arm/mach-omap2/voltage.c:49:5: warning: symbol 'volt_mod' was not
declared. Should it be static?
arch/arm/mach-omap2/voltage.c:130:27: warning: symbol 'omap3_vp_offs' was not
declared. Should it be
static?
Cc: Kevin Hilmankhil...@deeprootsystems.com
Cc: Thara Gopinathth...@ti.com
Signed-off-by: Nishanth Menonn...@ti.com
---
Note: i had initially considered splitting these into three seperate patches,
but these are too trivial.
arch/arm/mach-omap2/voltage.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 3431fa3..1a3d00d 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -39,14 +39,14 @@
#define VP_TRANXDONE_TIMEOUT300
#ifdef CONFIG_PM_DEBUG
-struct dentry *voltage_dir;
+static struct dentry *voltage_dir;
#endif
/* VP SR debug support */
u32 enable_sr_vp_debug;
/* PRM voltage module */
-u32 volt_mod;
+static u32 volt_mod;
/* Voltage processor register offsets */
struct vp_reg_offs {
@@ -127,7 +127,7 @@ static struct omap_vdd_info *vdd_info;
static int no_scalable_vdd;
/* OMAP3 VP register offsets and other definitions */
-struct __init vp_reg_offs omap3_vp_offs[] = {
+static struct __init vp_reg_offs omap3_vp_offs[] = {
This change is no longer valid after the patch converting vdd id's to
names. Rest of the two changes have been taken in.
huh where kevin's pm branch is what I work on and post to l-o. I am
not interested if others have a private tree that none in this community
can see or work with - sorry l-o does not provide me an indication on an
alternate kernel tree for sr development!
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: [PM-SR][PATCH 01/12] omap3: voltage: cleanup pr_xxxx
On 08/06/2010 02:42 AM, Gopinath, Thara wrote:
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 01/12] omap3: voltage: cleanup pr_
Few more pr_ need cleanup for printing the function name and
not using multiline prints when c allows us to do .
Cc: Kevin Hilmankhil...@deeprootsystems.com
Cc: Thara Gopinathth...@ti.com
Signed-off-by: Nishanth Menonn...@ti.com
---
arch/arm/mach-omap2/voltage.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 148e4d4..3431fa3 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -253,8 +253,9 @@ static int vp_debug_set(void *data, u64 val)
u32 *option = data;
*option = val;
} else {
- pr_notice(DEBUG option not enabled!\n \
- echo 1 pm_debug/enable_sr_vp_debug - to enable\n);
+ pr_notice(%s: DEBUG option not enabled!
+ echo 1 pm_debug/enable_sr_vp_debug - to enable\n,
+ __func__);
}
I do not think this is needed as these fns get called only from user space.
have you tried working on someone else's unfamiliar code and grepping
for a warning message at the middle of the night because some developer
forgot to give a %s:..., __func__ with half a dozen people watching
behind your back to know it's meaning because the product is hitting the
shelves the next day? Instead of being able to use cscope and pop the
function in and go straight to it and understand what is happening?? I
believe there are few in this list who had the fortune to be in that sitn..
Well that is my motivation here. if driver reports a warning to kernel
syslog, well, I expect the log to contain the function name for me to
maintain faster.
Regards
Thara
return 0;
}
@@ -265,7 +266,7 @@ static int vp_volt_debug_get(void *data, u64 *val)
u8 vsel;
vsel = voltage_read_reg(info-vp_offs.voltage_reg);
- pr_notice(curr_vsel = %x\n, vsel);
+ pr_notice(%s: curr_vsel = %x\n, __func__, vsel);
*val = vsel * 12500 + 60;
return 0;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap: Fix sev instruction usage for multi-omap
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, August 06, 2010 12:35 PM To: Kevin Hilman Cc: Nayak, Rajendra; linux-omap@vger.kernel.org Subject: [PATCH] omap: Fix sev instruction usage for multi-omap * Tony Lindgren t...@atomide.com [100806 09:55]: * Kevin Hilman khil...@deeprootsystems.com [100806 01:48]: Also with omap_4430sdp_defconfig, I see these compile errors arch/arm/kernel/entry-armv.S: Assembler messages: arch/arm/kernel/entry-armv.S:48: Error: bad instruction `test_for_ipi r0,r6,r5,lr' arch/arm/kernel/entry-armv.S:48: Error: bad instruction `test_for_ipi r0,r6,r5,lr' make[1]: *** [arch/arm/kernel/entry-armv.o] Error 1 make: *** [arch/arm/kernel] Error 2 Doing a git log on entry-armv.S shows me a top commit which might be an issue if conflicts are'nt resolved well. commit 7b70c4275f28702b76b273c8534c38f8313812e9 Merge: ceb0885... a20df56... Author: Russell King rmk+ker...@arm.linux.org.uk Date: Sat Jul 31 14:20:16 2010 +0100 Merge branch 'devel-stable' into devel Conflicts: arch/arm/kernel/entry-armv.S arch/arm/kernel/setup.c arch/arm/mm/init.c Maybe this is an issue in Tony's for-next as well. Haven't tested it though. Yeah, I'm guessing this an issue in for-next, and probably l-o master too. Noticed that with omap3_defconfig with CONFIG_SMP enabled. Does the following work for you? With this patch, I went past the previous break but hit this /tmp/ccUTrImV.s: Assembler messages: /tmp/ccUTrImV.s:140: Error: selected processor does not support `sev' make[1]: *** [arch/arm/mach-omap2/omap-smp.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 Here's a related patch that allows CONFIG_SMP to compile with omap3_defconfig. Booting still won't work before some arm generic code is changed. Now with this, omap4 build using omap_4430sdp_defconfig seems to go through, but like you said, boot is still an issue. regards, Rajendra Regards, Tony -- 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] omap: Fix omap_4430sdp_defconfig for make oldconfig
* Nayak, Rajendra rna...@ti.com [100806 14:22]: Now with this, omap4 build using omap_4430sdp_defconfig seems to go through, but like you said, boot is still an issue. Hmm, I guess these issues pop up if you do yes | make oldconfig. Can you try the patch below? After applying the patch, you need to: $ rm .config $ cp arch/arm/configs/omap_4430sdp_defconfig .config $ yes | ARCH=arm make oldconfig Then omap2 and 3 won't get selected by make oldconfig. Regards, Tony From 96214d5365a10f370e7690a3aa2dc24dbca39e79 Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Fri, 6 Aug 2010 14:40:46 +0300 Subject: [PATCH] omap: Fix omap_4430sdp_defconfig for make oldconfig We don't want to select select the other omaps at this point because otherwise we would have to disable CONFIG_SMP. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index 63e0c2d..14c1e18 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -13,6 +13,9 @@ CONFIG_MODULE_SRCVERSION_ALL=y # CONFIG_BLK_DEV_BSG is not set CONFIG_ARCH_OMAP=y CONFIG_ARCH_OMAP4=y +# CONFIG_ARCH_OMAP2PLUS_TYPICAL is not set +# CONFIG_ARCH_OMAP2 is not set +# CONFIG_ARCH_OMAP3 is not set # CONFIG_OMAP_MUX is not set CONFIG_OMAP_32K_TIMER=y CONFIG_OMAP_DM_TIMER=y
Re: [PM-SR][PATCH 01/12] omap3: voltage: cleanup pr_xxxx
On Fri, Aug 06, 2010 at 06:08:03AM -0500, Nishanth Menon wrote: Well that is my motivation here. if driver reports a warning to kernel syslog, well, I expect the log to contain the function name for me to maintain faster. That's really not the expectation for Linux log messages - the general approach to find the source of a message is generally to just grep for the message text which is usually very effective. -- 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] OMAP4: HWMOD: Do omap_hwmod_late_init for OMAP4
This patch includes cpu_is check for omap44xx cpu inorder to do
omap_hwmod_late_init() without which hwmods initialization does not
happen for omap4.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap2/io.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index b89e678..9b15f46 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -345,7 +345,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
#ifndef CONFIG_PM_RUNTIME
skip_setup_idle = 1;
#endif
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) /* FIXME: OMAP4 */
+ if (cpu_is_omap24xx() || cpu_is_omap34xx() || cpu_is_omap44xx())
omap_hwmod_late_init(skip_setup_idle);
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/13 v5] OMAP: GPIO: Introduce support for OMAP15xx chip GPIO init
This patch introduces platform_data structure for GPIO
so that GPIO module can be implemented in platform device model.
This patch also adds support for handling OMAP15xx specific gpio_init
by providing platform device data and doing device registration.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap1/gpio15xx.c | 101
arch/arm/plat-omap/gpio.c |7 --
arch/arm/plat-omap/include/plat/gpio.h | 20 ++
3 files changed, 121 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/mach-omap1/gpio15xx.c
diff --git a/arch/arm/mach-omap1/gpio15xx.c b/arch/arm/mach-omap1/gpio15xx.c
new file mode 100644
index 000..b2daa66
--- /dev/null
+++ b/arch/arm/mach-omap1/gpio15xx.c
@@ -0,0 +1,101 @@
+/*
+ * OMAP15XX-specific gpio code
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * Author:
+ * Charulatha V ch...@ti.com
+ *
+ * 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.
+ */
+
+#include linux/gpio.h
+
+#define OMAP1_MPUIO_VBASE OMAP1_MPUIO_BASE
+#define OMAP1510_GPIO_BASE 0xfffce000
+
+static struct omap_gpio_dev_attr omap15xx_gpio_attr = {
+ .bank_width = 16,
+};
+
+/*
+ * OMAP15XX GPIO1 interface data
+ */
+static struct __initdata resource omap15xx_mpu_gpio_resources[] = {
+ {
+ .start = OMAP1_MPUIO_VBASE,
+ .end= OMAP1_MPUIO_VBASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_MPUIO,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct __initdata omap_gpio_platform_data omap15xx_mpu_gpio_config = {
+ .virtual_irq_start = IH_MPUIO_BASE,
+ .bank_type = METHOD_MPUIO,
+ .gpio_attr = omap15xx_gpio_attr,
+};
+
+static struct __initdata platform_device omap15xx_mpu_gpio = {
+ .name = omap-gpio,
+ .id = 0,
+ .dev= {
+ .platform_data = omap15xx_mpu_gpio_config,
+ },
+ .num_resources = ARRAY_SIZE(omap15xx_mpu_gpio_resources),
+ .resource = omap15xx_mpu_gpio_resources,
+};
+
+/*
+ * OMAP15XX GPIO2 interface data
+ */
+static struct __initdata resource omap15xx_gpio_resources[] = {
+ {
+ .start = OMAP1510_GPIO_BASE,
+ .end= OMAP1510_GPIO_BASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_GPIO_BANK1,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct __initdata omap_gpio_platform_data omap15xx_gpio_config = {
+ .virtual_irq_start = IH_GPIO_BASE,
+ .bank_type = METHOD_GPIO_1510,
+ .gpio_attr = omap15xx_gpio_attr,
+};
+
+static struct __initdata platform_device omap15xx_gpio = {
+ .name = omap-gpio,
+ .id = 1,
+ .dev= {
+ .platform_data = omap15xx_gpio_config,
+ },
+ .num_resources = ARRAY_SIZE(omap15xx_gpio_resources),
+ .resource = omap15xx_gpio_resources,
+};
+
+/*
+ * omap15xx_gpio_init needs to be done before
+ * machine_init functions access gpio APIs.
+ * Hence omap15xx_gpio_init is a postcore_initcall.
+ */
+static int __init omap15xx_gpio_init(void)
+{
+ if (!cpu_is_omap15xx())
+ return -EINVAL;
+
+ platform_device_register(omap15xx_mpu_gpio);
+ platform_device_register(omap15xx_gpio);
+
+ gpio_bank_count = 2,
+ return 0;
+}
+postcore_initcall(omap15xx_gpio_init);
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index d013b45..dfe4b9e 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -205,13 +205,6 @@ struct gpio_bank {
u32 dbck_enable_mask;
};
-#define METHOD_MPUIO 0
-#define METHOD_GPIO_1510 1
-#define METHOD_GPIO_1610 2
-#define METHOD_GPIO_7XX3
-#define METHOD_GPIO_24XX 5
-#define METHOD_GPIO_44XX 6
-
#ifdef CONFIG_ARCH_OMAP16XX
static struct gpio_bank gpio_bank_1610[5] = {
{ OMAP1_MPUIO_VBASE, NULL, INT_MPUIO, IH_MPUIO_BASE,
diff --git a/arch/arm/plat-omap/include/plat/gpio.h
b/arch/arm/plat-omap/include/plat/gpio.h
index de1c604..67d0086 100644
--- a/arch/arm/plat-omap/include/plat/gpio.h
+++ b/arch/arm/plat-omap/include/plat/gpio.h
@@ -28,6 +28,7 @@
#include linux/io.h
#include mach/irqs.h
+#include linux/platform_device.h
#define OMAP1_MPUIO_BASE 0xfffb5000
@@ -71,6 +72,25 @@
IH_MPUIO_BASE + ((nr) 0x0f) : \
IH_GPIO_BASE + (nr))
+#define METHOD_MPUIO 0
+#define METHOD_GPIO_1510 1
+#define METHOD_GPIO_1610 2
+#define
[PATCH 00/13 v5] OMAP: GPIO: Implement GPIO in HWMOD way
This patch series makes OMAP2PLUS specific GPIO implemented in HWMOD FW way. This is done by implementing GPIO module in platform device model. This patch series is generated on origin/pm-wip/hwmods-omap4. This patch series is created on top of the following two patches: - OMAP4: HWMOD: Do omap_hwmod_late_init for OMAP4 - musb: Kill board specific pinmux from driver file http://marc.info/?l=linux-usbm=127858711304301w=2 - Revert the following patch: OMAP: bus-level PM: enable use of runtime PM API for suspend/resume http://dev.omapzoom.org/?p=swarch/linux-omap-adv.git;a=commitdiff;h=8041359e18e49bf8a3d41f15894db9e476f3a8fc (or) Remove the locking in the omap_hwmod_for_each* function This patch series is tested on OMAP4430 SDP board and OMAP3430 SDP board. It would be of great help if someone could test the same on OMAP1 and OMAP2 boards. Links to related discussions: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32833.html Version History: --- Comments Fixed in V5: - Use dev_pm_ops instead of sys_dev_class - Use runtime suspend/resume hooks for GPIO device - extend the usage of mod_usage flag to all cpu classes.( Earlier it was used only for OMAP2PLUS) - Make gpio_context as part of gpio_bank structure v4 Series: Some link for v4 series: https://patchwork.kernel.org/patch/107411/ Comments Fixed in v4: - Remove gpio_bank_count from dev_attr field and derive it from hwmod class iteration count - Add TODOs for future omap gpio code cleanup related activity - Rename gpio's platform_data 'method' to 'bank_type' - Rename gpio's platform_data 'gpio_bank_bits' to 'gpio_bank_width' - Add 'rev' field to gpio class in hwmod datbase and get 'bank_type' based on 'rev' field - Filename removed from file description when a new file is created Comments Fixed in v3: - .module_offs populated in hwmod structures - If not defined CONFIG_PM_RUNTIME is not handled in GPIO driver - No changes to mach-omap2/clock-data.c to handle clocks by dev ptr as it is taken care using clock get by name in hwmod omap_device layer - Using ick instead of arm_gpio_ck for OMAP15xx clock - SoC base addresses moved to plat-omap/omap.h that should be used only by the omap_hwmod__data.c file - OMAP2/3 hwmod structures naming convention changed as it is followed in OMAP4 - omap24xx_gpio_init() uses cpu_is_omap24xx() instead of separate checks for 2420 2430 in OMAP2 specific init call (mach-omap layer) - Reason for using postcore_initcall is added to patch description for the patch OMAP: GPIO: Introduce support for OMAP2PLUS chip GPIO init - Comments added for usage of dbck_flag and other elements in dev_attr structure - Uses dev_dbg() and dev_err() instead of pr_dbg() and pr_err() - Corrects the gpio clock details in OMAP4 hwmod database v2 series: Some important links to patch v2 series and comments: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30262.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28787.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30263.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30295.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30259.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28933.html Comments Fixed in V2: - GPIO dev attr was added for SoC specific chip info (eg., gpio bank count) - Removed omap_gpio_init() usage from board files - platform_get_resource() used instead of pdata-base for OMAP2+ base addresses - postcore_initcall used for gpio init instead of making GPIO as an early platform device. SoC specific gpio_init needs to be done before machine_init functions access gpio APIs. Hence making SoC specific gpio_init as postcore_initcall. - getting gpio dbck is moved to omap_set_gpio_debounce() instead of doing it in probe v1 series: Some important links to patch v1 series and comments: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26934.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg27860.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28183.html Highlights in v1: - Introduces SoC specific functions at mach-omap layer - Implements GPIO as a platform device - Make gpio an early device and make it implemented in HWMOD FW adapted way for OMAP2PLUS Charulatha V (13): OMAP: GPIO: Modify init() in preparation for platform device implementation OMAP: GPIO: Introduce support for OMAP15xx chip GPIO init OMAP: GPIO: Introduce support for OMAP16xx chip GPIO init OMAP: GPIO: Introduce support for OMAP7xx chip GPIO init OMAP: GPIO: add GPIO hwmods structures for OMAP3 OMAP: GPIO: add GPIO hwmods structures for OMAP242X OMAP: GPIO: add GPIO hwmods structures for OMAP243X OMAP: GPIO: Add gpio dev_attr and correct clks in OMAP4 hwmod struct OMAP: GPIO: Introduce support for OMAP2PLUS chip GPIO init OMAP: GPIO: Implement GPIO as a
[PATCH 08/13 v5] OMAP: GPIO: Add gpio dev_attr and correct clks in OMAP4 hwmod struct
This patch adds gpio_dev_attr to OMAP4 gpio hwmod structure. This patch
also corrects the gpio .main_clk and .clk fields in gpio hwmod structures.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 40 +++
1 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 20f5f8c..1b066df 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,7 @@
#include plat/omap_hwmod.h
#include plat/cpu.h
+#include plat/gpio.h
#include omap_hwmod_common_data.h
@@ -1272,6 +1273,20 @@ static struct omap_hwmod omap44xx_fdif_hwmod = {
* general purpose io module
*/
+/* gpio_dev_attr common for gpio2-6*/
+static struct omap_gpio_dev_attr gpio_dev_attr = {
+ .bank_width = 32,
+ .dbck_flag = true,
+ .off_mode_support = true,
+};
+
+/* gpio_dev_attr for gpio1*/
+static struct omap_gpio_dev_attr gpio1_dev_attr = {
+ .bank_width = 32,
+ .dbck_flag = true,
+ .off_mode_support = false,
+};
+
static struct omap_hwmod_class_sysconfig omap44xx_gpio_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0010,
@@ -1285,6 +1300,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_gpio_sysc = {
static struct omap_hwmod_class omap44xx_gpio_hwmod_class = {
.name = gpio,
.sysc = omap44xx_gpio_sysc,
+ .rev = 2,
};
/* gpio1 */
@@ -1305,7 +1321,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,
+ .clk= gpio1_ick,
.addr = omap44xx_gpio1_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_gpio1_addrs),
.user = OCP_USER_MPU | OCP_USER_SDMA,
@@ -1325,7 +1341,6 @@ static struct omap_hwmod omap44xx_gpio1_hwmod = {
.class = omap44xx_gpio_hwmod_class,
.mpu_irqs = omap44xx_gpio1_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio1_irqs),
- .main_clk = gpio1_ick,
.prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_WKUP_GPIO1_CLKCTRL,
@@ -1333,6 +1348,7 @@ static struct omap_hwmod omap44xx_gpio1_hwmod = {
},
.opt_clks = gpio1_opt_clks,
.opt_clks_cnt = ARRAY_SIZE(gpio1_opt_clks),
+ .dev_attr = gpio1_dev_attr,
.slaves = omap44xx_gpio1_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_gpio1_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
@@ -1356,7 +1372,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,
+ .clk= gpio2_ick,
.addr = omap44xx_gpio2_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_gpio2_addrs),
.user = OCP_USER_MPU | OCP_USER_SDMA,
@@ -1376,7 +1392,6 @@ static struct omap_hwmod omap44xx_gpio2_hwmod = {
.class = omap44xx_gpio_hwmod_class,
.mpu_irqs = omap44xx_gpio2_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio2_irqs),
- .main_clk = gpio2_ick,
.prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_L4PER_GPIO2_CLKCTRL,
@@ -1384,6 +1399,7 @@ static struct omap_hwmod omap44xx_gpio2_hwmod = {
},
.opt_clks = gpio2_opt_clks,
.opt_clks_cnt = ARRAY_SIZE(gpio2_opt_clks),
+ .dev_attr = gpio_dev_attr,
.slaves = omap44xx_gpio2_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_gpio2_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
@@ -1407,7 +1423,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,
+ .clk= gpio3_ick,
.addr = omap44xx_gpio3_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_gpio3_addrs),
.user = OCP_USER_MPU | OCP_USER_SDMA,
@@ -1427,7 +1443,6 @@ static struct omap_hwmod omap44xx_gpio3_hwmod = {
.class = omap44xx_gpio_hwmod_class,
.mpu_irqs = omap44xx_gpio3_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio3_irqs),
- .main_clk = gpio3_ick,
.prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_L4PER_GPIO3_CLKCTRL,
@@ -1435,6 +1450,7 @@ static struct
[PATCH 11/13 v5] OMAP: GPIO: Make gpio_context as part of gpio_bank structure
gpio_context array, which is used to save gpio bank's context,
is used only for OMAP3 architecture.
This patch moves gpio_context as part of gpio_bank structure
so that it can be specific to each gpio bank and can be
used for any OMAP architecture
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/plat-omap/gpio.c | 70 ++---
1 files changed, 34 insertions(+), 36 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index a377d40..6a5cf43 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -132,6 +132,19 @@
#define OMAP4_GPIO_CLEARDATAOUT0x0190
#define OMAP4_GPIO_SETDATAOUT 0x0194
+struct omap_gpio_regs {
+ u32 irqenable1;
+ u32 irqenable2;
+ u32 wake_en;
+ u32 ctrl;
+ u32 oe;
+ u32 leveldetect0;
+ u32 leveldetect1;
+ u32 risingdetect;
+ u32 fallingdetect;
+ u32 dataout;
+};
+
struct gpio_bank {
unsigned long pbase;
void __iomem *base;
@@ -156,27 +169,11 @@ struct gpio_bank {
u32 mod_usage;
u32 dbck_enable_mask;
struct device *dev;
+ struct omap_gpio_regs gpio_context;
bool dbck_flag;
bool off_mode_support;
};
-#ifdef CONFIG_ARCH_OMAP3
-struct omap3_gpio_regs {
- u32 irqenable1;
- u32 irqenable2;
- u32 wake_en;
- u32 ctrl;
- u32 oe;
- u32 leveldetect0;
- u32 leveldetect1;
- u32 risingdetect;
- u32 fallingdetect;
- u32 dataout;
-};
-
-static struct omap3_gpio_regs gpio_context[OMAP34XX_NR_GPIOS];
-#endif
-
/*
* TODO: Cleanup gpio_bank usage as it is having information
* related to all instances of the device
@@ -2032,25 +2029,25 @@ void omap_gpio_save_context(void)
/* saving banks from 2-6 only since GPIO1 is in WKUP */
for (i = 1; i gpio_bank_count; i++) {
struct gpio_bank *bank = gpio_bank[i];
- gpio_context[i].irqenable1 =
+ bank-gpio_context.irqenable1 =
__raw_readl(bank-base + OMAP24XX_GPIO_IRQENABLE1);
- gpio_context[i].irqenable2 =
+ bank-gpio_context.irqenable2 =
__raw_readl(bank-base + OMAP24XX_GPIO_IRQENABLE2);
- gpio_context[i].wake_en =
+ bank-gpio_context.wake_en =
__raw_readl(bank-base + OMAP24XX_GPIO_WAKE_EN);
- gpio_context[i].ctrl =
+ bank-gpio_context.ctrl =
__raw_readl(bank-base + OMAP24XX_GPIO_CTRL);
- gpio_context[i].oe =
+ bank-gpio_context.oe =
__raw_readl(bank-base + OMAP24XX_GPIO_OE);
- gpio_context[i].leveldetect0 =
+ bank-gpio_context.leveldetect0 =
__raw_readl(bank-base + OMAP24XX_GPIO_LEVELDETECT0);
- gpio_context[i].leveldetect1 =
+ bank-gpio_context.leveldetect1 =
__raw_readl(bank-base + OMAP24XX_GPIO_LEVELDETECT1);
- gpio_context[i].risingdetect =
+ bank-gpio_context.risingdetect =
__raw_readl(bank-base + OMAP24XX_GPIO_RISINGDETECT);
- gpio_context[i].fallingdetect =
+ bank-gpio_context.fallingdetect =
__raw_readl(bank-base + OMAP24XX_GPIO_FALLINGDETECT);
- gpio_context[i].dataout =
+ bank-gpio_context.dataout =
__raw_readl(bank-base + OMAP24XX_GPIO_DATAOUT);
}
}
@@ -2063,24 +2060,25 @@ void omap_gpio_restore_context(void)
for (i = 1; i gpio_bank_count; i++) {
struct gpio_bank *bank = gpio_bank[i];
__raw_writel(gpio_context[i].irqenable1,
+ __raw_writel(bank-gpio_context.irqenable1,
bank-base + OMAP24XX_GPIO_IRQENABLE1);
- __raw_writel(gpio_context[i].irqenable2,
+ __raw_writel(bank-gpio_context.irqenable2,
bank-base + OMAP24XX_GPIO_IRQENABLE2);
- __raw_writel(gpio_context[i].wake_en,
+ __raw_writel(bank-gpio_context.wake_en,
bank-base + OMAP24XX_GPIO_WAKE_EN);
- __raw_writel(gpio_context[i].ctrl,
+ __raw_writel(bank-gpio_context.ctrl,
bank-base + OMAP24XX_GPIO_CTRL);
- __raw_writel(gpio_context[i].oe,
+ __raw_writel(bank-gpio_context.oe,
bank-base + OMAP24XX_GPIO_OE);
- __raw_writel(gpio_context[i].leveldetect0,
+ __raw_writel(bank-gpio_context.leveldetect0,
bank-base + OMAP24XX_GPIO_LEVELDETECT0);
- __raw_writel(gpio_context[i].leveldetect1,
+
[PATCH 09/13 v5] OMAP: GPIO: Introduce support for OMAP2PLUS chip GPIO init
This patch adds support for handling GPIO as a HWMOD FW adapted
platform device for OMAP2PLUS chips.
gpio_init needs to be done before machine_init functions access
gpio APIs.Hence gpio_init is made as a postcore_initcall.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap2/gpio.c | 120
1 files changed, 120 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpio.c
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
new file mode 100644
index 000..30aeef9
--- /dev/null
+++ b/arch/arm/mach-omap2/gpio.c
@@ -0,0 +1,120 @@
+/*
+ * gpio.c - OMAP2PLUS-specific gpio code
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * Author:
+ * Charulatha V ch...@ti.com
+ *
+ * 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.
+ */
+
+#include linux/gpio.h
+#include linux/err.h
+#include linux/slab.h
+#include linux/interrupt.h
+
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+
+/*
+ * For GPIO, it is a must to relinquish clocks in the Idle-path
+ * as it is possible to have a GPIO bank requested and still
+ * allow PER domain to go to OFF. In the idle path (interrupt
+ * disabled context), omap_device APIs cannot be used as they
+ * are not mutex-free functions. Hence the below wrappers are
+ * required to handle interrupts disabled context and interrupts
+ * enabled context.
+ */
+static int gpio_enable_hwmod(struct omap_device *od)
+{
+ struct omap_hwmod *oh = *od-hwmods;
+
+ if (irqs_disabled())
+ _omap_hwmod_enable(oh);
+ else
+ omap_device_enable_hwmods(od);
+ return 0;
+}
+
+static int gpio_idle_hwmod(struct omap_device *od)
+{
+ struct omap_hwmod *oh = *od-hwmods;
+
+ if (irqs_disabled())
+ _omap_hwmod_idle(oh);
+ else
+ omap_device_idle_hwmods(od);
+ return 0;
+}
+
+static struct omap_device_pm_latency omap_gpio_latency[] = {
+ [0] = {
+ .deactivate_func = gpio_idle_hwmod,
+ .activate_func = gpio_enable_hwmod,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+static int omap2_init_gpio(struct omap_hwmod *oh, void *user)
+{
+ struct omap_device *od;
+ struct omap_gpio_platform_data *pdata;
+ char *name = omap-gpio;
+ static int id;
+ struct omap_gpio_dev_attr *gpio_dev_data;
+
+ if (!oh) {
+ pr_err(Could not look up omap gpio %d\n, id + 1);
+ return -EINVAL;
+ }
+
+ pdata = kzalloc(sizeof(struct omap_gpio_platform_data),
+ GFP_KERNEL);
+ if (!pdata) {
+ pr_err(Memory allocation failed gpio%d\n, id + 1);
+ return -ENOMEM;
+ }
+
+ gpio_dev_data = (struct omap_gpio_dev_attr *)oh-dev_attr;
+
+ pdata-gpio_attr = gpio_dev_data;
+ pdata-virtual_irq_start = IH_GPIO_BASE + 32 * id;
+ switch (oh-class-rev) {
+ case 0:
+ case 1:
+ pdata-bank_type = METHOD_GPIO_24XX;
+ break;
+ case 2:
+ pdata-bank_type = METHOD_GPIO_44XX;
+ break;
+ default:
+ WARN(1, Invalid gpio bank_type\n);
+ break;
+ }
+ gpio_bank_count++;
+
+ od = omap_device_build(name, id, oh, pdata,
+ sizeof(*pdata), omap_gpio_latency,
+ ARRAY_SIZE(omap_gpio_latency),
+ false);
+ WARN(IS_ERR(od), Cant build omap_device for %s:%s.\n,
+ name, oh-name);
+
+ id++;
+ return 0;
+}
+
+/*
+ * gpio_init needs to be done before
+ * machine_init functions access gpio APIs.
+ * Hence gpio_init is a postcore_initcall.
+ */
+static int __init omap2_gpio_init(void)
+{
+ return omap_hwmod_for_each_by_class(gpio, omap2_init_gpio,
+ NULL);
+}
+postcore_initcall(omap2_gpio_init);
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/13 v5] OMAP: GPIO: Implement GPIO as a platform device
This patch implements GPIO as a platform device. Also it
implements OMAP2PLUS specific GPIO as HWMOD FW adapted device.
This patch makes GPIO to use runtime APIs.
GPIO APIs are used in machine_init functions. Hence it is
required to complete GPIO probe before machine_init. Therefore
GPIO device register and driver register are implemented as
postcore_initcalls.
Inorder to convert GPIO as platform device, modifications are
required in clock_data.c file for OMAP1 so that device names
can be used to obtain clock instead of getting clocks by
name/NULL ptr.
omap_gpio_init() does nothing now and this function would be
removed in the next patch as it's usage is spread across most of
the board files.
TODO:
1. Cleanup the GPIO driver. Use function pointers and register
offest pointers instead of using hardcoded values
2. Remove all cpu_is_ checks and OMAP specific macros
3. Remove usage of gpio_bank array so that only
instance specific information is used in driver code
4. Rename 'method'/ avoid it's usage
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap1/Makefile |6 +
arch/arm/mach-omap1/clock_data.c |4 +-
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/plat-omap/gpio.c | 428
arch/arm/plat-omap/include/plat/gpio.h |3 +
5 files changed, 121 insertions(+), 322 deletions(-)
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 9a304d8..b014bb1 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -49,6 +49,12 @@ ifeq ($(CONFIG_ARCH_OMAP15XX),y)
obj-$(CONFIG_MACH_OMAP_INNOVATOR) += fpga.o
endif
+# GPIO
+obj-$(CONFIG_ARCH_OMAP730) += gpio7xx.o
+obj-$(CONFIG_ARCH_OMAP850) += gpio7xx.o
+obj-$(CONFIG_ARCH_OMAP15XX)+= gpio15xx.o
+obj-$(CONFIG_ARCH_OMAP16XX)+= gpio16xx.o
+
# LEDs support
led-$(CONFIG_MACH_OMAP_H2) += leds-h2p2-debug.o
led-$(CONFIG_MACH_OMAP_H3) += leds-h2p2-debug.o
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index af54114..cbdcf9c 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -143,7 +143,7 @@ static struct arm_idlect1_clk armper_ck = {
* activation. [ GPIO code for 1510 ]
*/
static struct clk arm_gpio_ck = {
- .name = arm_gpio_ck,
+ .name = ick,
.ops= clkops_generic,
.parent = ck_dpll1,
.flags = ENABLE_ON_INIT,
@@ -684,7 +684,7 @@ static struct omap_clk omap_clks[] = {
CLK(NULL, ck_sossi, sossi_ck, CK_16XX),
CLK(NULL, arm_ck, arm_ck,CK_16XX | CK_1510 |
CK_310),
CLK(NULL, armper_ck,armper_ck.clk, CK_16XX | CK_1510 |
CK_310),
- CLK(NULL, arm_gpio_ck, arm_gpio_ck, CK_1510 | CK_310),
+ CLK(omap-gpio.0, ick, arm_gpio_ck, CK_1510 | CK_310),
CLK(NULL, armxor_ck,armxor_ck.clk, CK_16XX | CK_1510 |
CK_310 | CK_7XX),
CLK(NULL, armtim_ck,armtim_ck.clk, CK_16XX | CK_1510 |
CK_310),
CLK(omap_wdt, fck, armwdt_ck.clk, CK_16XX | CK_1510 |
CK_310),
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 800b430..9dcc4b5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -3,7 +3,7 @@
#
# Common support
-obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o
+obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o
gpio.o
omap-2-3-common= irq.o sdrc.o
hwmod-common = omap_hwmod.o \
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index dfe4b9e..a377d40 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -21,7 +21,10 @@
#include linux/err.h
#include linux/clk.h
#include linux/io.h
+#include linux/slab.h
+#include linux/pm_runtime.h
+#include plat/omap_device.h
#include mach/hardware.h
#include asm/irq.h
#include mach/irqs.h
@@ -32,7 +35,6 @@
/*
* OMAP1510 GPIO registers
*/
-#define OMAP1510_GPIO_BASE 0xfffce000
#define OMAP1510_GPIO_DATA_INPUT 0x00
#define OMAP1510_GPIO_DATA_OUTPUT 0x04
#define OMAP1510_GPIO_DIR_CONTROL 0x08
@@ -46,10 +48,6 @@
/*
* OMAP1610 specific GPIO registers
*/
-#define OMAP1610_GPIO1_BASE0xfffbe400
-#define OMAP1610_GPIO2_BASE0xfffbec00
-#define OMAP1610_GPIO3_BASE0xfffbb400
-#define OMAP1610_GPIO4_BASE0xfffbbc00
#define OMAP1610_GPIO_REVISION 0x
#define OMAP1610_GPIO_SYSCONFIG0x0010
#define OMAP1610_GPIO_SYSSTATUS0x0014
@@ -71,12 +69,6 @@
/*
* OMAP7XX specific GPIO registers
*/
-#define OMAP7XX_GPIO1_BASE
[PATCH 12/13 v5] OMAP: GPIO: Use dev_pm_ops instead of sys_dev_class
This patch makes GPIO driver to use dev_pm_ops instead of
sysdev_class. With this approach, gpio_bank_suspend gpio_bank_resume
are not part of sys_dev_class.
According to this patch, a GPIO bank relinquishes the clock using
PM runtime APIs when all the gpios in that bank are freed. It also
relinquishes the clocks in the idle-path too, as it is possible to
have a GPIO bank requested and still allow PER domain to go to OFF state.
In the idle path (interrupt disabled context), PM runtime APIs cannot
be used as they are not mutex-free functions. Hence omap_device APIs
are used in the idle and resume after idle path.
To summarize,
1. pm_runtime_get_sync() for any gpio bank is called when one of the gpios
is requested on the bank, in which, no other gpio is being used (when
mod_usage becomes non-zero)
2. omap_device_enable() is called during gpio resume after idle, only
if the particular bank is being used (if mod_usage is non-zero)
3. pm_runtime_put_sync() is called when the last used gpio in that
gpio bank is freed (when mod_usage becomes zero)
4. omap_device_idle() is called during idle, if the particular bank
is being used (if mod_usage is non-zero)
With this patch, GPIO's prepare_for_idle and resume_after_idle APIs
makes use of the parameter save_context and restore_context respectively
inorder to identify if save context/restore context needs to be done.
Links to related discussion:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32833.html
For suspend/resume path to work, this patch has dependency of
1. reverting the following patch:
OMAP: bus-level PM: enable use of runtime PM API for suspend/resume
http://dev.omapzoom.org/?p=swarch/linux-omap-adv.git;a=commitdiff;
h=8041359e18e49bf8a3d41f15894db9e476f3a8fc
(or)
2. Remove the locking in the omap_hwmod_for_each* function
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap2/pm24xx.c |4 +-
arch/arm/mach-omap2/pm34xx.c | 23 +-
arch/arm/plat-omap/gpio.c | 561
arch/arm/plat-omap/include/plat/gpio.h |6 +-
4 files changed, 297 insertions(+), 297 deletions(-)
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index 6aeedea..c01e156 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -106,7 +106,7 @@ static void omap2_enter_full_retention(void)
l = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0) | OMAP24XX_USBSTANDBYCTRL;
omap_ctrl_writel(l, OMAP2_CONTROL_DEVCONF0);
- omap2_gpio_prepare_for_idle(PWRDM_POWER_RET);
+ omap2_gpio_prepare_for_idle(false);
if (omap2_pm_debug) {
omap2_pm_dump(0, 0, 0);
@@ -140,7 +140,7 @@ no_sleep:
tmp = timespec_to_ns(ts_idle) * NSEC_PER_USEC;
omap2_pm_dump(0, 1, tmp);
}
- omap2_gpio_resume_after_idle();
+ omap2_gpio_resume_after_idle(false);
clk_enable(osc_ck);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index fb4994a..66c7e11 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -79,16 +79,6 @@ static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
static struct powerdomain *core_pwrdm, *per_pwrdm;
static struct powerdomain *cam_pwrdm;
-static inline void omap3_per_save_context(void)
-{
- omap_gpio_save_context();
-}
-
-static inline void omap3_per_restore_context(void)
-{
- omap_gpio_restore_context();
-}
-
static void omap3_enable_io_chain(void)
{
int timeout = 0;
@@ -395,15 +385,17 @@ void omap_sram_idle(void)
/* PER */
if (per_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(2);
- omap2_gpio_prepare_for_idle(per_next_state);
if (per_next_state == PWRDM_POWER_OFF) {
if (core_next_state == PWRDM_POWER_ON) {
per_next_state = PWRDM_POWER_RET;
pwrdm_set_next_pwrst(per_pwrdm, per_next_state);
per_state_modified = 1;
- } else
- omap3_per_save_context();
+ }
}
+ if (per_next_state == PWRDM_POWER_OFF)
+ omap2_gpio_prepare_for_idle(true);
+ else
+ omap2_gpio_prepare_for_idle(false);
}
if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
@@ -471,9 +463,10 @@ void omap_sram_idle(void)
/* PER */
if (per_next_state PWRDM_POWER_ON) {
per_prev_state = pwrdm_read_prev_pwrst(per_pwrdm);
- omap2_gpio_resume_after_idle();
if (per_prev_state == PWRDM_POWER_OFF)
- omap3_per_restore_context();
+ omap2_gpio_resume_after_idle(true);
+ else
+
[PATCH 13/13 v5] OMAP: GPIO: Remove omap_gpio_init()
This patch removes the usage of omap_gpio_init() from all
omap board files since omap_gpio_init() does nothing, after gpio
is implemented as a platform device.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap1/board-ams-delta.c |1 -
arch/arm/mach-omap1/board-fsample.c|1 -
arch/arm/mach-omap1/board-h2.c |1 -
arch/arm/mach-omap1/board-h3.c |1 -
arch/arm/mach-omap1/board-htcherald.c |1 -
arch/arm/mach-omap1/board-innovator.c |1 -
arch/arm/mach-omap1/board-nokia770.c |1 -
arch/arm/mach-omap1/board-osk.c|1 -
arch/arm/mach-omap1/board-palmte.c |1 -
arch/arm/mach-omap1/board-palmz71.c|1 -
arch/arm/mach-omap1/board-perseus2.c |1 -
arch/arm/mach-omap1/board-sx1.c|1 -
arch/arm/mach-omap1/board-voiceblue.c |1 -
arch/arm/mach-omap2/board-2430sdp.c|1 -
arch/arm/mach-omap2/board-3430sdp.c|1 -
arch/arm/mach-omap2/board-3630sdp.c|1 -
arch/arm/mach-omap2/board-4430sdp.c|1 -
arch/arm/mach-omap2/board-am3517evm.c |1 -
arch/arm/mach-omap2/board-apollon.c|1 -
arch/arm/mach-omap2/board-cm-t35.c |1 -
arch/arm/mach-omap2/board-devkit8000.c |1 -
arch/arm/mach-omap2/board-h4.c |1 -
arch/arm/mach-omap2/board-igep0020.c |1 -
arch/arm/mach-omap2/board-ldp.c|1 -
arch/arm/mach-omap2/board-n8x0.c |1 -
arch/arm/mach-omap2/board-omap3beagle.c|1 -
arch/arm/mach-omap2/board-omap3evm.c |1 -
arch/arm/mach-omap2/board-omap3pandora.c |1 -
arch/arm/mach-omap2/board-omap3stalker.c |1 -
arch/arm/mach-omap2/board-omap3touchbook.c |1 -
arch/arm/mach-omap2/board-omap4panda.c |1 -
arch/arm/mach-omap2/board-overo.c |1 -
arch/arm/mach-omap2/board-rx51.c |1 -
arch/arm/mach-omap2/board-zoom2.c |1 -
arch/arm/mach-omap2/board-zoom3.c |1 -
35 files changed, 0 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 41992ab..774867f 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -136,7 +136,6 @@ static void __init ams_delta_init_irq(void)
{
omap1_init_common_hw();
omap_init_irq();
- omap_gpio_init();
}
static struct map_desc ams_delta_io_desc[] __initdata = {
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index 180ce79..09b6165 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -325,7 +325,6 @@ static void __init omap_fsample_init_irq(void)
{
omap1_init_common_hw();
omap_init_irq();
- omap_gpio_init();
fsample_init_smc91x();
}
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index d2cda58..cf9aaff 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -374,7 +374,6 @@ static void __init h2_init_irq(void)
{
omap1_init_common_hw();
omap_init_irq();
- omap_gpio_init();
h2_init_smc91x();
}
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index c2ef4ff..423b45e 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -435,7 +435,6 @@ static void __init h3_init_irq(void)
{
omap1_init_common_hw();
omap_init_irq();
- omap_gpio_init();
h3_init_smc91x();
}
diff --git a/arch/arm/mach-omap1/board-htcherald.c
b/arch/arm/mach-omap1/board-htcherald.c
index 311899f..bc8f56f 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -278,7 +278,6 @@ static void __init htcherald_init(void)
{
printk(KERN_INFO HTC Herald init.\n);
- omap_gpio_init();
omap_board_config = htcherald_config;
omap_board_config_size = ARRAY_SIZE(htcherald_config);
diff --git a/arch/arm/mach-omap1/board-innovator.c
b/arch/arm/mach-omap1/board-innovator.c
index 3daf87a..27c283d 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -290,7 +290,6 @@ static void __init innovator_init_irq(void)
{
omap1_init_common_hw();
omap_init_irq();
- omap_gpio_init();
#ifdef CONFIG_ARCH_OMAP15XX
if (cpu_is_omap1510()) {
omap1510_fpga_init_irq();
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index 51a4539..397febe 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -246,7 +246,6 @@ static void __init omap_nokia770_init(void)
platform_add_devices(nokia770_devices, ARRAY_SIZE(nokia770_devices));
[PATCH 04/13 v5] OMAP: GPIO: Introduce support for OMAP7xx chip GPIO init
This patch adds support for handling OMAP7xx specific gpio_init
by providing platform device data and doing device registration.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap1/gpio7xx.c | 274 +
1 files changed, 274 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap1/gpio7xx.c
diff --git a/arch/arm/mach-omap1/gpio7xx.c b/arch/arm/mach-omap1/gpio7xx.c
new file mode 100644
index 000..c8cebc4
--- /dev/null
+++ b/arch/arm/mach-omap1/gpio7xx.c
@@ -0,0 +1,274 @@
+/*
+ * OMAP7XX-specific gpio code
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * Author:
+ * Charulatha V ch...@ti.com
+ *
+ * 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.
+ */
+
+#include linux/gpio.h
+
+#define OMAP7XX_GPIO1_BASE 0xfffbc000
+#define OMAP7XX_GPIO2_BASE 0xfffbc800
+#define OMAP7XX_GPIO3_BASE 0xfffbd000
+#define OMAP7XX_GPIO4_BASE 0xfffbd800
+#define OMAP7XX_GPIO5_BASE 0xfffbe000
+#define OMAP7XX_GPIO6_BASE 0xfffbe800
+#define OMAP1_MPUIO_VBASE OMAP1_MPUIO_BASE
+
+static struct omap_gpio_dev_attr omap7xx_gpio_attr = {
+ .bank_width = 32,
+};
+
+/*
+ * OMAP7XX MPU GPIO interface data
+ */
+static struct __initdata resource omap7xx_mpu_gpio_resources[] = {
+ {
+ .start = OMAP1_MPUIO_VBASE,
+ .end= OMAP1_MPUIO_VBASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_7XX_MPUIO,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct __initdata omap_gpio_platform_data omap7xx_mpu_gpio_config = {
+ .virtual_irq_start = IH_MPUIO_BASE,
+ .bank_type = METHOD_MPUIO,
+ .gpio_attr = omap7xx_gpio_attr,
+};
+
+static struct __initdata platform_device omap7xx_mpu_gpio = {
+ .name = omap-gpio,
+ .id = 0,
+ .dev= {
+ .platform_data = omap7xx_mpu_gpio_config,
+ },
+ .num_resources = ARRAY_SIZE(omap7xx_mpu_gpio_resources),
+ .resource = omap7xx_mpu_gpio_resources,
+};
+
+/*
+ * OMAP7XX GPIO1 interface data
+ */
+static struct __initdata resource omap7xx_gpio1_resources[] = {
+ {
+ .start = OMAP7XX_GPIO1_BASE,
+ .end= OMAP7XX_GPIO1_BASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_7XX_GPIO_BANK1,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct __initdata omap_gpio_platform_data omap7xx_gpio1_config = {
+ .virtual_irq_start = IH_GPIO_BASE,
+ .bank_type = METHOD_GPIO_7XX,
+ .gpio_attr = omap7xx_gpio_attr,
+};
+
+static struct __initdata platform_device omap7xx_gpio1 = {
+ .name = omap-gpio,
+ .id = 1,
+ .dev= {
+ .platform_data = omap7xx_gpio1_config,
+ },
+ .num_resources = ARRAY_SIZE(omap7xx_gpio1_resources),
+ .resource = omap7xx_gpio1_resources,
+};
+
+/*
+ * OMAP7XX GPIO2 interface data
+ */
+static struct __initdata resource omap7xx_gpio2_resources[] = {
+ {
+ .start = OMAP7XX_GPIO2_BASE,
+ .end= OMAP7XX_GPIO2_BASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_7XX_GPIO_BANK2,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct __initdata omap_gpio_platform_data omap7xx_gpio2_config = {
+ .virtual_irq_start = IH_GPIO_BASE + 32,
+ .bank_type = METHOD_GPIO_7XX,
+ .gpio_attr = omap7xx_gpio_attr,
+};
+
+static struct __initdata platform_device omap7xx_gpio2 = {
+ .name = omap-gpio,
+ .id = 2,
+ .dev= {
+ .platform_data = omap7xx_gpio2_config,
+ },
+ .num_resources = ARRAY_SIZE(omap7xx_gpio2_resources),
+ .resource = omap7xx_gpio2_resources,
+};
+
+/*
+ * OMAP7XX GPIO3 interface data
+ */
+static struct __initdata resource omap7xx_gpio3_resources[] = {
+ {
+ .start = OMAP7XX_GPIO3_BASE,
+ .end= OMAP7XX_GPIO3_BASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_7XX_GPIO_BANK3,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct __initdata omap_gpio_platform_data omap7xx_gpio3_config = {
+ .virtual_irq_start = IH_GPIO_BASE + 64,
+ .bank_type = METHOD_GPIO_7XX,
+ .gpio_attr = omap7xx_gpio_attr,
+};
+
+static struct __initdata platform_device omap7xx_gpio3 = {
+ .name
[PATCH 05/13 v5] OMAP: GPIO: add GPIO hwmods structures for OMAP3
Add hwmod structures for GPIO module on OMAP3
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 382
1 files changed, 382 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 5d8eb58..90fb907 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -17,6 +17,7 @@
#include mach/irqs.h
#include plat/cpu.h
#include plat/dma.h
+#include plat/gpio.h
#include omap_hwmod_common_data.h
@@ -36,6 +37,12 @@ static struct omap_hwmod omap3xxx_iva_hwmod;
static struct omap_hwmod omap3xxx_l3_main_hwmod;
static struct omap_hwmod omap3xxx_l4_core_hwmod;
static struct omap_hwmod omap3xxx_l4_per_hwmod;
+static struct omap_hwmod omap3xxx_gpio1_hwmod;
+static struct omap_hwmod omap3xxx_gpio2_hwmod;
+static struct omap_hwmod omap3xxx_gpio3_hwmod;
+static struct omap_hwmod omap3xxx_gpio4_hwmod;
+static struct omap_hwmod omap3xxx_gpio5_hwmod;
+static struct omap_hwmod omap3xxx_gpio6_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -197,6 +204,375 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
};
+/* L4 WKUP - GPIO1 interface */
+
+static struct omap_hwmod_addr_space omap3xxx_gpio1_addrs[] = {
+ {
+ .pa_start = 0x4831,
+ .pa_end = 0x483101ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__gpio1 = {
+ .master = omap3xxx_l4_wkup_hwmod,
+ .slave = omap3xxx_gpio1_hwmod,
+ .clk= gpio1_ick,
+ .addr = omap3xxx_gpio1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_gpio1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 PER - GPIO2 interface */
+
+static struct omap_hwmod_addr_space omap3xxx_gpio2_addrs[] = {
+ {
+ .pa_start = 0x4905,
+ .pa_end = 0x490501ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio2 = {
+ .master = omap3xxx_l4_per_hwmod,
+ .slave = omap3xxx_gpio2_hwmod,
+ .clk= gpio2_ick,
+ .addr = omap3xxx_gpio2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_gpio2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 PER - GPIO3 interface */
+
+static struct omap_hwmod_addr_space omap3xxx_gpio3_addrs[] = {
+ {
+ .pa_start = 0x49052000,
+ .pa_end = 0x490521ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio3 = {
+ .master = omap3xxx_l4_per_hwmod,
+ .slave = omap3xxx_gpio3_hwmod,
+ .clk= gpio3_ick,
+ .addr = omap3xxx_gpio3_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_gpio3_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 PER - GPIO4 interface */
+
+static struct omap_hwmod_addr_space omap3xxx_gpio4_addrs[] = {
+ {
+ .pa_start = 0x49054000,
+ .pa_end = 0x490541ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio4 = {
+ .master = omap3xxx_l4_per_hwmod,
+ .slave = omap3xxx_gpio4_hwmod,
+ .clk= gpio4_ick,
+ .addr = omap3xxx_gpio4_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_gpio4_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 PER - GPIO5 interface */
+
+static struct omap_hwmod_addr_space omap3xxx_gpio5_addrs[] = {
+ {
+ .pa_start = 0x49056000,
+ .pa_end = 0x490561ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio5 = {
+ .master = omap3xxx_l4_per_hwmod,
+ .slave = omap3xxx_gpio5_hwmod,
+ .clk= gpio5_ick,
+ .addr = omap3xxx_gpio5_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_gpio5_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 PER - GPIO6 interface */
+
+static struct omap_hwmod_addr_space omap3xxx_gpio6_addrs[] = {
+ {
+ .pa_start = 0x49058000,
+ .pa_end = 0x490581ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio6 = {
+ .master = omap3xxx_l4_per_hwmod,
+ .slave = omap3xxx_gpio6_hwmod,
+ .clk
[PATCH 07/13 v5] OMAP: GPIO: add GPIO hwmods structures for OMAP243X
Add hwmod structures for GPIO module on OMAP243X
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 290
1 files changed, 290 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 4526628..d3582e1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -15,6 +15,7 @@
#include mach/irqs.h
#include plat/cpu.h
#include plat/dma.h
+#include plat/gpio.h
#include omap_hwmod_common_data.h
@@ -33,6 +34,11 @@ static struct omap_hwmod omap2430_mpu_hwmod;
static struct omap_hwmod omap2430_iva_hwmod;
static struct omap_hwmod omap2430_l3_main_hwmod;
static struct omap_hwmod omap2430_l4_core_hwmod;
+static struct omap_hwmod omap2430_gpio1_hwmod;
+static struct omap_hwmod omap2430_gpio2_hwmod;
+static struct omap_hwmod omap2430_gpio3_hwmod;
+static struct omap_hwmod omap2430_gpio4_hwmod;
+static struct omap_hwmod omap2430_gpio5_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap2430_l3_main__l4_core = {
@@ -165,12 +171,296 @@ static struct omap_hwmod omap2430_iva_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
};
+/* L4 WKUP - GPIO1 interface */
+
+static struct omap_hwmod_addr_space omap2430_gpio1_addr_space[] = {
+ {
+ .pa_start = 0x4900C000,
+ .pa_end = 0x4900C1ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__gpio1 = {
+ .master = omap2430_l4_wkup_hwmod,
+ .slave = omap2430_gpio1_hwmod,
+ .clk= gpios_ick,
+ .addr = omap2430_gpio1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_gpio1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 WKUP - GPIO2 interface */
+
+static struct omap_hwmod_addr_space omap2430_gpio2_addr_space[] = {
+ {
+ .pa_start = 0x4900E000,
+ .pa_end = 0x4900E1ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__gpio2 = {
+ .master = omap2430_l4_wkup_hwmod,
+ .slave = omap2430_gpio2_hwmod,
+ .clk= gpios_ick,
+ .addr = omap2430_gpio2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_gpio2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 WKUP - GPIO3 interface */
+
+static struct omap_hwmod_addr_space omap2430_gpio3_addr_space[] = {
+ {
+ .pa_start = 0x4901,
+ .pa_end = 0x490101ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__gpio3 = {
+ .master = omap2430_l4_wkup_hwmod,
+ .slave = omap2430_gpio3_hwmod,
+ .clk= gpios_ick,
+ .addr = omap2430_gpio3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_gpio3_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 WKUP - GPIO4 interface */
+
+static struct omap_hwmod_addr_space omap2430_gpio4_addr_space[] = {
+ {
+ .pa_start = 0x49012000,
+ .pa_end = 0x490121ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__gpio4 = {
+ .master = omap2430_l4_wkup_hwmod,
+ .slave = omap2430_gpio4_hwmod,
+ .clk= gpios_ick,
+ .addr = omap2430_gpio4_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_gpio4_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 CORE - GPIO5 interface */
+
+static struct omap_hwmod_addr_space omap2430_gpio5_addr_space[] = {
+ {
+ .pa_start = 0x480B6000,
+ .pa_end = 0x480B61ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_core__gpio5 = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_gpio5_hwmod,
+ .clk= gpio5_ick,
+ .addr = omap2430_gpio5_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_gpio5_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* GPIO common */
+
+static struct omap_gpio_dev_attr gpio_dev_attr = {
+ .bank_width = 32,
+ .dbck_flag = false,
+ /*
+* off_mode is supported by GPIO, but it is not
+* supported by software due to leakage current problem.
+* Hence making off_mode_support flag as false
+*/
+ .off_mode_support = false,
+};
+
+static struct omap_hwmod_class_sysconfig omap243x_gpio_sysc = {
+
[PATCH 06/13 v5] OMAP: GPIO: add GPIO hwmods structures for OMAP242X
Add hwmod structures for GPIO module on OMAP242X
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 234
1 files changed, 234 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 3cc768e..228ffe4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -15,6 +15,7 @@
#include mach/irqs.h
#include plat/cpu.h
#include plat/dma.h
+#include plat/gpio.h
#include omap_hwmod_common_data.h
@@ -33,6 +34,10 @@ static struct omap_hwmod omap2420_mpu_hwmod;
static struct omap_hwmod omap2420_iva_hwmod;
static struct omap_hwmod omap2420_l3_main_hwmod;
static struct omap_hwmod omap2420_l4_core_hwmod;
+static struct omap_hwmod omap2420_gpio1_hwmod;
+static struct omap_hwmod omap2420_gpio2_hwmod;
+static struct omap_hwmod omap2420_gpio3_hwmod;
+static struct omap_hwmod omap2420_gpio4_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -165,12 +170,241 @@ static struct omap_hwmod omap2420_iva_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
};
+/* L4 WKUP - GPIO1 interface */
+static struct omap_hwmod_addr_space omap2420_gpio1_addr_space[] = {
+ {
+ .pa_start = 0x48018000,
+ .pa_end = 0x480181ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio1 = {
+ .master = omap2420_l4_wkup_hwmod,
+ .slave = omap2420_gpio1_hwmod,
+ .clk= gpios_ick,
+ .addr = omap2420_gpio1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_gpio1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 WKUP - GPIO2 interface */
+static struct omap_hwmod_addr_space omap2420_gpio2_addr_space[] = {
+ {
+ .pa_start = 0x4801a000,
+ .pa_end = 0x4801a1ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio2 = {
+ .master = omap2420_l4_wkup_hwmod,
+ .slave = omap2420_gpio2_hwmod,
+ .clk= gpios_ick,
+ .addr = omap2420_gpio2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_gpio2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 WKUP - GPIO3 interface */
+static struct omap_hwmod_addr_space omap2420_gpio3_addr_space[] = {
+ {
+ .pa_start = 0x4801c000,
+ .pa_end = 0x4801c1ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio3 = {
+ .master = omap2420_l4_wkup_hwmod,
+ .slave = omap2420_gpio3_hwmod,
+ .clk= gpios_ick,
+ .addr = omap2420_gpio3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_gpio3_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 WKUP - GPIO4 interface */
+static struct omap_hwmod_addr_space omap2420_gpio4_addr_space[] = {
+ {
+ .pa_start = 0x4801e000,
+ .pa_end = 0x4801e1ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__gpio4 = {
+ .master = omap2420_l4_wkup_hwmod,
+ .slave = omap2420_gpio4_hwmod,
+ .clk= gpios_ick,
+ .addr = omap2420_gpio4_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_gpio4_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* GPIO common */
+
+static struct omap_gpio_dev_attr gpio_dev_attr = {
+ .bank_width = 32,
+ .dbck_flag = false,
+ /*
+* off_mode is supported by GPIO, but it is not
+* supported by software due to leakage current problem.
+* Hence making off_mode_support flag as false
+*/
+ .off_mode_support = false,
+};
+
+static struct omap_hwmod_class_sysconfig omap242x_gpio_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .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 omap242x_gpio_hwmod_class = {
+ .name = gpio,
+ .sysc = omap242x_gpio_sysc,
+ .rev = 0,
+};
+
+/* GPIO1 */
+
+static struct omap_hwmod_irq_info omap242x_gpio1_irqs[] = {
+ { .name = gpio_mpu_irq, .irq = INT_24XX_GPIO_BANK1 },
+};
+
+static struct omap_hwmod_ocp_if *omap2420_gpio1_slaves[] = {
+
[PATCH 03/13 v5] OMAP: GPIO: Introduce support for OMAP16xx chip GPIO init
This patch adds support for handling OMAP16xx specific gpio_init
by providing platform device data and doing device registration.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap1/gpio16xx.c | 208
1 files changed, 208 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap1/gpio16xx.c
diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
new file mode 100644
index 000..727c52b
--- /dev/null
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -0,0 +1,208 @@
+/*
+ * OMAP16XX-specific gpio code
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * Author:
+ * Charulatha V ch...@ti.com
+ *
+ * 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.
+ */
+
+#include linux/gpio.h
+
+#define OMAP1610_GPIO1_BASE0xfffbe400
+#define OMAP1610_GPIO2_BASE0xfffbec00
+#define OMAP1610_GPIO3_BASE0xfffbb400
+#define OMAP1610_GPIO4_BASE0xfffbbc00
+#define OMAP1_MPUIO_VBASE OMAP1_MPUIO_BASE
+
+static struct omap_gpio_dev_attr omap16xx_gpio_attr = {
+ .bank_width = 16,
+};
+
+/*
+ * OMAP16XX MPU GPIO interface data
+ */
+static struct __initdata resource omap16xx_mpu_gpio_resources[] = {
+ {
+ .start = OMAP1_MPUIO_VBASE,
+ .end= OMAP1_MPUIO_VBASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_MPUIO,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct __initdata omap_gpio_platform_data omap16xx_mpu_gpio_config = {
+ .virtual_irq_start = IH_MPUIO_BASE,
+ .bank_type = METHOD_MPUIO,
+ .gpio_attr = omap16xx_gpio_attr,
+};
+
+static struct __initdata platform_device omap16xx_mpu_gpio = {
+ .name = omap-gpio,
+ .id = 0,
+ .dev= {
+ .platform_data = omap16xx_mpu_gpio_config,
+ },
+ .num_resources = ARRAY_SIZE(omap16xx_mpu_gpio_resources),
+ .resource = omap16xx_mpu_gpio_resources,
+};
+
+/*
+ * OMAP16XX GPIO1 interface data
+ */
+static struct __initdata resource omap16xx_gpio1_resources[] = {
+ {
+ .start = OMAP1610_GPIO1_BASE,
+ .end= OMAP1610_GPIO1_BASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_GPIO_BANK1,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct __initdata omap_gpio_platform_data omap16xx_gpio1_config = {
+ .virtual_irq_start = IH_GPIO_BASE,
+ .bank_type = METHOD_GPIO_1610,
+ .gpio_attr = omap16xx_gpio_attr,
+};
+
+static struct __initdata platform_device omap16xx_gpio1 = {
+ .name = omap-gpio,
+ .id = 1,
+ .dev= {
+ .platform_data = omap16xx_gpio1_config,
+ },
+ .num_resources = ARRAY_SIZE(omap16xx_gpio1_resources),
+ .resource = omap16xx_gpio1_resources,
+};
+
+/*
+ * OMAP16XX GPIO2 interface data
+ */
+static struct __initdata resource omap16xx_gpio2_resources[] = {
+ {
+ .start = OMAP1610_GPIO2_BASE,
+ .end= OMAP1610_GPIO2_BASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_1610_GPIO_BANK2,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct __initdata omap_gpio_platform_data omap16xx_gpio2_config = {
+ .virtual_irq_start = IH_GPIO_BASE + 16,
+ .bank_type = METHOD_GPIO_1610,
+ .gpio_attr = omap16xx_gpio_attr,
+};
+
+static struct __initdata platform_device omap16xx_gpio2 = {
+ .name = omap-gpio,
+ .id = 2,
+ .dev= {
+ .platform_data = omap16xx_gpio2_config,
+ },
+ .num_resources = ARRAY_SIZE(omap16xx_gpio2_resources),
+ .resource = omap16xx_gpio2_resources,
+};
+
+/*
+ * OMAP16XX GPIO3 interface data
+ */
+static struct __initdata resource omap16xx_gpio3_resources[] = {
+ {
+ .start = OMAP1610_GPIO3_BASE,
+ .end= OMAP1610_GPIO3_BASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_1610_GPIO_BANK3,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct __initdata omap_gpio_platform_data omap16xx_gpio3_config = {
+ .virtual_irq_start = IH_GPIO_BASE + 32,
+ .bank_type = METHOD_GPIO_1610,
+ .gpio_attr = omap16xx_gpio_attr,
+};
+
+static struct __initdata platform_device omap16xx_gpio3 = {
+ .name = omap-gpio,
+ .id = 3,
+ .dev
RE: [PATCH] OMAP4: HWMOD: Do omap_hwmod_late_init for OMAP4
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Varadarajan, Charulatha
Sent: Friday, August 06, 2010 6:01 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit; Nayak,
Rajendra; Varadarajan, Charulatha; Basak, Partha
Subject: [PATCH] OMAP4: HWMOD: Do omap_hwmod_late_init for OMAP4
This patch includes cpu_is check for omap44xx cpu inorder to do
omap_hwmod_late_init() without which hwmods initialization does not
happen for omap4.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
---
arch/arm/mach-omap2/io.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index b89e678..9b15f46 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -345,7 +345,7 @@ void __init omap2_init_common_hw(struct
omap_sdrc_params *sdrc_cs0,
#ifndef CONFIG_PM_RUNTIME
skip_setup_idle = 1;
#endif
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) /* FIXME: OMAP4 */
+ if (cpu_is_omap24xx() || cpu_is_omap34xx() || cpu_is_omap44xx())
Rather use now
if (cpu_class_is_omap2())
omap_hwmod_late_init(skip_setup_idle);
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: HWMOD: Do omap_hwmod_late_init for OMAP4
Hi Charu,
On 8/6/2010 2:31 PM, Varadarajan, Charulatha wrote:
This patch includes cpu_is check for omap44xx cpu inorder to do
omap_hwmod_late_init() without which hwmods initialization does not
happen for omap4.
Signed-off-by: Charulatha Vch...@ti.com
Signed-off-by: Basak, Parthap-bas...@ti.com
---
arch/arm/mach-omap2/io.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index b89e678..9b15f46 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -345,7 +345,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
#ifndef CONFIG_PM_RUNTIME
skip_setup_idle = 1;
#endif
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) /* FIXME: OMAP4 */
+ if (cpu_is_omap24xx() || cpu_is_omap34xx() || cpu_is_omap44xx())
omap_hwmod_late_init(skip_setup_idle);
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
This is already done in this patch:
[PATCH v3 1/7] OMAP4: hwmod: Add initial data for OMAP4430 ES1 ES2
https://patchwork.kernel.org/patch/117347/
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: [PATCH 7/7] omap3: make coresight register save across OFF modes a sysfs option
On Sun, Jul 25, 2010 at 08:05:20 +0300, Alexander Shishkin wrote: This adds a sysfs file at /sys/power/coresight_save which is used to control if the ETM and debug components' states should be saved and restored across OFF modes. The non-omap patches are merged to Russell's tree, so these three are the only remaining. This one won't apply to linux-omap master any more because of the pm44xx in the makefile, but should be ok otherwise. It would still apply to linus' tree. So, should I rediff it, resend it or just drop it, because it's not needed? Regards, -- Alex -- 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] omap2: McBSP: Remove mux code for OMAP2420 McBSP2 and do cleanups
This 'legacy' OMAP2420 McBSP2 muxing code is currently broken after recent
conversion to new mux code. The omap_mcbsp_request calling this code is
usually called after booting whereas the omap_mux_init_signal is __init
marked so null pointer dereference would occur.
Fix this by removing the muxing code and let the bootloader or board file to
do it if necessary. Remove also omap2_mcbsp_ops as there is no use for it.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
arch/arm/mach-omap2/mcbsp.c | 39 ---
1 files changed, 0 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 87aa4c9..fa8da0a 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -23,29 +23,6 @@
#include plat/cpu.h
#include plat/mcbsp.h
-#include mux.h
-
-static void omap2_mcbsp2_mux_setup(void)
-{
- omap_mux_init_signal(eac_ac_sclk.mcbsp2_clkx, OMAP_PULL_ENA);
- omap_mux_init_signal(eac_ac_fs.mcbsp2_fsx, OMAP_PULL_ENA);
- omap_mux_init_signal(eac_ac_din.mcbsp2_dr, OMAP_PULL_ENA);
- omap_mux_init_signal(eac_ac_dout.mcbsp2_dx, OMAP_PULL_ENA);
- omap_mux_init_gpio(117, OMAP_PULL_ENA);
- /*
-* TODO: Need to add MUX settings for OMAP 2430 SDP
-*/
-}
-
-static void omap2_mcbsp_request(unsigned int id)
-{
- if (cpu_is_omap2420() (id == OMAP_MCBSP2))
- omap2_mcbsp2_mux_setup();
-}
-
-static struct omap_mcbsp_ops omap2_mcbsp_ops = {
- .request= omap2_mcbsp_request,
-};
#ifdef CONFIG_ARCH_OMAP2420
static struct omap_mcbsp_platform_data omap2420_mcbsp_pdata[] = {
@@ -55,7 +32,6 @@ static struct omap_mcbsp_platform_data omap2420_mcbsp_pdata[]
= {
.dma_tx_sync= OMAP24XX_DMA_MCBSP1_TX,
.rx_irq = INT_24XX_MCBSP1_IRQ_RX,
.tx_irq = INT_24XX_MCBSP1_IRQ_TX,
- .ops= omap2_mcbsp_ops,
},
{
.phys_base = OMAP24XX_MCBSP2_BASE,
@@ -63,7 +39,6 @@ static struct omap_mcbsp_platform_data omap2420_mcbsp_pdata[]
= {
.dma_tx_sync= OMAP24XX_DMA_MCBSP2_TX,
.rx_irq = INT_24XX_MCBSP2_IRQ_RX,
.tx_irq = INT_24XX_MCBSP2_IRQ_TX,
- .ops= omap2_mcbsp_ops,
},
};
#define OMAP2420_MCBSP_PDATA_SZARRAY_SIZE(omap2420_mcbsp_pdata)
@@ -82,7 +57,6 @@ static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[]
= {
.dma_tx_sync= OMAP24XX_DMA_MCBSP1_TX,
.rx_irq = INT_24XX_MCBSP1_IRQ_RX,
.tx_irq = INT_24XX_MCBSP1_IRQ_TX,
- .ops= omap2_mcbsp_ops,
},
{
.phys_base = OMAP24XX_MCBSP2_BASE,
@@ -90,7 +64,6 @@ static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[]
= {
.dma_tx_sync= OMAP24XX_DMA_MCBSP2_TX,
.rx_irq = INT_24XX_MCBSP2_IRQ_RX,
.tx_irq = INT_24XX_MCBSP2_IRQ_TX,
- .ops= omap2_mcbsp_ops,
},
{
.phys_base = OMAP2430_MCBSP3_BASE,
@@ -98,7 +71,6 @@ static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[]
= {
.dma_tx_sync= OMAP24XX_DMA_MCBSP3_TX,
.rx_irq = INT_24XX_MCBSP3_IRQ_RX,
.tx_irq = INT_24XX_MCBSP3_IRQ_TX,
- .ops= omap2_mcbsp_ops,
},
{
.phys_base = OMAP2430_MCBSP4_BASE,
@@ -106,7 +78,6 @@ static struct omap_mcbsp_platform_data
omap2430_mcbsp_pdata[] = {
.dma_tx_sync= OMAP24XX_DMA_MCBSP4_TX,
.rx_irq = INT_24XX_MCBSP4_IRQ_RX,
.tx_irq = INT_24XX_MCBSP4_IRQ_TX,
- .ops= omap2_mcbsp_ops,
},
{
.phys_base = OMAP2430_MCBSP5_BASE,
@@ -114,7 +85,6 @@ static struct omap_mcbsp_platform_data
omap2430_mcbsp_pdata[] = {
.dma_tx_sync= OMAP24XX_DMA_MCBSP5_TX,
.rx_irq = INT_24XX_MCBSP5_IRQ_RX,
.tx_irq = INT_24XX_MCBSP5_IRQ_TX,
- .ops= omap2_mcbsp_ops,
},
};
#define OMAP2430_MCBSP_PDATA_SZARRAY_SIZE(omap2430_mcbsp_pdata)
@@ -133,7 +103,6 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.dma_tx_sync= OMAP24XX_DMA_MCBSP1_TX,
.rx_irq = INT_24XX_MCBSP1_IRQ_RX,
.tx_irq = INT_24XX_MCBSP1_IRQ_TX,
- .ops= omap2_mcbsp_ops,
.buffer_size= 0x6F,
},
{
@@ -143,7 +112,6 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.dma_tx_sync= OMAP24XX_DMA_MCBSP2_TX,
.rx_irq = INT_24XX_MCBSP2_IRQ_RX,
Re: [PATCH 7/7] omap3: make coresight register save across OFF modes a sysfs option
* Alexander Shishkin virtu...@slind.org [100806 15:30]: On Sun, Jul 25, 2010 at 08:05:20 +0300, Alexander Shishkin wrote: This adds a sysfs file at /sys/power/coresight_save which is used to control if the ETM and debug components' states should be saved and restored across OFF modes. The non-omap patches are merged to Russell's tree, so these three are the only remaining. This one won't apply to linux-omap master any more because of the pm44xx in the makefile, but should be ok otherwise. It would still apply to linus' tree. So, should I rediff it, resend it or just drop it, because it's not needed? Patches look OK to me. Care to refresh and repost the remaining ones one more time to avoid confusion about which ones remain? Are you OK if we merge these in the next merge window after this? I'd rather have these sitting in linux-omap tree for a while first before we merge them so we can be sure they won't break the idle code.. Regards, Tony -- 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 updates for 2.6.36
Hi Linus, Please pull OMAP Display Subsystem patches from below. Mostly fixes and improvements to existing features. Tomi The following changes since commit 9fe6206f400646a2322096b56c59891d530e8d51: Linus Torvalds (1): Linux 2.6.35 are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git for-linus Afzal Mohammed (1): OMAP: DSS2: OMAPFB: Fix probe error path Archit Taneja (3): OMAP: DSS2: Remove extra return statement OMAP: DSS2: Fix error path in omap_dsi_update() OMAP: DSS2: Replace strncmp() with sysfs_streq() in overlay_manager_store() Grazvydas Ignotas (1): OMAP: DSS2: OMAPFB: add support for FBIO_WAITFORVSYNC Igor Grinberg (1): OMAP: DSS2: TDO35S: fix video signaling Jani Nikula (21): OMAP: DSS2: Taal: Add panel hardware reset OMAP: DSS2: Taal: Add locks to protect taal data access OMAP: DSS2: Taal: Remove platform enable/disable OMAP: DSS2: Taal: Fix request_irq() error handling OMAP: DSS2: Taal: Remove ESD work cancel from driver probe error handling OMAP: DSS2: Taal: Improve taal_power_on() error handling OMAP: DSS2: Taal: Ensure panel is enabled in enable_te() and run_test() OMAP: DSS2: Taal: Change DSI bus locking to avoid deadlock in ESD work OMAP: DSS2: Taal: Check taal_power_on() return value in taal_resume() OMAP: DSS2: Taal: Change ESD work management OMAP: DSS2: Taal: Change probe error handling labels OMAP: DSS2: Taal: Add proper external TE support OMAP: DSS2: Add Nokia DSI command mode panel configuration struct OMAP: DSS2: Taal: Configure ESD check in DSI panel data OMAP: DSS2: Taal: Add panel specific configuration structure OMAP: DSS2: Taal: Print panel name in addition to revision OMAP: DSS2: Taal: CABC workaround is Taal specific OMAP: DSS2: OMAPFB: Check fb2display() return value OMAP: DSS2: OMAPFB: Remove redundant rotate range check OMAP: DSS2: OMAPFB: Remove redundant color register range check OMAP: DSS2: OMAPFB: Fix sysfs mirror input check Maurus Cuelenaere (1): OMAP: DSS2: OMAPFB: Fix invalid bpp for PAL and NTSC modes Tobias Klauser (1): OMAP: DSS2: storage class should be before const qualifier Tomi Valkeinen (20): OMAP: DSS2: DSI: Increase HS TX timeout OMAP: DSS2: Fix update area calculations with multiple scaled overlays OMAP: DSS2: DSI: print errors in dsi_vc_flush_receive_data() OMAP: DSS2: DSI: use a private workqueue OMAP: DSS2: DSI: change dsi_vc_dcs_read_2 parameters OMAP: DSS2: DSI: handle error in synchronous write OMAP: DSS2: DSI: change DSI timeout functions OMAP: DSS2: Taal: add locks to taal_bl_update_status OMAP: DSS2: Taal: Use Nokia DSI panel data OMAP: DSS2: Taal: Add regulator configuration support OMAP: DSS2: DSI: Wait for DSI PLL clocks to be active before selecting them OMAP: DSS2: DSI: change dsi_vc_config_l4/vp() OMAP: DSS2: DSI: use BTA to end the frame transfer OMAP: DSS2: change manual update scaling setup OMAP: DSS2: DSI: Remove BTA after set_max_rx_packet_size OMAP: DSS2: DSI: Add error IRQ mask for DSI complexIO OMAP: DSS2: DSI: increase FIFO low threshold OMAP: DSS2: DSI: detect unsupported update requests OMAP: DSS2: Taal: Optimize enable_te, rotate, mirror when value unchanged OMAP: DSS2: adjust YUV overlay width to be even Vaibhav Hiremath (1): OMAP3EVM: Replace vdvi regulator supply with vdds_dsi Ville Syrjälä (14): OMAP: DSS2: Check if display supports update mode changes OMAP: DSS2: Make wait_for_go() succeed for disabled displays OMAP: DSS2: clear spurious SYNC_LOST_DIGIT interrupts OMAP: DSS2: OMAPFB: Refactor overlay address calculations OMAP: DSS2: OMAPFB: Check var even if there isn't memory OMAP: DSS2: OMAPFB: Skip unnecessary set_overlay_info() OMAP: DSS2: OMAPFB: Add support for switching memory regions OMAP: DSS2: OMAPFB: Add locking for memory regions OMAP: DSS2: OMAPFB: Convert the memory region locking to rwsem OMAP: DSS2: OMAPFB: Make lockdep happy OMAP: DSS2: OMAPFB: Add some locking debug checks OMAP: DSS2: DSI: Disable PCKFREE on error OMAP: DSS2: DSI: Print an error message if DSI clock calc fails OMAP: DSS2: DSI: Disable interface when disabling the display arch/arm/mach-omap2/board-omap3evm.c |7 +- arch/arm/plat-omap/include/plat/display.h |9 +- arch/arm/plat-omap/include/plat/nokia-dsi-panel.h | 31 ++ drivers/video/omap2/displays/panel-taal.c | 567 +++ .../video/omap2/displays/panel-toppoly-tdo35s.c|8 +- drivers/video/omap2/dss/dispc.c| 16 +- drivers/video/omap2/dss/display.c |4 +- drivers/video/omap2/dss/dsi.c | 463 -
Re: [PM-SR][PATCH 01/12] omap3: voltage: cleanup pr_xxxx
Mark Brown had written, on 08/06/2010 07:18 AM, the following: On Fri, Aug 06, 2010 at 06:08:03AM -0500, Nishanth Menon wrote: Well that is my motivation here. if driver reports a warning to kernel syslog, well, I expect the log to contain the function name for me to maintain faster. That's really not the expectation for Linux log messages - the general approach to find the source of a message is generally to just grep for the message text which is usually very effective. taking a small sample set of pr_xyz(); (pr which spans a single line): $ git grep pr_ drivers/|grep )|grep __func__|wc -l 589 $ git grep pr_ drivers/|grep )|grep -v __func__|wc -l 5373 $ git grep pr_fmt drivers/|wc -l 138 Reading Documentation/dynamic-debug-howto.txt, I see that you are in a one way right. I can get fine grained control over the log by enabling CONFIG_DYNAMIC_DEBUG. At the same time, I have wondered on the usage of pr_fmt() in many of the drivers. in a way, if i wanted to be that verbose in a driver, I could in theory do: #define pr_fmt(fmt) %s: fmt, __func__ and get the benefit throughout the file.. but overall, I still disagree that we dont need to have the function name in log is a speed booster for maintenance folks. a) when the strings are split up when they go multiple lines: E.g.: abcd efg print comes out abcd efg i) you do a git grep abcd efg will return nada ii) if you do a git grep of abcd, you will probably see half a dozen prints there, then open each file to see where the real message is, and you find the file searching a bit b) when there are couple more usage in cases of commonly used error message- (e.g. invalid parameters), you end up getting multiple hits, and you are left guessing where it came from in this example: lets see: (on l-o pm branch): git grep DEBUG option not enabled . arch/arm/mach-omap2/smartreflex.c: pr_notice(DEBUG option not enabled!\n \ arch/arm/mach-omap2/voltage.c: pr_notice(DEBUG option not enabled!\n \ now open up both the files to find exactly what you are looking for. c) time required: $ time git grep DEBUG option not enabled . arch/arm/mach-omap2/smartreflex.c: pr_notice(DEBUG option not enabled!\n \ arch/arm/mach-omap2/voltage.c: pr_notice(DEBUG option not enabled!\n \ real1m34.722s user0m0.440s sys 0m1.820s Vs cscope or ctags where it is rather instantaneous if you know the function name.. -- 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] omap: Fix omap_4430sdp_defconfig for make oldconfig
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, August 06, 2010 5:20 PM To: Nayak, Rajendra Cc: Kevin Hilman; linux-omap@vger.kernel.org Subject: [PATCH] omap: Fix omap_4430sdp_defconfig for make oldconfig * Nayak, Rajendra rna...@ti.com [100806 14:22]: Now with this, omap4 build using omap_4430sdp_defconfig seems to go through, but like you said, boot is still an issue. Hmm, I guess these issues pop up if you do yes | make oldconfig. Can you try the patch below? After applying the patch, you need to: $ rm .config $ cp arch/arm/configs/omap_4430sdp_defconfig .config $ yes | ARCH=arm make oldconfig Then omap2 and 3 won't get selected by make oldconfig. Yes, this seems to work. Regards, Tony -- 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-SR][PATCH 01/12] omap3: voltage: cleanup pr_xxxx
On Fri, Aug 06, 2010 at 08:10:44AM -0500, Nishanth Menon wrote: a) when the strings are split up when they go multiple lines: E.g.: abcd efg print comes out abcd efg That's generally considered bad practice for precisely this reason. c) time required: $ time git grep DEBUG option not enabled . arch/arm/mach-omap2/smartreflex.c: pr_notice(DEBUG option not enabled!\n \ arch/arm/mach-omap2/voltage.c: pr_notice(DEBUG option not enabled!\n \ real 1m34.722s user 0m0.440s sys 0m1.820s Vs cscope or ctags where it is rather instantaneous if you know the function name.. Interesting, I see better performance than that, especially hot cache, and of course an educated guess as to where to look helps greatly. -- 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-SR][PATCH 01/12] omap3: voltage: cleanup pr_xxxx
Mark Brown had written, on 08/06/2010 08:32 AM, the following: On Fri, Aug 06, 2010 at 08:10:44AM -0500, Nishanth Menon wrote: a) when the strings are split up when they go multiple lines: E.g.: abcd efg print comes out abcd efg That's generally considered bad practice for precisely this reason. I agree, but we dont normally have an cleaner option other than: a) reduce the size of the print message b) reduce the nesting to give us more space to print ;) but things get a little more worse now that I think of my personal experience, e.g.: pr_info(%s is not active\n, my_struct-name); if name is mpu, then you get a print of: mpu is not active, and a git grep does not match up either... c) time required: $ time git grep DEBUG option not enabled . arch/arm/mach-omap2/smartreflex.c: pr_notice(DEBUG option not enabled!\n \ arch/arm/mach-omap2/voltage.c: pr_notice(DEBUG option not enabled!\n \ real1m34.722s user0m0.440s sys 0m1.820s Vs cscope or ctags where it is rather instantaneous if you know the function name.. Interesting, I see better performance than that, especially hot cache, and of course an educated guess as to where to look helps greatly. tell me about it.. ;) mebbe I can use this thread to get a machine upgrade budget :P.. but I guess there are a lot more folks stuck like me.. just for curiosity sake, this data was on a dual core model name : Intel(R) Pentium(R) 4 CPU 3.40GHz bogomips: 6800.29 with a 7200RPM SATA 500GB drive :(.. -- 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: [PM-SR][PATCH 01/12] omap3: voltage: cleanup pr_xxxx
On Fri, Aug 06, 2010 at 08:37:52AM -0500, Nishanth Menon wrote: Interesting, I see better performance than that, especially hot cache, and of course an educated guess as to where to look helps greatly. tell me about it.. ;) mebbe I can use this thread to get a machine upgrade budget :P.. but I guess there are a lot more folks stuck like me.. just for curiosity sake, this data was on a dual core model name: Intel(R) Pentium(R) 4 CPU 3.40GHz bogomips : 6800.29 with a 7200RPM SATA 500GB drive :(.. That's actually better in most respects than the laptop I tried for comparison. -- 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
omap3camera and linux-omap
I am currently using Sakari's omap3camera repository (branch 'devel'). 'git merge-base linux-omap omap3camera' tells me that the last commit omap3camera has in common with linux-omap is 40a0c47, from July 7 2010. But there are 1000 commits which are only in omap3camera, dating back to 2008. Is this destined to stay this way? Or will the omap3camera tree be merged into linux-omap at some point? When proposing a patch for the omap3camera tree, should it be sent to this list? Thanks, Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich -- 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: Issues with calling pm_runtime functions in platform_pm_suspend_noirq/IRQ disabled context.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, August 05, 2010 5:05 AM
To: Basak, Partha
Cc: Paul Walmsley; linux-omap@vger.kernel.org; Kalliguddi, Hema; Raja,
Govindraj; Varadarajan, Charulatha; Nayak, Rajendra; Cousson, Benoit
Subject: Re: Issues with calling pm_runtime functions in
platform_pm_suspend_noirq/IRQ disabled context.
Basak, Partha p-bas...@ti.com writes:
Tested GPIO for Suspend with these changes obtained dump of Circular
Locking dependencies:
It would *really* help to have these GPIO conversion patches posted
against a public tree/branch one could see exactly what is going on and
be able to reproduce this problem for easier analysis. I have some
hunches as to what is going wrong here, but cannot be sure. I'd much
rather be able to see and try the code.
Fortunately, lockdep is verbose enough to try and understand the
symptoms here. Lockdep seems to have detected that these two locks have
been acquired in different order, resulting in *potential* deadlock.
Indeed, during init (#0 below) you have the hwmod_mutex acquired
(hwmod_for_each_by_class()) then the dpm_list_mtx acquired
(device_pm_add()). Later, during suspend the dpm_list_mtx is aquired
first (dpm_suspend_noirq()), then the omap_hwmod_mutex is acquired
(omap_hwmod_idle()).
Taking the same locks in different order at different times is the
circular dependency and a recipe for potential deadlock.
In our case, there is no real potential for deadlock here as the locks
are only taken the hwmod-dpm order once during init, all other times
(when the omap_device/hwmod are ready) it will happen in the dpm-hwmod
order.
The simple fix here is probably to remove the locking in the
omap_hwmod_for_each* functions. Could you try that?
We tried this, it works. But the GPIO patch series sent out(posted today, Aug
06 2010) are tested based on reverting the pm_bus.c suspend_no_irq patch.
I'm a bit confused why I don't see the same problem with the UART layer
which currently also handles things in the idle path as well.
Kevin
# echo mem /sys/power/state
[ 809.981658] PM: Syncing filesystems ... done.
[ 810.037963] Freezing user space processes ... (elapsed 0.02 seconds)
done.
[ 810.067901] Freezing remaining freezable tasks ... (elapsed 0.02
seconds) done.
[ 810.105224] Suspending console(s) (use no_console_suspend to debug)
[ 810.166748] PM: suspend of devices complete after 46.142 msecs
[ 810.170562]
[ 810.170593] ===
[ 810.170593] [ INFO: possible circular locking dependency detected ]
[ 810.170623] 2.6.35-rc5-00131-g56e767c-dirty #34
[ 810.170654] ---
[ 810.170654] sh/670 is trying to acquire lock:
[ 810.170684] (omap_hwmod_mutex){+.+.+.}, at: [c004fe84]
omap_hwmod_idle+0x1c/0x38
[ 810.170745]
[ 810.170745] but task is already holding lock:
[ 810.170776] (dpm_list_mtx){+.+...}, at: [c023baf8]
dpm_suspend_noirq+0x28/0x188
[ 810.170806]
[ 810.170837] which lock already depends on the new lock.
[ 810.170837]
[ 810.170837]
[ 810.170837] the existing dependency chain (in reverse order) is:
[ 810.170867]
[ 810.170867] - #1 (dpm_list_mtx){+.+...}:
[ 810.170898][c009bc3c] lock_acquire+0x60/0x74
[ 810.170959][c0437a9c] mutex_lock_nested+0x58/0x2e4
[ 810.170989][c023bcc0] device_pm_add+0x14/0xcc
[ 810.171020][c0235304] device_add+0x3b8/0x564
[ 810.171051][c0238834] platform_device_add+0x104/0x160
[ 810.171112][c005f2a8] omap_device_build_ss+0x14c/0x1c8
[ 810.171142][c005f36c] omap_device_build+0x48/0x50
[ 810.171173][c004d34c] omap2_init_gpio+0xf0/0x15c
[ 810.171203][c004f254]
omap_hwmod_for_each_by_class+0x60/0xa4
[ 810.171264][c0040340] do_one_initcall+0x58/0x1b4
[ 810.171295][c0008574] kernel_init+0x98/0x150
[ 810.171325][c0041968] kernel_thread_exit+0x0/0x8
[ 810.171356]
[ 810.171356] - #0 (omap_hwmod_mutex){+.+.+.}:
[ 810.171386][c009b4e4] __lock_acquire+0x108c/0x1784
[ 810.171447][c009bc3c] lock_acquire+0x60/0x74
[ 810.171478][c0437a9c] mutex_lock_nested+0x58/0x2e4
[ 810.171508][c004fe84] omap_hwmod_idle+0x1c/0x38
[ 810.171539][c005eb9c] omap_device_idle_hwmods+0x20/0x3c
[ 810.171600][c005ec88] _omap_device_deactivate+0x58/0x14c
[ 810.171630][c005ef50] omap_device_idle+0x4c/0x6c
[ 810.171661][c0053e7c] platform_pm_runtime_suspend+0x4c/0x74
[ 810.171691][c023c9f8] __pm_runtime_suspend+0x204/0x34c
[ 810.171722][c023cbe0] pm_runtime_suspend+0x20/0x34
[ 810.171752][c0053dbc] platform_pm_runtime_idle+0x8/0x10
[ 810.171783][c023c344] __pm_runtime_idle+0x15c/0x198
[ 810.171813]
RE: Issues with calling pm_runtime functions in platform_pm_suspend_noirq/IRQ disabled context.
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, August 05, 2010 4:51 AM To: Basak, Partha Cc: Paul Walmsley; linux-omap@vger.kernel.org; Kalliguddi, Hema; Raja, Govindraj; Varadarajan, Charulatha; Nayak, Rajendra; Cousson, Benoit Subject: Re: Issues with calling pm_runtime functions in platform_pm_suspend_noirq/IRQ disabled context. Kevin Hilman khil...@deeprootsystems.com writes: Kevin Hilman khil...@deeprootsystems.com writes: Basak, Partha p-bas...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, August 03, 2010 11:06 PM To: Basak, Partha Cc: Paul Walmsley; linux-omap@vger.kernel.org; Kalliguddi, Hema; Raja, Govindraj; Varadarajan, Charulatha; Nayak, Rajendra; Cousson, Benoit Subject: Re: Issues with calling pm_runtime functions in platform_pm_suspend_noirq/IRQ disabled context. Basak, Partha p-bas...@ti.com writes: Resending with the corrected mailing list Hello Kevin, I want to draw your attention to an issue the following patch introduces. http://dev.omapzoom.org/?p=swarch/linux-omap- adv.git;a=commitdiff;h=8041359e18e49bf8a3d41f15894db9e476f3a8fc [...] I believe, it is not correct to call the pm_runtime APIs from interrupt locked context since the underlying functions __pm_runtime_suspend __pm_runtime_resume enable interrupts and call schedule(). Further, from a s/w layering standpoint, platform-bus is a deeper layer than the Runtime layer, which the runtime layer calls into. So it may not be correct to have this layer calling into pm_runtime(). It should directly call omap_device APIs. The original version of this patch did directly call the omap_device APIs. However, Paul didn't like that approach and there were use-counting problems to handle as well (e.g. if a driver was not (yet) in use, it would already be disabled, and a suspend would trigger an omap_device_disable() which would fail since device was already disabled.) Paul and I agreed that this current approach would solve the use-counting problems, but you're correct in that it introduces new problems as these functions can _possibly_ sleep/schedule. That being said, have you actually seen problems here? I would like to see how they are triggered? Scenario 1: Consider the case where a driver has already called pm_runtime_put_sync as part of aggressive clock cutting scheme. Subsequently, when system suspend is called, pm_runtime_put_sync is called again. Due to atomic_dec_and_test check on usage_count, the second call goes through w/o error. I don't think you're fully understanding the point of the put/get in the suspend/resume path. The reason for the 'put' in the suspend path is because the PM core has done a 'get' in dpm_prepare() [c.f. drivers/base/power/main.c] so that runtime PM transitions are prevented during suspend/resume. On OMAP, we want to allow those transitions to happen so we can use the same runtime PM calls in the idle and suspend paths. At System resume, pm_runtime_get_sync is called twice, once by resume, once by the driver itself. Yes, but there is a 'put_sync' in between those done by the PM core during resume (c.f. dpm_complete() in drivers/base/power/main.c] Because of the extra reference count, the aggressive clock control by the driver is broken, as call to put_sync by a driver reduces to usage_count to 1. As a result clock transition in Idle-path is broken. A closer look here, and there is indeed a bug in the _resume_noirq() method. The get here needs to be a _noresume version to match what is done in the PM core. This doesn't change the use count, but it does change whether the device is actually awoken by this 'get' or not. This get should never actually awake the device. It is only there to compensate for what the PM core does. Can you try this patch? Will post a version to the list with changelog shortly. After a little more thinking, I'm not sure yet if this is a real problem or not. One other question. At least for GPIO testing, does it work if you simply remove the _noirq hooks from pm_bus.c? If so, please feel to post a version with the dependency that the patch adding suspend/resume hooks in pm_bus.c needs to be reverted first. We have reverted this patch and tested before submitting the modified GPIO series. Kevin Kevin diff --git a/arch/arm/mach-omap2/pm_bus.c b/arch/arm/mach-omap2/pm_bus.c index bab0186..01bbe65 100644 --- a/arch/arm/mach-omap2/pm_bus.c +++ b/arch/arm/mach-omap2/pm_bus.c @@ -90,7 +90,7 @@ int platform_pm_resume_noirq(struct device *dev) * method so that the runtime PM usage counting is in the same * state it was when suspend was called. */ - pm_runtime_get_sync(dev); +
Patches Xf86-video-omapfb
Hi I would like to have the patches of Eino-Ville Talvala on the Xf86-video-omapfb which fixes the problems using DSS2 on OMAP3 EVM / Angstrom with rotation. These fixes where made dec. 2009 Who can help me on this? Best regards, Henk -- 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: [RFC PATCH] platform: Faciliatate the creation of pseduo-platform busses
On Thu, Aug 05, 2010 at 04:59:35PM -0600, Grant Likely wrote: (On that point Greg, what is the reason for even having the /sys/devices/platform/ parent? Why not just let the platform devices sit at the root of the device tree? In the OF case (granted, I'm biased) all of the platform_device registrations reflect the actual device hierarchy expressed in the device tree data.) If we sat them at the root, there would be a bunch of them there. I don't know, we could drop the parent, I guess whoever created the platform device oh so long ago, decided that it would look nicer to be in this type of structure. Now, having gone on this whole long tirade, it looks like having separate platform bus types may not be the best approach after all. I totally agree, and thanks for the detailed explaination, it saved me from having to write up the same thing :) 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
RE: Issues with calling pm_runtime functions in platform_pm_suspend_noirq/IRQ disabled context.
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, August 05, 2010 3:17 AM To: Basak, Partha Cc: Paul Walmsley; linux-omap@vger.kernel.org; Kalliguddi, Hema; Raja, Govindraj; Varadarajan, Charulatha; Nayak, Rajendra; Cousson, Benoit Subject: Re: Issues with calling pm_runtime functions in platform_pm_suspend_noirq/IRQ disabled context. Basak, Partha p-bas...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, August 03, 2010 11:06 PM To: Basak, Partha Cc: Paul Walmsley; linux-omap@vger.kernel.org; Kalliguddi, Hema; Raja, Govindraj; Varadarajan, Charulatha; Nayak, Rajendra; Cousson, Benoit Subject: Re: Issues with calling pm_runtime functions in platform_pm_suspend_noirq/IRQ disabled context. Basak, Partha p-bas...@ti.com writes: Resending with the corrected mailing list Hello Kevin, I want to draw your attention to an issue the following patch introduces. http://dev.omapzoom.org/?p=swarch/linux-omap- adv.git;a=commitdiff;h=8041359e18e49bf8a3d41f15894db9e476f3a8fc [...] I believe, it is not correct to call the pm_runtime APIs from interrupt locked context since the underlying functions __pm_runtime_suspend __pm_runtime_resume enable interrupts and call schedule(). Further, from a s/w layering standpoint, platform-bus is a deeper layer than the Runtime layer, which the runtime layer calls into. So it may not be correct to have this layer calling into pm_runtime(). It should directly call omap_device APIs. The original version of this patch did directly call the omap_device APIs. However, Paul didn't like that approach and there were use-counting problems to handle as well (e.g. if a driver was not (yet) in use, it would already be disabled, and a suspend would trigger an omap_device_disable() which would fail since device was already disabled.) Paul and I agreed that this current approach would solve the use-counting problems, but you're correct in that it introduces new problems as these functions can _possibly_ sleep/schedule. That being said, have you actually seen problems here? I would like to see how they are triggered? Scenario 1: Consider the case where a driver has already called pm_runtime_put_sync as part of aggressive clock cutting scheme. Subsequently, when system suspend is called, pm_runtime_put_sync is called again. Due to atomic_dec_and_test check on usage_count, the second call goes through w/o error. I don't think you're fully understanding the point of the put/get in the suspend/resume path. The reason for the 'put' in the suspend path is because the PM core has done a 'get' in dpm_prepare() [c.f. drivers/base/power/main.c] so that runtime PM transitions are prevented during suspend/resume. On OMAP, we want to allow those transitions to happen so we can use the same runtime PM calls in the idle and suspend paths. At System resume, pm_runtime_get_sync is called twice, once by resume, once by the driver itself. Yes, but there is a 'put_sync' in between those done by the PM core during resume (c.f. dpm_complete() in drivers/base/power/main.c] Because of the extra reference count, the aggressive clock control by the driver is broken, as call to put_sync by a driver reduces to usage_count to 1. As a result clock transition in Idle-path is broken. I understand the rationale better, but having these changes is making the next Idle call after a suspend-resume cycle to fail. I will continue debugging on this and come back with more details. Scenario2: Tested GPIO for Suspend with these changes obtained dump of Circular Locking dependencies: I don't think these to problems are related, AFAICT, they are separate issues. I'll respond to this scenario in a different reply. [...] The UART driver is a special case as it is managed from deep inside the idle path. Can you feedback on my observations and comment on the approach taken for these drivers? I cannot comment until I understand why these drivers need to enable/disable with interrupts off. In general, any use of the interrupts-off versions of the omap_device APIs need to be thorougly justified. Even the UART one will go away when the omap-serial driver is converted to runtime PM. For GPIO, it is a must to relinquish clocks in Idle-path as it is possible to have a GPIO bank requested and still allow PER domain to go to OFF. These the kind of things that I would expect to be discussed/described in the changelogs to patches posted to the list. For USB, this is required because of a h/w issue. Again, patches with descriptive changelogs describing the h/w issue please. My point is, just by exposing a _omap_hwmod_idle()(mutex-free version) will not let us call pm_runtime APIs in Idle path
Re: [PATCH v2 03/20] mmc: support embedded data field in mmc_host
On Fri, Aug 06, 2010 at 01:02:24PM +0300, Ohad Ben-Cohen wrote:
We have Russell's suggestion which is nice and simple, but it has the
1 device limitation.
You could make it generic by doing something like this:
#define set_device_data(name, type, index, data)\
({ \
extern void __set_device_data(const char *, int, void *, size_t); \
BUILD_BUG_ON(!__same_type(type, *data));\
__set_device_data(name : #type, index, data, sizeof(type)); \
})
#define get_device_data(name, type, index) ({ \
extern void *__get_device_data(const char *, int);\
type *__ptr = __get_device_data(name : #type, index); \
__ptr; })
And now we have something that takes a string and index to use as a lookup
key in some kind of list - and it's typesafe (because the lookup key is
dependent on the stringified type.)
But... at this point I feel that we're getting too complicated, and will
get shouted at to use something like DT which already solves this problem.
--
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: [RFC PATCH] platform: Faciliatate the creation of pseduo-platform busses
On Fri, Aug 6, 2010 at 8:27 AM, Greg KH gre...@suse.de wrote: On Thu, Aug 05, 2010 at 04:59:35PM -0600, Grant Likely wrote: (On that point Greg, what is the reason for even having the /sys/devices/platform/ parent? Why not just let the platform devices sit at the root of the device tree? In the OF case (granted, I'm biased) all of the platform_device registrations reflect the actual device hierarchy expressed in the device tree data.) If we sat them at the root, there would be a bunch of them there. I don't know, we could drop the parent, I guess whoever created the platform device oh so long ago, decided that it would look nicer to be in this type of structure. Personally I'd rather see a meaningful structure used here. Maybe having them all in the root will encourage people to find realistic parents for their platform devices. :-) Why don't I float a patch to remove this and see if anybody freaks out. Should I wrap it with a CONFIG_ so that it can be configurable for a release or to, or just make it unconditional? Now, having gone on this whole long tirade, it looks like having separate platform bus types may not be the best approach after all. I totally agree, and thanks for the detailed explaination, it saved me from having to write up the same thing :) :-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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: omap3camera and linux-omap
Hi Michael, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Michael Jones Sent: Friday, August 06, 2010 8:48 AM To: linux-omap@vger.kernel.org Cc: sakari.ai...@maxwell.research.nokia.com Subject: omap3camera and linux-omap I am currently using Sakari's omap3camera repository (branch 'devel'). 'git merge-base linux-omap omap3camera' tells me that the last commit omap3camera has in common with linux-omap is 40a0c47, from July 7 2010. But there are 1000 commits which are only in omap3camera, dating back to 2008. Is this destined to stay this way? This is because devel branch keeps a detailed development history since we started working on the camera driver. At the end, the patches submitted will be a consolidated set, which should end in something around ~12 patches or so.. Or will the omap3camera tree be merged into linux-omap at some point? The omap3camera submission is on hold, because the camera driver is dependant on Media controller framework, which is holding for merge in linux-media mailing list. When proposing a patch for the omap3camera tree, should it be sent to this list? You should preferably send the patches to linux-media (at) vger.kernel.org mailing with cc to Sakari Ailus and Laurent Pinchart. So far we have been keeping patch review internally, because we didn't want to pollute the mailing list with patches to unsubmitted code. Regards, Sergio Thanks, Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans- Joachim Reich -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8]usb: musb:USB driver changes to use hwmod+ omap-device apis
From: Hema HK hem...@ti.com Series of patches to port musb driver to use hwmod and runtime pm APIs for OMAP4 and OMAP3.These patches are tested on OMAP4430SDP and OMAP3630-ZOOM3 boards. The patch 1 and 2 are are the prerequisites for the hwmod changes. Patch 6 is the OMAP3 offmode support patch. This patch series is generated on origin/pm-wip/hwmods-omap4. Offmode is tested with origin/pm on omap3630 zoom3 board. Signed-off-by: Hema HK hem...@ti.com Cc: Felipe Balbi felipe.ba...@nokia.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@deeprootsystems.com --- -- 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/8] usb: musb: Adding names for IRQs in resource structure
From: Hema HK hem...@ti.com
Modified the Omap,Blackfin and Davinci board files to add the name of the IRQs
in the resource structures and musb driver to use the get_irq_byname() api to
get the mc and dma irq numbers instead of using the index as the order of
resource definition need not be always in order of device interrupt and
then dma interrupt
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
Based off omap4-next branch.
arch/arm/mach-davinci/usb.c|2 ++
arch/arm/mach-omap2/usb-musb.c |2 ++
arch/blackfin/mach-bf527/boards/cm_bf527.c |2 ++
arch/blackfin/mach-bf527/boards/ezbrd.c|2 ++
arch/blackfin/mach-bf527/boards/ezkit.c|2 ++
arch/blackfin/mach-bf548/boards/cm_bf548.c |2 ++
arch/blackfin/mach-bf548/boards/ezkit.c|2 ++
drivers/usb/musb/cppi_dma.c|2 +-
drivers/usb/musb/musb_core.c |2 +-
drivers/usb/musb/musbhsdma.c |2 +-
10 files changed, 17 insertions(+), 3 deletions(-)
Index: linux-omap-pm/arch/arm/mach-davinci/usb.c
===
--- linux-omap-pm.orig/arch/arm/mach-davinci/usb.c 2010-08-06
09:01:23.605862579 -0400
+++ linux-omap-pm/arch/arm/mach-davinci/usb.c 2010-08-06 09:01:25.526112352
-0400
@@ -64,10 +64,12 @@
{
.start = IRQ_USBINT,
.flags = IORESOURCE_IRQ,
+ .name = mc
},
{
/* placeholder for the dedicated CPPI IRQ */
.flags = IORESOURCE_IRQ,
+ .name = dma
},
};
Index: linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/usb-musb.c 2010-08-06
09:01:23.613862415 -0400
+++ linux-omap-pm/arch/arm/mach-omap2/usb-musb.c2010-08-06
09:01:25.526112352 -0400
@@ -39,10 +39,12 @@
[1] = { /* general IRQ */
.start = INT_243X_HS_USB_MC,
.flags = IORESOURCE_IRQ,
+ .name = mc,
},
[2] = { /* DMA IRQ */
.start = INT_243X_HS_USB_DMA,
.flags = IORESOURCE_IRQ,
+ .name = dma,
},
};
Index: linux-omap-pm/arch/blackfin/mach-bf527/boards/cm_bf527.c
===
--- linux-omap-pm.orig/arch/blackfin/mach-bf527/boards/cm_bf527.c
2010-08-06 09:01:23.645862783 -0400
+++ linux-omap-pm/arch/blackfin/mach-bf527/boards/cm_bf527.c2010-08-06
09:01:25.526112352 -0400
@@ -82,11 +82,13 @@
.start = IRQ_USB_INT0,
.end= IRQ_USB_INT0,
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL,
+ .name = mc
},
[2] = { /* DMA IRQ */
.start = IRQ_USB_DMA,
.end= IRQ_USB_DMA,
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL,
+ .name = dma
},
};
Index: linux-omap-pm/arch/blackfin/mach-bf527/boards/ezbrd.c
===
--- linux-omap-pm.orig/arch/blackfin/mach-bf527/boards/ezbrd.c 2010-08-06
09:01:23.637862922 -0400
+++ linux-omap-pm/arch/blackfin/mach-bf527/boards/ezbrd.c 2010-08-06
09:01:25.526112352 -0400
@@ -46,11 +46,13 @@
.start = IRQ_USB_INT0,
.end= IRQ_USB_INT0,
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL,
+ .name = mc
},
[2] = { /* DMA IRQ */
.start = IRQ_USB_DMA,
.end= IRQ_USB_DMA,
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL,
+ .name = dma
},
};
Index: linux-omap-pm/arch/blackfin/mach-bf527/boards/ezkit.c
===
--- linux-omap-pm.orig/arch/blackfin/mach-bf527/boards/ezkit.c 2010-08-06
09:01:23.653862977 -0400
+++ linux-omap-pm/arch/blackfin/mach-bf527/boards/ezkit.c 2010-08-06
09:01:25.526112352 -0400
@@ -86,11 +86,13 @@
.start = IRQ_USB_INT0,
.end= IRQ_USB_INT0,
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL,
+ .name = mc
},
[2] = { /* DMA IRQ */
.start = IRQ_USB_DMA,
.end= IRQ_USB_DMA,
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL,
+ .name = dma
},
};
Index: linux-omap-pm/arch/blackfin/mach-bf548/boards/cm_bf548.c
===
--- linux-omap-pm.orig/arch/blackfin/mach-bf548/boards/cm_bf548.c
2010-08-06 09:01:23.625864028 -0400
+++
[PATCH 2/8] usb: musb: Remove board_data parameter from musb_platform_init()
From: Hema HK hem...@ti.com
Removed the board_data parameter being passed to musb_platform_init function
as board data can be extracted from device structure which is already member of
musb structure.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
drivers/usb/musb/blackfin.c |2 +-
drivers/usb/musb/davinci.c |2 +-
drivers/usb/musb/musb_core.c |2 +-
drivers/usb/musb/musb_core.h |2 +-
drivers/usb/musb/omap2430.c |6 --
drivers/usb/musb/tusb6010.c |2 +-
6 files changed, 9 insertions(+), 7 deletions(-)
Index: linux-omap-pm/drivers/usb/musb/blackfin.c
===
--- linux-omap-pm.orig/drivers/usb/musb/blackfin.c 2010-08-06
09:01:19.805863959 -0400
+++ linux-omap-pm/drivers/usb/musb/blackfin.c 2010-08-06 09:01:30.721863471
-0400
@@ -323,7 +323,7 @@
return -EIO;
}
-int __init musb_platform_init(struct musb *musb, void *board_data)
+int __init musb_platform_init(struct musb *musb)
{
/*
Index: linux-omap-pm/drivers/usb/musb/davinci.c
===
--- linux-omap-pm.orig/drivers/usb/musb/davinci.c 2010-08-06
09:01:19.821862599 -0400
+++ linux-omap-pm/drivers/usb/musb/davinci.c2010-08-06 09:01:30.721863471
-0400
@@ -376,7 +376,7 @@
return -EIO;
}
-int __init musb_platform_init(struct musb *musb, void *board_data)
+int __init musb_platform_init(struct musb *musb)
{
void __iomem*tibase = musb-ctrl_base;
u32 revision;
Index: linux-omap-pm/drivers/usb/musb/musb_core.c
===
--- linux-omap-pm.orig/drivers/usb/musb/musb_core.c 2010-08-06
09:01:25.530112841 -0400
+++ linux-omap-pm/drivers/usb/musb/musb_core.c 2010-08-06 09:01:30.721863471
-0400
@@ -2023,7 +2023,7 @@
* isp1504, non-OTG, etc) mostly hooking up through ULPI.
*/
musb-isr = generic_interrupt;
- status = musb_platform_init(musb, plat-board_data);
+ status = musb_platform_init(musb);
if (status 0)
goto fail2;
Index: linux-omap-pm/drivers/usb/musb/musb_core.h
===
--- linux-omap-pm.orig/drivers/usb/musb/musb_core.h 2010-08-06
09:01:19.785863497 -0400
+++ linux-omap-pm/drivers/usb/musb/musb_core.h 2010-08-06 09:01:30.721863471
-0400
@@ -612,7 +612,7 @@
#define musb_platform_get_vbus_status(x) 0
#endif
-extern int __init musb_platform_init(struct musb *musb, void *board_data);
+extern int __init musb_platform_init(struct musb *musb);
extern int musb_platform_exit(struct musb *musb);
#endif /* __MUSB_CORE_H__ */
Index: linux-omap-pm/drivers/usb/musb/omap2430.c
===
--- linux-omap-pm.orig/drivers/usb/musb/omap2430.c 2010-08-06
09:01:19.793863369 -0400
+++ linux-omap-pm/drivers/usb/musb/omap2430.c 2010-08-06 09:01:30.721863471
-0400
@@ -189,10 +189,12 @@
return 0;
}
-int __init musb_platform_init(struct musb *musb, void *board_data)
+int __init musb_platform_init(struct musb *musb)
{
u32 l;
- struct omap_musb_board_data *data = board_data;
+ struct device *dev = musb-controller;
+ struct musb_hdrc_platform_data *plat = dev-platform_data;
+ struct omap_musb_board_data *data = plat-board_data;
#if defined(CONFIG_ARCH_OMAP2430)
omap_cfg_reg(AE5_2430_USB0HS_STP);
Index: linux-omap-pm/drivers/usb/musb/tusb6010.c
===
--- linux-omap-pm.orig/drivers/usb/musb/tusb6010.c 2010-08-06
09:01:19.813862848 -0400
+++ linux-omap-pm/drivers/usb/musb/tusb6010.c 2010-08-06 09:01:30.721863471
-0400
@@ -1091,7 +1091,7 @@
return -ENODEV;
}
-int __init musb_platform_init(struct musb *musb, void *board_data)
+int __init musb_platform_init(struct musb *musb)
{
struct platform_device *pdev;
struct resource *mem;
--
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/4]usb: musb: HWMOD database structures addition for OMAP3
From: Hema HK hem...@ti.com
OMAP3 hwmod data stuctures are populated with base address, L3 and L4
interface clocks, IRQs,and sysconfig register details.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
[Review commets incorporated]
Index: linux-omap-pm/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
2010-08-06 08:31:45.0 -0400
+++ linux-omap-pm/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c2010-08-06
08:34:24.761878220 -0400
@@ -82,6 +82,16 @@
};
static struct omap_hwmod omap3xxx_l4_wkup_hwmod;
+static struct omap_hwmod omap3xxx_usbhsotg_hwmod;
+
+/* L3 - USBHSOTG interface */
+static struct omap_hwmod_ocp_if omap3xxx_usbhsotg__l3 = {
+ .master = omap3xxx_usbhsotg_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
/* L4_CORE - L4_WKUP interface */
static struct omap_hwmod_ocp_if omap3xxx_l4_core__l4_wkup = {
@@ -90,6 +100,38 @@
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/*
+* USBHSOTG interface data
+*/
+
+static struct omap_hwmod_addr_space omap3xxx_usbhsotg_addrs[] = {
+ {
+ .pa_start = OMAP34XX_HSUSB_OTG_BASE,
+ .pa_end = OMAP34XX_HSUSB_OTG_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* USBHSOTG - L4_CORE interface */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__usbhsotg = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_usbhsotg_hwmod,
+ .clk= l4_ick,
+ .addr = omap3xxx_usbhsotg_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_usbhsotg_addrs),
+ .user = OCP_USER_MPU,
+
+};
+
+static struct omap_hwmod_ocp_if *omap3xxx_usbhsotg_masters[] = {
+ omap3xxx_usbhsotg__l3,
+};
+
+static struct omap_hwmod_ocp_if *omap3xxx_usbhsotg_slaves[] = {
+ omap3xxx_l4_core__usbhsotg,
+};
+
+
/* Slave interfaces on the L4_CORE interconnect */
static struct omap_hwmod_ocp_if *omap3xxx_l4_core_slaves[] = {
omap3xxx_l3_main__l4_core,
@@ -197,6 +239,56 @@
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
};
+/*
+ * USBHSOTG (USBHS)
+ */
+static struct omap_hwmod_class_sysconfig omap3xxx_usbhsotg_sysc = {
+ .rev_offs = 0x0400,
+ .sysc_offs = 0x0404,
+ .syss_offs = 0x0408,
+ .sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE|
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE,
+ .idlemodes = SIDLE_FORCE | SIDLE_NO | SIDLE_SMART,
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class usbotg_class = {
+ .name = usbotg,
+ .sysc = omap3xxx_usbhsotg_sysc,
+};
+
+/* usb_otg_hs */
+static struct omap_hwmod_irq_info omap3xxx_usbhsotg_mpu_irqs[] = {
+
+ { .name = mc, .irq = 92 },
+ { .name = dma, .irq = 93 },
+
+};
+
+static struct omap_hwmod omap3xxx_usbhsotg_hwmod = {
+ .name = usb_otg_hs,
+ .mpu_irqs = omap3xxx_usbhsotg_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_usbhsotg_mpu_irqs),
+ .main_clk = hsotgusb_ick,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP3430_GRPSEL_HSOTGUSB_MASK,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP3430ES2_ST_HSOTGUSB_IDLE_SHIFT,
+ .idlest_stdby_bit = OMAP3430ES2_ST_HSOTGUSB_STDBY_SHIFT
+ },
+ },
+ .masters= omap3xxx_usbhsotg_masters,
+ .masters_cnt= ARRAY_SIZE(omap3xxx_usbhsotg_masters),
+ .slaves = omap3xxx_usbhsotg_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_usbhsotg_slaves),
+ .class = usbotg_class,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+};
+
static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l3_main_hwmod,
omap3xxx_l4_core_hwmod,
@@ -204,6 +296,7 @@
omap3xxx_l4_wkup_hwmod,
omap3xxx_mpu_hwmod,
omap3xxx_iva_hwmod,
+ omap3xxx_usbhsotg_hwmod,
NULL,
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8]usb: musb: HWMOD database structures fixes OMAP4
From: Hema HK hem...@ti.com
Fixed the missing sysc settings for OMAP4 and enabled the OMAP4
hwmod data structure.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
Index: linux-omap-pm/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
2010-08-06 08:31:45.885868560 -0400
+++ linux-omap-pm/arch/arm/mach-omap2/omap_hwmod_44xx_data.c2010-08-06
08:35:41.250112281 -0400
@@ -4516,8 +4516,15 @@
*/
static struct omap_hwmod_class_sysconfig omap44xx_usb_otg_hs_sysc = {
- .sysc_flags = SYSS_MISSING,
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+
+ .rev_offs = 0x0400,
+ .sysc_offs = 0x0404,
+ .syss_offs = 0x0408,
+ .sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE|
+ SYSC_HAS_ENAWAKEUP | 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_usb_otg_hs_hwmod_class = {
@@ -4884,7 +4891,7 @@
/* usb_host_hs class */
/* omap44xx_usb_host_hs_hwmod, */
/* usb_otg_hs class */
-/* omap44xx_usb_otg_hs_hwmod, */
+ omap44xx_usb_otg_hs_hwmod,
/* usb_tll_hs class */
/* omap44xx_usb_tll_hs_hwmod, */
/* wd_timer class */
--
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/8]usb : musb:Using omap_device_build for musb device registration
From: Hema HK hem...@ti.com
Using omap_device_build api instead of platform_device_register for musb
device registration.The device specific resources defined in centralized
database will be used. So removed the resource definitions from the musb
platform file.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/usb-musb.c | 100 +
1 file changed, 53 insertions(+), 47 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/usb-musb.c 2010-08-06
09:01:25.526112352 -0400
+++ linux-omap-pm/arch/arm/mach-omap2/usb-musb.c2010-08-06
09:01:43.786112839 -0400
@@ -29,24 +29,12 @@
#include mach/hardware.h
#include mach/irqs.h
#include plat/usb.h
+#include plat/omap_device.h
#ifdef CONFIG_USB_MUSB_SOC
-static struct resource musb_resources[] = {
- [0] = { /* start and end set dynamically */
- .flags = IORESOURCE_MEM,
- },
- [1] = { /* general IRQ */
- .start = INT_243X_HS_USB_MC,
- .flags = IORESOURCE_IRQ,
- .name = mc,
- },
- [2] = { /* DMA IRQ */
- .start = INT_243X_HS_USB_DMA,
- .flags = IORESOURCE_IRQ,
- .name = dma,
- },
-};
+static const char name[] = musb_hdrc;
+#define MAX_OMAP_MUSB_HWMOD_NAME_LEN 16
static struct musb_hdrc_config musb_config = {
.multipoint = 1,
@@ -75,43 +63,61 @@
static u64 musb_dmamask = DMA_BIT_MASK(32);
-static struct platform_device musb_device = {
- .name = musb_hdrc,
- .id = -1,
- .dev = {
- .dma_mask = musb_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = musb_plat,
- },
- .num_resources = ARRAY_SIZE(musb_resources),
- .resource = musb_resources,
+static struct omap_device_pm_latency omap_musb_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
};
void __init usb_musb_init(struct omap_musb_board_data *board_data)
{
- if (cpu_is_omap243x()) {
- musb_resources[0].start = OMAP243X_HS_BASE;
- } else if (cpu_is_omap34xx()) {
- musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
- } else if (cpu_is_omap44xx()) {
- musb_resources[0].start = OMAP44XX_HSUSB_OTG_BASE;
- musb_resources[1].start = OMAP44XX_IRQ_HS_USB_MC_N;
- musb_resources[2].start = OMAP44XX_IRQ_HS_USB_DMA_N;
+ char oh_name[MAX_OMAP_MUSB_HWMOD_NAME_LEN];
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ struct platform_device *pdev;
+ struct device *dev;
+ int l, bus_id = -1;
+ struct musb_hdrc_platform_data *pdata;
+
+ l = snprintf(oh_name, MAX_OMAP_MUSB_HWMOD_NAME_LEN,
+ usb_otg_hs);
+ WARN(l = MAX_OMAP_MUSB_HWMOD_NAME_LEN,
+ String buffer overflow in MUSB device setup\n);
+
+ oh = omap_hwmod_lookup(oh_name);
+
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ } else {
+ /*
+* REVISIT: This line can be removed once all the platforms
+* using musb_core.c have been converted to use use clkdev.
+*/
+ musb_plat.clock = ick;
+ musb_plat.board_data = board_data;
+ musb_plat.power = board_data-power 1;
+ musb_plat.mode = board_data-mode;
+ pdata = musb_plat;
+
+ od = omap_device_build(name, bus_id, oh, pdata,
+ sizeof(struct musb_hdrc_platform_data),
+ omap_musb_latency,
+ ARRAY_SIZE(omap_musb_latency), false);
+ if (IS_ERR(od)) {
+ pr_err(Could not build omap_device for %s %s\n,
+ name, oh_name);
+ } else {
+
+ pdev = od-pdev;
+ dev = pdev-dev;
+ get_device(dev);
+ dev-dma_mask = musb_dmamask;
+ dev-coherent_dma_mask = musb_dmamask;
+ put_device(dev);
+ }
}
- musb_resources[0].end = musb_resources[0].start + SZ_4K - 1;
-
- /*
-* REVISIT: This line can be removed once all the platforms using
-* musb_core.c have been converted to use use clkdev.
Re: [PATCH v2 03/20] mmc: support embedded data field in mmc_host
On Fri, 6 Aug 2010, Russell King - ARM Linux wrote:
On Fri, Aug 06, 2010 at 01:02:24PM +0300, Ohad Ben-Cohen wrote:
We have Russell's suggestion which is nice and simple, but it has the
1 device limitation.
You could make it generic by doing something like this:
#define set_device_data(name, type, index, data) \
({ \
extern void __set_device_data(const char *, int, void *, size_t); \
BUILD_BUG_ON(!__same_type(type, *data)); \
__set_device_data(name : #type, index, data, sizeof(type)); \
})
#define get_device_data(name, type, index) ({ \
extern void *__get_device_data(const char *, int); \
type *__ptr = __get_device_data(name : #type, index); \
__ptr; })
And now we have something that takes a string and index to use as a lookup
key in some kind of list - and it's typesafe (because the lookup key is
dependent on the stringified type.)
But... at this point I feel that we're getting too complicated, and will
get shouted at to use something like DT which already solves this problem.
DT is not generally available yet. A simple interim solution would
still be worth it.
Nicolas
--
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/8] usb: musb: Offmode fix for idle path
From: Hema HK hem...@ti.com
With OMAP core-off support musb was not functional as context was getting
lost after wakeup from core-off. And also musb was blocking the core-off
after loading the gadget driver even with no cable connected sometimes.
Added the conext save/restore api in the platform layer which will
be called in the idle and wakeup path.
Changed the usb sysconfig settings as per the usbotg functional spec.
When the device is not active, configure to force idle and force standby mode.
When it is being used, configure in smart standby and smart idle mode.
So while attempting to coreoff the usb is configured to force standby and
force idle mode, after wakeup configured in smart idle and smart standby.
Signed-off-by: Hema HK hem...@ti.com
Signed-off-by: Maulik Mankad x0082...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm34xx.c |4 ++
arch/arm/mach-omap2/usb-musb.c| 21 ++
arch/arm/plat-omap/include/plat/usb.h |2 +
drivers/usb/musb/musb_core.c | 11 ---
drivers/usb/musb/omap2430.c | 48 +++---
5 files changed, 71 insertions(+), 15 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/pm34xx.c 2010-08-06
09:23:01.153862710 -0400
+++ linux-omap-pm/arch/arm/mach-omap2/pm34xx.c 2010-08-06 10:44:06.393863125
-0400
@@ -39,6 +39,7 @@
#include plat/gpmc.h
#include plat/dma.h
#include plat/dmtimer.h
+#include plat/usb.h
#include asm/tlbflush.h
@@ -416,6 +417,8 @@
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_prcm_save_context();
+ /* Save MUSB context */
+ musb_context_save_restore(1);
}
}
@@ -458,6 +461,8 @@
omap3_prcm_restore_context();
omap3_sram_restore_context();
omap2_sms_restore_context();
+ /* restore MUSB context */
+ musb_context_save_restore(0);
}
omap_uart_resume_idle(0);
omap_uart_resume_idle(1);
Index: linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/usb-musb.c 2010-08-06
09:24:23.690112596 -0400
+++ linux-omap-pm/arch/arm/mach-omap2/usb-musb.c2010-08-06
10:44:06.385862697 -0400
@@ -120,6 +120,27 @@
}
}
+void musb_context_save_restore(int save)
+{
+ struct omap_hwmod *oh = omap_hwmod_lookup(usb_otg_hs);
+ struct omap_device *od = oh-od;
+ struct platform_device *pdev = od-pdev;
+ struct device *dev = pdev-dev;
+ struct device_driver *drv = dev-driver;
+
+ if (drv) {
+ struct musb_hdrc_platform_data *pdata = dev-platform_data;
+ const struct dev_pm_ops *pm = drv-pm;
+ if (!pdata-is_usb_active(dev)) {
+
+ if (save)
+ pm-suspend(dev);
+ else
+ pm-resume_noirq(dev);
+ }
+ }
+}
+
#else
void __init usb_musb_init(struct omap_musb_board_data *board_data)
{
Index: linux-omap-pm/arch/arm/plat-omap/include/plat/usb.h
===
--- linux-omap-pm.orig/arch/arm/plat-omap/include/plat/usb.h2010-08-06
09:23:01.137862514 -0400
+++ linux-omap-pm/arch/arm/plat-omap/include/plat/usb.h 2010-08-06
10:44:06.381864367 -0400
@@ -79,6 +79,8 @@
extern void usb_ohci_init(const struct ohci_hcd_omap_platform_data *pdata);
+/* For saving and restoring the musb context during off/wakeup*/
+extern void musb_context_save_restore(int save);
#endif
Index: linux-omap-pm/drivers/usb/musb/musb_core.c
===
--- linux-omap-pm.orig/drivers/usb/musb/musb_core.c 2010-08-06
09:24:21.069863329 -0400
+++ linux-omap-pm/drivers/usb/musb/musb_core.c 2010-08-06 10:44:06.369863527
-0400
@@ -2427,11 +2427,6 @@
}
musb_save_context(musb);
-
- if (musb-set_clock)
- musb-set_clock(musb-clock, 0);
- else
- clk_disable(musb-clock);
spin_unlock_irqrestore(musb-lock, flags);
return 0;
}
@@ -2443,12 +2438,6 @@
if (!musb-clock)
return 0;
-
- if (musb-set_clock)
- musb-set_clock(musb-clock, 1);
- else
- clk_enable(musb-clock);
-
musb_restore_context(musb);
/* for static cmos like DaVinci, register values were preserved
Index: linux-omap-pm/drivers/usb/musb/omap2430.c
[PATCH 7/8] : Hwmod api changes
From: Hema HK hem...@ti.com
Omap USBOTG modules has a requirement to set the auto idle bit only after
setting smart idle bit. Modified the _sys_enable api to set the smart idle
first and then the autoidle bit. Setting this will not have any impact on the
other modules.
Added 2 wrapper APIs in the omap device layer for wakeup enable/disable
and sidle/mstandby settings.
Signed-off-by: Hema HK hem...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c | 18 +++
arch/arm/plat-omap/include/plat/omap_device.h |2 +
arch/arm/plat-omap/omap_device.c | 42 ++
3 files changed, 56 insertions(+), 6 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/omap_hwmod.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/omap_hwmod.c 2010-08-06
08:59:03.641863815 -0400
+++ linux-omap-pm/arch/arm/mach-omap2/omap_hwmod.c 2010-08-06
09:02:00.021864999 -0400
@@ -653,12 +653,6 @@
_set_master_standbymode(oh, idlemode, v);
}
- if (sf SYSC_HAS_AUTOIDLE) {
- idlemode = (oh-flags HWMOD_NO_OCP_AUTOIDLE) ?
- 0 : 1;
- _set_module_autoidle(oh, idlemode, v);
- }
-
/* XXX OCP ENAWAKEUP bit? */
/*
@@ -671,6 +665,18 @@
_set_clockactivity(oh, oh-class-sysc-clockact, v);
_write_sysconfig(v, oh);
+
+ /* Set the auto idle bit only after setting the smartidle bit
+* as this is requirement for some modules like USBOTG
+* setting this will not have any impact on the other modues.
+*/
+
+ if (sf SYSC_HAS_AUTOIDLE) {
+ idlemode = (oh-flags HWMOD_NO_OCP_AUTOIDLE) ?
+ 0 : 1;
+ _set_module_autoidle(oh, idlemode, v);
+ }
+ _write_sysconfig(v, oh);
}
/**
Index: linux-omap-pm/arch/arm/plat-omap/include/plat/omap_device.h
===
--- linux-omap-pm.orig/arch/arm/plat-omap/include/plat/omap_device.h
2010-08-06 08:59:03.661863725 -0400
+++ linux-omap-pm/arch/arm/plat-omap/include/plat/omap_device.h 2010-08-06
09:02:00.021864999 -0400
@@ -116,6 +116,8 @@
int omap_device_disable_clocks(struct omap_device *od);
int omap_device_enable_clocks(struct omap_device *od);
+int omap_device_enable_wakeup(struct omap_device *od);
+int omap_device_disable_wakeup(struct omap_device *od);
/*
* Entries should be kept in latency order ascending
Index: linux-omap-pm/arch/arm/plat-omap/omap_device.c
===
--- linux-omap-pm.orig/arch/arm/plat-omap/omap_device.c 2010-08-06
08:59:03.661863725 -0400
+++ linux-omap-pm/arch/arm/plat-omap/omap_device.c 2010-08-06
09:02:00.021864999 -0400
@@ -757,3 +757,45 @@
/* XXX pass along return value here? */
return 0;
}
+
+/**
+ * omap_device_enable_wakeup - Enable the wakeup bit
+ * @od: struct omap_device *od
+ *
+ * Enable the wakup bit for omap_hwmods associated
+ * with the omap_device. Returns 0.
+ */
+
+int omap_device_enable_wakeup(struct omap_device *od)
+{
+ struct omap_hwmod *oh;
+ int i;
+
+ for (i = 0, oh = *od-hwmods; i od-hwmods_cnt; i++, oh++)
+ omap_hwmod_enable_wakeup(oh);
+
+ /* XXX pass along return value here? */
+ return 0;
+}
+
+/**
+ * omap_device_disable_wakeup -Disable the wakeup bit
+ * @od: struct omap_device *od
+ *
+ * Disable the wakup bit for omap_hwmods associated
+ * with the omap_device. Returns 0.
+ */
+
+
+int omap_device_disable_wakeup(struct omap_device *od)
+{
+ struct omap_hwmod *oh;
+ int i;
+
+ for (i = 0, oh = *od-hwmods; i od-hwmods_cnt; i++, oh++)
+ omap_hwmod_disable_wakeup(oh);
+
+ /* XXX pass along return value here? */
+ return 0;
+}
+
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8 ]usb : musb:Using runtime pm apis for musb.
From: Hema HK hem...@ti.com
Calling runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync()
for enabling/disabling the clocks,sysconfig settings.
used omap_hwmod_enable_wakeup omap_hwmod_disable_wakeup apis to set/clear
the wakeup enable bit.
Also need to put the USB in force standby and force idle mode when usb not used
and set it back to smart idle and smart stndby after wakeup.
these cases are handled using the oh flags.
For omap3430 auto idle bit has to be disabled because of the errata.So using
HWMOD_NO_OCP_AUTOIDLE flag for OMAP3430.
Signed-off-by: Hema HK hem...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm34xx.c | 10 +++-
arch/arm/mach-omap2/usb-musb.c| 72 ++-
arch/arm/plat-omap/include/plat/usb.h |9 +++
drivers/usb/musb/musb_core.c | 12 +
drivers/usb/musb/omap2430.c | 77 +-
include/linux/usb/musb.h | 18 +++
6 files changed, 126 insertions(+), 72 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/pm34xx.c 2010-08-06
10:44:06.0 -0400
+++ linux-omap-pm/arch/arm/mach-omap2/pm34xx.c 2010-08-06 10:44:42.942112875
-0400
@@ -418,7 +418,9 @@
omap3_core_save_context();
omap3_prcm_save_context();
/* Save MUSB context */
- musb_context_save_restore(1);
+ musb_context_save_restore(save_context);
+ } else {
+ musb_context_save_restore(disable_clk);
}
}
@@ -462,8 +464,10 @@
omap3_sram_restore_context();
omap2_sms_restore_context();
/* restore MUSB context */
- musb_context_save_restore(0);
- }
+ musb_context_save_restore(restore_context);
+ } else {
+ musb_context_save_restore(enable_clk);
+ }
omap_uart_resume_idle(0);
omap_uart_resume_idle(1);
if (core_next_state == PWRDM_POWER_OFF)
Index: linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/usb-musb.c 2010-08-06
10:44:06.0 -0400
+++ linux-omap-pm/arch/arm/mach-omap2/usb-musb.c2010-08-06
10:44:42.942112875 -0400
@@ -25,11 +25,13 @@
#include linux/io.h
#include linux/usb/musb.h
+#include linux/pm_runtime.h
#include mach/hardware.h
#include mach/irqs.h
#include plat/usb.h
#include plat/omap_device.h
+#include plat/omap_hwmod.h
#ifdef CONFIG_USB_MUSB_SOC
@@ -99,6 +101,18 @@
musb_plat.board_data = board_data;
musb_plat.power = board_data-power 1;
musb_plat.mode = board_data-mode;
+ musb_plat.device_enable = omap_device_enable;
+ musb_plat.device_idle = omap_device_idle;
+ musb_plat.enable_wakeup = omap_device_enable_wakeup;
+ musb_plat.disable_wakeup = omap_device_disable_wakeup;
+ /*
+* Errata 1.166 idle_req/ack is broken in omap3430
+* workaround is to disable the autodile bit for omap3430.
+*/
+ if (cpu_is_omap3430())
+ oh-flags |= HWMOD_NO_OCP_AUTOIDLE;
+
+ musb_plat.oh = oh;
pdata = musb_plat;
od = omap_device_build(name, bus_id, oh, pdata,
@@ -120,7 +134,7 @@
}
}
-void musb_context_save_restore(int save)
+void musb_context_save_restore(enum musb_state state)
{
struct omap_hwmod *oh = omap_hwmod_lookup(usb_otg_hs);
struct omap_device *od = oh-od;
@@ -129,14 +143,64 @@
struct device_driver *drv = dev-driver;
if (drv) {
+#ifdef CONFIG_PM_RUNTIME
struct musb_hdrc_platform_data *pdata = dev-platform_data;
const struct dev_pm_ops *pm = drv-pm;
- if (!pdata-is_usb_active(dev)) {
- if (save)
+ if (!pdata-is_usb_active(dev)) {
+ switch (state) {
+ case save_context:
+ /* If the usb device not active then Save
+* the context,set the sysconfig setting to
+* force standby force idle during idle and
+* disable the clock.
+*/
+ oh-flags |= HWMOD_SWSUP_SIDLE
+
RE: [PATCH 2/6] TI816X: Update common omap platform files
Hi Kevin, Kevin Hilman wrote: Hemant Pedanekar hema...@ti.com writes: This patch updates the common platform files with TI816X specific additions. Also adds new files for TI816X modules base addresseses and irq definitions. Signed-off-by: Hemant Pedanekar hema...@ti.com --- [...] diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S b/arch/arm/mach-omap2/include/mach/entry-macro.S index 50fd749..6516cbd 100644 --- a/arch/arm/mach-omap2/include/mach/entry-macro.S +++ b/arch/arm/mach-omap2/include/mach/entry-macro.S @@ -34,7 +34,7 @@ .endm /* - * Unoptimized irq functions for multi-omap2, 3 and 4 + * Unoptimized irq functions for multi-omap2, 3, 4 and ti816x */ #ifdef MULTI_OMAP2 @@ -57,7 +57,8 @@ omap_irq_base: .word 0 [...] +bne 9998f + +/* + * ti816x has additional IRQ pending register. Checking this + * register on omap2 omap3 has no effect (read as 0). + */ +ldr \irqnr, [\base, #0xf8] /* IRQ pending reg 4 */ +cmp \irqnr, #0x0 This part makes me a slightly nervous. At least according to the TRMs, this address is undefined on OMAP2 OMAP3 (yet still in the INTC block.) Was this tested on OMAP2/3 hardware and verified to return 0? You might also consider wrapping this section in #ifdef CONFIG_ARCH_TI816X so a multi-OMAP kernel without 816x support would avoid this extra read. Won't the usage of #ifdef inside MULTI_OMAP2 make things look strange? E.g., #ifdef MULTI_OMAP2 ... #ifdef CONFIG_ARCH_TI816X ... #endif #endif (Specifically, since there is already a custom block present in #else part?) Thanks - Hemant -- 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
UbiFS regression(?)
UBI error: ubi_io_read: error -74 while reading 64 bytes from PEB 0:0, read 64 bytes UBI error: ubi_io_read: error -74 while reading 64 bytes from PEB 0:1, read 64 bytes . root=ubi0:rootfs rw rootwait ubi.mtd=4 rootfstype=ubifs beagleboard 2.6.35-beagle-32op-08909-g8428498 last commit: 842849896627701e4c07441f2c7519aeec771058 CONFIG_MTD_UBI=y CONFIG_MTD_UBI_WL_THRESHOLD=4096 CONFIG_MTD_UBI_BEB_RESERVE=1 CONFIG_UBIFS_FS=y CONFIG_UBIFS_FS_XATTR=y CONFIG_UBIFS_FS_ADVANCED_COMPR=y CONFIG_UBIFS_FS_LZO=y CONFIG_UBIFS_FS_ZLIB=y -- 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/6] TI816X: Update common omap platform files
Pedanekar, Hemant hema...@ti.com writes: Hi Kevin, Kevin Hilman wrote: Hemant Pedanekar hema...@ti.com writes: This patch updates the common platform files with TI816X specific additions. Also adds new files for TI816X modules base addresseses and irq definitions. Signed-off-by: Hemant Pedanekar hema...@ti.com --- [...] diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S b/arch/arm/mach-omap2/include/mach/entry-macro.S index 50fd749..6516cbd 100644 --- a/arch/arm/mach-omap2/include/mach/entry-macro.S +++ b/arch/arm/mach-omap2/include/mach/entry-macro.S @@ -34,7 +34,7 @@ .endm /* - * Unoptimized irq functions for multi-omap2, 3 and 4 + * Unoptimized irq functions for multi-omap2, 3, 4 and ti816x */ #ifdef MULTI_OMAP2 @@ -57,7 +57,8 @@ omap_irq_base:.word 0 [...] + bne 9998f + + /* +* ti816x has additional IRQ pending register. Checking this +* register on omap2 omap3 has no effect (read as 0). + */ + ldr \irqnr, [\base, #0xf8] /* IRQ pending reg 4 */ + cmp \irqnr, #0x0 This part makes me a slightly nervous. At least according to the TRMs, this address is undefined on OMAP2 OMAP3 (yet still in the INTC block.) Was this tested on OMAP2/3 hardware and verified to return 0? You might also consider wrapping this section in #ifdef CONFIG_ARCH_TI816X so a multi-OMAP kernel without 816x support would avoid this extra read. Won't the usage of #ifdef inside MULTI_OMAP2 make things look strange? E.g., #ifdef MULTI_OMAP2 ... #ifdef CONFIG_ARCH_TI816X ... #endif #endif (Specifically, since there is already a custom block present in #else part?) Yeah, I thought about that too. That's why I said you might consider... above. But thinking more, you're right. When we want an optimized version for a specific SoC, we just compile for that SoC and get the optimized version. Go ahead and leave out the #ifdef, but I'd still like to see some tests on OMAP2 that show that reading this undefined part of the INTC block does indeed return zero. 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: [RFC PATCH] platform: Faciliatate the creation of pseduo-platform busses
On Fri, Aug 06, 2010 at 09:12:27AM -0600, Grant Likely wrote: On Fri, Aug 6, 2010 at 8:27 AM, Greg KH gre...@suse.de wrote: On Thu, Aug 05, 2010 at 04:59:35PM -0600, Grant Likely wrote: (On that point Greg, what is the reason for even having the /sys/devices/platform/ parent? Why not just let the platform devices sit at the root of the device tree? In the OF case (granted, I'm biased) all of the platform_device registrations reflect the actual device hierarchy expressed in the device tree data.) If we sat them at the root, there would be a bunch of them there. I don't know, we could drop the parent, I guess whoever created the platform device oh so long ago, decided that it would look nicer to be in this type of structure. Personally I'd rather see a meaningful structure used here. Maybe having them all in the root will encourage people to find realistic parents for their platform devices. :-) That would be nice, but take your standard PC today: ls /sys/devices/platform/ Fixed MDIO bus.0 i8042 pcspkr power serial8250 uevent vesafb.0 There are tty devices below the serial port, which is nice to see, but the others? I don't know what type of bus they would be on, do you? Why don't I float a patch to remove this and see if anybody freaks out. Should I wrap it with a CONFIG_ so that it can be configurable for a release or to, or just make it unconditional? If you can figure out a structure for the desktop/server machines, sure, I say just always enable it :) 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
Re: [PATCH V2 6/8] usb: musb: Offmode fix for idle path
On Sat, Aug 7, 2010 at 1:27 AM, Hema HK hem...@ti.com wrote:
From: Hema HK hem...@ti.com
With OMAP core-off support musb was not functional as context was getting
lost after wakeup from core-off. And also musb was blocking the core-off
after loading the gadget driver even with no cable connected sometimes.
Added the conext save/restore api in the platform layer which will
be called in the idle and wakeup path.
Changed the usb sysconfig settings as per the usbotg functional spec.
When the device is not active, configure to force idle and force standby mode.
When it is being used, configure in smart standby and smart idle mode.
So while attempting to coreoff the usb is configured to force standby and
force idle mode, after wakeup configured in smart idle and smart standby.
Signed-off-by: Hema HK hem...@ti.com
Signed-off-by: Maulik Mankad x0082...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm34xx.c | 4 ++
arch/arm/mach-omap2/usb-musb.c | 21 ++
arch/arm/plat-omap/include/plat/usb.h | 2 +
drivers/usb/musb/musb_core.c | 11 ---
drivers/usb/musb/omap2430.c | 48
+++---
5 files changed, 71 insertions(+), 15 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/pm34xx.c 2010-08-06
09:23:01.153862710 -0400
+++ linux-omap-pm/arch/arm/mach-omap2/pm34xx.c 2010-08-06 10:44:06.393863125
-0400
@@ -39,6 +39,7 @@
#include plat/gpmc.h
#include plat/dma.h
#include plat/dmtimer.h
+#include plat/usb.h
#include asm/tlbflush.h
@@ -416,6 +417,8 @@
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_prcm_save_context();
+ /* Save MUSB context */
+ musb_context_save_restore(1);
}
}
@@ -458,6 +461,8 @@
omap3_prcm_restore_context();
omap3_sram_restore_context();
omap2_sms_restore_context();
+ /* restore MUSB context */
+ musb_context_save_restore(0);
}
omap_uart_resume_idle(0);
omap_uart_resume_idle(1);
Index: linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/usb-musb.c 2010-08-06
09:24:23.690112596 -0400
+++ linux-omap-pm/arch/arm/mach-omap2/usb-musb.c 2010-08-06
10:44:06.385862697 -0400
@@ -120,6 +120,27 @@
}
}
+void musb_context_save_restore(int save)
+{
+ struct omap_hwmod *oh = omap_hwmod_lookup(usb_otg_hs);
+ struct omap_device *od = oh-od;
+ struct platform_device *pdev = od-pdev;
+ struct device *dev = pdev-dev;
+ struct device_driver *drv = dev-driver;
+
+ if (drv) {
+ struct musb_hdrc_platform_data *pdata = dev-platform_data;
+ const struct dev_pm_ops *pm = drv-pm;
+ if (!pdata-is_usb_active(dev)) {
+
+ if (save)
+ pm-suspend(dev);
+ else
+ pm-resume_noirq(dev);
+ }
+ }
+}
+
#else
void __init usb_musb_init(struct omap_musb_board_data *board_data)
{
Index: linux-omap-pm/arch/arm/plat-omap/include/plat/usb.h
===
--- linux-omap-pm.orig/arch/arm/plat-omap/include/plat/usb.h 2010-08-06
09:23:01.137862514 -0400
+++ linux-omap-pm/arch/arm/plat-omap/include/plat/usb.h 2010-08-06
10:44:06.381864367 -0400
@@ -79,6 +79,8 @@
extern void usb_ohci_init(const struct ohci_hcd_omap_platform_data *pdata);
+/* For saving and restoring the musb context during off/wakeup*/
+extern void musb_context_save_restore(int save);
#endif
Index: linux-omap-pm/drivers/usb/musb/musb_core.c
===
--- linux-omap-pm.orig/drivers/usb/musb/musb_core.c 2010-08-06
09:24:21.069863329 -0400
+++ linux-omap-pm/drivers/usb/musb/musb_core.c 2010-08-06 10:44:06.369863527
-0400
@@ -2427,11 +2427,6 @@
}
musb_save_context(musb);
-
- if (musb-set_clock)
- musb-set_clock(musb-clock, 0);
- else
- clk_disable(musb-clock);
spin_unlock_irqrestore(musb-lock, flags);
return 0;
}
@@ -2443,12 +2438,6 @@
if (!musb-clock)
return 0;
Is this check can be deleted also ?
Because our blackfin platform have no clock support now.
Thanks.
-
- if (musb-set_clock)
-
