Linux on ARM based TI OMAP SoCs
 help / color / mirror / Atom feed
From: Mike Turquette <mturquette@linaro.org>
To: Tero Kristo <t-kristo@ti.com>, Stefan Roese <stefan.roese@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>,
	linux-omap <linux-omap@vger.kernel.org>,
	Paul Walmsley <paul@pwsan.com>
Subject: Re: Odd behavior with dpll4_m4x2_ck on omap3 + DT
Date: Mon, 16 Sep 2013 12:45:05 -0700	[thread overview]
Message-ID: <20130916194505.27384.1874@quantum> (raw)
In-Reply-To: <5232F85E.7050502@ti.com>

Quoting Tero Kristo (2013-09-13 04:34:54)
> On 09/13/2013 10:51 AM, Stefan Roese wrote:
> > On 11.09.2013 09:21, Tomi Valkeinen wrote:
> >> 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 =).
> >
> > Okay, I finally found some time to test this. The patch above generates
> > this warning:
> >
> > arch/arm/mach-omap2/dpll3xxx.c: In function 'omap3_clkoutx2_recalc':
> > arch/arm/mach-omap2/dpll3xxx.c:663:6: warning: passing argument 1 of '__clk_get_rate' from incompatible pointer type [enabled by default]
> > include/linux/clk-provider.h:423:15: note: expected 'struct clk *' but argument is of type 'struct clk_hw_omap *'
> 
> Yea sorry about that, I just quickly hacked the patch together without 
> testing it at all. :P
> 
> >
> > I then changed it (not 100% sure if correctly) to this version:
> >
> > +       if ((dd->flags & DPLL_J_TYPE) ||
> > +           __clk_get_rate(dd->clk_bypass) == __clk_get_rate(pclk->hw.clk))
> >
> > And this seems to work. At least the clock rate mismatch warning does not
> > appear with this patch applied (and without the clk_enable) in the
> > bootlog any more.
> 
> Yea, looks good to me, however I guess I would like second opinion on 
> this also.

Looks right to me.

Regards,
Mike

> 
> -Tero

  reply	other threads:[~2013-09-16 19:45 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-28  9:22 Odd behavior with dpll4_m4x2_ck on omap3 + DT Tomi Valkeinen
2013-08-28  9:48 ` Tero Kristo
2013-08-28 10:14   ` Tomi Valkeinen
2013-08-28 11:40     ` Tero Kristo
2013-09-10 11:33       ` Stefan Roese
2013-09-10 12:12         ` Tero Kristo
2013-09-10 12:19           ` Tomi Valkeinen
2013-09-10 12:24             ` Tero Kristo
2013-09-10 12:40               ` Tomi Valkeinen
2013-09-10 13:17                 ` Tero Kristo
2013-09-10 21:17                   ` Mike Turquette
2013-09-10 21:57                     ` Mike Turquette
2013-09-11  7:21                   ` Tomi Valkeinen
2013-09-13  7:51                     ` Stefan Roese
2013-09-13 11:34                       ` Tero Kristo
2013-09-16 19:45                         ` Mike Turquette [this message]
2013-09-27  8:41                         ` Tomi Valkeinen
2013-09-27 11:24                           ` Tero Kristo
2013-09-30  7:56                             ` Tomi Valkeinen
2013-10-07  8:21                   ` Paul Walmsley
2013-10-08  1:35                     ` Mike Turquette
2013-10-13 20:17                       ` Paul Walmsley
2013-09-10 12:25           ` Stefan Roese

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130916194505.27384.1874@quantum \
    --to=mturquette@linaro.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=stefan.roese@gmail.com \
    --cc=t-kristo@ti.com \
    --cc=tomi.valkeinen@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox