All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: "Alvin Šipraga" <alsi@bang-olufsen.dk>,
	"Alvin Šipraga" <alvin@pqrs.dk>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Rob Herring" <robh+dt@kernel.org>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
	Rabeeh Khoury <rabeeh@solid-run.com>,
	Jacob Siverskog <jacob@teenage.engineering>,
	Sergej Sawazki <sergej@taudac.com>,
	linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 3/3] clk: si5351: allow PLLs to be adjusted without reset
Date: Sun, 17 Dec 2023 22:32:49 -0800	[thread overview]
Message-ID: <ed6a16e092feb62366d3ddbeb3cbbe64.sboyd@kernel.org> (raw)
In-Reply-To: <20231124-alvin-clk-si5351-no-pll-reset-v6-3-69b82311cb90@bang-olufsen.dk>

Quoting Alvin Šipraga (2023-11-24 05:17:44)
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
> 
> Introduce a new PLL reset mode flag which controls whether or not to
> reset a PLL after adjusting its rate. The mode can be configured through
> platform data or device tree.
> 
> Since commit 6dc669a22c77 ("clk: si5351: Add PLL soft reset"), the
> driver unconditionally resets a PLL whenever its rate is adjusted.
> The rationale was that a PLL reset was required to get three outputs
> working at the same time. Before this change, the driver never reset the
> PLLs.
> 
> Commit b26ff127c52c ("clk: si5351: Apply PLL soft reset before enabling
> the outputs") subsequently introduced an option to reset the PLL when
> enabling a clock output that sourced it. Here, the rationale was that
> this is required to get a deterministic phase relationship between
> multiple output clocks.
> 
> This clearly shows that it is useful to reset the PLLs in applications
> where multiple clock outputs are used. However, the Si5351 also allows
> for glitch-free rate adjustment of its PLLs if one avoids resetting the
> PLL. In our audio application where a single Si5351 clock output is used
> to supply a runtime adjustable bit clock, this unconditional PLL reset
> behaviour introduces unwanted glitches in the clock output.
> 
> It would appear that the problem being solved in the former commit
> may be solved by using the optional device tree property introduced in
> the latter commit, obviating the need for an unconditional PLL reset
> after rate adjustment. But it's not OK to break the default behaviour of
> the driver, and it cannot be assumed that all device trees are using the
> property introduced in the latter commit. Hence, the new behaviour is
> made opt-in.
> 
> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> Cc: Rabeeh Khoury <rabeeh@solid-run.com>
> Cc: Jacob Siverskog <jacob@teenage.engineering>
> Cc: Sergej Sawazki <sergej@taudac.com>
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---

Applied to clk-next

      reply	other threads:[~2023-12-18  6:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-24 13:17 [PATCH v6 0/3] clk: si5351: add option to adjust PLL without glitches Alvin Šipraga
2023-11-24 13:17 ` [PATCH v6 1/3] dt-bindings: clock: si5351: convert to yaml Alvin Šipraga
2023-12-18  6:32   ` Stephen Boyd
2023-11-24 13:17 ` [PATCH v6 2/3] dt-bindings: clock: si5351: add PLL reset mode property Alvin Šipraga
2023-12-18  6:32   ` Stephen Boyd
2023-11-24 13:17 ` [PATCH v6 3/3] clk: si5351: allow PLLs to be adjusted without reset Alvin Šipraga
2023-12-18  6:32   ` Stephen Boyd [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=ed6a16e092feb62366d3ddbeb3cbbe64.sboyd@kernel.org \
    --to=sboyd@kernel.org \
    --cc=alsi@bang-olufsen.dk \
    --cc=alvin@pqrs.dk \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jacob@teenage.engineering \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=rabeeh@solid-run.com \
    --cc=robh+dt@kernel.org \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=sergej@taudac.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.