From: Stephen Boyd <sboyd@kernel.org>
To: Luca Ceresoli <luca@lucaceresoli.net>,
Marek Vasut <marek.vasut@gmail.com>,
Michael Turquette <mturquette@baylibre.com>,
Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru>,
Serge Semin <fancer.lancer@gmail.com>,
Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>,
Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>,
Philipp Zabel <p.zabel@pengutronix.de>,
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
linux-clk@vger.kernel.org, linux-mips@vger.kernel.org,
linux-kernel@vger.kernel.org, Stephen Boyd <sboyd@codeaurora.org>
Subject: Re: [PATCH RESEND v12 1/8] clk: vc5: Fix 5P49V6901 outputs disabling when enabling FOD
Date: Fri, 30 Sep 2022 14:24:52 -0700 [thread overview]
Message-ID: <20220930212455.3D9D2C433D6@smtp.kernel.org> (raw)
In-Reply-To: <20220929225402.9696-2-Sergey.Semin@baikalelectronics.ru>
Quoting Serge Semin (2022-09-29 15:53:55)
> We have discovered random glitches during the system boot up procedure.
> The problem investigation led us to the weird outcomes: when none of the
> Renesas 5P49V6901 ports are explicitly enabled by the kernel driver, the
> glitches disappeared. It was a mystery since the SoC external clock
> domains were fed with different 5P49V6901 outputs. The driver code didn't
> seem like bogus either. We almost despaired to find out a root cause when
> the solution has been found for a more modern revision of the chip. It
> turned out the 5P49V6901 clock generator stopped its output for a short
> period of time during the VC5_OUT_DIV_CONTROL register writing. The same
> problem was found for the 5P49V6965 revision of the chip and was
> successfully fixed in commit fc336ae622df ("clk: vc5: fix output disabling
> when enabling a FOD") by enabling the "bypass_sync" flag hidden inside
> "Unused Factory Reserved Register". Even though the 5P49V6901 registers
> description and programming guide doesn't provide any intel regarding that
> flag, setting it up anyway in the officially unused register completely
> eliminated the denoted glitches. Thus let's activate the functionality
> submitted in commit fc336ae622df ("clk: vc5: fix output disabling when
> enabling a FOD") for the Renesas 5P49V6901 chip too in order to remove the
> ports implicit inter-dependency.
>
> Fixes: dbf6b16f5683 ("clk: vc5: Add support for IDT VersaClock 5P49V6901")
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
>
> ---
Applied to clk-next
next prev parent reply other threads:[~2022-09-30 21:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-29 22:53 [PATCH RESEND v12 0/8] clk/resets: baikal-t1: Add DDR/PCIe resets and xGMAC/SATA fixes Serge Semin
2022-09-29 22:53 ` [PATCH RESEND v12 1/8] clk: vc5: Fix 5P49V6901 outputs disabling when enabling FOD Serge Semin
2022-09-30 21:24 ` Stephen Boyd [this message]
2022-09-29 22:53 ` [PATCH RESEND v12 2/8] clk: baikal-t1: Fix invalid xGMAC PTP clock divider Serge Semin
2022-09-30 21:25 ` Stephen Boyd
2022-09-29 22:53 ` [PATCH RESEND v12 3/8] clk: baikal-t1: Add shared xGMAC ref/ptp clocks internal parent Serge Semin
2022-09-30 21:25 ` Stephen Boyd
2022-09-29 22:53 ` [PATCH RESEND v12 4/8] clk: baikal-t1: Add SATA internal ref clock buffer Serge Semin
2022-09-30 21:26 ` Stephen Boyd
2022-09-29 22:53 ` [PATCH RESEND v12 5/8] clk: baikal-t1: Move reset-controls code into a dedicated module Serge Semin
2022-09-30 21:26 ` Stephen Boyd
2022-09-29 22:54 ` [PATCH RESEND v12 6/8] dt-bindings: clk: baikal-t1: Add DDR/PCIe reset IDs Serge Semin
2022-09-30 21:27 ` Stephen Boyd
2022-09-29 22:54 ` [PATCH RESEND v12 7/8] clk: baikal-t1: Add DDR/PCIe directly controlled resets support Serge Semin
2022-09-30 21:27 ` Stephen Boyd
2022-09-29 22:54 ` [PATCH RESEND v12 8/8] clk: baikal-t1: Convert to platform device driver Serge Semin
2022-09-30 21:27 ` Stephen Boyd
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=20220930212455.3D9D2C433D6@smtp.kernel.org \
--to=sboyd@kernel.org \
--cc=Alexey.Malahov@baikalelectronics.ru \
--cc=Pavel.Parkhomenko@baikalelectronics.ru \
--cc=Sergey.Semin@baikalelectronics.ru \
--cc=fancer.lancer@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=luca@lucaceresoli.net \
--cc=marek.vasut@gmail.com \
--cc=mturquette@baylibre.com \
--cc=p.zabel@pengutronix.de \
--cc=sboyd@codeaurora.org \
--cc=tsbogend@alpha.franken.de \
/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.