gcc-sc8180x: Building-in clock controller requires `clk_ignore_unused` kernel parameter

[Maximilian Luz]

During boot, the gcc-sc8180x clock controller causes a hard lock up. Current workarounds include building it as module (CONFIG_SC_GCC_8180X=M; note that it needs to be included in the initram) or adding the clk_ignore_unused option the the kernel command line.

One possible explanation for this is that during (early) boot, something accesses an unclocked register. As adding clk_ignore_unused seems to fix this, the clock is likely enabled and set up by UEFI, however disabled once gcc-sc8180x probes. Building the driver as module seems to sufficiently delay this, due to which the clock is then either required by something else already loaded (preventing disabling of it) or disablement of it is sufficiently delayed until after whatever accesses it is done.

Try to figure out what clock in particular is required and how we can fix this.

[Maximilian Luz]

Quoting @andersson from aarch64-laptops IRC:

all platforms where the clock state set up by the bootloader somehow relates to clients built as modules, needs clk_ignore_unused...because "unused" is determined before any kernel modules have had a chance to probe

in the event that you make gcc a module then disabling unused clocks will be a nop, because there are no clocks at late_initcall()

there's a "new" mechanism called "sync_state", in which a provider is informed when all devices referencing it in dt has been probed

so we should be able to implement a sync_state callback in each provider and when that happens disable any then unused clocks

Something like this has been attempted with this patch, but I haven't found any follow-up discussions and the patch was never merged. For now, the commonly accepted mechanism is to use clk_ignore_unused.

I'll keep this issue open to track the sync_state implementation.