[PATCH] clk: meson: meson8b: mark fclk_div gate clocks as CLK_IS_CRITICAL

[Jerome Brunet]

On Tue, 2018-05-01 at 23:55 +0200, Martin Blumenstingl wrote:
> Hello Yixun,
> 
> On Tue, May 1, 2018 at 11:45 PM, Martin Blumenstingl
> <martin.blumenstingl at googlemail.com> wrote:
> > Until commit 05f814402d6174 ("clk: meson: add fdiv clock gates") we
> > relied on the bootloader to enable the fclk_div clock gates. It turns
> > out that our clock tree is incomplete at least on Meson8b (tested with
> > an Odroid-C1, which uses an RGMII PHY) because after the mentioned
> > commit Ethernet is not working anymore (no RX/TX activity can be seen).
> > At the same time Ethernet was still working on Meson8m2 with a RMII PHY.
> > 
> > It is currently not clear which of the fclk_div gates is required for
> > (RGMII) Ethernet operation on Meson8b and why. Mark the fclk_div gates
> > as CLK_IS_CRITICAL so the common clock framework keeps these gates
> > enabled for us until we know which clock is required for Ethernet on
> > Meson8b and which driver has to claim it.
> 
> based on the public datasheet for Meson8b (S805) I cannot see which
> part of the SoC uses fclk_divX for (RGMII) Ethernet.
> I did some further tests and it seems that Ethernet is not working if
> fclk_div2 is disabled (the other fclk_divX don't seem to affect
> Ethernet operation)
> 
> could you please check your internal datasheets and let us know how
> fclk_div2 is routed internally and how it can affect Ethernet data
> transfers?

Hi Martin,

As usual, thanks for your thorough work !

Now that you know which of the fdiv is actually required, I would prefer if we
could mark only the required clock as critical.

Also, could you please add a short FIXME comment in the code explaining why this
is necessary. This should a be temporary fix while we get the ethernet driver
sorted out. If the ethernet of the meson8b requires the fdiv2 it should claim it
(through other clock if necessary)

> 
> (my current speculation is that it may be related to the "Ethernet
> Memory Power Domain" in CBUS HHI_MEM_PD_REG0, but I have no proof for
> that)