Hi Geert, On Wednesday, January 25, 2017, Geert Uytterhoeven wrote: > > I can play around and see. I know udealy(100) works OK, but then I > > have to have a delay that's as long as the slowest peripheral. > > If it was just to turn a clock on once, or once in a while, that's OK. > > But it seems like runtime pm wants to turn the clocks on/off as much > > as possible. > > That's not really true: depending on tuning and/or QoS parameters, > pm_runtime_put() may anticipate future use, and may decide not turn off > the clock immediately. > It may be worth looking into that, and to see how to relax that behavior > on RZ/A1. Yes, if there is a way to relax things, then that would be better. > > But won't the individual drivers still want to keep turning clocks on > and off manually? > > (unless I'm not understanding that the underlying clock routines will > basically just > > ignore everything). But even if that' the case...that just wasted CPU > cycles (remember, > > I'm only working with a 400MHz single core here running XIP_KERNEL) > > If a clock is already enabled, preparing and/or enabling it again will > just > increase the prepare resp. enable counters. Disabling/unpreparing > afterwards > will also just decrease the counters. Should be quite cheap OK, I think I see your point: If I go and double-enable a clock, then the runtime pm won't do much of anything because I'll always be a count higher so a true 'clock disable' will never really occur. Is that correct? #I'm getting side tracked from what I really started to do which was test out PFC for i2c and spi :( Chris
