Re: Odd behavior with dpll4_m4x2_ck on omap3 + DT

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

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]