From: Sergey Shtylyov <s.shtylyov@omp.ru>
To: Serge Semin <Sergey.Semin@baikalelectronics.ru>,
Stephen Boyd <sboyd@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Michael Turquette <mturquette@baylibre.com>,
Luca Ceresoli <luca@lucaceresoli.net>,
Marek Vasut <marek.vasut@gmail.com>
Cc: Serge Semin <fancer.lancer@gmail.com>,
Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>,
Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>,
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 v4 2/8] clk: vc5: Fix 5P49V6901 outputs disabling when enabling FOD
Date: Fri, 10 Jun 2022 13:03:10 +0300 [thread overview]
Message-ID: <eb0cbc41-2868-4cbf-9fbf-eeabd25dda04@omp.ru> (raw)
In-Reply-To: <20220610072124.8714-3-Sergey.Semin@baikalelectronics.ru>
On 6/10/22 10:21 AM, Serge Semin wrote:
> 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 was 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 has
> was found for the 5P49V6965 revision of the chip and the was successfully
s/was found/been found/, s/the was/that was/?
> 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>
[...]
MBR, Sergey
next prev parent reply other threads:[~2022-06-10 10:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-10 7:21 [PATCH v4 0/8] clk/resets: baikal-t1: Add DDR/PCIe resets and xGMAC/SATA fixes Serge Semin
2022-06-10 7:21 ` [PATCH v4 1/8] reset: Fix devm bulk optional exclusive control getter Serge Semin
2022-06-10 7:21 ` [PATCH v4 2/8] clk: vc5: Fix 5P49V6901 outputs disabling when enabling FOD Serge Semin
2022-06-10 9:39 ` Luca Ceresoli
2022-06-10 10:20 ` Serge Semin
2022-06-10 10:03 ` Sergey Shtylyov [this message]
2022-06-10 10:24 ` Serge Semin
2022-06-10 7:21 ` [PATCH v4 3/8] clk: baikal-t1: Fix invalid xGMAC PTP clock divider Serge Semin
2022-06-10 7:21 ` [PATCH v4 4/8] clk: baikal-t1: Add shared xGMAC ref/ptp clocks internal parent Serge Semin
2022-06-10 7:21 ` [PATCH v4 5/8] clk: baikal-t1: Add SATA internal ref clock buffer Serge Semin
2022-06-10 7:21 ` [PATCH v4 6/8] clk: baikal-t1: Move reset-controls code into a dedicated module Serge Semin
2022-06-10 7:21 ` [PATCH v4 7/8] clk: baikal-t1: Add DDR/PCIe directly controlled resets support Serge Semin
2022-06-10 7:21 ` [PATCH v4 8/8] clk: baikal-t1: Convert to platform device driver Serge Semin
2022-06-20 21:33 ` [PATCH v4 0/8] clk/resets: baikal-t1: Add DDR/PCIe resets and xGMAC/SATA fixes Serge Semin
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=eb0cbc41-2868-4cbf-9fbf-eeabd25dda04@omp.ru \
--to=s.shtylyov@omp.ru \
--cc=Alexey.Malahov@baikalelectronics.ru \
--cc=Pavel.Parkhomenko@baikalelectronics.ru \
--cc=Sergey.Semin@baikalelectronics.ru \
--cc=fancer.lancer@gmail.com \
--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=sboyd@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox