Hi, On Mon, Mar 21, 2022 at 10:54:16PM +0100, Janusz Krzysztofik wrote: > In preparation for conversion of OMAP1 clocks to common clock framework, > identify users of those clocks which don't call clk_prepare/unprepare() > and update them to call clk_prepare_enable/clk_disable_unprepare() instead > of just clk_enable/disable(), as required by CCF implementation of clock > API. > > v2: update still a few more OMAP specific drivers missed in v1, > - call clk_prepare/unprepare() just after/before clk_get/put() where it > can make more sense than merging prepare/unprepare with enable/disable. Something is still broken. When doing kexec (using CCF kernel), the kexec'ed kernel now hangs early (on 770): [ 0.853912] MUX: initialized W4_USB_PUEN [ 0.858001] MUX: initialized V6_USB0_TXD [ 0.862060] MUX: initialized W5_USB0_SE0 [ 0.866210] MUX: initialized Y5_USB0_RCV [ 0.870269] MUX: initialized AA9_USB0_VP [ 0.874389] MUX: initialized R9_USB0_VM [ 0.878356] USB: hmc 16, usb0 6 wires (dev), Mini-AB on usb0 [ 0.886230] initcall customize_machine+0x0/0x30 returned 0 after 29296 usecs [ 0.893707] calling init_atags_procfs+0x0/0xe8 @ 1 [ 0.898864] initcall init_atags_procfs+0x0/0xe8 returned 0 after 0 usecs [ 0.905883] calling exceptions_init+0x0/0x8c @ 1 [ 0.910797] initcall exceptions_init+0x0/0x8c returned 0 after 0 usecs [ 0.917602] calling omap_init+0x0/0xc @ 1 [ 0.922393] initcall omap_init+0x0/0xc returned 0 after 9765 usecs [ 0.928863] calling omap1_init_devices+0x0/0x2c @ 1 [ 2.568664] random: fast init done Probably something is now disabled that has been previously always enabled by default/bootloader. I'll try adding some printk()s to see the exact place where it hangs... A.
