Gadiyar, Anand wrote:
Hi all,
Commit 5b36d70fa08f09de161487fe7f6e04200ffb8d71 breaks boot on OMAP3430 SDP.
Reversing the patch allows the boot to work.
Bootlog and the patch are shown below.
Regards,
Anand
================================================
commit 5b36d70fa08f09de161487fe7f6e04200ffb8d71
Author: Jouni Hogander <[EMAIL PROTECTED]> >
Date: Mon Jun 9 12:32:40 2008 +0300
PRCM: OMAP3: Fix to wrongly modified omap2_clk_wait_ready
omap2_clk_wait_ready was wrongly modified to check
registers contents. This fix changes it back to check
addresses.
Signed-off-by: Jouni Hogander <[EMAIL PROTECTED]> >
Acked-by: Paul Walmsley <[EMAIL PROTECTED]> >
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]> >
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index d3ab537..ed15868 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -246,8 +246,8 @@ static void omap2_clk_wait_ready(struct clk *clk)
/* REVISIT: What are the appropriate exclusions for 34XX? */
/* OMAP3: ignore DSS-mod clocks */
if (cpu_is_omap34xx() &&
- ((reg & ~0xff) == cm_read_mod_reg(OMAP3430_DSS_MOD, 0) ||
- (((reg & ~0xff) == cm_read_mod_reg(CORE_MOD, 0)) &&
+ ((reg & ~0xff) == (__force
u32)OMAP34XX_CM_REGADDR(OMAP3430_DSS_MOD, 0) ||
+ (((reg & ~0xff) == (__force u32)OMAP34XX_CM_REGADDR(CORE_MOD, 0))
&&
clk-> >enable_bit == OMAP3430_EN_SSI_SHIFT)))
return;
Hmm, looking at recent git, we already have OMAP34XX_CM_REGADDR
instead of cm_read_mod_reg there
http://source.mvista.com/git/?p=linux-omap-2.6.git;a=blob;f=arch/arm/mach-omap2/clock.c;h=ed1586847db4dd95cff8016e4259b533f1582737;hb=HEAD
and it seems that this patch is already applied
http://source.mvista.com/git/?p=linux-omap-2.6.git;a=commitdiff;h=5b36d70fa08f09de161487fe7f6e04200ffb8d71
?
*BUT*: I still see below Unhandled fault at OMAP3 based Beagle board!
Any idea?
Oops. Sorry for this confusion. The patch inlined in the mail was the commit
that
causes the boot failure - not the fix. I would rather have Jouni and Paul look
at the
commit. I haven't looked too deeply at the patch to see why it causes the crash.
Until this is fixed, you might just want to apply the patch in reverse.
Ah, yes, sorry for my misunderstanding! And many thanks for finding
the cause of this issue. Hopefully we will have a fix for this soon now.
Sorry and thanks
Dirk
--
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
