| Message ID | 20220610072124.8714-3-Sergey.Semin@baikalelectronics.ru (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | clk/resets: baikal-t1: Add DDR/PCIe resets and xGMAC/SATA fixes | expand |
Hi Serge, thank you for your patch! On 10/06/22 09:21, 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 > 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. Sadly, you have been through the same troubles I had on the 6965. > 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> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> (not sure which address is appropriate as I sent patches to update to the Bootlin one and they are being applied one y one on the various maintainers branches)
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
On Fri, Jun 10, 2022 at 11:39:18AM +0200, Luca Ceresoli wrote: > Hi Serge, > > thank you for your patch! > > On 10/06/22 09:21, 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 > > 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. > > Sadly, you have been through the same troubles I had on the 6965. Hi Luca Yeah, it was a nightmare fixing that weird problem. Thanks god you have committed the solution. Last time I had to face something similar was when I was fixing a problem in the IDT NTB controller, which caused PCIe MRd TLPs successfully passed from one side to another, but not in the opposite direction. I spent months trying to figure out the root cause of the problem or at least find some workaround. I wrote several messages to the support team but for some reason they didn't respond. After all the struggle I've found the IDT PCIe bridges configuration tool, hacked it's XML config files where I found the info regarding the Vendor-specific PCIe config-space undocumented flags. It turned out that by default the controller discarded the PCIe MRd responses coming from the link-partner with non-zero device number. In order to make things working a vendor-specific flag needed to be set. > > > 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> > Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> > > (not sure which address is appropriate as I sent patches to update to > the Bootlin one and they are being applied one y one on the various > maintainers branches) Thanks. I'll use the top one then since it was used in the patch Author tag. -Sergey > > -- > Luca
On Fri, Jun 10, 2022 at 01:03:10PM +0300, Sergey Shtylyov wrote: > 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/? Right. Thanks.) -Sergey > > > 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
diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c index e7be3e54b9be..03cfef494b49 100644 --- a/drivers/clk/clk-versaclock5.c +++ b/drivers/clk/clk-versaclock5.c @@ -1204,7 +1204,7 @@ static const struct vc5_chip_info idt_5p49v6901_info = { .model = IDT_VC6_5P49V6901, .clk_fod_cnt = 4, .clk_out_cnt = 5, - .flags = VC5_HAS_PFD_FREQ_DBL, + .flags = VC5_HAS_PFD_FREQ_DBL | VC5_HAS_BYPASS_SYNC_BIT, }; static const struct vc5_chip_info idt_5p49v6965_info = {
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 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> --- Changelog v4: - This is a new patch added on v4 lap of the series. --- drivers/clk/clk-versaclock5.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)