All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@deeprootsystems.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: linux-omap@vger.kernel.org
Subject: hwmod and PER going idle before WFI
Date: Tue, 24 Nov 2009 11:03:23 -0800	[thread overview]
Message-ID: <87fx83vj7o.fsf@deeprootsystems.com> (raw)

Hi Paul,

In working with the UART conversion to hwmod, I noticed something I
don't see when not using hwmod for managing the UARTs.

Namely, in the idle path for PER we do disable the PER UART (via
omap_uart_prepare_for_idle(2)) and then the GPIO context is saved via
omap3_per_save_context();

When switching to use omap_hwmod, I noticed via crashes and then via
lauterbach that as soon as UART3 clocks are disabled, PER goes idle.
This causes the subsequent GPIO context save to fault since PER has
gone idle.

I seem to remember having a similar problem before when the problem
was in the management of autodeps cause by a mis-merge.

The patch below is a hack/workaround that just moves the UART idle after
the GPIO context save because I haven't found the root cause yet.  

Any ideas what might be happening here?

Kevin


commit 5f3cbd67a54ae8b8cecbbd9ec3f55ffe07625e88
Author: Kevin Hilman <khilman@deeprootsystems.com>
Date:   Mon Nov 23 11:05:02 2009 -0800

    temp: OMAP3: PM: GPIO: disable PER UART after GPIO save
    
    FIXME: GPIO core needs to use clock API to prevent this.
    
    When PER UARTs are disabled in idle path and no GPIOs are in use,
    the PER block may go idle.  This causes the GPIO context save
    that happens right after UART disabling to fail with data aborts
    when accessing the GPIO regs in PER.

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 627a509..da32764 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -398,7 +398,6 @@ void omap_sram_idle(void)
 	per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
 	core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
 	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) {
@@ -408,6 +407,7 @@ void omap_sram_idle(void)
 			} else
 				omap3_per_save_context();
 		}
+		omap_uart_prepare_idle(2);
 	}
 
 	if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)

             reply	other threads:[~2009-11-24 19:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-24 19:03 Kevin Hilman [this message]
2009-11-24 19:33 ` hwmod and PER going idle before WFI Cousson, Benoit
2009-11-24 19:44   ` Kevin Hilman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fx83vj7o.fsf@deeprootsystems.com \
    --to=khilman@deeprootsystems.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.