<HappY[m]>
Hello! I am facing one issue with another OS.. but exactly same configuration & same kernel sourcei used in pmos but I don't have any issue like this.. I am serious unable to find out.. any suggestions would be appreciate
<HappY[m]>
lumag: I don't have "rmtfs_mem" memory in my stock kernel ..
junari_ has joined #linux-msm
junari has quit [Ping timeout: 480 seconds]
<vknecht[m]>
<bryanodonoghue> "would be interested to see if..." <- Hi ! There doesn't seem to be ECC nor CRC error (taken during a 150 frames capture, dunno how to get the final values before debugfs file is closed)... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/BixcQatHxnqZpQbyBIcyyGBJ>)
Danct12 has quit [Quit: What if we rewrite the code?]
Danct12 has joined #linux-msm
<HappY[m]>
Camera?
<vknecht[m]>
trying to debug camera subsystem, yes, but without any sensor yet, just the test-pattern-generator
<HappY[m]>
<lumag> "HappY, sizes?" <- Honestly this is my first time mainline port.. I don't have proper knowledge about it.. I checked various devices as a reference after I booted my device.. mainline boot was taken 5 months from me.. and yes without pmos groups it was impossible.. because I remember & laugh about my 1st dts..... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/YbAQkOcgTKjJPDJlOFskqlqk>)
<lumag>
HappY[m], well, your regions look correct.
<bryanodonoghue>
vknecht[m] what does an all zeros pattern produce ?
<vknecht[m]>
not sure the unrecoverable/recoverable errors split is correct, but since the total is 0, guess it doesn't matter for now ;-)
<vknecht[m]>
bryanodonoghue: any chance camss depends on interconnect ? it's disabled here
<vknecht[m]>
hmm, it's disabled for 8916 too, so shouldn't matter I guess
<HappY[m]>
<HappY[m]> "IMG_20230924_082845.jpg" <- lumag: I don't have this issue on pmos cdsp, adsp, Slpi, ipa all booted up successfully without error.. but I am facing on Ubuntu or Debian.. even I used same pmos kernel & same kernel config.. unable to find out problem in pmos only have pmic-glink, spmi , & unhandled contex fault related issues..
<bryanodonoghue>
vknecht[m] I mean do you have any camss mods for 8939 ?
<vknecht[m]>
bryanodonoghue: no
<vknecht[m]>
tried at one point to add the additional csid@1b08800 found in downstream, but it didn't help, and I guess not relevant for now ?
<vknecht[m]>
these are the kind of csiphy and csid difference I see downstream between 8916 and 8939...
<bryanodonoghue>
eh well for completeness I'd recommend adding a compat for 8939 and setting the ispif clock
<bryanodonoghue>
its is an AHB clock so it might make a difference
<bryanodonoghue>
btw the VFE versions are the _exact_ same number ?
<vknecht[m]>
didn't check...
<bryanodonoghue>
should be but, that's important
<bryanodonoghue>
I can check
<vknecht[m]>
that's what I tried when I shamelessly overwrote 8916 camss, to accound for clocks diffs and csid2... maybe made a mistake in clocks ? https://pastebin.com/uRpw3Yn7
<vknecht[m]>
getting VFE HW Version = 0x10040000 on 8939
<vknecht[m]>
hmm, and VFE HW Version = 0x10030000 on 8916/idol347
<vknecht[m]>
bryanodonoghue: ^
* vknecht[m]
suspect 8939 is vfe-4-7 instead of vfe-4-1
<lumag>
HappY[m], For Ubuntu / Debian. please make sure that you have proper firmware both in rootfs and in initramfs. You might have to tune it in /etc/initramfs-tools/
junari_ has quit [Ping timeout: 480 seconds]
junari has joined #linux-msm
AffeNull[m]1 has joined #linux-msm
<AffeNull[m]1>
vknecht: 8917 has `VFE HW Version = 0x10080001` but is still vfe-4-1
<AffeNull[m]1>
and there would be a difference in the downstream device tree if it were vfe-4-7
<HappY[m]>
<lumag> "HappY, For Ubuntu / Debian..." <- And what should I do if reserved memory address is same but sizes is different..? in that case should I `/delete-node/ &xyz-mem;` ? Or i can ignore?
<lumag>
HappY[m], You can ignore it or just provide correct address + size.
<lumag>
We do delete + new node if the starting address differs only
<HappY[m]>
Ohhhh okay okay.. thank you thank you..