On 10/09/13 16:17, Tero Kristo wrote: > In theory, DPLLs can also be used in their bypass mode to feed customer > nodes clocks. I just think the check in the clkoutx2_recalc is wrong, > and should be enhanced to actually check what is the target mode for the > clock once it is enabled. Maybe something like this would work properly: > > diff --git a/arch/arm/mach-omap2/dpll3xxx.c > b/arch/arm/mach-omap2/dpll3xxx.c > index 3a0296c..ba218fb 100644 > --- a/arch/arm/mach-omap2/dpll3xxx.c > +++ b/arch/arm/mach-omap2/dpll3xxx.c > @@ -658,14 +658,12 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw > *hw, > > dd = pclk->dpll_data; > > - WARN_ON(!dd->enable_mask); > - > - v = __raw_readl(dd->control_reg) & dd->enable_mask; > - v >>= __ffs(dd->enable_mask); > - if ((v != OMAP3XXX_EN_DPLL_LOCKED) || (dd->flags & DPLL_J_TYPE)) > + if ((dd->flags & DPLL_J_TYPE) || > + __clk_get_rate(dd->clk_bypass) == __clk_get_rate(pclk)) > rate = parent_rate; > else > rate = parent_rate * 2; > + > return rate; > } Stefan, are you able to test the above? I'd rather have a proper fix for this, than hack omapdss =). >> How is the DPLL4's clock rate 432000000 anyway in bypass mode. Isn't >> bypass mode usually plain sys-clock, or such? > > This again reflects the rate that the clock has once it is enabled, the > clkoutx2 does not. Ok. Then it does sound like the clkoutx2 is calculated wrong, as you say. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
