Re: Bug in linux omap clock framework?

[Tomi Valkeinen <tomi.valkeinen@nokia.com>]

On Wed, 2008-12-10 at 09:37 +0200, Högander Jouni wrote:
> "ext Tomi Valkeinen" <tomi.valkeinen@nokia.com> writes:
> 
> > Hi,
> >
> > On Mon, 2008-12-08 at 02:24 -0700, ext Paul Walmsley wrote:
> >> Hi Tomi,
> >> 
> >> On Mon, 8 Dec 2008, Tomi Valkeinen wrote:
> >> 
> >> > On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote:
> >> > > Hi Tomi,
> >> > > 
> >> > > nice test case.
> >> > > 
> >> > > On Fri, 5 Dec 2008, Tomi.Valkeinen@nokia.com wrote:
> >> > > 
> >> > > > I have had strange clk_enable() crashes with DSS2, and now I managed to
> >> > > > isolate it. With the included patch, on OMAP3 SDP board, with default
> >> > > > kernel config, I always get the crash below. In this example case it
> >> > > > happens at specific time on boot, but with DSS2 it happens randomly at
> >> > > > runtime, when I enable the DSS clocks.
> >> > > 
> >> 
> >> At this point my guess would be that it is a DSS driver problem, but I 
> >> don't think it is clear yet.
> >> 
> >
> > I don't know much about power and clock domains, but I believe I found
> > the reason and fix for this. At least this should point to the right
> > direction.
> >
> > It looks to me that when I do clk_enable() to a clock which is inside a
> > turned off powerdomain, clk_enable() function will return before the
> > powerdomain is fully turned on. Reading PM_PWSTST_DSS shows that the
> > powerdomain is still in transition state.
> >
> > The following change waits until the powerdomain has finished the
> > transition. At least it fixed the problem for me, and other things seem
> > to be still working =).
> >
> >
> > diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c
> > index fa62f14..f713d0b 100644
> > --- a/arch/arm/mach-omap2/clockdomain.c
> > +++ b/arch/arm/mach-omap2/clockdomain.c
> > @@ -567,6 +567,8 @@ int omap2_clkdm_clk_enable(struct clockdomain *clkdm, struct clk *clk)
> >         else
> >                 omap2_clkdm_wakeup(clkdm);
> >  
> > +       pwrdm_wait_transition(clkdm->pwrdm.ptr);
> > +
> 
> Altough this patch is fixing the problem, I'll guess it's because of
> delay it causes rather than waiting for
> PM_PWSTST_DSS. omap2_clkdm_clk_enable alone doesn't switch pwrdm to
> on. This is because clockdomain/powerdomains are controlled by HW (hw
> supervised).
> 
> I think the right answer is to use ST_*_IDLE & ST_*_STDBY bits in
> omap2_clk_wait_ready.

But ST_DSS_IDLE says active only after both interface and functional
clock are on, so it doesn't help here.

Why is it wrong to wait for PM_PWSTST_DSS? Do you mean that this crash
is not caused by the DSS being not powered on, but by something else,
and so the small delay just accidentally fixes the problem?

 Tomi


--
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