gcc-sc8180x: Building-in clock controller requires `clk_ignore_unused` kernel parameter
qzed opened this issue · comments
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.
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.