Re: [PATCH] omap: Fix sev instruction usage for multi-omap
On 08/06/2010 03:05 PM, Tony Lindgren wrote: * 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 Tony, I also did similar thing these days. And yes, with these 2 CONFIG_SMP related patches in omap3_defconfig, I can built a single for omap2/3/4 with CONFIG_SMP=y. But the kernel still doesn't boot on both omap3 beagle board and omap4 panda board on my side. I'm very glad to help this out. Thanks, -- Bryan Wu bryan...@canonical.com Kernel Developer+86.138-1617-6545 Mobile Ubuntu Kernel Team | Hardware Enablement Team Canonical Ltd. www.canonical.com Ubuntu - Linux for human beings | www.ubuntu.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
Re: [PATCH 1/2] mfd: menelaus: Fix mmc slot 2 misconfiguration
* Jarkko Nikula jhnik...@gmail.com [100808 19:57]: Tested on N810. Integrated eMMC on N810 started to work with this patch. Ah great, good to hear! I've been wondering for a while how come only the external MMC worked. 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 4/5] [omap1] Bluetooth device code common to HTC smartphones
* Cory Maccarrone darkstar6...@gmail.com [100808 20:22]: On Wed, Aug 4, 2010 at 3:15 AM, Tony Lindgren t...@atomide.com wrote: * Cory Maccarrone darkstar6...@gmail.com [100802 18:23]: This change adds in a bluetooth controld driver/rfkill interface to the serial bluetooth controller found on many HTC smartphones such as the HTC Herald and HTC Wizard. To me it looks like most of this should be in drivers/bluetooth/omap7xx.c or something like that. Then you can just pass it the gpio numbers in the platform_data. Not sure I agree that it fits there. The driver isn't really a bluetooth driver -- it's really just an RFKILL interface, and some code to toggle UART clocks on and off, plus GPIO work on a board-specific level. In principle, the gpios could be set and the clocks enabled in the board files, and this driver wouldn't be necessary to get working bluetooth (as we'd use hciattach on /dev/ttyS*). But then, we can't toggle it off for power saving. Maybe a better place would be plat-omap/? But it really is more specific to these HTC boards, not the architecture itself. Hmm well what we've used earlier is to set something like set_power function pointer in the platform data, then call that in the driver if set. But in this case the driver is 8250.c, so let's not mess with that.. This issue should get properly solved with the omap specific serial driver once we get that merged as then we can have hooks for set_power in addition to cutting serial clocks when idle. So really, the only point of this driver is to be able to power on and off the external bluetooth chip, which is why I submitted it as helper code to the board files. Yeah. Can you take a look at the omap specific serial driver to get it working on omap1? Then you can have your GPIO functions set in the board-*.c file as set_power or similar, and the UART driver can idle properly. 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] omap: Fix sev instruction usage for multi-omap
* Bryan Wu bryan...@canonical.com [100809 09:35]: I also did similar thing these days. And yes, with these 2 CONFIG_SMP related patches in omap3_defconfig, I can built a single for omap2/3/4 with CONFIG_SMP=y. But the kernel still doesn't boot on both omap3 beagle board and omap4 panda board on my side. I'm very glad to help this out. Yeah let's try to figure out what needs to be done to boot it. To me it looks like we should be able to get omap3 4 kernel working with CONFIG_SMP with (hopefully) minor changes. Then getting omap2 working will require more work as some instructions require CONFIG_CPU_32v6K extensions, and 24xx does not support that. 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: Issues with calling pm_runtime functions in platform_pm_suspend_noirq/IRQ disabled context.
On Sat, 7 Aug 2010, Basak, Partha wrote: -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Saturday, August 07, 2010 1:00 AM On Tue, 3 Aug 2010, Basak, Partha wrote: I believe, it is not correct to call the pm_runtime APIs from interrupt locked context Why do you think that the PM runtime APIs are being called from interrupt context? Could you point out the call chain that you're seeing? I meant that they should not not be called in a context which has interrupts disabled. SRAM_Idle as well as suspend_no_irq are the instances I was referring to. It would be really helpful if you would use the exact names of the functions that you are referring to. This message assumes that your use of SRAM_Idle refers to omap_sram_idle() in pm34xx.c, and that suspend_no_irq refers to platform_pm_suspend_noirq() in pm_bus.c. You write that [the PM runtime functions] should not not be called in a context which has interrupts disabled. All interrupts? Some interrupts? Context in the general sense, or in the strict sense used in Linux interrupt handling? It is difficult to comment on this statement since it is unclear. I will guess that your message refers to the fact that some of the PM runtime functions take a mutex, and therefore it is invalid to call those functions when the timer interrupt is disabled. If that's what you mean, then it's worth observing that it's valid to call some PM runtime functions, such as pm_runtime_get_noresume(), pm_runtime_suspended(), etc., no matter which interrupts are enabled, since they don't take any mutex. Similarly, it seems quite valid to call pretty much any PM runtime function as long as the timer interrupt is still running. This is the case with platform_pm_suspend_noirq(), at least, with this call chain: dpm_suspend_noirq() - device_suspend_noirq() - pm_irq_op() - dev_pm_ops.suspend_noirq - platform_pm_suspend_noirq() Unfortunately, your message didn't provide a call chain, so, not sure if we're even referring to the same code path. Based on this chain, I don't see any interrupt-related problems with calling PM runtime functions from platform_pm_suspend_noirq(). If you are actually seeing some problem here, then you should post the warning that you're seeing and the call chain that's causing the problem. Finally, we have omap_sram_idle(): In particular, for USB, while executing SRAM_Idle, is we use pm_runtime functions, we see spurious IO-Pad interrupts. Your message doesn't specify what PM runtime functions you are executing. But if those functions are calling mutex_lock(), then they obviously must not be called from omap_sram_idle() in interrupt context. It's not clear from your message why you need to call PM runtime functions from the idle loop. I'd suggest that you post the problematic code in question to the list. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] omap: n8x0: Audio update to N810
Hi With this set and a fix [1] it is possible to get ALSA SoC on N810 working. This set is generated against mainline commit e320cea but applies also to linux-omap (board-n8x0.c has cbus patches in linux-omap). -- Jarkko 1. http://marc.info/?l=linux-omapm=128109830113485w=2 -- 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/3] omap: n8x0: Cleanup i2c1 and menelaus registration
- Move n8x0_i2c_board_info_1 out from #ifdef CONFIG_MENELAUS block,
register i2c1 in n8x0_init_machine and do a few clean-ups around these.
Code looks better if board infos are grouped together
- Mark n8x0_i2c_board_info_1 and n8x0_menelaus_platform_data with __initdata
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
arch/arm/mach-omap2/board-n8x0.c | 34 +++---
1 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index a3e2b49..313ce5e 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -614,30 +614,25 @@ static int n8x0_menelaus_late_init(struct device *dev)
return 0;
}
-static struct i2c_board_info __initdata n8x0_i2c_board_info_1[] = {
+#else
+static int n8x0_menelaus_late_init(struct device *dev)
+{
+ return 0;
+}
+#endif
+
+static struct menelaus_platform_data n8x0_menelaus_platform_data __initdata = {
+ .late_init = n8x0_menelaus_late_init,
+};
+
+static struct i2c_board_info __initdata n8x0_i2c_board_info_1[] __initdata = {
{
I2C_BOARD_INFO(menelaus, 0x72),
.irq = INT_24XX_SYS_NIRQ,
+ .platform_data = n8x0_menelaus_platform_data,
},
};
-static struct menelaus_platform_data n8x0_menelaus_platform_data = {
- .late_init = n8x0_menelaus_late_init,
-};
-
-static void __init n8x0_menelaus_init(void)
-{
- n8x0_i2c_board_info_1[0].platform_data = n8x0_menelaus_platform_data;
- omap_register_i2c_bus(1, 400, n8x0_i2c_board_info_1,
- ARRAY_SIZE(n8x0_i2c_board_info_1));
-}
-
-#else
-static inline void __init n8x0_menelaus_init(void)
-{
-}
-#endif
-
static void __init n8x0_map_io(void)
{
omap2_set_globals_242x();
@@ -665,9 +660,10 @@ static void __init n8x0_init_machine(void)
/* FIXME: add n810 spi devices */
spi_register_board_info(n800_spi_board_info,
ARRAY_SIZE(n800_spi_board_info));
+ omap_register_i2c_bus(1, 400, n8x0_i2c_board_info_1,
+ ARRAY_SIZE(n8x0_i2c_board_info_1));
omap_serial_init();
- n8x0_menelaus_init();
n8x0_onenand_init();
n8x0_mmc_init();
n8x0_usb_init();
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] omap: n8x0: Register i2c2 and add board info with tlv320aic3x for N810
Second i2c bus on Nokia N800 and N810 shares both common and hw specific
peripherals. Register now this bus and add board info with tlv320aic3x for
N810. Common peripherals may be added as an additional board info to
omap_register_i2c_bus(2, ...);
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
With this patch it is possible to probe tlv320aic3x audio codec and get the
ASoC subsystem registered on Nokia N810.
---
arch/arm/mach-omap2/board-n8x0.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 313ce5e..7863633 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -20,6 +20,7 @@
#include linux/i2c.h
#include linux/spi/spi.h
#include linux/usb/musb.h
+#include sound/tlv320aic3x.h
#include asm/mach/arch.h
#include asm/mach-types.h
@@ -633,6 +634,17 @@ static struct i2c_board_info __initdata
n8x0_i2c_board_info_1[] __initdata = {
},
};
+static struct aic3x_pdata n810_aic33_data __initdata = {
+ .gpio_reset = 118,
+};
+
+static struct i2c_board_info n810_i2c_board_info_2[] __initdata = {
+ {
+ I2C_BOARD_INFO(tlv320aic3x, 0x18),
+ .platform_data = n810_aic33_data,
+ },
+};
+
static void __init n8x0_map_io(void)
{
omap2_set_globals_242x();
@@ -662,6 +674,10 @@ static void __init n8x0_init_machine(void)
ARRAY_SIZE(n800_spi_board_info));
omap_register_i2c_bus(1, 400, n8x0_i2c_board_info_1,
ARRAY_SIZE(n8x0_i2c_board_info_1));
+ omap_register_i2c_bus(2, 400, NULL, 0);
+ if (machine_is_nokia_n810())
+ i2c_register_board_info(2, n810_i2c_board_info_2,
+ ARRAY_SIZE(n810_i2c_board_info_2));
omap_serial_init();
n8x0_onenand_init();
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] omap: n8x0: Mux i2s codec port pins for McBSP block
Bootloader on Nokia N800 and N810 muxes I2C codec port pins for EAC block.
As there is no driver and use for EAC, mux those pins for McBSP instead
since N810 ASoC drivers can use it.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
With this patch it is possible to use audio on Nokia N810 by enabling the
CONFIG_SND_OMAP_SOC_N810=y
---
arch/arm/mach-omap2/board-n8x0.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 7863633..8fd2269 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -660,6 +660,11 @@ static void __init n8x0_init_irq(void)
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* I2S codec port pins for McBSP block */
+ OMAP2420_MUX(EAC_AC_SCLK, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP2420_MUX(EAC_AC_FS, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP2420_MUX(EAC_AC_DIN, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP2420_MUX(EAC_AC_DOUT, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 7/8] : Hwmod api changes
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, August 09, 2010 1:51 PM To: Nayak, Rajendra Cc: Kalliguddi, Hema; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Basak, Partha; Felipe Balbi; Tony Lindgren; Cousson, Benoit; Kevin Hilman Subject: RE: [PATCH 7/8] : Hwmod api changes (cc Benoît) On Mon, 9 Aug 2010, Nayak, Rajendra wrote: Does it make sense for the framework itself to enable wakeup for all devices when the slave port is programmed to be in Smartidle It seems to me that they are separate mechanisms? If a module is programmed for slave smart-idle, then the module prevents the PRCM from shutting off the module clock(s) until the module is not busy. This seems distinct from ENAWAKEUP, which I thought simply controlled whether the module would assert the SWakeup signal to the PRCM when an external wakeup condition occurred for that module. Is that an accurate summary? hmm.. the reason I thought the two were related was because the need to assert a SWakeup will arise only when the module is programmed in smart-idle. If the module is either in no-idle (in which case no idle-ack is asserted by the module) or force-idle (when the module is forced to idle and expected to stay idle) there might not be a need for the module to be capable of asserting a SWakeup. The reason I proposed ENAWAKEUP to be always enabled with smart-idle was with as understanding that we may never have a case wherein the module is programmed in smart-idle but not expected to assert SWakeup (if it supports one). I will check up on this if there ever could be such a case. instead of exposing 2 more omap device level api;s to the drivers? Something like this probably needs to be exposed to core code that would also set/clear PM_WKEN_* for the appropriate processor module. Right now we just set a bunch of these bits directly in pm.c, and that needs to change. The other issue is that I suspct the module needs to be enabled in order for SYSCONFIG writes to succeed; right now the underlying hwmod code does not appear to enforce this :-( But I don't see why drivers would need to call these functions directly. Hema, was that your intention? If so, you could you please explain the use case? I have a patch for this and can post it for review in case you feel it makes sense. - Paul-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] : Hwmod api changes
On 8/6/2010 7:28 PM, Kalliguddi, Hema wrote:
From: Hema HKhem...@ti.com
Omap USBOTG modules has a requirement to set the auto idle bit only after
setting smart idle bit.
Is it a requirement or an errata? Could you provide more information
(i.e. TRM page or errata number / description)?
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 HKhem...@ti.com
Signed-off-by: Basak, Parthap-bas...@ti.com
Cc: Felipe Balbifelipe.ba...@nokia.com
Cc: Tony Lindgrent...@atomide.com
Cc: Kevin Hilmankhil...@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.
+*/
Except that you are adding an extra access to a quite slow L4 slave
interface. I'm not sure if write posted will help in that case.
+
+ 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)
Why do you need that? Could you elaborate?
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 0/8]usb: musb:USB driver changes to use hwmod+ omap-device apis
On 8/6/2010 5:54 PM, HEMA HK wrote: From: Hema HKhem...@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. The way you are submitting that series is quite confusing! You are mixing several numbering schemes and several series versions. If this is a V2, you have to resubmit everything with a V2, and you must include an history. [8/8] usb : musb:Using runtime pm apis for musb. [7/8] : Hwmod api changes [V2,6/8] usb: musb: Offmode fix for idle path [V2,4/8] usb : musb:Using omap_device_build for musb device registration [4/8] usb: musb: HWMOD database structures fixes OMAP4 [V2,3/4] usb: musb: HWMOD database structures addition for OMAP3 [2/8] usb: musb: Remove board_data parameter from musb_platform_init() [1/8] usb: musb: Adding names for IRQs in resource structure The cover letter does not contain the overall stat to summarize what files you are modifying. Some spaces are missing after the : in the email subjects. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP4: HWMOD: Do omap_hwmod_late_init for OMAP4
-Original Message-
From: Cousson, Benoit
Sent: Friday, August 06, 2010 6:06 PM
To: Varadarajan, Charulatha
Cc: linux-omap@vger.kernel.org; p...@pwsan.com;
khil...@deeprootsystems.com; Nayak, Rajendra; Basak, Partha
Subject: 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/
Okay. I found omap_hwmod_late_init() call missing for OMAP4 in
origin/pm-wip/hwmods-omap4 and sent this patch without noticing your
above mentioned patch. Please ignore this patch.
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 V2 4/8]usb : musb:Using omap_device_build for musb device registration
On 8/6/2010 5:57 PM, Kalliguddi, Hema wrote:
From: Hema HKhem...@ti.com
snip
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);
This is not needed in your case. Just use a const char*, and you will
avoid the useless snprintf and test.
+
+ oh = omap_hwmod_lookup(oh_name);
+
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ } else {
You can avoid that indentation be returning in case of failure.
+ /*
+* 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 {
You can avoid that second level of indentation be returning in case of
failure as well.
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] OMAP: DSS2: OMAPFB: add support for FBIO_WAITFORVSYNC
-Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Tuesday, August 03, 2010 5:32 PM To: ext Grazvydas Ignotas Cc: linux-fb...@vger.kernel.org; linux-omap@vger.kernel.org; Hiremath, Vaibhav Subject: Re: [PATCH] OMAP: DSS2: OMAPFB: add support for FBIO_WAITFORVSYNC On Fri, 2010-07-02 at 22:54 +0200, ext Grazvydas Ignotas wrote: FBIO_WAITFORVSYNC is a stardard ioctl for waiting vsync, already used by some userspace, so add it as an alias for OMAPFB_WAITFORVSYNC. Signed-off-by: Grazvydas Ignotas nota...@gmail.com --- Tomi, I know I already sent this earlier, but as now FBIO_WAITFORVSYNC is a standard ioctl, so why don't we support it? I know you might not like that omapfb_ioctl will have one standard ioctl handler between all OMAP specific ones, but that's something plenty of other drivers do. One could ask that if FBIO_WAITFORSYNC is a standard ioctl, why do we need to handle it in omapfb's custom ioctl function =). But I think this is fine, I'll apply. [Hiremath, Vaibhav] I still think we should mark the old (custom) interface as deprecated and add new standard ioctl interface here, so that in the future we can remove custom one. Thanks, Vaibhav Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 6/8] usb: musb: Offmode fix for idle path
On 8/6/2010 7:27 PM, Kalliguddi, Hema wrote:
From: Hema HKhem...@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.
Is this valid for OMAP3 and OMAP4? I checked quickly the OMAP4 TRM vB in
the USB_OTG chapter related to PM (23.13.4.2 Power-Management), and I
cannot find any note regarding that specific programming model.
Could give us reference to the documentation that contains the details
about that?
Benoit
Signed-off-by: Hema HKhem...@ti.com
Signed-off-by: Maulik Mankadx0082...@ti.com
Cc: Felipe Balbifelipe.ba...@nokia.com
Cc: Tony Lindgrent...@atomide.com
Cc: Kevin Hilmankhil...@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 @@
#includeplat/gpmc.h
#includeplat/dma.h
#includeplat/dmtimer.h
+#includeplat/usb.h
#includeasm/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
RE: [PATCH V2 6/8] usb: musb: Offmode fix for idle path
Hi,
-Original Message-
From: Cousson, Benoit
Sent: Monday, August 09, 2010 6:31 PM
To: Kalliguddi, Hema
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
Mankad, Maulik Ojas; Felipe Balbi; Tony Lindgren; Kevin Hilman
Subject: Re: [PATCH V2 6/8] usb: musb: Offmode fix for idle path
On 8/6/2010 7:27 PM, Kalliguddi, Hema wrote:
From: Hema HKhem...@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.
Is this valid for OMAP3 and OMAP4? I checked quickly the OMAP4
TRM vB in
the USB_OTG chapter related to PM (23.13.4.2 Power-Management), and I
cannot find any note regarding that specific programming model.
Could give us reference to the documentation that contains the details
about that?
Benoit
This is valid for both OMAP3 and OMAP4. You can find this in 24.1.5.4 section
With different modes. When not used with any application the mode has to be
programmed
is force idle and force standby. What I observed is that without this USB was
blocking the coreoff.
http://focus.ti.com/pdfs/wtbu/SWPU223D_Final_EPDF_06_07_2010.pdf
Regards,
Hema
Signed-off-by: Hema HKhem...@ti.com
Signed-off-by: Maulik Mankadx0082...@ti.com
Cc: Felipe Balbifelipe.ba...@nokia.com
Cc: Tony Lindgrent...@atomide.com
Cc: Kevin Hilmankhil...@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 @@
#includeplat/gpmc.h
#includeplat/dma.h
#includeplat/dmtimer.h
+#includeplat/usb.h
#includeasm/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
Re: [PATCH] spi: omap2_mcspi: make use of dev_vdbg()
On Mon, Aug 9, 2010 at 4:36 AM, Felipe Balbi felipe.ba...@nokia.com wrote:
On Thu, Jun 03, 2010 at 01:09:01PM +0200, Balbi Felipe (Nokia-D/Helsinki)
wrote:
From: Felipe Balbi felipe.ba...@nokia.com
dev_vdbg() is only compiled when VERBOSE is defined, so
there's no need to wrap dev_dbg() on #ifdef VERBOSE .. #endif
as we can use dev_vdbg() directly.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
ping, any comments to this one ? It's been pending for quite a long time.
It didn't get sent to the spi-devel-general list, so it didn't get
picked up by patchwork and wasn't there for me to pick up when I was
collecting stuff for .36.
g.
drivers/spi/omap2_mcspi.c | 36 +---
1 files changed, 9 insertions(+), 27 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index b3a94ca..d703927 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -489,10 +489,8 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
dev_err(spi-dev, TXS timed
out\n);
goto out;
}
-#ifdef VERBOSE
- dev_dbg(spi-dev, write-%d %02x\n,
+ dev_vdbg(spi-dev, write-%d %02x\n,
word_len, *tx);
-#endif
__raw_writel(*tx++, tx_reg);
}
if (rx != NULL) {
@@ -506,10 +504,8 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
(l OMAP2_MCSPI_CHCONF_TURBO)) {
omap2_mcspi_set_enable(spi, 0);
*rx++ = __raw_readl(rx_reg);
-#ifdef VERBOSE
- dev_dbg(spi-dev, read-%d
%02x\n,
+ dev_vdbg(spi-dev, read-%d
%02x\n,
word_len, *(rx - 1));
-#endif
if
(mcspi_wait_for_reg_bit(chstat_reg,
OMAP2_MCSPI_CHSTAT_RXS)
0) {
dev_err(spi-dev,
@@ -522,10 +518,8 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
}
*rx++ = __raw_readl(rx_reg);
-#ifdef VERBOSE
- dev_dbg(spi-dev, read-%d %02x\n,
+ dev_vdbg(spi-dev, read-%d %02x\n,
word_len, *(rx - 1));
-#endif
}
} while (c);
} else if (word_len = 16) {
@@ -542,10 +536,8 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
dev_err(spi-dev, TXS timed
out\n);
goto out;
}
-#ifdef VERBOSE
- dev_dbg(spi-dev, write-%d %04x\n,
+ dev_vdbg(spi-dev, write-%d %04x\n,
word_len, *tx);
-#endif
__raw_writel(*tx++, tx_reg);
}
if (rx != NULL) {
@@ -559,10 +551,8 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
(l OMAP2_MCSPI_CHCONF_TURBO)) {
omap2_mcspi_set_enable(spi, 0);
*rx++ = __raw_readl(rx_reg);
-#ifdef VERBOSE
- dev_dbg(spi-dev, read-%d
%04x\n,
+ dev_vdbg(spi-dev, read-%d
%04x\n,
word_len, *(rx - 1));
-#endif
if
(mcspi_wait_for_reg_bit(chstat_reg,
OMAP2_MCSPI_CHSTAT_RXS)
0) {
dev_err(spi-dev,
@@ -575,10 +565,8 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
}
*rx++ = __raw_readl(rx_reg);
-#ifdef VERBOSE
- dev_dbg(spi-dev, read-%d %04x\n,
+ dev_vdbg(spi-dev, read-%d %04x\n,
word_len, *(rx - 1));
-#endif
}
} while (c);
} else if (word_len = 32) {
@@ -595,10 +583,8 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
dev_err(spi-dev, TXS timed
out\n);
goto out;
Re: [PATCH] musb: move usb_add_hcd to the core init code from gadget code (v2)
Felipe,
Any comments on this patch?
Thanks a lot,
-Bryan
On 07/23/2010 10:36 PM, Bryan Wu wrote:
BugLink: http://bugs.launchpad.net/bugs/608312
v2:
fix the building error on latest 2.6.35-rc kernel, since v1 was generated in
2.6.33 kernel.
v1:
usb_add_hcd was only called when we insmod the gadget class module or built-in
that gadget class driver. If musb is configured as OTG controller, we need to
insmod or built-in gadget class driver to make our Host mode fucntion works.
In our Ubuntu system, normally we compiled all the gadget class drivers as
modules. Then users can insmod the gadget modules as they want. But without the
gadget class driver running, we needs host function to support common USB
devices.
This patch fix this issue and tested on omap3 beagle board and Gumstix board.
Signed-off-by: Bryan Wubryan...@canonical.com
---
drivers/usb/musb/musb_core.c | 13 +
drivers/usb/musb/musb_gadget.c | 18 --
2 files changed, 5 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 3b795c5..1b6d74c 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1583,14 +1583,6 @@ irqreturn_t musb_interrupt(struct musb *musb)
(devctl MUSB_DEVCTL_HM) ? host : peripheral,
musb-int_usb, musb-int_tx, musb-int_rx);
-#ifdef CONFIG_USB_GADGET_MUSB_HDRC
- if (is_otg_enabled(musb) || is_peripheral_enabled(musb))
- if (!musb-gadget_driver) {
- DBG(5, No gadget driver loaded\n);
- return IRQ_HANDLED;
- }
-#endif
-
/* the core can interrupt us for multiple reasons; docs have
* a generic interrupt flowchart to follow
*/
@@ -2128,6 +2120,11 @@ bad_config:
status = musb_gadget_setup(musb);
+ if (is_otg_enabled(musb)) {
+ status = usb_add_hcd(musb_to_hcd(musb), -1, 0);
+ musb_start(musb);
+ }
+
DBG(1, %s mode, status %d, dev%02x\n,
is_otg_enabled(musb) ? OTG : PERIPHERAL,
status,
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 6fca870..9e55534 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1761,24 +1761,6 @@ int usb_gadget_register_driver(struct usb_gadget_driver
*driver)
otg_set_peripheral(musb-xceiv,musb-g);
spin_unlock_irqrestore(musb-lock, flags);
-
- if (is_otg_enabled(musb)) {
- DBG(3, OTG startup...\n);
-
- /* REVISIT: funcall to other code, which also
-* handles power budgeting ... this way also
-* ensures HdrcStart is indirectly called.
-*/
- retval = usb_add_hcd(musb_to_hcd(musb), -1, 0);
- if (retval 0) {
- DBG(1, add_hcd failed, %d\n, retval);
- spin_lock_irqsave(musb-lock, flags);
- otg_set_peripheral(musb-xceiv, NULL);
- musb-gadget_driver = NULL;
- musb-g.dev.driver = NULL;
- spin_unlock_irqrestore(musb-lock, flags);
- }
- }
}
return retval;
--
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 8/8 ]usb : musb:Using runtime pm apis for musb.
On 8/6/2010 7:29 PM, Hema HK wrote:
From: Hema HKhem...@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 HKhem...@ti.com
Signed-off-by: Basak, Parthap-bas...@ti.com
Cc: Felipe Balbifelipe.ba...@nokia.com
Cc: Tony Lindgrent...@atomide.com
Cc: Kevin Hilmankhil...@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 @@
#includelinux/io.h
#includelinux/usb/musb.h
+#includelinux/pm_runtime.h
#includemach/hardware.h
#includemach/irqs.h
#includeplat/usb.h
#includeplat/omap_device.h
+#includeplat/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.
+*/
As written in the errata document: Unique reference to be used for
communication, Errata ID: i479. You should not use 1.166.
Also the description is a little bit different:
idle_req / idle_ack mechanism potentially broken when autoidle is enabled.
OK, it looks like it can occur randomly during run time, meaning that
potentially can be probably removed.
In that case, what is the point of the previous patch that separate
smartidle and autoidle modification?
+ if (cpu_is_omap3430())
+ oh-flags |= HWMOD_NO_OCP_AUTOIDLE;
You should not access omap_hwmod structure from here and moreover the
flags attribute is a not supposed to be changed dynamically. It is
reflecting the capability of the hwmod and should considered as a constant.
For that kind of fix, you just have to modified the omap3 hwmod data file.
+
+ 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 =
[PATCH 0/5] Convert I2C driver to use omap_device/runtime PM
Hi, This series makes I2C device registration use hwmod and omap_device api's and converts the I2C driver to use runtime PM api's. Patches apply on the pm-wip/hwmods-omap4 branch from Kevin's tree. Patches are tested on OMAP3 and OMAP4 SDP platforms. regards, Rajendra Paul Walmsley (2): OMAP2xxx: hwmod: add I2C hwmods for OMAP2420, 2430 OMAP: I2C: split device registration; convert OMAP2+ to omap_device Rajendra Nayak (3): OMAP4: runtime: Enable PM runtime core for OMAP4 OMAP3: hwmod: add I2C hwmods for OMAP3430 OMAP: I2C: Convert i2c driver to use PM runtime api's -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] OMAP2xxx: hwmod: add I2C hwmods for OMAP2420, 2430
From: Paul Walmsley p...@pwsan.com
Add hwmod structures for I2C controllers on OMAP2420/2430.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 134 ++-
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 140 +++-
2 files changed, 270 insertions(+), 4 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..892e733 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -15,9 +15,12 @@
#include mach/irqs.h
#include plat/cpu.h
#include plat/dma.h
+#include plat/i2c.h
+#include plat/omap24xx.h
#include omap_hwmod_common_data.h
+#include cm-regbits-24xx.h
#include prm-regbits-24xx.h
/*
@@ -71,6 +74,8 @@ static struct omap_hwmod omap2420_l3_main_hwmod = {
};
static struct omap_hwmod omap2420_l4_wkup_hwmod;
+static struct omap_hwmod omap2420_i2c1_hwmod;
+static struct omap_hwmod omap2420_i2c2_hwmod;
/* L4_CORE - L4_WKUP interface */
static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
@@ -79,6 +84,45 @@ static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* I2C IP block address space length (in bytes) */
+#define OMAP2_I2C_AS_LEN 128
+
+/* L4 CORE - I2C1 interface */
+static struct omap_hwmod_addr_space omap2420_i2c1_addr_space[] = {
+ {
+ .pa_start = 0x4807,
+ .pa_end = 0x4807 + OMAP2_I2C_AS_LEN - 1,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_core__i2c1 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_i2c1_hwmod,
+ .clk= i2c1_ick,
+ .addr = omap2420_i2c1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_i2c1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 CORE - I2C2 interface */
+static struct omap_hwmod_addr_space omap2420_i2c2_addr_space[] = {
+ {
+ .pa_start = 0x48072000,
+ .pa_end = 0x48072000 + OMAP2_I2C_AS_LEN - 1,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_core__i2c2 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_i2c2_hwmod,
+ .clk= i2c2_ick,
+ .addr = omap2420_i2c2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_i2c2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* Slave interfaces on the L4_CORE interconnect */
static struct omap_hwmod_ocp_if *omap2420_l4_core_slaves[] = {
omap2420_l3_main__l4_core,
@@ -87,6 +131,8 @@ static struct omap_hwmod_ocp_if *omap2420_l4_core_slaves[] =
{
/* Master interfaces on the L4_CORE interconnect */
static struct omap_hwmod_ocp_if *omap2420_l4_core_masters[] = {
omap2420_l4_core__l4_wkup,
+ omap2420_l4_core__i2c1,
+ omap2420_l4_core__i2c2
};
/* L4 CORE */
@@ -165,6 +211,92 @@ static struct omap_hwmod omap2420_iva_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
};
+/* I2C common */
+static struct omap_hwmod_class_sysconfig i2c_sysc = {
+ .rev_offs = 0x00,
+ .sysc_offs = 0x20,
+ .syss_offs = 0x10,
+ .sysc_flags = SYSC_HAS_SOFTRESET,
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class i2c_class = {
+ .name = i2c,
+ .sysc = i2c_sysc,
+};
+
+static struct omap_i2c_dev_attr i2c_dev_attr;
+
+/* I2C1 */
+
+static struct omap_hwmod_irq_info i2c1_mpu_irqs[] = {
+ { .irq = INT_24XX_I2C1_IRQ, },
+};
+
+static struct omap_hwmod_dma_info i2c1_sdma_chs[] = {
+ { .name = tx, .dma_ch = OMAP24XX_DMA_I2C1_TX },
+ { .name = rx, .dma_ch = OMAP24XX_DMA_I2C1_RX },
+};
+
+static struct omap_hwmod_ocp_if *omap2420_i2c1_slaves[] = {
+ omap2420_l4_core__i2c1,
+};
+
+static struct omap_hwmod omap2420_i2c1_hwmod = {
+ .name = i2c1,
+ .mpu_irqs = i2c1_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(i2c1_mpu_irqs),
+ .sdma_chs = i2c1_sdma_chs,
+ .sdma_chs_cnt = ARRAY_SIZE(i2c1_sdma_chs),
+ .main_clk = i2c1_fck,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP2420_EN_I2C1_SHIFT,
+ },
+ },
+ .slaves = omap2420_i2c1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_i2c1_slaves),
+ .class = i2c_class,
+ .dev_attr = i2c_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+};
+
+/* I2C2 */
+
+static struct
[PATCH 3/5] OMAP3: hwmod: add I2C hwmods for OMAP3430
Add hwmod structures for I2C controllers on OMAP3430.
This patch was developed in collaboration with Paul Walmsley p...@pwsan.com.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 232
arch/arm/mach-omap2/prm-regbits-34xx.h |3 +
arch/arm/plat-omap/include/plat/i2c.h | 13 ++
arch/arm/plat-omap/include/plat/l4_3xxx.h | 24 +++
4 files changed, 272 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/l4_3xxx.h
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5d8eb58..7ef093f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -17,6 +17,9 @@
#include mach/irqs.h
#include plat/cpu.h
#include plat/dma.h
+#include plat/l4_3xxx.h
+#include plat/i2c.h
+#include plat/omap34xx.h
#include omap_hwmod_common_data.h
@@ -36,6 +39,9 @@ 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_i2c1_hwmod;
+static struct omap_hwmod omap3xxx_i2c2_hwmod;
+static struct omap_hwmod omap3xxx_i2c3_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -90,6 +96,85 @@ static struct omap_hwmod_ocp_if omap3xxx_l4_core__l4_wkup = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+
+/* I2C IP block address space length (in bytes) */
+#define OMAP2_I2C_AS_LEN 128
+
+/* L4 CORE - I2C1 interface */
+static struct omap_hwmod_addr_space omap3xxx_i2c1_addr_space[] = {
+ {
+ .pa_start = 0x4807,
+ .pa_end = 0x4807 + OMAP2_I2C_AS_LEN - 1,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3_l4_core__i2c1 = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_i2c1_hwmod,
+ .clk= i2c1_ick,
+ .addr = omap3xxx_i2c1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_i2c1_addr_space),
+ .fw = {
+ .omap2 = {
+ .l4_fw_region = OMAP3_L4_CORE_FW_I2C1_REGION,
+ .l4_prot_group = 7,
+ .flags = OMAP_FIREWALL_L4,
+ }
+ },
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 CORE - I2C2 interface */
+static struct omap_hwmod_addr_space omap3xxx_i2c2_addr_space[] = {
+ {
+ .pa_start = 0x48072000,
+ .pa_end = 0x48072000 + OMAP2_I2C_AS_LEN - 1,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3_l4_core__i2c2 = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_i2c2_hwmod,
+ .clk= i2c2_ick,
+ .addr = omap3xxx_i2c2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_i2c2_addr_space),
+ .fw = {
+ .omap2 = {
+ .l4_fw_region = OMAP3_L4_CORE_FW_I2C2_REGION,
+ .l4_prot_group = 7,
+ .flags = OMAP_FIREWALL_L4,
+ }
+ },
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 CORE - I2C3 interface */
+static struct omap_hwmod_addr_space omap3xxx_i2c3_addr_space[] = {
+ {
+ .pa_start = 0x4806,
+ .pa_end = 0x4806 + OMAP2_I2C_AS_LEN - 1,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3_l4_core__i2c3 = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_i2c3_hwmod,
+ .clk= i2c3_ick,
+ .addr = omap3xxx_i2c3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_i2c3_addr_space),
+ .fw = {
+ .omap2 = {
+ .l4_fw_region = OMAP3_L4_CORE_FW_I2C3_REGION,
+ .l4_prot_group = 7,
+ .flags = OMAP_FIREWALL_L4,
+ }
+ },
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* Slave interfaces on the L4_CORE interconnect */
static struct omap_hwmod_ocp_if *omap3xxx_l4_core_slaves[] = {
omap3xxx_l3_main__l4_core,
@@ -98,6 +183,9 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_core_slaves[] =
{
/* Master interfaces on the L4_CORE interconnect */
static struct omap_hwmod_ocp_if *omap3xxx_l4_core_masters[] = {
omap3xxx_l4_core__l4_wkup,
+ omap3_l4_core__i2c1,
+ omap3_l4_core__i2c2,
+ omap3_l4_core__i2c3,
};
/* L4 CORE */
@@ -197,6 +285,147 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
[PATCH 4/5] OMAP: I2C: split device registration; convert OMAP2+ to omap_device
From: Paul Walmsley p...@pwsan.com
Split the OMAP1 and OMAP2+ platform_device build and register code.
Convert the OMAP2+ variant to use omap_device.
This patch was developed in collaboration with Rajendra Nayak
rna...@ti.com.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/i2c.c | 161 +-
include/linux/i2c-omap.h |5 ++
2 files changed, 93 insertions(+), 73 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a5ce4f0..f58b425 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -27,18 +27,18 @@
#include linux/platform_device.h
#include linux/i2c.h
#include linux/i2c-omap.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/clk.h
#include mach/irqs.h
#include plat/mux.h
#include plat/i2c.h
#include plat/omap-pm.h
+#include plat/omap_device.h
#define OMAP_I2C_SIZE 0x3f
#define OMAP1_I2C_BASE 0xfffb3800
-#define OMAP2_I2C_BASE10x4807
-#define OMAP2_I2C_BASE20x48072000
-#define OMAP2_I2C_BASE30x4806
-#define OMAP4_I2C_BASE40x4835
static const char name[] = i2c_omap;
@@ -55,15 +55,6 @@ static const char name[] = i2c_omap;
static struct resource i2c_resources[][2] = {
{ I2C_RESOURCE_BUILDER(0, 0) },
-#ifdefined(CONFIG_ARCH_OMAP2PLUS)
- { I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE2, 0) },
-#endif
-#ifdefined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
- { I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE3, 0) },
-#endif
-#ifdefined(CONFIG_ARCH_OMAP4)
- { I2C_RESOURCE_BUILDER(OMAP4_I2C_BASE4, 0) },
-#endif
};
#define I2C_DEV_BUILDER(bus_id, res, data) \
@@ -77,22 +68,19 @@ static struct resource i2c_resources[][2] = {
}, \
}
-static struct omap_i2c_bus_platform_data i2c_pdata[ARRAY_SIZE(i2c_resources)];
+#define MAX_OMAP_I2C_HWMOD_NAME_LEN16
+#define OMAP_I2C_MAX_CONTROLLERS 4
+static struct omap_i2c_bus_platform_data i2c_pdata[OMAP_I2C_MAX_CONTROLLERS];
static struct platform_device omap_i2c_devices[] = {
I2C_DEV_BUILDER(1, i2c_resources[0], i2c_pdata[0]),
-#ifdefined(CONFIG_ARCH_OMAP2PLUS)
- I2C_DEV_BUILDER(2, i2c_resources[1], i2c_pdata[1]),
-#endif
-#ifdefined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
- I2C_DEV_BUILDER(3, i2c_resources[2], i2c_pdata[2]),
-#endif
-#ifdefined(CONFIG_ARCH_OMAP4)
- I2C_DEV_BUILDER(4, i2c_resources[3], i2c_pdata[3]),
-#endif
};
#define OMAP_I2C_CMDLINE_SETUP (BIT(31))
+#define I2C_ICLK 0
+#define I2C_FCLK 1
+static struct clk *omap_i2c_clks[ARRAY_SIZE(omap_i2c_devices)][2];
+
static int __init omap_i2c_nr_ports(void)
{
int ports = 0;
@@ -109,35 +97,57 @@ static int __init omap_i2c_nr_ports(void)
return ports;
}
-/* Shared between omap2 and 3 */
-static resource_size_t omap2_i2c_irq[3] __initdata = {
- INT_24XX_I2C1_IRQ,
- INT_24XX_I2C2_IRQ,
- INT_34XX_I2C3_IRQ,
-};
+static int omap1_i2c_device_enable(struct platform_device *pdev)
+{
+ struct clk *c;
+ c = omap_i2c_clks[pdev-id - 1][I2C_ICLK];
+ if (c !IS_ERR(c))
+ clk_enable(c);
-static resource_size_t omap4_i2c_irq[4] __initdata = {
- OMAP44XX_IRQ_I2C1,
- OMAP44XX_IRQ_I2C2,
- OMAP44XX_IRQ_I2C3,
- OMAP44XX_IRQ_I2C4,
-};
+ c = omap_i2c_clks[pdev-id - 1][I2C_FCLK];
+ if (c !IS_ERR(c))
+ clk_enable(c);
+
+ return 0;
+}
+
+static int omap1_i2c_device_idle(struct platform_device *pdev)
+{
+ struct clk *c;
+
+ c = omap_i2c_clks[pdev-id - 1][I2C_FCLK];
+ if (c !IS_ERR(c))
+ clk_disable(c);
-static inline int omap1_i2c_add_bus(struct platform_device *pdev, int bus_id)
+ c = omap_i2c_clks[pdev-id - 1][I2C_ICLK];
+ if (c !IS_ERR(c))
+ clk_disable(c);
+
+ return 0;
+}
+
+static inline int omap1_i2c_add_bus(int bus_id)
{
- struct omap_i2c_bus_platform_data *pd;
- struct resource *res;
-
- pd = pdev-dev.platform_data;
- res = pdev-resource;
- res[0].start = OMAP1_I2C_BASE;
- res[0].end = res[0].start + OMAP_I2C_SIZE;
- res[1].start = INT_I2C;
+ struct platform_device *pdev;
+ struct omap_i2c_bus_platform_data *pdata;
+
omap1_i2c_mux_pins(bus_id);
+ pdev = omap_i2c_devices[bus_id - 1];
+ pdata = i2c_pdata[bus_id - 1];
+
+ /* idle and shutdown share the same code */
+ pdata-device_enable = omap1_i2c_device_enable;
+ pdata-device_idle = omap1_i2c_device_idle;
+ pdata-device_shutdown = omap1_i2c_device_idle;
+
+ omap_i2c_clks[bus_id - 1][I2C_ICLK] = clk_get(pdev-dev, ick);
+ omap_i2c_clks[bus_id - 1][I2C_FCLK] = clk_get(pdev-dev, fck);
+
[PATCH 5/5] OMAP: I2C: Convert i2c driver to use PM runtime api's
This patch converts the i2c driver to use PM runtime apis for OMAP2+
and omap_device api's for OMAP1
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
---
drivers/i2c/busses/i2c-omap.c | 81 ++---
1 files changed, 35 insertions(+), 46 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 7674efb..387f9c6 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -39,6 +39,7 @@
#include linux/io.h
#include linux/slab.h
#include linux/i2c-omap.h
+#include linux/pm_runtime.h
/* I2C controller revisions */
#define OMAP_I2C_REV_2 0x20
@@ -175,8 +176,6 @@ struct omap_i2c_dev {
void __iomem*base; /* virtual */
int irq;
int reg_shift; /* bit shift for I2C register
addresses */
- struct clk *iclk; /* Interface clock */
- struct clk *fclk; /* Functional clock */
struct completion cmd_complete;
struct resource *ioarea;
u32 latency;/* maximum mpu wkup latency */
@@ -265,45 +264,25 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
(i2c_dev-regs[reg] i2c_dev-reg_shift));
}
-static int __init omap_i2c_get_clocks(struct omap_i2c_dev *dev)
+static void omap_i2c_unidle(struct omap_i2c_dev *dev)
{
- int ret;
-
- dev-iclk = clk_get(dev-dev, ick);
- if (IS_ERR(dev-iclk)) {
- ret = PTR_ERR(dev-iclk);
- dev-iclk = NULL;
- return ret;
- }
-
- dev-fclk = clk_get(dev-dev, fck);
- if (IS_ERR(dev-fclk)) {
- ret = PTR_ERR(dev-fclk);
- if (dev-iclk != NULL) {
- clk_put(dev-iclk);
- dev-iclk = NULL;
- }
- dev-fclk = NULL;
- return ret;
- }
+ struct platform_device *pdev;
+ struct omap_i2c_bus_platform_data *pdata;
- return 0;
-}
+ WARN_ON(!dev-idle);
-static void omap_i2c_put_clocks(struct omap_i2c_dev *dev)
-{
- clk_put(dev-fclk);
- dev-fclk = NULL;
- clk_put(dev-iclk);
- dev-iclk = NULL;
-}
+ pdev = container_of(dev-dev, struct platform_device, dev);
+ pdata = pdev-dev.platform_data;
-static void omap_i2c_unidle(struct omap_i2c_dev *dev)
-{
- WARN_ON(!dev-idle);
+ pm_runtime_get_sync(pdev-dev);
+ /*
+* This is needed for now to have OMAP1
+* working as PM runtime is not yet
+* supported on OMAP1
+*/
+ if (pdata-device_enable)
+ pdata-device_enable(pdev);
- clk_enable(dev-iclk);
- clk_enable(dev-fclk);
if (cpu_is_omap34xx()) {
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
@@ -326,10 +305,15 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
static void omap_i2c_idle(struct omap_i2c_dev *dev)
{
+ struct platform_device *pdev;
+ struct omap_i2c_bus_platform_data *pdata;
u16 iv;
WARN_ON(dev-idle);
+ pdev = container_of(dev-dev, struct platform_device, dev);
+ pdata = pdev-dev.platform_data;
+
dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
if (dev-rev = OMAP_I2C_REV_ON_4430)
omap_i2c_write_reg(dev, OMAP_I2C_IRQENABLE_CLR, 1);
@@ -345,8 +329,15 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
}
dev-idle = 1;
- clk_disable(dev-fclk);
- clk_disable(dev-iclk);
+
+ pm_runtime_put_sync(pdev-dev);
+ /*
+* This is needed for now to have OMAP1
+* working as PM runtime is not yet
+* supported on OMAP1
+*/
+ if (pdata-device_idle)
+ pdata-device_idle(pdev);
}
static int omap_i2c_init(struct omap_i2c_dev *dev)
@@ -356,6 +347,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
unsigned long fclk_rate = 1200;
unsigned long timeout;
unsigned long internal_clk = 0;
+ struct clk *fclk;
if (dev-rev = OMAP_I2C_REV_2) {
/* Disable I2C controller before soft reset */
@@ -414,7 +406,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
* always returns 12MHz for the functional clock, we can
* do this bit unconditionally.
*/
- fclk_rate = clk_get_rate(dev-fclk);
+ fclk = clk_get(dev-dev, fck);
+ fclk_rate = clk_get_rate(fclk);
/* TRM for 5912 says the I2C clock must be prescaled to be
* between 7 - 12 MHz. The XOR
[PATCH 1/5] OMAP4: runtime: Enable PM runtime core for OMAP4
The PM runtime core functions are implemented in pm_bus.c which needs to be compiled for CONFIG_ARCH_OMAP4 for runtime api's to work. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 800b430..18db759 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -50,7 +50,7 @@ ifeq ($(CONFIG_PM),y) obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o pm_bus.o -obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o +obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o AFLAGS_sleep24xx.o :=-Wa,-march=armv6 -- 1.5.4.7 -- 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/8] : Hwmod api changes
On 8/9/2010 11:37 AM, Nayak, Rajendra wrote: From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, August 09, 2010 1:51 PM (cc Benoît) On Mon, 9 Aug 2010, Nayak, Rajendra wrote: Does it make sense for the framework itself to enable wakeup for all devices when the slave port is programmed to be in Smartidle It seems to me that they are separate mechanisms? If a module is programmed for slave smart-idle, then the module prevents the PRCM from shutting off the module clock(s) until the module is not busy. This seems distinct from ENAWAKEUP, which I thought simply controlled whether the module would assert the SWakeup signal to the PRCM when an external wakeup condition occurred for that module. Is that an accurate summary? hmm.. the reason I thought the two were related was because the need to assert a SWakeup will arise only when the module is programmed in smart-idle. If the module is either in no-idle (in which case no idle-ack is asserted by the module) or force-idle (when the module is forced to idle and expected to stay idle) there might not be a need for the module to be capable of asserting a SWakeup. In fact, the SWakeup is asserted as soon as the module is in idle (idle_ack = 1) and cannot use the OCP interface to communicate a IRQ_REQ or DMA_REQ. But the wakeup capability is disabled by setting the SidleMode to Force-Idle, regardless of the value of Wakeup enable. Bottom-line is that the SWakeup can be asserted only if the module is in smart-idle. The reason I proposed ENAWAKEUP to be always enabled with smart-idle was with as understanding that we may never have a case wherein the module is programmed in smart-idle but not expected to assert SWakeup (if it supports one). I will check up on this if there ever could be such a case. This is something that can make sense on OMAP4, because the wakeup status is de-asserted automatically as soon as the interrupt status is cleared. On previous platform, as Paul said, we will have to handle that manually somewhere, but preferably not in driver directly. It will not be that straightforward. instead of exposing 2 more omap device level api;s to the drivers? Something like this probably needs to be exposed to core code that would also set/clear PM_WKEN_* for the appropriate processor module. Right now we just set a bunch of these bits directly in pm.c, and that needs to change. The other issue is that I suspct the module needs to be enabled in order for SYSCONFIG writes to succeed; right now the underlying hwmod code does not appear to enforce this :-( At least we have a comment saying that we should do it :-) We probably just need to ensure that a module is enabled before accessing the sysconfig. Regards, Benoit But I don't see why drivers would need to call these functions directly. Hema, was that your intention? If so, you could you please explain the use case? I have a patch for this and can post it for review in case you feel it makes sense. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issues with calling pm_runtime functions in platform_pm_suspend_noirq/IRQ disabled context.
Basak, Partha p-bas...@ti.com writes:
Finally, we have omap_sram_idle():
In particular, for USB, while executing SRAM_Idle, is we use pm_runtime
functions, we see spurious IO-Pad interrupts.
Your message doesn't specify what PM runtime functions you are executing.
But if those functions are calling mutex_lock(), then they obviously must
not be called from omap_sram_idle() in interrupt context.
It's not clear from your message why you need to call PM runtime functions
from the idle loop. I'd suggest that you post the problematic code in
question to the list.
USB issue:
Please refer to the USB patch attached (will be sent to the list as well in a
few minutes)
As I mentioned previously, few drivers like GPIO, USB UART have clock-
disable/enable + context save/restore in Idle path(omap_sram_idle()).
In particular, I am referring to calling of the functions
pm_runtime_put_sync() pm_runtime_get_sync() for USB around wfi.
Now, the following call sequence from omap_sram_idle()will enable IRQs:
pm_runtime_put_sync--
__pm_runtime_put--
pm_runtime_idle--
spin_unlock_irq(),
__pm_runtime_idle(),--
spin_unlock_irq,
spin_unlock_irq
The functions pm_runtime_idle() __ pm_runtime_idle() do not use
spin_lock_irqsave spin_unlock_irqrestore. This leads to enabling of
the interrupts in omap_sram_idle unconditionally, which for USB in
particular is leading to IO-pad interrupt being triggered which does
not come otherwise.
You seem to have correctly identified the problem. Can you try the
patch below (untested) which attempts to address the root cause you've
identified?
Kevin
To work around this problem, instead of using Runtime APIs, we are using
omap_device_enable/disable, which in-turn call to __omap_hwmod_enable/idle
Simply put, I am not talking about grabbing a mutex when interrupts are
disabled, rather of a scenario where interrupts are getting enabled as a
side-effect of calling these functions in omap_sram_idle().
From be3aeea5f8d29c8ce2fa278f48aef849eb682282 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@deeprootsystems.com
Date: Mon, 9 Aug 2010 08:12:39 -0700
Subject: [PATCH] PM: allow runtime PM get/put from interrupts-disabled context
When using runtime PM in combination with CPUidle, the runtime PM
transtions of some devices may be triggered during the idle path.
Late in the idle sequence, interrupts may already be disabled when
runtime PM for these devices is initiated (using the _sync versions of
the runtime PM API.)
Currently, the runtime PM core assumes methods are called with
interrupts enabled. However, if it is called with interrupts
disabled, the internal locking unconditionally enables interrupts, for
example:
pm_runtime_put_sync()
__pm_runtime_put()
pm_runtime_idle()
spin_lock_irq()
__pm_runtime_idle()
spin_unlock_irq() --- interrupts unconditionally enabled
dev-bus-pm-runtime_idle()
spin_lock_irq()
spin_unlock_irq()
To fix, use the save/restore versions of the spinlock API.
Reported-by: Partha Basak p-bas...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
drivers/base/power/runtime.c | 68 ++---
include/linux/pm.h |1 +
2 files changed, 37 insertions(+), 32 deletions(-)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index b0ec0e9..b02ef35 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -80,24 +80,24 @@ static int __pm_runtime_idle(struct device *dev)
dev-power.idle_notification = true;
if (dev-bus dev-bus-pm dev-bus-pm-runtime_idle) {
- spin_unlock_irq(dev-power.lock);
+ spin_unlock_irqrestore(dev-power.lock, dev-power.lock_flags);
dev-bus-pm-runtime_idle(dev);
- spin_lock_irq(dev-power.lock);
+ spin_lock_irqsave(dev-power.lock, dev-power.lock_flags);
} else if (dev-type dev-type-pm dev-type-pm-runtime_idle) {
- spin_unlock_irq(dev-power.lock);
+ spin_unlock_irqrestore(dev-power.lock, dev-power.lock_flags);
dev-type-pm-runtime_idle(dev);
- spin_lock_irq(dev-power.lock);
+ spin_lock_irqsave(dev-power.lock, dev-power.lock_flags);
} else if (dev-class dev-class-pm
dev-class-pm-runtime_idle) {
- spin_unlock_irq(dev-power.lock);
+ spin_unlock_irqrestore(dev-power.lock, dev-power.lock_flags);
dev-class-pm-runtime_idle(dev);
- spin_lock_irq(dev-power.lock);
+ spin_lock_irqsave(dev-power.lock, dev-power.lock_flags);
}
dev-power.idle_notification = false;
@@ -115,9 +115,9 @@ int pm_runtime_idle(struct
RE: Issues with calling pm_runtime functions in platform_pm_suspend_noirq/IRQ disabled context.
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Monday, August 09, 2010 9:01 PM To: Basak, Partha Cc: Paul Walmsley; linux-omap@vger.kernel.org; Kalliguddi, Hema; Raja, Govindraj; Varadarajan, Charulatha Subject: Re: Issues with calling pm_runtime functions in platform_pm_suspend_noirq/IRQ disabled context. Basak, Partha p-bas...@ti.com writes: Finally, we have omap_sram_idle(): In particular, for USB, while executing SRAM_Idle, is we use pm_runtime functions, we see spurious IO-Pad interrupts. Your message doesn't specify what PM runtime functions you are executing. But if those functions are calling mutex_lock(), then they obviously must not be called from omap_sram_idle() in interrupt context. It's not clear from your message why you need to call PM runtime functions from the idle loop. I'd suggest that you post the problematic code in question to the list. USB issue: Please refer to the USB patch attached (will be sent to the list as well in a few minutes) As I mentioned previously, few drivers like GPIO, USB UART have clock- disable/enable + context save/restore in Idle path(omap_sram_idle()). In particular, I am referring to calling of the functions pm_runtime_put_sync() pm_runtime_get_sync() for USB around wfi. Now, the following call sequence from omap_sram_idle()will enable IRQs: pm_runtime_put_sync-- __pm_runtime_put-- pm_runtime_idle-- spin_unlock_irq(), __pm_runtime_idle(),-- spin_unlock_irq, spin_unlock_irq The functions pm_runtime_idle() __ pm_runtime_idle() do not use spin_lock_irqsave spin_unlock_irqrestore. This leads to enabling of the interrupts in omap_sram_idle unconditionally, which for USB in particular is leading to IO-pad interrupt being triggered which does not come otherwise. You seem to have correctly identified the problem. Can you try the patch below (untested) which attempts to address the root cause you've identified? Kevin To work around this problem, instead of using Runtime APIs, we are using omap_device_enable/disable, which in-turn call to __omap_hwmod_enable/idle Simply put, I am not talking about grabbing a mutex when interrupts are disabled, rather of a scenario where interrupts are getting enabled as a side-effect of calling these functions in omap_sram_idle(). From be3aeea5f8d29c8ce2fa278f48aef849eb682282 Mon Sep 17 00:00:00 2001 From: Kevin Hilman khil...@deeprootsystems.com Date: Mon, 9 Aug 2010 08:12:39 -0700 Subject: [PATCH] PM: allow runtime PM get/put from interrupts-disabled context When using runtime PM in combination with CPUidle, the runtime PM transtions of some devices may be triggered during the idle path. Late in the idle sequence, interrupts may already be disabled when runtime PM for these devices is initiated (using the _sync versions of the runtime PM API.) Currently, the runtime PM core assumes methods are called with interrupts enabled. However, if it is called with interrupts disabled, the internal locking unconditionally enables interrupts, for example: pm_runtime_put_sync() __pm_runtime_put() pm_runtime_idle() spin_lock_irq() __pm_runtime_idle() spin_unlock_irq() --- interrupts unconditionally enabled dev-bus-pm-runtime_idle() spin_lock_irq() spin_unlock_irq() To fix, use the save/restore versions of the spinlock API. Similar thing was thought when this problem was encountered but there was a concern that it may lead to interrupts are being disable for longer times Are all run time PM APIs are short enough to keep interrupts disabled without impacting interrupt latency? -- 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
Aguirre, Sergio wrote: 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 Hi Sergio, Thanks for the helpful reply. Can you also clarify for me the difference between omap3camera and your linux-omap-camera (http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary) repositories? I assume this development has mainly happened on the board-rx51* platform? Ultimately I want to get raw sensor data to memory. Do you foresee any problems doing that with the current state of omap3camera? Might I be better off going with a kernel with v4l2_int_device at first? 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.
Shilimkar, Santosh santosh.shilim...@ti.com writes: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Monday, August 09, 2010 9:01 PM To: Basak, Partha Cc: Paul Walmsley; linux-omap@vger.kernel.org; Kalliguddi, Hema; Raja, Govindraj; Varadarajan, Charulatha Subject: Re: Issues with calling pm_runtime functions in platform_pm_suspend_noirq/IRQ disabled context. Basak, Partha p-bas...@ti.com writes: Finally, we have omap_sram_idle(): In particular, for USB, while executing SRAM_Idle, is we use pm_runtime functions, we see spurious IO-Pad interrupts. Your message doesn't specify what PM runtime functions you are executing. But if those functions are calling mutex_lock(), then they obviously must not be called from omap_sram_idle() in interrupt context. It's not clear from your message why you need to call PM runtime functions from the idle loop. I'd suggest that you post the problematic code in question to the list. USB issue: Please refer to the USB patch attached (will be sent to the list as well in a few minutes) As I mentioned previously, few drivers like GPIO, USB UART have clock- disable/enable + context save/restore in Idle path(omap_sram_idle()). In particular, I am referring to calling of the functions pm_runtime_put_sync() pm_runtime_get_sync() for USB around wfi. Now, the following call sequence from omap_sram_idle()will enable IRQs: pm_runtime_put_sync-- __pm_runtime_put-- pm_runtime_idle-- spin_unlock_irq(), __pm_runtime_idle(),-- spin_unlock_irq, spin_unlock_irq The functions pm_runtime_idle() __ pm_runtime_idle() do not use spin_lock_irqsave spin_unlock_irqrestore. This leads to enabling of the interrupts in omap_sram_idle unconditionally, which for USB in particular is leading to IO-pad interrupt being triggered which does not come otherwise. You seem to have correctly identified the problem. Can you try the patch below (untested) which attempts to address the root cause you've identified? Kevin To work around this problem, instead of using Runtime APIs, we are using omap_device_enable/disable, which in-turn call to __omap_hwmod_enable/idle Simply put, I am not talking about grabbing a mutex when interrupts are disabled, rather of a scenario where interrupts are getting enabled as a side-effect of calling these functions in omap_sram_idle(). From be3aeea5f8d29c8ce2fa278f48aef849eb682282 Mon Sep 17 00:00:00 2001 From: Kevin Hilman khil...@deeprootsystems.com Date: Mon, 9 Aug 2010 08:12:39 -0700 Subject: [PATCH] PM: allow runtime PM get/put from interrupts-disabled context When using runtime PM in combination with CPUidle, the runtime PM transtions of some devices may be triggered during the idle path. Late in the idle sequence, interrupts may already be disabled when runtime PM for these devices is initiated (using the _sync versions of the runtime PM API.) Currently, the runtime PM core assumes methods are called with interrupts enabled. However, if it is called with interrupts disabled, the internal locking unconditionally enables interrupts, for example: pm_runtime_put_sync() __pm_runtime_put() pm_runtime_idle() spin_lock_irq() __pm_runtime_idle() spin_unlock_irq() --- interrupts unconditionally enabled dev-bus-pm-runtime_idle() spin_lock_irq() spin_unlock_irq() To fix, use the save/restore versions of the spinlock API. Similar thing was thought when this problem was encountered but there was a concern that it may lead to interrupts are being disable for longer times why? if interrupts are enabled when this API is used, this patch doesn't change the amount of time interrupts are disabled. if interrupts are already disabled, then you *want* interrupts to be disabled for the entire time. what exactly is the concern? Kevin Are all run time PM APIs are short enough to keep interrupts disabled without impacting interrupt latency? -- 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: Monday, August 09, 2010 9:25 PM
To: Shilimkar, Santosh
Cc: Basak, Partha; Paul Walmsley; linux-omap@vger.kernel.org; Kalliguddi,
Hema; Raja, Govindraj; Varadarajan, Charulatha
Subject: Re: Issues with calling pm_runtime functions in
platform_pm_suspend_noirq/IRQ disabled context.
Shilimkar, Santosh santosh.shilim...@ti.com writes:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Sent: Monday, August 09, 2010 9:01 PM
To: Basak, Partha
Cc: Paul Walmsley; linux-omap@vger.kernel.org; Kalliguddi, Hema; Raja,
Govindraj; Varadarajan, Charulatha
Subject: Re: Issues with calling pm_runtime functions in
platform_pm_suspend_noirq/IRQ disabled context.
Basak, Partha p-bas...@ti.com writes:
Finally, we have omap_sram_idle():
In particular, for USB, while executing SRAM_Idle, is we use
pm_runtime
functions, we see spurious IO-Pad interrupts.
Your message doesn't specify what PM runtime functions you are
executing.
But if those functions are calling mutex_lock(), then they obviously
must
not be called from omap_sram_idle() in interrupt context.
It's not clear from your message why you need to call PM runtime
functions
from the idle loop. I'd suggest that you post the problematic code
in
question to the list.
USB issue:
Please refer to the USB patch attached (will be sent to the list as
well
in a few minutes)
As I mentioned previously, few drivers like GPIO, USB UART have
clock-
disable/enable + context save/restore in Idle path(omap_sram_idle()).
In particular, I am referring to calling of the functions
pm_runtime_put_sync() pm_runtime_get_sync() for USB around wfi.
Now, the following call sequence from omap_sram_idle()will enable
IRQs:
pm_runtime_put_sync--
__pm_runtime_put--
pm_runtime_idle--
spin_unlock_irq(),
__pm_runtime_idle(),--
spin_unlock_irq,
spin_unlock_irq
The functions pm_runtime_idle() __ pm_runtime_idle() do not use
spin_lock_irqsave spin_unlock_irqrestore. This leads to enabling of
the interrupts in omap_sram_idle unconditionally, which for USB in
particular is leading to IO-pad interrupt being triggered which does
not come otherwise.
You seem to have correctly identified the problem. Can you try the
patch below (untested) which attempts to address the root cause you've
identified?
Kevin
To work around this problem, instead of using Runtime APIs, we are
using
omap_device_enable/disable, which in-turn call to
__omap_hwmod_enable/idle
Simply put, I am not talking about grabbing a mutex when interrupts
are
disabled, rather of a scenario where interrupts are getting enabled as
a
side-effect of calling these functions in omap_sram_idle().
From be3aeea5f8d29c8ce2fa278f48aef849eb682282 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@deeprootsystems.com
Date: Mon, 9 Aug 2010 08:12:39 -0700
Subject: [PATCH] PM: allow runtime PM get/put from interrupts-disabled
context
When using runtime PM in combination with CPUidle, the runtime PM
transtions of some devices may be triggered during the idle path.
Late in the idle sequence, interrupts may already be disabled when
runtime PM for these devices is initiated (using the _sync versions of
the runtime PM API.)
Currently, the runtime PM core assumes methods are called with
interrupts enabled. However, if it is called with interrupts
disabled, the internal locking unconditionally enables interrupts, for
example:
pm_runtime_put_sync()
__pm_runtime_put()
pm_runtime_idle()
spin_lock_irq()
__pm_runtime_idle()
spin_unlock_irq() --- interrupts unconditionally
enabled
dev-bus-pm-runtime_idle()
spin_lock_irq()
spin_unlock_irq()
To fix, use the save/restore versions of the spinlock API.
Similar thing was thought when this problem was encountered but
there was a concern that it may lead to interrupts are being disable
for longer times
why?
if interrupts are enabled when this API is used, this patch doesn't
change the amount of time interrupts are disabled.
if interrupts are already disabled, then you *want* interrupts to be
disabled for the entire time.
Correct me if I am off the track here.
If these API's are _always_ called with interrupt disabled then probably we
don't even need the new spinlock version locking.
Considering the API is called with interrupt enabled.
int pm_runtime_suspend(struct device *dev)
{
int retval;
spin_lock_irqsave(dev-power.lock, dev-power.lock_flags);
retval = __pm_runtime_suspend(dev,
RE: Issues with calling pm_runtime functions in platform_pm_suspend_noirq/IRQ disabled context.
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh
Sent: Monday, August 09, 2010 9:43 PM
To: Kevin Hilman
Cc: Basak, Partha; Paul Walmsley; linux-omap@vger.kernel.org; Kalliguddi,
Hema; Raja, Govindraj; Varadarajan, Charulatha
Subject: RE: Issues with calling pm_runtime functions in
platform_pm_suspend_noirq/IRQ disabled context.
[Snip]
pm_runtime_put_sync()
__pm_runtime_put()
pm_runtime_idle()
spin_lock_irq()
__pm_runtime_idle()
spin_unlock_irq() --- interrupts unconditionally
enabled
dev-bus-pm-runtime_idle()
spin_lock_irq()
spin_unlock_irq()
To fix, use the save/restore versions of the spinlock API.
Similar thing was thought when this problem was encountered but
there was a concern that it may lead to interrupts are being disable
for longer times
why?
if interrupts are enabled when this API is used, this patch doesn't
change the amount of time interrupts are disabled.
if interrupts are already disabled, then you *want* interrupts to be
disabled for the entire time.
Correct me if I am off the track here.
If these API's are _always_ called with interrupt disabled then probably
we don't even need the new spinlock version locking.
Considering the API is called with interrupt enabled.
int pm_runtime_suspend(struct device *dev)
{
int retval;
spin_lock_irqsave(dev-power.lock, dev-power.lock_flags);
retval = __pm_runtime_suspend(dev, false);
spin_unlock_irqrestore(dev-power.lock, dev-power.lock_flags);c
The interrupt on local cpu remain disabled till __pm_runtime_suspend
does its job and re-enables the interrupts. No?
Sorry Kevin for oversight. The existing used lock is already a irq version.
You are right. This change should be fine. Some how I was under impression
the existing code was using plain spin lock version.
Really sorry about the noise.
Regards,
Santosh
--
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
Hema,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Hema HK
Sent: Friday, August 06, 2010 10:57 PM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: Kalliguddi, Hema; Mankad, Maulik Ojas; Felipe Balbi; Tony Lindgren;
Kevin Hilman
Subject: [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.c2010-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);
Might be good idea to check (oh) before proceeding?
if (!oh) {
/* error message */
return;
}
+ 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.c2010-08-06
10:44:06.369863527 -0400
@@ -2427,11 +2427,6 @@
}
musb_save_context(musb);
-
- if
RE: omap3camera and linux-omap
Hi Michael, -Original Message- From: Michael Jones [mailto:michael.jo...@matrix-vision.de] Sent: Monday, August 09, 2010 10:42 AM To: Aguirre, Sergio Cc: linux-omap@vger.kernel.org; sakari.ai...@maxwell.research.nokia.com Subject: Re: omap3camera and linux-omap Aguirre, Sergio wrote: 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 Hi Sergio, Thanks for the helpful reply. Can you also clarify for me the difference between omap3camera and your linux-omap-camera (http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary) repositories? No problem. The difference is that, in my 'omap-devel' branch, you'll find: 1. Latest linux-omap master. 2. Some yet unmerged OMAP Zoom3 patches (Touchscreen, NEC LCD panel) 3. Some patches to support Beagleboard xM (OMAP3730) 4. Merged Sakari's 'devel' branch. 5. Some omap3 camera driver unmerged legacy nodes removal patches from Laurent Pinchart. 6. Some patches to add support for different RAW Patterns, which I'm still working on. 7. Sony IMX046 8MP CSI-2 Sensor driver, present in Zoom3. 8. LV8093 Lens actuator driver, present on Zoom3 and in tandem with IMX046 sensor I assume this development has mainly happened on the board-rx51* platform? Yeah, Sakari and Laurent maintain the rx51 (a.k.a. Nokia N900) camera support. Ultimately I want to get raw sensor data to memory. Do you foresee any problems doing that with the current state of omap3camera? It shouldn't be a problem, as soon as you configure the pipeline adequately. Please see this Media controller testapp, maintained by Laurent Pinchart, for help on how to do that: http://git.ideasonboard.org/?p=media-ctl.git;a=summary Might I be better off going with a kernel with v4l2_int_device at first? I won't recommend that. You probably noticed that my tree still keeps some branches with support for that old driver, but it was for some maintenance support for a code mainline for Texas Instruments. I'll definitely recommend to stick with the latest code, and most preferably base your work on Sakari's tree (i.e. gitorious.org/omap3camera tree), so we can all reference to a standard codebase. I appreciate your interest in contributing with the camera driver development, and definitely looking forward for any patches you may want to share with us. 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
Re: [PATCH 4/5] [omap1] Bluetooth device code common to HTC smartphones
On Mon, Aug 9, 2010 at 12:43 AM, Tony Lindgren t...@atomide.com wrote: * Cory Maccarrone darkstar6...@gmail.com [100808 20:22]: On Wed, Aug 4, 2010 at 3:15 AM, Tony Lindgren t...@atomide.com wrote: * Cory Maccarrone darkstar6...@gmail.com [100802 18:23]: This change adds in a bluetooth controld driver/rfkill interface to the serial bluetooth controller found on many HTC smartphones such as the HTC Herald and HTC Wizard. To me it looks like most of this should be in drivers/bluetooth/omap7xx.c or something like that. Then you can just pass it the gpio numbers in the platform_data. Not sure I agree that it fits there. The driver isn't really a bluetooth driver -- it's really just an RFKILL interface, and some code to toggle UART clocks on and off, plus GPIO work on a board-specific level. In principle, the gpios could be set and the clocks enabled in the board files, and this driver wouldn't be necessary to get working bluetooth (as we'd use hciattach on /dev/ttyS*). But then, we can't toggle it off for power saving. Maybe a better place would be plat-omap/? But it really is more specific to these HTC boards, not the architecture itself. Hmm well what we've used earlier is to set something like set_power function pointer in the platform data, then call that in the driver if set. But in this case the driver is 8250.c, so let's not mess with that.. This issue should get properly solved with the omap specific serial driver once we get that merged as then we can have hooks for set_power in addition to cutting serial clocks when idle. So really, the only point of this driver is to be able to power on and off the external bluetooth chip, which is why I submitted it as helper code to the board files. Yeah. Can you take a look at the omap specific serial driver to get it working on omap1? Then you can have your GPIO functions set in the board-*.c file as set_power or similar, and the UART driver can idle properly. I can look at it. Where is the code for that, arch/arm/mach-omap2/serial.c? - Cory -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] OMAP4: prcm: Add temporarily helper functions for rmw and read inside the PRM
Benoit Cousson b-cous...@ti.com writes:
Since OMAP4 is using an absolute address, the current PRM accessors
are not useable.
OMAP4 adaptation for these API are currently ongoing, so define temp
version until the proper ones are defined.
Curious what we're waiting for for the final versions of these?
Kevin
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/prcm.c | 24
arch/arm/plat-omap/include/plat/prcm.h |2 ++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 96f4616..d4388d3 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -216,6 +216,30 @@ u32 prm_read_mod_bits_shift(s16 domain, s16 idx, u32
mask)
return v;
}
+/* Read a PRM register, AND it, and shift the result down to bit 0 */
+u32 omap4_prm_read_bits_shift(void __iomem *reg, u32 mask)
+{
+ u32 v;
+
+ v = __raw_readl(reg);
+ v = mask;
+ v = __ffs(mask);
+
+ return v;
+}
+
+/* Read-modify-write a register in a PRM module. Caller must lock */
+u32 omap4_prm_rmw_reg_bits(u32 mask, u32 bits, void __iomem *reg)
+{
+ u32 v;
+
+ v = __raw_readl(reg);
+ v = ~mask;
+ v |= bits;
+ __raw_writel(v, reg);
+
+ return v;
+}
/* Read a register in a CM module */
u32 cm_read_mod_reg(s16 module, u16 idx)
{
diff --git a/arch/arm/plat-omap/include/plat/prcm.h
b/arch/arm/plat-omap/include/plat/prcm.h
index 9fbd914..ab77442 100644
--- a/arch/arm/plat-omap/include/plat/prcm.h
+++ b/arch/arm/plat-omap/include/plat/prcm.h
@@ -38,6 +38,8 @@ u32 prm_read_mod_reg(s16 module, u16 idx);
void prm_write_mod_reg(u32 val, s16 module, u16 idx);
u32 prm_rmw_mod_reg_bits(u32 mask, u32 bits, s16 module, s16 idx);
u32 prm_read_mod_bits_shift(s16 domain, s16 idx, u32 mask);
+u32 omap4_prm_read_bits_shift(void __iomem *reg, u32 mask);
+u32 omap4_prm_rmw_reg_bits(u32 mask, u32 bits, void __iomem *reg);
u32 cm_read_mod_reg(s16 module, u16 idx);
void cm_write_mod_reg(u32 val, s16 module, u16 idx);
u32 cm_rmw_mod_reg_bits(u32 mask, u32 bits, s16 module, s16 idx);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] OMAP4: prcm: Add temporarily helper functions for rmw and read inside the PRM
On 8/9/2010 7:30 PM, Kevin Hilman wrote:
Benoit Coussonb-cous...@ti.com writes:
Since OMAP4 is using an absolute address, the current PRM accessors
are not useable.
OMAP4 adaptation for these API are currently ongoing, so define temp
version until the proper ones are defined.
Curious what we're waiting for for the final versions of these?
That should be soon... Rajendra is working on that... among hundreds
other stuff.
Benoit
Kevin
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Kevin Hilmankhil...@deeprootsystems.com
---
arch/arm/mach-omap2/prcm.c | 24
arch/arm/plat-omap/include/plat/prcm.h |2 ++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 96f4616..d4388d3 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -216,6 +216,30 @@ u32 prm_read_mod_bits_shift(s16 domain, s16 idx, u32 mask)
return v;
}
+/* Read a PRM register, AND it, and shift the result down to bit 0 */
+u32 omap4_prm_read_bits_shift(void __iomem *reg, u32 mask)
+{
+ u32 v;
+
+ v = __raw_readl(reg);
+ v= mask;
+ v= __ffs(mask);
+
+ return v;
+}
+
+/* Read-modify-write a register in a PRM module. Caller must lock */
+u32 omap4_prm_rmw_reg_bits(u32 mask, u32 bits, void __iomem *reg)
+{
+ u32 v;
+
+ v = __raw_readl(reg);
+ v= ~mask;
+ v |= bits;
+ __raw_writel(v, reg);
+
+ return v;
+}
/* Read a register in a CM module */
u32 cm_read_mod_reg(s16 module, u16 idx)
{
diff --git a/arch/arm/plat-omap/include/plat/prcm.h
b/arch/arm/plat-omap/include/plat/prcm.h
index 9fbd914..ab77442 100644
--- a/arch/arm/plat-omap/include/plat/prcm.h
+++ b/arch/arm/plat-omap/include/plat/prcm.h
@@ -38,6 +38,8 @@ u32 prm_read_mod_reg(s16 module, u16 idx);
void prm_write_mod_reg(u32 val, s16 module, u16 idx);
u32 prm_rmw_mod_reg_bits(u32 mask, u32 bits, s16 module, s16 idx);
u32 prm_read_mod_bits_shift(s16 domain, s16 idx, u32 mask);
+u32 omap4_prm_read_bits_shift(void __iomem *reg, u32 mask);
+u32 omap4_prm_rmw_reg_bits(u32 mask, u32 bits, void __iomem *reg);
u32 cm_read_mod_reg(s16 module, u16 idx);
void cm_write_mod_reg(u32 val, s16 module, u16 idx);
u32 cm_rmw_mod_reg_bits(u32 mask, u32 bits, s16 module, s16 idx);
--
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 and Sergio, Michael Jones wrote: Aguirre, Sergio wrote: 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 Hi Sergio, Thanks for the helpful reply. Can you also clarify for me the difference between omap3camera and your linux-omap-camera (http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary) repositories? I assume this development has mainly happened on the board-rx51* platform? As Sergio noted, this is a tree for N900. The main point for the tree, however, is the OMAP 3 ISP driver, which can be tested on N900 as the tree also contains N900 sensor, lens and flash drivers. Ultimately I want to get raw sensor data to memory. Do you foresee any problems doing that with the current state of omap3camera? Might I be better off going with a kernel with v4l2_int_device at first? Please don't. It's basically obsolete. Go with v4l2_subdev instead. If you have a sensor driver to write, the et8ek8 driver in the omap3camera tree can be used as an example on what ops the sensor driver should implement. Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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
Re: [PATCH] OMAP1: PM: Fix OMAP1610 build
Manjunatha GK manj...@ti.com writes:
OMAP1610 build fails with following error on the branch pm-wip/hwmods-omap4.
This patch fixes the build error.
arch/arm/mach-omap1/pm_bus.c: In function 'platform_pm_runtime_suspend':
arch/arm/mach-omap1/pm_bus.c:30: error: 'ret' undeclared (first use in this
function)
arch/arm/mach-omap1/pm_bus.c:30: error: (Each undeclared identifier is
reported only once
arch/arm/mach-omap1/pm_bus.c:30: error: for each function it appears in.)
arch/arm/mach-omap1/pm_bus.c:32: error: implicit declaration of function
'clk_get'
arch/arm/mach-omap1/pm_bus.c:32: warning: assignment makes pointer from
integer without a cast
arch/arm/mach-omap1/pm_bus.c:33: error: implicit declaration of function
'IS_ERR'
arch/arm/mach-omap1/pm_bus.c:34: error: implicit declaration of function
'clk_disable'
arch/arm/mach-omap1/pm_bus.c:35: error: implicit declaration of function
'clk_put'
arch/arm/mach-omap1/pm_bus.c:38: warning: assignment makes pointer from
integer without a cast
arch/arm/mach-omap1/pm_bus.c: In function 'platform_pm_runtime_resume':
arch/arm/mach-omap1/pm_bus.c:52: warning: assignment makes pointer from
integer without a cast
arch/arm/mach-omap1/pm_bus.c:54: error: implicit declaration of function
'clk_enable'
arch/arm/mach-omap1/pm_bus.c:58: warning: assignment makes pointer from
integer without a cast
arch/arm/mach-omap1/pm_bus.c:49: warning: unused variable 'r'
arch/arm/mach-omap1/pm_bus.c: In function 'platform_pm_runtime_idle':
arch/arm/mach-omap1/pm_bus.c:72: error: 'ret' undeclared (first use in this
function)
make[1]: *** [arch/arm/mach-omap1/pm_bus.o] Error 1
make: *** [arch/arm/mach-omap1] Error 2
This patch fixes build issues and same has been tested for
omap_h2_1610_defconfig.
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Thanks, will fold this into the OMAP1 bus support in pm-wip/runtime
Kevin
---
arch/arm/mach-omap1/pm_bus.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/pm_bus.c b/arch/arm/mach-omap1/pm_bus.c
index 29d651a..6c5ab40 100644
--- a/arch/arm/mach-omap1/pm_bus.c
+++ b/arch/arm/mach-omap1/pm_bus.c
@@ -15,6 +15,8 @@
#include linux/pm_runtime.h
#include linux/platform_device.h
#include linux/mutex.h
+#include linux/clk.h
+#include linux/err.h
#include plat/omap_device.h
#include plat/omap-pm.h
@@ -23,6 +25,7 @@
int platform_pm_runtime_suspend(struct device *dev)
{
struct clk *iclk, *fclk;
+ int ret = 0;
dev_dbg(dev, %s\n, __func__);
@@ -46,7 +49,7 @@ int platform_pm_runtime_suspend(struct device *dev)
int platform_pm_runtime_resume(struct device *dev)
{
- int r, ret = 0;
+ int ret = 0;
struct clk *iclk, *fclk;
iclk = clk_get(dev, ick);
@@ -69,6 +72,7 @@ int platform_pm_runtime_resume(struct device *dev)
int platform_pm_runtime_idle(struct device *dev)
{
+ int ret = 0;
ret = pm_runtime_suspend(dev);
dev_dbg(dev, %s [%d]\n, __func__, ret);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP PM: MPU/DMA Latency constraints
Vishwanath Sripathy vishwanath...@ti.com writes:
This patch has implementation for OMAP MPU/DMA Latency constraints using PM
QOS.
Changelog is missing description of the problem being solved and the
motivation for the solution.
In particular, a system-wide API is being changed here with no
description of the problem or the reason for this particular solution.
On first glance, the idea here seems wrong. In getting rid of the device
pointer, how do you plan to handle per-device constraints?
Kevin
Signed-off-by: Vishwanath Sripathy vishwanath...@ti.com
---
arch/arm/plat-omap/Kconfig|3 +
arch/arm/plat-omap/Makefile |1 +
arch/arm/plat-omap/i2c.c |3 +-
arch/arm/plat-omap/include/plat/omap-pm.h |9 +-
arch/arm/plat-omap/omap-pm-noop.c | 20 +--
arch/arm/plat-omap/omap-pm.c | 309
+
6 files changed, 328 insertions(+), 17 deletions(-)
create mode 100755 arch/arm/plat-omap/omap-pm.c
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 286b606..ce544b0 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -194,6 +194,9 @@ config OMAP_PM_NONE
config OMAP_PM_NOOP
bool No-op/debug PM layer
+config OMAP_PM
+ depends on PM
+ bool OMAP PM layer implementation
endchoice
endmenu
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 2a15191..fad2475 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -32,3 +32,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
+obj-$(CONFIG_OMAP_PM) += omap-pm.o
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a5ce4f0..29dc45a
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -145,7 +145,8 @@ static inline int omap1_i2c_add_bus(struct
platform_device *pdev, int bus_id)
*/
static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long t)
{
- omap_pm_set_max_mpu_wakeup_lat(dev, t);
+ struct pm_qos_request_list *qos_handle = NULL;
+ omap_pm_set_max_mpu_wakeup_lat(qos_handle, t);
}
static inline int omap2_i2c_add_bus(struct platform_device *pdev, int bus_id)
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h
b/arch/arm/plat-omap/include/plat/omap-pm.h
index 728fbb9..47ba9e6 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -19,6 +19,7 @@
#include linux/clk.h
#include powerdomain.h
+#include linux/pm_qos_params.h
/**
* struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
@@ -86,7 +87,7 @@ void omap_pm_if_exit(void);
/**
* omap_pm_set_max_mpu_wakeup_lat - set the maximum MPU wakeup latency
- * @dev: struct device * requesting the constraint
+ * @qos_request: handle for the constraint. The pointer should be
initialized to NULL
* @t: maximum MPU wakeup latency in microseconds
*
* Request that the maximum interrupt latency for the MPU to be no
@@ -118,7 +119,7 @@ void omap_pm_if_exit(void);
* Returns -EINVAL for an invalid argument, -ERANGE if the constraint
* is not satisfiable, or 0 upon success.
*/
-int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);
+int omap_pm_set_max_mpu_wakeup_lat(struct pm_qos_request_list **qos_request,
long t);
/**
@@ -185,7 +186,7 @@ int omap_pm_set_max_dev_wakeup_lat(struct device
*req_dev, struct device *dev,
/**
* omap_pm_set_max_sdma_lat - set the maximum system DMA transfer start
latency
- * @dev: struct device *
+ * @qos_request: handle for the constraint. The pointer should be
initialized to NULL
* @t: maximum DMA transfer start latency in microseconds
*
* Request that the maximum system DMA transfer start latency for this
@@ -210,7 +211,7 @@ int omap_pm_set_max_dev_wakeup_lat(struct device
*req_dev, struct device *dev,
* Returns -EINVAL for an invalid argument, -ERANGE if the constraint
* is not satisfiable, or 0 upon success.
*/
-int omap_pm_set_max_sdma_lat(struct device *dev, long t);
+int omap_pm_set_max_sdma_lat(struct pm_qos_request_list **qos_request, long
t);
/**
diff --git a/arch/arm/plat-omap/omap-pm-noop.c
b/arch/arm/plat-omap/omap-pm-noop.c
index e129ce8..af2fe43 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -34,19 +34,17 @@ struct omap_opp *l3_opps;
* Device-driver-originated constraints (via board-*.c files)
*/
-int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t)
+int omap_pm_set_max_mpu_wakeup_lat(struct pm_qos_request_list **pmqos_req,
long t)
{
- if (!dev || t -1) {
+ if (!pmqos_req || t -1) {
WARN(1, OMAP PM: %s: invalid parameter(s), __func__);
return -EINVAL;
};
if (t == -1)
Zoom3 not booting with omap3_defconfig
Hi, I'm trying to boot from NFS with my Zoom3 board with current master branch (commit ID: 842849896627701e4c07441f2c7519aeec771058) But, I'm not successful so far. :( Seems that it can't detect the eth0 device. (See attached log: bad.txt) Now, If I take omap_zoom3_defconfig from just before commit: commit 80690ccc41f01df6edfb6684006824d8edff189e Author: Vincent Sanders vi...@simtec.co.uk Date: Tue Aug 3 21:19:21 2010 +0100 Remove ARM default configurations which duplicate omap3_defconfig I'm able to boot fine (see attached log: good.txt) So, somehow, current omap3_defconfig doesn't seem to be as functional as omap_zoom3_defconfig used to be... Is there something that everybody knows, and I'm missing on how to make a usable Zoom3 .config? Regards, Sergio Uncompressing Linux... done, booting the kernel. [0.00] Linux version 2.6.35-08926-g12fafbf (x0091...@dtx0091359-ubuntu-1) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #3 Mon Aug 9 12:15:41 CDT 2010 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: OMAP Zoom3 board [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3630/3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x10 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 [0.00] Kernel command line: earlyprintk console=ttyS0,115200n8 noinitrd mem=512M root=/dev/nfs rw nfsroot=128.247.74.241:/home/x0091359/my-nfs/busybox,nolock ip=dhcp nfsvers=3,tcp omap_vout_mod.video1_ numbuffers=6 omap_vout_mod.vid1_static_vrfb_alloc=y omap_vout_mod.video2_numbuffers=6 omap_vout_mod.vid2_static_vrfb_alloc=y [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 512MB = 512MB total [0.00] Memory: 505836k/505836k available, 18452k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] DMA : 0xffc0 - 0xffe0 ( 2 MB) [0.00] vmalloc : 0xe080 - 0xf800 ( 376 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .init : 0xc0008000 - 0xc0048000 ( 256 kB) [0.00] .text : 0xc0048000 - 0xc0604000 (5872 kB) [0.00] .data : 0xc063 - 0xc0808a40 (1891 kB) [0.00] Hierarchical RCU implementation. [0.00] RCU-based detection of stalled CPUs is disabled. [0.00] Verbose stalled-CPUs detection is disabled. [0.00] NR_IRQS:402 [0.00] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz [0.00] (null): Could not get uart4_ick [0.00] (null): Could not get uart4_fck [0.00] Reprogramming SDRC clock to 4 Hz [0.00] GPMC revision 5.0 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] Could not get gpios_ick [0.00] Could not get gpios_fck [0.00] OMAP GPIO hardware version 2.5 [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3951 kB [0.00] per task-struct memory footprint: 2304 bytes [0.00] Calibrating delay loop... 597.64 BogoMIPS (lpj=2334720) [0.00] pid_max: default: 32768 minimum: 301 [0.00] Security Framework initialized [0.00] Mount-cache hash table entries: 512 [0.00] CPU: Testing write buffer coherency: ok [0.00] regulator: core version 0.5 [0.00] NET: Registered protocol family 16 [0.000793] OMAP DMA hardware revision 5.0 [0.084228] bio: create slab bio-0 at 0 [0.093078] SCSI subsystem initialized [0.102752] usbcore: registered new interface driver usbfs [0.104034] usbcore: registered new interface driver hub [0.104949] usbcore: registered new device driver usb [0.107543] i2c_omap i2c_omap.1: bus 1 rev4.0 at 2400 kHz [0.118652] twl4030: PIH (irq 7) chaining IRQs 368..375
Re: [PATCH v3 0/7] OMAP: hwmod: Full data set for OMAP4430 ES1 ES2
Benoit Cousson b-cous...@ti.com writes: Hi Kevin Paul, Here is the OMAP4430 ES1 ES2 hwmod data v3 series. Please note that there is no difference between the ES1 ES2 wrt hwmod. This series is re-organised in order to allow initial submission for upstream with minimal interconnect data set + mpu. Further data will be sent along with the driver once adapted to hwmod. A first patch is done for the TIMER IP as an example. Patches are based on lo/for-next + for-next-fixes + pm-wip/hwmods-reset + pm-wip/hwmods-debugfs and are available here: git://dev.omapzoom.org/pub/scm/swarch/linux-omap-adv.git pm-wip/hwmods-omap4 Tested on OMAP4430 ES1.0 GP device using PAB board. This is looking good to me. Of course, as you noted we need to understand the root cause of need for those temporary patches before merging. To facilitate broader testing with the other hwmod conversions in progress, and to test with runtime PM, I've updated my pm-wip/hwmods-omap4 branch now includes your series (and its dependencies.) IOW, my pm-wip/hwmods-omap4 branch is just a merge of my pm-wip/runtime branch and your pm-wip/hwmods-omap4 branch. 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: Zoom3 not booting with omap3_defconfig
Hi Sergio, I've seen the exact same thing happen, when I used the linux-omap v2.6.35 tag for a beagleboard based device. It gives me the same kernel panic. [2.097320] Waiting for root device /dev/mmcblk0p2... [2.235595] mmc0: new SD card at address b874 [2.243530] mmcblk0: mmc0:b874 SU02G 1.87 GiB (ro) [2.250213] mmcblk0: p1 p2 [2.323638] VFS: Cannot open root device mmcblk0p2 or unknown-block(179,2) [2.330871] Please append a correct root= boot option; here are the available partitions: [2.339477] b300 1971712 mmcblk0 driver: mmcblk [2.344848] b301 40131 mmcblk0p1 [2.349182] b302 514080 mmcblk0p2 [2.353973] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2) In my case, I found that using v2.6.35 and using the omap3_beagleboard_defconfig worked. This must an artifact from the defconfig clean up that happened for v2.6.35, breakages due to defective or untested defconfigs. Why don't you try a defconfig from a previous kernel version that works? Best regards, Elvis Dowson -- 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 v3] serial: Add OMAP high-speed UART driver
Govindraj govindraj...@gmail.com writes: On Wed, Jul 7, 2010 at 5:32 PM, Tony Lindgren t...@atomide.com wrote: * Govindraj govindraj...@gmail.com [100608 09:24]: On Mon, Jun 7, 2010 at 9:45 PM, Luke-Jr l...@dashjr.org wrote: On Monday 07 June 2010 08:28:51 am Govindraj wrote: Link: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=summa ry Branch: pm-wip/uart This branch doesn't appear to have omap-serial.c at all... If you are trying to use with any client device connected to uart then we need to ensure the client driver speaks to omap-serial dev entries. You need apply the driver patch on top of this branch. [PATCH v3] serial: Add OMAP high-speed UART driver. Do we still have a dependency to pm-wip/uart branch? Can you please check if you can rebase all these patches on top of linux-omap for-next branch? pm-wip uart branch is having all the mach-omap2/serail.c changes along with hwmod data file updation and serial hwmod usage. The driver patch [serial: Add OMAP high-speed UART driver] was tested against wip/uart branch. I will re-base all these patches for-next branch, and will post driver and board support patches from pm-wip/uart as a single series. Any update on this? FWIW, I rebased the pm-wip/uart part on top of latest pm-wip/hwmods-omap4 but from here, you should take over responsibility for pm-wip/uart. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: Voltage: fix typos, compile break
From: Mike Turquette mturque...@ti.com mach-omap/voltage.c incorrectly called omap_get_mpuss_device and omap_get_l3_device. The correct function names are omap2_get_mpuss_device and omap2_get_l3_device respectively. This fixes a compile break. Test on OMAP3430 SDP. Signed-off-by: Mike Turquette mturque...@ti.com --- This patch is meant to apply to Kevin's pm-srf branch. Without it compilation for OMAP3 is broken. arch/arm/mach-omap2/voltage.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c index e7055f6..148e4d4 100644 --- a/arch/arm/mach-omap2/voltage.c +++ b/arch/arm/mach-omap2/voltage.c @@ -385,7 +385,7 @@ static void __init omap3_vdd_data_configure(int vdd) vdd_info[vdd].volt_clk = clk_get(NULL, dpll1_ck); WARN(IS_ERR(vdd_info[vdd].volt_clk), unable to get clock for VDD%d\n, vdd + 1); - vdd_info[vdd].opp_dev = omap_get_mpuss_device(); + vdd_info[vdd].opp_dev = omap2_get_mpuss_device(); vdd_info[vdd].vp_reg.tranxdone_status = OMAP3430_VP1_TRANXDONE_ST_MASK; vdd_info[vdd].cmdval_reg = OMAP3_PRM_VC_CMD_VAL_0_OFFSET; @@ -411,7 +411,7 @@ static void __init omap3_vdd_data_configure(int vdd) vdd_info[vdd].volt_clk = clk_get(NULL, l3_ick); WARN(IS_ERR(vdd_info[vdd].volt_clk), unable to get clock for VDD%d\n, vdd + 1); - vdd_info[vdd].opp_dev = omap_get_l3_device(); + vdd_info[vdd].opp_dev = omap2_get_l3_device(); vdd_info[vdd].vp_reg.tranxdone_status = OMAP3430_VP2_TRANXDONE_ST_MASK; vdd_info[vdd].cmdval_reg = OMAP3_PRM_VC_CMD_VAL_1_OFFSET; -- 1.7.0.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] OMAP PM: Device wakeup latency constraint framework
This patch implements device wakeup latency constraint framework.
Using omap_pm_set_max_dev_wakeup_lat(), drivers can specify the
maximum amount of time for a device to become accessible after
its clocks are enabled. This is done by restricting the power
states that the parent powerdomain of a device can be put into.
Only power states with profiled wakeup latency value less than
the requested constraint get selected while the constraint is
active.
Signed-off-by: Vibhore Vardhan vvard...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
This patch is dependent on OMAP PM: MPU/DMA Latency constraints
patch (https://patchwork.kernel.org/patch/113855/)
Baseline used: linux-next
Tested on: Zoom 3630
arch/arm/mach-omap2/powerdomain.c | 164 +
arch/arm/mach-omap2/powerdomains34xx.h| 60 +
arch/arm/plat-omap/include/plat/powerdomain.h | 32 +
3 files changed, 256 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 6527ec3..16edec6 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -23,6 +23,7 @@
#include linux/errno.h
#include linux/err.h
#include linux/io.h
+#include linux/slab.h
#include asm/atomic.h
@@ -133,6 +134,13 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
pwrdm-state = pwrdm_read_pwrst(pwrdm);
pwrdm-state_counter[pwrdm-state] = 1;
+ /* Initialize priority ordered list for wakeup latency constraint */
+ spin_lock_init(pwrdm-wakeuplat_lock);
+ plist_head_init(pwrdm-wakeuplat_dev_list, pwrdm-wakeuplat_lock);
+
+ /* res_mutex protects res_list add and del ops */
+ mutex_init(pwrdm-wakeuplat_mutex);
+
pr_debug(powerdomain: registered %s\n, pwrdm-name);
return 0;
@@ -1075,3 +1083,159 @@ int pwrdm_post_transition(void)
return 0;
}
+/**
+ * pwrdm_wakeuplat_set_constraint - Set powerdomain wakeup latency constraint
+ * @pwrdm: struct powerdomain * to which requesting device belongs to
+ * @dev: struct device * of requesting device
+ * @t: wakeup latency constraint in microseconds
+ *
+ * Adds new entry to powerdomain's wakeup latency constraint list.
+ * If the requesting device already exists in the list, old value is
+ * overwritten. Checks whether current power state is still adequate.
+ * Returns -EINVAL if the powerdomain or device pointer is NULL,
+ * or -ENOMEM if kmalloc fails, or -ERANGE if constraint can't be met,
+ * or returns 0 upon success.
+ */
+int pwrdm_wakeuplat_set_constraint (struct powerdomain *pwrdm,
+ struct device *dev, unsigned long t)
+{
+ struct wakeuplat_dev_list *user;
+ int found = 0, ret = 0;
+
+ if (!pwrdm || !dev) {
+ WARN(1, OMAP PM: %s: invalid parameter(s), __func__);
+ return -EINVAL;
+ }
+
+ mutex_lock(pwrdm-wakeuplat_mutex);
+
+ plist_for_each_entry(user, pwrdm-wakeuplat_dev_list, node) {
+ if (user-dev == dev) {
+ found = 1;
+ break;
+ }
+ }
+
+ /* Add new entry to the list or update existing request */
+ if (found user-constraint_us == t) {
+ goto exit_set;
+ } else if (!found) {
+ user = kzalloc(sizeof(struct wakeuplat_dev_list), GFP_KERNEL);
+ if (!user) {
+ pr_err(OMAP PM: FATAL ERROR: kzalloc failed\n);
+ ret = -ENOMEM;
+ goto exit_set;
+ }
+ user-dev = dev;
+ } else {
+ plist_del(user-node, pwrdm-wakeuplat_dev_list);
+ }
+
+ plist_node_init(user-node, t);
+ plist_add(user-node, pwrdm-wakeuplat_dev_list);
+ user-node.prio = user-constraint_us = t;
+
+ ret = pwrdm_wakeuplat_update_pwrst(pwrdm);
+
+exit_set:
+ mutex_unlock(pwrdm-wakeuplat_mutex);
+
+ return ret;
+}
+
+/**
+ * pwrdm_wakeuplat_release_constraint - Release powerdomain wkuplat constraint
+ * @pwrdm: struct powerdomain * to which requesting device belongs to
+ * @dev: struct device * of requesting device
+ *
+ * Removes device's entry from powerdomain's wakeup latency constraint list.
+ * Checks whether current power state is still adequate.
+ * Returns -EINVAL if the powerdomain or device pointer is NULL or
+ * no such entry exists in the list, or returns 0 upon success.
+ */
+int pwrdm_wakeuplat_release_constraint (struct powerdomain *pwrdm,
+ struct device *dev)
+{
+ struct wakeuplat_dev_list *user;
+ int found = 0, ret = 0;
+
+ if (!pwrdm || !dev) {
+ WARN(1, OMAP PM: %s: invalid parameter(s), __func__);
+ return -EINVAL;
+ }
+
+ mutex_lock(pwrdm-wakeuplat_mutex);
+
+ plist_for_each_entry(user, pwrdm-wakeuplat_dev_list, node) {
+
RE: Zoom3 not booting with omap3_defconfig (update: sometimes...)
Hi, -Original Message- From: Elvis Dowson [mailto:elvis.dow...@mac.com] Sent: Monday, August 09, 2010 2:17 PM To: Aguirre, Sergio Cc: linux-omap@vger.kernel.org Subject: Re: Zoom3 not booting with omap3_defconfig Hi Sergio, I've seen the exact same thing happen, when I used the linux-omap v2.6.35 tag for a beagleboard based device. It gives me the same kernel panic. Actually, I realized something weird... If I have the exact same kernel, generated with omap3_defconfig, IT sometimes generates me these errors: [2.674804] IP-Config: Failed to open eth0 [2.678924] IP-Config: No network devices available. And sometimes it succeeds: [2.680389] net eth0: SMSC911x/921x identified at 0xe08da000, IRQ: 318 [3.688232] Sending DHCP requests .., OK [6.469879] IP-Config: Got DHCP answer from 0.0.0.0, my address is 128.247.75.216 [6.479034] IP-Config: Complete: So, I don't know... Either I have a faulty HW, or some race condition is happening on the driver that doesn't allow to open it.. I'll try to find out why the open of eth0 fails sometimes.. Regards, Sergio [2.097320] Waiting for root device /dev/mmcblk0p2... [2.235595] mmc0: new SD card at address b874 [2.243530] mmcblk0: mmc0:b874 SU02G 1.87 GiB (ro) [2.250213] mmcblk0: p1 p2 [2.323638] VFS: Cannot open root device mmcblk0p2 or unknown- block(179,2) [2.330871] Please append a correct root= boot option; here are the available partitions: [2.339477] b300 1971712 mmcblk0 driver: mmcblk [2.344848] b301 40131 mmcblk0p1 [2.349182] b302 514080 mmcblk0p2 [2.353973] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2) In my case, I found that using v2.6.35 and using the omap3_beagleboard_defconfig worked. This must an artifact from the defconfig clean up that happened for v2.6.35, breakages due to defective or untested defconfigs. Why don't you try a defconfig from a previous kernel version that works? Best regards, Elvis Dowson -- 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
[Zoom3] smsc911x_soft_reset: Failed to complete reset (sometimes...)
Hi all, Seems that, with current master branch (commit ID: 842849896627701e4c07441f2c7519aeec771058), and doing this change: diff --git a/drivers/net/smsc911x.h b/drivers/net/smsc911x.h index 016360c..2cd4f5a 100644 --- a/drivers/net/smsc911x.h +++ b/drivers/net/smsc911x.h @@ -23,7 +23,7 @@ #define TX_FIFO_LOW_THRESHOLD ((u32)1600) #define SMSC911X_EEPROM_SIZE ((u32)7) -#define USE_DEBUG 0 +#define USE_DEBUG 1 /* This is the maximum number of packets to be received every * NAPI poll */ I see in the console sometimes (not always) these error messages: [2.682342] eth0: smsc911x_soft_reset: Failed to complete reset [2.688385] eth0: smsc911x_open: soft reset failed [2.693176] IP-Config: Failed to open eth0 [2.697326] IP-Config: No network devices available. Is somebody also experiencing this? NOTE: It doesn't seem consistent. I had to reboot several times the board, To reproduce it. Sometimes it comes at the first try. Regards, Sergio -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] usb: musb: Adding names for IRQs in resource structure
Hema HK hem...@ti.com writes:
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.
In patch 0/8 you say this is based on pm-wip/hwmods-omap4 branch. Here
you say thisis omap4-next branch (presumably in Santosh's tree.)
Otherwise, this change looks right.
Kevin
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.c2010-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.c 2010-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.c 2010-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:
Re: [PATCH 0/8]usb: musb:USB driver changes to use hwmod+ omap-device apis
Cousson, Benoit b-cous...@ti.com writes: On 8/6/2010 5:54 PM, HEMA HK wrote: From: Hema HKhem...@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. The way you are submitting that series is quite confusing! You are mixing several numbering schemes and several series versions. If this is a V2, you have to resubmit everything with a V2, and you must include an history. [8/8] usb : musb:Using runtime pm apis for musb. [7/8] : Hwmod api changes [V2,6/8] usb: musb: Offmode fix for idle path [V2,4/8] usb : musb:Using omap_device_build for musb device registration [4/8] usb: musb: HWMOD database structures fixes OMAP4 [V2,3/4] usb: musb: HWMOD database structures addition for OMAP3 [2/8] usb: musb: Remove board_data parameter from musb_platform_init() [1/8] usb: musb: Adding names for IRQs in resource structure The cover letter does not contain the overall stat to summarize what files you are modifying. Please consider using git-format-patch + git-send-email which will automatically take care of many of the problems Benoit has pointed out. Please see this wiki page for lots of useful suggestions: http://wiki.omappedia.org/wiki/Releasing_to_Linux_kernel_using_patches_and_emails Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 6/8] usb: musb: Offmode fix for idle path
Kalliguddi, Hema hem...@ti.com writes: [...] 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. Is this valid for OMAP3 and OMAP4? I checked quickly the OMAP4 TRM vB in the USB_OTG chapter related to PM (23.13.4.2 Power-Management), and I cannot find any note regarding that specific programming model. Could give us reference to the documentation that contains the details about that? Benoit This is valid for both OMAP3 and OMAP4. You can find this in 24.1.5.4 section With different modes. When not used with any application the mode has to be programmed is force idle and force standby. What I observed is that without this USB was blocking the coreoff. http://focus.ti.com/pdfs/wtbu/SWPU223D_Final_EPDF_06_07_2010.pdf For the next rev, please include links to public docs in the changelog. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 PM: fix the error messages printed when the system suspend
On Tue, Jun 22, 2010 at 11:11 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Stanley.Miao stanley.m...@windriver.com writes: First, the subject needs to be more descriptive: OMAP3: AM3505/3517 do not have IO wakeup capability Functionally, what does this statement mean? The 3503 seems to have the EN_IO [8] bit, but I've yet to figure out what the EN_IO_CHAIN [16] means. Thanks, Cliff -- 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 12/13 v5] OMAP: GPIO: Use dev_pm_ops instead of sys_dev_class
Charulatha V ch...@ti.com writes: @@ -1728,7 +1729,6 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev) } pm_runtime_enable(bank-dev); - pm_runtime_get_sync(bank-dev); Why do you remove this? omap_gpio_mod_init(bank, id); This next call accesses GPIO registers and will fault if the GPIO module is reset. You get lucky currently as the GPIO hwmods are not reset on init due to a problem under investigation. (see this patch in Benoit's series) [PATCH v3 6/7] OMAP: hwmod: Temporary prevent reset during _setup for GPIOs Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13 v5] OMAP: GPIO: Modify init() in preparation for platform device implementation
Charulatha V ch...@ti.com writes:
This is in prepartion for implementing GPIO as a platform device.
gpio bank's base addresses are moved from gpio.c to plat/gpio.h.
This patch also modifies omap_gpio_init() to make use of
omap_gpio_chip_init() and omap_gpio_mod_init(). omap_gpio_mod_init() does
the module init by clearing the status register and initializing the
GPIO control register. omap_gpio_chip_init() initializes the chip request,
free, get, set and other function pointers and sets the gpio irq handler.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
[...]
+static void omap_gpio_mod_init(struct gpio_bank *bank, int id)
+{
+ if (cpu_class_is_omap2()) {
+ if (cpu_is_omap44xx()) {
+ __raw_writel(0x, bank-base +
+ OMAP4_GPIO_IRQSTATUSCLR0);
+ __raw_writel(0x, bank-base +
+ OMAP4_GPIO_DEBOUNCENABLE);
+ /* Initialize interface clk ungated, module enabled */
+ __raw_writel(0, bank-base + OMAP4_GPIO_CTRL);
+ } else if (cpu_is_omap34xx()) {
+ __raw_writel(0x, bank-base +
+ OMAP24XX_GPIO_IRQENABLE1);
+ __raw_writel(0x, bank-base +
+ OMAP24XX_GPIO_IRQSTATUS1);
+ __raw_writel(0x, bank-base +
+ OMAP24XX_GPIO_DEBOUNCE_EN);
+
+ /* Initialize interface clk ungated, module enabled */
+ __raw_writel(0, bank-base + OMAP24XX_GPIO_CTRL);
+ /* Enable autoidle for the OCP interface */
+ omap_writel(1 0, 0x48306814);
This autoidle stuff should be removed in this series as setting this is
handled by the hwmod layer.
+ } else if (cpu_is_omap24xx()) {
+ static const u32 non_wakeup_gpios[] = {
+ 0xe203ffc0, 0x08700040
+ };
+ if (id ARRAY_SIZE(non_wakeup_gpios))
+ bank-non_wakeup_gpios = non_wakeup_gpios[id];
+
+ /* Enable autoidle for the OCP interface */
+ omap_writel(1 0, 0x48019010);
ditto
+ }
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/13 v5] OMAP: GPIO: Remove omap_gpio_init()
Charulatha V ch...@ti.com writes:
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.
This patch should also remove the function from plat/gpio.c
Kevin
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
@@
Re: [PATCH 10/13 v5] OMAP: GPIO: Implement GPIO as a platform device
Charulatha V ch...@ti.com writes:
@@ -650,21 +511,28 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
__raw_writel(debounce, reg);
reg = bank-base;
- if (cpu_is_omap44xx())
+ if (bank-method == METHOD_GPIO_44XX)
reg += OMAP4_GPIO_DEBOUNCENABLE;
else
reg += OMAP24XX_GPIO_DEBOUNCE_EN;
val = __raw_readl(reg);
+ if (!bank-dbck) {
+ struct platform_device *pdev = to_platform_device(bank-dev);
+ struct omap_device *odev = to_omap_device(pdev);
insert empty line
+ if (odev-hwmods[0]-opt_clks-_clk)
+ bank-dbck = odev-hwmods[0]-opt_clks-_clk;
As was discussed in Bangalore, drivers should have no knowledge of hwmod
internals.
Instead, please propose an API to hwmod for getting the optional
clock(s), or possibly cleaner, an API to directly enable/disable
optional clocks for an omap_device.
Kevin
+ if (IS_ERR(bank-dbck))
+ dev_err(bank-dev, Could not get gpio dbck\n);
+ }
+
--
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 09/13 v5] OMAP: GPIO: Introduce support for OMAP2PLUS chip GPIO init
Charulatha V ch...@ti.com writes:
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
---
[...]
+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);
+
pdata should be free'd here as omap_device_build makes a copy for
itself.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/13 v5] OMAP: GPIO: Use dev_pm_ops instead of sys_dev_class
Charulatha V ch...@ti.com writes:
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.
This does not match the code.
The only clock associated with a GPIO hwmod is the optional clock for
the debounce clock. This clock is managed by the driver itself, not
by using the PM runtime API.
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.
This doesn't make sense to me. What clocks are you referring to?
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.
This needs much more fleshing out.
Exactly what mutexes are causing the problems here. As pointed out in
previous discussions, the ones in the PM runtime core should not be a
problem in this path. Therefore, I'll assume the problems are coming
from the mutexes when the device code (mach-omap2/gpio.c) calls into the
hwmod layer. More on this in comments on the next patch.
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)
context is saved/restored in the idle path, but...
3. pm_runtime_put_sync() is called when the last used gpio in that
gpio bank is freed (when mod_usage becomes zero)
in this path, the bank is now runtime suspended, but context has not
been saved for it. That should be fine, since this bank is no longer
used, but now let's assume there was an off-mode transition and context
is lost. Then, gpio_request() is called which will trigger
a pm_runtime_get_sync() and gpio_bank_runtime_resume() will be called.
In this case, it's not terribly clear that runtime_resume is doing sane
things if context has just been lost. Seems like runtime_resume should
be a nop in this case since any re-init will be be done in gpio_request().
4. omap_device_idle() is called during idle, if the particular bank
is being used (if mod_usage is non-zero)
This mixture of pm_runtime_* and omap_device_* APIs is confusing at
best.
There should be a single path into the drivers runtime_suspend hooks.
Namely, when pm_runtime_put_* is called and the usecount goes to zero.
If you can't use the runtime PM APIs, then we need to understand
*exactly* why and work on a solution for that particular problem.
On my omap34xx/omap3evm, I had to disable the omap_device_* calls in the
idle path since as they were causing strange crashes, and as stated
above, I'm not sure what the purpose is.
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.
Why?
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
Did you mean 'and' instead of 'or'? If you meant 'or', then clearly
(20 is preferred over (1), and I have a patch to fix that in the current
pm-wip/runtime branch.
If you meant 'and', then you need to describe the root cause for (1).
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,
Re: [PATCH 09/13 v5] OMAP: GPIO: Introduce support for OMAP2PLUS chip GPIO init
Charulatha V ch...@ti.com writes:
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.
What clocks are you referring to?
There is no main_clk associated with this hwmod, so hwmod is not
managing any clocks for you and the driver is handling the debounce
clock (opt_clk.)
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;
+}
The use of hwmod to disable GPIO hwmods in the idle path needs some more
explanation since it differs from what is done in the current GPIO code.
As mentioned above, the (optional) clocks are being managed by the
driver already, so what exactly are you wanting hwmod to do for you?
The only thing that will happen is the toggling of no-idle/smart-idle,
and it's not clear to me that is what you want.
Whatever the new behavior you're trying to get, it should be described
well in the changelog since it's different from current behavior of the
GPIO code. In fact, a change like this which is signifcantly different
from current behavior should be done in a separate patch.
+
+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,
+ },
+};
So, to keep the same behavior as the current code, you could just drop
the omap_gpio_latency part here, and you don't have to worry about
calling into omap_hwmod_* with interrupts disabled.
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: beginner questions on being added to the linux tree
Hi Jacob, On Mon, 9 Aug 2010 19:36:01 -0500 Jacob Tanenbaum jacob.tanenb...@logicpd.com wrote: I work for LogicPD and am trying to add new support for there OMAP3 development boards to the kernel, I have a working version of some of the base support and was wondering how to get that ready to be merged in during this merge window. We have tested the code against the most recent version of linux-next I can get to build and was wondering where to go. Do I send merge requests to the linux-next list or a series of patches. I have sent patches to the omap and arm lists and got some minor syntax errors reported by them (spaces instead of tabs and the like) and was wondering where to go from here. I only merge other people's trees, so you need to set up a git tree somewhere and tell me (cc'ing linux-next and all other appropriate lists/people) where it is and which branch to fetch. I then fetch that branch each day and merge it with everything else. Getting your code merged by Linus during this merge window is up to Linus and Russell or Tony, I guess. But I cannot take new trees now until after -rc1 is out. So if you really want your code merged during this merge window, your best bet is to convince Russell and/or Tony. Having your tree in linux-next may be useful for ongoing development unless Tony thinks it may be better for you to just submit your code through his omap tree. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpckrMG2t7bm.pgp Description: PGP signature
Re: [PATCH] OMAP3 PM: fix the error messages printed when the system suspend
Cliff Brake wrote: On Tue, Jun 22, 2010 at 11:11 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Stanley.Miao stanley.m...@windriver.com writes: First, the subject needs to be more descriptive: OMAP3: AM3505/3517 do not have IO wakeup capability Functionally, what does this statement mean? The 3503 seems to have the EN_IO [8] bit, but I've yet to figure out what the EN_IO_CHAIN [16] means. Please reference to Chapter 4.11 PRCM Off-Mode Management in OMAP35x TRM. Stanley. Thanks, Cliff -- 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 4/8]usb : musb:Using omap_device_build for musb device registration
Hi,
-Original Message-
From: Cousson, Benoit
Sent: Monday, August 09, 2010 6:15 PM
To: Kalliguddi, Hema
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
Felipe Balbi; Tony Lindgren; Kevin Hilman
Subject: Re: [PATCH V2 4/8]usb : musb:Using omap_device_build
for musb device registration
On 8/6/2010 5:57 PM, Kalliguddi, Hema wrote:
From: Hema HKhem...@ti.com
snip
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);
This is not needed in your case. Just use a const char*, and you will
avoid the useless snprintf and test.
Ok.
+
+oh = omap_hwmod_lookup(oh_name);
+
+if (!oh) {
+pr_err(Could not look up %s\n, oh_name);
+} else {
You can avoid that indentation be returning in case of failure.
Agreed.
+/*
+ * 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 {
You can avoid that second level of indentation be returning in case of
failure as well.
Agreed.
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 0/8]usb: musb:USB driver changes to use hwmod+ omap-device apis
Hi, -Original Message- From: Cousson, Benoit Sent: Monday, August 09, 2010 6:02 PM To: Kalliguddi, Hema Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Felipe Balbi; Tony Lindgren; Kevin Hilman Subject: Re: [PATCH 0/8]usb: musb:USB driver changes to use hwmod+ omap-device apis On 8/6/2010 5:54 PM, HEMA HK wrote: From: Hema HKhem...@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. The way you are submitting that series is quite confusing! You are mixing several numbering schemes and several series versions. If this is a V2, you have to resubmit everything with a V2, and you must include an history. [8/8] usb : musb:Using runtime pm apis for musb. [7/8] : Hwmod api changes [V2,6/8] usb: musb: Offmode fix for idle path [V2,4/8] usb : musb:Using omap_device_build for musb device registration [4/8] usb: musb: HWMOD database structures fixes OMAP4 [V2,3/4] usb: musb: HWMOD database structures addition for OMAP3 [2/8] usb: musb: Remove board_data parameter from musb_platform_init() [1/8] usb: musb: Adding names for IRQs in resource structure The cover letter does not contain the overall stat to summarize what files you are modifying. Some spaces are missing after the : in the email subjects. I will take care of this in the next st of patches. Thanks, Hema Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/8 ]usb : musb:Using runtime pm apis for musb.
Hi,
-Original Message-
From: Cousson, Benoit
Sent: Monday, August 09, 2010 7:37 PM
To: Kalliguddi, Hema
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
Basak, Partha; Felipe Balbi; Tony Lindgren; Kevin Hilman
Subject: Re: [PATCH 8/8 ]usb : musb:Using runtime pm apis for musb.
On 8/6/2010 7:29 PM, Hema HK wrote:
From: Hema HKhem...@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 HKhem...@ti.com
Signed-off-by: Basak, Parthap-bas...@ti.com
Cc: Felipe Balbifelipe.ba...@nokia.com
Cc: Tony Lindgrent...@atomide.com
Cc: Kevin Hilmankhil...@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.c
2010-08-06 10:44:42.942112875 -0400
@@ -25,11 +25,13 @@
#includelinux/io.h
#includelinux/usb/musb.h
+#includelinux/pm_runtime.h
#includemach/hardware.h
#includemach/irqs.h
#includeplat/usb.h
#includeplat/omap_device.h
+#includeplat/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.
+*/
As written in the errata document: Unique reference to be used for
communication, Errata ID: i479. You should not use 1.166.
Also the description is a little bit different:
idle_req / idle_ack mechanism potentially broken when autoidle
is enabled.
OK, it looks like it can occur randomly during run time, meaning that
potentially can be probably removed.
I will update it accordingly.
In that case, what is the point of the previous patch that separate
smartidle and autoidle modification?
This errata is applicable to only OMAP3430. The previous patch required
for OMAP4.
+ if (cpu_is_omap3430())
+ oh-flags |= HWMOD_NO_OCP_AUTOIDLE;
You should not access omap_hwmod structure from here and moreover the
flags attribute is a not supposed to be changed dynamically. It is
reflecting the capability of the hwmod and should considered
as a constant.
For that kind of fix, you just have to modified the omap3
hwmod
RE: [PATCH 4/8]usb: musb: HWMOD database structures fixes OMAP4
Hi,
-Original Message-
From: Cousson, Benoit
Sent: Monday, August 09, 2010 5:22 PM
To: Kalliguddi, Hema
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
Felipe Balbi; Tony Lindgren; Kevin Hilman
Subject: Re: [PATCH 4/8]usb: musb: HWMOD database structures
fixes OMAP4
Hi Hema,
On 8/6/2010 5:57 PM, Kalliguddi, Hema wrote:
From: Hema HKhem...@ti.com
Fixed the missing sysc settings for OMAP4 and enabled the OMAP4
hwmod data structure.
Signed-off-by: Hema HKhem...@ti.com
Cc: Felipe Balbifelipe.ba...@nokia.com
Cc: Tony Lindgrent...@atomide.com
Cc: Kevin Hilmankhil...@deeprootsystems.com
It is a good practice, if not mandatory, to CC the authors of the file
you are modifying with your patch.
Neither Paul, nor myself are in CC of this patch. Could you please add
us to this one and the other ones when applicable?
It is mistake of not CCing the owner. I will take care of it.
---
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.c
2010-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,
};
This part if fine except the missing MIDLE_XXX modes. Here is the
modified version using the same convention as other modules:
OK. I will add it.
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_AUTOIDLE | SYSC_HAS_ENAWAKEUP |
+ SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO |
MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
};
I don't have any preference for the parens, but in order to be
consistent with the already existing hwmods, let's keep them.
There was comment from Sergie to remove the parens for omap3 database. So I
have removed.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP PM: MPU/DMA Latency constraints
Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, August 09, 2010 11:59 PM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP PM: MPU/DMA Latency constraints
Vishwanath Sripathy vishwanath...@ti.com writes:
This patch has implementation for OMAP MPU/DMA Latency constraints using PM
QOS.
Changelog is missing description of the problem being solved and the
motivation for the solution.
In particular, a system-wide API is being changed here with no
description of the problem or the reason for this particular solution.
On first glance, the idea here seems wrong. In getting rid of the device
pointer, how do you plan to handle per-device constraints?
Sorry for not being a very descriptive.
The motivation here is to remove the dependency on SRF for implementing mpu/dma
latency constraints. Instead they have been implemented using pm_qos
infrastructure.
Latest pm_qos apis take pm_qos handle to distinguish different pm_qos requests
(or use counting mechanism). Hence drivers need to pass pm_qos handle instead
of device pointer. Drivers just to define a handle and this handle gets
initialized when they make the first request. So from driver's point of view,
it's an opaque handle. That's why you see the change in signature of the api.
Regards
Vishwa
Kevin
Signed-off-by: Vishwanath Sripathy vishwanath...@ti.com
---
arch/arm/plat-omap/Kconfig|3 +
arch/arm/plat-omap/Makefile |1 +
arch/arm/plat-omap/i2c.c |3 +-
arch/arm/plat-omap/include/plat/omap-pm.h |9 +-
arch/arm/plat-omap/omap-pm-noop.c | 20 +--
arch/arm/plat-omap/omap-pm.c | 309
+
6 files changed, 328 insertions(+), 17 deletions(-)
create mode 100755 arch/arm/plat-omap/omap-pm.c
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 286b606..ce544b0 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -194,6 +194,9 @@ config OMAP_PM_NONE
config OMAP_PM_NOOP
bool No-op/debug PM layer
+config OMAP_PM
+ depends on PM
+ bool OMAP PM layer implementation
endchoice
endmenu
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 2a15191..fad2475 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -32,3 +32,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
+obj-$(CONFIG_OMAP_PM) += omap-pm.o
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a5ce4f0..29dc45a
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -145,7 +145,8 @@ static inline int omap1_i2c_add_bus(struct
platform_device
*pdev, int bus_id)
*/
static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long
t)
{
- omap_pm_set_max_mpu_wakeup_lat(dev, t);
+ struct pm_qos_request_list *qos_handle = NULL;
+ omap_pm_set_max_mpu_wakeup_lat(qos_handle, t);
}
static inline int omap2_i2c_add_bus(struct platform_device *pdev, int
bus_id)
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h b/arch/arm/plat-
omap/include/plat/omap-pm.h
index 728fbb9..47ba9e6 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -19,6 +19,7 @@
#include linux/clk.h
#include powerdomain.h
+#include linux/pm_qos_params.h
/**
* struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
@@ -86,7 +87,7 @@ void omap_pm_if_exit(void);
/**
* omap_pm_set_max_mpu_wakeup_lat - set the maximum MPU wakeup latency
- * @dev: struct device * requesting the constraint
+ * @qos_request: handle for the constraint. The pointer should be
initialized to
NULL
* @t: maximum MPU wakeup latency in microseconds
*
* Request that the maximum interrupt latency for the MPU to be no
@@ -118,7 +119,7 @@ void omap_pm_if_exit(void);
* Returns -EINVAL for an invalid argument, -ERANGE if the constraint
* is not satisfiable, or 0 upon success.
*/
-int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);
+int omap_pm_set_max_mpu_wakeup_lat(struct pm_qos_request_list
**qos_request, long t);
/**
@@ -185,7 +186,7 @@ int omap_pm_set_max_dev_wakeup_lat(struct device
*req_dev, struct device *dev,
/**
* omap_pm_set_max_sdma_lat - set the maximum system DMA transfer start
latency
- * @dev: struct device *
+ * @qos_request: handle for the constraint. The pointer should be
initialized to
NULL
* @t: maximum DMA transfer start latency in microseconds
*
* Request that the maximum system DMA transfer start latency for this
@@ -210,7 +211,7 @@ int omap_pm_set_max_dev_wakeup_lat(struct device
*req_dev, struct device *dev,
* Returns
RE: [PATCH 1/8] usb: musb: Adding names for IRQs in resource structure
Hi,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, August 10, 2010 2:24 AM
To: Kalliguddi, Hema
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
Felipe Balbi; Tony Lindgren
Subject: Re: [PATCH 1/8] usb: musb: Adding names for IRQs in
resource structure
Hema HK hem...@ti.com writes:
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.
In patch 0/8 you say this is based on pm-wip/hwmods-omap4 branch. Here
you say thisis omap4-next branch (presumably in Santosh's tree.)
Otherwise, this change looks right.
It is a mistake. I will correct it.
Kevin
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.c
2010-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.c
2010-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 |
RE: [PATCH 01/13 v5] OMAP: GPIO: Modify init() in preparation for platform device implementation
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, August 10, 2010 3:51 AM
To: Varadarajan, Charulatha
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Nayak,
Rajendra; Basak, Partha
Subject: Re: [PATCH 01/13 v5] OMAP: GPIO: Modify init() in preparation for
platform device implementation
Charulatha V ch...@ti.com writes:
This is in prepartion for implementing GPIO as a platform device.
gpio bank's base addresses are moved from gpio.c to plat/gpio.h.
This patch also modifies omap_gpio_init() to make use of
omap_gpio_chip_init() and omap_gpio_mod_init(). omap_gpio_mod_init()
does
the module init by clearing the status register and initializing the
GPIO control register. omap_gpio_chip_init() initializes the chip
request,
free, get, set and other function pointers and sets the gpio irq handler.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
[...]
+static void omap_gpio_mod_init(struct gpio_bank *bank, int id)
+{
+ if (cpu_class_is_omap2()) {
+ if (cpu_is_omap44xx()) {
+ __raw_writel(0x, bank-base +
+ OMAP4_GPIO_IRQSTATUSCLR0);
+ __raw_writel(0x, bank-base +
+OMAP4_GPIO_DEBOUNCENABLE);
+ /* Initialize interface clk ungated, module enabled */
+ __raw_writel(0, bank-base + OMAP4_GPIO_CTRL);
+ } else if (cpu_is_omap34xx()) {
+ __raw_writel(0x, bank-base +
+ OMAP24XX_GPIO_IRQENABLE1);
+ __raw_writel(0x, bank-base +
+ OMAP24XX_GPIO_IRQSTATUS1);
+ __raw_writel(0x, bank-base +
+ OMAP24XX_GPIO_DEBOUNCE_EN);
+
+ /* Initialize interface clk ungated, module enabled */
+ __raw_writel(0, bank-base + OMAP24XX_GPIO_CTRL);
+ /* Enable autoidle for the OCP interface */
+ omap_writel(1 0, 0x48306814);
This autoidle stuff should be removed in this series as setting this is
handled by the hwmod layer.
Okay.
+ } else if (cpu_is_omap24xx()) {
+ static const u32 non_wakeup_gpios[] = {
+ 0xe203ffc0, 0x08700040
+ };
+ if (id ARRAY_SIZE(non_wakeup_gpios))
+ bank-non_wakeup_gpios = non_wakeup_gpios[id];
+
+ /* Enable autoidle for the OCP interface */
+ omap_writel(1 0, 0x48019010);
ditto
Okay.
+ }
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 13/13 v5] OMAP: GPIO: Remove omap_gpio_init()
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, August 10, 2010 4:30 AM
To: Varadarajan, Charulatha
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Nayak,
Rajendra; Basak, Partha
Subject: Re: [PATCH 13/13 v5] OMAP: GPIO: Remove omap_gpio_init()
Charulatha V ch...@ti.com writes:
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.
This patch should also remove the function from plat/gpio.c
Yes. My mistake, I missed it in this patch series.
Kevin
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
Re: [PATCH] spi: omap2_mcspi: make use of dev_vdbg()
Hi, On Mon, Aug 09, 2010 at 03:22:31PM +0200, ext Grant Likely wrote: It didn't get sent to the spi-devel-general list, so it didn't get picked up by patchwork and wasn't there for me to pick up when I was collecting stuff for .36. that's subscribers only ? I couldn't bother subscribing to a list just to send a small cleanup patch. Even though it didn't go to the list, both maintainers are in Cc list and nobody even commented. Anyways, could you, somehow, get an account on majordomo ? -- balbi DefectiveByDesign.org -- 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] spi: omap2_mcspi: make use of dev_vdbg()
On Mon, Aug 9, 2010 at 11:21 PM, Felipe Balbi felipe.ba...@nokia.com wrote: Hi, On Mon, Aug 09, 2010 at 03:22:31PM +0200, ext Grant Likely wrote: It didn't get sent to the spi-devel-general list, so it didn't get picked up by patchwork and wasn't there for me to pick up when I was collecting stuff for .36. that's subscribers only ? I couldn't bother subscribing to a list just to send a small cleanup patch. Even though it didn't go to the list, both maintainers are in Cc list and nobody even commented. My inbox gets very full. If it isn't in patchwork then I tend to lose it. Anyways, could you, somehow, get an account on majordomo ? I know, the sourceforge list is a bit of a pain. I don't even know who the admin of that list is. It was set up before I started the SPI maintainership. I've been thinking about creating a new spi list on vger.kernel.org. g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] spi: omap2_mcspi: make use of dev_vdbg()
Hi, On Tue, Aug 10, 2010 at 07:27:43AM +0200, ext Grant Likely wrote: I know, the sourceforge list is a bit of a pain. I don't even know who the admin of that list is. It was set up before I started the SPI maintainership. I've been thinking about creating a new spi list on vger.kernel.org. please do, that would make things a whole lot easier for plenty of developers. Specially the ones who are just coming up with simple patches once in a while :-) -- balbi DefectiveByDesign.org -- 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 09/13 v5] OMAP: GPIO: Introduce support for OMAP2PLUS chip GPIO init
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, August 10, 2010 5:29 AM
To: Varadarajan, Charulatha
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Nayak,
Rajendra; Basak, Partha
Subject: Re: [PATCH 09/13 v5] OMAP: GPIO: Introduce support for OMAP2PLUS
chip GPIO init
Charulatha V ch...@ti.com writes:
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
---
[...]
+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);
+
pdata should be free'd here as omap_device_build makes a copy for
itself.
Okay.
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
