Am Mon, 11 Nov 2024 19:31:17 +0100 schrieb Andreas Kemnade <andreas@xxxxxxxxxxxx>: > Am Mon, 11 Nov 2024 17:09:53 +0200 > schrieb Tony Lindgren <tony@xxxxxxxxxxx>: > > > * Andreas Kemnade <andreas@xxxxxxxxxxxx> [241108 17:41]: > > > They are not used, if they are just disabled, kernel does not touch > > > them, so if it is there, the kernel can handle > > > pm. At least as long as it is not under ti,sysc. > > > > > > There are probably cleaner solutions for this, but for a CC: stable I > > > would prefer something less invasive. > > > > For unused devices, it's best to configure things to use ti-sysc, and > > then set status disabled (or reserved) for the child devices only. This > > way the parent interconnect target module is PM runtime managed by > > Linux, and it's power domain gets properly idled for the unused devices > > too. > > > Hmm, we also have omap_hwmod_setup_all() which is still called if > without device nodes being available. > > Converting mcspi to ti-sysc is more than 100 lines. So it does not > qualify for stable. > > > > I can try a ti-sysc based fix in parallel. > > > > Yeah that should be trivial hopefully :) > > > I played around, got pm issues too, tried to force-enable things (via > power/control), > watched CM_IDLEST1_CORE and CM_FCLKEN1_CORE, they behave. Bits are set > or reset. > > but not CM_IDLEST_CKGEN, it is 0x209 instead of 0x1. > > I test from initramfs, so no mmc activity involved > > removing status = "disabled" from mcspi3 solves things. > With and without ti-sysc conversion. removing status = "disabled" from > mcspi4 seems not to help. > > That all cannot be... I will retry tomorrow. > well, I tried a bit further: I build the omap spi driver as module. and booted With mcspi3 not disabled and no module autoload. without module loaded: pm bad, same as with mcspi3 disabled with module loaded: core pm ok with module loaded and unloaded: core pm ok. so at least a trace. Regards, Andreas
