All of lore.kernel.org
 help / color / mirror / Atom feed
* Bits that affect several muxes
@ 2016-01-22 23:37 Daniel Glöckner
  2016-01-26  8:22 ` Vladimir Zapolskiy
  0 siblings, 1 reply; 3+ messages in thread
From: Daniel Glöckner @ 2016-01-22 23:37 UTC (permalink / raw)
  To: linux-clk

Hi,

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.

Maybe I haven't dug deep enough into the mail archive, but I couldn't
find any information on how to handle cases like these. Can this be
modeled with the existing clock primitives?

Best regards,

  Daniel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Bits that affect several muxes
  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
  0 siblings, 1 reply; 3+ messages in thread
From: Vladimir Zapolskiy @ 2016-01-26  8:22 UTC (permalink / raw)
  To: Daniel Glöckner; +Cc: linux-clk

Hi Daniel,

On 23.01.2016 01:37, Daniel Glöckner wrote:
> Hi,
> 
> 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)?

> Maybe I haven't dug deep enough into the mail archive, but I couldn't
> find any information on how to handle cases like these. Can this be
> modeled with the existing clock primitives?

I believe I met something similar (one bit control, which changes several
muxes or gates), and practically I found that in read-only muxes case this
can be handled by registering several such muxes with the same hardware
controls (same mux register, bit shift and mask) but different list of
parents, which are specific to every particular mux. And CCF is not yet
ready to correctly process clk_set_parent() calls on such kind of muxes.

Best wishes,
Vladimir


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Bits that affect several muxes
  2016-01-26  8:22 ` Vladimir Zapolskiy
@ 2016-01-27  2:32   ` Daniel Glöckner
  0 siblings, 0 replies; 3+ messages in thread
From: Daniel Glöckner @ 2016-01-27  2:32 UTC (permalink / raw)
  To: Vladimir Zapolskiy; +Cc: linux-clk, Shawn Guo

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-01-27  2:32 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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.