diff mbox

[RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod

Message ID 1350922532-26338-1-git-send-email-t-kristo@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Tero Kristo Oct. 22, 2012, 4:15 p.m. UTC
When waking up from off-mode, some IP blocks are reset automatically by
hardware. For this reason, software must wait until the reset has
completed before attempting to access the IP block.

This patch fixes for example the bug introduced by commit
6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c ("mmc: omap_hsmmc: remove access
to SYSCONFIG register"), in which the MMC IP block is reset during
off-mode entry, but the code expects the module to be already available
during the execution of context restore.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Venkatraman S <svenkatr@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

Comments

Kevin Hilman Oct. 22, 2012, 9:46 p.m. UTC | #1
Tero Kristo <t-kristo@ti.com> writes:

> When waking up from off-mode, some IP blocks are reset automatically by
> hardware. For this reason, software must wait until the reset has
> completed before attempting to access the IP block.
>
> This patch fixes for example the bug introduced by commit
> 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c ("mmc: omap_hsmmc: remove access
> to SYSCONFIG register"), in which the MMC IP block is reset during
> off-mode entry, but the code expects the module to be already available
> during the execution of context restore.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Benoit Cousson <b-cousson@ti.com>
> Cc: Venkatraman S <svenkatr@ti.com>

I can confirm that this patch the regression in my OMAP3 PM tests where
suspend test (to retention or off) failed if ran after the off-idle
test.

Tested-by: Kevin Hilman <khilman@ti.com>

on 3530/Overo, 3730/OveroSTORM, 3730/Beagle-xM

Thanks Tero for the fix,

Kevin
Shubhrajyoti Datta Oct. 23, 2012, 3:43 p.m. UTC | #2
On Tue, Oct 23, 2012 at 3:16 AM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> Tero Kristo <t-kristo@ti.com> writes:
>
>> When waking up from off-mode, some IP blocks are reset automatically by
>> hardware. For this reason, software must wait until the reset has
>> completed before attempting to access the IP block.
>>
>> This patch fixes for example the bug introduced by commit
>> 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c ("mmc: omap_hsmmc: remove access
>> to SYSCONFIG register"), in which the MMC IP block is reset during
>> off-mode entry, but the code expects the module to be already available
>> during the execution of context restore.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> Cc: Paul Walmsley <paul@pwsan.com>
>> Cc: Benoit Cousson <b-cousson@ti.com>
>> Cc: Venkatraman S <svenkatr@ti.com>
>
> I can confirm that this patch the regression in my OMAP3 PM tests where
> suspend test (to retention or off) failed if ran after the off-idle
> test.
>
> Tested-by: Kevin Hilman <khilman@ti.com>
>
> on 3530/Overo, 3730/OveroSTORM, 3730/Beagle-xM

on 3630/Beagle works.
However on 3430 on idle path didnot work.
let me know if i am missing some thing.

>
> Thanks Tero for the fix,
>
> Kevin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kevin Hilman Oct. 23, 2012, 4:09 p.m. UTC | #3
Shubhrajyoti Datta <omaplinuxkernel@gmail.com> writes:

> On Tue, Oct 23, 2012 at 3:16 AM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> Tero Kristo <t-kristo@ti.com> writes:
>>
>>> When waking up from off-mode, some IP blocks are reset automatically by
>>> hardware. For this reason, software must wait until the reset has
>>> completed before attempting to access the IP block.
>>>
>>> This patch fixes for example the bug introduced by commit
>>> 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c ("mmc: omap_hsmmc: remove access
>>> to SYSCONFIG register"), in which the MMC IP block is reset during
>>> off-mode entry, but the code expects the module to be already available
>>> during the execution of context restore.
>>>
>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>> Cc: Paul Walmsley <paul@pwsan.com>
>>> Cc: Benoit Cousson <b-cousson@ti.com>
>>> Cc: Venkatraman S <svenkatr@ti.com>
>>
>> I can confirm that this patch the regression in my OMAP3 PM tests where
>> suspend test (to retention or off) failed if ran after the off-idle
>> test.
>>
>> Tested-by: Kevin Hilman <khilman@ti.com>
>>
>> on 3530/Overo, 3730/OveroSTORM, 3730/Beagle-xM
>
> on 3630/Beagle works.
> However on 3430 on idle path didnot work.
> let me know if i am missing some thing.

Could you please explain what worked and didn't work on each platforms?

Also, which 3430 did you test on?  If it's SDP, then it has a UART1
console, correct?

Kevin
Shubhrajyoti Datta Oct. 23, 2012, 5:50 p.m. UTC | #4
On Tue, Oct 23, 2012 at 9:39 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> Shubhrajyoti Datta <omaplinuxkernel@gmail.com> writes:
[...]
>
> Could you please explain what worked and didn't work on each platforms?
>
> Also, which 3430 did you test on?  If it's SDP, then it has a UART1
> console, correct?
idle mode

set autosuspend for uart
sleep

off count didnt increment on 3430sdp.

hope not hitting any setup at my end.

>
> Kevin
diff mbox

Patch

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index b969ab1..523729b 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1278,6 +1278,7 @@  static void _enable_sysc(struct omap_hwmod *oh)
 	u8 idlemode, sf;
 	u32 v;
 	bool clkdm_act;
+	int c;
 
 	if (!oh->class->sysc)
 		return;
@@ -1338,6 +1339,27 @@  static void _enable_sysc(struct omap_hwmod *oh)
 		_set_module_autoidle(oh, idlemode, &v);
 		_write_sysconfig(v, oh);
 	}
+
+	/*
+	 * Wait until reset has completed, this is needed as the IP
+	 * block is reset automatically by hardware in some cases
+	 * (off-mode for example), and the drivers require the
+	 * IP to be ready when they access it
+	 */
+	if (sf & SYSS_HAS_RESET_STATUS)
+		omap_test_timeout((omap_hwmod_read(oh,
+						   oh->class->sysc->syss_offs)
+				   & SYSS_RESETDONE_MASK),
+				  MAX_MODULE_SOFTRESET_WAIT, c);
+
+	if (sf & SYSC_HAS_RESET_STATUS) {
+		u32 softrst_mask =
+			(0x1 << oh->class->sysc->sysc_fields->srst_shift);
+		omap_test_timeout(!(omap_hwmod_read(oh,
+						    oh->class->sysc->sysc_offs)
+				   & softrst_mask),
+				  MAX_MODULE_SOFTRESET_WAIT, c);
+	}
 }
 
 /**