On Fri, 9 Nov 2012, Paul Walmsley wrote:
> On Fri, 9 Nov 2012, Mike Turquette wrote:
>
> > But I'm OK with the below patch in the short term. I just have one
> > question: did you observe any PM regressions by skipping the clkdm
> > programming?
>
> It's still under test here but 3530ES3 Beagle
On Fri, 9 Nov 2012, Mike Turquette wrote:
> But I'm OK with the below patch in the short term. I just have one
> question: did you observe any PM regressions by skipping the clkdm
> programming?
It's still under test here but 3530ES3 Beagle passed the PM tests with it,
with no obvious warnings.
Quoting Paul Walmsley (2012-11-09 11:08:00)
> On Fri, 9 Nov 2012, Paul Walmsley wrote:
>
> > On Thu, 8 Nov 2012, Mike Turquette wrote:
> >
> > > You're right. In my rush I glossed over the clkdm decrement part. In
> > > light of the suspend/resume issues I'm not sure this approach is really
> >
On Fri, 9 Nov 2012, Paul Walmsley wrote:
> On Thu, 8 Nov 2012, Mike Turquette wrote:
>
> > You're right. In my rush I glossed over the clkdm decrement part. In
> > light of the suspend/resume issues I'm not sure this approach is really
> > valid. I think getting to the bottom of those issues w
On Thu, 8 Nov 2012, Mike Turquette wrote:
> You're right. In my rush I glossed over the clkdm decrement part. In
> light of the suspend/resume issues I'm not sure this approach is really
> valid. I think getting to the bottom of those issues will give the
> final word.
What do you think about
Quoting Paul Walmsley (2012-11-08 16:58:21)
> On Thu, 8 Nov 2012, Mike Turquette wrote:
>
> > The OMAP port to the common clk framework[1] resulted in spurious WARNs
> > while disable unused clocks. This is due to _clkdm_clk_hwmod_disable
> > catching clkdm->usecount's with a value of zero. Even
On Thu, 8 Nov 2012, Mike Turquette wrote:
> The OMAP port to the common clk framework[1] resulted in spurious WARNs
> while disable unused clocks. This is due to _clkdm_clk_hwmod_disable
> catching clkdm->usecount's with a value of zero. Even less desirable it
> would not allow the clkdm_clk_dis
The OMAP port to the common clk framework[1] resulted in spurious WARNs
while disable unused clocks. This is due to _clkdm_clk_hwmod_disable
catching clkdm->usecount's with a value of zero. Even less desirable it
would not allow the clkdm_clk_disable function pointer to get called due
to an early
