RE: [PATCH 1/1] Added sleep support to UART
Hi,
This patch currently depends on at least one of the PM workaround
patches from Jouni Hogander. Namely this one:
[PATCH 07/10] 34XX: PM: Workaround to check whether any fck is active
before entering sleep
Sorry I think I forgot to mention this in the patch note. Should we
change the patch in order to make this one apply cleanly (I could make a
separate patch for the UART fclk hack which depends on the above?)
-Tero
>-Original Message-
>From: ext Tony Lindgren [mailto:[EMAIL PROTECTED]
>Sent: 31 May, 2008 02:02
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 1/1] Added sleep support to UART
>
>Hi,
>
>* Tero Kristo <[EMAIL PROTECTED]> [080529 06:07]:
>> UART usage (e.g. serial console) now denies sleep for 5
>seconds. This
>> makes it possible to use serial console when dynamic idle is enabled.
>>
>> Also moved code from pm-debug.c to serial.c, and made pm24xx.c use
>> this new implementation.
>
>The changes for pm34xx.c don't currently apply, can you please
>refresh this patch?
>
>Thanks,
>
>Tony
>
>
>> Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
>> ---
>> arch/arm/mach-omap2/pm-debug.c | 132
>
>> arch/arm/mach-omap2/pm.h |8 --
>> arch/arm/mach-omap2/pm24xx.c | 53 ++-
>> arch/arm/mach-omap2/pm34xx.c |8 ++-
>> arch/arm/mach-omap2/serial.c | 118
>
>> include/asm-arm/arch-omap/common.h |3 +
>> 6 files changed, 163 insertions(+), 159 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm-debug.c
>> b/arch/arm/mach-omap2/pm-debug.c index 8a9f3c4..c20fa3b 100644
>> --- a/arch/arm/mach-omap2/pm-debug.c
>> +++ b/arch/arm/mach-omap2/pm-debug.c
>> @@ -34,138 +34,6 @@
>> #ifdef CONFIG_PM_DEBUG
>> int omap2_pm_debug = 0;
>>
>> -static int serial_console_clock_disabled; -static int
>> serial_console_uart; -static unsigned int
>serial_console_next_disable;
>> -
>> -static struct clk *console_iclk, *console_fclk;
>> -
>> -static void serial_console_kick(void) -{
>> -serial_console_next_disable = omap2_read_32k_sync_counter();
>> -/* Keep the clocks on for 4 secs */
>> -serial_console_next_disable += 4 * 32768;
>> -}
>> -
>> -static void serial_wait_tx(void)
>> -{
>> -static const unsigned long uart_bases[3] = {
>> -0x4806a000, 0x4806c000, 0x4806e000
>> -};
>> -unsigned long lsr_reg;
>> -int looped = 0;
>> -
>> -/* Wait for TX FIFO and THR to get empty */
>> -lsr_reg = IO_ADDRESS(uart_bases[serial_console_uart -
>1] + (5 << 2));
>> -while ((__raw_readb(lsr_reg) & 0x60) != 0x60)
>> -looped = 1;
>> -if (looped)
>> -serial_console_kick();
>> -}
>> -
>> -u32 omap2_read_32k_sync_counter(void) -{
>> -return omap_readl(OMAP2_32KSYNCT_BASE + 0x0010);
>> -}
>> -
>> -void serial_console_fclk_mask(u32 *f1, u32 *f2) -{
>> -switch (serial_console_uart) {
>> -case 1:
>> -*f1 &= ~(1 << 21);
>> -break;
>> -case 2:
>> -*f1 &= ~(1 << 22);
>> -break;
>> -case 3:
>> -*f2 &= ~(1 << 2);
>> -break;
>> -}
>> -}
>> -
>> -void serial_console_sleep(int enable) -{
>> -if (console_iclk == NULL || console_fclk == NULL)
>> -return;
>> -
>> -if (enable) {
>> -BUG_ON(serial_console_clock_disabled);
>> -if (clk_get_usecount(console_fclk) == 0)
>> -return;
>> -if ((int) serial_console_next_disable - (int)
>omap2_read_32k_sync_counter() >= 0)
>> -return;
>> -serial_wait_tx();
>> -clk_disable(console_iclk);
>> -clk_disable(console_fclk);
>> -serial_console_clock_disabled = 1;
>> -} else {
>> -int serial_wakeup = 0;
>> -u32 l;
>> -
>> -switch (serial_console_uart) {
>> -case 1:
>> -l = prm_read_mod_reg(CORE_MOD, PM_WKST1);
>> -if (l & OMAP24XX_ST_UART1)
>> -serial_wakeup = 1;
>> -break;
>> -case 2:
>> -l = prm_read_mod_reg(CORE_MOD, PM_WKST1);
>> -if (l & OMAP24XX_ST_UART2)
>> -serial_wakeup = 1;
>> -break;
>> -case 3:
>> -l = prm_read_mod_reg(CORE_MOD,
>OMAP24XX_PM_WKST2);
>> -if (l & OMAP24XX_ST_UART3)
>> -serial_wakeup = 1;
>> -break;
>> -}
>> -if (serial_wakeup)
>> -serial_console_kick();
>> -if (!serial_console_clock_disabled)
>> -return;
>> -clk_enable(console_iclk);
>> -clk_enable(console_fclk);
>> -serial_console_clock_disabled = 0;
>> -}
>> -}
>> -
>> -void pm_init_serial_con
RE: [PATCH 1/1] Added sleep support to UART
Hi,
I'll resend the patch in the following email. Comments below what has
been changed.
>-Original Message-
>From: ext Tony Lindgren [mailto:[EMAIL PROTECTED]
>Sent: 10 June, 2008 09:06
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 1/1] Added sleep support to UART
>
>* Tony Lindgren <[EMAIL PROTECTED]> [080609 22:11]:
>> Hi,
>>
>> Sorry for the delay on looking at this, it's looking pretty good in
>> general. Few more mostly cosmetic comments below.
>
>Here's one more comment:
>
>> > --- a/arch/arm/mach-omap2/pm24xx.c
>> > +++ b/arch/arm/mach-omap2/pm24xx.c
>> >if (omap2_pm_debug) {
>> >unsigned long long tmp;
>> > - u32 resume_time;
>> > + s64 resume_time;
>> > + struct timespec t;
>> >
>> > - resume_time = omap2_read_32k_sync_counter();
>> > + getnstimeofday(&t);
>> > + resume_time = timespec_to_ns(&t);
>> >tmp = resume_time - sleep_time;
>> > - tmp *= 100;
>> > - omap2_pm_dump(0, 1, tmp / 32768);
>> > + omap2_pm_dump(0, 1, tmp / 1000);
>> >}
>
>You should make all these calculations using timespec_sub():
>
>struct timespec ts1, ts2, ts_delta;
>getnstimeofday(&ts1);
>getnstimeofday(&ts2);
>ts_delta = timespec_sub(&ts2, &ts1);
Fixed this in several places now to use timespec_sub, timespec_add and
timespec_compare.
>> +#if defined(CONFIG_ARCH_OMAP2)
>> +static const u32 omap_uart_fclk_mask[OMAP_MAX_NR_PORTS] = {
>> +OMAP24XX_EN_UART1, OMAP24XX_EN_UART2, OMAP24XX_EN_UART3 };
#endif
>> +
>> +#if defined(CONFIG_ARCH_OMAP3)
>> +static const u32 omap_uart_fclk_mask[OMAP_MAX_NR_PORTS] = {
>> +OMAP3430_EN_UART1, OMAP3430_EN_UART2, OMAP3430_EN_UART3 };
>
>The above should be omap24xx_uart_fclk_mask and
omap34xx_uart_fclk_mask.
>Otherwise we cannot compile in both 24xx and 34xx into the same kernel.
Changed. Added omap_uart_fclk_mask to point to these structures though,
initialized at boot time. Also removed those #ifdef:s from the code.
>> +/* UART padconfig registers, these may differ if non-default
padconfig
>> + is used */
>> +#define CONTROL_PADCONF_UART1_RX 0x48002182 #define
>> +CONTROL_PADCONF_UART2_RX 0x4800217A #define CONTROL_PADCONF_UART3_RX
>> +0x4800219E #define PADCONF_WAKEUP_ST 0x8000
>> +
>> +static const u32 omap_uart_padconf[OMAP_MAX_NR_PORTS] = {
>> +CONTROL_PADCONF_UART1_RX, CONTROL_PADCONF_UART2_RX,
>> +CONTROL_PADCONF_UART3_RX }; #endif
>
>This should be omap34xx_uart_padconf is only used for 34xx. Also, it's
currently not defined for 24xx and breaks build.
Changed.
>> +void omap_serial_check_wakeup(void)
>> +{
>> +int i;
>> +
>> +if (cpu_is_omap34xx())
>> +for (i = 0; i < OMAP_MAX_NR_PORTS; i++) {
>> +if (!uart_ick[i])
>> +continue;
>> +if (omap_readw(omap_uart_padconf[i]) &
PADCONF_WAKEUP_ST)
>> +omap_serial_kick();
>> +return;
>> +}
>
>The formatting for return above looks one tab too much to the right?
This is actually a hidden bug, that return should be part of that if
statement. Luckily enough the code worked if you had only one UART
enabled in configs. Added braces around that stuff now.
>> +if (cpu_is_omap24xx()) {
>> +u32 l;
>> +
>> +for (i = 0; i < OMAP_MAX_NR_PORTS; i++) {
>> +if (!uart_ick[i])
>> +continue;
>> +l = prm_read_mod_reg(CORE_MOD,
omap2_uart_wk_st[i]);
>> +if (l & omap2_uart_wk_bit[i])
>> +omap_serial_kick();
>> +return;
>> +}
>> +}
>> +}
>
>Here too.
Similar bug.
>> +
>> +if (cpu_is_omap24xx())
>> +prm_set_mod_reg_bits(omap2_uart_wk_bit[i],
CORE_MOD,
>> +omap2_uart_wk_en[i]);
>> }
>
>How about run the patch through checkpatch.pl, this line looks too
long?
Ok, split the code lines that caused warnings now to be multiline
statements.
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Added sleep support to UART
Hi,
>A few minor comments based on a quick look.
>
>In terms of the OMAP3 code, is that for retention-idle only,
>or does it work with off-idle also?
That patch should basically work in off-mode also, however it requires
correct settings in the padconfig registers which are currently done in
the boot code. Also, currently I have not had any chance to actually
test this in off-mode, I am still trying to get the off-mode work on my
HW.
>
>On Tue, 10 Jun 2008, Tero Kristo wrote:
>
>> +const u32 omap2_uart_wk_bit[OMAP_MAX_NR_PORTS] = {
>> + OMAP24XX_ST_UART1, OMAP24XX_ST_UART2, OMAP24XX_ST_UART3 };
>
>Looks like that can be static.
True.
>
>> +/* UART padconfig registers, these may differ if
>non-default padconfig
>> + is used */
>> +#define CONTROL_PADCONF_UART1_RX 0x48002182 #define
>> +CONTROL_PADCONF_UART2_RX 0x4800217A #define
>CONTROL_PADCONF_UART3_RX
>> +0x4800219E #define PADCONF_WAKEUP_ST 0x8000
>
>Please use omap_ctrl_read{b,w,l}() rather than
>omap_read{b,w,l}() for SCM addresses.
Hmm yea, could do.
>Also, the above are register addresses + 2. Is it possible to
>use the actual register addresses (ideally they should be
>defined in include/asm-arm/arch-omap/control.h), do long
>reads, and simply shift the register contents for the serial
>ports that need it?
These registers are currently not defined anywhere and I did not feel
like wanting to put all the padconfig register definitions somewhere
(all 200+ of them) I don't think it is currently very clear how we
want to handle these registers in general. Also, this fix is more or
less temporary anyway while we are waiting for a real driver that
handles UART clocks properly (the final solution will most likely use
some of the elements of this though.)
Also, the spec says that these registers can be accessed in either 8, 16
or 32 bit modes so why make it unnecessarily complicated and potentially
buggy with shifts (race conditions)?
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Added sleep support to UART
> >What race are you referring to? Wouldn't such a race exist >with the current code? (i.e., a shift should not cause any >further race) Two simultaneous writes to the same register, both accessing their own halves of it. One of the writes would potentially be lost with 32 bit accesses. As far as I understand, Cortex + caches provides a mechanism for accessing device addresses in 16bit format, which prevents this kind of race condition on machine level. (Well, I must admit that my code does not really write anything to the registers so it does not cause any race condition, this is just something I did out of habit.) -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] CPU-idle trial fix + PM debug expansion
Hi,
Quick counter comments here. :P
>This will leave cx->core_state to its previous value in case
>of ON state. So just pwrdm_set_next_pwrst(core_pd,
>cx->core_state) without if is better.
I did not really consider the logic of cpu-idle code too much, just moved
context / save functionality to omap_sram_idle. I just made suspend + dynamic
idle work.
>> +save_core = (pwrdm_read_next_pwrst(core_pwrdm) ==
>PWRDM_POWER_OFF);
>> +save_per = (pwrdm_read_next_pwrst(per_pwrdm) ==
>> PWRDM_POWER_OFF);
>
>Just read next states here.
I am comparing the values to PWRDM_POWER_OFF, because you will only need to
save context if you enter OFF state.
>
>> +
>> +if (save_core) {
>> +omap3_save_core_ctx();
>> +omap3_save_prcm_ctx();
>> +}
>
>And do this if core next_st < PWRDM_POWER_ON
Save is not needed if you enter PWRDM_POWER_RET.
>
>> +
>> +if (save_per)
>> +omap3_save_per_ctx();
>
>And same here. Additionally, do this only if core next_st <
>PWRDM_POWER_ON.
Per domain can in theory go to OFF even if core stays on (yes, there is some
discussion about tying Core + Per because of the gpio dependencies, but we
might find something else for this.)
>
>>
>> -omap3_save_per_ctx();
>> omap2_gpio_prepare_for_retention();
>>
>> /* XXX This is for gpio fclk hack. Will be removed as
>gpio driver
>> * handqles fcks correctly */
>> per_gpio_clk_disable();
>>
>> -omap_save_uart_ctx();
>> +if (save_per)
>> +omap_save_uart_ctx();
>
>Again, do this only if core next_st < PWRDM_POWER_ON and per
>next_st == PWRDM_POWER_OFF.
Same here.
>
>> +
>> omap_serial_enable_clocks(0);
>
>Consider Rajendras idea to do this only if needed.
I think the idea was to access uart clocks only if we can assume that per_pwrdm
will enter ret / off? Yes good idea.
>> /* XXX This is for gpio fclk hack. Will be removed as
>gpio driver
>> * handles fcks correctly */
>>
>> per_gpio_clk_enable();
>> -omap3_restore_per_ctx();
>> +
>> +if (save_per)
>> +omap3_restore_per_ctx();
>>
>> omap2_gpio_resume_after_retention();
>
>Same comments to restore part as before wfi. I think you
>should look at what Rajendra has done (logic in
>omap3_enter_idle). You might also want to look at previous
>discussion related to this. Something like this:
I have looked at this code, and I somehow consider it a bit too complicated for
the purpose. The simpler setup I have implemented in omap_sram_idle is working,
also all powerdomains have their next states set-up correctly when you reach
omap_sram_idle. Anyway, it is easy to expand the code now that it actually
works.
>neon_pwrdm\n");
>> +if (mpu_pwrdm == NULL || neon_pwrdm == NULL ||
>per_pwrdm == NULL ||
>> +core_pwrdm == NULL) {
>> +printk(KERN_ERR "Failed to get pwrdm pointers\n");
>
>Neon handling is missing.
Neon pwrdm is accessed only in the init code to make wakeup dependency from mpu
-> neon. I have not tried out neon save / restore so far (just some vfp hack is
needed.)
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 34xx off-mode support fixes
>Do you have any guesses what is wrong in Rajendras cpuidle >code? Is it that dma save/restore? At least I couldn't figure >it out from your patches. Not sure, one possible cause is that cpuidle code is calling pwrdm_set_next_pwrst(), I recall having some issues if I tried calling this function within idle loop. Rest of the PM code is calling set_pwrdm_state(). I haven't really tried cpuidle too much, I just wanted to get suspend + dynamic idle work as the code in those is simpler => easier to get chip off state to work. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: Fixed crash bug with serial + suspend
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 03 March, 2009 18:58
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH] OMAP3: Fixed crash bug with serial + suspend
>
>Tero Kristo writes:
>
>> It was possible for an unhandled interrupt to occur if there was
>> incoming serial traffic during wakeup from suspend. This was
>caused by
>> the code in arch-arm/mach-omap2/serial.c keeping interrupt
>enabled all
>> the time, but not acking its interrupts. Applies on top of PM branch.
>>
>> Signed-off-by: Tero Kristo
>> ---
>> arch/arm/mach-omap2/pm34xx.c | 15 +++
>> arch/arm/mach-omap2/serial.c | 18 ++
>> arch/arm/plat-omap/include/mach/serial.h |1 +
>> 3 files changed, 34 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c
>> b/arch/arm/mach-omap2/pm34xx.c index 9102cee..5a627db 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -629,7 +629,22 @@ static void omap3_pm_finish(void)
>> pm_idle = saved_idle;
>> }
>>
>> +/* Hooks to enable / disable UART interrupts during suspend
>*/ static
>> +int omap3_pm_begin(suspend_state_t state) {
>> +omap_uart_enable_irqs(0);
>> +return 0;
>> +}
>> +
>> +static void omap3_pm_end(void)
>> +{
>> +omap_uart_enable_irqs(1);
>> +return;
>> +}
>> +
>> static struct platform_suspend_ops omap_pm_ops = {
>> +.begin = omap3_pm_begin,
>> +.end= omap3_pm_end,
>> .prepare= omap3_pm_prepare,
>> .enter = omap3_pm_enter,
>> .finish = omap3_pm_finish,
>
>I think this functionality is more appropriate for the
>prepare/finish hooks than the begin/end hooks. serial.c already has
>omap_uart_prepare_suspend() hook where the interrupt disable
>could be added., and a omap_uart_prepare_resume() call could
>be added to the omap3_pm_finish.
This would cause sequencing issues and it would still be possible to get
unhandled interrupts if I understand the behavior of suspend correctly. I think
it works (simplified) like this:
call begin hook
suspend devices [ this is where the driver interrupt gets disabled ]
call prepare hook
enter state [ Zzzz ]
call finish hook
resume devices [ this is where the driver interrupt gets enabled ]
call end hook
So, if you use prepare / finish hooks to enable the interrupt in serial.c, you
will get a short time period where you have the interrupt enabled but you do
not have "real" handler for the interrupt. This time is longer if you have some
drivers in the system that take a long time to resume/suspend and you are
unlucky with the ordering of drivers.
>
>> diff --git a/arch/arm/mach-omap2/serial.c
>> b/arch/arm/mach-omap2/serial.c index 90f1c67..952da79 100644
>> --- a/arch/arm/mach-omap2/serial.c
>> +++ b/arch/arm/mach-omap2/serial.c
>> @@ -432,6 +432,24 @@ static void omap_uart_idle_init(struct
>omap_uart_state *uart)
>> WARN_ON(ret);
>> }
>>
>> +void omap_uart_enable_irqs(int enable) {
>> +int i, ret;
>> +
>> +for (i = 0; i < OMAP_MAX_NR_PORTS; i++) {
>> +struct plat_serial8250_port *p =
>serial_platform_data + i;
>> +struct omap_uart_state *uart = &omap_uart[i];
>> +
>
>Can you use the "list_for_each_entry(uart, &uart_list, node)"
>construct instead of a for loop? Or was there a reason to
>enable/ack all serial interrupts, even those that have not
>been enabled.
Hmm, yea that's true. I'll fix this one.
>
>> +if (!p->membase)
>> +continue;
>> +if (enable)
>> +ret = request_irq(p->irq, omap_uart_interrupt,
>> +IRQF_SHARED, "serial idle",
>(void *)uart);
>> +else
>> +free_irq(p->irq, (void *)uart);
>> +}
>> +}
>> +
>> static ssize_t sleep_timeout_show(struct kobject *kobj,
>>struct kobj_attribute *attr,
>>char *buf)
>> diff --git a/arch/arm/plat-omap/include/mach/serial.h
>> b/arch/arm/plat-omap/include/mach/serial.h
>> index 8e89585..7ca1f27 100644
>> --- a/arch/arm/plat-omap/include/mach/serial.h
>> +++ b/arch/arm/plat-omap/include/mach/serial.h
>> @@ -47,6 +47,7 @@ extern void omap_uart_check_wakeup(void); extern
>> void omap_uart_prepare_suspend(void); extern void
>> omap_uart_prepare_idle(int num); extern void
>> omap_uart_resume_idle(int num);
>> +extern void omap_uart_enable_irqs(int enable);
>> #endif
>>
>> #endif
>> --
>> 1.5.4.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>linux-omap"
>> in the body of a message to majord...@vger.kernel.org More majordomo
>> info at http://vger.kernel.org/majordomo-info.html
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info a
RE: [PATCH 0/2] OMAP3: GPIO off-mode fixes
The first patch in this set contains a small bug, missing kfree() for one of the dynamically reserved arrays during init in error path. Sending a fixed patch now. -Tero >-Original Message- >From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: 09 March, 2009 20:48 >To: Kristo Tero (Nokia-D/Tampere) >Cc: linux-omap@vger.kernel.org >Subject: Re: [PATCH 0/2] OMAP3: GPIO off-mode fixes > >Tero Kristo writes: > >> These two patches add fixes to GPIO off-mode handling. First >patch is >> more important as it fixes a HW bug, second one just optimizes >> off-mode code a bit by removing a couple of unnecessary >registers from the context save. > >Thanks, pushing both patches to PM branch. > >Kevin >-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: PM: Force USB to standby if not used
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 14 May, 2009 18:56
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH] OMAP3: PM: Force USB to standby if not used
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> This patch will allow device to enter sleep mode while a USB
>cable is
>> connected and USB is either disabled or built as a module
>from kernel
>> config.
>>
>> Applies on top of PM branch.
>>
>> Signed-off-by: Tero Kristo
>> ---
>> arch/arm/mach-omap2/usb-musb.c | 10 --
>> 1 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/usb-musb.c
>> b/arch/arm/mach-omap2/usb-musb.c index 12a9b0a..dd51d2f 100644
>> --- a/arch/arm/mach-omap2/usb-musb.c
>> +++ b/arch/arm/mach-omap2/usb-musb.c
>> @@ -32,7 +32,9 @@
>> #include
>>
>> #define AUTOIDLE(1 << 0)
>> +#define FORCESTDBY (1 << 0)
>> #define OTG_SYSCONFIG (OMAP34XX_HSUSB_OTG_BASE + 0x404)
>> +#define OTG_FORCESTDBY (OMAP34XX_HSUSB_OTG_BASE + 0x414)
>>
>> static struct resource musb_resources[] = {
>> [0] = { /* start and end set dynamically */ @@ -185,7
>+187,11 @@
>> void __init usb_musb_init(void)
>> return;
>> }
>>
>> -/* Enable smartidle on MUSB to improve C1 wakeup latency */
>> -if (cpu_is_omap34xx())
>> +#if !defined(CONFIG_USB) || defined(CONFIG_USB_MODULE)
>> +/* Force MUSB to standby if not used */
>> +if (cpu_is_omap34xx()) {
>> omap_writel(AUTOIDLE, OTG_SYSCONFIG);
>> +omap_writel(FORCESTDBY, OTG_FORCESTDBY);
>> +}
>> +#endif
>
>Tero,
>
>Is this needed if OTG_SYSCONFIG is set to force-idle?
>
>Yesterday, I pushed a patch changing OTG_SYSCONFIG to
>force-idle instead of auto-idle since on ES3.0 3430SDP, having
>it in auto-idle was keeping CORE from hitting retention.
>IIUC, there's an errata where force-idle doesn't work properly.
>
>Also, why the #ifdefs?
>
>This code is already conditionally compiled based on
>CONFIG_USB_MUSB_SOC (see mach-omap2/Makefile) which is set
>whether MUSB is built-in or a module.
>
>#if !defined(CONFIG_USB) then CONFIG_USB_MUSB_SOC will not be
>defined either.
You are actually right, I missed that change to Makefile. The reason for this
patch was to be able to hit retention / off when USB is not enabled, and this
was possible with the #ifdef:s earlier. I think you can just ignore this patch.
-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: Smart Reflex pm patches causes a kernel panic
Hi Elvis,
I think I saw something similar last week, and it was caused by not having
CONFIG_OMAP_PM_SRF enabled. The actual culprit is the marked line in
sr_configure_vp():
vpconfig = PRM_VP1_CONFIG_ERROROFFSET |
PRM_VP1_CONFIG_ERRORGAIN |
PRM_VP1_CONFIG_TIMEOUTEN |
>>>mpu_opps[resource_get_level("vdd1_opp")].vsel <<
OMAP3430_INITVOLTAGE_SHIFT;
SR2 has similar code a bit later.
You will also get a failure if mpu_opps[] and/or l3_opps[] is not defined at
all in your board files, this null pointer exception would actually indicate a
problem like that more likely.
-Tero
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org
>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Elvis Dowson
>Sent: 19 May, 2009 14:21
>To: Kevin Hilman
>Cc: Linux OMAP Users
>Subject: Smart Reflex pm patches causes a kernel panic
>
>Hi Kevin,
> I get a kernel panic on my TI OMAP 3503 when
>I incorporate the SR patches. How can I trace and debug this
>to find the cause of this null pointer error ?
>
>Power Management for TI OMAP3.
>mmc0: mmc_rescan - card ocr from io_op=0x, err = -110
>pm_dbg_init()
>Unable to handle kernel NULL pointer dereference at virtual
>address 001e pgd = c0004000 [001e] *pgd=
>Internal error: Oops: 5 [#1] PREEMPT Modules linked in:
>CPU: 0Not tainted (2.6.29-omap1 #1)
>PC is at sr_configure_vp+0x28/0x1bc
>LR is at sr_configure_vp+0x1c/0x1bc
>pc : []lr : []psr: 6113
>sp : cf81ff28 ip : cf81ff28 fp : cf81ff3c
>r10: r9 : r8 : 0001
>r7 : c0012b44 r6 : r5 : c05c8660 r4 : c05c8624
>r3 : r2 : 0001 r1 : 8113 r0 :
>Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
>Control: 10c5387d Table: 80004019 DAC: 0017 Process
>swapper (pid: 1, stack limit = 0xcf81e2e8)
>Stack: (0xcf81ff28 to 0xcf82)
>ff20: c05c8660 c05c8624 cf81ff5c cf81ff40 c0012bc8
>c01055d8
>ff40: 08012954 c002d9d0 c002da20 cf81ffd4 cf81ff60
>c00f52f8 c0012b50
>ff60: cf81ff8c cf81ff70 c01cb9e4 c01cb6a8 cf81ff00 cf9a26e0 c01cbae4
>cf81ff96
>ff80: cf81ffbc cf81ff90 c014d408 c01cb970 c02fb2b4 35339600
>0031
>ffa0: 0192 c05d2034 cf81ffd4 c002d9d0
>c002da20
>ffc0: cf81fff4 cf81ffd8 c00083fc c00f52ac
>0001
>ffe0: cf81fff8 c011e2b8 c0008384
>0836d404 5777f140
>Backtrace:
>[] (sr_configure_vp+0x0/0x1bc) from []
>(omap3_sr_init+0x84/0x114)
> r4:c05c8624
>[] (omap3_sr_init+0x0/0x114) from []
>(do_one_initcall+0x58/0x198)
> r5:c002da20 r4:c002d9d0
>[] (do_one_initcall+0x0/0x198) from []
>(kernel_init
>+0x84/0xf4)
> r8: r7: r6: r5:c002da20 r4:c002d9d0
>[] (kernel_init+0x0/0xf4) from [] (do_exit
>+0x0/0x7d0)
> r5: r4:
>Code: eb0024a7 e59f3180 e350 05933000 (01d301be) ---[ end
>trace eadc9c7cb4a7e9eb ]--- Kernel panic - not syncing:
>Attempted to kill init!
>
>
>I have extracted the pm patches by doing a
>
>git format-patch master
>
>on the pm branch. This generates 186 patch files, as of today.
>
>Since I don't know which particular patch is causing the
>problem, I need to fully exclude the following patch numbers
>to prevent the kernel panic.
>
>#
>file://omap-pm/0149-OMAP3-SR-Fix-init-voltage-on-OPP-change.patch
>;patch=1 \
>#
>file://omap-pm/0151-OMAP3-SR-Update-VDD1-2-voltages-at-boot.patch
>;patch=1 \
>#
>file://omap-pm/0152-OMAP3-SR-Use-sysclk-for-SR-CLKLENGTH-calc.patch
>;patch=1 \
>#
>file://omap-pm/0153-OMAP3-SR-Disable-SR-autocomp-only-for-CORE-
>trans.patch
>;patch=1 \
>#
>file://omap-pm/0154-OMAP3-SR-Reset-voltage-level-on-SR-disable.patch
>;patch=1 \
>#
>file://omap-pm/0155-OMAP3-SR-Replace-printk-s-with-pr_-calls.patch
>;patch=1 \
># file://omap-pm/0156-OMAP3-SR-Remove-redundant-
>defines.patch;patch=1 \
>#
>file://omap-pm/0157-OMAP3-SR-Replace-SR_PASS-FAIL-SR_TRUE-FALSE.patch
>;patch=1 \
># file://omap-pm/0158-OMAP3-SR-Replace-0x1-n-with-BIT-
>n.patch;patch=1 \
>#
>file://omap-pm/0159-OMAP3-clock-Remove-virt_vdd1-2_prcm_set.patch
>;patch=1 \
>
>The following patches (from 167 to 186) are more recent, and
>no necessary to reproduce the crash above:
>
>#
>file://omap-pm/0168-OMAP3-SR-Fix-SR-driver-to-check-for-omap-pm
>-return.patch
>;patch=1 \
>#
>file://omap-pm/0169-OMAP3-PM-Don-t-do-unnecessary-searches-in-o
>map_sr_.patch
>;patch=1 \
>#
>file://omap-pm/0181-OMAP-PM-SmartReflex-has-build-dependency-on
>-OMAP-P.patch
>;patch=1 \
>#
>file://omap-pm/0186-OMAP3-PM-Fix-Smartreflex-when-used-with-PM_
>NOOP-la.patch
>;patch=1 \
>
>Excluding the SR patches gives me a workable kernel that
>doesn't crash on startup.
RE: Smart Reflex pm patches causes a kernel panic
>-Original Message-
>From: ext Elvis Dowson [mailto:elvis.dow...@mac.com]
>Sent: 19 May, 2009 14:49
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: Linux OMAP Users
>Subject: Re: Smart Reflex pm patches causes a kernel panic
>
>Hi Tero,
> Thanks for the reply. I'll try this out. I
>don't think mpu_opps is defined for my board_overo.c file. I
>guess I should look at the board_sdp3430.c as an example for this?
Yes, take a look at it. You are basically missing some parameters in a call to
omap2_init_common_hw(), at least the version I am looking at here has a few
NULL pointers passed. The rate tables (mpu + l3) should be posted as parameters
in that.
-Tero
>
>Thanks and do let me know!
>
>Best regards,
>
>Elvis
>
>
>On May 19, 2009, at 3:41 PM, tero.kri...@nokia.com wrote:
>
>> Hi Elvis,
>>
>> I think I saw something similar last week, and it was caused by not
>> having CONFIG_OMAP_PM_SRF enabled. The actual culprit is the marked
>> line in sr_configure_vp():
>>
>>vpconfig = PRM_VP1_CONFIG_ERROROFFSET |
>>PRM_VP1_CONFIG_ERRORGAIN |
>>PRM_VP1_CONFIG_TIMEOUTEN |
>
> mpu_opps[resource_get_level("vdd1_opp")].vsel <<
>>OMAP3430_INITVOLTAGE_SHIFT;
>>
>> SR2 has similar code a bit later.
>>
>> You will also get a failure if mpu_opps[] and/or l3_opps[] is not
>> defined at all in your board files, this null pointer
>exception would
>> actually indicate a problem like that more likely.
>
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: Re-program also chipselect 1 when changing SDRAM timing
>-Original Message- >From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: 27 May, 2009 18:50 >To: Kristo Tero (Nokia-D/Tampere) >Cc: linux-omap@vger.kernel.org >Subject: Re: [PATCH] OMAP3: Re-program also chipselect 1 when >changing SDRAM timing > >Tero Kristo writes: > >> From: Tero Kristo >> >> Previously only chipselect 0 was controlled, which would >result in the >> chipselect 1 running on too low rate during low core OPPs. >> >> Applies on top of PM branch. >> >> Signed-off-by: Tero Kristo > >Hi Tero, > >This does part of what Jean Pihet does in his recent patch[1] >to add support for 2 CSs. Your version assumes the same >parameters for both SDRAM parts, and Jean has expanded that so >board code can configure different paramaters for the different CSes. > >I have yet to fully review Jean's patch, but will probably >take his version so that two different SDRAM parts could be used. Yeah, I did not notice that patch of course as I just checked if something like this is done on top of PM branch yet. I'll give Jean's patch a shot and see if it works for me. > >Kevin > > >[1] See hist post from 26 May: [RFC][PATCH] OMAP3: add support >for 2 SDRAM chip selects (was: Re: Beagleboard rev C memory >timings & suspend/resume) > >> --- >> arch/arm/mach-omap2/sram34xx.S | 29 +++-- >> 1 files changed, 23 insertions(+), 6 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/sram34xx.S >> b/arch/arm/mach-omap2/sram34xx.S index f41f8d9..bcfe9eb 100644 >> --- a/arch/arm/mach-omap2/sram34xx.S >> +++ b/arch/arm/mach-omap2/sram34xx.S >> @@ -187,15 +187,24 @@ wait_dll_unlock: >> bne wait_dll_unlock >> bx lr >> configure_sdrc: >> -ldr r11, omap3_sdrc_rfr_ctrl >> +ldr r11, omap3_sdrc_rfr_ctrl_0 >> str r0, [r11] >> -ldr r11, omap3_sdrc_actim_ctrla >> +ldr r11, omap3_sdrc_rfr_ctrl_1 >> +str r0, [r11] >> +ldr r11, omap3_sdrc_actim_ctrla_0 >> +str r1, [r11] >> +ldr r11, omap3_sdrc_actim_ctrla_1 >> str r1, [r11] >> -ldr r11, omap3_sdrc_actim_ctrlb >> +ldr r11, omap3_sdrc_actim_ctrlb_0 >> +str r2, [r11] >> +ldr r11, omap3_sdrc_actim_ctrlb_1 >> str r2, [r11] >> ldr r11, omap3_sdrc_mr_0 >> str r6, [r11] >> ldr r6, [r11] @ posted-write barrier for SDRC >> +ldr r11, omap3_sdrc_mr_1 >> +str r6, [r11] >> +ldr r6, [r11] @ posted-write barrier for SDRC >> bx lr >> >> omap3_sdrc_power: >> @@ -206,14 +215,22 @@ omap3_cm_idlest1_core: >> .word OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST) >> omap3_cm_iclken1_core: >> .word OMAP34XX_CM_REGADDR(CORE_MOD, CM_ICLKEN1) >> -omap3_sdrc_rfr_ctrl: >> +omap3_sdrc_rfr_ctrl_0: >> .word OMAP34XX_SDRC_REGADDR(SDRC_RFR_CTRL_0) >> -omap3_sdrc_actim_ctrla: >> +omap3_sdrc_rfr_ctrl_1: >> +.word OMAP34XX_SDRC_REGADDR(SDRC_RFR_CTRL_1) >> +omap3_sdrc_actim_ctrla_0: >> .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_A_0) >> -omap3_sdrc_actim_ctrlb: >> +omap3_sdrc_actim_ctrla_1: >> +.word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_A_1) >> +omap3_sdrc_actim_ctrlb_0: >> .word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_B_0) >> +omap3_sdrc_actim_ctrlb_1: >> +.word OMAP34XX_SDRC_REGADDR(SDRC_ACTIM_CTRL_B_1) >> omap3_sdrc_mr_0: >> .word OMAP34XX_SDRC_REGADDR(SDRC_MR_0) >> +omap3_sdrc_mr_1: >> +.word OMAP34XX_SDRC_REGADDR(SDRC_MR_1) >> omap3_sdrc_dlla_status: >> .word OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS) >> omap3_sdrc_dlla_ctrl: >> -- >> 1.5.4.3 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe >linux-omap" >> in the body of a message to majord...@vger.kernel.org More majordomo >> info at http://vger.kernel.org/majordomo-info.html >-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/05] OMAP3: Basic Cpuidle with support for C0-C2
Hi Rajendra,
Currently cpuidle is not taking enable_off_mode variable (from pm.c)
into account, it only controls suspend / dynamic idle behavior.
-Tero
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of ext
>Rajendra Nayak
>Sent: 08 October, 2008 15:01
>To: linux-omap@vger.kernel.org
>Cc: 'Kevin Hilman'
>Subject: [PATCH 01/05] OMAP3: Basic Cpuidle with support for C0-C2
>
>Basic cpuidle driver for OMAP3 with deepest sleep state
>supported being MPU CSWR.
>
>Signed-off-by: Rajendra Nayak <[EMAIL PROTECTED]>
>---
> arch/arm/mach-omap2/Makefile |2
> arch/arm/mach-omap2/cpuidle34xx.c| 274
>+++
> arch/arm/mach-omap2/pm34xx.c |4
> arch/arm/plat-omap/include/mach/pm.h |1
> 4 files changed, 279 insertions(+), 2 deletions(-)
>
>Index: linux-omap-2.6/arch/arm/mach-omap2/Makefile
>===
>--- linux-omap-2.6.orig/arch/arm/mach-omap2/Makefile
>2008-10-08 16:49:07.0 +0530
>+++ linux-omap-2.6/arch/arm/mach-omap2/Makefile
>2008-10-08 16:49:10.0 +0530
>@@ -23,7 +23,7 @@ ifeq ($(CONFIG_PM),y)
> obj-y += pm.o
> obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
> obj-$(CONFIG_ARCH_OMAP24XX) += sleep24xx.o
>-obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
>+obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
>cpuidle34xx.o
> obj-$(CONFIG_PM_DEBUG)+= pm-debug.o
> endif
>
>Index: linux-omap-2.6/arch/arm/mach-omap2/cpuidle34xx.c
>===
>--- /dev/null 1970-01-01 00:00:00.0 +
>+++ linux-omap-2.6/arch/arm/mach-omap2/cpuidle34xx.c
>2008-10-08 16:50:02.0 +0530
>@@ -0,0 +1,274 @@
>+/*
>+ * linux/arch/arm/mach-omap2/cpuidle34xx.c
>+ *
>+ * OMAP3 CPU IDLE Routines
>+ *
>+ * Copyright (C) 2008 Texas Instruments, Inc.
>+ * Rajendra Nayak <[EMAIL PROTECTED]>
>+ *
>+ * Copyright (C) 2007 Texas Instruments, Inc.
>+ * Karthik Dasu <[EMAIL PROTECTED]>
>+ *
>+ * Copyright (C) 2006 Nokia Corporation
>+ * Tony Lindgren <[EMAIL PROTECTED]>
>+ *
>+ * Copyright (C) 2005 Texas Instruments, Inc.
>+ * Richard Woodruff <[EMAIL PROTECTED]>
>+ *
>+ * Based on pm.c for omap2
>+ *
>+ * This program is free software; you can redistribute it
>and/or modify
>+ * it under the terms of the GNU General Public License version 2 as
>+ * published by the Free Software Foundation.
>+ */
>+
>+#include
>+#include
>+#include
>+#include
>+
>+#ifdef CONFIG_CPU_IDLE
>+
>+#define OMAP3_MAX_STATES 7
>+#define OMAP3_STATE_C0 0 /* C0 - System executing code */ #define
>+OMAP3_STATE_C1 1 /* C1 - MPU WFI + Core active */ #define
>+OMAP3_STATE_C2 2 /* C2 - MPU CSWR + Core active */ #define
>+OMAP3_STATE_C3 3 /* C3 - MPU OFF + Core active */ #define
>+OMAP3_STATE_C4 4 /* C4 - MPU RET + Core RET */ #define
>OMAP3_STATE_C5 5
>+/* C5 - MPU OFF + Core RET */ #define OMAP3_STATE_C6 6 /* C6
>- MPU OFF
>++ Core OFF */
>+
>+struct omap3_processor_cx {
>+ u8 valid;
>+ u8 type;
>+ u32 sleep_latency;
>+ u32 wakeup_latency;
>+ u32 mpu_state;
>+ u32 core_state;
>+ u32 threshold;
>+ u32 flags;
>+};
>+
>+struct omap3_processor_cx omap3_power_states[OMAP3_MAX_STATES];
>+struct omap3_processor_cx current_cx_state; struct
>powerdomain *mpu_pd;
>+
>+static int omap3_idle_bm_check(void)
>+{
>+ return 0;
>+}
>+
>+/**
>+ * omap3_enter_idle - Programs OMAP3 to enter the specified state
>+ * @dev: cpuidle device
>+ * @state: The target state to be programmed
>+ *
>+ * Called from the CPUidle framework to program the device to the
>+ * specified target state selected by the governor.
>+ */
>+static int omap3_enter_idle(struct cpuidle_device *dev,
>+ struct cpuidle_state *state)
>+{
>+ struct omap3_processor_cx *cx = cpuidle_get_statedata(state);
>+ struct timespec ts_preidle, ts_postidle, ts_idle;
>+
>+ current_cx_state = *cx;
>+
>+ /* Used to keep track of the total time in idle */
>+ getnstimeofday(&ts_preidle);
>+
>+ local_irq_disable();
>+ local_fiq_disable();
>+
>+ /* Program MPU to target state */
>+ if (cx->mpu_state < PWRDM_POWER_ON)
>+ pwrdm_set_next_pwrst(mpu_pd, cx->mpu_state);
>+
>+ /* Execute ARM wfi */
>+ omap_sram_idle();
>+
>+ /* Program MPU to ON */
>+ if (cx->mpu_state < PWRDM_POWER_ON)
>+ pwrdm_set_next_pwrst(mpu_pd, PWRDM_POWER_ON);
>+
>+ getnstimeofday(&ts_postidle);
>+ ts_idle = timespec_sub(ts_postidle, ts_preidle);
>+
>+ local_irq_enable();
>+ local_fiq_enable();
>+
>+ return timespec_to_ns(&ts_idle);
>+}
>+
>+/**
>+ * omap3_enter_idle_bm - Checks for any bus activity
>+ * @dev: cpuidle device
>+ * @state: The target state to be programmed
>+ *
>+ * Called from the CPUidle framework for C states with
>+CPUIDLE_FL
RE: [PATCH] PM: Added three PLL registers to the PRCM context save
Hi,
Just an initial comment to this patch, this is somewhat experimental and
I think we should agree what registers will actually be saved here and
what should be left for drivers. CM_CLKSEL4 is for DPLL5 which is used
by USB. Two of the CLKEN registers are more interesting.
-Tero
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of ext Tero Kristo
>Sent: 19 November, 2008 11:32
>To: linux-omap@vger.kernel.org
>Subject: [PATCH] PM: Added three PLL registers to the PRCM context save
>
>These registers are now also saved:
> CM_CLKSEL4
> CM_CLKEN
> CM_CLKEN2
>
>Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
>---
> arch/arm/mach-omap2/prcm.c | 14 ++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
>diff --git a/arch/arm/mach-omap2/prcm.c
>b/arch/arm/mach-omap2/prcm.c index d5a1e4b..c64b668 100644
>--- a/arch/arm/mach-omap2/prcm.c
>+++ b/arch/arm/mach-omap2/prcm.c
>@@ -46,7 +46,10 @@ struct omap3_prcm_regs {
> u32 emu_cm_clksel;
> u32 emu_cm_clkstctrl;
> u32 pll_cm_autoidle2;
>+ u32 pll_cm_clksel4;
> u32 pll_cm_clksel5;
>+ u32 pll_cm_clken;
>+ u32 pll_cm_clken2;
> u32 cm_polctrl;
> u32 iva2_cm_fclken;
> u32 core_cm_fclken1;
>@@ -233,8 +236,14 @@ void omap3_prcm_save_context(void)
>cm_read_mod_reg(OMAP3430_EMU_MOD,
>CM_CLKSTCTRL);
> prcm_context.pll_cm_autoidle2 =
>cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE2);
>+ prcm_context.pll_cm_clksel4 =
>+ cm_read_mod_reg(PLL_MOD,
>OMAP3430ES2_CM_CLKSEL4);
> prcm_context.pll_cm_clksel5 =
>cm_read_mod_reg(PLL_MOD,
>OMAP3430ES2_CM_CLKSEL5);
>+ prcm_context.pll_cm_clken =
>+ cm_read_mod_reg(PLL_MOD, CM_CLKEN);
>+ prcm_context.pll_cm_clken2 =
>+ cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKEN2);
> prcm_context.cm_polctrl = __raw_readl(OMAP3430_CM_POLCTRL);
> prcm_context.iva2_cm_fclken =
>cm_read_mod_reg(OMAP3430_IVA2_MOD,
>CM_FCLKEN); @@ -380,8 +389,13 @@ void omap3_prcm_restore_context(void)
>CM_CLKSTCTRL);
> cm_write_mod_reg(prcm_context.pll_cm_autoidle2, PLL_MOD,
>CM_AUTOIDLE2);
>+ cm_write_mod_reg(prcm_context.pll_cm_clksel4, PLL_MOD,
>+ OMAP3430ES2_CM_CLKSEL4);
> cm_write_mod_reg(prcm_context.pll_cm_clksel5, PLL_MOD,
>OMAP3430ES2_CM_CLKSEL5);
>+ cm_write_mod_reg(prcm_context.pll_cm_clken, PLL_MOD, CM_CLKEN);
>+ cm_write_mod_reg(prcm_context.pll_cm_clken2, PLL_MOD,
>+ OMAP3430ES2_CM_CLKEN2);
> __raw_writel(prcm_context.cm_polctrl, OMAP3430_CM_POLCTRL);
> cm_write_mod_reg(prcm_context.iva2_cm_fclken, OMAP3430_IVA2_MOD,
>CM_FCLKEN);
>--
>1.5.4.3
>
>--
>To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in the body of a message to
>[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: GPIO fixes for off-mode
Hi, >On Monday 01 December 2008, Tero Kristo wrote: >> Off mode is now using the omap2 retention fix code for >scanning GPIOs >> only during off-mode transitions. All the *non_wakeup_gpios >variables >> are now used for off-mode transition tracking on OMAP3. This patch >> fixes cases where GPIO state changes are missed during off-mode. > >I second the "no #ifdefs" comment ... I agree the code looks horrible at the moment with the multitude of #ifdef:s, I just did not feel comfortable fixing all of those, so I continued the way it has been written so far... >Could you uplevel your description here a bit? I'm trying to >understand if what this does is complete and correct. > >My understanding is that we currently have several mechanisms >interacting to affect things that relate to the OMAP3-only >"off" modes for pins used as GPIOs: > > - irq_chip.set_wake() calls, for GPIOs used as IRQs. > We should assume that if the IRQ is wake-enabled, that > applies to OFF mode too. (AFAICT, this mechanism is > not handled by this patch.) Off mode wakeup requires setting up IO pads according to the wakeup scheme you want to have. This is rather nasty limitation of the HW and you need to be careful how you configure these things. This patch assumes you have configured your IO pads in a way that you get wakeups for your GPIOs during off, and when you eventually wakeup, it will scan all GPIOs to see if any GPIO "interrupt" has happened. You will not get edge sensitive interrupts from GPIOs during off-mode, because the hardware block handling the edge sensing has no power at all. > - Hmm, and because a goal is to transparently enter OFF > modes to save power, rather than only after drivers > get suspend() calls that tend to trigger set_wake(), > an un-commented conclusion seems to be that all GPIOs > used as IRQs implicitly act like set_wake() was called. > (Something which *is* partially addressed here.) Yes, this is correct. I think this is somewhat against the design of the omap2 code, as the GPIOs can wakeup the device from both suspend and dynamic idle. However, this is mainly caused by the IO pad wakeup mechanism of omap3, which does not care whether you are in dynamic idle or in suspend. Handling this correctly would require creating IO pad control mechanism to the kernel, something that I am not sure if we want to do (we would need to have separate IO pad config for suspend and dynamic idle.) > > - omap_cfg_reg() configuration for any pin can include > its OFF-mode parameters. Virtually unused ... and > not addressed by this patch, so I'm puzzled how pins > are expected to be kept active with just this patch. Mux configuration for OMAP3 is handled mostly by boot loader at the moment, this is the behavior at least on TI SDP implementation. > > - OMAP2-specific bug workarounds, some GPIOs can't be > used for wakeup, ergo bank->non_wakeup_gpios. This > is resolved for OMAP3, yes? Well, basically only bank 0 can be used for wakeup in omap3, wakeups for all the rest are handled via IO pad. > >When I looked at this issue a while back, I came to believe >that we'd need to map GPIOs to their config registers so we >could diddle the OFF-mode bits. And I don't see such a >mapping (table) here... Yep, if we want to have different configs for suspend and dynamic idle, this is something we should do. However, having around 190 pins in OMAP3 you can potentially configure as GPIOs, I am really hesitant writing such piece of code. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] Save sram context after changing MPU, DSP or core clocks
Hi Peter,
This patch causes linker error without CONFIG_PM option, should add
#ifdef:s around the call to omap3_save_scratchpad_contents();
-Tero
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of ext
>Peter 'p2' De Schrijver
>Sent: 19 November, 2008 13:45
>To: linux-omap@vger.kernel.org
>Cc: De-Schrijver Peter (Nokia-D/Helsinki)
>Subject: [PATCH 1/1] Save sram context after changing MPU, DSP
>or core clocks
>
>
>Signed-off-by: Peter 'p2' De Schrijver <[EMAIL PROTECTED]>
>---
> arch/arm/mach-omap2/clock34xx.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
>diff --git a/arch/arm/mach-omap2/clock34xx.c
>b/arch/arm/mach-omap2/clock34xx.c index d97d5a9..962ce56 100644
>--- a/arch/arm/mach-omap2/clock34xx.c
>+++ b/arch/arm/mach-omap2/clock34xx.c
>@@ -911,6 +911,9 @@ printk("%s set to %luHz intended rate
>%luHz\n",dpll2_clk->name,clk_get_rate(dpll
> clk_set_rate(dpll3_clk, prcm_vdd->rate);
> curr_vdd2_prcm_set = prcm_vdd;
> }
>+
>+ omap3_save_scratchpad_contents();
>+
> return 0;
> }
>
>--
>1.5.6.3
>
>--
>To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in the body of a message to
>[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 20/23] OMAP3: Add support for DPLL3 divisor values higher than 2
Hi,
>Hi Tero
>
>one comment on this patch ...
>
>On Thu, 11 Dec 2008, Tero Kristo wrote:
>
>> Previously only 1 and 2 was supported. This is needed for
>DVFS VDD2 control.
>
>> diff --git a/arch/arm/mach-omap2/sram34xx.S
>> b/arch/arm/mach-omap2/sram34xx.S index 16eb4ef..832cd76 100644
>> --- a/arch/arm/mach-omap2/sram34xx.S
>> +++ b/arch/arm/mach-omap2/sram34xx.S
>> @@ -70,6 +70,7 @@
>> * r5 = number of MPU cycles to wait for SDRC to stabilize after
>> * reprogramming the SDRC when switching to a slower MPU speed
>> * r6 = new SDRC_MR_0 register value
>> + * r7 = increasing SDRC rate? (1 = yes, 0 = no)
>> *
>> */
>> ENTRY(omap3_sram_configure_core_dpll)
>> @@ -78,8 +79,8 @@ ENTRY(omap3_sram_configure_core_dpll)
>> ldr r5, [sp, #56] @ load extra args from the stack
>> ldr r6, [sp, #60] @ load extra args from the stack
>
>you will also need a
>
> ldr r7, [sp, #64] @ load extra args from the stack
>
>here
Woops. Resending in a bit.
Funny though that this patch does not seem to affect system stability
too
much at initial testing, it did not cause any crash when I tried this
out.
Might cause problems in longer run / stress testing.
>> dsb @ flush buffered writes
>to interconnect
>> -cmp r3, #0x2@ if increasing SDRC clk rate,
>> -blneconfigure_sdrc @ program the SDRC regs
>early (for RFR)
>> +cmp r7, #1 @ if increasing SDRC clk rate,
>> +bleqconfigure_sdrc @ program the SDRC regs
>early (for RFR)
>> cmp r4, #SDRC_UNLOCK_DLL@ set the intended DLL state
>> blequnlock_dll
>> blnelock_dll
>> @@ -89,7 +90,7 @@ ENTRY(omap3_sram_configure_core_dpll)
>> cmp r4, #SDRC_UNLOCK_DLL@ wait for DLL status to change
>> bleqwait_dll_unlock
>> blnewait_dll_lock
>> -cmp r3, #0x1@ if increasing SDRC clk rate,
>> +cmp r7, #1 @ if increasing SDRC clk rate,
>> beq return_to_sdram @ return to SDRAM code,
>otherwise,
>> bl configure_sdrc @ reprogram SDRC regs now
>> mov r12, r5
>> diff --git a/arch/arm/plat-omap/include/mach/sram.h
>> b/arch/arm/plat-omap/include/mach/sram.h
>> index d07da3b..ad0a600 100644
>> --- a/arch/arm/plat-omap/include/mach/sram.h
>> +++ b/arch/arm/plat-omap/include/mach/sram.h
>> @@ -24,7 +24,8 @@ extern u32 omap2_set_prcm(u32 dpll_ctrl_val, u32
>> sdrc_rfr_val, int bypass); extern u32
>omap3_configure_core_dpll(u32 sdrc_rfr_ctrl,
>> u32 sdrc_actim_ctrla,
>> u32 sdrc_actim_ctrlb, u32 m2,
>> - u32 unlock_dll, u32 f, u32
>sdrc_mr);
>> + u32 unlock_dll, u32 f, u32 sdrc_mr,
>> + u32 inc);
>> extern void omap3_sram_restore_context(void);
>>
>> /* Do not use these */
>> @@ -62,7 +63,9 @@ extern unsigned long
>> omap243x_sram_reprogram_sdrc_sz;
>>
>> extern u32 omap3_sram_configure_core_dpll(u32 sdrc_rfr_ctrl,
>>u32 sdrc_actim_ctrla,
>> - u32 sdrc_actim_ctrlb, u32 m2);
>> + u32 sdrc_actim_ctrlb, u32 m2,
>> + u32 unlock_dll, u32
>f, u32 sdrc_mr,
>> + u32 inc);
>> extern unsigned long omap3_sram_configure_core_dpll_sz;
>>
>> #ifdef CONFIG_PM
>> diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
>> index 68a1f69..9f6232f 100644
>> --- a/arch/arm/plat-omap/sram.c
>> +++ b/arch/arm/plat-omap/sram.c
>> @@ -372,10 +372,10 @@ static u32
>(*_omap3_sram_configure_core_dpll)(u32 sdrc_rfr_ctrl,
>>u32 sdrc_actim_ctrla,
>>u32 sdrc_actim_ctrlb,
>>u32 m2, u32 unlock_dll,
>> - u32 f, u32 sdrc_mr);
>> + u32 f, u32
>sdrc_mr, u32 inc);
>> u32 omap3_configure_core_dpll(u32 sdrc_rfr_ctrl, u32
>sdrc_actim_ctrla,
>>u32 sdrc_actim_ctrlb, u32 m2, u32
>unlock_dll,
>> - u32 f, u32 sdrc_mr)
>> + u32 f, u32 sdrc_mr, u32 inc)
>> {
>> if (!_omap3_sram_configure_core_dpll)
>> omap_sram_error();
>> @@ -383,7 +383,7 @@ u32 omap3_configure_core_dpll(u32
>sdrc_rfr_ctrl, u32 sdrc_actim_ctrla,
>> return _omap3_sram_configure_core_dpll(sdrc_rfr_ctrl,
>> sdrc_actim_ctrla,
>> sdrc_actim_ctrlb, m2,
>> - unlock_dll, f, sdrc_mr);
>> + unlock_dll, f
RE: [PATCH] OMAP3: Add support for DPLL3 divisor values higher than 2
Hi Kevin,
Sorry I was on a sick leave so could not reply to this.
>Tero Kristo writes:
>
>> Previously only 1 and 2 was supported. This is needed for
>DVFS VDD2 control.
>>
>
>Tero,
>
>What is this patch against? It doesn't apply to current PM
>branch, current l-o HEAD or on top of you DVFS patchset.
This patch was intended to replace:
[PATCH 20/23] OMAP3: Add support for DPLL3 divisor values higher than 2
...from the core dvfs patch set.
-Tero
>
>Kevin
>
>> Signed-off-by: Tero Kristo
>> ---
>> arch/arm/mach-omap2/clock34xx.c|9 +++--
>> arch/arm/mach-omap2/sram34xx.S |8 +---
>> arch/arm/plat-omap/include/mach/sram.h |7 +--
>> arch/arm/plat-omap/sram.c |6 +++---
>> 4 files changed, 16 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/clock34xx.c
>> b/arch/arm/mach-omap2/clock34xx.c index d6d4b46..b38cb30 100644
>> --- a/arch/arm/mach-omap2/clock34xx.c
>> +++ b/arch/arm/mach-omap2/clock34xx.c
>> @@ -516,9 +516,9 @@ static int
>omap3_core_dpll_m2_set_rate(struct clk
>> *clk, unsigned long rate)
>>
>> sdrcrate = sdrc_ick.rate;
>> if (rate > clk->rate)
>> -sdrcrate <<= ((rate / clk->rate) - 1);
>> +sdrcrate <<= ((rate / clk->rate) >> 1);
>> else
>> -sdrcrate >>= ((clk->rate / rate) - 1);
>> +sdrcrate >>= ((clk->rate / rate) >> 1);
>>
>> sp = omap2_sdrc_get_params(sdrcrate);
>> if (!sp)
>> @@ -545,13 +545,10 @@ static int
>omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate)
>> pr_debug("clock: SDRC timing params used: %08x %08x %08x\n",
>> sp->rfr_ctrl, sp->actim_ctrla, sp->actim_ctrlb);
>>
>> -/* REVISIT: SRAM code doesn't support other M2 divisors yet */
>> -WARN_ON(new_div != 1 && new_div != 2);
>> -
>> local_irq_disable();
>> omap3_configure_core_dpll(sp->rfr_ctrl, sp->actim_ctrla,
>>sp->actim_ctrlb, new_div,
>unlock_dll, c,
>> - sp->mr);
>> + sp->mr, rate > clk->rate);
>> local_irq_enable();
>>
>> omap2_clksel_recalc(clk);
>> diff --git a/arch/arm/mach-omap2/sram34xx.S
>> b/arch/arm/mach-omap2/sram34xx.S index 16eb4ef..487fa86 100644
>> --- a/arch/arm/mach-omap2/sram34xx.S
>> +++ b/arch/arm/mach-omap2/sram34xx.S
>> @@ -70,6 +70,7 @@
>> * r5 = number of MPU cycles to wait for SDRC to stabilize after
>> * reprogramming the SDRC when switching to a slower MPU speed
>> * r6 = new SDRC_MR_0 register value
>> + * r7 = increasing SDRC rate? (1 = yes, 0 = no)
>> *
>> */
>> ENTRY(omap3_sram_configure_core_dpll)
>> @@ -77,9 +78,10 @@ ENTRY(omap3_sram_configure_core_dpll)
>> ldr r4, [sp, #52] @ pull extra args off the stack
>> ldr r5, [sp, #56] @ load extra args from the stack
>> ldr r6, [sp, #60] @ load extra args from the stack
>> +ldr r7, [sp, #64] @ load extra args from the stack
>> dsb @ flush buffered writes
>to interconnect
>> -cmp r3, #0x2@ if increasing SDRC clk rate,
>> -blneconfigure_sdrc @ program the SDRC regs
>early (for RFR)
>> +cmp r7, #1 @ if increasing SDRC clk rate,
>> +bleqconfigure_sdrc @ program the SDRC regs
>early (for RFR)
>> cmp r4, #SDRC_UNLOCK_DLL@ set the intended DLL state
>> blequnlock_dll
>> blnelock_dll
>> @@ -89,7 +91,7 @@ ENTRY(omap3_sram_configure_core_dpll)
>> cmp r4, #SDRC_UNLOCK_DLL@ wait for DLL status to change
>> bleqwait_dll_unlock
>> blnewait_dll_lock
>> -cmp r3, #0x1@ if increasing SDRC clk rate,
>> +cmp r7, #1 @ if increasing SDRC clk rate,
>> beq return_to_sdram @ return to SDRAM code,
>otherwise,
>> bl configure_sdrc @ reprogram SDRC regs now
>> mov r12, r5
>> diff --git a/arch/arm/plat-omap/include/mach/sram.h
>> b/arch/arm/plat-omap/include/mach/sram.h
>> index d07da3b..ad0a600 100644
>> --- a/arch/arm/plat-omap/include/mach/sram.h
>> +++ b/arch/arm/plat-omap/include/mach/sram.h
>> @@ -24,7 +24,8 @@ extern u32 omap2_set_prcm(u32 dpll_ctrl_val, u32
>> sdrc_rfr_val, int bypass); extern u32
>omap3_configure_core_dpll(u32 sdrc_rfr_ctrl,
>> u32 sdrc_actim_ctrla,
>> u32 sdrc_actim_ctrlb, u32 m2,
>> - u32 unlock_dll, u32 f, u32
>sdrc_mr);
>> + u32 unlock_dll, u32 f, u32 sdrc_mr,
>> + u32 inc);
>> extern void omap3_sram_restore_context(void);
>>
>> /* Do not use these */
>> @@ -62,7 +63,9 @@ extern unsigned long
>> omap243x_sram_reprogram_sdrc_sz;
>>
>> extern u32 omap3_sram_configure_core_dpll(u32 sdrc_rfr_ctrl,
>>
getnstimeofday() and suspend
Hi, I noticed an interesting feature in the getnstimeofday() function when used with suspend. System clock is effectively reset to the value it was just before suspend. You can see this behavior e.g. with this command line: date && echo mem > /sys/power/state && date With approx. 2 minutes in suspend state the output for me was this: / # date && echo mem > sys/power/state && date Thu Jan 1 00:13:40 UTC 1970PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) Successfully put all powerdomains to target state Restarting tasks ... done. Thu Jan 1 00:13:42 UTC 1970 I.e., the calendar clock was only advanced 2 seconds. The time you spend in suspend does not matter, the end result is the same, it will reset the time to the value it was before suspend. Is this behavior intended? -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: getnstimeofday() and suspend
>-Original Message- >From: ext Tony Lindgren [mailto:[EMAIL PROTECTED] >Sent: 13 August, 2008 17:00 >To: Kristo Tero (Nokia-D/Tampere) >Cc: linux-omap@vger.kernel.org >Subject: Re: getnstimeofday() and suspend > >* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [080813 15:59]: >> Hi, >> >> I noticed an interesting feature in the getnstimeofday() >function when >> used with suspend. System clock is effectively reset to the value it >> was just before suspend. You can see this behavior e.g. with this >> command >> line: >> >> date && echo mem > /sys/power/state && date >> >> With approx. 2 minutes in suspend state the output for me was this: >> >> / # date && echo mem > sys/power/state && date Thu Jan 1 >00:13:40 UTC >> 1970PM: Syncing filesystems ... >> done. >> Freezing user space processes ... (elapsed 0.00 seconds) done. >> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. >> Suspending console(s) >> Successfully put all powerdomains to target state Restarting >tasks ... >> done. >> Thu Jan 1 00:13:42 UTC 1970 >> >> I.e., the calendar clock was only advanced 2 seconds. The time you >> spend in suspend does not matter, the end result is the >same, it will >> reset the time to the value it was before suspend. >> >> Is this behavior intended? > >Hmm, well it should get the value straight from the 32KiHZ sync timer. >Does that get stopped somehow during suspend? > >Tony > Timer is not stopped, because immediately after suspend I get correct value from it (called from wakeup interrupt), but after this it is reprogrammed by something, or either time management code gets confused somehow. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: getnstimeofday() and suspend
>>Hmm, well it should get the value straight from the 32KiHZ sync timer. >>Does that get stopped somehow during suspend? >> >>Tony >> > >Timer is not stopped, because immediately after suspend I get >correct value from it (called from wakeup interrupt), but >after this it is reprogrammed by something, or either time >management code gets confused somehow. Hi Tony, This behavior of the getnstimeofday() is breaking pm-debug and the serial console wakeup hack if we use suspend. Enabling RTC module seems to fix some of the issues in some cases, but we are going to lose timer accuracy (RTC accuracy is only 1 second.) Also, these functionalities should not be dependant on RTC imo. Should I revert these patches to use directly HW timer and ignore getnstimeofday() or what do you think? -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: getnstimeofday() and suspend
>-Original Message- >From: Stoppa Igor (Nokia-D/Helsinki) >Sent: 15 August, 2008 13:11 >To: Hogander Jouni (Nokia-D/Tampere) >Cc: Kristo Tero (Nokia-D/Tampere); [EMAIL PROTECTED]; >linux-omap@vger.kernel.org >Subject: Re: getnstimeofday() and suspend > >On Fri, 2008-08-15 at 12:55 +0300, Högander Jouni wrote: > >> Using them both would also generate more complexity. What >would be the >> benefit in using them both? > >The RTC should be used during suspend since it's supposed to >keep track of time regardless of how long the duration of the >suspension is. > >The 32kHz alone is not a good generic solution since it >overflows after a couple of days. General problem seems to be that arch/arm has not defined read_persistent_clock() function. Attached patch tries to fix this problem by using a 32k counter hack. Probably something similar should be done which checks for overflows and uses RTC if available. -Tero 0001-Fixed-timekeeping-bug-during-suspend.patch Description: 0001-Fixed-timekeeping-bug-during-suspend.patch
RE: [PATCH 3/4] Added sleep support to UART
>-Original Message- >From: ext Tony Lindgren [mailto:[EMAIL PROTECTED] >Sent: 20 August, 2008 14:40 >To: Hogander Jouni (Nokia-D/Tampere) >Cc: linux-omap@vger.kernel.org; Kristo Tero (Nokia-D/Tampere) >Subject: Re: [PATCH 3/4] Added sleep support to UART > >* Jouni Hogander <[EMAIL PROTECTED]> [080815 10:48]: >> From: Tero Kristo <[EMAIL PROTECTED]> >> >> UART usage (e.g. serial console) now denies sleep for 5 >seconds. This >> makes it possible to use serial console when dynamic idle is >enabled. >> Write 1 to /sys/power/clocks_off_while_sleep to enable uart clock >> disable on idle. Without this omap won't enter retention. >> >> Also moved code from pm-debug.c to serial.c, and made pm24xx.c use >> this new implementation. > >This looks OK and safe to apply now. I guess it depends on the >GPIO patch above though? Yes, checks for the sleep conditions and dynamic clock disable / enable mechanism are introduced in the GPIO patch. I think it would be possible to change the order of dependency if needed though, but this would require changes to both patches. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] PM: Workaround for taking care of gpio clocks
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of ext >Tony Lindgren >Sent: 20 August, 2008 14:37 >To: Hogander Jouni (Nokia-D/Tampere) >Cc: linux-omap@vger.kernel.org >Subject: Re: [PATCH 2/4] PM: Workaround for taking care of gpio clocks > >* Jouni Hogander <[EMAIL PROTECTED]> [080815 10:47]: >> In omap3 gpios 2-6 are in per domain. Functional clocks for these >> should be disabled. This patch is needed until gpio driver disables >> gpio clocks. >> >> GPIO modules in PER domain are not able to act as a wake up >source if >> PER domain is in retention. PER domain sleep transition >before MPU is >> prevented by leaving icks active. PER domain still enters retention >> together with MPU. When this happens IOPAD wake up mechanism is used >> for gpios. > >As we talked offline.. Should we pass the GPIO wake-up >configuration from board-*.c files? Or can we always >automatically do this safely on 34xx? After some investigation it seems that we can configure wake-up events for almost every GPIO from the padconfigs. There are only 2 pins that do not seem to have this functionality, however I am not sure if this is a documentation bug or what because it is strange that only 2 pins lack this capability. GPIOs 32 and 187 are missing wake-up capability from padconfig. Because of this, our proposal would be to make GPIO clock switching global, but this would be enabled from a sysfs entry pretty much like how it is in the patches now. However, this would be separated from UART clock switching. So, we would introduce two new sysfs files: uart_clocks_off_while_idle and gpio_clocks_off_while_idle. This would avoid introducing new complexity in to the idle loop. How does this sound like? -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fixed CPU type check for OMAP3
Oops, minor bug here, pr_info is still putting out wrong data, should be
from the array I added. Sending new patch soon.
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of ext Tero Kristo
>Sent: 08 September, 2008 19:34
>To: linux-omap@vger.kernel.org
>Subject: [PATCH] Fixed CPU type check for OMAP3
>
>ES version definitions were incorrect, also GP/EMU/SEC etc.
>types were not detected at all.
>
>Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
>---
> arch/arm/mach-omap2/id.c |9 -
> arch/arm/plat-omap/include/mach/cpu.h |2 +-
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
>diff --git a/arch/arm/mach-omap2/id.c
>b/arch/arm/mach-omap2/id.c index a526c0f..290b88c 100644
>--- a/arch/arm/mach-omap2/id.c
>+++ b/arch/arm/mach-omap2/id.c
>@@ -53,6 +53,13 @@ static struct omap_id omap_ids[] __initdata = {
> { .hawkeye = 0xb68a, .dev = 0x0, .type = 0x2430 }, };
>
>+static const char omap3_revs[][4] = {
>+ "1.0",
>+ "2.0",
>+ "2.1",
>+ "3.0"
>+};
>+
> static struct omap_chip_id omap_chip;
>
> /**
>@@ -224,7 +231,7 @@ void __init omap2_check_revision(void)
>* Note that rev cannot be used directly as ES1.0 uses value 0.
>*/
> if (hawkeye == 0xb7ae) {
>- system_rev = 0x3430 | ((1 + rev) << 12);
>+ _set_system_rev(0x3430 | (rev << 12), rev);
> pr_info("OMAP%04x ES2.%i\n", system_rev >> 16, rev);
> _set_omap_chip();
> return;
>diff --git a/arch/arm/plat-omap/include/mach/cpu.h
>b/arch/arm/plat-omap/include/mach/cpu.h
>index e046418..e170d29 100644
>--- a/arch/arm/plat-omap/include/mach/cpu.h
>+++ b/arch/arm/plat-omap/include/mach/cpu.h
>@@ -357,7 +357,7 @@ IS_OMAP_TYPE(3430, 0x3430)
> #define OMAP3430_REV_ES1_00x3430
> #define OMAP3430_REV_ES2_00x34301000
> #define OMAP3430_REV_ES2_10x34302000
>-#define OMAP3430_REV_ES2_20x34303000
>+#define OMAP3430_REV_ES3_00x34303000
>
> /*
> * omap_chip bits
>--
>1.5.4.3
>
>--
>To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in the body of a message to
>[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fixed CPU type check for OMAP3
>From: ext Tony Lindgren [mailto:[EMAIL PROTECTED] >Sent: 11 September, 2008 03:29 > >I've redone the id.c, the old one was getting messy for omap2. >Maybe try my patch I posted on Tuesday and see how it works for you? Hmm did not notice this patch, just made a quick fix for this as I was seeing some problems with CPU type detection. I need to check this out when I have more time for this. > >Also one comment below. >> #define OMAP3430_REV_ES1_0 0x3430 >> #define OMAP3430_REV_ES2_0 0x34301000 >> #define OMAP3430_REV_ES2_1 0x34302000 >> -#define OMAP3430_REV_ES2_2 0x34303000 >> +#define OMAP3430_REV_ES3_0 0x34303000 >> >> /* >> * omap_chip bits > >Are you sure ES3.0 gives a three for revision? I believe 2.2 >had 3, or is the revision register broken again? I have tested this piece of code with ES2.1 and ES3.0 and it gives correct results, so I am certain 3.0 gives a 3 for rev. Regarding 2.2 I am not so sure, I think such chip revision does not exist at all. There was also something weird with the earlier code as it increased revision by 1, thus giving wrong results for any revision... and causing is_sil_rev_* macros to give incorrect results. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] PM: Dynamic GPIO clock handling
These comments should now be fixed in the new version I just sent out.
-Tero
>-Original Message-
>From: Högander Jouni [mailto:[EMAIL PROTECTED]
>Sent: 05 September, 2008 16:47
>To: ext Paul Walmsley
>Cc: Kristo Tero (Nokia-D/Tampere); linux-omap@vger.kernel.org
>Subject: Re: [PATCH 1/4] PM: Dynamic GPIO clock handling
>
>"ext Paul Walmsley" <[EMAIL PROTECTED]> writes:
>
>> Hello Tero, Jouni,
>>
>> so is this basically a workaround patch?
>
>Yes in new format. Please do not use word workaround;)
>
>>
>> a few comments:
>>
>> On Wed, 27 Aug 2008, Tero Kristo wrote:
>>
>>> From: ext Jouni Hogander <[EMAIL PROTECTED]>
>>>
>>> In omap3 gpios 2-6 are in per domain. Functional clocks for these
>>> should be disabled.
>>>
>>> GPIO modules in PER domain are not able to act as a wake up
>source if
>>> PER domain is in retention. PER domain sleep transition
>before MPU is
>>> prevented by leaving icks active. PER domain still enters retention
>>> together with MPU. When this happens IOPAD wake up
>mechanism is used
>>> for gpios.
>>>
>>> Signed-off-by: Jouni Hogander <[EMAIL PROTECTED]>
>>> ---
>>> arch/arm/mach-omap2/pm.c | 20 --
>>> arch/arm/mach-omap2/pm.h |2 +-
>>> arch/arm/mach-omap2/pm34xx.c | 56
>+-
>>> 3 files changed, 67 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
>>> index 4652136..1de5f14 100644
>>> --- a/arch/arm/mach-omap2/pm.c
>>> +++ b/arch/arm/mach-omap2/pm.c
>>> @@ -32,7 +32,7 @@
>>> #include "pm.h"
>>>
>>> unsigned short enable_dyn_sleep;
>>> -unsigned short clocks_off_while_idle;
>>> +unsigned short gpio_clocks_off_while_idle;
>>> atomic_t sleep_block = ATOMIC_INIT(0);
>>>
>>> static ssize_t idle_show(struct kobject *, struct
>kobj_attribute *,
>>> char *); @@ -42,16 +42,16 @@ static ssize_t
>idle_store(struct kobject
>>> *k, struct kobj_attribute *, static struct kobj_attribute
>sleep_while_idle_attr =
>>> __ATTR(sleep_while_idle, 0644, idle_show, idle_store);
>>>
>>> -static struct kobj_attribute clocks_off_while_idle_attr =
>>> - __ATTR(clocks_off_while_idle, 0644, idle_show, idle_store);
>>> +static struct kobj_attribute gpio_clocks_off_while_idle_attr =
>>> + __ATTR(gpio_clocks_off_while_idle, 0644, idle_show, idle_store);
>>>
>>> static ssize_t idle_show(struct kobject *kobj, struct
>kobj_attribute *attr,
>>> char *buf)
>>> {
>>> if (attr == &sleep_while_idle_attr)
>>> return sprintf(buf, "%hu\n", enable_dyn_sleep);
>>> - else if (attr == &clocks_off_while_idle_attr)
>>> - return sprintf(buf, "%hu\n", clocks_off_while_idle);
>>> + else if (attr == &gpio_clocks_off_while_idle_attr)
>>> + return sprintf(buf, "%hu\n",
>gpio_clocks_off_while_idle);
>>> else
>>> return -EINVAL;
>>> }
>>> @@ -69,8 +69,8 @@ static ssize_t idle_store(struct kobject *kobj,
>>> struct kobj_attribute *attr,
>>>
>>> if (attr == &sleep_while_idle_attr)
>>> enable_dyn_sleep = value;
>>> - else if (attr == &clocks_off_while_idle_attr)
>>> - clocks_off_while_idle = value;
>>> + else if (attr == &gpio_clocks_off_while_idle_attr)
>>> + gpio_clocks_off_while_idle = value;
>>> else
>>> return -EINVAL;
>>>
>>> @@ -106,10 +106,12 @@ static int __init omap_pm_init(void)
>>> /* disabled till drivers are fixed */
>>> enable_dyn_sleep = 0;
>>> error = sysfs_create_file(power_kobj,
>&sleep_while_idle_attr.attr);
>>> - if (error)
>>> + if (error) {
>>> printk(KERN_ERR "sysfs_create_file failed:
>%d\n", error);
>>> + return error;
>>> + }
>>> error = sysfs_create_file(power_kobj,
>>> - &clocks_off_while_idle_attr.attr);
>>> +
>&gpio_clocks_off_while_idle_attr.attr);
>>> if (error)
>>> printk(KERN_ERR "sysfs_create_file failed:
>%d\n", error);
>>>
>>> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
>>> index 68c9278..d446ea4 100644
>>> --- a/arch/arm/mach-omap2/pm.h
>>> +++ b/arch/arm/mach-omap2/pm.h
>>> @@ -17,7 +17,7 @@ extern int omap2_pm_init(void); extern int
>>> omap3_pm_init(void);
>>>
>>> extern unsigned short enable_dyn_sleep; -extern unsigned short
>>> clocks_off_while_idle;
>>> +extern unsigned short gpio_clocks_off_while_idle;
>>> extern atomic_t sleep_block;
>>>
>>> extern void omap2_block_sleep(void); diff --git
>>> a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index
>>> a16eb33..0baf359 100644
>>> --- a/arch/arm/mach-omap2/pm34xx.c
>>> +++ b/arch/arm/mach-omap2/pm34xx.c
>>> @@ -53,6 +53,43 @@ static void (*saved_idle)(void);
>>>
>>> static struct powerdomain *mpu_pwrdm;
>>>
>>> +/* Dynamic GPIO clock handling for sleep routines.
>>> + * omap_sram_idle() will call these functions and they will
>>> +dynamically
>>> + * enable / disab
RE: [PATCH] PM: Added sleep support to UART
Just a quick comment to this patch, there might be issues (again) with OMAP2 as the patch has lived again a bit. So, someone should preferably test this on OMAP2 before integrating. This is now a standalone version of the patch and does not require GPIO patch below to work. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] PM debug support for 34xx
Any comments to this? I have already a new version available of this
stuff where I have integrated the suspend / next state control to this
also, and the file structure modified a bit.
Should this be split into several patches for easier handling or
something? It is getting rather big already (as a patch.)
-Tero
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of ext Tero Kristo
>Sent: 12 September, 2008 14:49
>To: linux-omap@vger.kernel.org
>Subject: [PATCH] PM debug support for 34xx
>
>This patch adds a few files to the debug file system for PM
>debugging purposes. Enabled with kernel config options
>CONFIG_PM_DEBUG and CONFIG_DEBUG_FS. Data available in debug
>filesystem after this patch:
>- State enter counters for power domains (OFF, RET, ON)
>- State timers for the above (in ns)
>- PM register dumps with programmable save points
>- Current power domain states
>- Interface to set_pwrdm_state()
>
>Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
>---
> arch/arm/mach-omap2/clock.c |2 +
> arch/arm/mach-omap2/clockdomain.c | 27 ++
> arch/arm/mach-omap2/pm-debug.c| 406
>+
> arch/arm/mach-omap2/pm.c |2 +
> arch/arm/mach-omap2/pm.h | 33 ++-
> arch/arm/mach-omap2/pm34xx.c |6 +-
> arch/arm/mach-omap2/powerdomain.c | 69 +
> arch/arm/plat-omap/include/mach/powerdomain.h |7 +-
> 8 files changed, 548 insertions(+), 4 deletions(-)
>
>diff --git a/arch/arm/mach-omap2/clock.c
>b/arch/arm/mach-omap2/clock.c index 88c8ef4..a5fc5b0 100644
>--- a/arch/arm/mach-omap2/clock.c
>+++ b/arch/arm/mach-omap2/clock.c
>@@ -39,6 +39,7 @@
> #include "cm.h"
> #include "cm-regbits-24xx.h"
> #include "cm-regbits-34xx.h"
>+#include "pm.h"
>
> #define MAX_CLOCK_ENABLE_WAIT 10
>
>@@ -1025,5 +1026,6 @@ void omap2_clk_disable_unused(struct clk *clk)
>
> printk(KERN_INFO "Disabling unused clock \"%s\"\n", clk->name);
> _omap2_clk_disable(clk);
>+ pm_dbg_clk_state_switch(clk);
> }
> #endif
>diff --git a/arch/arm/mach-omap2/clockdomain.c
>b/arch/arm/mach-omap2/clockdomain.c
>index fa62f14..9670ed1 100644
>--- a/arch/arm/mach-omap2/clockdomain.c
>+++ b/arch/arm/mach-omap2/clockdomain.c
>@@ -36,6 +36,8 @@
> #include
> #include
>
>+#include "pm.h"
>+
> /* clkdm_list contains all registered struct clockdomains */
>static LIST_HEAD(clkdm_list);
>
>@@ -567,6 +569,8 @@ int omap2_clkdm_clk_enable(struct
>clockdomain *clkdm, struct clk *clk)
> else
> omap2_clkdm_wakeup(clkdm);
>
>+ pm_dbg_clkdm_state_switch(clkdm);
>+
> return 0;
> }
>
>@@ -618,6 +622,29 @@ int omap2_clkdm_clk_disable(struct
>clockdomain *clkdm, struct clk *clk)
> else
> omap2_clkdm_sleep(clkdm);
>
>+ pm_dbg_clkdm_state_switch(clkdm);
>+
>+ return 0;
>+}
>+
>+#if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS) #include
>+ #include int
>+clkdm_dbg_show_counters(struct seq_file *s, void *unused) {
>+ struct clockdomain *clkdm;
>+
>+ list_for_each_entry(clkdm, &clkdm_list, node) {
>+ if (strcmp(clkdm->name, "emu_clkdm") == 0 ||
>+ strcmp(clkdm->name, "wkup_clkdm") == 0)
>+ continue;
>+ seq_printf(s, "%s->%s (%d)", clkdm->name,
>+ clkdm->pwrdm.ptr->name,
>+ atomic_read(&clkdm->usecount));
>+ seq_printf(s, "\n");
>+ }
>+
> return 0;
> }
>
>+#endif
>diff --git a/arch/arm/mach-omap2/pm-debug.c
>b/arch/arm/mach-omap2/pm-debug.c index b00f5f4..380a2a0 100644
>--- a/arch/arm/mach-omap2/pm-debug.c
>+++ b/arch/arm/mach-omap2/pm-debug.c
>@@ -30,6 +30,9 @@
> #include
> #include
>
>+#include
>+#include
>+#include
> #include "prm.h"
> #include "cm.h"
> #include "pm.h"
>@@ -153,4 +156,407 @@ void omap2_pm_dump(int mode, int resume,
>unsigned int us)
> printk("%-20s: 0x%08x\n", regs[i].name, regs[i].val); }
>
>+#ifdef CONFIG_DEBUG_FS
>+#include
>+#include
>+
>+static void pm_dbg_regset_store(u32 *ptr);
>+
>+struct dentry *pm_dbg_dir;
>+
>+static int pm_dbg_init_done;
>+
>+enum {
>+ PM_DBG_STATE_NOW = 0,
>+ PM_DBG_STATE_PREV,
>+};
>+
>+struct pm_module_def {
>+ char name[8]; /* Name of the module */
>+ short type; /* CM or PRM */
>+ unsigned short offset;
>+ int low; /* First register address on this module */
>+ int high; /* Last register address on this module */ };
>+
>+#define MOD_CM 0
>+#define MOD_PRM 1
>+
>+static const struct pm_module_def pm_dbg_reg_modules[] = {
>+ { "IVA2", MOD_CM, OMAP3430_IVA2_MOD, 0, 0x4c },
>+ { "OCP", MOD_CM, OCP_MOD, 0, 0x10 },
>+ { "MPU", MOD_CM, MPU_MOD, 4, 0x4c },
>+ { "CORE", MOD_CM, CORE_MOD, 0, 0x4c },
>+ { "SGX", MOD_CM, OMAP3430ES2_SGX_MOD, 0, 0x4c },
>+ { "WKUP", MOD_CM, WKUP_MOD, 0, 0x40 },
>+ {
RE: [PATCH] PM: Fixed clockdomain state control for OMAP3
Hi Paul, reply below.
>-Original Message-
>From: ext Paul Walmsley [mailto:[EMAIL PROTECTED]
>Sent: 23 September, 2008 16:02
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH] PM: Fixed clockdomain state control for OMAP3
>
>Hello Tero,
>
>a few comments.
>
>On Tue, 16 Sep 2008, Tero Kristo wrote:
>
>> -pwrdm_for_each_clkdm(pwrdm, _clkdm_deny_idle);
>> -
>> +if (pwrdm_read_pwrst(pwrdm) < PWRDM_POWER_ON) {
>> +omap2_clkdm_wakeup(pwrdm->pwrdm_clkdms[0]);
>
>In general, shouldn't this happen for each clkdm in the pwrdm?
> i.e., you should probably create some _clkdm_wakeup() (similar to
>_clkdm_allow_idle() ) and call that via pwrdm_for_each_clkdm().
>
>This may not have any functional effect at present with OMAP3,
>but avoids the assumption that each powerdomain will have only
>one software-controllable clockdomain (and that it will always
>appear at the 0 element in the array).
The access of element 0 only is not because we have only 1 clockdomain
for each powerdomain, but because we only want to wake up some
clockdomain
to make the powerdomain come up. It does not matter which clockdomain is
awakened, as long as one is, and I don't think it makes sense to wake
all
of them up because this would cause additional overhead.
>
>> +sleep_switch = 1;
>> +pwrdm_wait_transition(pwrdm);
>> +}
>> +
>> ret = pwrdm_set_next_pwrst(pwrdm, state);
>> if (ret) {
>> printk(KERN_ERR "Unable to set state of
>powerdomain: %s\n", @@
>> -268,7 +257,10 @@ static int set_pwrdm_state(struct
>powerdomain *pwrdm, u32 state)
>> goto err;
>> }
>>
>> -pwrdm_for_each_clkdm(pwrdm, _clkdm_allow_idle);
>> +if (sleep_switch) {
>> +omap2_clkdm_allow_idle(pwrdm->pwrdm_clkdms[0]);
>
>Same comment as previous - shouldn't _clkdm_allow_idle() be
>kept, and called for each clkdm in the pwrdm, instead?
Same comment.
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
clk_disable_unused() is bugged
Hi, clk_disable_unused (in plat-omap/clock.c) is bugged in latest kernel. It checks whether ck->enable_reg is zero, and in most cases this happens to be so (CM_FCLKEN = 0.) Seems to be caused by some late change to clocktree where enable_reg fields are defined as module offsets, not register addresses. This bug causes several clocks to remain enabled after boot, and at least on OMAP3 it prevents retention. Paul, you got a fix coming for this? -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fixed OMAP3 version check
>-Original Message-
>From: Balbi Felipe (Nokia-D/Helsinki)
>Sent: 25 September, 2008 14:41
>To: ext Tony Lindgren
>Cc: Balbi Felipe (Nokia-D/Helsinki); Kristo Tero
>(Nokia-D/Tampere); linux-omap@vger.kernel.org
>Subject: Re: [PATCH] Fixed OMAP3 version check
>
>On Thu, Sep 25, 2008 at 01:31:21PM +0300, Tony Lindgren wrote:
>> * Felipe Balbi <[EMAIL PROTECTED]> [080925 13:24]:
>> > On Thu, Sep 25, 2008 at 01:17:51PM +0300, Tony Lindgren wrote:
>> > > Hi,
>> > >
>> > > * Tero Kristo <[EMAIL PROTECTED]> [080916 14:59]:
>> > > > CPU version was reported incorrectly (e.g. ES3.0 instead of
>> > > > ES2.1.) Also added a piece of optimization for CPU
>type check (omap_type()).
>> > > >
>> > > > Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
>> > > > ---
>> > > > arch/arm/mach-omap2/id.c |7 +--
>> > > > 1 files changed, 5 insertions(+), 2 deletions(-)
>> > > >
>> > > > diff --git a/arch/arm/mach-omap2/id.c
>b/arch/arm/mach-omap2/id.c
>> > > > index ab7a6e9..4e2b449 100644
>> > > > --- a/arch/arm/mach-omap2/id.c
>> > > > +++ b/arch/arm/mach-omap2/id.c
>> > > > @@ -37,7 +37,10 @@ EXPORT_SYMBOL(omap_chip_is);
>> > > >
>> > > > int omap_type(void)
>> > > > {
>> > > > - u32 val = 0;
>> > > > + static u32 val;
>> > > > +
>> > > > + if (val != 0)
>> > > > + return val;
>> > >
>> > > Hmm I guess this would return a random val? :)
>> >
>> > it would return 0, look that val is static.
>>
>> Ah, sorry I did not see the static. So this is to cache the
>result to
>> optimize it? I'd assume this function is only needed during
>some init
>> code hopefully where performance does not matter..
>
>Yeah, it's not like we're gonna check the revision after the
>board is botted all up I guess.
PM code will need to either cache the type information or call this
check every time when entering off-mode. Some things work differently in
secure chips. Could probably just cache this inside PM code.
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fixed OMAP3 version check
>-Original Message-
>From: ext Tony Lindgren [mailto:[EMAIL PROTECTED]
>Sent: 25 September, 2008 14:50
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: Balbi Felipe (Nokia-D/Helsinki); linux-omap@vger.kernel.org
>Subject: Re: [PATCH] Fixed OMAP3 version check
>
>* Tony Lindgren <[EMAIL PROTECTED]> [080925 14:47]:
>> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [080925 14:45]:
>> >
>> >
>> > >-Original Message-
>> > >From: Balbi Felipe (Nokia-D/Helsinki)
>> > >Sent: 25 September, 2008 14:41
>> > >To: ext Tony Lindgren
>> > >Cc: Balbi Felipe (Nokia-D/Helsinki); Kristo Tero
>(Nokia-D/Tampere);
>> > >linux-omap@vger.kernel.org
>> > >Subject: Re: [PATCH] Fixed OMAP3 version check
>> > >
>> > >On Thu, Sep 25, 2008 at 01:31:21PM +0300, Tony Lindgren wrote:
>> > >> * Felipe Balbi <[EMAIL PROTECTED]> [080925 13:24]:
>> > >> > On Thu, Sep 25, 2008 at 01:17:51PM +0300, Tony Lindgren wrote:
>> > >> > > Hi,
>> > >> > >
>> > >> > > * Tero Kristo <[EMAIL PROTECTED]> [080916 14:59]:
>> > >> > > > CPU version was reported incorrectly (e.g. ES3.0
>instead of
>> > >> > > > ES2.1.) Also added a piece of optimization for CPU
>> > >type check (omap_type()).
>> > >> > > >
>> > >> > > > Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
>> > >> > > > ---
>> > >> > > > arch/arm/mach-omap2/id.c |7 +--
>> > >> > > > 1 files changed, 5 insertions(+), 2 deletions(-)
>> > >> > > >
>> > >> > > > diff --git a/arch/arm/mach-omap2/id.c
>> > >b/arch/arm/mach-omap2/id.c
>> > >> > > > index ab7a6e9..4e2b449 100644
>> > >> > > > --- a/arch/arm/mach-omap2/id.c
>> > >> > > > +++ b/arch/arm/mach-omap2/id.c
>> > >> > > > @@ -37,7 +37,10 @@ EXPORT_SYMBOL(omap_chip_is);
>> > >> > > >
>> > >> > > > int omap_type(void)
>> > >> > > > {
>> > >> > > > - u32 val = 0;
>> > >> > > > + static u32 val;
>> > >> > > > +
>> > >> > > > + if (val != 0)
>> > >> > > > + return val;
>> > >> > >
>> > >> > > Hmm I guess this would return a random val? :)
>> > >> >
>> > >> > it would return 0, look that val is static.
>> > >>
>> > >> Ah, sorry I did not see the static. So this is to cache the
>> > >result to
>> > >> optimize it? I'd assume this function is only needed during
>> > >some init
>> > >> code hopefully where performance does not matter..
>> > >
>> > >Yeah, it's not like we're gonna check the revision after
>the board
>> > >is botted all up I guess.
>> >
>> > PM code will need to either cache the type information or
>call this
>> > check every time when entering off-mode. Some things work
>> > differently in secure chips. Could probably just cache
>this inside PM code.
>>
>> How about setting up the save and restore registers properly for GP
>> and HS omap once during PM init?
>
>To clarify: Set the save and restore registers and needed
>functions only once during PM init depending on the omap type.
That would be possible also. We only have two additional things to do in
secure OMAP chips anyway, so it is not a big deal. Need to get the damn
thing working first though, can think about optimizations later. >.<
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fixed OMAP3 version check
Hi,
Here is a fix that works on top of your patch. Tested with ES2.1 and
ES3.0 chips. I left out the caching for CPU type.
-Tero
>-Original Message-
>From: ext Tony Lindgren [mailto:[EMAIL PROTECTED]
>Sent: 25 September, 2008 13:18
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH] Fixed OMAP3 version check
>
>Hi,
>
>* Tero Kristo <[EMAIL PROTECTED]> [080916 14:59]:
>> CPU version was reported incorrectly (e.g. ES3.0 instead of ES2.1.)
>> Also added a piece of optimization for CPU type check (omap_type()).
>>
>> Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
>> ---
>> arch/arm/mach-omap2/id.c |7 +--
>> 1 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/id.c
>b/arch/arm/mach-omap2/id.c index
>> ab7a6e9..4e2b449 100644
>> --- a/arch/arm/mach-omap2/id.c
>> +++ b/arch/arm/mach-omap2/id.c
>> @@ -37,7 +37,10 @@ EXPORT_SYMBOL(omap_chip_is);
>>
>> int omap_type(void)
>> {
>> -u32 val = 0;
>> +static u32 val;
>> +
>> +if (val != 0)
>> +return val;
>
>Hmm I guess this would return a random val? :)
>
>
>> if (cpu_is_omap24xx()) {
>> val = omap_ctrl_readl(OMAP24XX_CONTROL_STATUS);
>> @@ -169,7 +172,7 @@ void __init omap34xx_check_revision(void)
>> rev = (idcode >> 28) & 0xff;
>>
>> if (hawkeye == 0xb7ae)
>> -system_rev = 0x34300034 | ((1 + rev) << 12);
>> +system_rev = 0x34300034 | (rev << 12);
>>
>> out:
>> switch (system_rev) {
>
>Well AFAIK here are the numbers for rev:
>
>ES1.0 0/* Cannot read idcode register */
>ES2.0 0
>ES2.1 1
>ES3.0 2
>
>While ES3.0 TRM claims:
>
>ES1.0 0
>ES2.0 1
>ES2.1 2
>ES3.0 3
>
>Which I think is incorrect at least for ES2.0 and ES2.1.
>
>Can you please try the attached patch and see if it detects
>your ES3.0 correctly?
>
>Tony
>
0001-OMAP3-Fixed-version-check.patch
Description: 0001-OMAP3-Fixed-version-check.patch
RE: [PATCH] OMAP3 clock: put DPLL into bypass if bypass rate = clk->rate, not hardware rate
Hi, The three patches you sent (fix CONFIG_OMAP_RESET_CLOCKS, fix dss1_alwon_clk and this one) seem to fix problems I was seeing with retention. -Tero >-Original Message- >From: ext Paul Walmsley [mailto:[EMAIL PROTECTED] >Sent: 25 September, 2008 17:39 >To: linux-omap@vger.kernel.org >Cc: Kristo Tero (Nokia-D/Tampere); [EMAIL PROTECTED] >Subject: [PATCH] OMAP3 clock: put DPLL into bypass if bypass >rate = clk->rate, not hardware rate > > >When a non-CORE DPLL is enabled via >omap3_noncore_dpll_enable(), use the user's desired rate in >clk->rate to determine whether to put the DPLL into bypass or >lock mode, rather than reading the DPLL's current idle state >from its hardware registers. > >This fixes a bug observed when leaving retention. Non-CORE >DPLLs were not being relocked when downstream clocks >re-enabled; rather, the DPLL entered bypass mode. > >Problem reported by Tero Kristo <[EMAIL PROTECTED]>. > >Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]> >--- > arch/arm/mach-omap2/clock34xx.c |4 +--- > 1 files changed, 1 insertions(+), 3 deletions(-) > >diff --git a/arch/arm/mach-omap2/clock34xx.c >b/arch/arm/mach-omap2/clock34xx.c index c89d6bc..df258f7 100644 >--- a/arch/arm/mach-omap2/clock34xx.c >+++ b/arch/arm/mach-omap2/clock34xx.c >@@ -281,9 +281,7 @@ static int >omap3_noncore_dpll_enable(struct clk *clk) > if (!dd) > return -EINVAL; > >- rate = omap2_get_dpll_rate(clk); >- >- if (dd->bypass_clk->rate == rate) >+ if (clk->rate == dd->bypass_clk->rate) > r = _omap3_noncore_dpll_bypass(clk); > else > r = _omap3_noncore_dpll_lock(clk); > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/3] Add pm-debug counters
>"ext Peter 'p2' De Schrijver" <[EMAIL PROTECTED]> writes:
>
>> This patch provides the debugfs entries and a function which will be
>> called by the PM code to register the time spent per domain
>per state.
>>
>> Signed-off-by: Peter 'p2' De Schrijver <[EMAIL PROTECTED]>
>> ---
>> arch/arm/mach-omap2/pm-debug.c| 175
>+
>> arch/arm/mach-omap2/pm.h |2 +
>> 2 files changed, 177 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/pm-debug.c
>> b/arch/arm/mach-omap2/pm-debug.c index 0b5c044..4ba6cec 100644
>> --- a/arch/arm/mach-omap2/pm-debug.c
>> +++ b/arch/arm/mach-omap2/pm-debug.c
>> @@ -29,6 +29,8 @@
>>
>> #include
>> #include
>> +#include
>> +#include
>>
>> #include "prm.h"
>> #include "cm.h"
>> @@ -288,4 +290,177 @@ void omap2_pm_dump(int mode, int
>resume, unsigned int us)
>> printk("%-20s: 0x%08x\n", regs[i].name, regs[i].val); }
>>
>> +#ifdef CONFIG_DEBUG_FS
>> +#include
>> +#include
>> +
>> +struct dentry *pm_dbg_dir;
>> +
>> +static int pm_dbg_init_done;
>> +
>> +enum {
>> +DEBUG_FILE_COUNTERS = 0,
>> +DEBUG_FILE_TIMERS,
>> +};
>> +
>> +static const char pwrdm_state_names[][4] = {
>> +"OFF",
>> +"RET",
>> +"INA",
>> +"ON"
>> +};
>> +
>> +void pm_dbg_update_time(struct powerdomain *pwrdm, int prev) {
>> +s64 t;
>> +struct timespec now;
>> +
>> +if (!pm_dbg_init_done)
>> +return ;
>> +
>> +/* Update timer for previous state */
>> +getnstimeofday(&now);
>> +t = timespec_to_ns(&now);
>> +
>> +pwrdm->state_timer[prev] += t - pwrdm->timer;
>> +
>> +pwrdm->timer = t;
>> +}
>> +
>> +static int clkdm_dbg_show_counter(struct clockdomain *clkdm, void
>> +*user) {
>> +struct seq_file *s = (struct seq_file *)user;
>> +
>> +if (strcmp(clkdm->name, "emu_clkdm") == 0 ||
>> +strcmp(clkdm->name, "wkup_clkdm") == 0)
>> +return 0;
>
>Why emu and wkup are not taken into account? If wkup is closed
>out here, I think also prm_clkdm and cm_clkdm should be.
>
>> +
>> +seq_printf(s, "%s->%s (%d)", clkdm->name,
>> +clkdm->pwrdm.ptr->name,
>> +atomic_read(&clkdm->usecount));
>> +seq_printf(s, "\n");
>> +
>> +return 0;
>> +}
>> +
>> +static int pwrdm_dbg_show_counter(struct powerdomain *pwrdm, void
>> +*user) {
>> +struct seq_file *s = (struct seq_file *)user;
>> +int i;
>> +
>> +if (strcmp(pwrdm->name, "emu_pwrdm") == 0 ||
>> +strcmp(pwrdm->name, "wkup_pwrdm") == 0)
>> +return 0;
>
>Why emu is closed out here? It has pwstst register.
I closed out emu and wkup powerdomains here because they
did not show any useful information. They are missing either
prepwstst or pwstst register and this debug stuff relies on
accessibility of both of them. If you do not have one, you
get "interesting" results (missing prepwstst => OFF count hits
the roof as the software assumes you are entering off mode
during each sleep period, missing pwstst => you are in OFF state
always.) You could show the current state for emu powerdomain yes,
but not counters.
>I think
>also dpll1..5_pwrdm should be closed out here. I'm not sure
>why those are even modelled in a clocktree.
I tracked the powerdomain code a bit, and it seems dpll1...dpll5
are mapped to some real software accessible powerdomains. E.g. we
have dpll1 -> MPU_MOD. Now, a side effect of this is that when you
access such a powerdomain, you may alter the HW registers of another
powerdomain, which you probably did not want to do. Nasty part of this
is that some code does pwrdm_for_each() calls to modify status of
all powerdomains, like pm34xx.c. Question for Paul: Is the powerdomain
code safe against this kind of stuff?
>
>> +
>> +if (pwrdm->state != pwrdm_read_pwrst(pwrdm))
>> +printk(KERN_ERR "pwrdm state mismatch(%s) %d != %d\n",
>> +pwrdm->name, pwrdm->state,
>pwrdm_read_pwrst(pwrdm));
>> +
>> +seq_printf(s, "%s (%s)", pwrdm->name,
>> +pwrdm_state_names[pwrdm->state]);
>> +for (i = 0; i < 4; i++)
>> +seq_printf(s, ",%s:%d", pwrdm_state_names[i],
>> +pwrdm->state_counter[i]);
>> +
>> +seq_printf(s, "\n");
>> +
>> +return 0;
>> +}
>> +
>> +static int pwrdm_dbg_show_timer(struct powerdomain *pwrdm, void
>> +*user) {
>> +struct seq_file *s = (struct seq_file *)user;
>> +int i;
>> +
>> +if (strcmp(pwrdm->name, "emu_pwrdm") == 0 ||
>> +strcmp(pwrdm->name, "wkup_pwrdm") == 0)
>> +return 0;
>
>Same comment as above.
>
>> +
>> +pwrdm_state_switch(pwrdm);
>> +
>> +seq_printf(s, "%s (%s)", pwrdm->name,
>> +pwrdm_state_names[pwrdm->state]);
>> +
>> +for (i = 0; i < 4; i++)
>> +seq_printf(s, ",%s:%lld", pwrdm_state_names[i],
>> +pwrdm->state_timer[i]);
>> +
>> +seq_printf(s, "\n");
>> +
>> +return 0;
>> +
RE: [PATCH 06/17] OMAP3: PM: Added next state check for IVA2, USB and PER into idle loop
>-Original Message-
>From: ext Sripathy, Vishwanath [mailto:vishwanath...@ti.com]
>Sent: 16 October, 2009 16:16
>To: Kristo Tero (Nokia-D/Tampere); linux-omap@vger.kernel.org
>Subject: RE: [PATCH 06/17] OMAP3: PM: Added next state check
>for IVA2, USB and PER into idle loop
>
>
> >
> >-Original Message-
> >From: linux-omap-ow...@vger.kernel.org
>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tero Kristo
> >Sent: Friday, October 16, 2009 5:49 AM
> >To: linux-omap@vger.kernel.org
> >Subject: [PATCH 06/17] OMAP3: PM: Added next state check for
>IVA2, USB and PER into idle loop
> >
> >From: Tero Kristo
> >
> >This is needed to prevent core from entering off mode if one
>of the IVA2,
> >USB or PER powerdomains are going to stay at least in
>retention state.
> >If this is not done, a powerdomain waking from RET may access core
> >domain which has just been reset.
> >
>From PRCM HW point of view, if any of non core domains do not
>enter OFF mode, then Core cannot enter off mode. So I do not
>understand why you want to do this change.
It appears that at least if IVA2 domain is in retention, core can and will
enter off. The PER domain clock check can be used to prevent unnecessary PER
domain context save/restores also.
>
> >Signed-off-by: Tero Kristo
> >---
> > arch/arm/mach-omap2/pm34xx.c | 36
>+++-
> > 1 files changed, 31 insertions(+), 5 deletions(-)
> >
> >diff --git a/arch/arm/mach-omap2/pm34xx.c
>b/arch/arm/mach-omap2/pm34xx.c
> >index 588ab79..3e5ae14 100644
> >--- a/arch/arm/mach-omap2/pm34xx.c
> >+++ b/arch/arm/mach-omap2/pm34xx.c
> >@@ -85,6 +85,13 @@ u32 voltage_off_while_idle;
> > OMAP3430_ST_DES1_MASK)
> > #define CORE_IDLEST3_ALL(\
> > OMAP3430ES2_ST_USBTLL_MASK|OMAP3430ES2_ST_CPEFUSE_MASK)
> >+#define PER_IDLEST_ALL (\
> >+OMAP3430_ST_WDT3_MASK|OMAP3430_ST_MCBSP4_MASK|\
> >+OMAP3430_ST_MCBSP3_MASK|OMAP3430_ST_MCBSP2_MASK|\
> >+OMAP3430_ST_GPT9_MASK|OMAP3430_ST_GPT8_MASK|\
> >+OMAP3430_ST_GPT7_MASK|OMAP3430_ST_GPT6_MASK|\
> >+OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
> >+OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
> >
> > struct power_state {
> > struct powerdomain *pwrdm;
> >@@ -103,7 +110,7 @@ static int (*_omap_save_secure_sram)(u32 *addr);
> >
> > static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
> > static struct powerdomain *core_pwrdm, *per_pwrdm;
> >-static struct powerdomain *cam_pwrdm, *iva2_pwrdm, *dss_pwrdm;
> >+static struct powerdomain *cam_pwrdm, *iva2_pwrdm,
>*dss_pwrdm, *usb_pwrdm;
> >
> > static struct prm_setup_vc prm_setup = {
> > .clksetup = 0xff,
> >@@ -428,6 +435,8 @@ void omap_sram_idle(void)
> > int per_next_state = PWRDM_POWER_ON;
> > int core_next_state = PWRDM_POWER_ON;
> > int dss_state = PWRDM_POWER_ON;
> >+int iva2_state = PWRDM_POWER_ON;
> >+int usb_state = PWRDM_POWER_ON;
> > int core_prev_state, per_prev_state;
> > u32 sdrc_pwr = 0;
> > int per_state_modified = 0;
> >@@ -463,14 +472,28 @@ void omap_sram_idle(void)
> > if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
> > pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
> >
> >+/* Get powerdomain state data */
> >+core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
> >+dss_state = pwrdm_read_pwrst(dss_pwrdm);
> >+iva2_state = pwrdm_read_pwrst(iva2_pwrdm);
> >+usb_state = pwrdm_read_pwrst(usb_pwrdm);
> >+per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
> >+
> >+/* Check if PER domain can enter OFF or not */
> >+if (per_next_state == PWRDM_POWER_OFF) {
> >+if ((cm_read_mod_reg(OMAP3430_PER_MOD, CM_IDLEST) &
> >+PER_IDLEST_ALL) != PER_IDLEST_ALL) {
> >+per_next_state = PWRDM_POWER_RET;
> >+pwrdm_set_next_pwrst(per_pwrdm, per_next_state);
> >+per_state_modified = 1;
> >+}
> >+}
> > /*
> > * Check whether core will enter idle or not. This is needed
> > * because I/O pad wakeup will fail if core stays on and PER
> > * enters off. This will also prevent unnecessary core context
> > * save / restore.
> > */
> >-core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
> >-dss_state = pwrdm_read_pwrst(dss_pwrdm);
> > if (core_next_state < PWRDM_POWER_ON) {
> > core_saved_state = core_next_state;
> > if ((cm_read_mod_reg(CORE_MOD, CM_IDLEST1) &
>CORE_IDLEST1_ALL)
> >@@ -482,14 +505,16 @@ void omap_sram_idle(void)
> > core_next_state = PWRDM_POWER_ON;
> > pwrdm_set_next_pwrst(core_pwrdm,
>PWRDM_POWER_ON);
> > } else if (core_next_state == PWRDM_POWER_OFF &&
> >- dss_state == PWRDM_POWER_ON) {
> >+ (dss_state == PWRDM_POWER_ON ||
> >+
RE: [PATCH 01/17] PM: fix suspend control for IVA2
>-Original Message-
>From: ext Girish S G [mailto:giris...@ti.com]
>Sent: 16 October, 2009 20:16
>To: Kristo Tero (Nokia-D/Tampere); linux-omap@vger.kernel.org
>Subject: RE: [PATCH 01/17] PM: fix suspend control for IVA2
>
>
>
>> -Original Message-
>> From: linux-omap-ow...@vger.kernel.org
>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tero
>> Kristo
>>
>> From: Tero Kristo
>>
>> IVA2 controls its target power state individually, thus
>suspend should not
>> touch IVA2. Without this patch DSP suspend always fails.
>>
>> Signed-off-by: Tero Kristo
>> Acked-by: Ameya Palande
>> ---
>> arch/arm/mach-omap2/pm34xx.c |9 -
>> 1 files changed, 8 insertions(+), 1 deletions(-)
>>
>> static struct prm_setup_vc prm_setup = {
>> .clksetup = 0xff,
>> @@ -676,6 +676,12 @@ static int omap3_pm_suspend(void)
>> pwrst->saved_state =
>pwrdm_read_next_pwrst(pwrst->pwrdm);
>> /* Set ones wanted by suspend */
>> list_for_each_entry(pwrst, &pwrst_list, node) {
>> +/* Special handling for IVA2, just use current
>sleep state */
>> +if (pwrst->pwrdm == iva2_pwrdm) {
>> +state = pwrdm_read_pwrst(pwrst->pwrdm);
>> +if (state < PWRDM_POWER_ON)
>> +pwrst->next_state = state;
>> +}
>
>Agree, IVA2 pwrdm is handled autonomously by bridge. I think
>this needs some additional change to remove all the redundant
>configuration of iva pwdm. There are some inconsistencies like,
> - Say enable_off_mode is disabled. Before doing system
>wide suspend if DSP hibernates then IVA2 will be put to OFF. In that
>case we have IVA2 going to OFF and other domains in RET. This
>might not be an issue, but it's bad from sytem PM framework integrity
>perspective.
This is an issue with bridge driver, and I am not sure how this should be
fixed. Currently bridge driver does not care whether off mode is enabled or not.
> - enable_off_mode->omap3_pm_off_mode_enable will also
>touch IVA2 power domain next state. This we don't want to do if dsp
>bridge is already taking care of IVA2.
>
>IMO, we need to have some mechanism wherein if bridge PM takes
>care of IVA then PM framework should not configure the IVA
>powerstate. It should only do if bridge PM is disabled.
Should we have a Kconfig option for this? Like CONFIG_OMAP3_BRIDGE_PM, and
disable all iva2 controls from pm34xx.c if it is enabled? Otherwise control
IVA2 as currently done.
-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: [PATCH 03/17] PM: Block CORE off when DSS is active
>-Original Message-
>From: ext Cousson, Benoit [mailto:b-cous...@ti.com]
>Sent: 16 October, 2009 18:27
>To: Kristo Tero (Nokia-D/Tampere); linux-omap@vger.kernel.org
>Cc: Kalle Jokiniemi
>Subject: RE: [PATCH 03/17] PM: Block CORE off when DSS is active
>
>Hi Tero,
>
>>
>Texas Instruments France SA, 821 Avenue Jack Kilby, 06270
>Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920
>
>-Original Message-
>
>>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>>ow...@vger.kernel.org] On Behalf Of Tero Kristo
>>Sent: Friday, October 16, 2009 12:49 PM
>>To: linux-omap@vger.kernel.org
>>Cc: Kalle Jokiniemi
>>Subject: [PATCH 03/17] PM: Block CORE off when DSS is active
>>
>>From: Kalle Jokiniemi
>>
>>If CORE power domain is allowed to reach off state
>>while display is active, the display will go blank.
>>Fixed by adding a check in idle loop.
>
>What is root cause? I guess it is due to extra latency
>required to wakeup from OFF?
>In that case, it should be better to use the
>omap_pm_set_max_dev_wakeup_lat() function and set a latency
>constraint to the CORE.
I believe the root cause is that if core enters off while display is doing
something (between DSS data bursts for example), then when the display next
wakes up and tries to access memories, core has lost its context which is
rather bad. It is not really a wakeup latency issue as such.
>On the other hand, I remember a discussion between Kevin and
>Tomi saying that this API might not be fully functional yet.
>
>Regards,
>Benoit
>
>
>>Signed-off-by: Kalle Jokiniemi
>>Signed-off-by: Jouni Hogander
>>---
>> arch/arm/mach-omap2/pm34xx.c |9 -
>> 1 files changed, 8 insertions(+), 1 deletions(-)
>>
>>diff --git a/arch/arm/mach-omap2/pm34xx.c
>b/arch/arm/mach-omap2/pm34xx.c
>>index e8704a6..52a3f2b 100644
>>--- a/arch/arm/mach-omap2/pm34xx.c
>>+++ b/arch/arm/mach-omap2/pm34xx.c
>>@@ -103,7 +103,7 @@ static int (*_omap_save_secure_sram)(u32 *addr);
>>
>> static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
>> static struct powerdomain *core_pwrdm, *per_pwrdm;
>>-static struct powerdomain *cam_pwrdm, *iva2_pwrdm;
>>+static struct powerdomain *cam_pwrdm, *iva2_pwrdm, *dss_pwrdm;
>>
>> static struct prm_setup_vc prm_setup = {
>> .clksetup = 0xff,
>>@@ -427,6 +427,7 @@ void omap_sram_idle(void)
>> int mpu_next_state = PWRDM_POWER_ON;
>> int per_next_state = PWRDM_POWER_ON;
>> int core_next_state = PWRDM_POWER_ON;
>>+ int dss_state = PWRDM_POWER_ON;
>> int core_prev_state, per_prev_state;
>> u32 sdrc_pwr = 0;
>> int per_state_modified = 0;
>>@@ -469,6 +470,7 @@ void omap_sram_idle(void)
>>* save / restore.
>>*/
>> core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
>>+ dss_state = pwrdm_read_pwrst(dss_pwrdm);
>> if (core_next_state < PWRDM_POWER_ON) {
>> core_saved_state = core_next_state;
>> if ((cm_read_mod_reg(CORE_MOD, CM_IDLEST1) &
>CORE_IDLEST1_ALL)
>>@@ -479,6 +481,10 @@ void omap_sram_idle(void)
>> CORE_IDLEST3_ALL) !=
>CORE_IDLEST3_ALL) {
>> core_next_state = PWRDM_POWER_ON;
>> pwrdm_set_next_pwrst(core_pwrdm,
>PWRDM_POWER_ON);
>>+ } else if (core_next_state == PWRDM_POWER_OFF &&
>>+ dss_state == PWRDM_POWER_ON) {
>>+ core_next_state = PWRDM_POWER_RET;
>>+ pwrdm_set_next_pwrst(core_pwrdm,
>PWRDM_POWER_RET);
>> }
>> }
>>
>>@@ -1234,6 +1240,7 @@ static int __init omap3_pm_init(void)
>> core_pwrdm = pwrdm_lookup("core_pwrdm");
>> cam_pwrdm = pwrdm_lookup("cam_pwrdm");
>> iva2_pwrdm = pwrdm_lookup("iva2_pwrdm");
>>+ dss_pwrdm = pwrdm_lookup("dss_pwrdm");
>>
>> omap_push_sram_idle();
>> #ifdef CONFIG_SUSPEND
>>--
>>1.5.4.3
>>
>>--
>>To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>>the body of a message to majord...@vger.kernel.org
>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller
>-Original Message-
>From: ext Girish S G [mailto:giris...@ti.com]
>Sent: 16 October, 2009 21:10
>To: 'Woodruff, Richard'; Kristo Tero (Nokia-D/Tampere);
>linux-omap@vger.kernel.org
>Cc: Hogander Jouni (Nokia-D/Tampere)
>Subject: RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in
>interrupt controller
>
>
>
>> -Original Message-
>> From: Woodruff, Richard [mailto:r-woodru...@ti.com]
>> Sent: Friday, October 16, 2009 1:04 PM
>> To: Ghongdemath, Girish; 'Tero Kristo'; linux-omap@vger.kernel.org
>> Cc: 'Jouni Hogander'
>> Subject: RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE
>in interrupt controller
>
>
>>
>> There was one report from a custom board when it made a
>difference. I've not tried to double check
>> this data. I don't have the reporters setup so there is no
>guarantee I could reproduce anyway. In
>> general optimization seemed to make sense.
>
>I second it.
>
>
>Regards,
>Girish
>
>
Is there errata number available for this issue by the way? I could attach this
to the patch.
Anyway, I guess the optimization would look something like this:
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 210a806..7a98321 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -93,6 +93,8 @@ u32 voltage_off_while_idle;
OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
+#define INTC_SYSCONFIG 0x10
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -505,6 +507,12 @@ void omap_sram_idle(void)
prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
omap3_enable_io_chain();
}
+ /*
+* Disable INTC autoidle as it can cause interrupt controller
+* to enter unknown state with right combination of sleep / wakeup
+* transitions
+*/
+ omap_writel(0x0, OMAP34XX_IC_BASE + INTC_SYSCONFIG);
/*
* On EMU/HS devices ROM code restores a SRDC value
@@ -561,6 +569,8 @@ void omap_sram_idle(void)
OMAP3430_GR_MOD,
OMAP3_PRM_VOLTCTRL_OFFSET);
}
+ /* Re-enable interrupt controller autoidle */
+ omap_writel(OMAP3430_AUTOIDLE, OMAP34XX_IC_BASE + INTC_SYSCONFIG);
/*
* Enable smartreflex after WFI. Only needed if we
--
1.5.4.3--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 20 October, 2009 19:02
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: giris...@ti.com; r-woodru...@ti.com;
>linux-omap@vger.kernel.org; Hogander Jouni (Nokia-D/Tampere)
>Subject: Re: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in
>interrupt controller
>
> writes:
>
There was one report from a custom board when it made a
>>>difference. I've not tried to double check
this data. I don't have the reporters setup so there is no
>>>guarantee I could reproduce anyway. In
general optimization seemed to make sense.
>>>
>>>I second it.
>>>
>>>
>>>Regards,
>>>Girish
>>>
>>>
>>
>> Is there errata number available for this issue by the way?
>I could attach this to the patch.
>>
>> Anyway, I guess the optimization would look something like this:
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c
>b/arch/arm/mach-omap2/pm34xx.c
>> index 210a806..7a98321 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -93,6 +93,8 @@ u32 voltage_off_while_idle;
>> OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
>> OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
>>
>> +#define INTC_SYSCONFIG 0x10
>> +
>> struct power_state {
>> struct powerdomain *pwrdm;
>> u32 next_state;
>> @@ -505,6 +507,12 @@ void omap_sram_idle(void)
>> prm_set_mod_reg_bits(OMAP3430_EN_IO,
>WKUP_MOD, PM_WKEN);
>> omap3_enable_io_chain();
>> }
>> + /*
>> +* Disable INTC autoidle as it can cause interrupt controller
>> +* to enter unknown state with right combination of
>sleep / wakeup
>> +* transitions
>> +*/
>> + omap_writel(0x0, OMAP34XX_IC_BASE + INTC_SYSCONFIG);
>
>Except omap_write* functions are deprecated.
I see, will use __raw_writel here then.
>
>I'd rather see a call into the interrupt code. Something like
>omap_intc_prepare_idle()
Can do these changes to add the interface yes. Though name would be
omap3_intc_prepare_idle() / ...resume_idle() as this is only needed for OMAP3.
>
>Also, isn't this only needed if CORE != ON?
I understood from the problem description that this is needed always when we
are entering WFI, because we might have L3/L4 sleep/run transitions there even
if CORE is on.
>
>> /*
>> * On EMU/HS devices ROM code restores a SRDC value
>> @@ -561,6 +569,8 @@ void omap_sram_idle(void)
>> OMAP3430_GR_MOD,
>>
>OMAP3_PRM_VOLTCTRL_OFFSET);
>> }
>> + /* Re-enable interrupt controller autoidle */
>> + omap_writel(OMAP3430_AUTOIDLE, OMAP34XX_IC_BASE +
>INTC_SYSCONFIG);
>
>and omap_intc_resume_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
RE: [PATCH 16/17] OMAP3: PM: Write voltage and clock setup times dynamically in idle loop
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 20 October, 2009 20:48
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 16/17] OMAP3: PM: Write voltage and clock
>setup times dynamically in idle loop
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> It is suggested by TI (SWPA152 February 2009) to write clksetup,
>> voltsetup_time1, voltsetup_time2, voltsetup2 dynamically in
>idle loop.
>
>Can you summarize the reasons why?
Basically this optimizes the clksetup / voltsetup times according to the sleep
mode. Currently the settings are too high in both retention and off-mode,
because the hardware appears to use for example VOLTSETUP2 even if we are not
in off-mode, adding extra delay to wakeup. Also, CLKSETUP is too high for
retention mode because oscillator is not actually shut-off here.
However, now that I think about it, it might be better to change this in a way
that it is user configurable whether we want to change the settings or not,
maybe add new items in to the prm_setup struct for alternate settings for ret /
off and only use these if available. Some boards might actually switch
oscillator off in retention mode which would require higher setup time.
>
>> Signed-off-by: Jouni Hogander
>> ---
>> arch/arm/mach-omap2/pm34xx.c | 36
>+---
>> 1 files changed, 25 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c
>b/arch/arm/mach-omap2/pm34xx.c
>> index f492142..ae83121 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -575,6 +575,30 @@ void omap_sram_idle(void)
>> if (regset_save_on_suspend)
>> pm_dbg_regset_save(1);
>>
>> +/* Write voltage setup times which are changed dynamically */
>
>AFAICT, we only set these values at init time and they are never
>changed. Are there some forthcoming patches that change these
>dynamically?
Following bit of the code actually changes them dynamically, you can see that
e.g. CLKSETUP time is either prm_setup.clksetup or 0x1 depending on the sleep
mode. But as previously said, I think these should probably be added as new
items to the prm_setup struct.
>
>Kevin
>
>> +if (core_next_state == PWRDM_POWER_OFF) {
>> +prm_write_mod_reg(0, OMAP3430_GR_MOD,
>> +OMAP3_PRM_VOLTSETUP1_OFFSET);
>> +prm_write_mod_reg(prm_setup.voltsetup2, OMAP3430_GR_MOD,
>> +OMAP3_PRM_VOLTSETUP2_OFFSET);
>> +prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
>> +OMAP3_PRM_CLKSETUP_OFFSET);
>> +} else {
>> +prm_write_mod_reg((prm_setup.voltsetup_time2 <<
>> +OMAP3430_SETUP_TIME2_SHIFT) |
>> +(prm_setup.voltsetup_time1 <<
>> +OMAP3430_SETUP_TIME1_SHIFT),
>> +OMAP3430_GR_MOD,
>OMAP3_PRM_VOLTSETUP1_OFFSET);
>> +prm_write_mod_reg(0, OMAP3430_GR_MOD,
>> +OMAP3_PRM_VOLTSETUP2_OFFSET);
>> +/*
>> + * Use static 1 as only HF_CLKOUT is turned off.
>> + * Value taken from application note SWPA152
>> + */
>> +prm_write_mod_reg(0x1, OMAP3430_GR_MOD,
>> +OMAP3_PRM_CLKSETUP_OFFSET);
>> +}
>> +
>> /*
>> * omap3_arm_context is the location where ARM registers
>> * get saved. The restore path then reads from this
>> @@ -1379,19 +1403,9 @@ static void __init configure_vc(void)
>>OMAP3430_GR_MOD,
>>OMAP3_PRM_VC_I2C_CFG_OFFSET);
>>
>> -/* Write setup times */
>> -prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
>> -OMAP3_PRM_CLKSETUP_OFFSET);
>> -prm_write_mod_reg((prm_setup.voltsetup_time2 <<
>> -OMAP3430_SETUP_TIME2_SHIFT) |
>> -(prm_setup.voltsetup_time1 <<
>> -OMAP3430_SETUP_TIME1_SHIFT),
>> -OMAP3430_GR_MOD, OMAP3_PRM_VOLTSETUP1_OFFSET);
>> -
>> +/* Write static setup times */
>> prm_write_mod_reg(prm_setup.voltoffset, OMAP3430_GR_MOD,
>> OMAP3_PRM_VOLTOFFSET_OFFSET);
>> -prm_write_mod_reg(prm_setup.voltsetup2, OMAP3430_GR_MOD,
>> -OMAP3_PRM_VOLTSETUP2_OFFSET);
>>
>> pm_dbg_regset_init(1);
>> pm_dbg_regset_init(2);
>> --
>> 1.5.4.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 09/17] OMAP3: PM: Ack pending interrupts before entering suspend
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org
>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Kevin Hilman
>Sent: 20 October, 2009 20:31
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 09/17] OMAP3: PM: Ack pending interrupts
>before entering suspend
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> Suspending drivers may still generate interrupts just before
>their suspend is
>> completed. Any pending interrupts here will prevent sleep.
>>
>> Signed-off-by: Tero Kristo
>
>This could also be done in omap3_intc_prepare_idle() hook.
I thought it is better to do this in suspend path only, because in normal sleep
case we most likely don't want to miss any interrupts. In suspend case, we
usually want to enter the suspend no matter what, and this is used here only to
clean up the mess left by some of the drivers. The GPT case is one of the main
things we try to fix here.
-Tero
>
>> ---
>> arch/arm/mach-omap2/irq.c |2 +-
>> arch/arm/mach-omap2/pm34xx.c |2 ++
>> arch/arm/plat-omap/include/mach/irqs.h |1 +
>> 3 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
>> index aceedd8..4ed05e9 100644
>> --- a/arch/arm/mach-omap2/irq.c
>> +++ b/arch/arm/mach-omap2/irq.c
>> @@ -101,7 +101,7 @@ static int omap_check_spurious(unsigned int irq)
>> }
>>
>> /* XXX: FIQ and additional INTC support (only MPU at the moment) */
>> -static void omap_ack_irq(unsigned int irq)
>> +void omap_ack_irq(unsigned int irq)
>> {
>> intc_bank_write_reg(0x1, &irq_banks[0], INTC_CONTROL);
>> }
>> diff --git a/arch/arm/mach-omap2/pm34xx.c
>b/arch/arm/mach-omap2/pm34xx.c
>> index 5854fa7..6a41811 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -778,6 +778,8 @@ static int omap3_pm_suspend(void)
>>
>> omap_uart_prepare_suspend();
>>
>> +/* Ack pending IRQs, as a pending IRQ will cause the
>suspend to fail */
>> +omap_ack_irq(0);
>> regset_save_on_suspend = 1;
>> omap_sram_idle();
>> regset_save_on_suspend = 0;
>> diff --git a/arch/arm/plat-omap/include/mach/irqs.h
>b/arch/arm/plat-omap/include/mach/irqs.h
>> index 2473910..d56be1c 100644
>> --- a/arch/arm/plat-omap/include/mach/irqs.h
>> +++ b/arch/arm/plat-omap/include/mach/irqs.h
>> @@ -483,6 +483,7 @@
>> #ifndef __ASSEMBLY__
>> extern void omap_init_irq(void);
>> extern int omap_irq_pending(void);
>> +extern void omap_ack_irq(unsigned int irq);
>> void omap3_intc_save_context(void);
>> void omap3_intc_restore_context(void);
>> #endif
>> --
>> 1.5.4.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
>To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
To unsubscribe from this list: send the line "unsubscribe 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 08/17] OMAP2/3: GPTIMER: Clear pending interrupts when entering suspend
>-Original Message- >From: linux-omap-ow...@vger.kernel.org >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Kevin Hilman >Sent: 20 October, 2009 20:37 >To: Kristo Tero (Nokia-D/Tampere) >Cc: linux-omap@vger.kernel.org >Subject: Re: [PATCH 08/17] OMAP2/3: GPTIMER: Clear pending >interrupts when entering suspend > >Tero Kristo writes: > >> From: Tero Kristo >> >> OMAP GP timers keep running for a few cycles after they are stopped, >> which can cause the timer to expire and generate an >interrupt. The pending >> interrupt will prevent OMAP from entering suspend, thus we >ack it manually. >> >> Signed-off-by: Tero Kristo >> >> --- >> arch/arm/mach-omap2/timer-gp.c | 14 +- >> 1 files changed, 13 insertions(+), 1 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/timer-gp.c >b/arch/arm/mach-omap2/timer-gp.c >> index 9c056ff..c9d47bb 100644 >> --- a/arch/arm/mach-omap2/timer-gp.c >> +++ b/arch/arm/mach-omap2/timer-gp.c >> @@ -92,9 +92,21 @@ static void omap2_gp_timer_set_mode(enum >clock_event_mode mode, >> case CLOCK_EVT_MODE_ONESHOT: >> break; >> case CLOCK_EVT_MODE_UNUSED: >> -case CLOCK_EVT_MODE_SHUTDOWN: >> case CLOCK_EVT_MODE_RESUME: >> break; >> +case CLOCK_EVT_MODE_SHUTDOWN: >> +/* >> + * Wait for min period x 2 to make sure that timer is >> + * stopped >> + */ >> +udelay(evt->min_delta_ns / 500); >> +/* >> + * Clear possibly pending interrupt, this will >occasionally >> + * generate spurious timer IRQs during suspend but this >> + * is okay, as another option is not to enter >suspend at all >> + */ >> +omap_dm_timer_write_status(gptimer, >OMAP_TIMER_INT_OVERFLOW); >> +break; > >Seems to me that this fix should just be done in omap_dm_timer_stop() >since it could also result in extra interrupts in when using oneshot >mode under dyntick. Hmm yea, I can attempt to move this in there. > >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 >-- To unsubscribe from this list: send the line "unsubscribe 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 17/17] OMAP3: PM: Force disable OTG autoidle
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 20 October, 2009 21:44
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 17/17] OMAP3: PM: Force disable OTG autoidle
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> OMAP3 sleep can be prevented in some cases where OTG
>autoidle is enabled.
>> This patch force disables autoidle during boot and after
>wakeup from off-mode.
>> See omap erratas 1.164 and 1.165.
>
>The init-at-boot step isn't needed as this is already done in
>PM branch (see usb-muxb.c:usb_musb_pm_init()).
True, that reset part actually does this, which is also part of the errata.
>
>> Signed-off-by: Tero Kristo
>> ---
>> arch/arm/mach-omap2/pm34xx.c | 14 ++
>> 1 files changed, 14 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c
>b/arch/arm/mach-omap2/pm34xx.c
>> index ae83121..5f351f2 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -94,6 +94,8 @@ u32 voltage_off_while_idle;
>> OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
>> OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
>>
>> +#define OTG_SYSCONFIG (OMAP34XX_HSUSB_OTG_BASE + 0x404)
>> +
>> struct power_state {
>> struct powerdomain *pwrdm;
>> u32 next_state;
>> @@ -423,6 +425,16 @@ static void restore_table_entry(void)
>> restore_control_register(control_reg_value);
>> }
>>
>> +static inline void disable_otg_autoidle(void)
>> +{
>> +/*
>> + * OTG autoidle can prevent core domain sleep in some
>cases, thus
>> + * disable it. See omap erratas 1.164 and 1.165.
>> + */
>> +cm_set_mod_reg_bits(OMAP3430_EN_HSOTGUSB, CORE_MOD, CM_ICLKEN1);
>
>Is the ICLK enable required as part of the fix too? I don't see
>mention of enabling the iclk as part of the workaround for either of
>these errata.
>
>If the iclk needs to be enabled, it should be done at init using
>the clk API.
ICLK enable part is here because we will crash unless ICLK is active. It does
not really need to be on, but it was rather simpler to do it this way. I can
try to look if adding this into USB code would make sense.
>
>> +omap_writel(0x0, OTG_SYSCONFIG);
>
>omap_writel() deprecated.
Again...
>
>> +}
>> +
>
>For readability, this should be a function in the USB core code
>(either usb-musb.c or a static inline in )
>
>Kevin
>
>> void omap_sram_idle(void)
>> {
>> /* Variable to tell what needs to be saved and restored
>> @@ -628,6 +640,7 @@ void omap_sram_idle(void)
>> omap3_prcm_restore_context();
>> omap3_sram_restore_context();
>> omap2_sms_restore_context();
>> +disable_otg_autoidle();
>> }
>> omap_uart_resume_idle(0);
>> omap_uart_resume_idle(1);
>> @@ -1417,6 +1430,7 @@ static int __init omap3_pm_early_init(void)
>> OMAP3_PRM_POLCTRL_OFFSET);
>>
>> configure_vc();
>> +disable_otg_autoidle();
>>
>> return 0;
>> }
>> --
>> 1.5.4.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 16/17] OMAP3: PM: Write voltage and clock setup times dynamically in idle loop
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 21 October, 2009 17:15
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 16/17] OMAP3: PM: Write voltage and clock
>setup times dynamically in idle loop
>
> writes:
>
>>
>>
>>>-Original Message-
>>>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>>>Sent: 20 October, 2009 20:48
>>>To: Kristo Tero (Nokia-D/Tampere)
>>>Cc: linux-omap@vger.kernel.org
>>>Subject: Re: [PATCH 16/17] OMAP3: PM: Write voltage and clock
>>>setup times dynamically in idle loop
>>>
>>>Tero Kristo writes:
>>>
From: Tero Kristo
It is suggested by TI (SWPA152 February 2009) to write clksetup,
voltsetup_time1, voltsetup_time2, voltsetup2 dynamically in
>>>idle loop.
>>>
>>>Can you summarize the reasons why?
>>
>> Basically this optimizes the clksetup / voltsetup times
>according to the sleep mode. Currently the settings are too
>high in both retention and off-mode, because the hardware
>appears to use for example VOLTSETUP2 even if we are not in
>off-mode, adding extra delay to wakeup. Also, CLKSETUP is too
>high for retention mode because oscillator is not actually
>shut-off here.
>>
>> However, now that I think about it, it might be better to
>change this in a way that it is user configurable whether we
>want to change the settings or not, maybe add new items in to
>the prm_setup struct for alternate settings for ret / off and
>only use these if available. Some boards might actually switch
>oscillator off in retention mode which would require higher setup time.
>>
>>>
Signed-off-by: Jouni Hogander
---
arch/arm/mach-omap2/pm34xx.c | 36
>>>+---
1 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
>>>b/arch/arm/mach-omap2/pm34xx.c
index f492142..ae83121 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -575,6 +575,30 @@ void omap_sram_idle(void)
if (regset_save_on_suspend)
pm_dbg_regset_save(1);
+ /* Write voltage setup times which are changed dynamically */
>>>
>>>AFAICT, we only set these values at init time and they are never
>>>changed. Are there some forthcoming patches that change these
>>>dynamically?
>>
>> Following bit of the code actually changes them dynamically, you can
>> see that e.g. CLKSETUP time is either prm_setup.clksetup or 0x1
>> depending on the sleep mode.
>
>Doh, I see now.
>
>> But as previously said, I think these should probably be added as
>> new items to the prm_setup struct.
>
>Yes, I would rather see the prm_setup struct extended so these can be
>passed in by board code.
I'll change the patch accordingly.
>>>
>>>Kevin
>>>
+ if (core_next_state == PWRDM_POWER_OFF) {
+ prm_write_mod_reg(0, OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTSETUP1_OFFSET);
+ prm_write_mod_reg(prm_setup.voltsetup2, OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTSETUP2_OFFSET);
+ prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
+ OMAP3_PRM_CLKSETUP_OFFSET);
+ } else {
+ prm_write_mod_reg((prm_setup.voltsetup_time2 <<
+ OMAP3430_SETUP_TIME2_SHIFT) |
+ (prm_setup.voltsetup_time1 <<
+ OMAP3430_SETUP_TIME1_SHIFT),
+ OMAP3430_GR_MOD,
>>>OMAP3_PRM_VOLTSETUP1_OFFSET);
+ prm_write_mod_reg(0, OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTSETUP2_OFFSET);
+ /*
+ * Use static 1 as only HF_CLKOUT is turned off.
+ * Value taken from application note SWPA152
+ */
+ prm_write_mod_reg(0x1, OMAP3430_GR_MOD,
+ OMAP3_PRM_CLKSETUP_OFFSET);
+ }
+
/*
* omap3_arm_context is the location where ARM registers
* get saved. The restore path then reads from this
@@ -1379,19 +1403,9 @@ static void __init configure_vc(void)
OMAP3430_GR_MOD,
OMAP3_PRM_VC_I2C_CFG_OFFSET);
- /* Write setup times */
- prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
- OMAP3_PRM_CLKSETUP_OFFSET);
- prm_write_mod_reg((prm_setup.voltsetup_time2 <<
- OMAP3430_SETUP_TIME2_SHIFT) |
- (prm_setup.voltsetup_time1 <<
- OMAP3430_SETUP_TIME1_SHIFT),
- OMAP3430_GR_MOD, OMAP3_PRM_VOLTSETUP1_OFFSET);
-
+ /* Write static setup times */
prm_write_mod_reg(prm_setup.voltoffset, OMAP3430_GR_MOD,
OMAP3_PRM_VOLTOFFSET_OFFSET);
- prm_write_mod_reg(prm_setup
RE: [PATCH 09/17] OMAP3: PM: Ack pending interrupts before entering suspend
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 21 October, 2009 17:20
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 09/17] OMAP3: PM: Ack pending interrupts
>before entering suspend
>
> writes:
>
>>>-Original Message-
>>>From: linux-omap-ow...@vger.kernel.org
>>>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext
>Kevin Hilman
>>>Sent: 20 October, 2009 20:31
>>>To: Kristo Tero (Nokia-D/Tampere)
>>>Cc: linux-omap@vger.kernel.org
>>>Subject: Re: [PATCH 09/17] OMAP3: PM: Ack pending interrupts
>>>before entering suspend
>>>
>>>Tero Kristo writes:
>>>
From: Tero Kristo
Suspending drivers may still generate interrupts just before
>>>their suspend is
completed. Any pending interrupts here will prevent sleep.
Signed-off-by: Tero Kristo
>>>
>>>This could also be done in omap3_intc_prepare_idle() hook.
>>
>> I thought it is better to do this in suspend path only, because in
>> normal sleep case we most likely don't want to miss any
>> interrupts.
>
>Agreed, then I'd suggest doing this in omap3_intc_[suspend|resume]()
>hooks.
>
>> In suspend case, we usually want to enter the suspend no
>> matter what, and this is used here only to clean up the mess left by
>> some of the drivers. The GPT case is one of the main things we try
>> to fix here.
>
>So is this still needed with the GPTIMER fix in PATCH 8/17?
Yeah, it is not enough to ack the interrupt at module level, we still have the
pending IRQ in the interrupt controller itself.
>
>If there are other drivers having delayed interrupt triggering, it
>sounds like the drivers need to be fixed instead of this brute force
>approach.
I think any system device can have similar issue if they receive an interrupt
while we are entering suspend. The main problem is the sequence executed during
suspend: interrupts are disabled before we suspend the system devices (e.g.
clock source) and it is very possible for the devices to receive interrupts
during this window. GPT is a special case because it also has internal
buffering for the register writes, so it continues to tick a while after it is
stopped. GPT is also special in a sense that it can trigger an interrupt at
arbitrary points of time.
I don't know if similar issue exists on other platforms so changing the suspend
sequence itself is probably not an option. And.. acking all interrupts at every
suspending device is probably neither.
-Tero
>
>>
>>>
---
arch/arm/mach-omap2/irq.c |2 +-
arch/arm/mach-omap2/pm34xx.c |2 ++
arch/arm/plat-omap/include/mach/irqs.h |1 +
3 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index aceedd8..4ed05e9 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -101,7 +101,7 @@ static int
>omap_check_spurious(unsigned int irq)
}
/* XXX: FIQ and additional INTC support (only MPU at the
>moment) */
-static void omap_ack_irq(unsigned int irq)
+void omap_ack_irq(unsigned int irq)
{
intc_bank_write_reg(0x1, &irq_banks[0], INTC_CONTROL);
}
diff --git a/arch/arm/mach-omap2/pm34xx.c
>>>b/arch/arm/mach-omap2/pm34xx.c
index 5854fa7..6a41811 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -778,6 +778,8 @@ static int omap3_pm_suspend(void)
omap_uart_prepare_suspend();
+ /* Ack pending IRQs, as a pending IRQ will cause the
>>>suspend to fail */
+ omap_ack_irq(0);
regset_save_on_suspend = 1;
omap_sram_idle();
regset_save_on_suspend = 0;
diff --git a/arch/arm/plat-omap/include/mach/irqs.h
>>>b/arch/arm/plat-omap/include/mach/irqs.h
index 2473910..d56be1c 100644
--- a/arch/arm/plat-omap/include/mach/irqs.h
+++ b/arch/arm/plat-omap/include/mach/irqs.h
@@ -483,6 +483,7 @@
#ifndef __ASSEMBLY__
extern void omap_init_irq(void);
extern int omap_irq_pending(void);
+extern void omap_ack_irq(unsigned int irq);
void omap3_intc_save_context(void);
void omap3_intc_restore_context(void);
#endif
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe
>>>linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>--
>>>To unsubscribe from this list: send the line "unsubscribe
>>>linux-omap" in
>>>the body of a message to majord...@vger.kernel.org
>>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/4] RX51: SDRAM settings changes
>-Original Message- >From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: 26 October, 2009 20:50 >To: Kristo Tero (Nokia-D/Tampere) >Cc: linux-omap@vger.kernel.org >Subject: Re: [PATCH 0/4] RX51: SDRAM settings changes > >Tero Kristo writes: > >> From: Tero Kristo >> >> Following patch set fixes a few issues with current RX51 >board SDRAM settings. >> Applies on top of PM branch. >> > >Tero, > >Can you resend this series against the master branch? There >is no reason >this should be carried in the PM branch anymore. > >You'll have to add to your series the patch to add the >board-rx51-sdram.c file, which I currently carry in the PM branch. > >Then, for the PM branch, we just need a small patch to add the various >rate tables in the call to init_common_hw until DVFS stuff is >upstream. Ok, I have now done this. I also combined the series into one patch as it will generate a new file and I don't see any need to clutter git-log with several patches to currently non-existent file. Sending out now. -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: [PATCH 07/11] OMAP3: Fixed ARM aux ctrl register save/restore
>-Original Message-
>From: ext Gopinath, Thara [mailto:th...@ti.com]
>Sent: 28 October, 2009 11:32
>To: Kristo Tero (Nokia-D/Tampere); linux-omap@vger.kernel.org
>Subject: RE: [PATCH 07/11] OMAP3: Fixed ARM aux ctrl register
>save/restore
>
>
>
>>>-Original Message-
>>>From: linux-omap-ow...@vger.kernel.org
>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tero
>>>Kristo
>>>Sent: Friday, October 23, 2009 9:34 PM
>>>To: linux-omap@vger.kernel.org
>>>Subject: [PATCH 07/11] OMAP3: Fixed ARM aux ctrl register
>save/restore
>>>
>>>From: Tero Kristo
>>>
>>>Current value is stored on SDRAM and it is written back
>during wakeup.
>>>Previously a static value of 0x72 was written there.
>>>
>>>Signed-off-by: Tero Kristo
>>>Signed-off-by: Jouni Hogander
>>>---
>>> arch/arm/mach-omap2/control.c |1 +
>>> arch/arm/mach-omap2/sleep34xx.S | 23 ---
>>> 2 files changed, 21 insertions(+), 3 deletions(-)
>>>
>>>diff --git a/arch/arm/mach-omap2/control.c
>b/arch/arm/mach-omap2/control.c
>>>index 296f2c2..730fc53 100644
>>>--- a/arch/arm/mach-omap2/control.c
>>>+++ b/arch/arm/mach-omap2/control.c
>>>@@ -94,6 +94,7 @@ void *omap3_secure_ram_storage;
>>> * during the restore path.
>>> */
>>> u32 omap3_arm_context[128];
>>>+u32 omap3_aux_ctrl[2] = { 0x1, 0x0 };
>>>
>>> struct omap3_control_regs {
>>> u32 sysconfig;
>>>diff --git a/arch/arm/mach-omap2/sleep34xx.S
>b/arch/arm/mach-omap2/sleep34xx.S
>>>index f4f5ebe..0b03bf9 100644
>>>--- a/arch/arm/mach-omap2/sleep34xx.S
>>>+++ b/arch/arm/mach-omap2/sleep34xx.S
>>>@@ -26,6 +26,7 @@
>>> */
>>> #include
>>> #include
>>>+#include
>>> #include
>>> #include
>>>
>>>@@ -278,7 +279,11 @@ restore:
>>> mov r1, #0 @ set task id for ROM code in r1
>>> mov r2, #4 @ set some flags in r2, r6
>>> mov r6, #0xff
>>>-adr r3, write_aux_control_params@ r3 points to
>parameters
>>>+ldr r3, write_aux_control_params@ r3 points to
>parameters
>>>+ldr r4, phys_offset
>>>+addsr3, r3, r4
>>>+ldr r4, page_offset
>>>+subsr3, r3, r4
>>> mcr p15, 0, r0, c7, c10, 4 @ data write barrier
>>> mcr p15, 0, r0, c7, c10, 5 @ data memory barrier
>>> .word 0xE1600071 @ call SMI monitor (smi #1)
>>>@@ -287,13 +292,18 @@ restore:
>>> l2_inv_api_params:
>>> .word 0x1, 0x00
>>> write_aux_control_params:
>>>-.word 0x1, 0x72
>>>+.word omap3_aux_ctrl
>>> l2_inv_gp:
>>> /* Execute smi to invalidate L2 cache */
>>> mov r12, #0x1 @ set up to invalide L2
>>> smi:.word 0xE1600070@ Call SMI monitor (smieq)
>>> /* Write to Aux control register to set some bits */
>>>-mov r0, #0x72
>>>+ldr r1, write_aux_control_params
>>>+ldr r0, phys_offset
>>>+addsr1, r1, r0
>>>+ldr r0, page_offset
>>>+subsr1, r1, r0
>>>+ldr r0, [r1, #4]
>>> mov r12, #0x3
>>> .word 0xE1600070@ Call SMI monitor (smieq)
>>> logic_l1_restore:
>>>@@ -420,6 +430,9 @@ usettbr0:
>>> save_context_wfi:
>>> /*b save_context_wfi*/ @ enable to debug save code
>>> mov r8, r0 /* Store SDRAM address in r8 */
>>>+mrc p15, 0, r4, c1, c0, 1 @ Read Auxiliary
>Control Register
>>>+ldr r5, write_aux_control_params
>>>+str r4, [r5, #4]
>
>There is a simpler way of doing this. Store the aux control
>value at the top of the sdram array where other parameters are
>stored. It would be something like following
> mrc p15, 0, r4, c1, c0, 1
> str r4, [r8]
> add r8, r8, #4
>In the restore, you can read it from this location and pass it
>as parameter for smi for gp device or pass this location as a
>parameter for emu device. In this way no need to define
>page_offset and phys_offset. I have a patch done for this for
>an internal code base. I can share it with you if interested.
>Else I can post it after rebasing. Do let me know.
I can modify my patch according to this. However, do you know how much of the
sdram array is currently used? The size is 128 32bit words but I would not like
to calculate manually how much of that is used and whether I need to increase
its size or not.
>
>>> /* Check what that target sleep state is:stored in r1*/
>>> /* 1 - Only L1 and logic lost */
>>> /* 2 - Only L2 lost */
>>>@@ -605,6 +618,10 @@ wait_dll_lock:
>>> bne wait_dll_lock
>>> bx lr
>>>
>>>+phys_offset:
>>>+.word PHYS_OFFSET
>>>+page_offset:
>>>+.word PAGE_OFFSET
>>> cm_idlest1_core:
>>> .word CM_IDLEST1_CORE_V
>>> sdrc_dlla_status:
>>>--
>>>1.5.4.3
>>>
>>>--
>>>To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>>>the body of a message to majord...@vger.kernel.org
>>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>--
To unsubscribe from this l
RE: [PATCH 07/11] OMAP3: Fixed ARM aux ctrl register save/restore
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org
>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Kevin Hilman
>Sent: 12 November, 2009 01:27
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 07/11] OMAP3: Fixed ARM aux ctrl register
>save/restore
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> Current value is stored on SDRAM and it is written back
>during wakeup.
>> Previously a static value of 0x72 was written there.
>>
>> Signed-off-by: Tero Kristo
>> Signed-off-by: Jouni Hogander
>
>Thanks, applying to PM branch, queuing for pm-fixes.
I have a slightly modified version available of this now, which stores the data
inside arm_context. It is probably a bit nicer than this one. I'll send out the
refreshed version of this patch and you can see which one you want to use.
>
>Kevin
>
>> ---
>> arch/arm/mach-omap2/control.c |1 +
>> arch/arm/mach-omap2/sleep34xx.S | 23 ---
>> 2 files changed, 21 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/control.c
>b/arch/arm/mach-omap2/control.c
>> index 296f2c2..730fc53 100644
>> --- a/arch/arm/mach-omap2/control.c
>> +++ b/arch/arm/mach-omap2/control.c
>> @@ -94,6 +94,7 @@ void *omap3_secure_ram_storage;
>> * during the restore path.
>> */
>> u32 omap3_arm_context[128];
>> +u32 omap3_aux_ctrl[2] = { 0x1, 0x0 };
>>
>> struct omap3_control_regs {
>> u32 sysconfig;
>> diff --git a/arch/arm/mach-omap2/sleep34xx.S
>b/arch/arm/mach-omap2/sleep34xx.S
>> index f4f5ebe..0b03bf9 100644
>> --- a/arch/arm/mach-omap2/sleep34xx.S
>> +++ b/arch/arm/mach-omap2/sleep34xx.S
>> @@ -26,6 +26,7 @@
>> */
>> #include
>> #include
>> +#include
>> #include
>> #include
>>
>> @@ -278,7 +279,11 @@ restore:
>> mov r1, #0 @ set task id for ROM code in r1
>> mov r2, #4 @ set some flags in r2, r6
>> mov r6, #0xff
>> -adr r3, write_aux_control_params@ r3 points to
>parameters
>> +ldr r3, write_aux_control_params@ r3 points to
>parameters
>> +ldr r4, phys_offset
>> +addsr3, r3, r4
>> +ldr r4, page_offset
>> +subsr3, r3, r4
>> mcr p15, 0, r0, c7, c10, 4 @ data write barrier
>> mcr p15, 0, r0, c7, c10, 5 @ data memory barrier
>> .word 0xE1600071 @ call SMI monitor (smi #1)
>> @@ -287,13 +292,18 @@ restore:
>> l2_inv_api_params:
>> .word 0x1, 0x00
>> write_aux_control_params:
>> -.word 0x1, 0x72
>> +.word omap3_aux_ctrl
>> l2_inv_gp:
>> /* Execute smi to invalidate L2 cache */
>> mov r12, #0x1 @ set up to invalide L2
>> smi:.word 0xE1600070@ Call SMI monitor (smieq)
>> /* Write to Aux control register to set some bits */
>> -mov r0, #0x72
>> +ldr r1, write_aux_control_params
>> +ldr r0, phys_offset
>> +addsr1, r1, r0
>> +ldr r0, page_offset
>> +subsr1, r1, r0
>> +ldr r0, [r1, #4]
>> mov r12, #0x3
>> .word 0xE1600070@ Call SMI monitor (smieq)
>> logic_l1_restore:
>> @@ -420,6 +430,9 @@ usettbr0:
>> save_context_wfi:
>> /*b save_context_wfi*/ @ enable to debug save code
>> mov r8, r0 /* Store SDRAM address in r8 */
>> +mrc p15, 0, r4, c1, c0, 1 @ Read Auxiliary
>Control Register
>> +ldr r5, write_aux_control_params
>> +str r4, [r5, #4]
>> /* Check what that target sleep state is:stored in r1*/
>> /* 1 - Only L1 and logic lost */
>> /* 2 - Only L2 lost */
>> @@ -605,6 +618,10 @@ wait_dll_lock:
>> bne wait_dll_lock
>> bx lr
>>
>> +phys_offset:
>> +.word PHYS_OFFSET
>> +page_offset:
>> +.word PAGE_OFFSET
>> cm_idlest1_core:
>> .word CM_IDLEST1_CORE_V
>> sdrc_dlla_status:
>> --
>> 1.5.4.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
>To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 09/11] OMAP3: PM: Added support for L2 aux ctrl register save and restore
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 12 November, 2009 01:45
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 09/11] OMAP3: PM: Added support for L2 aux
>ctrl register save and restore
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> This patch adds a save and restore mechanism for ARM L2
>auxiliary control
>> register. This feature is enabled via Kconfig option
>> OMAP3_L2_AUX_SECURE_SAVE_RESTORE and the service ID for PPA
>can be provided
>> via option OMAP3_L2_AUX_SECURE_SERVICE_SET_ID. If bootloader
>does not modify
>> L2 aux register, using this save and restore logic for it is
>not needed.
>>
>> Signed-off-by: Tero Kristo
>
>Thanks, pulling into PM branch.
Same thing for this one, I have a version that uses arm_context as storage
area. I'll send it out also in a bit.
>
>Kevin
>
>> ---
>> arch/arm/mach-omap2/control.c |1 +
>> arch/arm/mach-omap2/sleep34xx.S | 31
>+++
>> arch/arm/plat-omap/Kconfig | 17 +
>> 3 files changed, 49 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/control.c
>b/arch/arm/mach-omap2/control.c
>> index 730fc53..82d8f1a 100644
>> --- a/arch/arm/mach-omap2/control.c
>> +++ b/arch/arm/mach-omap2/control.c
>> @@ -95,6 +95,7 @@ void *omap3_secure_ram_storage;
>> */
>> u32 omap3_arm_context[128];
>> u32 omap3_aux_ctrl[2] = { 0x1, 0x0 };
>> +u32 omap3_l2_aux_ctrl[2] = { 0x1, 0x0 };
>>
>> struct omap3_control_regs {
>> u32 sysconfig;
>> diff --git a/arch/arm/mach-omap2/sleep34xx.S
>b/arch/arm/mach-omap2/sleep34xx.S
>> index 0b03bf9..e291d6d 100644
>> --- a/arch/arm/mach-omap2/sleep34xx.S
>> +++ b/arch/arm/mach-omap2/sleep34xx.S
>> @@ -288,11 +288,30 @@ restore:
>> mcr p15, 0, r0, c7, c10, 5 @ data memory barrier
>> .word 0xE1600071 @ call SMI monitor (smi #1)
>>
>> +#ifdef CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE
>> +/* Restore L2 aux control register */
>> +@ set service ID for PPA
>> +mov r0, #CONFIG_OMAP3_L2_AUX_SECURE_SERVICE_SET_ID
>> +mov r12, r0 @ copy service ID in r12
>> +mov r1, #0 @ set task ID for ROM code in r1
>> +mov r2, #4 @ set some flags in r2, r6
>> +mov r6, #0xff
>> +ldr r3, write_l2_aux_control_params @ r3 points to
>parameters
>> +ldr r4, phys_offset
>> +addsr3, r3, r4
>> +ldr r4, page_offset
>> +subsr3, r3, r4
>> +mcr p15, 0, r0, c7, c10, 4 @ data write barrier
>> +mcr p15, 0, r0, c7, c10, 5 @ data memory barrier
>> +.word 0xE1600071 @ call SMI monitor (smi #1)
>> +#endif
>> b logic_l1_restore
>> l2_inv_api_params:
>> .word 0x1, 0x00
>> write_aux_control_params:
>> .word omap3_aux_ctrl
>> +write_l2_aux_control_params:
>> +.word omap3_l2_aux_ctrl
>> l2_inv_gp:
>> /* Execute smi to invalidate L2 cache */
>> mov r12, #0x1 @ set up to invalide L2
>> @@ -306,6 +325,15 @@ smi:.word 0xE1600070
>@ Call SMI monitor (smieq)
>> ldr r0, [r1, #4]
>> mov r12, #0x3
>> .word 0xE1600070@ Call SMI monitor (smieq)
>> +/* Restore L2 AUX control register */
>> +ldr r1, write_l2_aux_control_params
>> +ldr r0, phys_offset
>> +addsr1, r1, r0
>> +ldr r0, page_offset
>> +subsr1, r1, r0
>> +ldr r0, [r1, #4]
>> +mov r12, #0x2
>> +.word 0xE1600070@ Call SMI monitor (smieq)
>> logic_l1_restore:
>> mov r1, #0
>> /* Invalidate all instruction caches to PoU
>> @@ -433,6 +461,9 @@ save_context_wfi:
>> mrc p15, 0, r4, c1, c0, 1 @ Read Auxiliary
>Control Register
>> ldr r5, write_aux_control_params
>> str r4, [r5, #4]
>> +mrc p15, 1, r4, c9, c0, 2 @ Read L2 AUX ctrl register
>> +ldr r5, write_l2_aux_control_params
>> +str r4, [r5, #4]
>> /* Check what that target sleep state is:stored in r1*/
>> /* 1 - Only L1 and logic lost */
>> /* 2 - Only L2 lost */
>> diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
>> index 2143db5..3ff1a5f 100644
>> --- a/arch/arm/plat-omap/Kconfig
>> +++ b/arch/arm/plat-omap/Kconfig
>> @@ -185,6 +185,23 @@ config OMAP3_DEBOBS
>> help
>>Use ETK pads for debug observability
>>
>> +config OMAP3_L2_AUX_SECURE_SAVE_RESTORE
>> +bool "OMAP3 HS/EMU save and restore for L2 AUX control register"
>> +depends on ARCH_OMAP3 && PM
>> +default n
>> +help
>> + Without this option, L2 Auxiliary control register
>contents are
>> + lost during off-mode entry on HS/EMU devices. This feature
>> + requires support from PPA / boot-loader in HS/EMU
>devices, which
>> + currently does not exist by default.
>> +
>> +config OMAP3_L2_AUX_SECURE_SERVICE_SET_I
RE: [PATCH 08/11] OMAP3: PM: Disabled I2C4 repeated start operation mode
>-Original Message- >From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: 12 November, 2009 01:30 >To: Kristo Tero (Nokia-D/Tampere) >Cc: linux-omap@vger.kernel.org >Subject: Re: [PATCH 08/11] OMAP3: PM: Disabled I2C4 repeated >start operation mode > >Tero Kristo writes: > >> From: Tero Kristo >> >> Repeated start forces I2C4 pads low during idle, which >increases power >> consumption through external pull-ups. On the other hand, this change >> increases I2C4 command latencies a bit. > >Could you give an idea about how much the latencies increased? There is an additional master code (= 10 bits with start + ack) transmitted in the beginning of each I2C4 transmission. It is transmitted in fast/standard mode instead of high-speed, thus the duration of each I2C command is approximately doubled, from 25us to 50us. I'll update the patch description a bit and re-send. > >I'll apply this one but would like to update the changelog with some >more details if available. > >Kevin > >> Signed-off-by: Tero Kristo >> --- >> arch/arm/mach-omap2/pm34xx.c |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/pm34xx.c >b/arch/arm/mach-omap2/pm34xx.c >> index fec9c38..154cd31 100644 >> --- a/arch/arm/mach-omap2/pm34xx.c >> +++ b/arch/arm/mach-omap2/pm34xx.c >> @@ -1219,7 +1219,7 @@ static void __init configure_vc(void) >> prm_write_mod_reg(OMAP3430_CMD1 | OMAP3430_RAV1, >OMAP3430_GR_MOD, >>OMAP3_PRM_VC_CH_CONF_OFFSET); >> >> -prm_write_mod_reg(OMAP3430_MCODE_SHIFT | OMAP3430_HSEN >| OMAP3430_SREN, >> +prm_write_mod_reg(OMAP3430_MCODE_SHIFT | OMAP3430_HSEN, >>OMAP3430_GR_MOD, >>OMAP3_PRM_VC_I2C_CFG_OFFSET); >> >> -- >> 1.5.4.3 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe >linux-omap" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 11/11] OMAP3: PM: Disable OTG autoidle when waking up from off-mode
>-Original Message-
>From: ext Gadiyar, Anand [mailto:gadi...@ti.com]
>Sent: 12 November, 2009 08:25
>To: Kevin Hilman; Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: RE: [PATCH 11/11] OMAP3: PM: Disable OTG autoidle
>when waking up from off-mode
>
>Kevin Hilman wrote:
>> Tero Kristo writes:
>>
>> > From: Tero Kristo
>> >
>> > OMAP3 sleep can be prevented in some cases where OTG
>autoidle is enabled.
>> > This patch force disables autoidle during wakeup from
>off-mode. See omap
>> > errata 1.164.
>> >
>> > Signed-off-by: Tero Kristo
>>
>> This one needs a refresh against current PM branch.
>>
>> > ---
>> > arch/arm/mach-omap2/pm34xx.c |6 ++
>> > arch/arm/mach-omap2/usb-musb.c| 14 --
>> > arch/arm/plat-omap/include/mach/usb.h |3 +++
>>
>> mach/usb.h moved to plat/usb.h
>>
>> > 3 files changed, 17 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/arch/arm/mach-omap2/pm34xx.c
>b/arch/arm/mach-omap2/pm34xx.c
>> > index 5eb7321..070a0a2 100644
>> > --- a/arch/arm/mach-omap2/pm34xx.c
>> > +++ b/arch/arm/mach-omap2/pm34xx.c
>> > @@ -39,6 +39,7 @@
>> > #include
>> > #include
>> > #include
>> > +#include
>> >
>> > #include
>> >
>> > @@ -496,6 +497,11 @@ void omap_sram_idle(void)
>> >omap3_prcm_restore_context();
>> >omap3_sram_restore_context();
>> >omap2_sms_restore_context();
>> > + /*
>> > + * Errata 1.164 fix : OTG autoidle can prevent
>> > + * sleep
>> > + */
>> > + usb_musb_disable_autoidle();
>>
>> NAK. This belongs in the MUSB driver, not in the idle path.
>>
>
>Kevin,
>
>When we exit off-mode, the autoidle will get enabled, and needs
>an explicit disable. If the MUSB driver is not loaded, there will
>be no one to do this.
Also, even if the driver is loaded, it doesn't disable this bit each sleep
cycle.
>
>- Anand
>
>> Kevin
>>
>> >}
>> >omap_uart_resume_idle(0);
>> >omap_uart_resume_idle(1);
>> > diff --git a/arch/arm/mach-omap2/usb-musb.c
>b/arch/arm/mach-omap2/usb-musb.c
>> > index 8dde0b7..f4b86c0 100644
>> > --- a/arch/arm/mach-omap2/usb-musb.c
>> > +++ b/arch/arm/mach-omap2/usb-musb.c
>> > @@ -44,10 +44,11 @@ static struct platform_device dummy_pdev = {
>> >},
>> > };
>> >
>> > +static void __iomem *otg_base;
>> > +static struct clk *otg_clk;
>> > +
>> > static void __init usb_musb_pm_init(void)
>> > {
>> > - void __iomem *otg_base;
>> > - struct clk *otg_clk;
>> >struct device *dev = &dummy_pdev.dev;
>> >
>> >if (!cpu_is_omap34xx())
>> > @@ -74,12 +75,13 @@ static void __init usb_musb_pm_init(void)
>> >cpu_relax();
>> >}
>> >
>> > - if (otg_clk) {
>> > + if (otg_clk)
>> >clk_disable(otg_clk);
>> > - clk_put(otg_clk);
>> > - }
>> > +}
>> >
>> >
>> > - iounmap(otg_base);
>> > +void usb_musb_disable_autoidle(void)
>> > +{
>> > + __raw_writel(0, otg_base + OTG_SYSCONFIG);
>> > }
>> >
>> > #ifdef CONFIG_USB_MUSB_SOC
>> > diff --git a/arch/arm/plat-omap/include/mach/usb.h
>b/arch/arm/plat-omap/include/mach/usb.h
>> > index a4068a4..310ee17 100644
>> > --- a/arch/arm/plat-omap/include/mach/usb.h
>> > +++ b/arch/arm/plat-omap/include/mach/usb.h
>> > @@ -46,6 +46,9 @@ extern void usb_musb_init(void);
>> >
>> > extern void usb_ehci_init(struct
>ehci_hcd_omap_platform_data *pdata);
>> >
>> > +/* This is needed for OMAP3 errata 1.164: enabled
>autoidle can prevent sleep */
>> > +extern void usb_musb_disable_autoidle(void);
>> > +
>> > #endif
>> >
>> > void omap_usb_init(struct omap_usb_config *pdata);
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/6] OMAP3: PM: Added support for INACTIVE and ON states for powerdomains
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 16 November, 2009 21:42
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 2/6] OMAP3: PM: Added support for INACTIVE
>and ON states for powerdomains
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> Previously omap_sram_idle() did not know about the
>difference between ON and
>> INACTIVE states, which complicated the state handling in these cases.
>
>This changelog needs an update.
>
>This patch changes makes the IO-chain arming conditional and removes
>the clockdomain idle calls.
IO-chain arming is already conditional, the condition needs to be changed a bit
due to changed powerdomain states.
- previously: less than PWRDM_POWER_ON = RET and OFF
- now: less than or equal to PWRDM_POWER_RET = RET and OFF
What is changed actually is that if CORE or PER is going INACTIVE, we will
disable UART clocks which will allow CORE and UART to go inactive. Previously
this did not happen.
>While I understand the clkdm idle call removal, It's not clear from
>the changelog how these are related to the new handling of INACTIVE
>states.
Yes, I can try to fix the changelog a bit regarding this.
>
>> Signed-off-by: Tero Kristo
>> ---
>> arch/arm/mach-omap2/pm34xx.c | 14 +++---
>> 1 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c
>b/arch/arm/mach-omap2/pm34xx.c
>> index 9d0a9b4..7b52f30 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -383,6 +383,7 @@ void omap_sram_idle(void)
>> mpu_next_state = pwrdm_read_next_pwrst(mpu_pwrdm);
>> switch (mpu_next_state) {
>> case PWRDM_POWER_ON:
>> +case PWRDM_POWER_INACTIVE:
>> case PWRDM_POWER_RET:
>> /* No need to save context */
>> save_state = 0;
>> @@ -448,9 +449,11 @@ void omap_sram_idle(void)
>> OMAP3430_GR_MOD,
>>
>OMAP3_PRM_VOLTCTRL_OFFSET);
>> }
>> -/* Enable IO-PAD and IO-CHAIN wakeups */
>> -prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
>> -omap3_enable_io_chain();
>> +if (core_next_state <= PWRDM_POWER_RET) {
>> +/* Enable IO-PAD and IO-CHAIN wakeups */
>> +prm_set_mod_reg_bits(OMAP3430_EN_IO,
>WKUP_MOD, PM_WKEN);
>> +omap3_enable_io_chain();
>> +}
>> }
>> omap3_intc_prepare_idle();
>>
>> @@ -542,15 +545,13 @@ void omap_sram_idle(void)
>> }
>>
>> /* Disable IO-PAD and IO-CHAIN wakeup */
>> -if (core_next_state < PWRDM_POWER_ON) {
>> +if (core_next_state <= PWRDM_POWER_ON) {
>
>Hmm, did you mean <= RET here?
True, this is a bug. Should be RET.
>Otherwise, you can just remove the conditional.
>
>> prm_clear_mod_reg_bits(OMAP3430_EN_IO,
>WKUP_MOD, PM_WKEN);
>> omap3_disable_io_chain();
>> }
>>
>>
>> pwrdm_post_transition();
>> -
>> -omap2_clkdm_allow_idle(mpu_pwrdm->pwrdm_clkdms[0]);
>> }
>>
>> int omap3_can_sleep(void)
>> @@ -598,7 +599,6 @@ int set_pwrdm_state(struct powerdomain
>*pwrdm, u32 state)
>> }
>>
>> if (sleep_switch) {
>> -omap2_clkdm_allow_idle(pwrdm->pwrdm_clkdms[0]);
>> pwrdm_wait_transition(pwrdm);
>> pwrdm_state_switch(pwrdm);
>> }
>> --
>> 1.5.4.3
>
>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 4/6] OMAP3: PM: Removed PER + CORE state hacking from omap_sram_idle
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 16 November, 2009 21:45
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 4/6] OMAP3: PM: Removed PER + CORE state
>hacking from omap_sram_idle
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>
>A more descriptive changelog would be nice here.
>
>> This should be moved inside cpuidle to simplify design.
>
>And this should probably say "... and will be moved into CPUidle in
>subsequent patch."
I'll update this.
>
>Kevin
>
>> Signed-off-by: Tero Kristo
>> ---
>> arch/arm/mach-omap2/pm34xx.c | 18 ++
>> 1 files changed, 2 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c
>b/arch/arm/mach-omap2/pm34xx.c
>> index 7b52f30..c704756 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -81,7 +81,6 @@ static int (*_omap_save_secure_sram)(u32 *addr);
>>
>> static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
>> static struct powerdomain *core_pwrdm, *per_pwrdm;
>> -static struct powerdomain *cam_pwrdm;
>>
>> static struct prm_setup_times_vc prm_setup_times_default = {
>> .clksetup = 0xff,
>> @@ -370,7 +369,6 @@ void omap_sram_idle(void)
>> int core_next_state = PWRDM_POWER_ON;
>> int core_prev_state, per_prev_state;
>> u32 sdrc_pwr = 0;
>> -int per_state_modified = 0;
>>
>> if (!_omap_sram_idle)
>> return;
>> @@ -409,19 +407,10 @@ void omap_sram_idle(void)
>> if (per_next_state < PWRDM_POWER_ON) {
>> omap_uart_prepare_idle(2);
>> omap2_gpio_prepare_for_idle(per_next_state);
>> -if (per_next_state == PWRDM_POWER_OFF) {
>> -if (core_next_state == PWRDM_POWER_ON) {
>> -per_next_state = PWRDM_POWER_RET;
>> -pwrdm_set_next_pwrst(per_pwrdm,
>per_next_state);
>> -per_state_modified = 1;
>> -} else
>> -omap3_per_save_context();
>> -}
>> +if (per_next_state == PWRDM_POWER_OFF)
>> +omap3_per_save_context();
>> }
>>
>> -if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
>> -omap2_clkdm_deny_idle(mpu_pwrdm->pwrdm_clkdms[0]);
>> -
>> /*
>> * Disable smartreflex before entering WFI.
>> * Only needed if we are going to enter retention or off.
>> @@ -540,8 +529,6 @@ void omap_sram_idle(void)
>> omap3_gpio_restore_pad_context(1);
>> omap2_gpio_resume_after_idle();
>> omap_uart_resume_idle(2);
>> -if (per_state_modified)
>> -pwrdm_set_next_pwrst(per_pwrdm,
>PWRDM_POWER_OFF);
>> }
>>
>> /* Disable IO-PAD and IO-CHAIN wakeup */
>> @@ -1170,7 +1157,6 @@ static int __init omap3_pm_init(void)
>> neon_pwrdm = pwrdm_lookup("neon_pwrdm");
>> per_pwrdm = pwrdm_lookup("per_pwrdm");
>> core_pwrdm = pwrdm_lookup("core_pwrdm");
>> -cam_pwrdm = pwrdm_lookup("cam_pwrdm");
>>
>> omap_push_sram_idle();
>> #ifdef CONFIG_SUSPEND
>> --
>> 1.5.4.3
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/6] OMAP3: CPUidle: Added peripheral pwrdm checks into bm check
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 16 November, 2009 21:59
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 6/6] OMAP3: CPUidle: Added peripheral
>pwrdm checks into bm check
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> Following checks are made (and their reasoning):
>>
>> - If CAM domain is active, prevent idle completely
>> * CAM pwrdm does not have HW wakeup capability
>> - If PER is likely to remain on, prevent PER off
>> * Saves on unnecessary context save/restore
>> - If CORE domain is active, prevent PER off-mode
>> * PER off in this case would prevent wakeups from PER completely
>> - Only allow CORE off, if all peripheral domains are off
>> * CORE off will cause a chipwide reset
>>
>> Also, enabled CHECK_BM flag for C2, as this is needed for
>the camera case.
>>
>> Signed-off-by: Tero Kristo
>
>Some questions and a couple minor style comments below...
Will do the style changes, answers below.
>
>> ---
>> arch/arm/mach-omap2/cpuidle34xx.c | 105
>++---
>> 1 files changed, 98 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
>b/arch/arm/mach-omap2/cpuidle34xx.c
>> index e46345f..4654e87 100644
>> --- a/arch/arm/mach-omap2/cpuidle34xx.c
>> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
>> @@ -58,7 +58,8 @@ struct omap3_processor_cx {
>>
>> struct omap3_processor_cx omap3_power_states[OMAP3_MAX_STATES];
>> struct omap3_processor_cx current_cx_state;
>> -struct powerdomain *mpu_pd, *core_pd;
>> +struct powerdomain *mpu_pd, *core_pd, *per_pd, *iva2_pd;
>> +struct powerdomain *sgx_pd, *usb_pd, *cam_pd, *dss_pd;
>>
>> /*
>> * The latencies/thresholds for various C states have
>> @@ -91,6 +92,13 @@ static int omap3_idle_bm_check(void)
>> return 0;
>> }
>
>> +static int pwrdm_get_idle_state(struct powerdomain *pwrdm)
>
>could use a function comment
Ok.
>
>> +{
>> +if (pwrdm_can_idle(pwrdm))
>> +return pwrdm_read_next_pwrst(pwrdm);
>> +return PWRDM_POWER_ON;
>> +}
>> +
>
>Possible candidate for powerdomain API?
Candidate yes, if we would need this somewhere else. I did not want to make an
API change that is not needed anywhere else at the moment. Maybe Paul has some
comments on this?
>
>> /**
>> * omap3_enter_idle - Programs OMAP3 to enter the specified state
>> * @dev: cpuidle device
>> @@ -153,14 +161,90 @@ static int omap3_enter_idle_bm(struct
>cpuidle_device *dev,
>> struct cpuidle_state *state)
>> {
>> struct cpuidle_state *new_state = state;
>> -
>> -if ((state->flags & CPUIDLE_FLAG_CHECK_BM) &&
>omap3_idle_bm_check()) {
>> -BUG_ON(!dev->safe_state);
>> -new_state = dev->safe_state;
>> +u32 per_state = 0, saved_per_state = 0, cam_state, usb_state;
>> +u32 iva2_state, sgx_state, dss_state, new_core_state;
>> +struct omap3_processor_cx *cx;
>> +int ret;
>> +
>> +if (state->flags & CPUIDLE_FLAG_CHECK_BM) {
>> +if (omap3_idle_bm_check()) {
>> +BUG_ON(!dev->safe_state);
>> +new_state = dev->safe_state;
>> +goto select_state;
>> +}
>> +cx = cpuidle_get_statedata(state);
>> +new_core_state = cx->core_state;
>> +
>> +/* Check if CORE is active, if yes, fallback to
>inactive */
>> +if (!pwrdm_can_idle(core_pd))
>> +new_core_state = PWRDM_POWER_INACTIVE;
>> +
>> +/*
>> + * Prevent idle completely if CAM is active.
>> + * CAM does not have wakeup capability in OMAP3.
>> + */
>> +cam_state = pwrdm_get_idle_state(cam_pd);
>> +if (cam_state == PWRDM_POWER_ON) {
>> +new_state = dev->safe_state;
>> +goto select_state;
>> +}
>> +
>> +/*
>> + * Check if PER can idle or not. If we are not likely
>> + * to idle, deny PER off. This prevents unnecessary
>> + * context save/restore.
>> + */
>> +saved_per_state = pwrdm_read_next_pwrst(per_pd);
>> +if (pwrdm_can_idle(per_pd)) {
>> +per_state = saved_per_state;
>> +/*
>> + * Prevent PER off if CORE is active as this
>> + * would disable PER wakeups completely
>> + */
>> +if (per_state == PWRDM_POWER_OFF &&
>> +new_core_state > PWRDM_POWER_RET)
>> +per_state = PWRDM_POWER_RET;
>> +
>> +} else if (saved_per_state == PWRDM_POWER_OFF)
>> +per_state = PWRDM_POWER_RET;
>> +
>> +/*
>> + * If we are attempting CORE off, check if any other
>> + * powerdomains are at retention or higher.
RE: [PATCH 5/6] OMAP: Powerdomains: Add support for checking if pwrdm can idle
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 16 November, 2009 22:13
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 5/6] OMAP: Powerdomains: Add support for
>checking if pwrdm can idle
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> pwrdm_can_idle(pwrdm) will check if the specified
>powerdomain can enter
>> idle. This is done by checking the current fclk enable bits.
>>
>> This call can be used e.g. inside cpuidle to decide which
>power states
>> core and mpu should enter during idle, as there are certain
>dependencies
>> between wakeup capabilities and reset logic.
>>
>> Signed-off-by: Tero Kristo
>
>In your initial implementatio, you were checking all (most) of the
>fclks in a given powerdomain. In this version, you're currently only
>checking masks in CORE (UART1 and 2) and PER (UART3.)
The masks are negative masks, we are checking whether all the rest of the
clocks are inactive or not. UART clocks are currently masked away because we
are controlling those inside omap_sram_idle, thus they are always on when we do
the check, and the system assumes we can enter idle after they are disabled.
>
>I'll assume it's just to propose the idea and we can add more fclks
>later.
There might be some sort of need to add or change the masks on some boards.
Some of the UARTs might be controlled by some other drivers, in which case
their FCLK should actually be checked against, and not masked, because they
would no longer be controlled inside omap_sram_idle().
>
>That being said, I'm a little reluctant to add another list of FCLK
>masks. This seems like something that clock/clockdomain code should be
>handling.
>
>In terms of cleanness, it seems that pwrdm_can_idle() should call some
>sort of clkdm_can_idle() call for all the clockdomains associated with
>it (pwrdm->pwrdm_clkdms[].)
>
>The clockdomain code already tracks its usecount, so clkdm_can_idle()
>might be as simple as checking clkdm->usecount. Just a thought
>without digging into the clkdm code.
I did think and experiment with this usecount option a bit. The problem with
usecounts is that you will have some interesting usecount numbers due to
always_on clocks, uart clocks, and interface clocks. For example per_clkdm
usecount is currently 9 on my rx51 board when we are entering omap_sram_idle
and there is nothing but UART3 active. This number is most likely something
else if we have a different board which has e.g. different number of interface
clocks active. Interface clocks do not matter in the idle equation because we
have autoidle enabled for all of those when we are entering idle and they will
be turned off by hw. It might be possible to somehow keep a separate usecount
for FCLKs and all clocks inside clock framework, but this sounds awfully
complex, as you can simply read this from HW.
However, the part where this idle check would be moved inside clockdomain code
is simple, I could just move the FCLK check bit there, and move the fclk_reg
and mask definitions from pwrdm to clkdm.
How does the option of moving the FCLK checks inside clkdm code sound like, but
keeping the implementation similar otherwise?
>
>Kevin
>
>> ---
>> arch/arm/mach-omap2/powerdomain.c | 22
>++
>> arch/arm/mach-omap2/powerdomains34xx.h| 14 ++
>> arch/arm/plat-omap/include/plat/powerdomain.h |9 +
>> 3 files changed, 45 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/powerdomain.c
>b/arch/arm/mach-omap2/powerdomain.c
>> index 1237717..bf2b97a 100644
>> --- a/arch/arm/mach-omap2/powerdomain.c
>> +++ b/arch/arm/mach-omap2/powerdomain.c
>> @@ -1217,6 +1217,28 @@ int pwrdm_wait_transition(struct
>powerdomain *pwrdm)
>> return 0;
>> }
>>
>> +/**
>> + * pwrdm_can_idle - check if the powerdomain can enter idle
>> + * @pwrdm: struct powerdomain * the powerdomain to check status of
>> + *
>> + * Does a functional clock check for the powerdomain and
>returns 1 if the
>> + * powerdomain can enter idle, 0 if not.
>> + */
>> +int pwrdm_can_idle(struct powerdomain *pwrdm)
>> +{
>> +int i;
>> +const int fclk_regs[] = { CM_FCLKEN, OMAP3430ES2_CM_FCLKEN3 };
>> +
>> +if (!pwrdm)
>> +return -EINVAL;
>> +
>> +for (i = 0; i < pwrdm->fclk_reg_amt; i++)
>> +if (cm_read_mod_reg(pwrdm->prcm_offs, fclk_regs[i]) &
>> +(0x ^ pwrdm->fclk_masks[i]))
>> +return 0;
>> +return 1;
>> +}
>> +
>> int pwrdm_state_switch(struct powerdomain *pwrdm)
>> {
>> return _pwrdm_state_switch(pwrdm, PWRDM_STATE_NOW);
>> diff --git a/arch/arm/mach-omap2/powerdomains34xx.h
>b/arch/arm/mach-omap2/powerdomains34xx.h
>> index 9eb2dc5..c8cd297 100644
>> --- a/arch/arm/mach-omap2/powerdomains34xx.h
>> +++ b/arch/arm/mach-omap2/powerdomains34xx.h
>> @@ -180,6 +180,7 @@ static struct powerdomain iva
RE: [PATCH] OMAP3: PM: Force write last pad config register into save area
>-Original Message- >From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: 17 November, 2009 20:34 >To: Kristo Tero (Nokia-D/Tampere) >Cc: linux-omap@vger.kernel.org >Subject: Re: [PATCH] OMAP3: PM: Force write last pad config >register into save area > >Tero Kristo writes: > >> From: Tero Kristo >> >> Due to OMAP3 errata XYZ, the save of the last pad register >(ETK_D14 and >> ETK_D15) can fail sometimes when there is simultaneous OCP >access to the >> SCM register area. Fixed by writing the last register to the >save area. >> >> Also, optimized the delay loop for the HW save to include an >udelay(1), >> which limits the number of unnecessary HW accesses to SCM >register area >> during the save. >> >> Signed-off-by: Tero Kristo > >I certainly like this fix much better than the original proposal: > > http://marc.info/?l=linux-omap&m=125474186609661&w=2 > >Pulling into PM branch after s/XYZ/1.157/ I will resend the patch when TI has confirmed the errata number. This version of the patch was also missing an "#include " for the udelay, I missed this in the hurry, so I will add this one also. -Tero > >> --- >> arch/arm/mach-omap2/pm34xx.c | 10 +- >> 1 files changed, 9 insertions(+), 1 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/pm34xx.c >b/arch/arm/mach-omap2/pm34xx.c >> index 4b01303..4ead40e 100644 >> --- a/arch/arm/mach-omap2/pm34xx.c >> +++ b/arch/arm/mach-omap2/pm34xx.c >> @@ -155,7 +155,15 @@ static void omap3_core_save_context(void) >> /* wait for the save to complete */ >> while >(!(omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS) >> & PADCONF_SAVE_DONE)) >> -; >> +udelay(1); >> + >> +/* >> + * Force write last pad into memory, as this can fail in some >> + * cases according to errata XYZ >> + */ >> +omap_ctrl_writel(omap_ctrl_readl(OMAP343X_PADCONF_ETK_D14), >> +OMAP343X_CONTROL_MEM_WKUP + 0x2a0); >> + >> /* Save the Interrupt controller context */ >> omap_intc_save_context(); >> /* Save the GPMC context */ >> -- >> 1.5.4.3 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe >linux-omap" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] OMAP3: Implemented VFP restore/save context
>-Original Message-
>From: ext Sripathy, Vishwanath [mailto:vishwanath...@ti.com]
>Sent: 24 November, 2009 13:34
>To: Kristo Tero (Nokia-D/Tampere); linux-arm-ker...@lists.infradead.org
>Cc: linux-omap@vger.kernel.org
>Subject: RE: [PATCH 2/2] OMAP3: Implemented VFP restore/save context
>
>
>
>> -Original Message-
>> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>> ow...@vger.kernel.org] On Behalf Of Tero Kristo
>> Sent: Tuesday, November 24, 2009 4:07 PM
>> To: linux-arm-ker...@lists.infradead.org
>> Cc: linux-omap@vger.kernel.org
>> Subject: [PATCH 2/2] OMAP3: Implemented VFP restore/save context
>>
>> From: Tero Kristo
>>
>> VFP save context is called before MPU/NEON off. Restore is
>not needed as
>> the next VFP trap will restore context automatically. Uses
>the support
>> routine implemented in arch/arm/vfp/vfpmodule.c.
>>
>> Signed-off-by: Tero Kristo
>> Acked-by: Tony Lindgren
>> Cc: Vishwanath Sripathy
>> Cc: Rajendra Nayak
>> Cc: Richard Woodruff
>> Cc: Peter 'p2' De Schrijver
>> ---
>> arch/arm/mach-omap2/pm.h |1 +
>> arch/arm/mach-omap2/pm34xx.c | 21 -
>> 2 files changed, 21 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
>> index 4f22107..dd5bbaf 100644
>> --- a/arch/arm/mach-omap2/pm.h
>> +++ b/arch/arm/mach-omap2/pm.h
>> @@ -18,6 +18,7 @@ extern u32 sleep_while_idle;
>> extern u32 voltage_off_while_idle;
>>
>> extern void *omap3_secure_ram_storage;
>> +extern void vfp_pm_save_context(void);
>> extern void omap3_pm_off_mode_enable(int);
>> extern void omap_sram_idle(void);
>> extern int omap3_can_sleep(void);
>> diff --git a/arch/arm/mach-omap2/pm34xx.c
>b/arch/arm/mach-omap2/pm34xx.c
>> index b26ae5b..4b01303 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -321,6 +321,18 @@ static void restore_control_register(u32 val)
>> __asm__ __volatile__ ("mcr p15, 0, %0, c1, c0, 0" : :
>"r" (val));
>> }
>>
>> +static inline void omap3_save_neon_context(void)
>> +{
>> +#ifdef CONFIG_VFP
>> +vfp_pm_save_context();
>> +#endif
>> +}
>> +
>> +static inline void omap3_restore_neon_context(void)
>> +{
>> +return;
>> +}
>> +
>> /* Function to restore the table entry that was modified
>for enabling MMU */
>> static void restore_table_entry(void)
>> {
>> @@ -365,6 +377,7 @@ void omap_sram_idle(void)
>> /* save_state = 3 => L1, L2 and logic lost */
>> int save_state = 0;
>> int mpu_next_state = PWRDM_POWER_ON;
>> +int neon_next_state = PWRDM_POWER_ON;
>> int per_next_state = PWRDM_POWER_ON;
>> int core_next_state = PWRDM_POWER_ON;
>> int core_prev_state, per_prev_state;
>> @@ -398,8 +411,12 @@ void omap_sram_idle(void)
>> pwrdm_pre_transition();
>>
>> /* NEON control */
>> -if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
>> +if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON) {
>> pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
>> +neon_next_state = mpu_next_state;
>> +if (neon_next_state == PWRDM_POWER_OFF)
>> +omap3_save_neon_context();
>> +}
>>
>> /* PER */
>> per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
>> @@ -537,6 +554,8 @@ void omap_sram_idle(void)
>> omap3_disable_io_chain();
>> }
>>
>> +if (neon_next_state == PWRDM_POWER_OFF)
>> +omap3_restore_neon_context();
>>
>Why do call restore here when restore is done automatically
>upon context switch?
That is just a stub if we would need to add something there at some point.
restore_neon_context() currently does nothing.
>
>> pwrdm_post_transition();
>> }
>> --
>> 1.5.4.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] ARM: Implemented support for VFP PM context saving
>-Original Message- >From: ext Catalin Marinas [mailto:catalin.mari...@arm.com] >Sent: 24 November, 2009 15:20 >To: Russell King - ARM Linux >Cc: Kristo Tero (Nokia-D/Tampere); linux-omap@vger.kernel.org; >linux-arm-ker...@lists.infradead.org; Dave Estes >Subject: Re: [PATCH 1/2] ARM: Implemented support for VFP PM >context saving > >On Tue, 2009-11-24 at 11:48 +, Russell King - ARM Linux wrote: >> On Tue, Nov 24, 2009 at 12:37:03PM +0200, Tero Kristo wrote: >> > In some ARM architectures, like OMAP3, the VFP context can >be lost during >> > dynamic sleep cycle. For this purpose, there is now a function >> > vfp_pm_save_context() that should be called before the VFP >is assumed to >> > lose context. Next VFP trap will then restore context >automatically. >> > >> > We need to have the last_VFP_context[cpu] cleared after >the save in idle, >> > else the restore would fail to restore when it sees that >the last_VFP_context >> > is same as the current threads vfp_state. This happens >when the same >> > process/thread traps an exception post idle. >> > >> > Main work for this patch was done by Peter and Rajendra. >Some cleanup and >> > optimization by Tero. >> >> Why not re-use vfp_pm_suspend() ? Haven't you shown that >vfp_pm_suspend >> may be buggy since it doesn't save in the VFP-disabled case? >BTW, the two patches below were mentioned to me some time ago but I >haven't got the time to look at them: > >[ARM] vfp: Fix bug in vfp_pm_suspend >https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=c >ommit;h=88984c9b2d69c222ee1e2afc948ca73f597d40ff > >[ARM] vfp: Add additional vfp interfaces >https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=c >ommit;h=393e4bfaaf79377d29cd6bb2228f87601aeca668 These look pretty much like the same thing we have attempted on the omap3 patches, I could try these out and check if they work for omap3 also. They fix the potentially broken suspend also. -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: [PATCH] OMAP3: DVFS: No sdrc AC timing changes during core dvfs
Hi, Is there any update on this chain seeing this has been pending for a month now? -Tero >-Original Message- >From: linux-omap-ow...@vger.kernel.org >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext >Woodruff, Richard >Sent: 22 October, 2009 15:20 >To: Cousson, Benoit; Paul Walmsley; Nayak, Rajendra >Cc: linux-omap@vger.kernel.org >Subject: RE: [PATCH] OMAP3: DVFS: No sdrc AC timing changes >during core dvfs > >Hi Beonit, > >> From: Cousson, Benoit >> Sent: Thursday, October 22, 2009 3:59 AM >> To: Woodruff, Richard; Paul Walmsley; Nayak, Rajendra > >> >It is not guaranteed safe to write actim registers on the >fly to an active >> >part. It is safe to do RFR as it is buffered and sent out >at a safe time. >> >> I think that what Paul is suggesting is to change the ACTIM >after ensuring >> that the DDR is in self-refresh. In that case it is >perfectly valid; it is >> just tricky to ensure that all initiators are in mute before >doing that. > >Yes that is true, however, ... > >That is not the way the code is setup and it's a long way from >that. Run time pause of drivers is a minefield. > >With out a broad notifier they best you would hope for is some >opportunistic change time (against full system). You wouldn't >have a guaranteed way to speed them up again where you need >them most at high opp. > >Some minimal kernel not using dma and the like could do it but >that is probably more misleading to put in the tree than >something useful for most. > >Regards, >Richard W. > >-- >To unsubscribe from this list: send the line "unsubscribe >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 1/2] ARM: Implemented support for VFP PM context saving
>-Original Message- >From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] >Sent: 24 November, 2009 17:19 >To: Catalin Marinas >Cc: Kristo Tero (Nokia-D/Tampere); linux-omap@vger.kernel.org; >linux-arm-ker...@lists.infradead.org; Dave Estes >Subject: Re: [PATCH 1/2] ARM: Implemented support for VFP PM >context saving > >On Tue, Nov 24, 2009 at 01:20:26PM +, Catalin Marinas wrote: >> BTW, the two patches below were mentioned to me some time ago but I >> haven't got the time to look at them: >> >> [ARM] vfp: Fix bug in vfp_pm_suspend >> >https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=c >ommit;h=88984c9b2d69c222ee1e2afc948ca73f597d40ff > >This one is bad - it gets the current CPU by directly >referencing ti->cpu. >Too bad if you have kernel preemption enabled; the value obtained that >way is effectively meaningless. The only way to get a meaningful value >is via 'get_cpu()' and after you've done with using it, 'put_cpu()'. >That ensures you can't be preempted onto a different CPU mid-operation. > >It's safe in vfp_notifier because we're called in an already >atomic context. I investigated this issue a bit more, and indeed there is a potential bug in the vfp_pm_suspend(). Most of the time it works fine as apparently shell process has VFP enabled at least on my system, and it saves the state. The issue is different with dynamic idle, we are calling the code from init thread which does not need VFP for anything, and thus VFP is always disabled if we try to call vfp_pm_suspend(). For OMAP3, I found a way to fix the dynamic idle part to work properly by just simply calling vfp_sync_state() from idle. This functionality is supposed to be used by ptrace, but I guess it could be used for this also? A proper fix for suspend is bit more difficult, as I don't know too well how SMP is supposed to work in this case. I guess there is a separate VFP co-processor available for each ARM core, but vfp_pm_suspend() is only called once for the whole system? > >> [ARM] vfp: Add additional vfp interfaces >> >https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=c >ommit;h=393e4bfaaf79377d29cd6bb2228f87601aeca668 > >I don't like what's in this one. Lack of explaination in the >commit log >doesn't help. >-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if doing so would reset an active clockdomain
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>ow...@vger.kernel.org] On Behalf Of ext Vishwanath Sripathy
>Sent: 19 January, 2011 06:39
>To: Kristo Tero (Nokia-MS/Tampere); linux-omap@vger.kernel.org
>Cc: Paul Walmsley; Kevin Hilman
>Subject: RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if
>doing so would reset an active clockdomain
>
>Tero,
>
>> -Original Message-
>> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>> ow...@vger.kernel.org] On Behalf Of Tero Kristo
>> Sent: Tuesday, January 18, 2011 3:18 PM
>> To: linux-omap@vger.kernel.org
>> Cc: Paul Walmsley; Kevin Hilman
>> Subject: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if doing
>> so would reset an active clockdomain
>>
>> On OMAP3 SoCs, if the CORE powerdomain enters off-mode, many other
>> parts of the chip will be reset. If those parts of the chip are busy,
>> the reset will disrupt them, causing unpredictable and generally
>> undesirable results.
>If some parts of the chip are busy, then how can Core domain enter off
>state? The necessary condition for Core to enter low power state is that
>all the clock domains (including DSS, CAM, IVA, USB, PER etc) should
>have
>idled. Doesn't it mean that all the modules have idled and asserted
>idleack when Core is entering off state?
This can happen e.g. when some powerdomain has entered RET state. We have faced
this issue at least with IVA2 because it has its own power management.
>
>Vishwa
>>
>> Signed-off-by: Tero Kristo
>> Cc: Paul Walmsley
>> Cc: Kevin Hilman
>> ---
>> arch/arm/mach-omap2/cpuidle34xx.c | 40
>> +++-
>> 1 files changed, 38 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-
>> omap2/cpuidle34xx.c
>> index f3e043f..d31b858 100644
>> --- a/arch/arm/mach-omap2/cpuidle34xx.c
>> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
>> @@ -61,7 +61,7 @@ struct omap3_processor_cx {
>> struct omap3_processor_cx
>> omap3_power_states[OMAP3_MAX_STATES];
>> struct omap3_processor_cx current_cx_state;
>> struct powerdomain *mpu_pd, *core_pd, *per_pd;
>> -struct powerdomain *cam_pd;
>> +struct powerdomain *cam_pd, *dss_pd, *iva2_pd, *sgx_pd, *usb_pd;
>>
>> /*
>> * The latencies/thresholds for various C states have
>> @@ -235,7 +235,7 @@ static int omap3_enter_idle_bm(struct
>> cpuidle_device *dev,
>> {
>> struct cpuidle_state *new_state = next_valid_state(dev, state);
>> u32 core_next_state, per_next_state = 0, per_saved_state = 0;
>> -u32 cam_state;
>> +u32 cam_state, dss_state, iva2_state, sgx_state, usb_state;
>> struct omap3_processor_cx *cx;
>> int ret;
>>
>> @@ -256,6 +256,8 @@ static int omap3_enter_idle_bm(struct
>> cpuidle_device *dev,
>> *its own code.
>> */
>>
>> +/* XXX Add CORE-active check here */
>> +
>> /*
>> * Prevent idle completely if CAM is active.
>> * CAM does not have wakeup capability in OMAP3.
>> @@ -275,6 +277,36 @@ static int omap3_enter_idle_bm(struct
>> cpuidle_device *dev,
>> (core_next_state > PWRDM_POWER_RET))
>> per_next_state = PWRDM_POWER_RET;
>>
>> +/* XXX Add prevent-PER-off check here */
>> +
>> +/*
>> + * If we are attempting CORE off, check if any other
>> powerdomains
>> + * are at retention or higher. CORE off causes chipwide reset
>> which
>> + * would reset these domains also.
>> + */
>> +if (core_next_state == PWRDM_POWER_OFF) {
>> +iva2_state = pwrdm_read_pwrst(iva2_pd);
>> +sgx_state = pwrdm_read_pwrst(sgx_pd);
>> +usb_state = pwrdm_read_pwrst(usb_pd);
>> +dss_state = pwrdm_read_pwrst(dss_pd);
>> +
>> +if (cam_state > PWRDM_POWER_OFF ||
>> +dss_state > PWRDM_POWER_OFF ||
>> +iva2_state > PWRDM_POWER_OFF ||
>> +per_next_state > PWRDM_POWER_OFF ||
>> +sgx_state > PWRDM_POWER_OFF ||
>> +usb_state > PWRDM_POWER_OFF)
>> +core_next_state = PWRDM_POWER_RET;
>> +}
>> +
>> +/* Fallback to new target core/mpu state */
>> +while (cx->core_state < core_next_state) {
>> +state--;
>> +cx = cpuidle_get_statedata(state);
>> +}
>> +
>> +new_state = state;
>> +
>> /* Are we changing PER target state? */
>> if (per_next_state != per_saved_state)
>> pwrdm_set_next_pwrst(per_pd, per_next_state);
>> @@ -489,6 +521,10 @@ int __init omap3_idle_init(void)
>> core_pd = pwrdm_lookup("core_pwrdm");
>> per_pd = pwrdm_lookup("per_pwrdm");
>> cam_pd = pwrdm_lookup("cam_pwrdm");
>> +dss_pd = pwrdm_lookup("dss_pwrdm");
>> +iva2_pd = pwrdm_lookup("iva2_pwrdm");
>> +sgx_pd = pwrdm_lookup("sgx_pwrdm");
>> +usb_pd = pwrdm_lookup("usbhost_pwrdm");
>>
>> omap_init_power_states();
>> cpuidle_register_driver(&omap3_idle_driver);
>> --
>> 1.7.1
>>
RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if doing so would reset an active clockdomain
>-Original Message-
>From: ext Vishwanath Sripathy [mailto:vishwanath...@ti.com]
>Sent: 19 January, 2011 08:06
>To: Kristo Tero (Nokia-MS/Tampere); linux-omap@vger.kernel.org
>Cc: Paul Walmsley; Kevin Hilman
>Subject: RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if
>doing so would reset an active clockdomain
>
>Tero,
>
>> -Original Message-
>> From: Vishwanath Sripathy [mailto:vishwanath...@ti.com]
>> Sent: Wednesday, January 19, 2011 10:09 AM
>> To: Tero Kristo; linux-omap@vger.kernel.org
>> Cc: Paul Walmsley; Kevin Hilman
>> Subject: RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if
>> doing so would reset an active clockdomain
>>
>> Tero,
>>
>> > -Original Message-
>> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>> > ow...@vger.kernel.org] On Behalf Of Tero Kristo
>> > Sent: Tuesday, January 18, 2011 3:18 PM
>> > To: linux-omap@vger.kernel.org
>> > Cc: Paul Walmsley; Kevin Hilman
>> > Subject: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if
>> doing
>> > so would reset an active clockdomain
>> >
>> > On OMAP3 SoCs, if the CORE powerdomain enters off-mode, many
>> other
>> > parts of the chip will be reset. If those parts of the chip are
>busy,
>> > the reset will disrupt them, causing unpredictable and generally
>> > undesirable results.
>> If some parts of the chip are busy, then how can Core domain enter off
>> state? The necessary condition for Core to enter low power state is
>that
>> all the clock domains (including DSS, CAM, IVA, USB, PER etc) should
>> have
>> idled. Doesn't it mean that all the modules have idled and asserted
>> idleack when Core is entering off state?
>Besides these, Core off should reset the modules which are only in Core
>domain. It should not impact other power domains. Also Core domain
>modules
>which are reset will restore their context when Core comes out of off
>mode. So why are you saying that "If those parts of the chip are busy,
>the reset will disrupt them, causing unpredictable and generally
>undesirable results."?
Core off issues reset to peripheral domains when it wakes up, this is somehow
(badly) visible in TRM (look for COREDOMAINWKUP_RST.) When this reset happens,
the peripheral domain shows its reset status as being high, but the powerdomain
itself has not entered off (previous state can be e.g. RET), thus its context
will not be restored.
Also, another justification for this patch is to prevent unnecessary core-off
when the device can't really idle at all => prevents unnecessary overhead
inside omap_sram_idle path.
>
>Vishwa
>>
>> Vishwa
>> >
>> > Signed-off-by: Tero Kristo
>> > Cc: Paul Walmsley
>> > Cc: Kevin Hilman
>> > ---
>> > arch/arm/mach-omap2/cpuidle34xx.c | 40
>> > +++-
>> > 1 files changed, 38 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-
>> > omap2/cpuidle34xx.c
>> > index f3e043f..d31b858 100644
>> > --- a/arch/arm/mach-omap2/cpuidle34xx.c
>> > +++ b/arch/arm/mach-omap2/cpuidle34xx.c
>> > @@ -61,7 +61,7 @@ struct omap3_processor_cx {
>> > struct omap3_processor_cx
>> > omap3_power_states[OMAP3_MAX_STATES];
>> > struct omap3_processor_cx current_cx_state;
>> > struct powerdomain *mpu_pd, *core_pd, *per_pd;
>> > -struct powerdomain *cam_pd;
>> > +struct powerdomain *cam_pd, *dss_pd, *iva2_pd, *sgx_pd,
>> *usb_pd;
>> >
>> > /*
>> > * The latencies/thresholds for various C states have
>> > @@ -235,7 +235,7 @@ static int omap3_enter_idle_bm(struct
>> > cpuidle_device *dev,
>> > {
>> >struct cpuidle_state *new_state = next_valid_state(dev, state);
>> >u32 core_next_state, per_next_state = 0, per_saved_state = 0;
>> > - u32 cam_state;
>> > + u32 cam_state, dss_state, iva2_state, sgx_state, usb_state;
>> >struct omap3_processor_cx *cx;
>> >int ret;
>> >
>> > @@ -256,6 +256,8 @@ static int omap3_enter_idle_bm(struct
>> > cpuidle_device *dev,
>> > *its own code.
>> > */
>> >
>> > + /* XXX Add CORE-active check here */
>> > +
>> >/*
>> > * Prevent idle completely if CAM is active.
>> > * CAM does not have wakeup capability in OMAP3.
>> > @@ -275,6 +277,36 @@ static int omap3_enter_idle_bm(struct
>> > cpuidle_device *dev,
>> >(core_next_state > PWRDM_POWER_RET))
>> >per_next_state = PWRDM_POWER_RET;
>> >
>> > + /* XXX Add prevent-PER-off check here */
>> > +
>> > + /*
>> > + * If we are attempting CORE off, check if any other
>> > powerdomains
>> > + * are at retention or higher. CORE off causes chipwide reset
>> > which
>> > + * would reset these domains also.
>> > + */
>> > + if (core_next_state == PWRDM_POWER_OFF) {
>> > + iva2_state = pwrdm_read_pwrst(iva2_pd);
>> > + sgx_state = pwrdm_read_pwrst(sgx_pd);
>> > + usb_state = pwrdm_read_pwrst(usb_pd);
>> > + dss_state = pwrdm_read_pwrst(dss_pd);
>> > +
>> > + if (cam_state > PWRDM_POWER_OFF ||
>> > +
RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if doing so would reset an active clockdomain
>-Original Message- >From: ext Santosh Shilimkar [mailto:santosh.shilim...@ti.com] >Sent: 19 January, 2011 11:03 >To: Kristo Tero (Nokia-MS/Tampere); Vishwanath Sripathy; linux- >o...@vger.kernel.org >Cc: p...@pwsan.com; khil...@deeprootsystems.com >Subject: RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if >doing so would reset an active clockdomain > >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >> ow...@vger.kernel.org] On Behalf Of tero.kri...@nokia.com >> Sent: Wednesday, January 19, 2011 2:09 PM >> To: vishwanath...@ti.com; linux-omap@vger.kernel.org >> Cc: p...@pwsan.com; khil...@deeprootsystems.com >> Subject: RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if >> doing so would reset an active clockdomain >> >[...] > >> >> If some parts of the chip are busy, then how can Core domain >> enter off >> >> state? The necessary condition for Core to enter low power state >> is >> >that >> >> all the clock domains (including DSS, CAM, IVA, USB, PER etc) >> should >> >> have >> >> idled. Doesn't it mean that all the modules have idled and >> asserted >> >> idleack when Core is entering off state? >> >Besides these, Core off should reset the modules which are only in >> Core >> >domain. It should not impact other power domains. Also Core domain >> >modules >> >which are reset will restore their context when Core comes out of >> off >> >mode. So why are you saying that "If those parts of the chip are >> busy, >> >the reset will disrupt them, causing unpredictable and generally >> >undesirable results."? >> >> Core off issues reset to peripheral domains when it wakes up, this >> is somehow (badly) visible in TRM (look for COREDOMAINWKUP_RST.) >> When this reset happens, the peripheral domain shows its reset >> status as being high, but the powerdomain itself has not entered off >> (previous state can be e.g. RET), thus its context will not be >> restored. >> >Now its clear. Reseting other independent clockdomains is >certainly bad from CORE PD OFF to ON behavior . > >Please add this additional information to change log. I'll update the patch desc and resend it in a bit. -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: [PATCH] OMAP3: PM: fix save secure RAM to restore MPU power state
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@ti.com]
>Sent: 26 January, 2011 02:50
>To: linux-omap@vger.kernel.org
>Cc: linux-arm-ker...@lists.infradead.org; Kristo Tero (Nokia-MS/Tampere)
>Subject: [PATCH] OMAP3: PM: fix save secure RAM to restore MPU power
>state
>
>Currently, on HS/EMU devices, MPU power state forced to on during PM
>init by the save secure RAM code. Rather than forcing the state of
>MPU powerdomain to on, simply read the current value and restore it
>after the ROM code has run.
>
>This only affects the !CPUidle case since when CPUidle is enabled, the
>MPU power state is dynamically changed by CPUidle. In the !CPUidle
>case, MPU power state is initialized once at init and never touched.
>
>Cc: Tero Kristo
>Signed-off-by: Kevin Hilman
>---
>If no objectsions, will be queued in my pm-fixes branch for 2.6.38-rc.
Looks good to me. Ack, if you need one.
>
> arch/arm/mach-omap2/pm34xx.c |7 ---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
>diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>index 8cbbead..1916038 100644
>--- a/arch/arm/mach-omap2/pm34xx.c
>+++ b/arch/arm/mach-omap2/pm34xx.c
>@@ -168,9 +168,10 @@ static void omap3_core_restore_context(void)
> * once during boot sequence, but this works as we are not using secure
> * services.
> */
>-static void omap3_save_secure_ram_context(u32 target_mpu_state)
>+static void omap3_save_secure_ram_context(void)
> {
> u32 ret;
>+ int mpu_next_state = pwrdm_read_next_pwrst(mpu_pwrdm);
>
> if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
> /*
>@@ -181,7 +182,7 @@ static void omap3_save_secure_ram_context(u32
>target_mpu_state)
> pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
> ret = _omap_save_secure_sram((u32 *)
> __pa(omap3_secure_ram_storage));
>- pwrdm_set_next_pwrst(mpu_pwrdm, target_mpu_state);
>+ pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state);
> /* Following is for error tracking, it should not happen */
> if (ret) {
> printk(KERN_ERR "save_secure_sram() returns %08x\n",
>@@ -1094,7 +1095,7 @@ static int __init omap3_pm_init(void)
> local_fiq_disable();
>
> omap_dma_global_context_save();
>- omap3_save_secure_ram_context(PWRDM_POWER_ON);
>+ omap3_save_secure_ram_context();
> omap_dma_global_context_restore();
>
> local_irq_enable();
>--
>1.7.3.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap: dmtimer: Enable autoidle
>-Original Message- >From: ext Kevin Hilman [mailto:khil...@ti.com] >Sent: 15 February, 2011 01:29 >To: Kristo Tero (Nokia-MS/Tampere) >Cc: linux-omap@vger.kernel.org >Subject: Re: [PATCH] omap: dmtimer: Enable autoidle > >Tero Kristo writes: > >> This will save some power. >> >> Signed-off-by: Tero Kristo > >Please report which platforms this was tested with. Tested only on OMAP3. Should this be changed to apply only on that one? I don't know about OMAP4, but I think this should work on OMAP2 at least based on spec. > >Also, please Cc linux-arm-kernel. > >Thanks, > >Kevin > >> --- >> arch/arm/plat-omap/dmtimer.c |1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat- >omap/dmtimer.c >> index 1d706cf..949becc 100644 >> --- a/arch/arm/plat-omap/dmtimer.c >> +++ b/arch/arm/plat-omap/dmtimer.c >> @@ -341,6 +341,7 @@ static void omap_dm_timer_reset(struct >omap_dm_timer *timer) >> l = omap_dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG); >> l |= 0x02 << 3; /* Set to smart-idle mode */ >> l |= 0x2 << 8; /* Set clock activity to perserve f-clock on idle >*/ >> +l |= 0x1 << 0; /* Set autoidle */ >> >> /* >> * Enable wake-up on OMAP2 CPUs. -- To unsubscribe from this list: send the line "unsubscribe 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: dmtimer: Enable autoidle
>-Original Message- >From: ext DebBarma, Tarun Kanti [mailto:tarun.ka...@ti.com] >Sent: 15 February, 2011 11:31 >To: Kristo Tero (Nokia-MS/Tampere); Hilman, Kevin >Cc: linux-omap@vger.kernel.org >Subject: RE: [PATCH] omap: dmtimer: Enable autoidle > >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >> ow...@vger.kernel.org] On Behalf Of DebBarma, Tarun Kanti >> Sent: Tuesday, February 15, 2011 2:50 PM >> To: tero.kri...@nokia.com; Hilman, Kevin >> Cc: linux-omap@vger.kernel.org >> Subject: RE: [PATCH] omap: dmtimer: Enable autoidle >> >> > -Original Message- >> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >> > ow...@vger.kernel.org] On Behalf Of tero.kri...@nokia.com >> > Sent: Tuesday, February 15, 2011 1:47 PM >> > To: Hilman, Kevin >> > Cc: linux-omap@vger.kernel.org >> > Subject: RE: [PATCH] omap: dmtimer: Enable autoidle >> > >> > >> > >> > >-Original Message- >> > >From: ext Kevin Hilman [mailto:khil...@ti.com] >> > >Sent: 15 February, 2011 01:29 >> > >To: Kristo Tero (Nokia-MS/Tampere) >> > >Cc: linux-omap@vger.kernel.org >> > >Subject: Re: [PATCH] omap: dmtimer: Enable autoidle >> > > >> > >Tero Kristo writes: >> > > >> > >> This will save some power. >> > >> >> > >> Signed-off-by: Tero Kristo >> > > >> > >Please report which platforms this was tested with. >> > >> > Tested only on OMAP3. >> > >> > Should this be changed to apply only on that one? I don't know about >> > OMAP4, but I think this should work on OMAP2 at least based on spec. >> It works on OMAP2 and OMAP4. >Ok, on OMAP4 I should have clarified further. >AUTOIDLE is present only for millisecond timers: 1,2,10. >The reset of the timers do not have this bit. Does it matter if the bit is set on the timers that don't have it or does the HW just ignore it? Or should we enumerate the timers that support it on omap4? >-- >Tarun > >> >> > >> > >> > > >> > >Also, please Cc linux-arm-kernel. >> > > >> > >Thanks, >> > > >> > >Kevin >> > > >> > >> --- >> > >> arch/arm/plat-omap/dmtimer.c |1 + >> > >> 1 files changed, 1 insertions(+), 0 deletions(-) >> > >> >> > >> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat- >> > >omap/dmtimer.c >> > >> index 1d706cf..949becc 100644 >> > >> --- a/arch/arm/plat-omap/dmtimer.c >> > >> +++ b/arch/arm/plat-omap/dmtimer.c >> > >> @@ -341,6 +341,7 @@ static void omap_dm_timer_reset(struct >> > >omap_dm_timer *timer) >> > >> l = omap_dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG); >> > >> l |= 0x02 << 3; /* Set to smart-idle mode */ >> > >> l |= 0x2 << 8; /* Set clock activity to perserve f-clock >on >> idle >> > >*/ >> > >> + l |= 0x1 << 0; /* Set autoidle */ >> > >> >> > >> /* >> > >> * Enable wake-up on OMAP2 CPUs. >> > -- >> > To unsubscribe from this list: send the line "unsubscribe 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 -- To unsubscribe from this list: send the line "unsubscribe 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: dmtimer: Enable autoidle
>-Original Message- >From: ext DebBarma, Tarun Kanti [mailto:tarun.ka...@ti.com] >Sent: 15 February, 2011 11:52 >To: Kristo Tero (Nokia-MS/Tampere); Hilman, Kevin >Cc: linux-omap@vger.kernel.org >Subject: RE: [PATCH] omap: dmtimer: Enable autoidle > >[...] >> >> > >> >> > Should this be changed to apply only on that one? I don't know >about >> >> > OMAP4, but I think this should work on OMAP2 at least based on >spec. >> >> It works on OMAP2 and OMAP4. >> >Ok, on OMAP4 I should have clarified further. >> >AUTOIDLE is present only for millisecond timers: 1,2,10. >> >The reset of the timers do not have this bit. >> >> Does it matter if the bit is set on the timers that don't have it or >does >> the HW just ignore it? Or should we enumerate the timers that support >it >> on omap4? >For other timers it happens to be SOFTRESET bit. So HW would not ignore. Ok, so this one should only be implemented for omap2/3 or added logic is needed for omap4. >-- >Tarun >> >> >> >> > >> >> > >> >> > > >> >> > >Also, please Cc linux-arm-kernel. >> >> > > >> >> > >Thanks, >> >> > > >> >> > >Kevin >> >> > > >> >> > >> --- >> >> > >> arch/arm/plat-omap/dmtimer.c |1 + >> >> > >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> > >> >> >> > >> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat- >> >> > >omap/dmtimer.c >> >> > >> index 1d706cf..949becc 100644 >> >> > >> --- a/arch/arm/plat-omap/dmtimer.c >> >> > >> +++ b/arch/arm/plat-omap/dmtimer.c >> >> > >> @@ -341,6 +341,7 @@ static void omap_dm_timer_reset(struct >> >> > >omap_dm_timer *timer) >> >> > >> l = omap_dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG); >> >> > >> l |= 0x02 << 3; /* Set to smart-idle mode */ >> >> > >> l |= 0x2 << 8; /* Set clock activity to perserve f-clock >> >on >> >> idle >> >> > >*/ >> >> > >> +l |= 0x1 << 0; /* Set autoidle */ >> >> > >> >> >> > >> /* >> >> > >> * Enable wake-up on OMAP2 CPUs. >> >> > -- >> >> > To unsubscribe from this list: send the line "unsubscribe 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 -- To unsubscribe from this list: send the line "unsubscribe 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] OMAP3: add support for 2 SDRAM chip selects (was: Re: Beagleboard rev C memory timings & suspend/resume)
>-Original Message-
>From: ext Paul Walmsley [mailto:p...@pwsan.com]
>Sent: 05 June, 2009 21:11
>To: Jean Pihet; Kristo Tero (Nokia-D/Tampere)
>Cc: Kevin Hilman; linux-omap
>Subject: Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip
>selects (was: Re: Beagleboard rev C memory timings & suspend/resume)
>
>Hi Jean,
>
>On Fri, 5 Jun 2009, Jean Pihet wrote:
>
>> Here is the new patch that includes all the remarks and suggestion.
>> The description is here below.
>>
>> Some notes:
>> - all calls to omap2_init_common_hw have been adapted in the board
>> files. it looks like 2430SDP and Pandora board files are
>broken since
>> they use only one param. Can that be checked on those boards?
>> - it is assumed that RX51 only uses 1 CS. Is that correct?
>>
>> Can you review it and possibly merge?
>
>Looks great.
>
>Tero, does RX51 use two SDRC chipselects!
Yes, I'll take a look at this and post a patch on top of this. I did this for
the earlier version already, but need to re-check this one.
-Tero
>
>Acked-by: Paul Walmsley
>
>
>>
>> Thanks & regards,
>> Jean
>>
>> --
>> From 097a640997b74638e0e7200ecd5834205204c956 Mon Sep 17
>00:00:00 2001
>> From: Jean Pihet
>> Date: Fri, 5 Jun 2009 17:19:00 +0200
>> Subject: [PATCH] [PATCH] OMAP3: add support for 2 SDRAM chip selects
>>
>> Some boards (Beagle Cx, Overo) have 2 SDRAM parts connected to the
>> SDRC.
>>
>> This patch adds the following:
>> - ensure that the CKE signals mux settings are correct
>> - add a new argument of type omap_sdrc_params struct* to
>> omap2_init_common_hw and omap2_sdrc_init for the 2nd CS params
>> - adapted the OMAP boards files to the new prototype of
>> omap2_init_common_hw. Only Beagle and Overo are using the 2 CS'es
>> - adapt the sram sleep code to configure the SDRC for the 2nd CS
>>
>> Note: If the 2nd param to omap2_init_common_hw is NULL, then the
>> parameters are not programmed into the SDRC CS1 registers
>>
>> Tested on 3430 SDP and Beagleboard rev C2 and B5, with
>suspend/resume
>> and frequency changes (cpufreq).
>>
>> Thanks to Paul Walmsley and Kevin Hilman for the suggestions
>and code
>> reviews.
>>
>> Signed-off-by: Jean Pihet
>> ---
>> arch/arm/mach-omap2/board-2430sdp.c |2 +-
>> arch/arm/mach-omap2/board-3430sdp.c |6 +-
>> arch/arm/mach-omap2/board-apollon.c |2 +-
>> arch/arm/mach-omap2/board-generic.c |2 +-
>> arch/arm/mach-omap2/board-h4.c |2 +-
>> arch/arm/mach-omap2/board-ldp.c |2 +-
>> arch/arm/mach-omap2/board-n800.c |2 +-
>> arch/arm/mach-omap2/board-omap2evm.c |2 +-
>> arch/arm/mach-omap2/board-omap3beagle.c | 11 ++-
>> arch/arm/mach-omap2/board-omap3evm.c |6 +-
>> arch/arm/mach-omap2/board-omap3pandora.c |3 +-
>> arch/arm/mach-omap2/board-overo.c|8 ++-
>> arch/arm/mach-omap2/board-rx51.c |6 +-
>> arch/arm/mach-omap2/clock34xx.c | 37 ++--
>> arch/arm/mach-omap2/io.c |5 +-
>> arch/arm/mach-omap2/mux.c|6 ++
>> arch/arm/mach-omap2/sdrc.c | 63 +-
>> arch/arm/mach-omap2/sram34xx.S | 137
>> +++---
>> arch/arm/plat-omap/include/mach/io.h |3 +-
>> arch/arm/plat-omap/include/mach/mux.h|4 +
>> arch/arm/plat-omap/include/mach/sdrc.h |8 +-
>> arch/arm/plat-omap/include/mach/sram.h | 23 +++--
>> arch/arm/plat-omap/sram.c| 34 +---
>> 23 files changed, 266 insertions(+), 108 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-2430sdp.c
>> b/arch/arm/mach-omap2/board-2430sdp.c
>> index aa5df72..4cb7bc5 100644
>> --- a/arch/arm/mach-omap2/board-2430sdp.c
>> +++ b/arch/arm/mach-omap2/board-2430sdp.c
>> @@ -322,7 +322,7 @@ out:
>>
>> static void __init omap_2430sdp_init_irq(void) {
>> -omap2_init_common_hw(NULL);
>> +omap2_init_common_hw(NULL, NULL, NULL, NULL, NULL);
>> omap_init_irq();
>> omap_gpio_init();
>> sdp2430_init_smc91x();
>> diff --git a/arch/arm/mach-omap2/board-3430sdp.c
>> b/arch/arm/mach-omap2/board-3430sdp.c
>> index 195b749..24e2728 100644
>> --- a/arch/arm/mach-omap2/board-3430sdp.c
>> +++ b/arch/arm/mach-omap2/board-3430sdp.c
>> @@ -302,8 +302,10 @@ static inline void __init
>> sdp3430_init_smc91x(void)
>>
>> static void __init omap_3430sdp_init_irq(void) {
>> -omap2_init_common_hw(hyb18m512160af6_sdrc_params,
>omap3_mpu_rate_table,
>> - omap3_dsp_rate_table, omap3_l3_rate_table);
>> +omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL,
>> + omap3_mpu_rate_table,
>> + omap3_dsp_rate_table,
>> + omap3_l3_rate_table);
>> omap_init_irq();
>> omap_gpio_init();
>> sdp3430_init_smc91x();
>> diff --git a/arch/arm/mach-omap2/board-apollon.c
>> b/arch/arm/mach-omap2/board-apollon.c
>> index 2e24812..2dd1350 100644
>> --- a/arch/arm/mach-omap2/boa
RE: [PATCH] RX51: Add support for SDRAM chip select 1
>-Original Message-
>From: ext Jean Pihet [mailto:jpi...@mvista.com]
>Sent: 08 June, 2009 16:06
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH] RX51: Add support for SDRAM chip select 1
>
>Hi Tero,
>
>You should also ensure that the CKE signals mux settings are
>correct cf. an example for Overo at
>http://patchwork.kernel.org/patch/28598/.
Our bootloader configures the pads, I just double checked that it also changes
CKE pads to proper config.
The patch looks good otherwise? I tested this on RX51 HW and it works ok.
-Tero
>
>Note: the config option CONFIG_OMAP_MUX must be set for the
>omap_cfg* functions to have any effect.
>
>Regards,
>Jean
>
>On Monday 08 June 2009 14:03:23 Tero Kristo wrote:
>> From: Tero Kristo
>>
>> Applies on top of PM branch.
>>
>> Signed-off-by: Tero Kristo
>> ---
>> arch/arm/mach-omap2/board-rx51.c |6 +-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-rx51.c
>> b/arch/arm/mach-omap2/board-rx51.c index 3e4b7f8..7ab8a74 100644
>> --- a/arch/arm/mach-omap2/board-rx51.c
>> +++ b/arch/arm/mach-omap2/board-rx51.c
>> @@ -61,7 +61,11 @@ static struct omap_bluetooth_config
>rx51_bt_config
>> = {
>>
>> static void __init rx51_init_irq(void) {
>> -omap2_init_common_hw(rx51_get_sdram_timings(), NULL,
>> +struct omap_sdrc_params *sdrc_params;
>> +
>> +sdrc_params = rx51_get_sdram_timings();
>> +
>> +omap2_init_common_hw(sdrc_params, sdrc_params,
>> omap3_mpu_rate_table,
>> omap3_dsp_rate_table,
>> omap3_l3_rate_table);
>
>
>--
To unsubscribe from this list: send the line "unsubscribe 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] OMAP3: add support for 2 SDRAM chip selects
>-Original Message- >From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: 08 June, 2009 20:24 >To: Jean Pihet >Cc: Paul Walmsley; Kristo Tero (Nokia-D/Tampere); linux-omap >Subject: Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects > >Jean Pihet writes: > >> On Monday 08 June 2009 16:59:36 Kevin Hilman wrote: >>> Jean Pihet writes: >>> > Paul, >>> > >>> > Here is the updated patch that fixes the Overo build as well. >>> > Can you check it? >>> > >>> > Kevin, can you push it if it is correct? >>> >>> Can you run it through checkpatch, fix the errors and also merge >>> Tero's >>> RX51 patch if it looks good to you. >> Ok. I will check. The cause might be the mailer. >> >> I think we need the omap_cfg_reg calls in the RX51 board >file as well, >> even if the bootloader has the mux setting already right. That way a >> warning will be issued in case of a faulty bootloader. Do you agree? > >I agree. Well, this is ok for me too as it does not really change anything. I will voice my opinion here though. :) I find it somewhat weird that we take care of two pads in this fashion out of ~350 or so, where in most cases we just assume that the pads are configured properly by the boot loader. Should we do the same for every pad? Does the kernel even boot if the CKE signals are configured incorrectly? I would guess the boot loader will fail to load the kernel image into SDRAM in that case. -Tero > >Kevin > >>> >>> Below are the checkpatch errors I get: looks lik your mailer is >>> probably wrapping the patch and there is also one error to fix. >>> >>> Kevin >> >> Regards, >> Jean >>> >>> ERROR: patch seems to be corrupt (line wrapped?) >>> #306: FILE: arch/arm/mach-omap2/clock34xx.c:477: >>> unsigned long rate) >>> >>> ERROR: trailing whitespace >>> #494: FILE: arch/arm/mach-omap2/sdrc.c:128: >>> + * @sdrc_cs[01]: pointers to a null-terminated list of struct $ >>> >>> total: 2 errors, 0 warnings, 648 lines checked >>> >>> Your patch has style problems, please review. If any of >these errors >>> are false positives report them to the maintainer, see >CHECKPATCH in >>> MAINTAINERS. >>> >>> > Regards, >>> > Jean >>> > >>> > From ebe57354b0de059e1f042e0c488f761853f0 Mon Sep 17 00:00:00 >>> > 2001 >>> > From: Jean Pihet >>> > Date: Fri, 5 Jun 2009 17:19:00 +0200 >>> > Subject: OMAP3: add support for 2 SDRAM chip selects >>> > >>> > Some boards (Beagle Cx, Overo) have 2 SDRAM parts >connected to the >>> > SDRC. >>> > >>> > This patch adds the following: >>> > - ensure that the CKE signals mux settings are correct >>> > - add a new argument of type omap_sdrc_params struct* to >>> > omap2_init_common_hw and omap2_sdrc_init for the 2nd CS params >>> > - adapted the OMAP boards files to the new prototype of >>> > omap2_init_common_hw. Only Beagle and Overo are using the 2 CS'es >>> > - adapt the sram sleep code to configure the SDRC for the 2nd CS >>> > >>> > Note: If the 2nd param to omap2_init_common_hw is NULL, then the >>> > parameters are not programmed into the SDRC CS1 registers >>> > >>> > Tested on 3430 SDP and Beagleboard rev C2 and B5, with >>> > suspend/resume and frequency changes (cpufreq). >>> > >>> > Thanks to Paul Walmsley and Kevin Hilman for the suggestions and >>> > code reviews. >>> > >>> > Signed-off-by: Jean Pihet >>> > --- >>> > arch/arm/mach-omap2/board-2430sdp.c |2 +- >>> > arch/arm/mach-omap2/board-3430sdp.c |6 +- >>> > arch/arm/mach-omap2/board-apollon.c |2 +- >>> > arch/arm/mach-omap2/board-generic.c |2 +- >>> > arch/arm/mach-omap2/board-h4.c |2 +- >>> > arch/arm/mach-omap2/board-ldp.c |2 +- >>> > arch/arm/mach-omap2/board-n800.c |2 +- >>> > arch/arm/mach-omap2/board-omap2evm.c |2 +- >>> > arch/arm/mach-omap2/board-omap3beagle.c | 11 ++- >>> > arch/arm/mach-omap2/board-omap3evm.c |6 +- >>> > arch/arm/mach-omap2/board-omap3pandora.c |3 +- >>> > arch/arm/mach-omap2/board-overo.c|9 ++- >>> > arch/arm/mach-omap2/board-rx51.c |6 +- >>> > arch/arm/mach-omap2/clock34xx.c | 37 ++-- >>> > arch/arm/mach-omap2/io.c |5 +- >>> > arch/arm/mach-omap2/mux.c|6 ++ >>> > arch/arm/mach-omap2/sdrc.c | 63 +- >>> > arch/arm/mach-omap2/sram34xx.S | 137 >>> > +++--- >>> > arch/arm/plat-omap/include/mach/io.h |3 +- >>> > arch/arm/plat-omap/include/mach/mux.h|4 + >>> > arch/arm/plat-omap/include/mach/sdrc.h |8 +- >>> > arch/arm/plat-omap/include/mach/sram.h | 23 +++-- >>> > arch/arm/plat-omap/sram.c| 34 +--- >>> > 23 files changed, 267 insertions(+), 108 deletions(-) >>> > >>> > diff --git a/arch/arm/mach-omap2/board-2430sdp.c >>> > b/arch/arm/mach-omap2/board-2430sdp.c >>> > index aa5df72..4cb7bc5 100644 >>> > --- a/arch/arm/mach-omap2/board-2430sdp.c >>> > +++ b/arch/a
RE: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects
>-Original Message- >From: ext Jean Pihet [mailto:jpi...@mvista.com] >Sent: 09 June, 2009 11:24 >To: Kristo Tero (Nokia-D/Tampere) >Cc: khil...@deeprootsystems.com; p...@pwsan.com; >linux-omap@vger.kernel.org >Subject: Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects > >On Tuesday 09 June 2009 10:14:58 tero.kri...@nokia.com wrote: >> >-Original Message- >> >From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] >> >Sent: 08 June, 2009 20:24 >> >To: Jean Pihet >> >Cc: Paul Walmsley; Kristo Tero (Nokia-D/Tampere); linux-omap >> >Subject: Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM >chip selects >> > >> >Jean Pihet writes: >> >> On Monday 08 June 2009 16:59:36 Kevin Hilman wrote: >> >>> Jean Pihet writes: >> >>> > Paul, >> >>> > >> >>> > Here is the updated patch that fixes the Overo build as well. >> >>> > Can you check it? >> >>> > >> >>> > Kevin, can you push it if it is correct? >> >>> >> >>> Can you run it through checkpatch, fix the errors and also merge >> >>> Tero's >> >>> RX51 patch if it looks good to you. >> >> >> >> Ok. I will check. The cause might be the mailer. >> >> >> >> I think we need the omap_cfg_reg calls in the RX51 board >> > >> >file as well, >> > >> >> even if the bootloader has the mux setting already right. >That way >> >> a warning will be issued in case of a faulty bootloader. >Do you agree? >> > >> >I agree. >> >> Well, this is ok for me too as it does not really change anything. I >> will voice my opinion here though. :) >> >> I find it somewhat weird that we take care of two pads in >this fashion >> out of ~350 or so, where in most cases we just assume that the pads >> are configured properly by the boot loader. Should we do the >same for >> every pad? >Got your point. This omap_cfg_reg throws a warning if the pad >is incorrectly configured. The goal is to better track the >problem in case of a wrong/older bootloader. In the ideal >world the bootloader and kernel should match and do it all right! > >> Does the kernel even boot if the CKE signals are configured >> incorrectly? I would guess the boot loader will fail to load the >> kernel image into SDRAM in that case. >The kernel boots fine in that case, only the SDRAM contents >are not preserved when going to low power mode. Ok, in this case it sounds ok to me also as it might generate hard to track bugs. -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: [PATCH 0/2] adding back some features
>-Original Message-
>From: ext Tony Lindgren [mailto:t...@atomide.com]
>Sent: 17 June, 2009 12:58
>To: Paul Walmsley
>Cc: Kristo Tero (Nokia-D/Tampere); Kevin Hilman;
>linux-omap@vger.kernel.org
>Subject: Re: [PATCH 0/2] adding back some features
>
>* Paul Walmsley [090617 01:35]:
>> code comment below:
>>
>> On Wed, 17 Jun 2009, Tony Lindgren wrote:
>>
>> > * Kevin Hilman [090615 09:05]:
>> > > Kevin Hilman writes:
>> > >
>> > > > Tony Lindgren writes:
>> > > >
>> > > >> Hi,
>> > > >>
>> > > >> * Kevin Hilman [090612 15:13]:
>> > > >>> Here's a couple patches to add-back some feature dropped in
>> > > >>> the mainline sync. These are needed for the PM
>branch among other things.
>> > > >>>
>> > > >>> Applies to linux-omap master.
>> > > >>>
>> > > >>> Kevin Hilman (1):
>> > > >>> OMAP2/3: SoC IDs: add omap_type() for determining GP/EMU/HS
>> > > >>
>> > > >> Is there any reason to get this one into mainline early?
>> > > >
>> > > > Well, the PM branch has a dependency, but also the recenetly
>> > > > submitted qwatchdog driver has a dependency.
>> > > >
>> > > >> If not, I suggest you keep this in your pm branch for next
>> > > >> merge window that I can keep merging to l-o master as needed.
>> > > >>
>> > > >> However, if omap_type() is by other queues earlier,
>then I can
>> > > >> add it into my upstream queue. If this blocks several queues
>> > > >> from being rebased against mainline kernel, that alone might
>> > > >> already be a good enough reason to get it in early.
>> > > >
>> > > > I think it should go via your upstream queue. I
>imagine some of
>> > > > the other upcoming driver submissions from TI will have a
>> > > > dependency as well since there is still some missing
>EMU/HS support ind drivers.
>> > >
>> > > Also, I'm carrying this SRAM patch below for HS/EMU that
>could go
>> > > into Paul's SRAM/SDRC queue if this omap_type() gets
>merged sooner
>> > > rather than later.
>> >
>> > Hmm, the HS omap sram.c patch below for sure justifies
>fixing it as
>> > incorrect SRAM size can cause nasty bugs.
>> >
>> > Will add both omap_type and the sram.c patch below to omap-fixes.
>> >
>> > Regards,
>> >
>> > Tony
>> >
>> > > Kevin
>> > >
>> > > commit 106588e30f070d9a8d5906d409e0b9aad89edc9e
>> > > Author: Tero Kristo
>> > > Date: Thu Oct 9 17:47:02 2008 +0300
>> > >
>> > > OMAP3: SRAM size fix for HS/EMU devices
>> > >
>> > > Signed-off-by: Tero Kristo
>> > > Signed-off-by: Kevin Hilman
>> > >
>> > > diff --git a/arch/arm/plat-omap/sram.c
>b/arch/arm/plat-omap/sram.c
>> > > old mode 100644 new mode 100755 index 65006df..f40bd2d
>> > > --- a/arch/arm/plat-omap/sram.c
>> > > +++ b/arch/arm/plat-omap/sram.c
>> > > @@ -131,9 +131,15 @@ void __init omap_detect_sram(void)
>> > > if (cpu_class_is_omap2()) {
>> > > if (is_sram_locked()) {
>> > > if (cpu_is_omap34xx()) {
>> > > -omap_sram_base =
>OMAP3_SRAM_PUB_VA;
>> > > -omap_sram_start =
>OMAP3_SRAM_PUB_PA;
>> > > -omap_sram_size =
>0x8000; /* 32K */
>> > > +if (omap_type() ==
>OMAP2_DEVICE_TYPE_GP) {
>> > > +omap_sram_base
>= OMAP3_SRAM_PUB_VA;
>> > > +omap_sram_start
>= OMAP3_SRAM_PUB_PA;
>> > > +omap_sram_size
>= 0x8000; /* 32K */
>> > > +} else {
>>
>> This would be better if it specifically tested for HS and
>EMU devices.
>> There are at least two other omap_type() possibilities here, "TEST"
>> and "BAD"
>
>Tero, can you please repost? I will hold on sending out the
>omap-fixes for that, and refresh omap-fixes with the updated patch.
I'll try to look at this tomorrow if I happen to have time, I am currently
quite busy fixing some bugs in our code base. However, if you need it right now
and if someone wants to re-write this to check against TEST and BAD, I am of
course okay with that (rather simple fix actually.) :)
-Tero
>
>Tony
>
>
>> > > +omap_sram_base
>= OMAP3_SRAM_PUB_VA;
>> > > +omap_sram_start
>= OMAP3_SRAM_PUB_PA;
>> > > +omap_sram_size
>= 0x7000; /* 28K */
>> > > +}
>> > > } else {
>> > > omap_sram_base =
>OMAP2_SRAM_PUB_VA;
>> > > omap_sram_start =
>OMAP2_SRAM_PUB_PA;
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe
>> > linux-omap" in the body of a message to majord...@vger.kernel.org
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >
>>
>>
>> - Paul
>--
To unsubscribe from this list: send the line "unsubscribe linux-oma
RE: [PATCH] PM OMAP3: Change omap3_save_secure_ram to be called only during init
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 13 August, 2009 17:17
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH] PM OMAP3: Change omap3_save_secure_ram to
>be called only during init
>
>Tero Kristo writes:
>
>> This function is now called only once during the
>initialization of the device
>> and consequent sleep cycles will re-use the same saved
>contents for secure
>> RAM. Users who need secure services should do secure RAM
>saving before
>> entering off-mode, if a secure service has been accessed
>after last save.
>>
>> Signed-off-by: Tero Kristo
>
>You explain what you're doing, but you don't explain why.
>
>Is there a large latency involved in this save/restore that you're
>trying to eliminate for the no-secure-services case?
There are both latency and reliability issues. The context save uses a hardware
resource which takes an order of hundreds of milliseconds to initialize after a
wake up from off-mode, and also there is no way of checking whether it is ready
from kernel side or not. It just crashes if you use it too quickly.
>
>Kevin
>
>> ---
>> arch/arm/mach-omap2/pm34xx.c | 19 ++-
>> 1 files changed, 18 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c
>b/arch/arm/mach-omap2/pm34xx.c
>> index 4223622..b8cf5f2 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -127,6 +127,12 @@ static void omap3_core_restore_context(void)
>> omap_dma_global_context_restore();
>> }
>>
>> +/*
>> + * FIXME: This function should be called before entering
>off-mode after
>> + * OMAP3 secure services have been accessed. Currently it
>is only called
>> + * once during boot sequence, but this works as we are not
>using secure
>> + * services.
>> + */
>> static void omap3_save_secure_ram_context(u32 target_mpu_state)
>> {
>> u32 ret;
>> @@ -349,7 +355,6 @@ void omap_sram_idle(void)
>> OMAP3_PRM_VOLTCTRL_OFFSET);
>> omap3_core_save_context();
>> omap3_prcm_save_context();
>> -omap3_save_secure_ram_context(mpu_next_state);
>> }
>> /* Enable IO-PAD wakeup */
>> prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
>> @@ -923,6 +928,18 @@ int __init omap3_pm_init(void)
>> }
>> omap3_save_scratchpad_contents();
>>
>> +if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
>> +local_irq_disable();
>> +local_fiq_disable();
>> +
>> +omap_dma_global_context_save();
>> +omap3_save_secure_ram_context(PWRDM_POWER_ON);
>> +omap_dma_global_context_restore();
>> +
>> +local_irq_enable();
>> +local_fiq_enable();
>> +}
>> +
>> err1:
>> return ret;
>> err2:
>> --
>> 1.5.4.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 07/10 V3] omap3: clk: use pm accessor functions for cpufreq table
Hi,
One comment below.
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org
>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext
>Nishanth Menon
>Sent: 25 November, 2009 06:09
>To: linux-omap
>Cc: Nishanth Menon; Benoit Cousson; Kevin Hilman; Madhusudhan
>Chikkature Rajashekar; Paul Walmsley; Romit Dasgupta; Sanjeev
>Premi; Santosh Shilimkar; Sergio Alberto Aguirre Rodriguez;
>Thara Gopinath; Vishwanath Sripathy
>Subject: [PATCH 07/10 V3] omap3: clk: use pm accessor
>functions for cpufreq table
>
>omap2_clk_init_cpufreq_table currently directly accesses the opp
>table, making it unscalable to various OMAPs. Instead use the
>accessor functions to populate the cpufreq table
>
>Cc: Benoit Cousson
>Cc: Kevin Hilman
>Cc: Madhusudhan Chikkature Rajashekar
>Cc: Paul Walmsley
>Cc: Romit Dasgupta
>Cc: Sanjeev Premi
>Cc: Santosh Shilimkar
>Cc: Sergio Alberto Aguirre Rodriguez
>Cc: Thara Gopinath
>Cc: Vishwanath Sripathy
>
>Signed-off-by: Nishanth Menon
>---
> arch/arm/mach-omap2/clock34xx.c | 32
>+++-
> 1 files changed, 19 insertions(+), 13 deletions(-)
>
>diff --git a/arch/arm/mach-omap2/clock34xx.c
>b/arch/arm/mach-omap2/clock34xx.c
>index 5150939..d07f1c1 100644
>--- a/arch/arm/mach-omap2/clock34xx.c
>+++ b/arch/arm/mach-omap2/clock34xx.c
>@@ -1042,30 +1042,36 @@ static unsigned long
>omap3_clkoutx2_recalc(struct clk *clk)
> #if defined(CONFIG_ARCH_OMAP3)
>
> #ifdef CONFIG_CPU_FREQ
>-static struct cpufreq_frequency_table freq_table[MAX_VDD1_OPP+1];
>+
>+static struct cpufreq_frequency_table *freq_table;
>
> void omap2_clk_init_cpufreq_table(struct
>cpufreq_frequency_table **table)
> {
>- struct omap_opp *prcm;
> int i = 0;
>+ u8 opp_num;
>+ struct omap_opp *opp = NULL;
>+ unsigned long freq = ULONG_MAX;
>
>- if (!mpu_opps)
>+ if (!mpu_opps || opp_get_opp_count(&opp_num, mpu_opps)) {
>+ pr_warning("%s: failed to initialize frequency"
>+ "table\n", __func__);
> return;
>-
>- prcm = mpu_opps + MAX_VDD1_OPP;
>- for (; prcm->rate; prcm--) {
>- freq_table[i].index = i;
>- freq_table[i].frequency = prcm->rate / 1000;
>- i++;
> }
>
>- if (i == 0) {
>- printk(KERN_WARNING "%s: failed to initialize
>frequency \
>-
>table\n",
>-
>__func__);
>+ freq_table = kmalloc(sizeof(struct cpufreq_frequency_table) *
>+ (opp_num + 1), GFP_KERNEL);
I guess this should be GFP_ATOMIC, we have clockfw spinlock reserved when this
is called (gave me a runtime warning.)
>+ if (!freq_table) {
>+ pr_warning("%s: failed to allocate frequency"
>+ "table\n", __func__);
> return;
> }
>
>+ while (!opp_get_lower_opp(&opp, &freq, mpu_opps)) {
>+ freq_table[i].index = i;
>+ freq_table[i].frequency = freq / 1000;
>+ i++;
>+ }
>+
> freq_table[i].index = i;
> freq_table[i].frequency = CPUFREQ_TABLE_END;
>
>--
>1.6.3.3
>
>--
>To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 04/10 V3] omap3: pm: srf: use opp accessor functions
Hi, Couple of comments below. >-Original Message- >From: linux-omap-ow...@vger.kernel.org >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext >Nishanth Menon >Sent: 25 November, 2009 06:09 >To: linux-omap >Cc: Nishanth Menon; Benoit Cousson; Kevin Hilman; Madhusudhan >Chikkature Rajashekar; Paul Walmsley; Romit Dasgupta; Sanjeev >Premi; Santosh Shilimkar; Sergio Alberto Aguirre Rodriguez; >Thara Gopinath; Vishwanath Sripathy >Subject: [PATCH 04/10 V3] omap3: pm: srf: use opp accessor functions > >With the accessor functions, many of the direct accesses are >redundant. However we do not want to rewrite SRF at this point of time >We do the following here: >Remove get_opp and introduce three SRF specific accessor functions: > opp_to_freq, freq_to_opp - need this coz of usage of opp IDs > NOTE: These functions should be removed at a later point > of time. >get_opp is removed because, with the above functions, it is >redundant. > >NOTE: this implementation is just a start and leaves scope for >further cleanups which can be added on top. > >NOTE: this increases the number of warnings to: > >arch/arm/mach-omap2/resource34xx.c: In function 'opp_to_freq': >arch/arm/mach-omap2/resource34xx.c:182: warning: 'opp_id' is >deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) >arch/arm/mach-omap2/resource34xx.c: In function 'freq_to_opp': >arch/arm/mach-omap2/resource34xx.c:213: warning: 'opp_id' is >deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) >arch/arm/mach-omap2/resource34xx.c: In function 'init_opp': >arch/arm/mach-omap2/resource34xx.c:242: warning: 'freq_to_opp' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) >arch/arm/mach-omap2/resource34xx.c:249: warning: 'freq_to_opp' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) >arch/arm/mach-omap2/resource34xx.c: In function 'program_opp_freq': >arch/arm/mach-omap2/resource34xx.c:302: warning: 'opp_to_freq' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) >arch/arm/mach-omap2/resource34xx.c:303: warning: 'opp_to_freq' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) >arch/arm/mach-omap2/resource34xx.c:308: warning: 'opp_to_freq' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) >arch/arm/mach-omap2/resource34xx.c: In function 'program_opp': >arch/arm/mach-omap2/resource34xx.c:351: warning: 'opp_id' is >deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) >arch/arm/mach-omap2/resource34xx.c:352: warning: 'opp_id' is >deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) >arch/arm/mach-omap2/resource34xx.c:356: warning: 'opp_to_freq' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) >arch/arm/mach-omap2/resource34xx.c:380: warning: 'opp_to_freq' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) >arch/arm/mach-omap2/resource34xx.c: In function >'resource_set_opp_level': >arch/arm/mach-omap2/resource34xx.c:417: warning: 'opp_to_freq' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) >arch/arm/mach-omap2/resource34xx.c:418: warning: 'opp_to_freq' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) >arch/arm/mach-omap2/resource34xx.c:420: warning: 'opp_to_freq' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) >arch/arm/mach-omap2/resource34xx.c: In function 'set_opp': >arch/arm/mach-omap2/resource34xx.c:497: warning: 'freq_to_opp' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) >arch/arm/mach-omap2/resource34xx.c: In function 'validate_opp': >arch/arm/mach-omap2/resource34xx.c:516: warning: 'opp_to_freq' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) >arch/arm/mach-omap2/resource34xx.c:518: warning: 'opp_to_freq' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) >arch/arm/mach-omap2/resource34xx.c: In function 'init_freq': >arch/arm/mach-omap2/resource34xx.c:541: warning: 'opp_to_freq' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) >arch/arm/mach-omap2/resource34xx.c:544: warning: 'opp_to_freq' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) >arch/arm/mach-omap2/resource34xx.c: In function 'set_freq': >arch/arm/mach-omap2/resource34xx.c:560: warning: 'freq_to_opp' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) >arch/arm/mach-omap2/resource34xx.c:565: warning: 'freq_to_opp' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) >arch/arm/mach-omap2/resource34xx.c: In function 'validate_freq': >arch/arm/mach-omap2/resource34xx.c:579: warning: 'freq_to_opp' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) >arch/arm/mach-omap2/resource34xx.c:581: warning: 'freq_to_opp' >is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) > >Cc: Benoit Cousson >Cc: Kevin Hilman >Cc: Madhusudhan Chikkature Rajashekar >Cc: Paul Walmsley >Cc: Romit Dasgupta >Cc
RE: [PATCH 03/10 V3] omap3: pm: use opp accessor functions for omap34xx
One additional comment to this patch, compilation of board-rx51.c fails unless
#include "pm.h" is added to it. This might be true for other boards also seeing
it has been added to zoom2 at least.
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org
>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Kevin Hilman
>Sent: 25 November, 2009 19:22
>To: Nishanth Menon
>Cc: linux-omap
>Subject: Re: [PATCH 03/10 V3] omap3: pm: use opp accessor
>functions for omap34xx
>
>Nishanth Menon writes:
>
>> Move the definitions from omap3-opp.h to pm34xx.c. The definitions
>> are now based on omap_opp_def instead of omap_opp itself.
>> Since the opp.h has the omap_opp definition, omap-pm.h conflicts and
>> has been removed in favor of opp.h.
>
>ok
>
>> omap3_pm_init_opp_table is used to initialize the OPP table and
>> relevant board files which have omap2_init_common_hw called with opp
>> arrays have been updated with omap3_pm_init_opp_table.
>>
>> This change now allows us to dynamically register OPPs to the system
>> based on silicon type we detect.
>
>Nice.
>
>With this patch, I would suggest a couple more cleanups in how
>we are handling
>the master OPP lists for MPU, DSP and L3.
>
>Namely, It's time we could remove the rate_table passing from the OMAP
>PM layer all together and just keep them as pointers in opp.h.
>
>The longer term goal is to remove OPP handling from OMAP PM
>all together,
>so this will be a step in that direction.
>
>I've attached a patch that applies on top of your series that drops
>the OPPs from OMAP PM layer. After doing this, we now have some
>duplicate global pointers to the various rate tables that could be
>cleaned up. In addition, all the rate tables could be dropped from
>init_common_hw.
>
>If you follow my proposal for using opp_add() instead of opp_init()
>the board files that want to just use default OPPs do not have to do
>anyting with the rate tables. Only board files wanting to add OPPs
>would have to include opp.h and use opp_add().
>
>Also, dropping the rate tables from init_common_hw would mean you
>shouldn't have init sequence issues anymore and you can do the OPP
>init inside existing PM init.
>
>Kevin
>
>> NOTE: This introduces the following warnings highlighting areas we
>> need to cleanup:
>> arch/arm/mach-omap2/smartreflex.c: In function 'get_opp':
>> arch/arm/mach-omap2/smartreflex.c:161: warning: 'opp_id' is
>deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
>> arch/arm/mach-omap2/smartreflex.c:164: warning: 'opp_id' is
>deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
>> arch/arm/mach-omap2/smartreflex.c:166: warning: 'opp_id' is
>deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
>> arch/arm/mach-omap2/smartreflex.c:168: warning: 'opp_id' is
>deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
>> arch/arm/mach-omap2/resource34xx.c: In function 'get_opp':
>> arch/arm/mach-omap2/resource34xx.c:165: warning: 'opp_id' is
>deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
>> arch/arm/mach-omap2/resource34xx.c:168: warning: 'opp_id' is
>deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
>> arch/arm/mach-omap2/resource34xx.c:170: warning: 'opp_id' is
>deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
>> arch/arm/mach-omap2/resource34xx.c:172: warning: 'opp_id' is
>deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
>> arch/arm/mach-omap2/resource34xx.c: In function 'program_opp':
>> arch/arm/mach-omap2/resource34xx.c:284: warning: 'opp_id' is
>deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
>> arch/arm/mach-omap2/resource34xx.c:285: warning: 'opp_id' is
>deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33)
>>
>> Signed-off-by: Nishanth Menon
>> ---
>> arch/arm/mach-omap2/board-3430sdp.c |1 +
>> arch/arm/mach-omap2/board-omap3beagle.c |1 +
>> arch/arm/mach-omap2/board-omap3evm.c |1 +
>> arch/arm/mach-omap2/board-rx51.c |1 +
>> arch/arm/mach-omap2/board-zoom2.c |2 +
>> arch/arm/mach-omap2/omap3-opp.h | 58
>+---
>> arch/arm/mach-omap2/pm.h |6 +++
>> arch/arm/mach-omap2/pm34xx.c | 68
>+
>> arch/arm/plat-omap/include/plat/omap-pm.h | 17 +---
>> 9 files changed, 84 insertions(+), 71 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-3430sdp.c
>b/arch/arm/mach-omap2/board-3430sdp.c
>> index eac529f..0ec8327 100644
>> --- a/arch/arm/mach-omap2/board-3430sdp.c
>> +++ b/arch/arm/mach-omap2/board-3430sdp.c
>> @@ -220,6 +220,7 @@ static void __init omap_3430sdp_init_irq(void)
>> {
>> omap_board_config = sdp3430_config;
>> omap_board_config_size = ARRAY_SIZE(sdp3430_config);
>> +omap3_pm_init_opp_table();
>> omap3_pm_init_vc(&omap3_setuptime_table);
>> omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
>> omap2_ini
RE: [PATCHv2 5/6] OMAP: Powerdomains: Add support for checking if pwrdm/clkdm can idle
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org
>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Kevin Hilman
>Sent: 12 January, 2010 20:57
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCHv2 5/6] OMAP: Powerdomains: Add support for
>checking if pwrdm/clkdm can idle
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> pwrdm_can_idle(pwrdm) will check if the specified
>powerdomain can enter
>> idle. This is done by checking all clockdomains under the powerdomain
>> if they can idle also.
>>
>> omap2_clkdm_can_idle(clkdm) will check if the specified
>clockdomain can
>> enter idle. This checks the functional clock status in the
>clockdomain.
>>
>> These calls can be used e.g. inside cpuidle to decide which
>power states
>> core and mpu should enter during idle, as there are certain
>dependencies
>> between wakeup capabilities and reset logic.
>>
>> Signed-off-by: Tero Kristo
>
>This looks good by me, but needs a review from Paul to go upstream with
>the rest of his clockdomain/powerdomain updates for 2.6.34.
>
>One question... I'm wondering if it might be good to also check the
>CM_IDLEST_ register in the can_idle function. Even if all
>clocks are disabled, if the idle modes of the module are not
>set correctly,
>it may not enter the target state.
Hmm I guess you are right here. I think at least one case would be secure
devices which do not have FCLK control on the non-secure kernel, but their
IDLEST would indeed block state transition. I'll investigate this a bit and
update the patch.
>
>Kevin
>
>> ---
>> arch/arm/mach-omap2/clockdomain.c | 24
>
>> arch/arm/mach-omap2/clockdomains.h| 14 ++
>> arch/arm/mach-omap2/powerdomain.c | 25
>+
>> arch/arm/plat-omap/include/plat/clockdomain.h | 12
>> arch/arm/plat-omap/include/plat/powerdomain.h |1 +
>> 5 files changed, 76 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/clockdomain.c
>b/arch/arm/mach-omap2/clockdomain.c
>> index fcd8232..9ddeb96 100644
>> --- a/arch/arm/mach-omap2/clockdomain.c
>> +++ b/arch/arm/mach-omap2/clockdomain.c
>> @@ -474,6 +474,30 @@ int omap2_clkdm_wakeup(struct
>clockdomain *clkdm)
>> return 0;
>> }
>>
>> +
>> +/**
>> + * omap2_clkdm_can_idle - check if clockdomain has any
>active clocks or not
>> + * @clkdm: struct clockdomain *
>> + *
>> + * Checks if the clockdomain has any active clock or not,
>i.e. whether it
>> + * can enter idle. Returns -EINVAL if clkdm is NULL; 0 if
>unable to idle;
>> + * 1 if can idle.
>> + */
>> +int omap2_clkdm_can_idle(struct clockdomain *clkdm)
>> +{
>> +int i;
>> +const int fclk_regs[] = { CM_FCLKEN, OMAP3430ES2_CM_FCLKEN3 };
>> +
>> +if (!clkdm)
>> +return -EINVAL;
>> +
>> +for (i = 0; i < clkdm->fclk_reg_amt; i++)
>> +if (cm_read_mod_reg(clkdm->pwrdm.ptr->prcm_offs,
>> +fclk_regs[i]) &
>~clkdm->fclk_masks[i])
>> +return 0;
>> +return 1;
>> +}
>> +
>> /**
>> * omap2_clkdm_allow_idle - enable hwsup idle transitions for clkdm
>> * @clkdm: struct clockdomain *
>> diff --git a/arch/arm/mach-omap2/clockdomains.h
>b/arch/arm/mach-omap2/clockdomains.h
>> index c4ee076..2cde82a 100644
>> --- a/arch/arm/mach-omap2/clockdomains.h
>> +++ b/arch/arm/mach-omap2/clockdomains.h
>> @@ -167,6 +167,7 @@ static struct clockdomain iva2_clkdm = {
>> .flags = CLKDM_CAN_HWSUP_SWSUP,
>> .clktrctrl_mask = OMAP3430_CLKTRCTRL_IVA2_MASK,
>> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
>> +.fclk_reg_amt = 1,
>> };
>>
>> static struct clockdomain gfx_3430es1_clkdm = {
>> @@ -183,6 +184,7 @@ static struct clockdomain sgx_clkdm = {
>> .flags = CLKDM_CAN_HWSUP_SWSUP,
>> .clktrctrl_mask = OMAP3430ES2_CLKTRCTRL_SGX_MASK,
>> .omap_chip = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
>> +.fclk_reg_amt = 1,
>> };
>>
>> /*
>> @@ -206,6 +208,11 @@ static struct clockdomain core_l3_34xx_clkdm = {
>> .flags = CLKDM_CAN_HWSUP,
>> .clktrctrl_mask = OMAP3430_CLKTRCTRL_L3_MASK,
>> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
>> +.fclk_reg_amt = 2,
>> +.fclk_masks = {
>> +[0] = OMAP3430_EN_UART2 | OMAP3430_EN_UART1,
>> +[1] = 0,
>> +},
>> };
>>
>> static struct clockdomain core_l4_34xx_clkdm = {
>> @@ -222,6 +229,7 @@ static struct clockdomain dss_34xx_clkdm = {
>> .flags = CLKDM_CAN_HWSUP_SWSUP,
>> .clktrctrl_mask = OMAP3430_CLKTRCTRL_DSS_MASK,
>> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
>> +.fclk_reg_amt = 1,
>> };
>>
>> static struct clockdomain cam_clkdm = {
>> @@ -230,6 +238,7 @@ static struct clockdomain cam_clkdm = {
>> .flags = CLKDM_CAN_HWSUP_SWSUP,
>> .clktrctrl_mask = OMAP3430_CLKTRCTRL
RE: [PATCHv2 1/6] OMAP: Powerdomains: Add support for INACTIVE state on pwrdm level
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 12 January, 2010 20:25
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCHv2 1/6] OMAP: Powerdomains: Add support for
>INACTIVE state on pwrdm level
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> Currently only ON, RET and OFF are supported, and ON is
>arguably broken as it
>> allows the powerdomain to enter INACTIVE state unless idle
>is prevented.
>> Now, pwrdm code prevents idle if ON is selected, and also
>adds support for
>> INACTIVE. This simplifies the control needed inside sleep code.
>>
>> Signed-off-by: Tero Kristo
>
>Hi Tero,
>
>apologies for the long delay in reviewing this updated series.
No problem, I have actually been on a holiday myself so I did not really miss
review comments that much. Thanks for taking the time to look at this.
>I really like this idea as it indeed simplifies the control code
>inside the idle path. This also needs a review by Paul and should
>merge via his powerdomain updates for 2.6.34.
>
>The changelog should also describe that the powerdomain struct
>now caches the next_state.
Yeah, I can add this comment.
>One minor comment. I think the introduction of signed compares in
>certain cases leads to possible confusion and readability problems.
>
>I'm not sure I realy follow the need for the invalid state. Instead
>of setting next_state to -1 in pwrdm_register, why not read the
>current HW value and use that as the starting value?
I guess this invalid stuff comes from my old lazy initialization habits. :) But
yes, I can change this into a format where we just read the current value from
the register.
>If the invalid state is really needed, instead of using -1 and having
>to change to using signed comparisons in certain cases, it seems like
>we could just define a new invalid state as zero, and move the others
>up a notch.
This is probably not good, as it would break the direct SW to HW value mapping,
so I will go with the previous one.
>
>Then, use something like this to check for a valid state:
>
>static inline bool pwrdm_is_valid_state(struct powerdomain *pwrdm) {
> return (pwrdm->state > PWRDM_POWER_INVALID) ? true : false;
>}
>
>Kevin
>
>> ---
>> arch/arm/mach-omap2/powerdomain.c | 32
>+
>> arch/arm/mach-omap2/powerdomains34xx.h| 26
>++--
>> arch/arm/plat-omap/include/plat/powerdomain.h |6 -
>> 3 files changed, 45 insertions(+), 19 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/powerdomain.c
>b/arch/arm/mach-omap2/powerdomain.c
>> index b6990e3..1237717 100644
>> --- a/arch/arm/mach-omap2/powerdomain.c
>> +++ b/arch/arm/mach-omap2/powerdomain.c
>> @@ -112,8 +112,8 @@ static struct powerdomain
>*_pwrdm_deps_lookup(struct powerdomain *pwrdm,
>> static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
>> {
>>
>> -int prev;
>> -int state;
>> +u8 prev;
>> +u8 state;
>>
>> if (pwrdm == NULL)
>> return -EINVAL;
>> @@ -220,7 +220,7 @@ int pwrdm_register(struct powerdomain *pwrdm)
>>
>> pr_debug("powerdomain: registered %s\n", pwrdm->name);
>> ret = 0;
>> -
>> +pwrdm->next_state = -1;
>
>> pr_unlock:
>> write_unlock_irqrestore(&pwrdm_rwlock, flags);
>>
>> @@ -701,19 +701,38 @@ int pwrdm_get_mem_bank_count(struct
>powerdomain *pwrdm)
>> */
>> int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
>> {
>> +u8 prg_pwrst;
>> +
>> if (!pwrdm)
>> return -EINVAL;
>>
>> +if (pwrdm->next_state == pwrst)
>> +return 0;
>> +
>> if (!(pwrdm->pwrsts & (1 << pwrst)))
>> return -EINVAL;
>>
>> pr_debug("powerdomain: setting next powerstate for %s to %0x\n",
>> pwrdm->name, pwrst);
>>
>> +/* INACTIVE is reserved, so we program pwrdm as ON */
>> +if (pwrst == PWRDM_POWER_INACTIVE)
>> +prg_pwrst = PWRDM_POWER_ON;
>> +else
>> +prg_pwrst = pwrst;
>> +
>> prm_rmw_mod_reg_bits(OMAP_POWERSTATE_MASK,
>> - (pwrst << OMAP_POWERSTATE_SHIFT),
>> + (prg_pwrst << OMAP_POWERSTATE_SHIFT),
>> pwrdm->prcm_offs, PM_PWSTCTRL);
>>
>> +/* If next state is ON, prevent idle */
>> +if (pwrst == PWRDM_POWER_ON)
>> +omap2_clkdm_deny_idle(pwrdm->pwrdm_clkdms[0]);
>> +else
>> +omap2_clkdm_allow_idle(pwrdm->pwrdm_clkdms[0]);
>> +
>> +pwrdm->next_state = pwrst;
>> +
>> return 0;
>> }
>>
>> @@ -730,8 +749,11 @@ int pwrdm_read_next_pwrst(struct
>powerdomain *pwrdm)
>> if (!pwrdm)
>> return -EINVAL;
>>
>> +if (pwrdm->next_state > -1)
>> +return pwrdm->next_state;
>> +
>> return prm_read_mod_bits_shift(pwrdm->prcm_offs, PM_PWSTCTRL,
>> -OMAP_POWERSTATE_MASK);
>> +
RE: [PATCHv3 5/6] OMAP: Powerdomains: Add support for checking if pwrdm/clkdm can idle
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 18 January, 2010 20:41
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCHv3 5/6] OMAP: Powerdomains: Add support for
>checking if pwrdm/clkdm can idle
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> pwrdm_can_idle(pwrdm) will check if the specified
>powerdomain can enter
>> idle. This is done by checking all clockdomains under the powerdomain
>> if they can idle also.
>>
>> omap2_clkdm_can_idle(clkdm) will check if the specified
>clockdomain can
>> enter idle. This checks the functional clocks and idle
>status bits of the
>> domain according to following rules:
>> 1) get inverse of idlest and mask against idle_def.mask
>> * this gives a bitmask with non-idle bits high
>> 2) bitwise OR active functional clocks from the domain to the result
>> * in some cases FCLK can be active but idlest still shows
>module in idle
>> 3) disable bits defined in idle_def.mask
>
>disable? it looks like they're just being ignored.
Oh yes, just a small typo here in patch description. This should indeed say
that they are ignored, as the bit-field also is named as ignore.
>
>> * some bits should be ignored, like UART clocks which are
>dynamically
>> switched inside sleep loop
>>
>> These calls can be used e.g. inside cpuidle to decide which
>power states
>> core and mpu should enter during idle, as there are certain
>dependencies
>> between wakeup capabilities and reset logic.
>>
>> Signed-off-by: Tero Kristo
>
>Thanks for adding the IDLEST checks, I think that will help.
Yes, and this is actually required for the secure side clock status handling,
this information is not available anywhere else, thus it is impossible to get
the idle status from the clock framework usecounts.
>
>In the .mask field, instead of using a hard-coded mask, probably using
>the existing bitfields headers would be a bit more readable, and help
>ensure correctness.
Well, the bitfield definitions for those do not exist at the moment. The idea
of the mask is just to get all bits in that are needed, e.g. PER domain does
not have GPIO bits in the mask, as these appear to always be in a state that
they are accessible (i.e. IDLEST shows accessible for them.)
I can write all IDLEST bits into the masks (as was done before) if you like
this approach better. This will generate rather long definitions though, and
the probability of errors in those is actually higher than in this version (I
just write a number of low bits to one.)
>
>Hopefully there's a way to auto-generate these for OMAP4.
>
>> ---
>> arch/arm/mach-omap2/clockdomain.c | 27
>> arch/arm/mach-omap2/clockdomains.h| 54
>+
>> arch/arm/mach-omap2/powerdomain.c | 25 +++
>> arch/arm/plat-omap/include/plat/clockdomain.h | 17
>> arch/arm/plat-omap/include/plat/powerdomain.h |1 +
>> 5 files changed, 124 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/clockdomain.c
>b/arch/arm/mach-omap2/clockdomain.c
>> index dd285f0..f42111a 100644
>> --- a/arch/arm/mach-omap2/clockdomain.c
>> +++ b/arch/arm/mach-omap2/clockdomain.c
>> @@ -472,6 +472,33 @@ int omap2_clkdm_wakeup(struct
>clockdomain *clkdm)
>> return 0;
>> }
>>
>> +
>> +/**
>> + * omap2_clkdm_can_idle - check if clockdomain has any
>active clocks or not
>> + * @clkdm: struct clockdomain *
>> + *
>> + * Checks if the clockdomain has any active clock or not,
>i.e. whether it
>> + * can enter idle. Returns -EINVAL if clkdm is NULL; 0 if
>unable to idle;
>> + * 1 if can idle.
>> + */
>> +int omap2_clkdm_can_idle(struct clockdomain *clkdm)
>> +{
>> +int i;
>> +
>> +if (!clkdm)
>> +return -EINVAL;
>> +
>> +for (i = 0; i < clkdm->clk_reg_amt; i++)
>> +if (((~cm_read_mod_reg(clkdm->pwrdm.ptr->prcm_offs,
>> +CM_IDLEST + 4 * i) &
>> +clkdm->idle_def[i].mask) |
>> +
>cm_read_mod_reg(clkdm->pwrdm.ptr->prcm_offs,
>> +CM_FCLKEN + 4 * i)) &
>> +~clkdm->idle_def[i].ignore)
>
>This has some readability/indent issues.
>
>Also, could check fclk first, if active fclks, no reason to check
>idlest. How about something like this (untested, but I *think* I kept
>the same logic):
>
> for (i = 0; i < clkdm->clk_reg_amt; i++) {
> u32 idlest, fclk;
>
> fclk = cm_read_mod_reg(clkdm->pwrdm.ptr->prcm_offs,
> CM_FCLKEN + 4 * i);
> if (fclk & ~clkdm->idle_def[i].ignore)
> return 0;
>
> idlest = cm_read_mod_reg(clkdm->pwrdm.ptr->prcm_offs,
>CM_IDLEST + 4 * i);
> if (~idlest & clkdm->idle_def[i].mask)
> return 0
RE: OMAP3: PM: Disable OTG autoidle when waking up from off-mode
>-Original Message-
>From: ext Gupta, Ajay Kumar [mailto:ajay.gu...@ti.com]
>Sent: 21 January, 2010 12:31
>To: Kristo Tero (Nokia-D/Tampere); linux-omap@vger.kernel.org
>Cc: Kevin Hilman
>Subject: RE: OMAP3: PM: Disable OTG autoidle when waking up
>from off-mode
>
>Hi Kristo,
>
>There are some issues with this patch in PM branch.
>
>Please find my comments inline.
>
>Regards,
>Ajay
>
>> OMAP3: PM: Disable OTG autoidle when waking up from off-mode
>>
>> OMAP3 sleep can be prevented in some cases where OTG autoidle is
>> enabled.
>> This patch force disables autoidle during wakeup from
>off-mode. See
>> omap
>> errata 1.164.
>>
>> This fix can't be done in driver level, as off-mode
>entry resets and
>> enables
>> the autoidle bit, and driver does not access the
>register after each
>> off-mode
>> entry even if it is loaded.
>>
>> Tero Kristo
>> Kevin Hilman
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c
>b/arch/arm/mach-omap2/pm34xx.c
>> index 81ed252..ddd19cd 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -37,6 +37,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -430,6 +431,11 @@ void omap_sram_idle(void)
>> omap3_prcm_restore_context();
>> omap3_sram_restore_context();
>> omap2_sms_restore_context();
>> +/*
>> + * Errata 1.164 fix : OTG autoidle can prevent
>> + * sleep
>> + */
>> +usb_musb_disable_autoidle();
>
>Do we really need it? We are anyway disabling autoidle in
>Drivers/usb/musb/omap2430.c file.
This is not enough, as off-mode entry will reset this register. And, we are not
calling MUSB resume functions after every wakeup from off.
>
>
>> clk_disable(otg_clk);
>> -clk_put(otg_clk);
>> -}
>> +}
>
>
>
>>
>> -iounmap(otg_base);
>> +void usb_musb_disable_autoidle(void)
>> +{
>> +__raw_writel(0, otg_base + OTG_SYSCONFIG);
>
>
>We should first read the register and the reset the first bit D0
>for disabling autoidle.
We know that always when we are calling this function, we are waking up from
off-mode and MUSB module has been reset also. Thus, no need to read it, as we
know what the reset value is.
>
>Also, musb clock needs to be enabled during this function call.
>When I tool musb save/restore patch (accepted and in queue),
>I found a system hand during resume.
It is possible that MUSB clock is disabled here if you are fiddling with the
clocks on the MUSB module side. In that case this patch should probably be
modified.
-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: [PATCHv3 5/6] OMAP: Powerdomains: Add support for checking if pwrdm/clkdm can idle
>-Original Message- >From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: 20 January, 2010 02:48 >To: Kristo Tero (Nokia-D/Tampere) >Cc: linux-omap@vger.kernel.org >Subject: Re: [PATCHv3 5/6] OMAP: Powerdomains: Add support for >checking if pwrdm/clkdm can idle > > writes: > >> >> >>>-Original Message- >>>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] >>>Sent: 18 January, 2010 20:41 >>>To: Kristo Tero (Nokia-D/Tampere) >>>Cc: linux-omap@vger.kernel.org >>>Subject: Re: [PATCHv3 5/6] OMAP: Powerdomains: Add support for >>>checking if pwrdm/clkdm can idle >>> >>>Tero Kristo writes: >>> From: Tero Kristo pwrdm_can_idle(pwrdm) will check if the specified >>>powerdomain can enter idle. This is done by checking all clockdomains under the >powerdomain if they can idle also. omap2_clkdm_can_idle(clkdm) will check if the specified >>>clockdomain can enter idle. This checks the functional clocks and idle >>>status bits of the domain according to following rules: 1) get inverse of idlest and mask against idle_def.mask * this gives a bitmask with non-idle bits high 2) bitwise OR active functional clocks from the domain to >the result * in some cases FCLK can be active but idlest still shows >>>module in idle 3) disable bits defined in idle_def.mask >>> >>>disable? it looks like they're just being ignored. >> >> Oh yes, just a small typo here in patch description. This >should indeed say that they are ignored, as the bit-field also >is named as ignore. >> >>> * some bits should be ignored, like UART clocks which are >>>dynamically switched inside sleep loop These calls can be used e.g. inside cpuidle to decide which >>>power states core and mpu should enter during idle, as there are certain >>>dependencies between wakeup capabilities and reset logic. Signed-off-by: Tero Kristo >>> >>>Thanks for adding the IDLEST checks, I think that will help. >> >> Yes, and this is actually required for the secure side clock status >> handling, this information is not available anywhere else, thus it >> is impossible to get the idle status from the clock framework >> usecounts. >> >>> >>>In the .mask field, instead of using a hard-coded mask, >probably using >>>the existing bitfields headers would be a bit more readable, and help >>>ensure correctness. >> >> Well, the bitfield definitions for those do not exist at the >> moment. > >We could use the EN bit definitions for the CM_FCLKEN* since they're >the same for IDLEST. Some bits do not exist as EN bit definitions, but they do exist as ST. E.g secure clocks do not have EN bit, and some CORE domain EN bits are not definied either as they do not exist. I will update the masks in the code according to this, and just use ST bits. > >> The idea of the mask is just to get all bits in that are >> needed, e.g. PER domain does not have GPIO bits in the mask, as >> these appear to always be in a state that they are accessible >> (i.e. IDLEST shows accessible for them.) > >And I think if we used the #defines here, it would be much clearer >what bits are included and which are left out. > >Some comments as to which ones are needed or not would be helpful too. Ok, I'll inline the comments with the masks. > >> I can write all IDLEST bits into the masks (as was done before) if >> you like this approach better. This will generate rather long >> definitions though, and the probability of errors in those is >> actually higher than in this version (I just write a number of low >> bits to one.) > >I guess you didn't see the rest of my comments further down in the >original review. There was at least one error already in the SGX >since it's bit is not bit 0 but but 1. Using the existing #defines >would've solved that. True, I will update the masks according to this. > >On that note, please check out the other inline comments in the >original review. > >I should've mentioned that there were further comments inline in the >original review. Sorry for the confusion. Yeah, sorry missed those, will comment now. > >Kevin > >>> >>>Hopefully there's a way to auto-generate these for OMAP4. >>> --- arch/arm/mach-omap2/clockdomain.c | 27 arch/arm/mach-omap2/clockdomains.h| 54 >>>+ arch/arm/mach-omap2/powerdomain.c | 25 +++ arch/arm/plat-omap/include/plat/clockdomain.h | 17 arch/arm/plat-omap/include/plat/powerdomain.h |1 + 5 files changed, 124 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/clockdomain.c >>>b/arch/arm/mach-omap2/clockdomain.c index dd285f0..f42111a 100644 --- a/arch/arm/mach-omap2/clockdomain.c +++ b/arch/arm/mach-omap2/clockdomain.c @@ -472,6 +472,33 @@ int omap2_clkdm_wakeup(struct >>>clockdomain *clkdm) return 0; }
RE: [PATCHv3 1/6] OMAP: Powerdomains: Add support for INACTIVE state on pwrdm level
Hi Paul,
Thanks for comments, my responses inline below.
>-Original Message-
>From: ext Paul Walmsley [mailto:p...@pwsan.com]
>Sent: 21 January, 2010 06:35
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com
>Subject: Re: [PATCHv3 1/6] OMAP: Powerdomains: Add support for
>INACTIVE state on pwrdm level
>
>Hi Tero,
>
>I regret the delay in reviewing. I haven't kept up on the comments on
>this thread, so if I've asked a question that you've already answered,
>please feel free to point me to the response.
>
>A few comments/questions:
>
>On Fri, 15 Jan 2010, Tero Kristo wrote:
>
>> From: Tero Kristo
>>
>> Currently only ON, RET and OFF are supported, and ON is
>arguably broken as it
>> allows the powerdomain to enter INACTIVE state unless idle
>is prevented.
>> Now, pwrdm code prevents idle if ON is selected, and also
>adds support for
>> INACTIVE. This simplifies the control needed inside sleep code.
>>
>> This patch also requires caching of next power state inside
>powerdomain code,
>> as INACTIVE is not directly supported by hardware.
>
>The idea seems like a good one, and a simplification for the
>PM code. I'm
>a little worried that this patch mixes hardware-programmable
>powerdomain
>states with logical powerdomain states. I wonder if we would
>be better
>off separating, for example, the logic of putting a powerdomain into
>INACTIVE state and any other logical powerdomain management, from the
>physical details of how the chip is programmed. Just looking for your
>comments on this, not necessarily any changes in your patches in this
>regard.
>
>> Next powerstate is thus now stored for each powerdomain in
>next_state.
>>
>> Signed-off-by: Tero Kristo
>> ---
>> arch/arm/mach-omap2/powerdomain.c | 32
>
>> arch/arm/mach-omap2/powerdomains34xx.h| 26
>++--
>> arch/arm/plat-omap/include/plat/powerdomain.h |4 +++
>> 3 files changed, 43 insertions(+), 19 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/powerdomain.c
>b/arch/arm/mach-omap2/powerdomain.c
>> index 26b3f3e..a08d596 100644
>> --- a/arch/arm/mach-omap2/powerdomain.c
>> +++ b/arch/arm/mach-omap2/powerdomain.c
>> @@ -110,8 +110,8 @@ static struct powerdomain
>*_pwrdm_deps_lookup(struct powerdomain *pwrdm,
>> static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
>> {
>>
>> -int prev;
>> -int state;
>> +u8 prev;
>> +u8 state;
>>
>> if (pwrdm == NULL)
>> return -EINVAL;
>> @@ -218,7 +218,9 @@ int pwrdm_register(struct powerdomain *pwrdm)
>>
>> pr_debug("powerdomain: registered %s\n", pwrdm->name);
>> ret = 0;
>> -
>> +pwrdm->next_state =
>> +prm_read_mod_bits_shift(pwrdm->prcm_offs, PM_PWSTCTRL,
>> +OMAP_POWERSTATE_MASK);
>> pr_unlock:
>> write_unlock_irqrestore(&pwrdm_rwlock, flags);
>>
>> @@ -699,19 +701,38 @@ int pwrdm_get_mem_bank_count(struct
>powerdomain *pwrdm)
>> */
>> int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
>> {
>> +u8 prg_pwrst;
>> +
>> if (!pwrdm)
>> return -EINVAL;
>>
>> +if (pwrdm->next_state == pwrst)
>> +return 0;
>> +
>> if (!(pwrdm->pwrsts & (1 << pwrst)))
>> return -EINVAL;
>>
>> pr_debug("powerdomain: setting next powerstate for %s to %0x\n",
>> pwrdm->name, pwrst);
>>
>> +/* INACTIVE is reserved, so we program pwrdm as ON */
>> +if (pwrst == PWRDM_POWER_INACTIVE)
>> +prg_pwrst = PWRDM_POWER_ON;
>> +else
>> +prg_pwrst = pwrst;
>> +
>> prm_rmw_mod_reg_bits(OMAP_POWERSTATE_MASK,
>> - (pwrst << OMAP_POWERSTATE_SHIFT),
>> + (prg_pwrst << OMAP_POWERSTATE_SHIFT),
>> pwrdm->prcm_offs, PM_PWSTCTRL);
>>
>> +/* If next state is ON, prevent idle */
>> +if (pwrst == PWRDM_POWER_ON)
>> +omap2_clkdm_deny_idle(pwrdm->pwrdm_clkdms[0]);
>> +else
>> +omap2_clkdm_allow_idle(pwrdm->pwrdm_clkdms[0]);
>
>Looks like this will force clockdomains into hardware-supervised mode,
>even if they were originally programmed into software-supervised mode.
>Please fix this so clockdomains that were originally programmed into
>software-supervised mode aren't inadvertently switched.
I think the change here would be to only deny/allow idle if we are in hwsup
mode. Probably needs caching of the setup also. I'll do the change for this.
>
>> +
>> +pwrdm->next_state = pwrst;
>> +
>> return 0;
>> }
>>
>> @@ -728,8 +749,7 @@ int pwrdm_read_next_pwrst(struct
>powerdomain *pwrdm)
>> if (!pwrdm)
>> return -EINVAL;
>>
>> -return prm_read_mod_bits_shift(pwrdm->prcm_offs, PM_PWSTCTRL,
>> -OMAP_POWERSTATE_MASK);
>> +return pwrdm->next_state;
>> }
>>
>> /**
>> diff --git a/arch/arm/ma
RE: [PATCHv4 1/8] OMAP3: Clockdomain: Added API for checking if HWSUP is enabled
>-Original Message-
>From: ext Paul Walmsley [mailto:p...@pwsan.com]
>Sent: 02 February, 2010 00:11
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCHv4 1/8] OMAP3: Clockdomain: Added API for
>checking if HWSUP is enabled
>
>Hi Tero,
>
>On Fri, 22 Jan 2010, Tero Kristo wrote:
>
>> From: Tero Kristo
>>
>> omap2_clkdm_get_hwsup(clkdm) can be used to check if automatic HW
>> transitions for the domain are enabled or not. This is needed for the
>> powerdomain code that adds support for INACTIVE state, as it needs to
>> disable HWSUP on the fly for ON state, and re-enable it
>after returning
>> to some other state.
>>
>> Signed-off-by: Tero Kristo
>
>An updated patch with some revisions is below. Please let me know if
>there's something that still should be changed. The revisions are:
Your changes look okay to me.
>
>1. Split the if-statement expressions up into separate lines per
>CodingStyle
>
>2. Rename omap2_clkdm_get_hwsup() to omap2_clkdm_read_hwsup()
>to follow
>the general practice in this file and powerdomain.c that
>functions with
>'_get_' in the name read configuration data, and functions
>with '_read_'
>read from the hardware (or a cache of the hardware register)
>
>3. Add OMAP4 support
>
>4. Added the extra asterisk in the comment body to indicate
>kerneldoc-format comment
>
>5. Updated patch to apply after the current round of 2.6.34 changes
>
>
>regards,
>
>- Paul
>
>From fc2f8ad184e012a5574e1110c359354d247a1709 Mon Sep 17 00:00:00 2001
>From: Tero Kristo
>Date: Mon, 1 Feb 2010 13:41:26 -0700
>Subject: [PATCH] OMAP3: Clockdomain: Added API for checking if
>HWSUP is enabled
>
>omap2_clkdm_read_hwsup(clkdm) can be used to check if automatic HW
>transitions for the domain are enabled or not. This is needed for the
>powerdomain code that adds support for INACTIVE state, as it needs to
>disable HWSUP on the fly for ON state, and re-enable it after returning
>to some other state.
>
>Signed-off-by: Tero Kristo
>[p...@pwsan.com: added kerneldoc comment magic start; changed function
> name to omap2_clkdm_read_hwsup(); broke up expressions in function
> body; added OMAP4 support]
>Signed-off-by: Paul Walmsley
>---
> arch/arm/mach-omap2/clockdomain.c | 30
>+
> arch/arm/plat-omap/include/plat/clockdomain.h |1 +
> 2 files changed, 31 insertions(+), 0 deletions(-)
>
>diff --git a/arch/arm/mach-omap2/clockdomain.c
>b/arch/arm/mach-omap2/clockdomain.c
>index a38a615..8dce3c9 100644
>--- a/arch/arm/mach-omap2/clockdomain.c
>+++ b/arch/arm/mach-omap2/clockdomain.c
>@@ -868,6 +868,36 @@ int omap2_clkdm_wakeup(struct clockdomain *clkdm)
> }
>
> /**
>+ * omap2_clkdm_read_hwsup - read the hwsup idle transition bit
>+ * @clkdm: struct clockdomain *
>+ *
>+ * Checks whether hardware is allowed to switch the clockdomain @clkdm
>+ * automatically into active or idle states. Returns -EINVAL if @clkdm
>+ * is NULL; otherwise, 1 if hardware auto-idle is enabled, 0 if not.
>+ */
>+int omap2_clkdm_read_hwsup(struct clockdomain *clkdm)
>+{
>+ u32 u, v;
>+
>+ if (!clkdm)
>+ return -EINVAL;
>+
>+ u = cm_read_mod_reg(clkdm->pwrdm.ptr->prcm_offs, CM_CLKSTCTRL);
>+ u &= clkdm->clktrctrl_mask;
>+
>+ if (cpu_is_omap24xx())
>+ v = OMAP24XX_CLKSTCTRL_ENABLE_AUTO;
>+ else if (cpu_is_omap34xx() || cpu_is_omap44xx())
>+ v = OMAP34XX_CLKSTCTRL_ENABLE_AUTO;
>+ else
>+ BUG();
>+
>+ v <<= __ffs(clkdm->clktrctrl_mask);
>+
>+ return (u == v) ? 1 : 0;
>+}
>+
>+/**
> * omap2_clkdm_allow_idle - enable hwsup idle transitions for clkdm
> * @clkdm: struct clockdomain *
> *
>diff --git a/arch/arm/plat-omap/include/plat/clockdomain.h
>b/arch/arm/plat-omap/include/plat/clockdomain.h
>index ba0a6c0..9d25f4e 100644
>--- a/arch/arm/plat-omap/include/plat/clockdomain.h
>+++ b/arch/arm/plat-omap/include/plat/clockdomain.h
>@@ -129,6 +129,7 @@ int clkdm_del_sleepdep(struct clockdomain
>*clkdm1, struct clockdomain *clkdm2);
> int clkdm_read_sleepdep(struct clockdomain *clkdm1, struct
>clockdomain *clkdm2);
> int clkdm_clear_all_sleepdeps(struct clockdomain *clkdm);
>
>+int omap2_clkdm_read_hwsup(struct clockdomain *clkdm);
> void omap2_clkdm_allow_idle(struct clockdomain *clkdm);
> void omap2_clkdm_deny_idle(struct clockdomain *clkdm);
>
>--
>1.6.6.rc2.5.g49666
>
>--
To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv4 2/8] OMAP: Powerdomains: Add support for INACTIVE state on pwrdm level
>-Original Message- >From: ext Paul Walmsley [mailto:p...@pwsan.com] >Sent: 02 February, 2010 10:04 >To: Kristo Tero (Nokia-D/Tampere) >Cc: linux-omap@vger.kernel.org >Subject: Re: [PATCHv4 2/8] OMAP: Powerdomains: Add support for >INACTIVE state on pwrdm level > >Hello Tero, > >On Fri, 22 Jan 2010, Tero Kristo wrote: > >> Currently only ON, RET and OFF are supported, and ON is >arguably broken as it >> allows the powerdomain to enter INACTIVE state unless idle >is prevented. >> Now, pwrdm code prevents idle if ON is selected and hardware >supervised >> mode for the underlying clockdomain is enabled, and also >adds support for >> INACTIVE. This simplifies the control needed inside sleep code. >> >> This patch also requires caching of next power state inside >powerdomain code, >> as INACTIVE is not directly supported by hardware. Next >powerstate is thus >> now stored for each powerdomain in next_state. > >Still thinking about this patch. Am not sure it makes sense, >or at least, >it is incomplete. Consider: Reasoning for this patch at least for OMAP3 is as follows: - sleep code needs to know the states for mpu and core better than it does now, there is currently at least one "bug" in the sleep path which effectively prevents core INACTIVE completely (uart clocks are only turned off if core is going to RET or OFF) - support for ON/INACTIVE allows better testing facilities for different power states (e.g. suspend) - adding support for ON/INACTIVE to powerdomain code simplifies the interface between cpuidle34xx / pm34xx - adding support for other powerdomains than mpu/core is a nice to have feature and we can most likely live without it Alternative is to duplicate this code to several locations (pm34xx.c, cpuidle34xx.c.), or just put this code into separate file, and use it from the locations where it is needed. > >1. In the current code, pwrdm->next_state can never be initialized to >INACTIVE during pwrdm_register(), but this should be possible. To do >this, the code needs to iterate through the powerdomain's >clockdomains and >determine whether they are in hardware-supervised idle or >software-supervised idle. Well, there is a chicken-egg problem here. It is not possible to check the clockdomains at this state as clockdomains do not exist yet. It would be possible to split this out from powerdomain code, maybe into powerdomain34xx.c as you suggested and do the init later. > >2. What should happen to pwrdm->next_state if someone calls >omap2_clkdm_allow_idle(), omap2_clkdm_deny_idle(), >omap2_clkdm_sleep(), or >omap2_clkdm_wakeup()? Right now, nothing will happen, which >is a problem >since calling one of these functions could mean that the powerdomain's >possible next state may change from ON to INACTIVE or vice-versa. A >similar problem appears to exist with hwsup_changed: other >code may have >changed the clockdomain autoidle state, which may cause >hwsup_changed to >not reflect reality any longer. True... We should probably do something for these. However, at least currently this implementation does not cause any problems as clkdm_allow_idle, deny_idle, sleep and wakeup are not used anywhere. > >... > >I am still not sure that the idea of setting the powerdomain's >next power >state to INACTIVE makes sense. The TRM claims that a >powerdomain can be >"inactive," but this seems to be just poor documentation. To >say that a >powerdomain can be inactive is really just to say that the >powerdomain is >'ON' -- powered -- but all of its subsidiary clockdomain >activity states >are INACTIVE. Between ON and INACTIVE, the power state of the >powerdomain >is the same from the hardware's point of view -- but the differences >between the OFF, RET, and ON power states are distinct. And >from the PRCM >point of view, the only place that an INACTIVE power domain >state shows up >is in the powerdomain current power state register. This is also visible in the previous state register, and well, denying/allowing clockdomain to idle only makes sense for the ON state in general, as this is the only case where we actually care if we have allowed idle or not. It is also good to know if a clockdomain has actually entered idle or not, if we do not have INACTIVE state for powerdomain, we do not know this from anywhere. > >Perhaps a separate code layer that incorporates your ideas is >worthwhile >for use by pm*.c and cpuidle*.c, in order to simplify that >code. But in >the current powerdomain and clockdomain code, when we depart >from what the >hardware is capable of, the code needs to cover all of the >software corner >cases that can affect state transitions. Otherwise we probably should >stick with the simplicity of following the hardware's registers and >capabilities. Yeah, I think I try to put my powerdomain hacks into separate file. The patch might also break stuff for OMAP2 or OMAP4, which I think we want to avoid. Someon
RE: [PATCH] OMAP3: Serial: Improved sleep logic
>-Original Message-
>From: ext Tony Lindgren [mailto:t...@atomide.com]
>Sent: 03 February, 2010 19:50
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH] OMAP3: Serial: Improved sleep logic
>
>* Tero Kristo [100202 01:38]:
>> From: Tero Kristo
>>
>> Only RX interrupt will now kick the sleep prevent timer. In
>addition, TX
>> fifo status is checked before disabling clocks, this will
>prevent occasional
>> garbage being printed on serial line. Smartidle is also
>disabled while
>> entering idle if we have data in the transmit buffer,
>because having this
>> enabled will prevent wakeups from the TX interrupt, and this causes
>> pauses while sending large blocks of data.
>
>Sounds this is for 2.6.34 merge window and does not contain anything
>that needs to be fixed for 2.6.33.
Yeah, this only fixes a couple of annoying issues, but nothing fatal. Also
improves power efficiency in some cases which is a nice to have feature, and
basically eases the development of PM code as the UART does not block the
system from sleeping always.
-Tero
>
>Regards,
>
>Tony
>
>
>> Signed-off-by: Tero Kristo
>> ---
>> arch/arm/mach-omap2/serial.c | 19 +++
>> 1 files changed, 15 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/serial.c
>b/arch/arm/mach-omap2/serial.c
>> index 777e802..e11dfe9 100644
>> --- a/arch/arm/mach-omap2/serial.c
>> +++ b/arch/arm/mach-omap2/serial.c
>> @@ -317,7 +317,8 @@ static void omap_uart_allow_sleep(struct
>omap_uart_state *uart)
>> if (!uart->clocked)
>> return;
>>
>> -omap_uart_smart_idle_enable(uart, 1);
>> +if (serial_read_reg(uart->p, UART_LSR) & UART_LSR_TEMT)
>> +omap_uart_smart_idle_enable(uart, 1);
>> uart->can_sleep = 1;
>> del_timer(&uart->timer);
>> }
>> @@ -335,7 +336,11 @@ void omap_uart_prepare_idle(int num)
>>
>> list_for_each_entry(uart, &uart_list, node) {
>> if (num == uart->num && uart->can_sleep) {
>> -omap_uart_disable_clocks(uart);
>> +if (serial_read_reg(uart->p, UART_LSR) &
>> +UART_LSR_TEMT)
>> +omap_uart_disable_clocks(uart);
>> +else
>> +omap_uart_smart_idle_enable(uart, 0);
>> return;
>> }
>> }
>> @@ -407,8 +412,14 @@ int omap_uart_can_sleep(void)
>> static irqreturn_t omap_uart_interrupt(int irq, void *dev_id)
>> {
>> struct omap_uart_state *uart = dev_id;
>> +u8 lsr;
>>
>> -omap_uart_block_sleep(uart);
>> +lsr = serial_read_reg(uart->p, UART_LSR);
>> +/* Check for receive interrupt */
>> +if (lsr & UART_LSR_DR)
>> +omap_uart_block_sleep(uart);
>> +if (lsr & UART_LSR_TEMT && uart->can_sleep)
>> +omap_uart_smart_idle_enable(uart, 1);
>>
>> return IRQ_NONE;
>> }
>> --
>> 1.5.4.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: Serial: Improved sleep logic
>-Original Message-
>From: ext Tony Lindgren [mailto:t...@atomide.com]
>Sent: 04 February, 2010 18:11
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH] OMAP3: Serial: Improved sleep logic
>
>* tero.kri...@nokia.com [100203 23:59]:
>>
>>
>> >-Original Message-
>> >From: ext Tony Lindgren [mailto:t...@atomide.com]
>> >Sent: 03 February, 2010 19:50
>> >To: Kristo Tero (Nokia-D/Tampere)
>> >Cc: linux-omap@vger.kernel.org
>> >Subject: Re: [PATCH] OMAP3: Serial: Improved sleep logic
>> >
>> >* Tero Kristo [100202 01:38]:
>> >> From: Tero Kristo
>> >>
>> >> Only RX interrupt will now kick the sleep prevent timer. In
>> >addition, TX
>> >> fifo status is checked before disabling clocks, this will
>> >prevent occasional
>> >> garbage being printed on serial line. Smartidle is also
>> >disabled while
>> >> entering idle if we have data in the transmit buffer,
>> >because having this
>> >> enabled will prevent wakeups from the TX interrupt, and
>this causes
>> >> pauses while sending large blocks of data.
>> >
>> >Sounds this is for 2.6.34 merge window and does not contain anything
>> >that needs to be fixed for 2.6.33.
>>
>> Yeah, this only fixes a couple of annoying issues, but
>nothing fatal. Also improves power efficiency in some cases
>which is a nice to have feature, and basically eases the
>development of PM code as the UART does not block the system
>from sleeping always.
>
>Yeah cool. Separate issue, but I wonder if we should also clear
>the the first rx character from the fifo to avoid corrupting
>the console. Only when the uart clocks are off and and
>we get a key press. Would be easy to do just do with one
>serial_read_reg(uart->p, UART_RX)..
Yeah, I can try to add this change to the code and see what happens.
>
>Tony
>
>>
>> -Tero
>>
>> >
>> >Regards,
>> >
>> >Tony
>> >
>> >
>> >> Signed-off-by: Tero Kristo
>> >> ---
>> >> arch/arm/mach-omap2/serial.c | 19 +++
>> >> 1 files changed, 15 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/arch/arm/mach-omap2/serial.c
>> >b/arch/arm/mach-omap2/serial.c
>> >> index 777e802..e11dfe9 100644
>> >> --- a/arch/arm/mach-omap2/serial.c
>> >> +++ b/arch/arm/mach-omap2/serial.c
>> >> @@ -317,7 +317,8 @@ static void omap_uart_allow_sleep(struct
>> >omap_uart_state *uart)
>> >> if (!uart->clocked)
>> >> return;
>> >>
>> >> - omap_uart_smart_idle_enable(uart, 1);
>> >> + if (serial_read_reg(uart->p, UART_LSR) & UART_LSR_TEMT)
>> >> + omap_uart_smart_idle_enable(uart, 1);
>> >> uart->can_sleep = 1;
>> >> del_timer(&uart->timer);
>> >> }
>> >> @@ -335,7 +336,11 @@ void omap_uart_prepare_idle(int num)
>> >>
>> >> list_for_each_entry(uart, &uart_list, node) {
>> >> if (num == uart->num && uart->can_sleep) {
>> >> - omap_uart_disable_clocks(uart);
>> >> + if (serial_read_reg(uart->p, UART_LSR) &
>> >> + UART_LSR_TEMT)
>> >> + omap_uart_disable_clocks(uart);
>> >> + else
>> >> + omap_uart_smart_idle_enable(uart, 0);
>> >> return;
>> >> }
>> >> }
>> >> @@ -407,8 +412,14 @@ int omap_uart_can_sleep(void)
>> >> static irqreturn_t omap_uart_interrupt(int irq, void *dev_id)
>> >> {
>> >> struct omap_uart_state *uart = dev_id;
>> >> + u8 lsr;
>> >>
>> >> - omap_uart_block_sleep(uart);
>> >> + lsr = serial_read_reg(uart->p, UART_LSR);
>> >> + /* Check for receive interrupt */
>> >> + if (lsr & UART_LSR_DR)
>> >> + omap_uart_block_sleep(uart);
>> >> + if (lsr & UART_LSR_TEMT && uart->can_sleep)
>> >> + omap_uart_smart_idle_enable(uart, 1);
>> >>
>> >> return IRQ_NONE;
>> >> }
>> >> --
>> >> 1.5.4.3
>> >>
>> >> --
>> >> To unsubscribe from this list: send the line "unsubscribe
>> >linux-omap" in
>> >> the body of a message to majord...@vger.kernel.org
>> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: Serial: Improved sleep logic
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 04 February, 2010 23:20
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH] OMAP3: Serial: Improved sleep logic
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> Only RX interrupt will now kick the sleep prevent timer. In
>addition, TX
>> fifo status is checked before disabling clocks, this will
>prevent occasional
>> garbage being printed on serial line. Smartidle is also
>disabled while
>> entering idle if we have data in the transmit buffer,
>because having this
>> enabled will prevent wakeups from the TX interrupt, and this causes
>> pauses while sending large blocks of data.
>>
>> Signed-off-by: Tero Kristo
>
>After doing some more testing with this, something is not quite right
>still. I haven't taken the time to debug further, but with this patch
>on top of the current PM branch, the timer seems to expire and disable
>clocks whether or not there is UART activity.
This seems to be caused by the buggy timer usage inside serial.c. The code uses
jiffy timers for expire checks, and this is actually invalid inside
omap_sram_idle. Jiffy timer is stopped inside the ARM idle entry (cpu_idle ->
tick_nohz_stop_sched_tick()). This causes the jiffies value to be the same when
we enter idle, and while we are resuming idle, thus making the timer to expire
at rather random time. If you sleep for 4 seconds and wake using serial, the
device enters sleep again after one second. This can be fixed by using
ktime_get() instead of jiffy timer, as ktime_get() uses directly HW 32k tick
timer. I'll hack together a version of this code where I use ktime_get() for
the sleep expiry checks and see if it fixes this issue.
>In particular, using a UART1 console on OMAP3EVM, I notice that while
>typing longer commands (that take more that seconds to type),
>I notice that I loose chars in the middle of typing. /me doesn't like.
>
>So I won't be applying this to the PM branch until we can figure out
>what's happening here.
>
>Kevin
>
>> ---
>> arch/arm/mach-omap2/serial.c | 19 +++
>> 1 files changed, 15 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/serial.c
>b/arch/arm/mach-omap2/serial.c
>> index 777e802..e11dfe9 100644
>> --- a/arch/arm/mach-omap2/serial.c
>> +++ b/arch/arm/mach-omap2/serial.c
>> @@ -317,7 +317,8 @@ static void omap_uart_allow_sleep(struct
>omap_uart_state *uart)
>> if (!uart->clocked)
>> return;
>>
>> -omap_uart_smart_idle_enable(uart, 1);
>> +if (serial_read_reg(uart->p, UART_LSR) & UART_LSR_TEMT)
>> +omap_uart_smart_idle_enable(uart, 1);
>> uart->can_sleep = 1;
>> del_timer(&uart->timer);
>> }
>> @@ -335,7 +336,11 @@ void omap_uart_prepare_idle(int num)
>>
>> list_for_each_entry(uart, &uart_list, node) {
>> if (num == uart->num && uart->can_sleep) {
>> -omap_uart_disable_clocks(uart);
>> +if (serial_read_reg(uart->p, UART_LSR) &
>> +UART_LSR_TEMT)
>> +omap_uart_disable_clocks(uart);
>> +else
>> +omap_uart_smart_idle_enable(uart, 0);
>> return;
>> }
>> }
>> @@ -407,8 +412,14 @@ int omap_uart_can_sleep(void)
>> static irqreturn_t omap_uart_interrupt(int irq, void *dev_id)
>> {
>> struct omap_uart_state *uart = dev_id;
>> +u8 lsr;
>>
>> -omap_uart_block_sleep(uart);
>> +lsr = serial_read_reg(uart->p, UART_LSR);
>> +/* Check for receive interrupt */
>> +if (lsr & UART_LSR_DR)
>> +omap_uart_block_sleep(uart);
>> +if (lsr & UART_LSR_TEMT && uart->can_sleep)
>> +omap_uart_smart_idle_enable(uart, 1);
>>
>> return IRQ_NONE;
>> }
>> --
>> 1.5.4.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: Serial: Improved sleep logic
This patch can be ignored. The RX fifo clear logic did not really work for low
C states (C1 / C2) and you would still get garbage. I'll send an updated patch
where I have replaced the logic by an ignore timer for the first millisecond
after clocks are enabled. Also, I forgot v2 out from this.
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org
>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kristo
>Tero (Nokia-D/Tampere)
>Sent: 10 February, 2010 18:29
>To: linux-omap@vger.kernel.org
>Subject: [PATCH] OMAP3: Serial: Improved sleep logic
>
>From: Tero Kristo
>
>This patch contains following improvements:
>- Only RX interrupt will now kick the sleep prevent timer
>- TX fifo status is checked before disabling clocks, this will prevent
> on-going transmission to be cut
>- Smartidle is disabled while entering idle if we have data in
>the transmit
> buffer because having this enabled would prevent wakeups from the TX
> interrupt and this would cause pauses while sending large
>blocks of data
>- Sleep prevent timer is changed to use ktime_get() instead of
>a jiffy timer
> as jiffy timers are not valid within idle loop (tick
>scheduler is stopped)
>- RX and TX fifos are cleared when clocks are enabled, this
>will purge the
> first character from RX fifo, which is most likely garbage
>
>Signed-off-by: Tero Kristo
>---
> arch/arm/mach-omap2/serial.c | 70
>+++---
> 1 files changed, 45 insertions(+), 25 deletions(-)
>
>diff --git a/arch/arm/mach-omap2/serial.c
>b/arch/arm/mach-omap2/serial.c
>index 837b347..d7d96ba 100644
>--- a/arch/arm/mach-omap2/serial.c
>+++ b/arch/arm/mach-omap2/serial.c
>@@ -23,12 +23,15 @@
> #include
> #include
> #include
>+#include
>
> #include
> #include
> #include
> #include
>
>+#include
>+
> #include "prm.h"
> #include "pm.h"
> #include "prm-regbits-34xx.h"
>@@ -36,13 +39,13 @@
> #define UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV 0x52
> #define UART_OMAP_WER 0x17/* Wake-up enable register */
>
>-#define DEFAULT_TIMEOUT (5 * HZ)
>+#define DEFAULT_TIMEOUT (5LL * NSEC_PER_SEC)
>
> struct omap_uart_state {
> int num;
> int can_sleep;
>- struct timer_list timer;
>- u32 timeout;
>+ ktime_t expire_time;
>+ u64 timeout;
>
> void __iomem *wk_st;
> void __iomem *wk_en;
>@@ -231,6 +234,9 @@ static inline void
>omap_uart_enable_clocks(struct omap_uart_state *uart)
> clk_enable(uart->fck);
> uart->clocked = 1;
> omap_uart_restore_context(uart);
>+
>+ /* Clear RX and TX fifos, as they contain garbage at
>this point */
>+ serial_write_reg(uart->p, UART_FCR, 0xa7);
> }
>
> #ifdef CONFIG_PM
>@@ -302,9 +308,7 @@ static void omap_uart_block_sleep(struct
>omap_uart_state *uart)
> omap_uart_smart_idle_enable(uart, 0);
> uart->can_sleep = 0;
> if (uart->timeout)
>- mod_timer(&uart->timer, jiffies + uart->timeout);
>- else
>- del_timer(&uart->timer);
>+ uart->expire_time = ktime_add_ns(ktime_get(),
>uart->timeout);
> }
>
> static void omap_uart_allow_sleep(struct omap_uart_state *uart)
>@@ -317,25 +321,28 @@ static void omap_uart_allow_sleep(struct
>omap_uart_state *uart)
> if (!uart->clocked)
> return;
>
>- omap_uart_smart_idle_enable(uart, 1);
>+ if (serial_read_reg(uart->p, UART_LSR) & UART_LSR_TEMT)
>+ omap_uart_smart_idle_enable(uart, 1);
> uart->can_sleep = 1;
>- del_timer(&uart->timer);
>-}
>-
>-static void omap_uart_idle_timer(unsigned long data)
>-{
>- struct omap_uart_state *uart = (struct omap_uart_state *)data;
>-
>- omap_uart_allow_sleep(uart);
> }
>
> void omap_uart_prepare_idle(int num)
> {
> struct omap_uart_state *uart;
>+ ktime_t t;
>
> list_for_each_entry(uart, &uart_list, node) {
>+ if (num == uart->num && !uart->can_sleep) {
>+ t = ktime_get();
>+ if (t.tv64 > uart->expire_time.tv64)
>+ uart->can_sleep = 1;
>+ }
> if (num == uart->num && uart->can_sleep) {
>- omap_uart_disable_clocks(uart);
>+ if (serial_read_reg(uart->p, UART_LSR) &
>+ UART_LSR_TEMT)
>+ omap_uart_disable_clocks(uart);
>+ else
>+ omap_uart_smart_idle_enable(uart, 0);
> return;
> }
> }
>@@ -360,6 +367,7 @@ void omap_uart_resume_idle(int num)
> /* Check for normal UART wakeup */
> if (__raw_readl(uart->wk_st) & uart->wk_mask)
> omap_uart_block_sleep(uart);
>+
> return;
> }
> }
>@@ -407,8 +415,14 @@ int omap_uart_can_sleep(void)
> static irqreturn_t omap_uart_interrupt(int irq, void *dev_i
RE: [PATCHv4] OMAP3: Serial: Improved sleep logic
Grr, ktime_get() is not accessible during suspend, and thus this patch causes a
WARN during wakeup from suspend. I'll convert the patch to use
getrawmonotonic() instead, sending out a refreshed one soon.
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org
>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kristo
>Tero (Nokia-D/Tampere)
>Sent: 12 February, 2010 20:23
>To: linux-omap@vger.kernel.org
>Subject: [PATCHv4] OMAP3: Serial: Improved sleep logic
>
>From: Tero Kristo
>
>This patch contains following improvements:
>- Only RX interrupt will now kick the sleep prevent timer
>- TX fifo status is checked before disabling clocks, this will prevent
> on-going transmission to be cut
>- Smartidle is now enabled/disabled only while switching
>clocks, as having
> smartidle enabled while RX/TX prevents any wakeups from being
> received from UART module
>- Sleep prevent timer is changed to use ktime_get() instead of
>a jiffy timer
> as jiffy timers are not valid within idle loop (tick
>scheduler is stopped)
>- Added RX ignore timer for ignoring the first character
>received during
> first millisecond of wakeup, this prevents garbage character
>to be receive
> in low sleep states
>
>Signed-off-by: Tero Kristo
>---
> arch/arm/mach-omap2/serial.c | 79
>+++--
> 1 files changed, 52 insertions(+), 27 deletions(-)
>
>diff --git a/arch/arm/mach-omap2/serial.c
>b/arch/arm/mach-omap2/serial.c
>index 5f3035e..4be9ace 100644
>--- a/arch/arm/mach-omap2/serial.c
>+++ b/arch/arm/mach-omap2/serial.c
>@@ -29,6 +29,8 @@
> #include
> #include
>
>+#include
>+
> #include "prm.h"
> #include "pm.h"
> #include "prm-regbits-34xx.h"
>@@ -42,13 +44,14 @@
> * disabled via sysfs. This also causes that any deeper omap
>sleep states are
> * blocked.
> */
>-#define DEFAULT_TIMEOUT 0
>+#define DEFAULT_TIMEOUT (0LL * NSEC_PER_SEC)
>
> struct omap_uart_state {
> int num;
> int can_sleep;
>- struct timer_list timer;
>- u32 timeout;
>+ ktime_t expire_time;
>+ ktime_t garbage_time;
>+ u64 timeout;
>
> void __iomem *wk_st;
> void __iomem *wk_en;
>@@ -243,6 +246,9 @@ static inline void
>omap_uart_save_context(struct omap_uart_state *uart) {}
> static inline void omap_uart_restore_context(struct
>omap_uart_state *uart) {}
> #endif /* CONFIG_PM && CONFIG_ARCH_OMAP3 */
>
>+static void omap_uart_smart_idle_enable(struct omap_uart_state *uart,
>+ int enable);
>+
> static inline void omap_uart_enable_clocks(struct
>omap_uart_state *uart)
> {
> if (uart->clocked)
>@@ -250,8 +256,12 @@ static inline void
>omap_uart_enable_clocks(struct omap_uart_state *uart)
>
> clk_enable(uart->ick);
> clk_enable(uart->fck);
>+ omap_uart_smart_idle_enable(uart, 0);
> uart->clocked = 1;
> omap_uart_restore_context(uart);
>+
>+ /* Set up garbage timer to ignore RX during first 1ms */
>+ uart->garbage_time = ktime_add_ns(ktime_get(), NSEC_PER_MSEC);
> }
>
> #ifdef CONFIG_PM
>@@ -263,6 +273,7 @@ static inline void
>omap_uart_disable_clocks(struct omap_uart_state *uart)
>
> omap_uart_save_context(uart);
> uart->clocked = 0;
>+ omap_uart_smart_idle_enable(uart, 1);
> clk_disable(uart->ick);
> clk_disable(uart->fck);
> }
>@@ -320,12 +331,9 @@ static void omap_uart_block_sleep(struct
>omap_uart_state *uart)
> {
> omap_uart_enable_clocks(uart);
>
>- omap_uart_smart_idle_enable(uart, 0);
> uart->can_sleep = 0;
> if (uart->timeout)
>- mod_timer(&uart->timer, jiffies + uart->timeout);
>- else
>- del_timer(&uart->timer);
>+ uart->expire_time = ktime_add_ns(ktime_get(),
>uart->timeout);
> }
>
> static void omap_uart_allow_sleep(struct omap_uart_state *uart)
>@@ -338,16 +346,7 @@ static void omap_uart_allow_sleep(struct
>omap_uart_state *uart)
> if (!uart->clocked)
> return;
>
>- omap_uart_smart_idle_enable(uart, 1);
> uart->can_sleep = 1;
>- del_timer(&uart->timer);
>-}
>-
>-static void omap_uart_idle_timer(unsigned long data)
>-{
>- struct omap_uart_state *uart = (struct omap_uart_state *)data;
>-
>- omap_uart_allow_sleep(uart);
> }
>
> void omap_uart_prepare_idle(int num)
>@@ -355,8 +354,14 @@ void omap_uart_prepare_idle(int num)
> struct omap_uart_state *uart;
>
> list_for_each_entry(uart, &uart_list, node) {
>+ if (num == uart->num && !uart->can_sleep &&
>uart->timeout)
>+ if (ktime_get().tv64 > uart->expire_time.tv64)
>+ uart->can_sleep = 1;
>+
> if (num == uart->num && uart->can_sleep) {
>- omap_uart_disable_clocks(uart);
>+ if (serial_read_reg(uart->p, UART_LSR) &
>+ UART_LSR_TEMT)
>+ omap_uart_disable_clocks(uart);
>
RE: [PATCHv5] OMAP3: Serial: Improved sleep logic
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 24 February, 2010 18:05
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCHv5] OMAP3: Serial: Improved sleep logic
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> This patch contains following improvements:
>> - Only RX interrupt will now kick the sleep prevent timer
>> - TX fifo status is checked before disabling clocks, this
>will prevent
>> on-going transmission to be cut
>> - Smartidle is now enabled/disabled only while switching
>clocks, as having
>> smartidle enabled while RX/TX prevents any interrupts from being
>> received from UART module
>> - Sleep prevent timer is changed to use timespec instead of
>a jiffy timer
>> as jiffy timers are not valid within idle loop (tick
>scheduler is stopped)
>
>Could also probably use hrtimers for this.
Maybe, I didn't try this out though. It is possible that there are some issues
as hrtimers use ktime() as far as I understand and it is not accessible during
suspend. There is a separate issue with this patch and suspend though, I am
currently working on a fix for that. Suspend skewes the timebase even more, and
we get expire timers that point far into the future after suspend.
>
>That being said, I'm not sure what is the problem you're trying to
>solve with this change. I don't see any timings that are timing events
>inside the idle loop.
Here is the call-chain that currently accesses jiffies count incorrectly:
cpu_idle:
tick_nohz_stop_sched_tick(1); /* jiffy timer stops here */
omap_sram_idle();
omap_uart_prepare_idle();
asm("wfi"); /* sleep here for N seconds */
omap_uart_resume_idle(); /* This call uses incorrect jiffy timer now */
tick_nohz_restart_sched_tick(); /* jiffy timer restarted here, and jiffy
timer is refreshed also to correct value */
>
>> - Added RX ignore timer for ignoring the first character
>received during
>> first millisecond of wakeup, this prevents garbage
>character to be receive
>> in low sleep states
>>
>> Signed-off-by: Tero Kristo
>
>Something is still not quite right here.
>
>This doesn't work on my n900 here when testing this patch on top of
>the PM branch. The default is now a default timeout of zero. When I
>enable a 5 sec. timeout for UART2 on RX-51, when the timer expires, I
>no longer have response on the console.
>
>To test, I booted my n900 with init=/bin/sh to avoid all the setup
>done by /sbin/preinit. Then I enabled a timeout for UART2 only, and
>then the console hangs.
>
>Here's my hunch as to what's happening:
>
>I think the problem is a deadlock in getrawmonotonic(). Nested calls
>here will deadlock due to the xtime_lock being held.
Looking at the seqlock code, I think a seqlock reader can "hang" only in a case
where someone is constantly writing the seqlock. And, as we are inside
interrupt, this should not be possible.
>When updading the timeout, sleep_timeout_store() does a
>getrawmonotonic() to update the expiry time. While this happening,
>the UART interrupt could fire, causing an omap_uart_block_sleep()
>which would also getrawmonotonic() and deadlock in interrupt mode.
It does not really explain why it hangs after the 5 second period though, as
the device has called getrawmonotonic several times by this already. I have not
seen this kind of behavior in my testing, even while fiddling with the
sleep_timeout_store().
Anyway, I'll attempt to re-run my test on the latest PM / master branches and
see what happens.
>
>Kevin
>
>> ---
>> arch/arm/mach-omap2/serial.c | 98
>+
>> 1 files changed, 69 insertions(+), 29 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/serial.c
>b/arch/arm/mach-omap2/serial.c
>> index 5f3035e..f49c465 100644
>> --- a/arch/arm/mach-omap2/serial.c
>> +++ b/arch/arm/mach-omap2/serial.c
>> @@ -29,6 +29,8 @@
>> #include
>> #include
>>
>> +#include
>> +
>> #include "prm.h"
>> #include "pm.h"
>> #include "prm-regbits-34xx.h"
>> @@ -42,13 +44,14 @@
>> * disabled via sysfs. This also causes that any deeper
>omap sleep states are
>> * blocked.
>> */
>> -#define DEFAULT_TIMEOUT 0
>> +#define DEFAULT_TIMEOUT (0LL * NSEC_PER_SEC)
>>
>> struct omap_uart_state {
>> int num;
>> int can_sleep;
>> -struct timer_list timer;
>> -u32 timeout;
>> +struct timespec expire_time;
>> +struct timespec garbage_time;
>> +u64 timeout;
>>
>> void __iomem *wk_st;
>> void __iomem *wk_en;
>> @@ -243,6 +246,9 @@ static inline void
>omap_uart_save_context(struct omap_uart_state *uart) {}
>> static inline void omap_uart_restore_context(struct
>omap_uart_state *uart) {}
>> #endif /* CONFIG_PM && CONFIG_ARCH_OMAP3 */
>>
>> +static void omap_uart_smart_idle_enable(struct
>omap_uart_state *uart,
>> +int enable);
>> +
>> static inline void omap_uart_enable_clocks(struct
>omap_uart_state *uart)
>> {
RE: [PATCHv5] OMAP3: Serial: Improved sleep logic
>-Original Message- >From: linux-omap-ow...@vger.kernel.org >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Kevin Hilman >Sent: 25 February, 2010 17:21 >To: Kristo Tero (Nokia-D/Tampere) >Cc: linux-omap@vger.kernel.org >Subject: Re: [PATCHv5] OMAP3: Serial: Improved sleep logic > > writes: > >[...] > >>>Here's my hunch as to what's happening: >>> >>>I think the problem is a deadlock in getrawmonotonic(). Nested calls >>>here will deadlock due to the xtime_lock being held. >> >> Looking at the seqlock code, I think a seqlock reader can >"hang" only in a case where someone is constantly writing the >seqlock. And, as we are inside interrupt, this should not be possible. >> >>>When updading the timeout, sleep_timeout_store() does a >>>getrawmonotonic() to update the expiry time. While this happening, >>>the UART interrupt could fire, causing an omap_uart_block_sleep() >>>which would also getrawmonotonic() and deadlock in interrupt mode. >> >> It does not really explain why it hangs after the 5 second >period though, as the device has called getrawmonotonic >several times by this already. I have not seen this kind of >behavior in my testing, even while fiddling with the >sleep_timeout_store(). > >minor clarification... > >For me the hang is not after the 5 second timeout. For me it happens >as soon as I write a non-zero value to >/sys/devices/.../serial8250.2/sleep_timeout. It looks somewhat weird... I did some debugging on this today and I am seeing the same hang here, and it actually seems to be caused by the getrawmonotonic() somehow, as the system did not hang anymore after I removed the calls. Anyway, I figured another way to solve the issues I am seeing. I reverted back to using jiffy timers, but added a workqueue for wakeups; now wakeup timers are kicked into action after the timebase is restored. I'll post the new patch right away. There is still one issue with the UART though; some TX is still lost because PM code does not currently prevent CORE off while PER is active, basically resetting the PER domain when CORE goes off. This would be fixed by the cpuidle set I posted a bit back. Another note, I am seeing really strange behavior for my n900 with current linux-omap tree. PM branch boots up nicely, but it does not go into dynamic idle until I force it to suspend once Also, master branch crashes mid-boot to an ubifs caused DMA failure. -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: [PATCHv6 9/9] OMAP3: PM: Added support for suspending to INACTIVE state
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 02 March, 2010 01:43
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCHv6 9/9] OMAP3: PM: Added support for
>suspending to INACTIVE state
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> With the new support functions this is now possible.
>Suspending to INACTIVE
>> is useful for testing purposes.
>>
>> Signed-off-by: Tero Kristo
>> ---
>> arch/arm/mach-omap2/pm34xx.c | 11 ++-
>> 1 files changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c
>b/arch/arm/mach-omap2/pm34xx.c
>> index cdbedcf..41d6cc3 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -633,11 +633,12 @@ int set_pwrdm_state(struct powerdomain
>*pwrdm, u32 state)
>> if (pwrdm == NULL || IS_ERR(pwrdm))
>> return -EINVAL;
>>
>> -while (!(pwrdm->pwrsts & (1 << state))) {
>> -if (state == PWRDM_POWER_OFF)
>> -return ret;
>> -state--;
>> -}
>
>The comment above set_pwrdm_state() says only ON & RET are supported.
>Please update that comment as well.
True, ancient info there. OFF for example has been supported for ages already.
>
>
>> +if (state != PWRDM_POWER_INACTIVE)
>> +while (!(pwrdm->pwrsts & (1 << state))) {
>> +if (state == PWRDM_POWER_OFF)
>> +return ret;
>> +state--;
>> +}
>
>I think all powerdomains can be inactive right?
Yes.
>I think it would be cleaner to just have all the pwrdm->pwrsts fields
>include intactive as a valid option.
>
>Something like the patch below. IIRC, you did something like this in
>one of the earlier versions of the patch.
Yeah, something like this was done previously, however Paul did not like the
idea of changing the generic powerdomain code too much so I dropped it
completely. It is now done only via the support functions in patch #1, and only
done for the powerdomains that actually need it for the cpuidle
(mpu/core/neon.) It would be possible to add support for the rest of the
powerdomains also, but I decided to drop this in favor of getting the patch set
in.
>
>Kevin
>
>diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h
>b/arch/arm/plat-omap/include/plat/powerdomain.h
>index a1ecd47..c692472 100644
>--- a/arch/arm/plat-omap/include/plat/powerdomain.h
>+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
>@@ -31,17 +31,17 @@
> #define PWRDM_MAX_PWRSTS 4
>
> /* Powerdomain allowable state bitfields */
>-#define PWRSTS_OFF_ON ((1 << PWRDM_POWER_OFF) | \
>+#define PWRSTS_ON ((1 << PWRDM_POWER_INACTIVE) | \
>(1 << PWRDM_POWER_ON))
>
>+#define PWRSTS_OFF_ON ((1 << PWRDM_POWER_OFF) | PWRSTS_ON)
>+
> #define PWRSTS_OFF_RET((1 << PWRDM_POWER_OFF) | \
>(1 << PWRDM_POWER_RET))
>
>-#define PWRSTS_RET_ON ((1 << PWRDM_POWER_RET) | \
>- (1 << PWRDM_POWER_ON))
>-
>-#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 << PWRDM_POWER_ON))
>+#define PWRSTS_RET_ON ((1 << PWRDM_POWER_RET) | PWRSTS_ON)
>
>+#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | PWRSTS_ON)
>
> /* Powerdomain flags */
> #define PWRDM_HAS_HDWR_SAR(1 << 0) /* hardware
>save-and-restore support */
>--
To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv6 4/9] OMAP3: PM: Removed pwrdm state hacking from omap_sram_idle
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 02 March, 2010 01:32
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCHv6 4/9] OMAP3: PM: Removed pwrdm state
>hacking from omap_sram_idle
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> Following hacks will be moved inside cpuidle in subsequent patch:
>>
>> - CAM domain prevents idle completely
>> - PER should not go OFF if core remains active
>>
>> This simplifies the design and allows cpuidle to keep better
>track of which
>> power states system will actually enter.
>>
>> Signed-off-by: Tero Kristo
>
>I think this should be combined with PATCH 7. IOW, the removal and
>re-addition should be in the same patch.
Ok, will change this.
>
>Kevin
>
>> ---
>> arch/arm/mach-omap2/pm34xx.c | 19 ++-
>> 1 files changed, 2 insertions(+), 17 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c
>b/arch/arm/mach-omap2/pm34xx.c
>> index c2d80fc..cdbedcf 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -93,7 +93,6 @@ static int (*_omap_save_secure_sram)(u32 *addr);
>>
>> static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
>> static struct powerdomain *core_pwrdm, *per_pwrdm;
>> -static struct powerdomain *cam_pwrdm;
>>
>> static struct prm_setup_vc prm_setup = {
>> .clksetup = 0xff,
>> @@ -373,7 +372,6 @@ void omap_sram_idle(void)
>> int core_next_state = PWRDM_POWER_ON;
>> int core_prev_state, per_prev_state;
>> u32 sdrc_pwr = 0;
>> -int per_state_modified = 0;
>>
>> if (!_omap_sram_idle)
>> return;
>> @@ -411,20 +409,11 @@ void omap_sram_idle(void)
>> core_next_state = omap3_pwrdm_read_next_pwrst(core_pwrdm);
>> if (per_next_state < PWRDM_POWER_ON) {
>> omap2_gpio_prepare_for_idle(per_next_state);
>> -if (per_next_state == PWRDM_POWER_OFF) {
>> -if (core_next_state == PWRDM_POWER_ON) {
>> -per_next_state = PWRDM_POWER_RET;
>> -pwrdm_set_next_pwrst(per_pwrdm,
>per_next_state);
>> -per_state_modified = 1;
>> -} else
>> -omap3_per_save_context();
>> -}
>> +if (per_next_state == PWRDM_POWER_OFF)
>> +omap3_per_save_context();
>> omap_uart_prepare_idle(2);
>> }
>>
>> -if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
>> -omap2_clkdm_deny_idle(mpu_pwrdm->pwrdm_clkdms[0]);
>> -
>> /*
>> * Disable smartreflex before entering WFI.
>> * Only needed if we are going to enter retention or off.
>> @@ -554,8 +543,6 @@ void omap_sram_idle(void)
>> }
>> omap2_gpio_resume_after_idle();
>> omap_uart_resume_idle(2);
>> -if (per_state_modified)
>> -pwrdm_set_next_pwrst(per_pwrdm,
>PWRDM_POWER_OFF);
>> }
>>
>> /* Disable IO-PAD and IO-CHAIN wakeup */
>> @@ -564,7 +551,6 @@ void omap_sram_idle(void)
>> omap3_disable_io_chain();
>> }
>>
>> -
>> pwrdm_post_transition();
>> }
>>
>> @@ -1239,7 +1225,6 @@ static int __init omap3_pm_init(void)
>> neon_pwrdm = pwrdm_lookup("neon_pwrdm");
>> per_pwrdm = pwrdm_lookup("per_pwrdm");
>> core_pwrdm = pwrdm_lookup("core_pwrdm");
>> -cam_pwrdm = pwrdm_lookup("cam_pwrdm");
>>
>> neon_clkdm = clkdm_lookup("neon_clkdm");
>> mpu_clkdm = clkdm_lookup("mpu_clkdm");
>> --
>> 1.5.4.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv6 1/9] OMAP3: PM: Added support functions for omap3 pwrdm handling
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 02 March, 2010 01:17
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCHv6 1/9] OMAP3: PM: Added support functions
>for omap3 pwrdm handling
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> Added omap3_pwrdm_set_next_pwrst and
>omap3_pwrdm_read_next_pwrst. These
>> functions add support for INACTIVE and ON states to the standard OMAP
>> powerdomain functions, and add caching logic for the next
>state. These
>> functions are used in subsequent patches to simplify the
>logic of the idle
>> loop.
>>
>> Signed-off-by: Tero Kristo
>> ---
>> arch/arm/mach-omap2/pm.h |2 +
>> arch/arm/mach-omap2/pm34xx.c | 60
>+-
>> 2 files changed, 61 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
>> index 75aa685..1d9a740 100644
>> --- a/arch/arm/mach-omap2/pm.h
>> +++ b/arch/arm/mach-omap2/pm.h
>> @@ -67,6 +67,8 @@ static inline void omap3_pm_init_vc(struct
>prm_setup_vc *setup_vc)
>>
>> extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
>> extern int omap3_pm_set_suspend_state(struct powerdomain
>*pwrdm, int state);
>> +extern int omap3_pwrdm_set_next_pwrst(struct powerdomain
>*pwrdm, u8 pwrst);
>> +extern int omap3_pwrdm_read_next_pwrst(struct powerdomain *pwrdm);
>>
>> extern u32 wakeup_timer_seconds;
>> extern struct omap_dm_timer *gptimer_wakeup;
>> diff --git a/arch/arm/mach-omap2/pm34xx.c
>b/arch/arm/mach-omap2/pm34xx.c
>> index 1359ec9..f20d3d8 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -576,6 +576,64 @@ int omap3_can_sleep(void)
>> return 1;
>> }
>>
>> +struct powerdomain_data {
>> +u8 next_state;
>> +u8 init_done;
>> +};
>> +
>> +static struct powerdomain_data mpu_pwrdm_data;
>> +static struct powerdomain_data core_pwrdm_data;
>> +static struct powerdomain_data neon_pwrdm_data;
>> +
>> +static struct powerdomain_data *get_pwrdm_data(struct
>powerdomain *pwrdm)
>> +{
>> +if (pwrdm == mpu_pwrdm)
>> +return &mpu_pwrdm_data;
>> +else if (pwrdm == core_pwrdm)
>> +return &core_pwrdm_data;
>> +else if (pwrdm == neon_pwrdm)
>> +return &neon_pwrdm_data;
>> +return NULL;
>> +}
>> +
>> +int omap3_pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
>
>I think this func should be documented along the lines of the
>changelog.
>It should describe the caching and the fact that 'INACTIVE' is a state
>that can be read, but not written.
Ok, will do the change.
>> +{
>> +struct powerdomain_data *data = get_pwrdm_data(pwrdm);
>> +u8 prg_pwrst;
>> +
>> +if (!data)
>> +return pwrdm_set_next_pwrst(pwrdm, pwrst);
>> +
>> +if (!data->init_done)
>> +data->init_done = 1;
>
>Not sure I follow the purpose of the 'init_done' flag here,
>but I'm having
>an averse reaction to it.
init_done actually means if the cache is valid or not. If not, we ignore the
current cached state. Another way of doing this would be to initialize all
values at proper point during boot by reading from HW, or just put the HW reset
values to the cache during compile time. The cache validity bit is needed in
the read_next_pwrst code also below.
>
>> +else if (data->next_state == pwrst)
>> +return 0;
>> +
>> +if (pwrst == PWRDM_POWER_INACTIVE)
>> +prg_pwrst = PWRDM_POWER_ON;
>> +else
>> +prg_pwrst = pwrst;
>> +
>> +pwrdm_set_next_pwrst(pwrdm, prg_pwrst);
>> +
>> +if (pwrst == PWRDM_POWER_ON)
>> +omap2_clkdm_deny_idle(pwrdm->pwrdm_clkdms[0]);
>> +else
>> +omap2_clkdm_allow_idle(pwrdm->pwrdm_clkdms[0]);
>> +
>> +data->next_state = pwrst;
>> +return 0;
>> +}
>> +
>> +int omap3_pwrdm_read_next_pwrst(struct powerdomain *pwrdm)
>> +{
>> +struct powerdomain_data *data = get_pwrdm_data(pwrdm);
>> +
>> +if (!data || !data->init_done)
>> +return pwrdm_read_next_pwrst(pwrdm);
>> +return data->next_state;
>> +}
>> +
>> /* This sets pwrdm state (other than mpu & core. Currently only ON &
>> * RET are supported. Function is assuming that clkdm doesn't have
>> * hw_sup mode enabled. */
>> @@ -604,7 +662,7 @@ int set_pwrdm_state(struct powerdomain
>*pwrdm, u32 state)
>> pwrdm_wait_transition(pwrdm);
>> }
>>
>> -ret = pwrdm_set_next_pwrst(pwrdm, state);
>> +ret = omap3_pwrdm_set_next_pwrst(pwrdm, state);
>> if (ret) {
>> printk(KERN_ERR "Unable to set state of
>powerdomain: %s\n",
>> pwrdm->name);
>> --
>> 1.5.4.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
To unsubscribe from this list: send the
RE: [PATCHv6 9/9] OMAP3: PM: Added support for suspending to INACTIVE state
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 08 March, 2010 19:16
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCHv6 9/9] OMAP3: PM: Added support for
>suspending to INACTIVE state
>
> writes:
>
>[...]
>
>> True, ancient info there. OFF for example has been supported
>for ages already.
>>
>>>
>>>
+ if (state != PWRDM_POWER_INACTIVE)
+ while (!(pwrdm->pwrsts & (1 << state))) {
+ if (state == PWRDM_POWER_OFF)
+ return ret;
+ state--;
+ }
>>>
>>>I think all powerdomains can be inactive right?
>>
>> Yes.
>>
>>>I think it would be cleaner to just have all the pwrdm->pwrsts fields
>>>include intactive as a valid option.
>>>
>>>Something like the patch below. IIRC, you did something like this in
>>>one of the earlier versions of the patch.
>>
>> Yeah, something like this was done previously, however Paul did not
>> like the idea of changing the generic powerdomain code too much so I
>> dropped it completely. It is now done only via the support functions
>> in patch #1, and only done for the powerdomains that actually need
>> it for the cpuidle (mpu/core/neon.) It would be possible to add
>> support for the rest of the powerdomains also, but I decided to drop
>> this in favor of getting the patch set in.
>
>I'm not proposing changing any of the other powerdomain code. Just
>changing the PWRSTS_* defines, essentially so that INACTIVE is
>a valid state.
>
>That will eliminate the need for a special check for inactive in this
>patch.
This is a chicken-egg problem. If you alter the PWRSTS_* defines, you need to
change implementation of pwrdm_set_next_pwrst() as it would accept INACTIVE
also, which is not supported by the code right now.
>
>Kevin
>
>>>
>>>diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h
>>>b/arch/arm/plat-omap/include/plat/powerdomain.h
>>>index a1ecd47..c692472 100644
>>>--- a/arch/arm/plat-omap/include/plat/powerdomain.h
>>>+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
>>>@@ -31,17 +31,17 @@
>>> #define PWRDM_MAX_PWRSTS4
>>>
>>> /* Powerdomain allowable state bitfields */
>>>-#define PWRSTS_OFF_ON ((1 << PWRDM_POWER_OFF) | \
>>>+#define PWRSTS_ON ((1 << PWRDM_POWER_INACTIVE) | \
>>> (1 << PWRDM_POWER_ON))
>>>
>>>+#define PWRSTS_OFF_ON ((1 << PWRDM_POWER_OFF)
>| PWRSTS_ON)
>>>+
>>> #define PWRSTS_OFF_RET ((1 << PWRDM_POWER_OFF) | \
>>> (1 << PWRDM_POWER_RET))
>>>
>>>-#define PWRSTS_RET_ON ((1 << PWRDM_POWER_RET) | \
>>>- (1 << PWRDM_POWER_ON))
>>>-
>>>-#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 << PWRDM_POWER_ON))
>>>+#define PWRSTS_RET_ON ((1 << PWRDM_POWER_RET)
>| PWRSTS_ON)
>>>
>>>+#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | PWRSTS_ON)
>>>
>>> /* Powerdomain flags */
>>> #define PWRDM_HAS_HDWR_SAR (1 << 0) /* hardware
>>>save-and-restore support */
>>>
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: GPIO: Added dynamic control logic for pad wakeups
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 08 March, 2010 19:06
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH] OMAP3: GPIO: Added dynamic control logic
>for pad wakeups
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> Pad wakeups are now enabled if the corresponding GPIO
>interrupt is enabled.
>>
>> Applies on top of PM branch.
>>
>> Signed-off-by: Tero Kristo
>> Signed-off-by: Jouni Hogander
>
>I just discovered this one in patchwork... sorry for the delay.
>
>Changes in wakeup state should not be directly correlated to interrupt
>enabled GPIOs. Rather, this should only be done for GPIOs that are
>explicitly wakeup enabled (via enable_irq_wake(), which in turn
>calls gpio_wake_enable()).
This logic somehow escapes me... I would guess drivers should not care during
dynamic idle whether the device is in off/ret/ina and interrupts should just
work. This is done to make this happen. Also, I understood that gpio wakeup
logic is needed for the suspend wakeup, which is quite different from dynamic
idle wakeup.
However, if this is intended behavior for the kernel, then I will accept it.
You are saying the code below should be moved into the gpio_wake_enable() /
disable() calls?
>
>A couple other minor comments below...
>
>> ---
>> arch/arm/plat-omap/gpio.c | 22 +-
>> 1 files changed, 21 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
>> index e242112..fa79db2 100644
>> --- a/arch/arm/plat-omap/gpio.c
>> +++ b/arch/arm/plat-omap/gpio.c
>> @@ -267,6 +267,7 @@ static struct gpio_bank gpio_bank_34xx[6] = {
>> #define OMAP34XX_PAD_SAFE_MODE 0x7
>> #define OMAP34XX_PAD_IN_PU_GPIO 0x11c
>> #define OMAP34XX_PAD_IN_PD_GPIO 0x10c
>> +#define OMAP34XX_PAD_WAKE_EN (1 << 14)
>
>Can use BIT(14) here
>
>> struct omap3_gpio_regs {
>> u32 sysconfig;
>> @@ -713,6 +714,8 @@ static inline void
>set_24xx_gpio_triggering(struct gpio_bank *bank, int gpio,
>> {
>> void __iomem *base = bank->base;
>> u32 gpio_bit = 1 << gpio;
>> +struct gpio_pad *pad;
>> +int gpio_num;
>> u32 val;
>>
>> if (cpu_is_omap44xx()) {
>> @@ -750,6 +753,23 @@ static inline void
>set_24xx_gpio_triggering(struct gpio_bank *bank, int gpio,
>> * GPIO wakeup request can only be
>generated on edge
>> * transitions
>> */
>
>The comment above needs to stay with the original code.
>
>> +pad = gpio_pads;
>> +
>> +gpio_num = bank->virtual_irq_start -
>IH_GPIO_BASE +
>> +gpio;
>> +/* Find the pad corresponding the GPIO */
>> +while (pad->gpio >= 0 && pad->gpio != gpio_num)
>> +pad++;
>> +/* Enable / disable pad wakeup */
>> +if (pad->gpio == gpio_num) {
>> +val = omap_ctrl_readw(pad->offset);
>> +if (trigger & IRQ_TYPE_EDGE_BOTH)
>> +val |= OMAP34XX_PAD_WAKE_EN;
>> +else
>> +val &=
>~(u16)OMAP34XX_PAD_WAKE_EN;
>> +omap_ctrl_writew(val, pad->offset);
>> +}
>> +
>> if (trigger & IRQ_TYPE_EDGE_BOTH)
>> __raw_writel(1 << gpio, bank->base
>> + OMAP24XX_GPIO_SETWKUENA);
>> @@ -1654,7 +1674,7 @@ static int __init omap3_gpio_pads_init(void)
>> gpio_pads[gpio_amt].gpio = -1;
>> return 0;
>> }
>> -late_initcall(omap3_gpio_pads_init);
>> +early_initcall(omap3_gpio_pads_init);
>
>This change isn't explained in the changelog and appears unrelated to
>this patch.
The reason for this change is that we need the gpio->pad mapping early now to
enable wakeups properly. Otherwise some components can enable gpio interrupts
early in the boot cycle and they will miss their wakeup setting because the map
does not exist yet. I think another way to do this would be to enable wakeups
for all enabled interrupts during the omap3_gpio_pads_init().
-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: [PATCHv6] OMAP3: Serial: Improved sleep logic
>-Original Message- >From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: 10 March, 2010 20:21 >To: Kristo Tero (Nokia-D/Tampere) >Cc: linux-omap@vger.kernel.org >Subject: Re: [PATCHv6] OMAP3: Serial: Improved sleep logic > >Kevin Hilman writes: > >> Tero Kristo writes: >> >>> From: Tero Kristo >>> >>> This patch contains following improvements: >>> - Only RX interrupt will now kick the sleep prevent timer >>> - TX fifo status is checked before disabling clocks, this >will prevent >>> on-going transmission to be cut >>> - Smartidle is now enabled/disabled only while switching >clocks, as having >>> smartidle enabled while RX/TX prevents any wakeups from >being received >>> from UART module >>> - Added workqueue for wakeup checks, as jiffy timer access >within the >>> idle loop results into skewed timers as jiffy timers are stopped >>> - Added garbage_timer for ignoring the first character >received during >>> the first tick after clock enable, this prevents garbage >characters to be >>> received in low sleep states >>> - omap_uart_enable_irqs() changed to use enable_irq / >disable_irq instead >>> of request / free. Using request/free changes the >behavior after first >>> suspend due to reversed interrupt handler ordering >>> >>> Signed-off-by: Tero Kristo >> >> Thanks Tero. This version looks good. >> >> Adding to pm-fixes queue for 2.6.34-rcX after minor change below... >> > >There's still something slightly strange going on here... > >I noticed via powertop that the garbage timer is now one of the top >reasons for wakeup in an idle system. Seems like the garbage timer >is firing when it shouldn't be, and triggering unnecessary wakeups > >Based on powertop stats, the garbage timer is firing about 3x more >often than the GPtimer that should be waking the system. You get one timer expire each wakeup cycle, but the system actually fires its own timer for each UART, thus you get 3x. It is possible to optimize the timer a bit by only firing it if we have a wakeup from UART, but this probably causes occasional garbage to the console, if a wakeup from some other source than UART and UART RX happen at the same time. Might be the lesser of two evils though. I can experiment with this change a bit and see how it behaves. > >I haven't dug any deeper, but this needs to be fixed before merging >upstream. > >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: [PATCHv6] OMAP3: Serial: Improved sleep logic
>-Original Message- >From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: 11 March, 2010 18:30 >To: Kristo Tero (Nokia-D/Tampere) >Cc: linux-omap@vger.kernel.org >Subject: Re: [PATCHv6] OMAP3: Serial: Improved sleep logic > > writes: > >> >> >>>-Original Message- >>>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] >>>Sent: 10 March, 2010 20:21 >>>To: Kristo Tero (Nokia-D/Tampere) >>>Cc: linux-omap@vger.kernel.org >>>Subject: Re: [PATCHv6] OMAP3: Serial: Improved sleep logic >>> >>>Kevin Hilman writes: >>> Tero Kristo writes: > From: Tero Kristo > > This patch contains following improvements: > - Only RX interrupt will now kick the sleep prevent timer > - TX fifo status is checked before disabling clocks, this >>>will prevent > on-going transmission to be cut > - Smartidle is now enabled/disabled only while switching >>>clocks, as having > smartidle enabled while RX/TX prevents any wakeups from >>>being received > from UART module > - Added workqueue for wakeup checks, as jiffy timer access >>>within the > idle loop results into skewed timers as jiffy timers are stopped > - Added garbage_timer for ignoring the first character >>>received during > the first tick after clock enable, this prevents garbage >>>characters to be > received in low sleep states > - omap_uart_enable_irqs() changed to use enable_irq / >>>disable_irq instead > of request / free. Using request/free changes the >>>behavior after first > suspend due to reversed interrupt handler ordering > > Signed-off-by: Tero Kristo Thanks Tero. This version looks good. Adding to pm-fixes queue for 2.6.34-rcX after minor change below... >>> >>>There's still something slightly strange going on here... >>> >>>I noticed via powertop that the garbage timer is now one of the top >>>reasons for wakeup in an idle system. Seems like the garbage timer >>>is firing when it shouldn't be, and triggering unnecessary wakeups >>> >>>Based on powertop stats, the garbage timer is firing about 3x more >>>often than the GPtimer that should be waking the system. >> >> You get one timer expire each wakeup cycle, but the system >actually fires its own timer for each UART, thus you get 3x. >It is possible to optimize the timer a bit by only firing it >if we have a wakeup from UART, but this probably causes >occasional garbage to the console, if a wakeup from some other >source than UART and UART RX happen at the same time. Might be >the lesser of two evils though. >> >> I can experiment with this change a bit and see how it behaves. >> > >OK, the 3x makes sense, but the garbage timer should never be the >cause of a wakeup. > >Maybe you also need to be sure that the garbage timer is disabled >before clocks are disabled so it doesn't fire and cause a wakeup. Yeah, that's another addition that I can do, but I don't think the system is actually woken up even though powertop claims so. Powertop is not too reliable wakeup source indicator, it only shows the number of expired timers / interrupts in most cases, but it does not know whether the device was sleeping when the interrupt was raised or not. The number of wakeups can be reliably seen from the number of PRCM interrupts that have occurred, but powertop does not parse the results too well for OMAP3 currently. And, there is no wakeup source indicator anyway available that would be exported from the kernel currently. I have fiddled at some point with a patch that does this, but I never posted it anywhere. -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
