Re: The clock problem in OMAP2 McSPI

[David Brownell <david-b@pacbell.net>]

On Thursday 16 August 2007, Kyungmin Park wrote:
> > 
> > On Thursday 16 August 2007, Kyungmin Park wrote:
> > > After booting, it oops with following messages[2].
> > >
> > > So I reverted only clock parts as before. Then it's work well.
> > > I think it has some clock problem.
> > >
> > > Do you have any idea?
> > 
> > Nope, sorry.  I looked at that driver code, and what I
> > see is neatly paired clk_enable()/clk_disable() calls ...
> > stuff that should be "obviously correct".  And which
> > works fine here...
> 
> I agree. The code of clock is completely matched and only enables it needed
> for McSPI

So it looks like the issue will be elsewhere...


> > I don't see how that should be able to cause a disable()
> > of something that's already got usecount 0.
> > 
> > I wouldn't *think* that the updates in the clock framework
> > have caused problems.  But regardless, to debug this I'd
> > start by tracing the refcounts of that functional clock.
> > 
> > The only slightly odd unusual thing in that driver should
> > be that the two clocks would normally be disabled until
> > there's some I/O to be done (either to the McSPI registers
> > or to a SPI device).  Most drivers leave clocks enabled all
> > the time, needlessly wasting power.
> 
> If it required the some delay time to work correctly?

Not at the level of clock refcounts.  Maybe to restart some
oscillator or PLL, but that's not an issue here.


> Since the clock pointer is always correct and it has ick and fck.
> Or other kernel features such as tickless, high-res affects the clock
> framework?

I'd more suspect something else mucking with that clock.

You said this happens early.  That suggests that brute
force dump_stack() debugging on enable/disable of that
clock would be informative...

- Dave