[PATCH] ARM: OMAP2+: SmartReflex: soc.h is needed for omap initcalls
commit aa4f99638b (ARM: OMAP2+: Use omap initcalls) converted
the initcalls here, but did not #include soc.h where the omap
inicalls are defined.
To fix, #include soc.h
Signed-off-by: Kevin Hilman khil...@linaro.org
---
Tony, the patch that broke this was introduced in your
omap-for-v3.9/multiplatform-enable-signed branch, and this problem was
found only when compiling with PM (specifically, SmartReflex) enabled.
arch/arm/mach-omap2/smartreflex-class3.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index 80f3acb..b2dcbd3 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -13,6 +13,7 @@
#include linux/power/smartreflex.h
#include voltage.h
+#include soc.h
static int sr_class3_enable(struct omap_sr *sr)
{
--
1.8.1.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
Re: [PATCH] usb: musb: fix context save over suspend.
NeilBrown ne...@suse.de writes: On Tue, 12 Feb 2013 13:03:36 -0800 Kevin Hilman khil...@linaro.org wrote: NeilBrown ne...@suse.de writes: [...] My patch was fixing a real hang when musb was built-in (or loaded), in host-mode (mini-A cable attached) but no devices attached. I just tried to reproduce this, and with your patch, the system hangs during suspend. Odd. I plug in a mini-A cable, note that the 'mode' file holds 'a_idle' (sometimes just plugging in the cable isn't enough to trigger that, but sometimes it is) and suspend/resume work perfectly. Though after resume it is back to b_idle. unplug/replug and it is back to a_idle. suspend/resume and back to b_idle. That being said, your description makes sense why this context save/restore is needed. Perhaps your patch needs to add a check whether the device is runtime suspended (I gather this is what Ruslan's patch is doing.) I'm not sure it is possible for the device to be runtime suspended at this point. Certainly my device never is, even if it was just before the suspend sequence started. Something is waking it up... (instruments the code). Ahh - usb_suspend() calls choose_wakeup() which might call pm_runtime_resume() if the could be a need to reprogram the wakeup setting. As that is a 'might', the device might not be runtime-awake when 'suspend' runs. Can you see if this, on top of my previous patch, does any better on your hardware? Yes, this patch adding the check on top of your previous one makes things work just fine on my hardware (3530/Overo). Kevin Thanks, NeilBrown diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 956db0e..00deb94 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2278,7 +2278,8 @@ static int musb_suspend(struct device *dev) } spin_unlock_irqrestore(musb-lock, flags); - musb_save_context(musb); + if (!pm_runtime_status_suspended(dev)) + musb_save_context(musb); return 0; } @@ -2289,7 +2290,8 @@ static int musb_resume_noirq(struct device *dev) * module got reset through the PSC (vs just being disabled). */ struct musb *musb = dev_to_musb(dev); - musb_restore_context(musb); + if (!pm_runtime_status_suspended(dev)) + musb_restore_context(musb); return 0; } -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap2_gpio_prepare_for_idle not functioning in suspend
Hi Russ,
Russ Dill russ.d...@ti.com writes:
After the gpio-omap runtime PM changes, I noticed that the
omap2_gpio_prepare_for_idle/omap2_gpio_resume_after_idle functions are
a NOP in the case of suspend.
void omap2_gpio_prepare_for_idle(int pwr_mode)
{
struct gpio_bank *bank;
list_for_each_entry(bank, omap_gpio_list, node) {
if (!bank-mod_usage)
continue;
bank-power_mode = pwr_mode;
pm_runtime_put_sync_suspend(bank-dev);
}
}
void omap2_gpio_resume_after_idle(void)
{
struct gpio_bank *bank;
list_for_each_entry(bank, omap_gpio_list, node) {
if (!bank-mod_usage)
continue;
pm_runtime_get_sync(bank-dev);
}
}
(called from omap_pm_enter-omap3_pm_suspend-omap_sram_idle)
At the point that platform_suspend_ops.enter is called,
dpm_suspend_end has already been called which disables runtime_pm.
During a suspend/resume where power is lost to certain GPIO banks, the
context will not be restored.
Did you actually observe context not being restored, or is this an
observation by looking at the code?
The PM domain layer (implemented in omap_device) is supposed to be
handling the case where runtime PM has been disabled by the PM core.
Specifically, check the 'noirq' hooks in the omap_device PM domain.
These check whether omap_devices are runtime_suspended, and
runtime_suspends them if they are not. Then during resume, the
resume_noirq hook will runtime resume them if they were forcibly
runtime suspended during the noirq phase.
That being said, there may have been some recent PM core changes that
have caused this not to work anymore, so I'd be very curious exactly how
to reproduce this.
Thanks,
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 07/18] ARM: OMAP2+: AM33XX: hwmod: Update TPTC0 hwmod with the right flags
Vaibhav Bedia vaibhav.be...@ti.com writes:
TPTC0 needs to be idled and put to standby under SW control.
Please elaborate about why (e.g. HW support not available, HW support
broken/buggy, etc.) since these blocks are not well documented in the
docs that I have (spruh73f.)
Thanks,
Kevin
Add the appropriate flags in the TPTC0 hwmod entry.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Vaibhav Hiremath hvaib...@ti.com
---
v1-v2:
No change
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 5e50e68..5c34d4b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -1823,6 +1823,7 @@ static struct omap_hwmod am33xx_tptc0_hwmod = {
.class = am33xx_tptc_hwmod_class,
.clkdm_name = l3_clkdm,
.mpu_irqs = am33xx_tptc0_irqs,
+ .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
.main_clk = l3_gclk,
.prcm = {
.omap4 = {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 16/18] ARM: OMAP2+: AM33XX: Basic suspend resume support
Hi Viabhav, Vaibhav Bedia vaibhav.be...@ti.com writes: AM335x supports various low power modes as documented in section 8.1.4.3 of the AM335x TRM which is available @ http://www.ti.com/litv/pdf/spruh73f DeepSleep0 mode offers the lowest power mode with limited wakeup sources without a system reboot and is mapped as the suspend state in the kernel. In this state, MPU and PER domains are turned off with the internal RAM held in retention to facilitate resume process. As part of the boot process, the assembly code is copied over to OCMCRAM using the OMAP SRAM code. AM335x has a Cortex-M3 (WKUP_M3) which assists the MPU in DeepSleep0 entry and exit. WKUP_M3 takes care of the clockdomain and powerdomain transitions based on the intended low power state. MPU needs to load the appropriate WKUP_M3 binary onto the WKUP_M3 memory space before it can leverage any of the PM features like DeepSleep. The IPC mechanism between MPU and WKUP_M3 uses a mailbox sub-module and 8 IPC registers in the Control module. MPU uses the assigned Mailbox for issuing an interrupt to WKUP_M3 which then goes and checks the IPC registers for the payload. WKUP_M3 has the ability to trigger on interrupt to MPU by executing the sev instruction. In the current implementation when the suspend process is initiated MPU interrupts the WKUP_M3 to let it know about the intent of entering DeepSleep0 and waits for an ACK. When the ACK is received MPU continues with its suspend process to suspend all the drivers and then jumps to assembly in OCMC RAM. The assembly code puts the PLLs in bypass, puts the external RAM in self-refresh mode and then finally execute the WFI instruction. Execution of the WFI instruction triggers another interrupt to the WKUP_M3 which then continues wiht the power down sequence wherein the clockdomain and powerdomain transition takes place. As part of the sleep sequence, WKUP_M3 unmasks the interrupt lines for the wakeup sources. WFI execution on WKUP_M3 causes the hardware to disable the main oscillator of the SoC. When a wakeup event occurs, WKUP_M3 starts the power-up sequence by switching on the power domains and finally enabling the clock to MPU. Since the MPU gets powered down as part of the sleep sequence in the resume path ROM code starts executing. The ROM code detects a wakeup from sleep and then jumps to the resume location in OCMC which was populated in one of the IPC registers as part of the suspend sequence. The low level code in OCMC relocks the PLLs, enables access to external RAM and then jumps to the cpu_resume code of the kernel to finish the resume process. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Cc: Tony Lingren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com Thanks for the updated series here, and my apologies for the delayed review. I've just had a quick scan of this patch, and have a few general comments, I'll probably have a few more comments after a closer look. --- v1-v2: Move assembly code addition, control module access and hookup in OMAP PM framework in separate patches. Address other comments from Kevin Hilman and Santosh Shilimkar on v1. The discussion on v1 is present @ http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129979.html Note: The mailbox change will need slight rework once the driver is finalized. arch/arm/mach-omap2/pm33xx.c | 469 ++ arch/arm/mach-omap2/pm33xx.h | 56 + 2 files changed, 525 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/pm33xx.c create mode 100644 arch/arm/mach-omap2/pm33xx.h diff --git a/arch/arm/mach-omap2/pm33xx.c b/arch/arm/mach-omap2/pm33xx.c new file mode 100644 index 000..aaa4daa --- /dev/null +++ b/arch/arm/mach-omap2/pm33xx.c @@ -0,0 +1,469 @@ +/* + * AM33XX Power Management Routines + * + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/ + * Vaibhav Bedia vaibhav.be...@ti.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed as is WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/kernel.h +#include linux/init.h +#include linux/err.h +#include linux/firmware.h +#include linux/io.h +#include linux/platform_device.h +#include linux/sched.h +#include linux/suspend.h +#include linux/completion.h +#include linux/module.h +#include linux/mailbox.h +#include linux/interrupt.h + +#include
Re: [PATCH] ARM: OMAP4: PM: Avoid expensive cpu_suspend() path for all CPU power states except off
Santosh Shilimkar santosh.shilim...@ti.com writes: Current CPU PM code code make use of common cpu_suspend() path for all the CPU power states which is not optimal. In fact cpu_suspend() path is needed only when we put CPU power domain to off state where the CPU context is lost. Update the code accordingly so that the expensive cpu_suspend() path can be avoided for the shallow CPU power states like CPU PD INA/CSWR. Cc: Kevin Hilman khil...@deeprootsystems.com Reported-by: Richard Woodruff r-woodru...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Looks OK at first glance, but are you sure this is right for the various ways both clusters might idle using coupled CPUidle? Some description of the testing would be helpful here. Thanks, Kevin --- arch/arm/mach-omap2/omap-mpuss-lowpower.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c index aac46bf..abdd0f6 100644 --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c @@ -276,7 +276,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state) /* * Call low level function with targeted low power state. */ - cpu_suspend(save_state, omap4_finish_suspend); + if (save_state) + cpu_suspend(save_state, omap4_finish_suspend); + else + omap4_finish_suspend(save_state); /* * Restore the CPUx power state to ON otherwise CPUx -- 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] ARM: OMAP4: PM: Warn users about usage of older bootloaders
Paul Walmsley p...@pwsan.com writes:
On Mon, 4 Feb 2013, Rajendra Nayak wrote:
OMAP4 CHIP level PM works only with newer bootloaders. The
dependency on the bootloader comes from the fact that the
kernel is missing reset and initialization code for some
devices.
While the right thing to do is to add reset and init code in
the kernel, for some co-processor IP blocks like DSP and IVA
it means downloading firmware into each one of them to execute
idle instructions.
While a feasible solution is worked upon on how such IP blocks
can be better handled in the kernel, in the interim, to avoid
any further frustration to users testing PM on OMAP4 and finding
it broken, warn them about the bootloader being a possible
cause.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: R Sricharan r.sricha...@ti.com
Thanks Rajendra, I appreciate the patch. I've tweaked it slightly and the
following is what's queued here; hopefully it can go in for v3.9.
- Paul
From: Rajendra Nayak rna...@ti.com
Date: Mon, 4 Feb 2013 17:54:43 +0530
Subject: [PATCH] ARM: OMAP4: PM: Warn users about usage of older bootloaders
OMAP4 CHIP level PM works only with newer bootloaders. The
dependency on the bootloader comes from the fact that the
kernel is missing reset and initialization code for some
devices.
While the right thing to do is to add reset and init code in
the kernel, for some co-processor IP blocks like DSP and IVA
it means downloading firmware into each one of them to execute
idle instructions.
While a feasible solution is worked upon on how such IP blocks
can be better handled in the kernel, in the interim, to avoid
any further frustration to users testing PM on OMAP4 and finding
it broken, warn them about the bootloader being a possible
cause.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: R Sricharan r.sricha...@ti.com
[p...@pwsan.com: tweaked warning messages and comments slightly]
Signed-off-by: Paul Walmsley p...@pwsan.com
FWIW
Acked-by: Kevin Hilman khil...@linaro.org
---
arch/arm/mach-omap2/pm44xx.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index aa6fd98..502ed9b 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -77,8 +77,18 @@ static int omap4_pm_suspend(void)
omap_set_pwrdm_state(pwrst-pwrdm, pwrst-saved_state);
pwrdm_set_logic_retst(pwrst-pwrdm, pwrst-saved_logic_state);
}
- if (ret)
+ if (ret) {
pr_crit(Could not enter target state in pm_suspend\n);
+ /*
+ * OMAP4 chip PM currently works only with certain (newer)
+ * versions of bootloaders. This is due to missing code in the
+ * kernel to properly reset and initialize some devices.
+ * Warn the user about the bootloader version being one of the
+ * possible causes.
+ * http://www.spinics.net/lists/arm-kernel/msg218641.html
+ */
+ pr_warn(A possible cause could be an old bootloader - try
u-boot = v2012.07\n);
+ }
else
pr_info(Successfully put all powerdomains to target state\n);
@@ -146,6 +156,13 @@ int __init omap4_pm_init(void)
}
pr_err(Power Management for TI OMAP4.\n);
+ /*
+ * OMAP4 chip PM currently works only with certain (newer)
+ * versions of bootloaders. This is due to missing code in the
+ * kernel to properly reset and initialize some devices.
+ * http://www.spinics.net/lists/arm-kernel/msg218641.html
+ */
+ pr_warn(u-boot = v2012.07 is required for full PM support\n);
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (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 GPIO - don't wake from suspend unless requested.
Grant Likely grant.lik...@secretlab.ca writes: On Fri, 14 Dec 2012 18:05:53 +1100, NeilBrown ne...@suse.de wrote: On Mon, 10 Sep 2012 10:57:07 -0700 Kevin Hilman khil...@deeprootsystems.com wrote: OK thanks, I'll queue this up for v3.6-rc as this should qualify as a regression. I don't think this did actually get queued. At least I'm still seeing the bug in 3.7 and I cannot see a patch in the git history that looks right. But then I don't remember what we ended up with - it was 3 months ago!!! This is the last thing I can find in my email history - it still seems to apply and still seems to work. NeilBrown Kevin, let me know if I need to do anything here. Since you might have it in one of you're trees, I'm not going to do anything unless I hear from you. oops, just stumbled across this one. Sorry for the lag. Grant, feel free to apply. Seems this one never made it into my queue. 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: AM335x: Beaglebone stops to boot with current git kernel
Hiremath, Vaibhav hvaib...@ti.com writes:
On Mon, Dec 03, 2012 at 23:49:36, Kevin Hilman wrote:
Hiremath, Vaibhav hvaib...@ti.com writes:
+static struct omap_hwmod am33xx_debugss_hwmod = {
+ .name = debugss,
+ .class = am33xx_debugss_hwmod_class,
+ .clkdm_name = l3_aon_clkdm,
+ .main_clk = debugss_ick,
+ .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
Setting these flags would still leave the problem where JTAG clocks
are on when its not required no? In that case, what is the advantage
of this patch?
I missed to wrap it around #ifdef CONFIG_DEBUG_KERNEL. I will submit the
formal patch shortly.
IMO, this should not be handled in the data at all (neither clock nor
hwmod), and should be handled at runtime/boot-time, not compile time.
Wouldn't that become another interface/control for debug? We already have
various (standard) debug kernel parameters available.
But I see your point, compile-time option will force users to rebuild kernel
just in order to disable JTAG/Debug clock.
The solution to this is to rather to have a small bit of code that
requests the debugss clocks that are needed for JTAG debug, so the
kernel knows they are in use.
That code could then be enabled at boot time via command-line or DT
option.
In case of command-line, something like below???
static int __init omap2_debug_clk_enable(char *str)
{
if (!str)
return 0;
if (!strcmp(str, debug))
enable debug clock
return 0;
}
early_param(debug, omap2_debug_clk_enable);
Yes, that's the idea I had in mind. Though you don't want to override
debug here. The debug option is specifically about default log levels
for the console and isn't really related to clocks.
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: AM335x: Beaglebone stops to boot with current git kernel
Hiremath, Vaibhav hvaib...@ti.com writes:
+static struct omap_hwmod am33xx_debugss_hwmod = {
+ .name = debugss,
+ .class = am33xx_debugss_hwmod_class,
+ .clkdm_name = l3_aon_clkdm,
+ .main_clk = debugss_ick,
+ .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
Setting these flags would still leave the problem where JTAG clocks
are on when its not required no? In that case, what is the advantage
of this patch?
I missed to wrap it around #ifdef CONFIG_DEBUG_KERNEL. I will submit the
formal patch shortly.
IMO, this should not be handled in the data at all (neither clock nor
hwmod), and should be handled at runtime/boot-time, not compile time.
The solution to this is to rather to have a small bit of code that
requests the debugss clocks that are needed for JTAG debug, so the
kernel knows they are in use.
That code could then be enabled at boot time via command-line or DT
option.
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] MAINTAINERS: update email address for Kevin Hilman
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- MAINTAINERS | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9386a63..17f2ad2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5236,7 +5236,7 @@ S:Maintained F: arch/arm/*omap*/*clock* OMAP POWER MANAGEMENT SUPPORT -M: Kevin Hilman khil...@ti.com +M: Kevin Hilman khil...@deeprootsystems.com L: linux-omap@vger.kernel.org S: Maintained F: arch/arm/*omap*/*pm* @@ -5331,7 +5331,7 @@ F:arch/arm/*omap*/usb* OMAP GPIO DRIVER M: Santosh Shilimkar santosh.shilim...@ti.com -M: Kevin Hilman khil...@ti.com +M: Kevin Hilman khil...@deeprootsystems.com L: linux-omap@vger.kernel.org S: Maintained F: drivers/gpio/gpio-omap.c @@ -6610,7 +6610,7 @@ F:arch/arm/mach-s3c2410/bast-irq.c TI DAVINCI MACHINE SUPPORT M: Sekhar Nori nsek...@ti.com -M: Kevin Hilman khil...@ti.com +M: Kevin Hilman khil...@deeprootsystems.com L: davinci-linux-open-sou...@linux.davincidsp.com (moderated for non-subscribers) T: git git://gitorious.org/linux-davinci/linux-davinci.git Q: http://patchwork.kernel.org/project/linux-davinci/list/ -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] OMAP USB Host cleanup
Roger Quadros rog...@ti.com writes: Kevin, On 11/16/2012 10:08 PM, Kevin Hilman wrote: Roger Quadros rog...@ti.com writes: Hi, This patchset addresses the following - Avoid addressing clocks one by one by name and use a for loop + bunch of cleanups. - Get number of channels/ports dynamically either from revision register or from platform data. Avoids getting clocks that are not present. - Add OMAP5 and HSIC mode (Not tested) - Save power on Panda when EHCI driver is not loaded. Seeing the clock changes/cleanups, I gave this a spin on OMAP3 (3530/Beagle, 3530/Overo, 3730/Beagle-xM, 3730/OveroSTORM) to see if it fixed up the problem where CORE does not hit retention in idle when USB host is enabled, even with no devices attached. Unfortunately, it didn't help. :( oh that's bad. But this series wasn't meant to fix that ;). Oh, sorry. Yeah, I didn't mean this as a nak. Just an opportunity to complain to the maintainers that a long-standing issue needs to be addressed. 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 1/4] mfd: tps65217: Set PMIC to shutdowm on PWR_EN toggle
AnilKumar Ch anilku...@ti.com writes:
From: Colin Foe-Parker colin.foepar...@logicpd.com
Set tps65217 PMIC status to OFF if power enable toggle is
supported. Also adds platform data flag, which should be
passed from board init data.
nit: changelog mentions platform_data, but the code is using DT.
Kevin
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move the additions to tps65217 MFD driver]
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
.../devicetree/bindings/regulator/tps65217.txt |4
drivers/mfd/tps65217.c | 12
2 files changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt
b/Documentation/devicetree/bindings/regulator/tps65217.txt
index d316fb8..4f05d20 100644
--- a/Documentation/devicetree/bindings/regulator/tps65217.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65217.txt
@@ -11,6 +11,9 @@ Required properties:
using the standard binding for regulators found at
Documentation/devicetree/bindings/regulator/regulator.txt.
+Optional properties:
+- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
+
The valid names for regulators are:
tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
@@ -20,6 +23,7 @@ Example:
tps: tps@24 {
compatible = ti,tps65217;
+ ti,pmic-shutdown-controller;
regulators {
dcdc1_reg: dcdc1 {
diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index 3fb32e6..c7f17d8 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -160,6 +160,7 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
unsigned int version;
unsigned int chip_id = ids-driver_data;
const struct of_device_id *match;
+ bool status_off = false;
int ret;
if (client-dev.of_node) {
@@ -170,6 +171,8 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
return -EINVAL;
}
chip_id = (unsigned int)match-data;
+ status_off = of_property_read_bool(client-dev.of_node,
+ ti,pmic-shutdown-controller);
}
if (!chip_id) {
@@ -207,6 +210,15 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
return ret;
}
+ /* Set the PMIC to shutdown on PWR_EN toggle */
+ if (status_off) {
+ ret = tps65217_set_bits(tps, TPS65217_REG_STATUS,
+ TPS65217_STATUS_OFF, TPS65217_STATUS_OFF,
+ TPS65217_PROTECT_NONE);
+ if (ret)
+ dev_warn(tps-dev, unable to set the status OFF\n);
+ }
+
dev_info(tps-dev, TPS65217 ID %#x version 1.%d\n,
(version TPS65217_CHIPID_CHIP_MASK) 4,
version TPS65217_CHIPID_REV_MASK);
--
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/4] ARM: dts: AM33XX: Enable system power off control in am335x-bone
AnilKumar Ch anilku...@ti.com writes:
Enable system power off control for BeagleBone in am335x-bone.dts file
under rtc node. RTC is the incharge of controlling the system power.
This flag is used by the driver to hook up the pm_power_off system call.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 1d55190..206c3eb 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -52,6 +52,10 @@
};
};
+
+ rtc@44e3e000 {
+ ti,system-power-controller;
+ };
};
Also, I think this series is missing a patch that allows the RTC driver
to be compiled on AM335x.
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 00/16] OMAP USB Host cleanup
Roger Quadros rog...@ti.com writes: Hi, This patchset addresses the following - Avoid addressing clocks one by one by name and use a for loop + bunch of cleanups. - Get number of channels/ports dynamically either from revision register or from platform data. Avoids getting clocks that are not present. - Add OMAP5 and HSIC mode (Not tested) - Save power on Panda when EHCI driver is not loaded. Seeing the clock changes/cleanups, I gave this a spin on OMAP3 (3530/Beagle, 3530/Overo, 3730/Beagle-xM, 3730/OveroSTORM) to see if it fixed up the problem where CORE does not hit retention in idle when USB host is enabled, even with no devices attached. Unfortunately, it didn't help. :( Felipe, Keshava, any plans to address this problem which has been around for a couple cycles now and led me to disable USB host in omap2plus_defconfig?[1] Kevin [1] https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=06b4ba529528fbf9c24ce37b7618f4b0264750e2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP4: PM: fix errata handling when CONFIG_PM=n
From: Kevin Hilman khil...@ti.com
commit c9621844 (ARM: OMAP4: PM: add errata support) introduced errata
handling for OMAP4, but was broken when CONFIG_PM=n.
When CONFIG_PM=n, pm44xx.c is not compiled, yet that is where pm44xx_errata
is defined. However, these errata are needed for the SMP boot/hotplug case
also, and are primarily used in omap-smp.c.
Move the definition of pm44xx_errata to omap-smp.c so that it's available
even in the CONFIG_PM=n case.
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
This patch applies on top of Tony's fixes-non-critical-part-2.
The bug was introduced in my for_3.8-fixes-pm tag (now included in Tony's
fixes-non-critical-part2.)
arch/arm/mach-omap2/omap-smp.c | 2 ++
arch/arm/mach-omap2/pm44xx.c | 1 -
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 49a08df..cd42d92 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -40,6 +40,8 @@
#define OMAP5_CORE_COUNT 0x2
+u16 pm44xx_errata;
+
/* SCU base address */
static void __iomem *scu_base;
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 0adbd7d..04922d1 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -34,7 +34,6 @@ struct power_state {
};
static LIST_HEAD(pwrst_list);
-u16 pm44xx_errata;
#ifdef CONFIG_SUSPEND
static int omap4_pm_suspend(void)
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: voltage: fixup oscillator handling when CONFIG_PM=n
From: Kevin Hilman khil...@ti.com
commit 908b75e8 (ARM: OMAP: add support for oscillator setup) added a new
API for oscillator setup, but is broken when CONFIG_PM=n.
The new functions have dummy definitions when CONFIG_PM=n, but also have
full implementations available, which conflict.
To fix, wrap the PM implmentations in #ifdef CONFIG_PM.
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
This applies to Tony's omap-for-v3.8/pm branch, which includes my
for_3.8-pm-voltage tag where this bug was introduced.
arch/arm/mach-omap2/pm.c | 2 ++
arch/arm/mach-omap2/pm.h | 2 +-
arch/arm/mach-omap2/vc.c | 2 ++
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 109a02e..ef668c756 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -39,6 +39,7 @@ static struct omap_device_pm_latency *pm_lats;
*/
int (*omap_pm_suspend)(void);
+#ifdef CONFIG_PM
/**
* struct omap2_oscillator - Describe the board main oscillator latencies
* @startup_time: oscillator startup latency
@@ -68,6 +69,7 @@ void omap_pm_get_oscillator(u32 *tstart, u32 *tshut)
*tstart = oscillator.startup_time;
*tshut = oscillator.shutdown_time;
}
+#endif
static int __init _init_omap_device(char *name)
{
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4db7b23..02c291c 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -135,7 +135,7 @@ extern void omap_pm_get_oscillator(u32 *tstart, u32 *tshut);
extern void omap_pm_setup_sr_i2c_pcb_length(u32 mm);
#else
static inline void omap_pm_setup_oscillator(u32 tstart, u32 tshut) { }
-static inline void omap_pm_get_oscillator(u32 *tstart, u32 *tshut) { }
+static inline void omap_pm_get_oscillator(u32 *tstart, u32 *tshut) { *tstart =
*tshut = 0; }
static inline void omap_pm_setup_sr_i2c_pcb_length(u32 mm) { }
#endif
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 687aa86..a89ec8a 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -666,6 +666,7 @@ static u8 omap_vc_calc_vsel(struct voltagedomain *voltdm,
u32 uvolt)
return voltdm-pmic-uv_to_vsel(uvolt);
}
+#ifdef CONFIG_PM
/**
* omap_pm_setup_sr_i2c_pcb_length - set length of SR I2C traces on PCB
* @mm: length of the PCB trace in millimetres
@@ -678,6 +679,7 @@ void __init omap_pm_setup_sr_i2c_pcb_length(u32 mm)
{
sr_i2c_pcb_length = mm;
}
+#endif
void __init omap_vc_init_channel(struct voltagedomain *voltdm)
{
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc4
Paul Walmsley p...@pwsan.com writes: On Fri, 9 Nov 2012, Kevin Hilman wrote: I found that disabling MMC in the config made the tests pass again, so then bisected it down to the commit below removing SYSCONFIG accesses[2]. I haven't had the time to find out exactly the cause, but clearly the code that was removed was doing something that hwmod is not taking care of automatically. Venkat, Felipe, could you please investigate this and hopefully get a fix out for v3.7-rc? This one might fix it -- it fixes another PM bug in the v3.7-rcs involving the same commit: http://git.kernel.org/?p=linux/kernel/git/pjw/omap-pending.git;a=commit;h=613ad0e98c3596cd2524172fae2a795c3fc57e4a Indeed, that fixes it. Somehow I thought I was already including that fix, but I wasn't. Thanks, 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: [PATCHv9 0/8] ARM: OMAP4: core retention support
Tero Kristo t-kri...@ti.com writes: On Tue, 2012-11-06 at 13:19 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: Hi Kevin, On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote: Hi Tero, Tero Kristo t-kri...@ti.com writes: Hi, Changes compared to previous version: - rebased on top of 3.7-rc1 - applies on top of latest func pwrst code (v6) - added back patch #1 to this set (it wasn't queued yet after all) - added patch #7 for fixing a bug in the functional pwrst code - added patch #8 for fixing a regression with MUSB PHY power handling (not quite sure if this is the correct way to fix this or not) Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle + suspend. Branch also available here: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.7-rc1-omap4-ret-v9 I tested this branch on 4430/Panda and 4460/Panda-ES and I'm seeing several domains not hitting target power state in suspend[1]. Am I missing some other fixes? Using omap2plus_defconfig, I tried your branch alone, and merged with v3.7-rc4, and I get the same errors. [...] This looks like a combination of boot loader/kernel problems. My guess is that l3init is probably held on by the USB, and both ivahd / tesla are held on by some DSP/IVA modules which are not idling properly. The last patch in this set should fix the USB problems at least partially, but also the USB DPLL itself might be in wrong state, attached patch might help for that one and get l3init to idle. For DSP I don't have a patch right now, what is the boot loader you are using? (Can you provide git / commit / config info?) I was using mainline u-boot at tag v2012.04.01 when I saw the errors. To check the bootloader, I upgraded to the latest mainline tag (v2012.10) and the problems are gone on both 4430/Panda and 4460/Panda-ES... Interesting. That suggests that there's still some kernel assumptions/dependencies on the bootloader that need to be addressed. After a little bit of looking into this, this is pretty similar to what I was working on quite a while back once I tried to get the core ret work with mainline kernel. I ended up sending patches against the boot-loader as there wasn't a readily visible solution to some of the issues on kernel side = so now if you update the u-boot, it gets fixed. Yes, recent u-boots have become much more sane in what they initialze. Now, there is a bare set of essential clocks/pads that are configured, so that probably explains why things work better with a sane bootloader. Kevin I am seeing (at least) following subsystems being non-idle with the old bootloader: - M3 cortex (stuck in transition) - DSP (stuck in transition) - SL2IF (stuck in transition) - FSUSB (stuck in transition) ...but I am not aware of any way to get these to working properly from this state without POR. Some of them probably require firmware to be loaded and letting them out of reset also (M3 / DSP.) Benoit, do you have any clues? -Tero -- 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: [PATCHv2] ARM: OMAP4: USB: power down MUSB PHY during boot
Felipe Balbi ba...@ti.com writes: HI, On Fri, Nov 09, 2012 at 04:30:35PM +0200, Tero Kristo wrote: Commit c9e4412ab8eb8ef82d645d8749c4ce96ad490007 removed all of the USB PHY functions for OMAP4, but this causes a problem with core retention as the MUSB module remains enabled if omap-usb2 phy driver is not used. This keeps the USB DPLL enabled and prevents l3_init pwrdm from idling. Fixed by adding a minimal function back that disables the USB PHY during boot. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Kishon Vijay Abraham I kis...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com looks good to me. I would still suggest adding a REVISIT or FIXME note stating that this should be moved to SCM driver eventually ;-) Other than that: Acked-by: Felipe Balbi ba...@ti.com Thanks will try to get this in for v3.8 along with the original patch 4/9 which gets full-chip retention working on OMAP4. 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: OMAP baseline test results for v3.7-rc5
Tony Lindgren t...@atomide.com writes: * Paul Walmsley p...@pwsan.com [121112 11:33]: Here are some basic OMAP test results for Linux v3.7-rc5. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.7-rc5/2012081034/ Passing tests - Boot to userspace (9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone PM ret/off, suspend + dynamic idle (2/4): 3730beaglexm, 37xxevm Failing tests: fixed by posted patches -- Boot tests: * 3530ES3 Beagle: I2C timeouts during userspace init - Intermittent, appears on 5 out of 6 boots here - Aaro Koskinen observes this also on N900 - Appears to be caused by commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc - http://marc.info/?l=linux-arm-kernelm=135071372426971w=2 - http://marc.info/?l=linux-omapm=135197877112220w=2 - Revert posted, pending I2C maintainers: - http://marc.info/?l=linux-arm-kernelm=135221953727077w=2 Here's one more booting issue I recently ran into: - If DEBUG_LL and earlyprintk are enabled, and omap-serial.c is compiled as a module, the kernel boot hangs early as the clocks for serial port are cut while earlyprintk still uses the port. This might be regression from v3.6. Can you test if the patch below[1] helps? With that, it seems to finish booting for me (based solely on a ping test.) The problem is a race between the late_initcall for omap_device (which idles devices that have no drivers) and the late_initcall in kernel/printk.c which turns off the earlyconsole. Any printks that happen between this omap_device late initcall and the earlyconsole late initcall will crash when accessing the UART. Kevin [1] diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index 7a7d1f2..138114a 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -1275,4 +1275,4 @@ static int __init omap_device_late_init(void) bus_for_each_dev(platform_bus_type, NULL, NULL, omap_device_late_idle); return 0; } -late_initcall(omap_device_late_init); +late_initcall_sync(omap_device_late_init); -- 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 5/7] crypto: omap-sham: Convert to use pm_runtime API
Hi Mark,
Mark A. Greer mgr...@animalcreek.com writes:
From: Mark A. Greer mgr...@animalcreek.com
Convert the omap-sham crypto driver to use the
pm_runtime API instead of the clk API.
CC: Kevin Hilman khil...@deeprootsystems.com
CC: Paul Walmsley p...@pwsan.com
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
Acked-by: Kevin Hilman khil...@ti.com
This looks much better and is more obviously a straight forward clock
API -- runtime PM conversion.
Thanks,
Kevin
---
drivers/crypto/omap-sham.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index a3fd6fc..85d43b2 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -22,12 +22,12 @@
#include linux/errno.h
#include linux/interrupt.h
#include linux/kernel.h
-#include linux/clk.h
#include linux/irq.h
#include linux/io.h
#include linux/platform_device.h
#include linux/scatterlist.h
#include linux/dma-mapping.h
+#include linux/pm_runtime.h
#include linux/delay.h
#include linux/crypto.h
#include linux/cryptohash.h
@@ -141,7 +141,6 @@ struct omap_sham_dev {
struct device *dev;
void __iomem*io_base;
int irq;
- struct clk *iclk;
spinlock_t lock;
int err;
int dma;
@@ -238,7 +237,7 @@ static void omap_sham_copy_ready_hash(struct
ahash_request *req)
static int omap_sham_hw_init(struct omap_sham_dev *dd)
{
- clk_enable(dd-iclk);
+ pm_runtime_get_sync(dd-dev);
if (!test_bit(FLAGS_INIT, dd-flags)) {
omap_sham_write_mask(dd, SHA_REG_MASK,
@@ -653,7 +652,8 @@ static void omap_sham_finish_req(struct ahash_request
*req, int err)
/* atomic operation is not needed here */
dd-flags = ~(BIT(FLAGS_BUSY) | BIT(FLAGS_FINAL) | BIT(FLAGS_CPU) |
BIT(FLAGS_DMA_READY) | BIT(FLAGS_OUTPUT_READY));
- clk_disable(dd-iclk);
+
+ pm_runtime_put_sync(dd-dev);
if (req-base.complete)
req-base.complete(req-base, err);
@@ -1198,14 +1198,6 @@ static int __devinit omap_sham_probe(struct
platform_device *pdev)
if (err)
goto dma_err;
- /* Initializing the clock */
- dd-iclk = clk_get(dev, ick);
- if (IS_ERR(dd-iclk)) {
- dev_err(dev, clock intialization failed.\n);
- err = PTR_ERR(dd-iclk);
- goto clk_err;
- }
-
dd-io_base = ioremap(dd-phys_base, SZ_4K);
if (!dd-io_base) {
dev_err(dev, can't ioremap\n);
@@ -1213,11 +1205,14 @@ static int __devinit omap_sham_probe(struct
platform_device *pdev)
goto io_err;
}
- clk_enable(dd-iclk);
+ pm_runtime_enable(dev);
+ pm_runtime_get_sync(dev);
+
dev_info(dev, hw accel on OMAP rev %u.%u\n,
(omap_sham_read(dd, SHA_REG_REV) SHA_REG_REV_MAJOR) 4,
omap_sham_read(dd, SHA_REG_REV) SHA_REG_REV_MINOR);
- clk_disable(dd-iclk);
+
+ pm_runtime_put_sync(pdev-dev);
spin_lock(sham.lock);
list_add_tail(dd-list, sham.dev_list);
@@ -1235,9 +1230,8 @@ err_algs:
for (j = 0; j i; j++)
crypto_unregister_ahash(algs[j]);
iounmap(dd-io_base);
+ pm_runtime_disable(dev);
io_err:
- clk_put(dd-iclk);
-clk_err:
omap_sham_dma_cleanup(dd);
dma_err:
if (dd-irq = 0)
@@ -1266,7 +1260,7 @@ static int __devexit omap_sham_remove(struct
platform_device *pdev)
crypto_unregister_ahash(algs[i]);
tasklet_kill(dd-done_task);
iounmap(dd-io_base);
- clk_put(dd-iclk);
+ pm_runtime_disable(pdev-dev);
omap_sham_dma_cleanup(dd);
if (dd-irq = 0)
free_irq(dd-irq, dd);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP4: TWL: mux sys_drm_msecure as output for PMIC
From: Kevin Hilman khil...@ti.com
On OMAP4 boards using the TWL6030 PMIC, the sys_drm_msecure is
connected to the MSECURE input of the TWL6030 PMIC. This signal
controls the secure-mode operation of the PMIC. If its not mux'd
correctly, some functionality of the PMIC will not be accessible since
the PMIC will be in secure mode.
For example, if the TWL RTC is in secure mode, most of its registers
are read-only, meaning (re)programming the RTC (e.g. for wakeup from
suspend) will fail.
To fix, ensure the signal is properly mux'd as output when TWL is
intialized.
This fix is required when using recent versions of u-boot (= v2012.04.01)
since u-boot is no longer setting the default mux for this pin.
Signed-off-by: Kevin Hilman khil...@ti.com
---
Based on v3.7-rc4. Targetted as a fix for v3.7.
A correponding DT fix for this is needed as well, but that will be part of
a bigger series to get PM working with DT boot and needs to include other
pins like sys_nirq1.
arch/arm/mach-omap2/twl-common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 635e109..96cae8b 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -73,6 +73,7 @@ void __init omap4_pmic_init(const char *pmic_type,
{
/* PMIC part*/
omap_mux_init_signal(sys_nirq1, OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_WAKEUPENABLE);
+ omap_mux_init_signal(fref_clk0_out.sys_drm_msecure, OMAP_PIN_OUTPUT);
omap_pmic_init(1, 400, pmic_type, 7 + OMAP44XX_IRQ_GIC_START,
pmic_data);
/* Register additional devices on i2c1 bus if needed */
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/26] Move OMAP2+ over to common clk framework
Mike Turquette mturque...@ti.com writes: Quoting Rajendra Nayak (2012-11-07 21:02:59) On Thursday 08 November 2012 06:42 AM, Mike Turquette wrote: I also tested on OMAP4460 Panda-ES. Boot is fine and PRCM programming appears sane. However Panda-ES never comes back from suspend/resume. This problem exists on the PRM/CM branch I based on and was not introduced by this series. I am investigating that independently of this series. Don't bother. Its been a know issue for a long time now. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg72056.html Thanks. I realized that after posting! I think there are fixes posted to the list so I will re-test with those fixes tomorrow. I recently sent a pull request for these: http://marc.info/?l=linux-omapm=135224963505956w=2 With that, suspend/resume is working fine on 4460/Panda-ES. 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: OMAP4/Panda: u-boot upgrade v2012.04.01 - v2012.10 breaks RTC wakeups
Hi Sricharan, R Sricharan r.sricha...@ti.com writes: In the latest, pad mux and clocks for all non-essential modules at U-BOOT were removed. This might also cause the problem. We can bring this back in u-boot by adding the following macros and check if it works fine again. include/configs/omap4_common.h -- #define CONFIG_SYS_ENABLE_PADS_ALL #define CONFIG_SYS_CLOCKS_ENABLE_ALL Thanks for the pointer, that got things working again. It's actually CONFIG_SYS_ENABLE_PADS_ALL alone which got things working again. I'm glad to see u-boot going in this direction. In the kernel, we've also been trying to get rid of bootloader dependencies also, but it's clear we haven't got all of them yet. I'll keep digging to see what's missing in the kernel pads setup to get RTC working again. 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 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support
Bedia, Vaibhav vaibhav.be...@ti.com writes: Hi Kevin, On Wed, Nov 07, 2012 at 06:36:06, Kevin Hilman wrote: Bedia, Vaibhav vaibhav.be...@ti.com writes: On Mon, Nov 05, 2012 at 23:10:27, Kevin Hilman wrote: [...] Also, if there are drivers for these devices, won't this interfere? Hmm, I can think of the following scenarios 1. Runtime PM adapted drivers are compiled in - We'll have to ensure that in their suspend callbacks they end up doing omap_hwmod_idle() via the runtime PM APIs. That already happens for all omap_devices. In this case the omap_hwmod_enable() followed by omap_hwmod_idle() is not necessary in the PM code. Correct. 2. The drivers are not compiled in - In this case, the hwmod code puts the IPs in standby during bootup so the first suspend-resume iteration will pass. During resuming, the SYSC configuration for forced standby will be lost, Please clarify how the SYSC is lost in this case. The register configuration of IPs in the PER domain is lost when we enter the suspend state. So the forced standby configuration from SYSC is lost and we need to do this for every successful suspend-resume cycle. so in the subsequent iterations these IPs won't go standby and the hwmod code does not touch them since they never got enabled. In this case we do need the sequence that is there currently. 3. For some reason the respective drivers don't idle the IPs during suspend - (no_idle_on_suspend flag for the hwmod in DT?). In this scenario I think we should abort the suspend process since we know that the suspend is not going to work. Agreed. Is there some other scenario that needs to be covered? You covered the ones I was thinking of. How about adding some flag in hwmod code for handling this? Something similar to what was done for MMC [1]. I think the problem that we have is in some ways similar to the one addressed in [1]. Except that in the absence of drivers, no hwmod code is executed on the suspend/resume path. We could perhaps add a couple of APIs to check the SYSC values when coming out of suspend and take appropriate action if the sysc cache does not match? Yes, for IPs with only SW support and no drivers, we may need something like this. But again, it needs to be suspend and idle aware, not just suspend. 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: [PATCHv9 0/8] ARM: OMAP4: core retention support
Tero Kristo t-kri...@ti.com writes: Hi Kevin, On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote: Hi Tero, Tero Kristo t-kri...@ti.com writes: Hi, Changes compared to previous version: - rebased on top of 3.7-rc1 - applies on top of latest func pwrst code (v6) - added back patch #1 to this set (it wasn't queued yet after all) - added patch #7 for fixing a bug in the functional pwrst code - added patch #8 for fixing a regression with MUSB PHY power handling (not quite sure if this is the correct way to fix this or not) Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle + suspend. Branch also available here: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.7-rc1-omap4-ret-v9 I tested this branch on 4430/Panda and 4460/Panda-ES and I'm seeing several domains not hitting target power state in suspend[1]. Am I missing some other fixes? Using omap2plus_defconfig, I tried your branch alone, and merged with v3.7-rc4, and I get the same errors. [...] This looks like a combination of boot loader/kernel problems. My guess is that l3init is probably held on by the USB, and both ivahd / tesla are held on by some DSP/IVA modules which are not idling properly. The last patch in this set should fix the USB problems at least partially, but also the USB DPLL itself might be in wrong state, attached patch might help for that one and get l3init to idle. For DSP I don't have a patch right now, what is the boot loader you are using? (Can you provide git / commit / config info?) I was using mainline u-boot at tag v2012.04.01 when I saw the errors. To check the bootloader, I upgraded to the latest mainline tag (v2012.10) and the problems are gone on both 4430/Panda and 4460/Panda-ES... Interesting. That suggests that there's still some kernel assumptions/dependencies on the bootloader that need to be addressed. 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: [PATCHv9 2/8] ARM: OMAP4: PM: add errata support
Kevin Hilman khil...@deeprootsystems.com writes: Tero Kristo t-kri...@ti.com writes: Added similar PM errata flag support as omap3 has. This should be used in similar manner, set the flags during init time, and check the flag values during runtime. Signed-off-by: Tero Kristo t-kri...@ti.com These allow basic suspend/resume to work on 4460/Panda-ES, so I'm going to queue these up as fixes. However, since they're not technically regressions, it may be too late to get them in for v3.7, but they'll be in for v3.8 for sure. To be more specific, I'm planning on queuing patches 2, 3 and 6 as fixes for v3.8 (branch: for_3.8/fixes/pm). Paul has already queued patch 1, so that leaves patches 4, 5, 7 8. I think we can get this series in for v3.8 if we drop the functional pwrst dependency. To test, I dropped patches 5 7, and tested on 4430/Panda and 4460/Panda-ES (with latest mainline u-boot) and CORE is hitting retention just fine in suspend. If you can respin patch 8 based on the feedback from Felipe, I'll queue up patches 4 8 for v3.8 as well, then we'll at least have CORE retention in suspend in mainline. Then, the rest can be done when functional pwrsts are ready. Kevin P.S. do you have any patches to add any OMAP4 CPUidle support for CORE retention? Paul has already queued patch 1, and that leaves the -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] OMAP: PM: misc. fixes for v3.8
Tony, Here's a small series that fixes some errata to make suspend/resume work on OMAP4460. This is not a regression and has been broken for awhile, so this is v3.8 material, not v3.7. Kevin The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89: Linux 3.7-rc4 (2012-11-04 11:07:39 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-fixes-pm for you to fetch changes up to cd8ce159031813eb870a5f3d5b27c3be36cd6e3a: ARM: OMAP4: retrigger localtimers after re-enabling gic (2012-11-05 14:26:43 -0800) Some non-regression fixes for OMAP4460 PM support. Colin Cross (1): ARM: OMAP4: retrigger localtimers after re-enabling gic Santosh Shilimkar (1): ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change. Tero Kristo (1): ARM: OMAP4: PM: add errata support arch/arm/mach-omap2/common.h | 4 +++ arch/arm/mach-omap2/omap-headsmp.S| 38 arch/arm/mach-omap2/omap-mpuss-lowpower.c | 9 ++- arch/arm/mach-omap2/omap-smp.c| 39 +++- arch/arm/mach-omap2/omap4-common.c| 42 ++- arch/arm/mach-omap2/pm.h | 9 +++ arch/arm/mach-omap2/pm44xx.c | 1 + 7 files changed, 139 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] OMAP: PM: cleanups for v3.8
Tony, Here is some PM related cleanup targetted for v3.8. Kevin The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-cleanup-pm for you to fetch changes up to 9bb053787d5ca12ec388bb5f871c79ffb83762ab: ARM: OMAP2+: PM: VP: minor pr_warn updates (2012-10-25 14:32:34 -0700) Minor pr_warn() cleanup for OMAP2+ Voltage Processor (VP) Nishanth Menon (1): ARM: OMAP2+: PM: VP: minor pr_warn updates arch/arm/mach-omap2/vp.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] OMAP: PM: SmartReflex updates for v3.8
Tony, Here's some minor platform_data related updates for SR for v3.8. Kevin The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37: Linux 3.7-rc1 (2012-10-14 14:41:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-pm-sr for you to fetch changes up to 98aed08e16c5f18d0c31fc07127bc163ccd0d04c: ARM: OMAP: SmartReflex: pass device dependent data via platform data (2012-10-15 15:22:24 -0700) OMAP: SmartReflex: pass device-independent data via platform_data Jean Pihet (2): ARM: OMAP: hwmod: align the SmartReflex fck names ARM: OMAP: SmartReflex: pass device dependent data via platform data arch/arm/mach-omap2/clock33xx_data.c | 12 +++ arch/arm/mach-omap2/clock3xxx_data.c | 12 +++ arch/arm/mach-omap2/clock44xx_data.c | 6 ++-- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8 ++--- arch/arm/mach-omap2/sr_device.c| 13 +++ drivers/power/avs/smartreflex.c| 54 ++ include/linux/power/smartreflex.h | 14 ++-- 7 files changed, 61 insertions(+), 58 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] OMAP: PM: voltage layer updates for v3.8
Tony, Here's a set of voltage layer updates for v3.8. This implements all the framework changes necessary to get auto-ret/auto-off working, but the main change to enable auto-ret/auto-off is awaiting the functional power state changes that are still under review/rework. Also, this fixes that pesky VC warning about I2C config not matching other channels that was reported by Russell. Kevin The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89: Linux 3.7-rc4 (2012-11-04 11:07:39 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-pm-voltage for you to fetch changes up to df7cded30ced539d3b4e6bae9f3011d98c069d41: ARM: OMAP4: OPP: add OMAP4460 definitions (2012-11-05 15:31:49 -0800) OMAP voltage layer updates towards supporting auto-retention/auto-off Nishanth Menon (1): ARM: OMAP3+: PM: VP: use uV for max and min voltage limits Tero Kristo (13): ARM: OMAP: voltage: renamed vp_vddmin and vp_vddmax fields ARM: OMAP3+: voltage: introduce omap vc / vp params for voltagedomains ARM: OMAP3: VC: calculate ramp times ARM: OMAP4: voltage: add support for VOLTSETUP_x_OFF register ARM: OMAP4: VC: calculate ramp times ARM: OMAP: add support for oscillator setup ARM: OMAP3+: vp: use new vp_params for calculating vddmin and vddmax ARM: OMAP3+: voltage: use oscillator data to calculate setup times ARM: OMAP: TWL: change the vddmin / vddmax voltages to spec ARM: OMAP3+: voltage: remove unused volt_setup_time parameter ARM: OMAP4: vc: fix channel configuration ARM: OMAP4: VC: setup I2C parameters based on board data ARM: OMAP4: TWL: enable high speed mode for PMIC communication Vishwanath Sripathy (1): ARM: OMAP4: OPP: add OMAP4460 definitions arch/arm/mach-omap2/control.h | 1 + arch/arm/mach-omap2/omap_opp_data.h | 9 +- arch/arm/mach-omap2/omap_twl.c| 73 + arch/arm/mach-omap2/opp4xxx_data.c| 98 +- arch/arm/mach-omap2/pm.c | 30 ++ arch/arm/mach-omap2/pm.h | 10 + arch/arm/mach-omap2/vc.c | 451 -- arch/arm/mach-omap2/vc.h | 8 +- arch/arm/mach-omap2/vc3xxx_data.c | 22 ++ arch/arm/mach-omap2/vc44xx_data.c | 28 ++ arch/arm/mach-omap2/voltage.h | 44 ++- arch/arm/mach-omap2/voltagedomains3xxx_data.c | 5 + arch/arm/mach-omap2/voltagedomains44xx_data.c | 23 +- arch/arm/mach-omap2/vp.c | 6 +- arch/arm/mach-omap2/vp.h | 7 + arch/arm/mach-omap2/vp3xxx_data.c | 10 + arch/arm/mach-omap2/vp44xx_data.c | 15 + 17 files changed, 725 insertions(+), 115 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP4/Panda: u-boot upgrade v2012.04.01 - v2012.10 breaks RTC wakeups
Hello, I just noticed that the kernel wakeup from suspend using RTC is broken after I upgraded u-boot from v2012.04.01 to v2012.10 on my OMAP4430/Panda and OMAP4460/Panda-ES. I haven't isolated the cause yet, but am hoping someone might have a pointer about where to start digging. 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 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support
Bedia, Vaibhav vaibhav.be...@ti.com writes: On Mon, Nov 05, 2012 at 23:10:27, Kevin Hilman wrote: [...] Also, if there are drivers for these devices, won't this interfere? Hmm, I can think of the following scenarios 1. Runtime PM adapted drivers are compiled in - We'll have to ensure that in their suspend callbacks they end up doing omap_hwmod_idle() via the runtime PM APIs. That already happens for all omap_devices. In this case the omap_hwmod_enable() followed by omap_hwmod_idle() is not necessary in the PM code. Correct. 2. The drivers are not compiled in - In this case, the hwmod code puts the IPs in standby during bootup so the first suspend-resume iteration will pass. During resuming, the SYSC configuration for forced standby will be lost, Please clarify how the SYSC is lost in this case. so in the subsequent iterations these IPs won't go standby and the hwmod code does not touch them since they never got enabled. In this case we do need the sequence that is there currently. 3. For some reason the respective drivers don't idle the IPs during suspend - (no_idle_on_suspend flag for the hwmod in DT?). In this scenario I think we should abort the suspend process since we know that the suspend is not going to work. Agreed. Is there some other scenario that needs to be covered? You covered the ones I was thinking of. How about adding some flag in hwmod code for handling this? Something similar to what was done for MMC [1]. I think the problem that we have is in some ways similar to the one addressed in [1]. Except that in the absence of drivers, no hwmod code is executed on the suspend/resume path. 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 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support
+Santosh (to help with EMIF questions/comments)
On 11/02/2012 12:32 PM, Vaibhav Bedia wrote:
AM335x supports various low power modes as documented
in section 8.1.4.3 of the AM335x TRM which is available
@ http://www.ti.com/litv/pdf/spruh73f
DeepSleep0 mode offers the lowest power mode with limited
wakeup sources without a system reboot and is mapped as
the suspend state in the kernel. In this state, MPU and
PER domains are turned off with the internal RAM held in
retention to facilitate resume process. As part of the boot
process, the assembly code is copied over to OCMCRAM using
the OMAP SRAM code.
AM335x has a Cortex-M3 (WKUP_M3) which assists the MPU
in DeepSleep0 entry and exit. WKUP_M3 takes care of the
clockdomain and powerdomain transitions based on the
intended low power state. MPU needs to load the appropriate
WKUP_M3 binary onto the WKUP_M3 memory space before it can
leverage any of the PM features like DeepSleep.
The IPC mechanism between MPU and WKUP_M3 uses a mailbox
sub-module and 8 IPC registers in the Control module. MPU
uses the assigned Mailbox for issuing an interrupt to
WKUP_M3 which then goes and checks the IPC registers for
the payload. WKUP_M3 has the ability to trigger on interrupt
to MPU by executing the sev instruction.
In the current implementation when the suspend process
is initiated MPU interrupts the WKUP_M3 to let about the
intent of entering DeepSleep0 and waits for an ACK. When
the ACK is received, MPU continues with its suspend process
to suspend all the drivers and then jumps to assembly in
OCMC RAM to put the PLLs in bypass, put the external RAM in
self-refresh mode and then finally execute the WFI instruction.
The WFI instruction triggers another interrupt to the WKUP_M3
which then continues wiht the power down sequence wherein the
clockdomain and powerdomain transition takes place. As part of
the sleep sequence, WKUP_M3 unmasks the interrupt lines for
the wakeup sources. When WKUP_M3 executes WFI, the hardware
disables the main oscillator.
When a wakeup event occurs, WKUP_M3 starts the power-up
sequence by switching on the power domains and finally
enabling the clock to MPU. Since the MPU gets powered down
as part of the sleep sequence, in the resume path ROM code
starts executing. The ROM code detects a wakeup from sleep
and then jumps to the resume location in OCMC which was
populated in one of the IPC registers as part of the suspend
sequence.
The low level code in OCMC relocks the PLLs, enables access
to external RAM and then jumps to the cpu_resume code of
the kernel to finish the resume process.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Very well summarized. Thanks for the thorough changelog.
First, some general comments. This is a big patch and probably should
be broken up a bit. I suspect it could be broken up a bit, maybe into
at least:
- EMIF interface
- SCM interface, new APIs
- assembly/OCM code
- pm33xx.[ch]
- lastly, the late_init stuff that actually initizlizes
I have a handful of comments below. I wrote this up on the plane over
the weekend, and I see that Santosh has already made some similar
comments, but I'll send mine anyways.
[...]
+static int am33xx_pm_suspend(void)
+{
+ int status, ret = 0;
+
+ struct omap_hwmod *gpmc_oh, *usb_oh;
+ struct omap_hwmod *tptc0_oh, *tptc1_oh, *tptc2_oh;
+
+ /*
+ * By default the following IPs do not have MSTANDBY asserted
+ * which is necessary for PER domain transition. If the drivers
+ * are not compiled into the kernel HWMOD code will not change the
+ * state of the IPs if the IP was not never enabled
+ */
+ usb_oh = omap_hwmod_lookup(usb_otg_hs);
+ gpmc_oh = omap_hwmod_lookup(gpmc);
+ tptc0_oh= omap_hwmod_lookup(tptc0);
+ tptc1_oh= omap_hwmod_lookup(tptc1);
+ tptc2_oh= omap_hwmod_lookup(tptc2);
+
+ omap_hwmod_enable(usb_oh);
+ omap_hwmod_enable(gpmc_oh);
+ omap_hwmod_enable(tptc0_oh);
+ omap_hwmod_enable(tptc1_oh);
+ omap_hwmod_enable(tptc2_oh);
+
+ omap_hwmod_idle(usb_oh);
+ omap_hwmod_idle(gpmc_oh);
+ omap_hwmod_idle(tptc0_oh);
+ omap_hwmod_idle(tptc1_oh);
+ omap_hwmod_idle(tptc2_oh);
Doing this on every suspend looks a bit strange. Why not just have some
init function handle these devices once at boot. If this is really
needed on every suspend, it needs some more description, and probably
some basic stub drivers need to be created.
Also, if there are drivers for these devices, won't this interfere?
+ /* Put the GFX clockdomains to sleep */
+ clkdm_sleep(gfx_l3_clkdm);
+ clkdm_sleep(gfx_l4ls_clkdm);
+
+ /* Try to put GFX to sleep */
+ pwrdm_set_next_pwrst(gfx_pwrdm, PWRDM_POWER_OFF);
ditto.
[...]
+static int am33xx_pm_begin(suspend_state_t state)
+{
+ int ret = 0;
+
+ disable_hlt();
+
+ /*
+ * Physical
Re: [PATCH 11/15] ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX
Bedia, Vaibhav vaibhav.be...@ti.com writes: On Sat, Nov 03, 2012 at 18:34:30, Kevin Hilman wrote: [...] Doesn't this also mean that you won't get timer wakeups in idle? Or are you keeping the domain where the clockevent is on during idle? The lowest idle state that we are targeting will have MPU powered off with external memory in self-refresh mode. Peripheral domain with the clockevent will be kept on. Is this a limitation of the hardware? or the software? Well, making the lowest idle state same as the suspend state will require us to involve WKUP_M3 in the idle path and wakeup sources get limited to the IPs in the WKUP domain alone. There's no IO daisy chaining in AM33XX so that's one big difference compared to OMAP. The other potential problem is that the IPC mechanism that we have uses interrupts. It can still interrupt the M3, it's only the interrupt back to the MPU that is the issue, right? That being said, there's no reason it couldn't use polling in the idle path, right? Assuming that the lowest idle state, say Cx, is the same as the suspend state, we'll need to communicate with the WKUP_M3 using interrupts once we decide to enter Cx. I am not sure if we can do something in the cpuidle implementation to work around the interrupt for idle problem. We could probably not wait for an ACK when we want to enter Cx, why not? Are the response times from the M3 really up to 500ms (guessing based on the timeout you used in the suspend path.) That seems rather unlikely. Hmm, but as I think about it. Why does the MPU need to wait for an ACK at all? Why not just send the cmd and WFI? but the problem of limited wakeup sources remains. If we let the various drivers block the entry to Cx, since almost all the IPs are in the peripheral domain a system which uses anything other than UART and Timer in WKUP domain will probably never be able enter Cx. Even so, I think the system needs to be designed to hit the same power states in idle and suspend. Then, the states can be restricted based wakeup capabilities as you described. This would be easy to do in the runtime PM implementation for this device. IMO, assuming that idle will not be useful from the begining is leading down the path to poor design choices that will be much more difficult to fixup down the road in order to add idle support later. We need to design both idle and suspend at the same time. Also, don't forget about GPIO0. Systems could easily be built such that peripherals which want to wakeup but don't have native wakeup capabilities could use a GPIO in bank 0 to wake the system. Similarily, I2C0 is in WKUP, and brought out to capes, so some simple designs with with I2C devices on a cape might be perfectly capable of hitting deep power states in idle. 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/15] ARM: DTS: AM33XX: Add nodes for OCMCRAM and Mailbox
Bedia, Vaibhav vaibhav.be...@ti.com writes: On Mon, Nov 05, 2012 at 20:23:11, Shilimkar, Santosh wrote: [...] On OMAP the OCMC RAM is always clocked and doesn't need any special clock enable. CM_L3_2_OCMC_RAM_CLKCTRL module mode field is read only. Isn't it same on AMXX ? On AM33xx, OCMC RAM is in PER domain and the corresponding CLKCLTR module mode fields are r/w. OCMC RAM needs to be disabled as part of the DeepSleep0 entry to let PER domain transition. After DeepSleep0, the ROM code is being given an address in OCMC RAM to jump to. If OCMC RAM is disabled as part of suspend, this means that OCMC RAM contents are maintained even though PER domain transitions? If so, that needs to be more clearly documented. 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: [PATCHv9 0/8] ARM: OMAP4: core retention support
Hi Tero, Tero Kristo t-kri...@ti.com writes: Hi, Changes compared to previous version: - rebased on top of 3.7-rc1 - applies on top of latest func pwrst code (v6) - added back patch #1 to this set (it wasn't queued yet after all) - added patch #7 for fixing a bug in the functional pwrst code - added patch #8 for fixing a regression with MUSB PHY power handling (not quite sure if this is the correct way to fix this or not) Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle + suspend. Branch also available here: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.7-rc1-omap4-ret-v9 I tested this branch on 4430/Panda and 4460/Panda-ES and I'm seeing several domains not hitting target power state in suspend[1]. Am I missing some other fixes? Using omap2plus_defconfig, I tried your branch alone, and merged with v3.7-rc4, and I get the same errors. Kevin [1] # echo enabled /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup # echo mem /sys/power/state [ 102.271087] PM: Syncing filesystems ... done. [ 102.282196] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 102.312133] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 102.343353] Suspending console(s) (use no_console_suspend to debug) �[ 102.363433] PM: suspend of devices complete after 10.650 msecs [ 102.365631] PM: late suspend of devices complete after 2.166 msecs [ 102.369201] PM: noirq suspend of devices complete after 3.509 msecs [ 102.369232] Disabling non-boot CPUs ... [ 102.373016] CPU1: shutdown [ 104.357421] Powerdomain (core_pwrdm) didn't enter target state 1 [ 104.357452] Powerdomain (tesla_pwrdm) didn't enter target state 1 [ 104.357452] Powerdomain (ivahd_pwrdm) didn't enter target state 1 [ 104.357482] Powerdomain (l3init_pwrdm) didn't enter target state 1 [ 104.357482] Could not enter target state in pm_suspend [ 104.357666] Enabling non-boot CPUs ... [ 104.359863] CPU1: Booted secondary processor [ 104.360626] cpu cpu0: opp_init_cpufreq_table: Device OPP not found (-19) [ 104.360656] cpu cpu0: omap_cpu_init: cpu1: failed creating freq table[-19] [ 104.360656] CPU1 is up [ 104.362579] PM: noirq resume of devices complete after 1.892 msecs [ 104.364807] PM: early resume of devices complete after 1.373 msecs [ 104.710937] PM: resume of devices complete after 346.099 msecs [ 104.817901] Restarting tasks ... done. -- 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: [PATCHv9 6/8] ARM: OMAP4: retrigger localtimers after re-enabling gic
Tero Kristo t-kri...@ti.com writes: From: Colin Cross ccr...@android.com 'Workaround for ROM bug because of CA9 r2pX gic control' register change disables the gic distributor while the secondary Just to clarify: this is referring to PATCH 3/8 of this series, correct? 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: [PATCHv9 2/8] ARM: OMAP4: PM: add errata support
Tero Kristo t-kri...@ti.com writes:
Added similar PM errata flag support as omap3 has. This should be used
in similar manner, set the flags during init time, and check the flag
values during runtime.
Signed-off-by: Tero Kristo t-kri...@ti.com
These allow basic suspend/resume to work on 4460/Panda-ES, so I'm going
to queue these up as fixes.
However, since they're not technically regressions, it may be too late
to get them in for v3.7, but they'll be in for v3.8 for sure.
Kevin
---
arch/arm/mach-omap2/pm.h |7 +++
arch/arm/mach-omap2/pm44xx.c |1 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 707e9cb..f26f2d7 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -100,6 +100,13 @@ extern void enable_omap3630_toggle_l2_on_restore(void);
static inline void enable_omap3630_toggle_l2_on_restore(void) { }
#endif /* defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3) */
+#if defined(CONFIG_ARCH_OMAP4)
+extern u16 pm44xx_errata;
+#define IS_PM44XX_ERRATUM(id)(pm44xx_errata (id))
+#else
+#define IS_PM44XX_ERRATUM(id)0
+#endif
+
#ifdef CONFIG_POWER_AVS_OMAP
extern int omap_devinit_smartreflex(void);
extern void omap_enable_smartreflex_on_init(void);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index ba06300..07e7ef2 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -33,6 +33,7 @@ struct power_state {
};
static LIST_HEAD(pwrst_list);
+u16 pm44xx_errata;
#ifdef CONFIG_SUSPEND
static int omap4_pm_suspend(void)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP4: PM: fix regulator name for VDD_MPU
From: Kevin Hilman khil...@ti.com
commit 24d7b40a (ARM: OMAP2+: PM: MPU DVFS: use generic CPU device for
MPU-SS) updated the regulator name used for the MPU regulator, but only
updated OMAP3, not OMAP4. Fix the OMAP4 name as well, otherwise CPUfreq
fails to find the MPU regulator.
Signed-off-by: Kevin Hilman khil...@ti.com
---
Applies to v3.7-rc4
arch/arm/mach-omap2/twl-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 635e109..44c4205 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -366,7 +366,7 @@ static struct regulator_init_data omap4_clk32kg_idata = {
};
static struct regulator_consumer_supply omap4_vdd1_supply[] = {
- REGULATOR_SUPPLY(vcc, mpu.0),
+ REGULATOR_SUPPLY(vcc, cpu0),
};
static struct regulator_consumer_supply omap4_vdd2_supply[] = {
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Jean Pihet jean.pi...@newoldbits.com writes: [...] I ran some intensive stress tests on the I2C and ... unfortunately I could not trigger the problem. It looks like the issue is caused by some transient situation where the CORE and/or I2C is in a low power state. FYI... I just ran across what appears to be the same bug on 3430/n900 during suspend/resume testing. With CPUidle enabled, this happens every time. Reverting the I2C QoS patch makes it work again. Kevin # rtcwake -m mem -s 1 Date:Fri Dec 31 17:00:34 MST 1999 hwclock: Sat Jan 1 00:00:34 2000 0.00 seconds [ 38.819732] omap_i2c omap_i2c.1: timeout waiting for bus ready wakeup from mem at Sat Jan 1 00:00:36 2000 [ 38.841949] PM: Syncing filesystems ... done. [ 38.859466] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 38.885284] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 38.916412] Suspending console(s) (use no_console_suspend to debug) [ 39.944274] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 39.944305] twl: i2c_read failed to transfer all messages [ 39.944305] twl_rtc: Could not read TWLregister D - error -110 [ 39.944335] twl_rtc twl_rtc: twl_rtc_read_time: reading CTRL_REG, error -110 [ 40.975524] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 40.97] twl: i2c_read failed to transfer all messages [ 40.97] VMMC2_IO_18: failed to disable [ 40.978698] PM: suspend of devices complete after 2049.163 msecs [ 40.984222] PM: late suspend of devices complete after 5.493 msecs [ 40.992126] PM: noirq suspend of devices complete after 7.873 msecs [ 40.992187] Disabling non-boot CPUs ... [ 40.992675] Successfully put all powerdomains to target state [ 40.997009] PM: noirq resume of devices complete after 4.058 msecs [ 41.002014] PM: early resume of devices complete after 3.601 msecs [ 41.179016] PM: resume of devices complete after 176.818 msecs [ 41.277740] Restarting tasks ... done. real0m 3.50s user0m 0.00s sys 0m 0.10s Date:Fri Dec 31 17:00:40 MST 1999 hwclock: Sat Jan 1 00:00:40 2000 0.00 seconds -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP: PM: few more fixes for v3.7-rc
Hi Tony, Here's a couple more trivial fixes for v3.7-rc. Thanks, Kevin The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.7-rc5-fixes-pm for you to fetch changes up to 73c503cb981394872db41dd5cde385cb5373b4b9: ARM: OMAP4: PM: fix regulator name for VDD_MPU (2012-11-05 16:30:29 -0800) Minor OMAP PM fixes for v3.7-rc Kevin Hilman (2): ARM: OMAP2+: PM: add missing newline to VC warning message ARM: OMAP4: PM: fix regulator name for VDD_MPU arch/arm/mach-omap2/twl-common.c | 2 +- arch/arm/mach-omap2/vc.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 00/21] ARM: OMAP3+: auto retention support
Hi Tero, Tero Kristo t-kri...@ti.com writes: This set applies on top of linux-3.6-rc5 + func-pwrst code (from Jean) + omap4 core retention set (from me) + PM usecounting changes set (from me). Since the functional pwrst and usecounting changes are still under review, I've taken the patches from this series that are not dependent on either of those series and queued them up here for v3.8 (branch: for_3.8/pm/voltage.) That includes patches the core voltage layer changes (patches 1-10 and 14-17) and the 4460 OPP data (patch 18.) I've left out the TPS changes so I can review those closer, and also left out the main auto-ret/auto off patch (PATCH 13/21) because of the dependencies on the usecounting series. With this, I tested DVFS on 3430/n900, 4430/Panda and 4460/PandaES and voltage scaling seems to be working well. Kevin Changes compared to previous version: - Added proper OMAP4 auto-retention support (now that the PM usecount set below supports OMAP4 also properly) - Merged TPS6236x support to this set (patches 16,18-20), without this there will be an issue with patch #21, as panda board will misbehave without TPS support and auto-ret enabled - Patch #15 fixes the addressing of voltage channels for OMAP4, without this the voltage channels either end up changing wrong voltage channel or not changing anything at all - Patch #16 is new based on the discussion earlier on the separate TPS set * uses proper I2C parameters based on board data, this is still in a data table though, as calculating these runtime would be rather complicated (if even possible, as it requires some higher order mathematics according to my understanding) - Patch #17 enables high speed I2C communication for voltage channel on OMAP4 (this now works thanks to patch #16) - Patch #18 is needed for 4460 boards, otherwise the boot-up OPP detection fails and voltage control doesn't work at all on 4460 boards - Patch #19 was pulled from the TPS support set - Patch #20 was pulled from the TPS support set, with following changes: * board setup for the GPIOs was sanitized a bit * dropped a number of unused defines from the code Working branch available: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.6-rc5-omap-auto-ret-v7 Testing done: - hw used: omap3 beagle rev c4, omap4460 gp panda, omap4430 emu blaze - suspend + cpuidle - measured core + mpu voltage rails on all setups to verify that the voltage transitions work properly during idle -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/15] ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX
On 11/02/2012 12:32 PM, Vaibhav Bedia wrote: AM33XX has only one usable timer in the WKUP domain. After reading the TRM, it seems there are two: DMTIMER0 and DMTIMER1. Looking at the hwmod data though, I don't see a hwmod for DMTIMER0. Can you explain a little about why DMTIMER0 is missing/broken? 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 0/3] capebus moving omap_devices to mach-omap2
On 11/02/2012 09:43 AM, Pantelis Antoniou wrote: [...] And then use the standard DT support to create later the platform_device that does represent the new super-cape devices. We know this is the ideal case. In fact that's the long term goal and we had internal discussions about it. Since you already had internal discussions about this, it would have been a great help in avoiding lots of this discussion if you would've summarized this ideal case from the beginning, then describe the weaknesses and limitations of DT for handling hotplug/dynamic devices and thus the reasoning behind creating capebus. Now it's taken this long thread for others to try to convince you about something you already knew to be the ideal case. Seems a bit wasteful. Kernel development typically works by building/extending infrastructure that is already there. Only when it's obvious that the current infrastructure cannot be extended for a new kind of usage do we build new infrastruture. In this case, DT is the obvious infrastructure that needs extending. At least we can all agree on that, for starters. DT is nowhere near being able to do it. That would require the introduction of a DT object file format with aliases being capable to be resolved dynamically. We're talking about major changes here in the way DT files are being compiled and used in practice. So yes, in an ideal world that would be great. We're nowhere near close today unfortunately. Assuming that we do work on a DT object format, and that the runtime resolution mechanism is approved, then I agree that this part of the capebus patches can be dropped and the functionality assumed by generic DT core. The question is that this will take time, with no guarantees that this would be acceptable from the device tree maintainers. So I am putting them in the CC list, to see what they think about it. Since this thread has already ventured into the weeds a few times, I would suggest that you summarize the DT limitations (focusing on they dynamic/hotplug needs) and start a thread on devicetree-discuss, so that the DT maintainers can be helpful without having to follow this thread. IMO, the path forward is clear (though probably longer than you would like): Let's first try and extend DT infrastructure. If that is obviously going nowhere, and DT maintainers are against it. Then, let's revisit capebus. 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 11/15] ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX
On 11/02/2012 01:32 PM, Vaibhav Bedia wrote: AM33XX has only one usable timer in the WKUP domain. Currently the timer instance in WKUP domain is used as the clockevent and the timer in non-WKUP domain as the clocksource. The timer in WKUP domain can keep running in suspend from a 32K clock and hence serve as the persistent clock. To enable this, interchange the timers used as clocksource and clockevent for AM33XX. Doesn't this also mean that you won't get timer wakeups in idle? Or are you keeping the domain where the clockevent is on during idle? 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 2/2] ARM: OMAP: omap_device: Correct resource handling for DT boot
On 10/30/2012 12:24 PM, Peter Ujfalusi wrote: When booting with DT the OF core can fill up the resources provided within the DT blob. The current way of handling the DT boot prevents us from removing hwmod data for platforms only suppose to boot with DT (OMAP5 for example) since we need to keep the whole hwmod database intact in order to have more resources in hwmod than in DT (to be able to append the DMA resource from hwmod). To fix this issue we just examine the OF provided resources: If we do not have resources we use hwmod to fill them. If we have resources we check if we already able to recive DMA resource, if no we only append the DMA resurce from hwmod to the OF provided ones. In this way we can start removing hwmod data for devices which have their resources correctly configured in DT without regressions. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.comke Acked-by: Kevin Hilman khil...@ti.com Benoit, feel free to take this one as well. 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/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device
On 11/02/2012 01:32 PM, Vaibhav Bedia wrote:
From: Vaibhav Hiremath hvaib...@ti.com
The current OMAP timer code registers two timers -
one as clocksource and one as clockevent.
AM33XX has only one usable timer in the WKUP domain
so one of the timers needs suspend-resume support
to restore the configuration to pre-suspend state.
The changelog describes what, but doesn't answer why?
commit adc78e6 (timekeeping: Add suspend and resume
of clock event devices) introduced .suspend and .resume
callbacks for clock event devices. Leverages these
callbacks to have AM33XX clockevent timer which is
in not in WKUP domain to behave properly across system
suspend.
You say it behaves properly without describing what improper
behavior is happening.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
arch/arm/mach-omap2/timer.c | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 6584ee0..e8781fd 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -135,6 +135,35 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
}
}
+static void omap_clkevt_suspend(struct clock_event_device *unused)
+{
+ char name[10];
+ struct omap_hwmod *oh;
+
+ sprintf(name, timer%d, 2);
hard-coded timer ID? the rest of the code is using timer_id
+ oh = omap_hwmod_lookup(name);
+ if (!oh)
+ return;
+
+ omap_hwmod_idle(oh);
+}
+
+static void omap_clkevt_resume(struct clock_event_device *unused)
+{
+ char name[10];
+ struct omap_hwmod *oh;
+
+ sprintf(name, timer%d, 2);
+ oh = omap_hwmod_lookup(name);
+ if (!oh)
+ return;
+
+ omap_hwmod_enable(oh);
+ __omap_dm_timer_load_start(clkev,
+ OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
+ __omap_dm_timer_int_enable(clkev, OMAP_TIMER_INT_OVERFLOW);
+}
I don't like the sprintf/hwmod_lookup for every suspend/resume. Just add a
new file-global static 'struct omap_hwmod clockevt_oh' along side
clockevent_gpt,
and assign it at init time in dmtimer_init_one. Then you don't have to
do this
sprintf/lookup on every suspend/resume.
Kevin
static struct clock_event_device clockevent_gpt = {
.name = gp_timer,
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
@@ -142,6 +171,8 @@ static struct clock_event_device clockevent_gpt = {
.rating = 300,
.set_next_event = omap2_gp_timer_set_next_event,
.set_mode = omap2_gp_timer_set_mode,
+ .suspend= omap_clkevt_suspend,
+ .resume = omap_clkevt_resume,
};
static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
--
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/15] ARM: DTS: AM33XX: Add nodes for OCMCRAM and Mailbox
On 11/02/2012 01:32 PM, Vaibhav Bedia wrote:
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Even simple patches need a simple changelog.
Kevin
arch/arm/boot/dts/am33xx.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..e2cbf24 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,16 @@
interrupt-parent = intc;
interrupts = 91;
};
+
+ ocmcram: ocmcram@4030 {
+ compatible = ti,ocmcram;
+ ti,hwmods = ocmcram;
+ ti,no_idle_on_suspend;
+ };
+
+ wkup_m3: wkup_m3@44d0 {
+ compatible = ti,wkup_m3;
+ ti,hwmods = wkup_m3;
+ };
};
};
--
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 14/15] ARM: OMAP2+: omap2plus_defconfig: Enable Mailbox
On 11/02/2012 01:32 PM, Vaibhav Bedia wrote: AM33XX PM code depends on Mailbox module for IPC between MPU and WKUP_M3. OK, but what if I try to build for AM33xx without starting from omap2plus_defconfig? IOW, instead of changing the default defconfig, AM33xx should select this when PM is enabled. Something like the (untested) change below. Kevin diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index d669e22..93c1a37 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -109,6 +109,7 @@ config SOC_AM33XX bool AM33XX support default y select ARM_CPU_SUSPEND if PM +select OMAP_MBOX_FWK if PM select CPU_V7 select MULTI_IRQ_HANDLER -- 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 11/15] ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX
T On 11/03/2012 12:47 PM, Bedia, Vaibhav wrote: Hi Kevin, On Sat, Nov 03, 2012 at 17:13:54, Kevin Hilman wrote: On 11/02/2012 01:32 PM, Vaibhav Bedia wrote: AM33XX has only one usable timer in the WKUP domain. Currently the timer instance in WKUP domain is used as the clockevent and the timer in non-WKUP domain as the clocksource. The timer in WKUP domain can keep running in suspend from a 32K clock and hence serve as the persistent clock. To enable this, interchange the timers used as clocksource and clockevent for AM33XX. Doesn't this also mean that you won't get timer wakeups in idle? Or are you keeping the domain where the clockevent is on during idle? The lowest idle state that we are targeting will have MPU powered off with external memory in self-refresh mode. Peripheral domain with the clockevent will be kept on. Is this a limitation of the hardware? or the software? Kevin P.S. I haven't yet made my way through the TRM, so I'll probably figure this out when I read it, but having this summarized in the changelog would be helpful since even after I read the TRM, I'll forget. I'm saving the TRM reading for entertainment on upcoming flight home from Linaro Connect. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/6] ARM: OMAP: SmartReflex: provide SoC integration API for VP
On 10/23/2012 10:43 PM, Nishanth Menon wrote:
SoC integration of SmartReflex AVS block is varied. Some use
Voltage Processor for a hardware loop in certain OMAP SoC (called
hardware loop), while others have just the AVS block without
hardware loop automatic calibration mechanism for AVS block
to talk through. So provide the Voltage Processor API
to allow for SmartReflex class drivers to use the same.
NOTE: SmartReflex class 3 mode of operation mandates VP APIs
so, refuse to enable AVS driver if corresponding APIs are
not available.
As part of this change, remove the inclusion of voltage.h
which is no longer needed as smartreflex.h includes
linux/platform_data/voltage-omap.h which contain relevant
definitions used here.
Signed-off-by: Nishanth Menon n...@ti.com
[...]
@@ -23,15 +22,26 @@ static int sr_class3_enable(struct omap_sr *sr)
__func__, sr-name);
return -ENODATA;
}
+ if (!sr-soc_ops.vp_enable) {
+ pr_warn(%s: no VP enable available.Cannot enable %s!!\n,
nit: add space after '.'
There's a couple of these in the patch.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/6] ARM: OMAP3+: move smartreflex-class3.c to drivers/power/avs
Hi Nishanth, On 10/25/2012 09:21 AM, Jean Pihet wrote: Hi Nishant, On Tue, Oct 23, 2012 at 11:43 PM, Nishanth Menon n...@ti.com wrote: smartreflex.c now resides in drivers/power/avs directory, but class driver is in mach-omap2. High time we move it off to drivers/power/avs. Great to see the SR fully moved to drivers/. After review of the code I am OK with the changes besides remarks sent on the patches: Acked-by: Jean Pihet j-pi...@ti.com I let Kevin comment on the VC/VP aspect though. This move looks good to me. Thanks! Just had one nit, but after that. Feel free to post without the RFC, and be sure to include Rafael and linux-pm since it's moving to drivers/power. I'll then queue it up for Rafael for v3.8. Thanks, 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/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device
On 11/03/2012 01:17 PM, Bedia, Vaibhav wrote: On Sat, Nov 03, 2012 at 17:45:03, Kevin Hilman wrote: On 11/02/2012 01:32 PM, Vaibhav Bedia wrote: From: Vaibhav Hiremath hvaib...@ti.com The current OMAP timer code registers two timers - one as clocksource and one as clockevent. AM33XX has only one usable timer in the WKUP domain so one of the timers needs suspend-resume support to restore the configuration to pre-suspend state. The changelog describes what, but doesn't answer why? Sorry I'll try to take of this in the future. Thanks. Here's a general rule. Assume you (or I) will be reading this a year from now and will have forgotten the details. The changelog then serves as our long-term memory. :) commit adc78e6 (timekeeping: Add suspend and resume of clock event devices) introduced .suspend and .resume callbacks for clock event devices. Leverages these callbacks to have AM33XX clockevent timer which is in not in WKUP domain to behave properly across system suspend. You say it behaves properly without describing what improper behavior is happening. There are two issues. One is that the clockevent timer doesn't get idled which blocks PER domain transition. The next one is that the clockevent doesn't generate any further interrupts once the system resumes. Please include both in the next rev of the changelog. We need to restore the pre-suspend configuration. I haven't tried but I guess we could have used the save and restore c timer registers here. Yes, please try with that. Won't that be necessary anyways for situations where the powerdomain goes off? 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 14/15] ARM: OMAP2+: omap2plus_defconfig: Enable Mailbox
On 11/03/2012 01:17 PM, Bedia, Vaibhav wrote: On Sat, Nov 03, 2012 at 17:50:25, Kevin Hilman wrote: On 11/02/2012 01:32 PM, Vaibhav Bedia wrote: AM33XX PM code depends on Mailbox module for IPC between MPU and WKUP_M3. OK, but what if I try to build for AM33xx without starting from omap2plus_defconfig? I honestly didn't think about this scenario. IOW, instead of changing the default defconfig, AM33xx should select this when PM is enabled. Something like the (untested) change below. Will try it out. Thanks for the suggestion. You're welcome. See... sometimes maintainers can be useful for something other than complaining. ;) 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: Fwd: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Linus Walleij linus.wall...@linaro.org writes: On Wed, Oct 31, 2012 at 9:10 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Linus Walleij linus.wall...@linaro.org writes: piece of hardware, this would be the right thing to do, and I think the in-kernel examples are all simple, e.g. arch/arm/mach-omap2/powerdomain* is all about power domains and nothing else, FYI... that code isn't the same as PM domain. This sort of points to a core problem here. Our terminologies are ambiguous that we cannot understand each others code. As long as linux/pm_domain.h begins: /* * pm_domain.h - Definitions and headers related to device power domains. * But arguably that should just be patched (I think there are a few remnants in the code still implying that these things are only about power). Agreed. The terminology is confusing, and any situations like this in the code/comments/docs should be patched. When PM domains were introduced, I was the first to complain that we shouldn't use the term power domain so as not to be confused with HW concepts, so we settled on the term 'PM domain.' Ultimately, it's just a configurable grouping of devices whose callbacks happen during PM transitions. That code is for the *hardware* powerdomains, not the software concept of PM domain. In OMAP, PM domain is implmented at the omap_device level. And omap_device is the abstraction of an IP block that knows about all the PM related register settings, clocks, HW powerdomain, voltage domain, PM related pin-muxing etc. etc.All of these things are abstracted in an omap_device, so that the PM domain implementation for OMAP looks rather simple (c.f. omap_device_pm_domain in arch/arm/plat-omap/omap_device.c.) OK following now... I think the lesser of two evils is the distributed approach, The pinctrl examples I've seen mentioned so far are all PM related (sleep, idle, wakeup, etc.) so to me I think they still belong in PM domains (and that's how we handle the PM related pins in OMAP.) Well, the pinctrl grabbers in these drivers are using these states also for platforms that do not even select CONFIG_PM. For example mach-nomadik is quite happy that the PL011 driver is thusly muxing in its pins. And would require refactoring to use PM domains. If CONFIG_PM is disabled, then is it safe to assume that the pins in question are probably only done once at init time. I assume during -probe(). ? So basically this requirement comes down to: - When dealing with a SoC IP block driver - That need to multiplex pins - Then your SoC must select CONFIG_PM and CONFIG_PM_RUNTIME andb CONFIG_PM_GENERIC_DOMAINS and implement proper domain handling hooks. Is this correct? I would say yes. Currently, PM domains are the way to hook SoC-specific integration details into PM transitions. However, if what we want/need are only ways to introduce SoC-specific integration details into non-PM transitions (e.g. probe/remove), maybe bus notifiers would suffice here. e.g. you'd get a bus notifier when the device is added/attached and any init-time pinctrl setup could be done then. This still keeps drivers clean of SoC-specific integration data/code, and also allows that to happen whether or not PM features are enabled. 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] gpio: omap-gpio: add support for pm_runtime autosuspend
Santosh Shilimkar santosh.shilim...@ti.com writes: [...] Just to summaries, there are 3 things we are talking here. Santosh, thanks for the summary. You are right on. 1. Delaying the idle with a timeout which $subject patch is trying to do to reduce latency for interrupts. That itself is reasonable. I agree, this is reasonable. IMO, adding autosuspend should be done as an isolated patch and kept separate from any other cleanup or changes. Also, as Jon mentioned, I think this should be done with a default timeout of zero so that current behaviour is unchanged. Tim can then set the timeout from userspace for his usecase and everyone is happy. 2. Removal of the bank mod_usage which is also clubbed in $subject path. Ofcourse that break the current driver for idle. So that change needs to be made with better thought and in a separate patch. This is doable. I had this discussion with Charu/Tarun during the last round of cleanup because I didn't like this mod_usage either. The alternative is to do a 'get' for every GPIO in the bank since runtime PM is doing the usecounting already. As Santosh said, this is fine for suspend, but for idle it means calling 'put' for every enabled GPIO in the bank instead of just forcing things with a single 'put.' 3. Removing omap_gpio_[prepare/resume]_for_idle() with soome thing better. For this one though, so far I have not come across a good solution. Ideas/Solution is welcome !! I agree that the prepare/resume idle hooks a are ugly and should be removed, but this needs quite a bit more thought. In particular, the 'remove triggering' stuff that is done needs pretty close examination. I'm not saying it can't be done, but patches to do this should be separate, well described and well tested, especially with off-mode. 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: OMAP baseline test results for v3.7-rc1
Hi Jean, Jean Pihet jean.pi...@newoldbits.com writes: [...] Based on a very quick look, I'd say the original patch 3db11fe is broken. I don't see how it can ensure that its PM_QOS_CPU_DMA_LATENCY request is honored when CONFIG_CPU_IDLE=n. CONFIG_CPU_IDLE=n is the default for omap2plus_defconfig. Withtout CPU_IDLE set the PM QoS has no influence on the power domains states. Exactly, which means there is *no* constraint set when CPUidle is disabled, and it's exactly this that is different from the behavior before your patch. Before your patch, the constraint would be set whether or not CPUidle was enabled, correct? The solution to this will probably be to make OMAPs non-CPUidle idle path check the constraints. 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: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Linus Walleij linus.wall...@linaro.org writes:
On Tue, Oct 30, 2012 at 12:34 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Sun, Oct 28, 2012 at 09:12:52PM +0100, Linus Walleij wrote:
Moving this handling to bus code or anywhere else
invariably implies that resource acquisition/release order
does not matter, and my point is that it does.
Doing this in the buses is definitely wrong, as you say it's not bus
specific. I do however think we can usefully do this stuff in a SoC
specific place like a power domain, keeping the SoC integration code
together and out of the drivers. IME the SoCs where you need to do
different things for different IPs shoudl mostly still get some reuse
out of such an approach.
Talking to Kevin Hilman today he was also stressing that
power domains is a good thing for handling resources, especially
when replacing prior hacks in the custom clk code. However
he pointed specifically to clocks and voltages, which may
be true.
What worries me is when knowledge of the hardware which
is traditionally a concern for the device driver start to
bubble up to the power domain (or better renamed resource
domain if use like this, as Felipe points out).
I worry that we will end up with power/resource domain
code that start to look like this:
suspend()
switch (device.id) {
case DEV_FOO:
clk_disable();
pinctrl_set_state();
power_domain_off();
case DEV_BAR:
pinctrl_set_state();
clk_disable();
// Always-on domain
case DEV_BAZ:
pinctrl_set_state();
clk_disable();
power_domain_off();
case ...
Mutate the above with silicon errata, specific tweaks etc that
Felipe was mentioning.
like this, as well as a bunch more. This is why we have a generic
description of IP blocks (omap_hwmod) which abstracts all of these
differences and keeps the PM domain layer rather simple.
I agree with Mark. Either you have to take care of this with
conditional code in the driver, and the drivers become bloated with a
mess of SoC integration details, or you hide it away in SoC-specific
code that can handle this, and keep the drivers portable.
Now that we have PM domains (PM domains didn't exist when we created
omap_device/omap_hwmod), I suspect the cleanest way to do this is to
create separate PM domains for each class of devices that have
different set of behavior.
What is happening is that device-specific behaviour which
traditionally handled in the driver is now inside the
power/resource domain.
piece of hardware, this would be the right thing to do,
and I think the in-kernel examples are all simple,
e.g. arch/arm/mach-omap2/powerdomain* is all about
power domains and nothing else,
FYI... that code isn't the same as PM domain. That code is for the
*hardware* powerdomains, not the software concept of PM domain. In
OMAP, PM domain is implmented at the omap_device level. And omap_device
is the abstraction of an IP block that knows about all the PM related
register settings, clocks, HW powerdomain, voltage domain, PM related
pin-muxing etc. etc.All of these things are abstracted in an
omap_device, so that the PM domain implementation for OMAP looks rather
simple (c.f. omap_device_pm_domain in arch/arm/plat-omap/omap_device.c.)
Note that the callbacks just call omap_device_enable(),
omap_device_disable() and all the HW ugliness, SoC-specific integration
mess is hidden away.
[...]
I think the lesser of two evils is the distributed approach,
and then I'm talking about pinctrl only, disregarding the
fact that clocks and power domains are basically subject to
the same kind of argument. I still buy into the concept of
using power domains for exactly power domains only.
Arguably this is an elegance opinion...
The pinctrl examples I've seen mentioned so far are all PM related
(sleep, idle, wakeup, etc.) so to me I think they still belong in
PM domains (and that's how we handle the PM related pins in OMAP.)
I worry that the per-SoC power domain implementation
which will live in arch/arm/mach-* as of today will become
the new board file problem, overburdening the arch/* tree.
Maybe I'm mistaken as to the size of these things,
but just doing ls arch/arm/mach-omap2/powerdomain*
makes me start worrying.
Yes, I agree that this means more code/data in arch/arm/mach-*, but
IMO, that's really where it belongs. It really is SoC integration
details, and driver should really not know about it.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] ARM: omap: vc: replace data_shift with data_mask
Mike Turquette mturque...@ti.com writes: From: Mike Turquette mturque...@linaro.org Signed-off-by: Mike Turquette mturque...@linaro.org Re: $SUBJECT... ok, I'll bite why? (I'm sure I will find out when I read the rest of the series, but I'm impatient and picky and would like to know here.) ;) 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 3/5] ARM: omap: vc: .get_voltage callback
Mike Turquette mturque...@ti.com writes:
From: Mike Turquette mturque...@linaro.org
Implement the voltdm-get_voltage callback for the voltage controller
driver.
nit: since it's not actually used in this series, it should say
Impelment the function that will be used as the -get_voltage()
callback...
This reads the DATA field corresponding to each VC and returns
the voltage, after converting it from vsel format.
If DATA is zero (the reset value) then the caller must interpret this as
the PMIC running at the default power-on voltage. In such a case DT
data for the PMIC is necessary to know the voltage.
Signed-off-by: Mike Turquette mturque...@ti.com
Signed-off-by: Mike Turquette mturque...@linaro.org
---
arch/arm/mach-omap2/vc.c | 21 +
arch/arm/mach-omap2/vc.h |1 +
2 files changed, 22 insertions(+)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 2bcac64..90a9ea6 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -101,6 +101,27 @@ static int omap_vc_config_channel(struct voltagedomain
*voltdm)
}
/* Voltage scale and accessory APIs */
+unsigned long omap_vc_get_bypass_data(struct voltagedomain *voltdm)
+{
+ struct omap_vc_channel *vc = voltdm-vc;
+ u32 vc_bypass_value;
+ u8 vsel;
+ unsigned long volt;
+
+ /* sanity */
+ if (!voltdm-pmic || !voltdm-pmic-vsel_to_uv ||
+ !voltdm-read || !voltdm-write)
+ return 0;
+
+ vc_bypass_value = voltdm-read(vc-common-bypass_val_reg);
+ vc_bypass_value = vc-common-data_mask;
+ vsel = vc_bypass_value __ffs(vc-common-data_mask);
Ah, now I see where the data_mask is used. :)
Kevin
+ volt = voltdm-pmic-vsel_to_uv(vsel);
+
+ return volt;
+}
+
int omap_vc_pre_scale(struct voltagedomain *voltdm,
unsigned long target_volt,
u8 *target_vsel, u8 *current_vsel)
diff --git a/arch/arm/mach-omap2/vc.h b/arch/arm/mach-omap2/vc.h
index 84a61b1..e7d4719 100644
--- a/arch/arm/mach-omap2/vc.h
+++ b/arch/arm/mach-omap2/vc.h
@@ -112,6 +112,7 @@ extern struct omap_vc_channel omap4_vc_iva;
extern struct omap_vc_channel omap4_vc_core;
void omap_vc_init_channel(struct voltagedomain *voltdm);
+unsigned long omap_vc_get_bypass_data(struct voltagedomain *voltdm);
int omap_vc_pre_scale(struct voltagedomain *voltdm,
unsigned long target_volt,
u8 *target_vsel, u8 *current_vsel);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/5] Introduce .get_voltage callback into voltdm
Hi Mike, Mike Turquette mturque...@ti.com writes: From: Mike Turquette mturque...@linaro.org This series creates a new callback for struct voltagedomain, .get_voltage. This fetches the voltage from hardware, if possible, and returns it to the caller. We use this call to populate voltdm-nominal_volt at boot time. I pointed out a couple nitpicky things on individual patches, but otherwise this direction and motiviation for this series looks OK by me. Just some minor comments about the structure of the series. I tend to prefer combining the introduction of a new function with it's usage. It makes review and understanding much easier, IMO. If there are reasons to keep them separate, that's fine too. Just describe the reasons in the cover letter. Thanks, 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 v5] gpio/omap: fix off-mode bug: clear debounce settings on free/reset
Jon Hunter jon-hun...@ti.com writes:
This change was originally titled gpio/omap: fix off-mode bug: clear debounce
clock enable mask on free/reset. The title has been updated slightly to
reflect (what should be) the final fix.
nit: this kind of thing should typically go after the '---' since it's
useful reviewers/maintainers but not necessarily in the permanant git
history.
Otherwise, thanks for taking this over, and hopefully this can still
get in for v3.7-rc.
Kevin
When a GPIO is freed or shutdown, we need to ensure that any debounce settings
are cleared and if the GPIO is the only GPIO in the bank that is currently
using debounce, then disable the debounce clock as well to save power.
Currently, the debounce settings are not cleared on a GPIO free or shutdown
and
so during a context restore on subsequent off-mode transition, the previous
debounce values are restored from the shadow copies (bank-context.debounce*)
leading to mismatch state between driver state and hardware state.
This was discovered when board code was doing
gpio_request_one()
gpio_set_debounce()
gpio_free()
which was leaving the GPIO debounce settings in a confused state. If that
GPIO
bank is subsequently used with off-mode enabled, bogus state would be
restored,
leaving GPIO debounce enabled which then prevented the CORE powerdomain from
transitioning.
To fix this, introduce a new function called _clear_gpio_debounce() to clear
any debounce settings when the GPIO is freed or shutdown. If this GPIO is the
last debounce-enabled GPIO in the bank, the debounce will also be cut.
Please note that we cannot use _gpio_dbck_disable() to disable the debounce
clock because this has been specifically created for the gpio suspend path
and is intended to shutdown the debounce clock while debounce is enabled.
Special thanks to Kevin Hilman for root causing the bug. This fix is a
collaborative effort with inputs from Kevin Hilman, Grazvydas Ignotas and
Santosh Shilimkar.
Testing:
- This has been unit tested on an OMAP3430 Beagle board, by requesting a gpio,
enabling debounce and then freeing the gpio and checking the register
contents, the saved register context and the debounce clock state.
- Kevin Hilman tested on 37xx/EVM board which configures GPIO debounce for the
ads7846 touchscreen in its board file using the above sequence, and so was
failing off-mode tests in dynamic idle. Verified that off-mode tests are
passing with this patch.
V5 changes:
- Corrected author
Reported-by: Paul Walmsley p...@pwsan.com
Cc: Igor Grinberg grinb...@compulab.co.il
Cc: Grazvydas Ignotas nota...@gmail.com
Cc: Jon Hunter jon-hun...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Kevin Hilman khil...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 94cbc84..d335af1 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -251,6 +251,40 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
}
}
+/**
+ * _clear_gpio_debounce - clear debounce settings for a gpio
+ * @bank: the gpio bank we're acting upon
+ * @gpio: the gpio number on this @gpio
+ *
+ * If a gpio is using debounce, then clear the debounce enable bit and if
+ * this is the only gpio in this bank using debounce, then clear the debounce
+ * time too. The debounce clock will also be disabled when calling this
function
+ * if this is the only gpio in the bank using debounce.
+ */
+static void _clear_gpio_debounce(struct gpio_bank *bank, unsigned gpio)
+{
+ u32 gpio_bit = GPIO_BIT(bank, gpio);
+
+ if (!bank-dbck_flag)
+ return;
+
+ if (!(bank-dbck_enable_mask gpio_bit))
+ return;
+
+ bank-dbck_enable_mask = ~gpio_bit;
+ bank-context.debounce_en = ~gpio_bit;
+ __raw_writel(bank-context.debounce_en,
+ bank-base + bank-regs-debounce_en);
+
+ if (!bank-dbck_enable_mask) {
+ bank-context.debounce = 0;
+ __raw_writel(bank-context.debounce, bank-base +
+ bank-regs-debounce);
+ clk_disable(bank-dbck);
+ bank-dbck_enabled = false;
+ }
+}
+
static inline void set_gpio_trigger(struct gpio_bank *bank, int gpio,
unsigned trigger)
{
@@ -539,6 +573,7 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio)
_set_gpio_irqenable(bank, gpio, 0);
_clear_gpio_irqstatus(bank, gpio);
_set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE);
+ _clear_gpio_debounce(bank, gpio);
}
/* Use disable_irq_wake() and enable_irq_wake() functions from drivers */
--
To unsubscribe from
Re: OMAP baseline test results for v3.7-rc2
Matt Porter mpor...@ti.com writes: On Tue, Oct 23, 2012 at 02:03:43PM -0700, Kevin Hilman wrote: Matt Porter mpor...@ti.com writes: [...] Ok, very quick update...no need to mess around with the eeprom. I just received the official word on what will be supported. Since A2 is pre-release, simply go to http://beagleboard.org/support/rma and fill out the form to have it replaced with the current revision (A6). This applies to *anyone* that received a pre-release A2 board. Hmm, doesn't seem the RMA people are aware of this. They just rejected my request since it's not a hardware related issue: Kevin, We only work with hardware related issue here. BeagleBone revision A2 was not officially released. We recommend you to work with the community for support in Uboot. You can post your questions at the BeagleBoard Google Groups: https://groups.google.com/forum/?fromgroups=#!forum/beagleboard Regards, RMA Team That's sad considering the beagleboard.org/BeagleBone hardware designer specifically said they would be replaced via this route. *sigh*. Ok, I'll go back and share this with him. Just and update... Something happened behind the scenes (thanks Matt) and they've accepted my RMA request. I'll be sending back my board in order to get a new one. Thanks, 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] gpio/omap: fix off-mode bug: clear debounce clock enable mask on free/reset
Jon Hunter jon-hun...@ti.com writes: On 10/24/2012 12:10 PM, Kevin Hilman wrote: From: Kevin Hilman khil...@ti.com When a GPIO bank is freed or shutdown, ensure that the banks dbck_enable_mask is cleared also. Otherwise, context restore on subsequent off-mode transition will restore previous value from the shadow copies (bank-context.debounce*) leading to mismatch state between driver state and hardware state. This was discovered when board code was doing gpio_request_one() gpio_set_debounce() gpio_free() which was leaving the GPIO debounce settings in a confused state. If that GPIO bank is subsequently used with off-mode enabled, bogus state would be restored, leaving GPIO debounce enabled which then prevented the CORE powerdomain from transitioning. To fix, ensure that bank-dbck_enable_mask is cleared when the bank is freed/shutdown so debounce state doesn't persist. Special thanks to Grazvydas Ignotas for pointing out a bug in an earlier version that would've disabled debounce on any runtime PM transition. Reported-by: Paul Walmsley p...@pwsan.com Cc: Igor Grinberg grinb...@compulab.co.il Cc: Grazvydas Ignotas nota...@gmail.com Signed-off-by: Kevin Hilman khil...@ti.com --- v2: only clear mask in free/shutdown, not in runtime PM paths, clarified changelog Applies on v3.7-rc2. drivers/gpio/gpio-omap.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 94cbc84..113b167 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -539,6 +539,7 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio) _set_gpio_irqenable(bank, gpio, 0); _clear_gpio_irqstatus(bank, gpio); _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE); +bank-dbck_enable_mask = 0; } Does this need to be ... + bank-dbck_enable_mask = ~(GPIO_BIT(bank, gpio)); + _gpio_dbck_disable(bank); There could be more than one gpio using debounce and so we should only clear the appropriate bit. Also after clearing a bit we could see if we can disable the debounce clock too. Sigh, you're right. I'm clearly in too much of a rush with this one. Thanks for taking the time to review. v3 coming right up using your suggestsion after some testing just to be sure it fixes that bug. 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] gpio/omap: fix off-mode bug: clear debounce clock enable mask on free/reset
Jon Hunter jon-hun...@ti.com writes:
On 10/25/2012 02:00 AM, Santosh Shilimkar wrote:
On Thursday 25 October 2012 04:24 AM, Jon Hunter wrote:
On 10/24/2012 12:10 PM, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
When a GPIO bank is freed or shutdown, ensure that the banks
dbck_enable_mask is cleared also. Otherwise, context restore on
subsequent off-mode transition will restore previous value from the
shadow copies (bank-context.debounce*) leading to mismatch state
between driver state and hardware state.
This was discovered when board code was doing
gpio_request_one()
gpio_set_debounce()
gpio_free()
which was leaving the GPIO debounce settings in a confused state. If
that GPIO bank is subsequently used with off-mode enabled, bogus state
would be restored, leaving GPIO debounce enabled which then prevented
the CORE powerdomain from transitioning.
To fix, ensure that bank-dbck_enable_mask is cleared when the bank
is freed/shutdown so debounce state doesn't persist.
The freed part is fine but I don't understand why it needs to be done
on _a_ gpio irq shutdown callback where IRQs related configuration
on that one GPIO needs to be cleared. De-bounce clock is surely not IRQ
related configuration.
If we are freeing the IRQs related to gpio and resetting the gpio, then
I don't see why we should not. We should not leave the debounce clock on
if these gpios are no longer being used.
Special thanks to Grazvydas Ignotas for pointing out a bug in an
earlier version that would've disabled debounce on any runtime PM
transition.
Reported-by: Paul Walmsley p...@pwsan.com
Cc: Igor Grinberg grinb...@compulab.co.il
Cc: Grazvydas Ignotas nota...@gmail.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
v2: only clear mask in free/shutdown, not in runtime PM paths,
clarified changelog
Applies on v3.7-rc2.
drivers/gpio/gpio-omap.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 94cbc84..113b167 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -539,6 +539,7 @@ static void _reset_gpio(struct gpio_bank *bank,
int gpio)
_set_gpio_irqenable(bank, gpio, 0);
_clear_gpio_irqstatus(bank, gpio);
_set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE);
+bank-dbck_enable_mask = 0;
}
Does this need to be ...
+bank-dbck_enable_mask = ~(GPIO_BIT(bank, gpio));
+_gpio_dbck_disable(bank);
Yes, its a per bank clock. There is an alternate. See below.
There could be more than one gpio using debounce and so we should only
clear the appropriate bit. Also after clearing a bit we could see if we
can disable the debounce clock too.
When I mentioned the clearing in gpio_free() path will do trick, I had
something like below in mind.
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index dee2856..8574105 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -629,8 +629,10 @@ static void omap_gpio_free(struct gpio_chip *chip,
unsigned offset)
* If this is the last gpio to be freed in the bank,
* disable the bank module.
*/
-if (!bank-mod_usage)
+if (!bank-mod_usage) {
+bank-dbck_enable_mask = 0;
pm_runtime_put(bank-dev);
+}
However, with this we could be leaving the debounce clock on longer than
needed. I think we need to call _gpio_dbck_disable() each time we free a
gpio and this function will determine if it can turn off the debounce
clock.
In fact, there appears to be another bug in the current driver, that we
do not clear the debounce_en register when freeing the gpio. Your patch
addresses this, but I think that debounce should be disabled when a gpio
is freed and not just when the last one is freed.
Also, with the above change, can't we still run into the original
problem? In other words, if a gpio is freed, but there is still another
one active in the back that is not using debounce, then we could restore
a incorrect debounce context because we have not clean-up the debounce
settings?
So may be we need to add a _clear_gpio_debounce() function and
call this when freeing a gpio.
Care to cook up a patch for this, on top of v3 of $SUBJECT patch?
Thanks,
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 v3] gpio/omap: fix off-mode bug: clear debounce clock enable mask on free/reset
From: Kevin Hilman khil...@ti.com When a GPIO is freed or shutdown, ensure that the proper bit in dbck_enable_mask is cleared also. Otherwise, context restore on subsequent off-mode transition will restore previous debounce values from the shadow copies (bank-context.debounce*) leading to mismatch state between driver state and hardware state. This was discovered when board code was doing gpio_request_one() gpio_set_debounce() gpio_free() which was leaving the GPIO debounce settings in a confused state. If that GPIO bank is subsequently used with off-mode enabled, bogus state would be restored, leaving GPIO debounce enabled which then prevented the CORE powerdomain from transitioning. To fix, ensure that right bit in bank-dbck_enable_mask is cleared when a GPIO is freed/shutdown so debounce state doesn't persist after free/reset. If this GPIO is the last debounce-enabled GPIO in the bank, the debounce will also be cut. Special thanks to Grazvydas Ignotas for pointing out a bug in the first version that would've disabled debounce on any runtime PM transition. And, special thanks to Jon Hunter for pointing out a bug in the second version which was mistakenly clearing all debounce bits on reset instead of individual GPIOs, as well as suggesting cutting the debounce clock after all debounce bits are cleared. Tesed on 37xx/EVM board which configures GPIO debounce for the ads7846 touchscreen in its board file using the above sequence, and so was failing off-mode tests in dynamic idle. Verified that off-mode tests are passing with this patch. Reported-by: Paul Walmsley p...@pwsan.com Cc: Igor Grinberg grinb...@compulab.co.il Cc: Grazvydas Ignotas nota...@gmail.com Cc: Jon Hunter jon-hun...@ti.com Signed-off-by: Kevin Hilman khil...@ti.com --- drivers/gpio/gpio-omap.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 94cbc84..ce1da19 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -539,6 +539,8 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio) _set_gpio_irqenable(bank, gpio, 0); _clear_gpio_irqstatus(bank, gpio); _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE); + bank-dbck_enable_mask = ~(GPIO_BIT(bank, gpio)); + _gpio_dbck_disable(bank); } /* Use disable_irq_wake() and enable_irq_wake() functions from drivers */ -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: omap: ensure writes to dev-buf_len are ordered
+Paul
Felipe Balbi ba...@ti.com writes:
if we allow compiler reorder our writes, we could
fall into a situation where dev-buf_len is reset
for no apparent reason.
Any chance this would help with the bug Paul found with I2C timeouts on
beagle userspace startup?
Kevin
This bug was found with a simple script which would
transfer data to an i2c client from 1 to 1024 bytes
(a simple for loop), when we got to transfer sizes
bigger than the fifo size, dev-buf_len was reset
to zero before we had an oportunity to handle XDR
Interrupt. Because dev-buf_len was zero, we entered
omap_i2c_transmit_data() to transfer zero bytes,
which would mean we would just silently exit
omap_i2c_transmit_data() without actually writing
anything to DATA register. That would cause XDR
IRQ to trigger forever and we would never transfer
the remaining bytes.
After adding the memory barrier, we also drop resetting
dev-buf_len to zero in omap_i2c_xfer_msg() because
both omap_i2c_transmit_data() and omap_i2c_receive_data()
will act until dev-buf_len reaches zero, rendering the
other write in omap_i2c_xfer_msg() redundant.
This patch has been tested with pandaboard for a few
iterations of the script mentioned above.
Signed-off-by: Felipe Balbi ba...@ti.com
---
This bug has been there forever, but it's quite annoying.
I think it deserves being pushed upstream during this -rc
cycle, but if Wolfram decides to wait until v3.8, I don't
mind.
drivers/i2c/busses/i2c-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index db31eae..1ec4e6e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -521,6 +521,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
/* REVISIT: Could the STB bit of I2C_CON be used with probing? */
dev-buf = msg-buf;
dev-buf_len = msg-len;
+ wmb();
omap_i2c_write_reg(dev, OMAP_I2C_CNT_REG, dev-buf_len);
@@ -579,7 +580,6 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
*/
timeout = wait_for_completion_timeout(dev-cmd_complete,
OMAP_I2C_TIMEOUT);
- dev-buf_len = 0;
if (timeout == 0) {
dev_err(dev-dev, controller timed out\n);
omap_i2c_init(dev);
--
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] ARM: PMU: fix runtime PM enable
Jon Hunter jon-hun...@ti.com writes: On 10/24/2012 12:23 PM, Will Deacon wrote: On Wed, Oct 24, 2012 at 04:06:07PM +0100, Jon Hunter wrote: On 10/24/2012 09:32 AM, Will Deacon wrote: Hmmm, now I start to wonder whether your original idea of having separate callbacks for enable/disable irq and resume/suspend doesn't make more sense. Then the CTI magic can go in the irq management code and be totally separate to the PM stuff. What do you reckon? The resume/suspend calls really replaced the enable/disable irq callbacks. That still seems like a good approach given that we need runtime PM for OMAP and PMU. Ok, perhaps splitting it up isn't worth it then. I'm still not convinced either way. Given that we needed to employ runtime PM for OMAP, adding the handlers is a natural progression and fits more with the PM framework model. Nah, we should be able to fix this in the platdata, I'd just rather have function pointers instead of state variables in there. Well, we could pass a pointer to pm_runtime_enable() function in the platdata. What do other drivers do? Grepping around, I see calls to pm_runtime_enable made in various drivers and, given that you pass the device in there, what's the problem with us just calling that unconditionally from perf? I know you said that will work for OMAP, but I'm trying to understand the effect that has on PM-aware platforms that don't require this for the PMU (since this seems to be per-device). I had done this initially when testing on OMAP platforms that do and don't require runtime PM for PMU. I don't see any side affect of this, however, may be Kevin could comment on if that is ok. It would be the best approach. Unconditonally enabling runtime PM should be fine. It may add a slight bit of overhead calling runtime PM functions that ultimately do nothing (because there are no callbacks), but it will be harmless. Personally, I think that would be cleaner. The less pdata we need, the better, IMO. 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: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)
Tony Lindgren t...@atomide.com writes: * Russell King - ARM Linux li...@arm.linux.org.uk [121023 03:12]: On Fri, Oct 12, 2012 at 04:54:34PM +0100, Russell King - ARM Linux wrote: For those who don't bother looking at my kautobuild boot tests on the OMAP boards I have, here's the errors which get spat out at boot time. Note that some of these I've reported in the past, and one of them is missing a newline character at the end of its string. twd: can't register interrupt 45 (-22) twd_local_timer_register failed -22 omap_hwmod: mcpdm: cannot be enabled for reset (3) omap-gpmc omap-gpmc: error: clk_get omap-gpmc: probe of omap-gpmc failed with error -2 Error setting wl12xx data: -38 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap_hsmmc omap_hsmmc.4: Failed to get debounce clk twl6040-codec twl6040-codec: ASoC: Failed to create Capture debugfs file omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0). omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels (0).Power Management for TI OMAP4. mmc1: host does not support reading read-only switch. assuming write-enable. Here's the latest set of error like messages, thanks to the kautobuild system: omap_hwmod: mcpdm: cannot be enabled for reset (3) Error setting wl12xx data: -38 That's now fixed up and I've queued it. omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap_hsmmc omap_hsmmc.4: Failed to get debounce clk omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0). omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels (0).Power Management for TI OMAP4. mmc1: host does not support reading read-only switch. assuming write-enable. This looks much better compared to the previous set, but we could still do with getting a \n on at least one of those messages... Kevin, do you have a patch for some of this? I'll fix up the missing newline right away. I was planning to leave the VC mismatch problem because it's fixed in Tero's auto retention series. However, I haven't been able to get to that series yet due to all the regressions/bugfixes, so I'll at least pull out the part that fixes up the mistmatch and submit it for v3.7. Kevin [1] http://marc.info/?l=linux-omapm=134859084918176w=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] ARM: OMAP2+: PM: add missing newline to VC warning message
From: Kevin Hilman khil...@ti.com
Add missing newline to warning message to avoid annoying
wrapping problems during kernel boot like this one:
omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0).
omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels
(0).Power Management for TI OMAP4.
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/vc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 880249b..75878c3 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -264,7 +264,7 @@ static void __init omap_vc_i2c_init(struct voltagedomain
*voltdm)
if (initialized) {
if (voltdm-pmic-i2c_high_speed != i2c_high_speed)
- pr_warn(%s: I2C config for vdd_%s does not match other
channels (%u).,
+ pr_warn(%s: I2C config for vdd_%s does not match other
channels (%u).\n,
__func__, voltdm-name, i2c_high_speed);
return;
}
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)
Kevin Hilman khil...@deeprootsystems.com writes: Tony Lindgren t...@atomide.com writes: [...] omap_hsmmc omap_hsmmc.4: Failed to get debounce clk omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0). omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels (0).Power Management for TI OMAP4. mmc1: host does not support reading read-only switch. assuming write-enable. This looks much better compared to the previous set, but we could still do with getting a \n on at least one of those messages... Kevin, do you have a patch for some of this? I'll fix up the missing newline right away. Patch sent. I was planning to leave the VC mismatch problem because it's fixed in Tero's auto retention series. However, I haven't been able to get to that series yet due to all the regressions/bugfixes, so I'll at least pull out the part that fixes up the mistmatch and submit it for v3.7. On closer look, I don't think a quick fix is right for this one. Those I2C config mismatch warnings are legitmate for now, and will be fixed when Tero's series is merged. Kevin Kevin [1] http://marc.info/?l=linux-omapm=134859084918176w=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
Re: [PATCH V2] ARM: PMU: fix runtime PM enable
Jon Hunter jon-hun...@ti.com writes: Commit 7be2958 (ARM: PMU: Add runtime PM Support) updated the ARM PMU code to use runtime PM which was prototyped and validated on the OMAP devices. In this commit, there is no call pm_runtime_enable() and for OMAP devices pm_runtime_enable() is currently being called from the OMAP PMU code when the PMU device is created. However, there are two problems with this: 1. For any other ARM device wishing to use runtime PM for PMU they will need to call pm_runtime_enable() for runtime PM to work. 2. When booting with device-tree and using device-tree to create the PMU device, pm_runtime_enable() needs to be called from within the ARM PERF driver as we are no longer calling any device specific code to create the device. Hence, PMU does not work on OMAP devices that use the runtime PM callbacks when using device-tree to create the PMU device. Therefore, call pm_runtime_enable() directly from the ARM PMU driver when registering the device. For platforms that do not use runtime PM, pm_runtime_enable() does nothing and for platforms that do use runtime PM but may not require it specifically for PMU, this will just add a little overhead when initialising and uninitialising the PMU device. Tested with PERF on OMAP2420, OMAP3430 and OMAP4460. V2 changes: - Call pm_runtime_enable() unconditionally on registering the PMU device. Signed-off-by: Jon Hunter jon-hun...@ti.com Acked-by: Kevin Hilman khil...@ti.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 V2] ARM: OMAP2+: PM: VP: minor pr_warn updates
Nishanth Menon n...@ti.com writes: change pr_warnings to pr_warn and ensure a newline is present in all messages Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Signed-off-by: Nishanth Menon n...@ti.com Thanks queuing for v3.8 as PM cleanup (branch: for_3.8/cleanup/pm.) 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 v3] gpio/omap: fix off-mode bug: clear debounce clock enable mask on free/reset
Jon Hunter jon-hun...@ti.com writes: Hi Kevin, On 10/25/2012 11:34 AM, Kevin Hilman wrote: From: Kevin Hilman khil...@ti.com When a GPIO is freed or shutdown, ensure that the proper bit in dbck_enable_mask is cleared also. Otherwise, context restore on subsequent off-mode transition will restore previous debounce values from the shadow copies (bank-context.debounce*) leading to mismatch state between driver state and hardware state. This was discovered when board code was doing gpio_request_one() gpio_set_debounce() gpio_free() which was leaving the GPIO debounce settings in a confused state. If that GPIO bank is subsequently used with off-mode enabled, bogus state would be restored, leaving GPIO debounce enabled which then prevented the CORE powerdomain from transitioning. To fix, ensure that right bit in bank-dbck_enable_mask is cleared when a GPIO is freed/shutdown so debounce state doesn't persist after free/reset. If this GPIO is the last debounce-enabled GPIO in the bank, the debounce will also be cut. Special thanks to Grazvydas Ignotas for pointing out a bug in the first version that would've disabled debounce on any runtime PM transition. And, special thanks to Jon Hunter for pointing out a bug in the second version which was mistakenly clearing all debounce bits on reset instead of individual GPIOs, as well as suggesting cutting the debounce clock after all debounce bits are cleared. ... and for introducing yet another bug :-( Tesed on 37xx/EVM board which configures GPIO debounce for the ads7846 touchscreen in its board file using the above sequence, and so was failing off-mode tests in dynamic idle. Verified that off-mode tests are passing with this patch. Reported-by: Paul Walmsley p...@pwsan.com Cc: Igor Grinberg grinb...@compulab.co.il Cc: Grazvydas Ignotas nota...@gmail.com Cc: Jon Hunter jon-hun...@ti.com Signed-off-by: Kevin Hilman khil...@ti.com --- drivers/gpio/gpio-omap.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 94cbc84..ce1da19 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -539,6 +539,8 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio) _set_gpio_irqenable(bank, gpio, 0); _clear_gpio_irqstatus(bank, gpio); _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE); +bank-dbck_enable_mask = ~(GPIO_BIT(bank, gpio)); +_gpio_dbck_disable(bank); We can't use _gpio_dbck_disable() here. This has been specifically implemented for the suspend path and is designed to disable the debounce clock while debounce is enabled (which makes sense). I agree, it makes sense. It reminds me that this driver could use some comments, since each time I come back to it I forget why some of this stuff is there. Yes this needs to be cleaned up. Most certainly agree. I have implemented the following and unit tested. Care to test on your 37xx board? Sorry I would do it myself I had one. Yes, it fixes the off-mode dynamic idle problem on my 37xx EVM. Also not sure if you just wish to squash your patch and mine together. This is based on top of yours. Let's just drop mine and you can take this forward. Cheers Jon From 33812f3bd4f7aab1154e7194b7f11fba700a5086 Mon Sep 17 00:00:00 2001 From: Jon Hunter jon-hun...@ti.com Date: Thu, 25 Oct 2012 16:00:51 -0500 Subject: [PATCH] gpio/omap: fix clearing of debounce settings on gpio free/reset When a GPIO is freed or shutdown, we need to ensure that any debounce settings are cleared and if the GPIO is the only GPIO in the bank that is currently using debounce, then disable the debounce clock as well to save power. Since this is a fix needed for v3.7-rc, you should add a bit more here describing what was broken (bogus context restore, etc.) Basically answering why to your the we need to ensure that... statement. Therefore, introduce a new function called _clear_gpio_debounce() to clear any debounce settings when the GPIO is freed or shutdown. Please note that we cannot use _gpio_dbck_disable() to disable the debounce clock because this has been specifically created for the gpio suspend path and is intended to shutdown the debounce clock while debounce is enabled. This has been unit tested on an OMAP3430 Beagle board, by requesting a gpio, enabling debounce and then freeing the gpio and checking the register contents, the saved register context and the debounce clock state. Signed-off-by: Jon Hunter jon-hun...@ti.com Reviewed-by: Kevin Hilman khil...@ti.com (though not that that matters now that I've shown a high-level of incompetence with this patch) ;) Also, Tested-by: Kevin Hilman khil...@ti.com When reposting for Linus W., you might make this 'v4' so that it's clear that it superceeds the other bungling attempts at the same fix. Thanks for following this through, Kevin -- To unsubscribe from
Re: [PATCH v2 5/7] crypto: omap-sham: Convert to use pm_runtime API
Hi Mark, Mark A. Greer mgr...@animalcreek.com writes: From: Mark A. Greer mgr...@animalcreek.com Convert the omap-sham crypto driver to use the pm_runtime API instead of the clk API. CC: Kevin Hilman khil...@deeprootsystems.com CC: Paul Walmsley p...@pwsan.com CC: Dmitry Kasatkin dmitry.kasat...@intel.com Signed-off-by: Mark A. Greer mgr...@animalcreek.com I can't pretend to fully understand this driver, It looks like the current code is doing a bit more fine-grained clock gating, and leaving the IP clocked only when needed. The proposed version does a 'get' in probe and a 'put' in remove, which means the IP will always be enabled (and thus preventing low-power states), even when it's not in use. If that's really needed, it should be thoroughly described in the changelog, otherwise I suggest doing the runtime PM 'get' and 'put' in roughtly the same spots as the current clk enable/disable which makes this a more straight-forward conversion. 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] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
Grazvydas Ignotas nota...@gmail.com writes: On Tue, Oct 23, 2012 at 9:09 PM, Kevin Hilman khil...@deeprootsystems.com wrote: From: Kevin Hilman khil...@ti.com When debounce clocks are disabled, ensure that the banks dbck_enable_mask is cleared also. Otherwise, context restore on subsequent off-mode transition will restore previous value from the shadow copies (bank-context.debounce*) leading to mismatch state between driver state and hardware state. This doesn't look right to me, aren't you effectively disabling debounce forever here? _gpio_dbck_disable is called from omap_gpio_runtime_suspend() and nothing will ever restore dbck_enable_mask back to what it was set by _set_gpio_debounce and debounce functionality is lost. Yes, you're right. Good catch. I need a fix that's more targetted to the free/reset path. Linus, please revert if it's not too late, and I'll come up with a more targetted fix. 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 v2] gpio/omap: fix off-mode bug: clear debounce clock enable mask on free/reset
From: Kevin Hilman khil...@ti.com When a GPIO bank is freed or shutdown, ensure that the banks dbck_enable_mask is cleared also. Otherwise, context restore on subsequent off-mode transition will restore previous value from the shadow copies (bank-context.debounce*) leading to mismatch state between driver state and hardware state. This was discovered when board code was doing gpio_request_one() gpio_set_debounce() gpio_free() which was leaving the GPIO debounce settings in a confused state. If that GPIO bank is subsequently used with off-mode enabled, bogus state would be restored, leaving GPIO debounce enabled which then prevented the CORE powerdomain from transitioning. To fix, ensure that bank-dbck_enable_mask is cleared when the bank is freed/shutdown so debounce state doesn't persist. Special thanks to Grazvydas Ignotas for pointing out a bug in an earlier version that would've disabled debounce on any runtime PM transition. Reported-by: Paul Walmsley p...@pwsan.com Cc: Igor Grinberg grinb...@compulab.co.il Cc: Grazvydas Ignotas nota...@gmail.com Signed-off-by: Kevin Hilman khil...@ti.com --- v2: only clear mask in free/shutdown, not in runtime PM paths, clarified changelog Applies on v3.7-rc2. drivers/gpio/gpio-omap.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 94cbc84..113b167 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -539,6 +539,7 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio) _set_gpio_irqenable(bank, gpio, 0); _clear_gpio_irqstatus(bank, gpio); _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE); + bank-dbck_enable_mask = 0; } /* Use disable_irq_wake() and enable_irq_wake() functions from drivers */ -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
Paul Walmsley p...@pwsan.com writes: Hi Tero, On Mon, 22 Oct 2012, Tero Kristo wrote: When waking up from off-mode, some IP blocks are reset automatically by hardware. For this reason, software must wait until the reset has completed before attempting to access the IP block. This patch fixes for example the bug introduced by commit 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c (mmc: omap_hsmmc: remove access to SYSCONFIG register), in which the MMC IP block is reset during off-mode entry, but the code expects the module to be already available during the execution of context restore. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com Cc: Venkatraman S svenk...@ti.com What do you think about these modifications? The code is quite similar to what was in the _ocp_softreset() function, so just moved it into a function. Also moved the callsite from the end of _enable_sysc() to the beginning, which makes more sense to me, but would like to get your opinion. FYI, after some more testing with this patch, I noticed that this patch (and the original from Tero) cause some sluggishness on UART1 console my 37xx/EVM platform as soon as off-mode is enabled (even without the UART autosuspend timeouts enabled.) I don't see this on any other OMAP3 platform but all the others I have have UART3 console (in PER), the EVM is the only one with UART1 console (in CORE.) I haven't debugged this any furhter, but thought it should be reported before this gets merged. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
Shubhrajyoti Datta omaplinuxker...@gmail.com writes: On Tue, Oct 23, 2012 at 3:16 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Tero Kristo t-kri...@ti.com writes: When waking up from off-mode, some IP blocks are reset automatically by hardware. For this reason, software must wait until the reset has completed before attempting to access the IP block. This patch fixes for example the bug introduced by commit 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c (mmc: omap_hsmmc: remove access to SYSCONFIG register), in which the MMC IP block is reset during off-mode entry, but the code expects the module to be already available during the execution of context restore. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com Cc: Venkatraman S svenk...@ti.com I can confirm that this patch the regression in my OMAP3 PM tests where suspend test (to retention or off) failed if ran after the off-idle test. Tested-by: Kevin Hilman khil...@ti.com on 3530/Overo, 3730/OveroSTORM, 3730/Beagle-xM on 3630/Beagle works. However on 3430 on idle path didnot work. let me know if i am missing some thing. Could you please explain what worked and didn't work on each platforms? Also, which 3430 did you test on? If it's SDP, then it has a UART1 console, correct? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
Kevin Hilman khil...@deeprootsystems.com writes: Paul Walmsley p...@pwsan.com writes: Hi Tero, On Mon, 22 Oct 2012, Tero Kristo wrote: When waking up from off-mode, some IP blocks are reset automatically by hardware. For this reason, software must wait until the reset has completed before attempting to access the IP block. This patch fixes for example the bug introduced by commit 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c (mmc: omap_hsmmc: remove access to SYSCONFIG register), in which the MMC IP block is reset during off-mode entry, but the code expects the module to be already available during the execution of context restore. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com Cc: Venkatraman S svenk...@ti.com What do you think about these modifications? The code is quite similar to what was in the _ocp_softreset() function, so just moved it into a function. Also moved the callsite from the end of _enable_sysc() to the beginning, which makes more sense to me, but would like to get your opinion. FYI, after some more testing with this patch, I noticed that this patch (and the original from Tero) cause some sluggishness on UART1 console my 37xx/EVM platform as soon as off-mode is enabled (even without the UART autosuspend timeouts enabled.) I don't see this on any other OMAP3 platform but all the others I have have UART3 console (in PER), the EVM is the only one with UART1 console (in CORE.) OK, found it. The reason for the sluggishness is that the GPIO blocks are timing out in the omap_test_timout() calls added in this patch, suggesting that they never detect reset done. Looking at the other user of _wait_softreset_complete made me remember that there modules that need their optional clocks enabled in order for softreset to work. It appears that the optional clocks are needed not only to initiate a softrest, but also to check SYSS.RESETDONE. The patch below on top of Paul's version makes the sluggishness disappear. Kevin diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index f9d8b2a..70267d2 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -1320,7 +1320,11 @@ static void _enable_sysc(struct omap_hwmod *oh) * (off-mode for example), and the drivers require the * IP to be ready when they access it */ + if (oh-flags HWMOD_CONTROL_OPT_CLKS_IN_RESET) + _enable_optional_clocks(oh); _wait_softreset_complete(oh); + if (oh-flags HWMOD_CONTROL_OPT_CLKS_IN_RESET) + _disable_optional_clocks(oh); v = oh-_sysc_cache; sf = oh-class-sysc-sysc_flags; -- 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] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
From: Kevin Hilman khil...@ti.com When debounce clocks are disabled, ensure that the banks dbck_enable_mask is cleared also. Otherwise, context restore on subsequent off-mode transition will restore previous value from the shadow copies (bank-context.debounce*) leading to mismatch state between driver state and hardware state. This was discovered when board code was doing gpio_request_one() gpio_set_debounce() gpio_free() which was leaving the GPIO debounce settings in a confused state. Then, enabling off mode causing bogus state to be restored, leaving GPIO debounce enabled which then prevented the CORE powerdomain from transitioning. Reported-by: Paul Walmsley p...@pwsan.com Cc: Igor Grinberg grinb...@compulab.co.il Signed-off-by: Kevin Hilman khil...@ti.com --- Applies on v3.7-rc2, targetted for v3.7. drivers/gpio/gpio-omap.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 94cbc84..dee2856 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -187,6 +187,7 @@ static inline void _gpio_dbck_disable(struct gpio_bank *bank) * to detect events and generate interrupts at least on OMAP3. */ __raw_writel(0, bank-base + bank-regs-debounce_en); + bank-dbck_enable_mask = 0; clk_disable(bank-dbck); bank-dbck_enabled = false; -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc2
Kevin Hilman khil...@deeprootsystems.com writes: +Igor Paul Walmsley p...@pwsan.com writes: Here are some basic OMAP test results for Linux v3.7-rc2. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/ [...] * 37xx EVM: CORE not entering dynamic off-idle - Cause unknown; dynamic retention-idle seems to work; system suspend to off works I got a start on this one, and discovered (using CM_IDLEST1_CORE) that SPI1 was not idle when going off. A quick hack disabling the touchscreen showed that after that, core was hitting idle just fine. I ran out of time today debugging this, but it's definitely realted to the GPIO debounce setting for the touchscreen. Changing it to zero[1] makes CORE hit retention again in idle. OK, found the root cause of this in the GPIO driver. Patch submitted: http://marc.info/?l=linux-omapm=135101577925972w=2 however... Igor, I'm hoping you might know what's going on here since we already had some problems with this ads7846 init stuff and you're more familiar with this debounce init. ... board files that are setting debounce values for ads7846 will no longer work. Currently, omap_ads7846_init() in common-board-devices.c does this: gpio_request_one() gpio_set_debounce() gpio_free() because of a bug in the GPIO driver, the debounce settings were sticky and lingered even after the gpio_free(). That bug has been fixed by the above patch, which means the above gpio_set_debounce() is completely pointless because it's followed immediately by a gpio_free(). IMO, the whole GPIO init for the ads7846 needs a rethink as it's currently partially done by common-board-devices.c and done (again) in the ads7846 driver. If the gpio_free() isn't done in common-board-devices, then the ads7846 driver will currently fail to probe/load becasue it can't request a GPIO line. Having found and fixed the PM regression, I'll leave the ads7846 cleanup to somone else. 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: OMAP baseline test results for v3.7-rc1
Jean Pihet jean.pi...@newoldbits.com writes: Hi, On Sat, Oct 20, 2012 at 8:14 AM, Paul Walmsley p...@pwsan.com wrote: Hi Jean On Fri, 19 Oct 2012, Paul Walmsley wrote: On Thu, 18 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ ... Failing tests: needing investigation Boot tests: * 3530ES3 Beagle: I2C timeouts during userspace init - May be related to the threaded IRQ conversion of the I2C driver - Unknown cause This one turned out to be caused by: commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc Author: Jean Pihet jean.pi...@newoldbits.com Date: Thu Sep 20 18:08:03 2012 +0200 ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints Reverting this commit causes the problem to go away, but since the OMAP PM constraint code was removed as well, it's unlikely that a simple revert is the right thing to do. Jean could you please investigate and fix this? I tried the latest l-o with omap2plus defconfig on my Beagleboard B5 (ES2.1) and could not reproduce the problem. I do not have the I2C error messages at boot, nor at user space start up. I tried to read/write the TWL RTC, successfully. Another difference is the bootloader images. I have the following: - Texas Instruments X-Loader 1.4.2 (Feb 3 2009 - 15:34:17) - U-Boot 2009.01-dirty (Feb 19 2009 - 12:22:31) Could you send your bootloader images? I noticed you have I2C error messages in U-Boot, could that be the cause of the I2C lock-up? FWIW, I have a relatively recent mainline u-boot+SPL: U-Boot SPL 2012.04.01 (Jul 03 2012 - 07:07:04) U-Boot 2012.04.01 (Jul 03 2012 - 07:07:04) And I see I2C error messages from u-boot too: timed out in wait_for_pin: I2C_STAT=0 I2C read: I/O error I think these are normal/expected since u-boot may be looking for expansion cards. 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: OMAP baseline test results for v3.7-rc2
Matt Porter mpor...@ti.com writes: [...] Ok, very quick update...no need to mess around with the eeprom. I just received the official word on what will be supported. Since A2 is pre-release, simply go to http://beagleboard.org/support/rma and fill out the form to have it replaced with the current revision (A6). This applies to *anyone* that received a pre-release A2 board. Hmm, doesn't seem the RMA people are aware of this. They just rejected my request since it's not a hardware related issue: Kevin, We only work with hardware related issue here. BeagleBone revision A2 was not officially released. We recommend you to work with the community for support in Uboot. You can post your questions at the BeagleBoard Google Groups: https://groups.google.com/forum/?fromgroups=#!forum/beagleboard Regards, RMA Team -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
Felipe Balbi ba...@ti.com writes:
Hi,
On Tue, Oct 23, 2012 at 11:09:31AM -0700, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
When debounce clocks are disabled, ensure that the banks
dbck_enable_mask is cleared also. Otherwise, context restore on
subsequent off-mode transition will restore previous value from the
shadow copies (bank-context.debounce*) leading to mismatch state
between driver state and hardware state.
This was discovered when board code was doing
gpio_request_one()
gpio_set_debounce()
gpio_free()
which was leaving the GPIO debounce settings in a confused state.
Then, enabling off mode causing bogus state to be restored, leaving
GPIO debounce enabled which then prevented the CORE powerdomain from
transitioning.
Reported-by: Paul Walmsley p...@pwsan.com
Cc: Igor Grinberg grinb...@compulab.co.il
Signed-off-by: Kevin Hilman khil...@ti.com
looks like this deserves a Cc: sta...@vger.kernel.org tag.
Agreed. I think this goes all the way back to v3.5, but would've only
been seen on boards using a request/gpio_set_debounce/free sequence
combined with off-mode.
Linus, feel free to add the Cc: stable when commiting. Thanks.
---
Applies on v3.7-rc2, targetted for v3.7.
drivers/gpio/gpio-omap.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 94cbc84..dee2856 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -187,6 +187,7 @@ static inline void _gpio_dbck_disable(struct gpio_bank
*bank)
* to detect events and generate interrupts at least on OMAP3.
*/
__raw_writel(0, bank-base + bank-regs-debounce_en);
+bank-dbck_enable_mask = 0;
shouldn't omap_gpio_restore_context() check for dbck_enabled instead of
the mask ? I mean:
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 94cbc84..b3a39a7 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1371,7 +1371,7 @@ static void omap_gpio_restore_context(struct gpio_bank
*bank)
bank-base + bank-regs-dataout);
__raw_writel(bank-context.oe, bank-base + bank-regs-direction);
- if (bank-dbck_enable_mask) {
+ if (bank-dbck_enabled) {
__raw_writel(bank-context.debounce, bank-base +
bank-regs-debounce);
__raw_writel(bank-context.debounce_en,
the outcome would be the same, so it doesn't really matter. Just that,
at least to me, it would look better.
I tried your version, and unfortunately, the outcome is not the same,
but don't plan to look into why. $SUBJECT version is targetted and
tested. If you want to cleanup the cosmetics here, please do in a
subsequent patch. This driver could certainly benefit from more
readability cleanups.
No strong feelings though.
Good. I'll take that as an Ack. :)
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
[GIT PULL] ARM: OMAP: PM fixes for v3.7-rc3
Tony, Here are a few more fixes PM-related fixes for v3.7-rc Kevin The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.7-rc3-fixes-pm for you to fetch changes up to 65bf7ca0005d7d827596d5df28583c83c9158da6: ARM: OMAP3: Beagle: fix OPP customization and initcall ordering (2012-10-22 16:01:42 -0700) Misc. OMAP PM-related fixes for v3.7-rc Kevin Hilman (2): ARM: OMAP2: UART: fix console UART mismatched runtime PM status ARM: OMAP3: Beagle: fix OPP customization and initcall ordering Paul Walmsley (1): ARM: OMAP3: PM: apply part of the erratum i582 workaround arch/arm/mach-omap2/board-omap3beagle.c | 22 +- arch/arm/mach-omap2/pm.h| 1 + arch/arm/mach-omap2/pm34xx.c| 30 -- arch/arm/mach-omap2/serial.c| 5 + 4 files changed, 47 insertions(+), 11 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] genirq: provide means to retrigger parent
Russell King - ARM Linux li...@arm.linux.org.uk writes: On Tue, Oct 16, 2012 at 03:07:49PM -0700, Kevin Hilman wrote: From: Thomas Gleixner t...@linutronix.de Attempts to retrigger nested threaded IRQs currently fail because they have no primary handler. In order to support retrigger of nested IRQs, the parent IRQ needs to be retriggered. To fix, when an IRQ needs to be resent, if the interrupt has a parent IRQ and runs in the context of the parent IRQ, then resend the parent. Also, handle_nested_irq() needs to clear the replay flag like the other handlers, otherwise check_irq_resend() will set it and it will never be cleared. Without clearing, it results in the first resend working fine, but check_irq_resend() returning early on subsequent resends because the replay flag is still set. Problem discovered on ARM/OMAP platforms where a nested IRQ that's also a wakeup IRQ happens late in suspend and needed to be retriggered during the resume process. Reported-by: Kevin Hilman khil...@ti.com Tested-by: Kevin Hilman khil...@ti.com [khil...@ti.com: changelog edits, clear IRQS_REPLAY in handle_nested_irq()] Signed-off-by: Thomas Gleixner t...@linutronix.de Umm, we also have the converse situation. We have platforms where the resend has to be done from the child IRQ, and the parent must not be touched. I hope that doesn't break those. I'm assuming the child IRQs you're concerned with are not threaded, right? This patch only addresses nested, threaded IRQs, and these don't have a primary handler to run at all, so cannot do any triggering. 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: RT throttling and suspend/resume (was Re: [PATCH] i2c: omap: revert i2c: omap: switch to threaded IRQ support)
Peter Zijlstra pet...@infradead.org writes: On Fri, 2012-10-19 at 16:54 -0700, Kevin Hilman wrote: So I did the same thing for my ARM SoC, and it definitley stops the RT throttling. However, it has the undesriable (IMO) side effect of making timed printk output rather unhelpful for debugging suspend/resume since printk time stays constant throughout suspend/resume no matter how long you sleep. :( So does that mean we have to choose between useful printk times during suspend/resume or functioning IRQ threads during suspend/resume ? Urgh.. this was not something I considered. This being primarily the sched_clock infrastructure and such. So what exactly is the problem with the suspend resume thing (its not something I've ever debugged), is all you need a clean break between pre and post suspend, or do you need the actual time the machine was gone? I think it's more a question of what people are used to. I think folks used to debugging suspend/resume (at least on ARM) are used to having the printk timestamps reflect the amount of time the machine was gone. With a sched_clock() that counts during suspend, that feature doesn't work anymore. I'm not sure that this feature is a deal breaker, but it has been convenient. I see that on x86, it's already normal that printk times don't reflect time spent in suspend, so I guess ARM needs to adapt. 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] arm: sched: stop sched_clock() during suspend
+Colin Cross, Barry Song also Felipe Balbi ba...@ti.com writes: The scheduler imposes a requirement to sched_clock() which is to stop the clock during suspend, if we don't do that IRQ threads will be rescheduled in the future which might cause transfers to timeout depending on how driver is written. It's not just about IRQ threads, it's about RT throttling. IOW, not just IRQ threads will be postponed, but all RT tasks will be throttled temporarily as well. The changelog should also mention that this has an inconvenient side effect of stopping the printk times during suspend. Based on the original thread where this feature was discussed and introduced, some platforms wanted to opt out of this behavior[1], so the optional API was added. However, in light of RT throttling, this a correctness issue for process accounting, so I agree that this should be done for all platforms instead of providing an optional 'needs suspend' version of the API, even though it means printk times no longer reflect time spent suspended. After a discussion with peterz on this topic, it seems that x86 already ensures that sched_clock stops during suspend for similar reasons[2]. The question then is whether this is a fix that belongs in v3.7. Technically, it is not a regression, so I think this should probably be v3.8 material. If that's the decision, then the threaded IRQ support for the OMAP I2C driver needs to be reverted for v3.7 until this fix is merged. Kevin [1] http://marc.info/?l=linux-arm-kernelm=134307004508708w=2 [2] http://marc.info/?l=linux-arm-kernelm=135065529907297w=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
Re: OMAP baseline test results for v3.7-rc1
Aaro Koskinen aaro.koski...@iki.fi writes: Hi, On Fri, Oct 19, 2012 at 10:01:36PM +0300, Felipe Balbi wrote: On Fri, Oct 19, 2012 at 10:03:58PM +0300, Aaro Koskinen wrote: FYI, I saw I2C hangs also on Nokia N900 with v3.7-rc1 (omap_i2c omap_i2c.1: timeout waiting for bus ready). After several reboots they disappered (kernel binary was the same), and I have been unable to reproduce them since. any change you have those logs saved somewhere ? Want to see if it's the same problem triggered by RTC. I did not save the logs, but now I tried again, I managed to reproduce it after couple boots. The log is below, and after that the there's also one from OK boot for comparison. In the error case, the boot never reaches userspace, just silently hangs (or maybe I just didn't wait enough long). Can you try to revert the threaded IRQ conversion to see if things get to working again? commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde Thanks, 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: OMAP baseline test results for v3.7-rc1
Paul Walmsley p...@pwsan.com writes: Hi Kevin On Fri, 19 Oct 2012, Paul Walmsley wrote: On Thu, 18 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ ... Failing tests: needing investigation ... PM tests: * 3730 Beagle XM: OPPs do not initialize - Several find_device_opp: Invalid parameters messages appear on boot; related warnings follow - Cause unknown This one seems to be caused by this commit: commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64 Author: Kevin Hilman khil...@ti.com Date: Thu Sep 6 14:03:08 2012 -0700 ARM: OMAP2+: PM: MPU DVFS: use generic CPU device for MPU-SS Care to take a look at it and fix it? Yup, will fix. Looks like this exposed some initcall ordering issues in the Beagle board file when adding OPPs. 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] ARM: OMAP3: Beagle: fix OPP customization and initcall ordering
From: Kevin Hilman khil...@ti.com
After commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64 (ARM: OMAP2+:
PM: MPU DVFS: use generic CPU device for MPU-SS), OPPs are registered
using an existing CPU device, not the omap_device for MPU-SS.
First, fix the board file to use get_cpu_device() as required by the
above commit, otherwise custom OPPs will be added to the wrong device.
Second, the board files OPP init is called from the its init_machine
method, and the generic CPU devices are not yet created when
init_machine is run. Therefore OPP initialization will fail. To fix,
use a device_initcall() for the board file's OPP customization.
Reported-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Tony, unless there are objections, I'll add this to a series of
PM related fixes I have left for v3.7-rc.
arch/arm/mach-omap2/board-omap3beagle.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 388c431..befad2a 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -24,6 +24,7 @@
#include linux/input.h
#include linux/gpio_keys.h
#include linux/opp.h
+#include linux/cpu.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
@@ -444,12 +445,13 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
-static void __init beagle_opp_init(void)
+static int __init beagle_opp_init(void)
{
int r = 0;
- /* Initialize the omap3 opp table */
- if (omap3_opp_init()) {
+ /* Initialize the omap3 opp table if not already created. */
+ r = omap3_opp_init();
+ if (IS_ERR_VALUE(r) (r != -EEXIST)) {
pr_err(%s: opp default init failed\n, __func__);
return;
}
@@ -458,13 +460,13 @@ static void __init beagle_opp_init(void)
if (cpu_is_omap3630()) {
struct device *mpu_dev, *iva_dev;
- mpu_dev = omap_device_get_by_hwmod_name(mpu);
+ mpu_dev = get_cpu_device(0);
iva_dev = omap_device_get_by_hwmod_name(iva);
if (IS_ERR(mpu_dev) || IS_ERR(iva_dev)) {
pr_err(%s: Aiee.. no mpu/dsp devices? %p %p\n,
__func__, mpu_dev, iva_dev);
- return;
+ return -ENODEV;
}
/* Enable MPU 1GHz and lower opps */
r = opp_enable(mpu_dev, 8);
@@ -484,8 +486,9 @@ static void __init beagle_opp_init(void)
opp_disable(iva_dev, 66000);
}
}
- return;
+ return 0;
}
+device_initcall(beagle_opp_init);
static void __init omap3_beagle_init(void)
{
@@ -522,8 +525,6 @@ static void __init omap3_beagle_init(void)
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);
omap_mux_init_signal(sdrc_cke1, OMAP_PIN_OUTPUT);
-
- beagle_opp_init();
}
MACHINE_START(OMAP3_BEAGLE, OMAP3 Beagle Board)
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Kevin Hilman khil...@deeprootsystems.com writes: Aaro Koskinen aaro.koski...@iki.fi writes: Hi, On Fri, Oct 19, 2012 at 10:01:36PM +0300, Felipe Balbi wrote: On Fri, Oct 19, 2012 at 10:03:58PM +0300, Aaro Koskinen wrote: FYI, I saw I2C hangs also on Nokia N900 with v3.7-rc1 (omap_i2c omap_i2c.1: timeout waiting for bus ready). After several reboots they disappered (kernel binary was the same), and I have been unable to reproduce them since. any change you have those logs saved somewhere ? Want to see if it's the same problem triggered by RTC. I did not save the logs, but now I tried again, I managed to reproduce it after couple boots. The log is below, and after that the there's also one from OK boot for comparison. In the error case, the boot never reaches userspace, just silently hangs (or maybe I just didn't wait enough long). Can you try to revert the threaded IRQ conversion to see if things get to working again? commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde Nevermind, Paul seems to have already isolated the problem on this one. 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: OMAP baseline test results for v3.7-rc1
Kevin Hilman khil...@deeprootsystems.com writes: Paul Walmsley p...@pwsan.com writes: Hi Kevin On Fri, 19 Oct 2012, Paul Walmsley wrote: On Thu, 18 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ ... Failing tests: needing investigation ... PM tests: * 3730 Beagle XM: OPPs do not initialize - Several find_device_opp: Invalid parameters messages appear on boot; related warnings follow - Cause unknown This one seems to be caused by this commit: commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64 Author: Kevin Hilman khil...@ti.com Date: Thu Sep 6 14:03:08 2012 -0700 ARM: OMAP2+: PM: MPU DVFS: use generic CPU device for MPU-SS Care to take a look at it and fix it? Yup, will fix. Looks like this exposed some initcall ordering issues in the Beagle board file when adding OPPs. Here's the fix: http://marc.info/?l=linux-omapm=135093801330065w=2 I'll be adding this to my PM-related fixes queue for v3.7-rc3. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
Tero Kristo t-kri...@ti.com writes: When waking up from off-mode, some IP blocks are reset automatically by hardware. For this reason, software must wait until the reset has completed before attempting to access the IP block. This patch fixes for example the bug introduced by commit 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c (mmc: omap_hsmmc: remove access to SYSCONFIG register), in which the MMC IP block is reset during off-mode entry, but the code expects the module to be already available during the execution of context restore. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com Cc: Venkatraman S svenk...@ti.com I can confirm that this patch the regression in my OMAP3 PM tests where suspend test (to retention or off) failed if ran after the off-idle test. Tested-by: Kevin Hilman khil...@ti.com on 3530/Overo, 3730/OveroSTORM, 3730/Beagle-xM Thanks Tero for the fix, 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: OMAP baseline test results for v3.7-rc1
Matt Porter mpor...@ti.com writes: On Sat, Oct 20, 2012 at 06:58:10PM +, Paul Walmsley wrote: On Sat, 20 Oct 2012, Richard Cochran wrote: On Sat, Oct 20, 2012 at 06:12:35PM +, Paul Walmsley wrote: Just tried omap2plus_defconfig here and the board didn't boot, confirming your result. Will add a section to the testlog README.txt about that. In terms of differences from your setup, looks like we have different X-Loader and u-boot; it wouldn't surprise me if we have different kernel configs too. I tried both omap2plus_defconfig and your am33xx_only config, and neither one work with my (recent) u-boot version. Just sent you the MLO and u-boot.img from here via private E-mail. Those were the files that came with the BeagleBone SD card here. TI also has a u-boot tree for the AM33xx; might be worth trying: git://arago-project.org/git/projects/u-boot-am33x.git Use of the vendor tree should be discouraged. The best thing to use is current ToT U-Boot mainline or the v2012.10 stable U-Boot release. X-Loader is deprecated by U-Boot SPL. Just FYI for anyone else having an older BeagleBone. On my Rev A2, using u-boot mainline, neither HEAD or v2012.10 result in a working network interface, so you can't netboot/dhcp. 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] ARM: OMAP3: Beagle: fix OPP customization and initcall ordering
From: Kevin Hilman khil...@ti.com
After commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64 (ARM: OMAP2+:
PM: MPU DVFS: use generic CPU device for MPU-SS), OPPs are registered
using an existing CPU device, not the omap_device for MPU-SS.
First, fix the board file to use get_cpu_device() as required by the
above commit, otherwise custom OPPs will be added to the wrong device.
Second, the board files OPP init is called from the its init_machine
method, and the generic CPU devices are not yet created when
init_machine is run. Therefore OPP initialization will fail. To fix,
use a device_initcall() for the board file's OPP customization, and
make the device_initcall board-specific by using a machine_is check.
Reported-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
v2: add machine_is* check to the device_initcall.
arch/arm/mach-omap2/board-omap3beagle.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 388c431..60729bf 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -24,6 +24,7 @@
#include linux/input.h
#include linux/gpio_keys.h
#include linux/opp.h
+#include linux/cpu.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
@@ -444,12 +445,16 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
-static void __init beagle_opp_init(void)
+static int __init beagle_opp_init(void)
{
int r = 0;
- /* Initialize the omap3 opp table */
- if (omap3_opp_init()) {
+ if (!machine_is_omap3_beagle())
+ return 0;
+
+ /* Initialize the omap3 opp table if not already created. */
+ r = omap3_opp_init();
+ if (IS_ERR_VALUE(r) (r != -EEXIST)) {
pr_err(%s: opp default init failed\n, __func__);
return;
}
@@ -458,13 +463,13 @@ static void __init beagle_opp_init(void)
if (cpu_is_omap3630()) {
struct device *mpu_dev, *iva_dev;
- mpu_dev = omap_device_get_by_hwmod_name(mpu);
+ mpu_dev = get_cpu_device(0);
iva_dev = omap_device_get_by_hwmod_name(iva);
if (IS_ERR(mpu_dev) || IS_ERR(iva_dev)) {
pr_err(%s: Aiee.. no mpu/dsp devices? %p %p\n,
__func__, mpu_dev, iva_dev);
- return;
+ return -ENODEV;
}
/* Enable MPU 1GHz and lower opps */
r = opp_enable(mpu_dev, 8);
@@ -484,8 +489,9 @@ static void __init beagle_opp_init(void)
opp_disable(iva_dev, 66000);
}
}
- return;
+ return 0;
}
+device_initcall(beagle_opp_init);
static void __init omap3_beagle_init(void)
{
@@ -522,8 +528,6 @@ static void __init omap3_beagle_init(void)
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);
omap_mux_init_signal(sdrc_cke1, OMAP_PIN_OUTPUT);
-
- beagle_opp_init();
}
MACHINE_START(OMAP3_BEAGLE, OMAP3 Beagle Board)
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Beagle: fix OPP customization and initcall ordering
Kevin Hilman khil...@deeprootsystems.com writes:
From: Kevin Hilman khil...@ti.com
After commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64 (ARM: OMAP2+:
PM: MPU DVFS: use generic CPU device for MPU-SS), OPPs are registered
using an existing CPU device, not the omap_device for MPU-SS.
First, fix the board file to use get_cpu_device() as required by the
above commit, otherwise custom OPPs will be added to the wrong device.
Second, the board files OPP init is called from the its init_machine
method, and the generic CPU devices are not yet created when
init_machine is run. Therefore OPP initialization will fail. To fix,
use a device_initcall() for the board file's OPP customization, and
make the device_initcall board-specific by using a machine_is check.
Reported-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
v2: add machine_is* check to the device_initcall.
arch/arm/mach-omap2/board-omap3beagle.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 388c431..60729bf 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -24,6 +24,7 @@
#include linux/input.h
#include linux/gpio_keys.h
#include linux/opp.h
+#include linux/cpu.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
@@ -444,12 +445,16 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
-static void __init beagle_opp_init(void)
+static int __init beagle_opp_init(void)
{
int r = 0;
- /* Initialize the omap3 opp table */
- if (omap3_opp_init()) {
+ if (!machine_is_omap3_beagle())
+ return 0;
+
+ /* Initialize the omap3 opp table if not already created. */
+ r = omap3_opp_init();
+ if (IS_ERR_VALUE(r) (r != -EEXIST)) {
pr_err(%s: opp default init failed\n, __func__);
return;
oops, sent wrong version. The one queued locally has 'return r' here.
Kevin
}
@@ -458,13 +463,13 @@ static void __init beagle_opp_init(void)
if (cpu_is_omap3630()) {
struct device *mpu_dev, *iva_dev;
- mpu_dev = omap_device_get_by_hwmod_name(mpu);
+ mpu_dev = get_cpu_device(0);
iva_dev = omap_device_get_by_hwmod_name(iva);
if (IS_ERR(mpu_dev) || IS_ERR(iva_dev)) {
pr_err(%s: Aiee.. no mpu/dsp devices? %p %p\n,
__func__, mpu_dev, iva_dev);
- return;
+ return -ENODEV;
}
/* Enable MPU 1GHz and lower opps */
r = opp_enable(mpu_dev, 8);
@@ -484,8 +489,9 @@ static void __init beagle_opp_init(void)
opp_disable(iva_dev, 66000);
}
}
- return;
+ return 0;
}
+device_initcall(beagle_opp_init);
static void __init omap3_beagle_init(void)
{
@@ -522,8 +528,6 @@ static void __init omap3_beagle_init(void)
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);
omap_mux_init_signal(sdrc_cke1, OMAP_PIN_OUTPUT);
-
- beagle_opp_init();
}
MACHINE_START(OMAP3_BEAGLE, OMAP3 Beagle Board)
--
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
