Hi Martin / Kevin,

On Fri, 20 Mar 2020 at 05:09, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
>
> Hi Kevin,
>
> On Mon, Mar 2, 2020 at 6:01 PM Kevin Hilman <khilman@baylibre.com> wrote:
> [...]
> > > updating flags to CLK_IS_CRITICAL which help enable all the parent for
> > > cpub_clk.
> >
> > With current mainline, I've tested DVFS using CPUfreq on both clusters
> > on odroid-n2, and both clusters are booting, so I don't understand the
> > need for this patch.
> I *think* there is a race condition at kernel boot between cpufreq and
> disabling orphaned clocks
> I'm not sure I fully understand it though and I don't have any G12B
> board to verify it
>
> my understanding is that u-boot runs Linux off CPU0 which is clocked by cpub_clk
> this means we need to keep cpub_clk enabled as long as Linux wants the
> CPU0 processor to be enabled (on 32-bit ARM platforms that would be
> smp_operations.cpu_{kill,die})
> cpufreq does not call clk_prepare_enable on the CPU clocks so this
> means that the orphaned clock cleanup mechanism can disable it "at any
> time", killing everything running on CPU0 and CPU1 (which are both
> clocked by cpub_clk)
>
> I have no explanation why this depends on booting from SD or eMMC.
>
> for the 32-bit SoCs we have CLK_IS_CRITICAL on the CPU clock as well
> since commit 0dad1ec65bc30a
> on G12A we have CLK_IS_CRITICAL on the sys_pll clocks, however my
> understanding is that cpub_clk could also be fed by one of the
> fixed_pll derived clocks (which have a gate as well, which may or may
> not be turned off by the orphaned clock cleanup - that is pure
> speculation from my side though).
>
>
> Martin

Thanks for this new input I will carefully check these details once again.

I am attaching small scripts on how I build the image with mainline
u-boot and mainline kernel.
So I am able to reproduce this issue on SD card.
Hoping some body could reproduce this issue at their end and share the feedback.
If their is some issue from my side please let me know.

-Anand