From: "Daniel Glöckner" <daniel-gl@gmx.net>
To: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Cc: linux-clk@vger.kernel.org, Shawn Guo <shawnguo@kernel.org>
Subject: Re: Bits that affect several muxes
Date: Wed, 27 Jan 2016 03:32:36 +0100 [thread overview]
Message-ID: <20160127023236.GA23081@minime.bse> (raw)
In-Reply-To: <56A72CB7.7050707@mentor.com>
Hi Vladimir,
I have added Shawn Guo to CC as the discussion shifts towards the i.MX6.
He wrote the existing i.MX6 PLL bypass code.
On Tue, Jan 26, 2016 at 10:22:15AM +0200, Vladimir Zapolskiy wrote:
> On 23.01.2016 01:37, Daniel Glöckner wrote:
> > today at work I just realized that the i.MX6 clock tree is not correctly
> > modeled wrt. PLL bypassing since bypassing the PLL also bypasses all PFD
> > post dividers. I've seen this before on the jz4730 where disabling the
> > PLL also sets several clocks to the same source.
>
> could you please give a more detailed example for iMX6 (particular clock
> names, registers, bit fields from the Reference Manual)?
The i.MX6 reference manual says "For the PLL equipped with PFDs the
input reference clock is also bypassed to all PFDs outputs."
I have taken the time to measure the effect of putting the PLLs in
bypass by routing their output to an LVDS clock output on an i.MX6Q.
The results are:
- All four PFD outputs of PLL2 are switched to the bypass source
(LVDS1_CLK_SEL=2..5), even the undocumented PFD3
- The PLL2 output itself (LVDS1_CLK_SEL=1) is not affected by bypass
- USB1 PLL (LVDS1_CLK_SEL=12) and its PFDs (LVDS1_CLK_SEL=14..17) are
_not_ affected by bypass
- USB2 PLL (LVDS1_CLK_SEL=13) is affected by bypass
- When the ENET PLL is in bypass, only PCIE REF (LVDS1_CLK_SEL=12) is
switched to the bypass clock, ETHERNET REF and SATA REF
(LVDS1_CLK_SEL=9, 11) still derive their clock from the ENET PLL
- ARM, Audio, and Video PLL (LVDS1_CLK_SEL=0, 6, 7) are not affected
by bypass
It also seems like the ENABLE bit has no effect on many of the PLLs
and only POWERDOWN stops the clock from being forwarded to the LVDS
output. Looks like someone at Freescale/NXP needs to fix some diagrams
in the reference manual.
Best regards,
Daniel
prev parent reply other threads:[~2016-01-27 2:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-22 23:37 Bits that affect several muxes Daniel Glöckner
2016-01-26 8:22 ` Vladimir Zapolskiy
2016-01-27 2:32 ` Daniel Glöckner [this message]
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=20160127023236.GA23081@minime.bse \
--to=daniel-gl@gmx.net \
--cc=linux-clk@vger.kernel.org \
--cc=shawnguo@kernel.org \
--cc=vladimir_zapolskiy@mentor.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.