<bamse>
steev: is that with or without {clk,pd}_ignore_unused?
<steev>
with both of those enabled
<steev>
kernel command line on that boot would have been "BOOTIMAGE=/boot/vmlinuz-5.13.4 root=UUID=<uuid> ro pd_ignore_unused cclk_ignore_unused verbose drm.debug=0x3"
<steev>
clk was spelled correctly though
<bamse>
it's the thought that counts ;)
<steev>
fwiw
<steev>
removing them
<steev>
[ 4.510637] dpu_mdss_enable+0x30/0x130 [msm]->msm_dss_enable_clk: core en fail. rc=-16
<steev>
[ 4.512910] disp_cc_mdss_ahb_clk status stuck at 'off'
<bamse>
hmm okay, that's different from what we get on the mtp...need to take a look at that as well then
<bamse>
i posted a patch/rfc recently to fix another problem where mdp_src_clk get stuck because we're turning off the parent and then we try to reparent it without turning on the old parent again
<steev>
ohh, i wasn't seeing it in patchwork for some reason
<bamse>
steev: but, that problem only relates to clk_ignore_unused...
<bamse>
steev: the typical thing with the rcgs is that when you change the mux both the old and the new parent must be ticking...so i wonder what them parents are doing in your case
<steev>
not sure - but fwiw, it shows up on both c630, so it's not specific to that one, at least :)
<steev>
bamse: so stupid/silly question... if i went through there and found the one that is giving me problems and made the same change, should i give that a test or nah?
<bamse>
steev: i don't think that's useful in itself, but figuring out what the old and new parent is
<steev>
that is a bit outside my paygrade
<steev>
bamse: oh... one other thing/question - any way we could get the ipa to retry to find the firmware? i've noticed if the module is in the initrd, and the firmware isn't, you have to modprobe -r ipa && modprobe ipa after boot to get it to work
<bamse>
steev: that would be very useful...not sure how to deal with it though
<bamse>
steev: last time i "discussed" this with torvalds i ended up on the front page of theregister.com
<steev>
oh, rip
<steev>
i was gonna say maybe the way uh, adreno does since it retries to find the firmware
<bamse>
steev: that was before his break though, maybe he's up for a new round :)
<bamse>
steev: hmm, does it? need to look at what robclark came up with there then
<bamse>
because if you have the .ko on the disk the firmware should be on disk as well when the module is loaded
<steev>
it's just ipa.ko
<steev>
in my initrd
<steev>
(i also put the firmware in after figuring that out with an initramfs-tools hook)
<steev>
although... other modules seem to include their firmware in the initrd, is there a reason why that doesn't?
<robclark>
bamse: drm/msm defers loading the gpu and retries on each open of device file (basically so we can get display up without needing gpu fw in initrd).. I'm not really sure I'd recommend it, it adds complexity..
<bamse>
robclark: ahh right
<bamse>
robclark: yeah and i don't think we have such an anchor point in the ipa driver
<steev>
well there's no device file until the firmware is loaded there
<steev>
i don't think there is one even after the firmware is loaded?
<robclark>
bamse: maybe we need a missing-fw equiv of -EPROBE_DEFER? Ie. "try this driver again once new fs is mounted"?
<bamse>
robclark: that was pretty much were our discussion was heading when torvalds objected
<bamse>
robclark: but i think we need to revive that discussion anyway
<steev>
hm
<robclark>
actually, otoh, couldn't udev do something like that?
<steev>
something i thought of - one thing i notice about this 5.13+ kernels... - before the display comes up "properly" - it's like there is something going on
<bamse>
robclark: because i noticed that arm64 is the one platform with CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
<steev>
rob, if you remember when i had that doubled up display - it's kinda like that
<robclark>
something pitch related messed up in efifb?
<steev>
ill take a vid
<robclark>
well, I mean, if it is before drm driver probes, it is efifb
<bamse>
robclark: problem is that "the fs" isn't well defined...
<steev>
Blergh. Of course I get a blue screen this boot
<steev>
where the blue screen happens though, is where it normally boots up showing the kali dragon plymouth screen
<steev>
fine in grub -> breaks -> unbreaks
<robclark>
I guess maybe check if there had been some recent efifb patches.. I was under the impression that it changes rarely.. but if it is before the display driver probes, assuming the fw didn't change recently, it must be an efifb issue