09:53 <loki666> I'm trying to bring a SM8650 board up... But so far the kernel keeps crashing in the first 500ms or less...

09:54 <loki666> I do have a working fbcon (form EFI) but I can barely see kernel logs it before it goes dark

09:56 <loki666> Does anyone has an idea to help me understand what's going wrong ? I tried ramoops section, but currently my attempts to dump it from an EFI app failed... Appreciate help.

09:57 <z3ntu> Enable CONFIG_DEBUG_DRIVER and add boot_delay (?) in kernel cmdline?

09:59 <logicalerzor[m]> loki666: prob good to also take a video of the screen with another device

10:02 <loki666> Tried that with a slow motion... But there is no k oops

10:03 <loki666> Seems to fails around SMMU / IOMMU stuff

10:05 <loki666> z3ntu: I'll try that

10:21 <Tooniis[m]> <loki666> "Seems to fails around SMMU..." <- linux touching secure registers probably

10:26 <loki666> Could be... Meaning I'm missing some nomas regions ?

10:26 <loki666> ^nomap

12:19 <krzk> loki666: anything from earlycon? or this is too early?

12:19 <krzk> There is also cmdline debug to print all initcalls, sometimes helps a lot

13:25 <loki666> krzk: not much I don't have a serial hooked on the board... Only the fbcon

13:39 <z3ntu> bryanodonoghue: I'm currently playing around with camss a bit, and have modified pclk in my sensor driver to be a different value, only modified the rear camera driver now. Now rear camera is still working fine but switching to front camera breaks with "Pixel clock is too high for VFE". From looking at debug prints from vfe_set_clock_rates it seems when I have rear cam active, the values from front cam get used, and for front cam the values

13:39 <z3ntu> from rear cam get used. Am I missing something regarding how this works together?

13:40 <z3ntu> Trying to understand the relationship of link-frequencies, pixel clock and some values, to maybe get some more understanding how to fix higher/other resolutions on the phone

13:56 <konradybcio> z3ntu: are the cameras on different CSIPHYs?

13:59 <z3ntu> yes, different phys

13:59 <z3ntu> csiphy1 and csiphy3

14:11 <z3ntu> yeah I'm pretty sure when I switch to front cam, I get the pixel_clock of rear cam, and the other way around. But then somehow with the original code (only updated link-frequencies??) it's breaking now with that "Pixel clock is too high for VFE", I don't know why this didn't happen before

14:17 <z3ntu> so both times I'm getting msm_vfe0_rdi0 for vfe->line[i].subdev.name in vfe_set_clock_rates

14:19 <z3ntu> ah both times it looks like libcamera is connecting csiphy1/csiphy3 to msm_csid0, I expected it to use csid1/csid3 or something respectively

14:20 <konradybcio> i noticed the same fun behavior just a day or two ago..

14:21 <z3ntu> but I mean that shouldn't matter, but maybe it exposes some weird/unexpected behavior

14:23 <konradybcio> any csid can take any PHY input

14:23 <konradybcio> the VFEs are supposedly hardwired in hw though

14:24 <z3ntu> but maybe with switching cams it's a race condition between reconfiguring the csid for the new sensor and enabling it for the new stream?

14:28 <z3ntu> ok I think I'm getting a bit confused myself, without modification rear cam AND front cam is working. Now I'm modifying rear cam driver and front cam stops working with this error (pretty sure this should also error out without changes, not sure why it's not doing this)

14:29 <z3ntu> I'm always having 7920000000 pclk in my front cam driver, and since that's 7.92GHz that's probably a bit too high

14:59 <z3ntu> ah, looks like https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=164202f682030cf8702f11cb63ccbcf2a81b2e75 in v6.17 is triggering this, when I revert the commit then no pixel clock calculation happens which seems wrong. So looks like this commit actually fixes more stuff than it has intended to?

14:59 <z3ntu> so it just exposes bugs in my sensor driver setup, probably it just works because the 'default' rear cam pclk was sane, and front cam was not sane but it never checked the front cam one