09:02 <z3ntu> mal Maybe hack up the driver to not pet the watchdog on time?

09:05 <minecrell> mal: try setting up the watchdog ping in userspace (e.g. watchdogd in busybox/pmOS) and then kill that service (don't stop it gracefully, you need to kill it)

09:16 <z3ntu> minecrell Ah the watchdog thing is pet from user space? I thought it's for as the kernel petting the watchdog

09:16 <z3ntu> s/as//

09:25 <minecrell> z3ntu: afaiu it's mainly supposed to be controlled from userspace so you can be sure that userspace is still running correctly

09:25 <z3ntu> got it

09:25 <minecrell> iff the watchdog is already active during boot then the kernel will pet it temporarily

09:26 <minecrell> until userspace takes over

12:01 <mal> minecrell: I see this is dmesg when killing the process handling watchdog "watchdog: watchdog0: watchdog did not stop!" but nothing after that

12:01 <minecrell[m]> make sure it's not restarted (check process list maybe)

12:13 <mal> it's not started

12:18 <minecrell> mal: fwiw I had some problems with the soc watchdog on msm8909, extremely confusing, it was literally counting too slowly as soon as Linux got started

12:18 <minecrell> never figured out why that happens

12:18 <minecrell> what I did instead is configure the watchdog in the pmic instead, qcom,pm8916-wdt (not sure if pm8226 has it but probably does)

12:18 <minecrell> that one worked fine

12:19 <minecrell> if I configured a timeout of 1s on the soc watchdog it was restarted after a few minutes only

12:19 <minecrell> or something like that

12:30 <mal> minecrell: now I got "watchdog0: pretimeout event" after waiting for about 15 minutes

12:31 <minecrell[m]> if you wait longer it might reboot eventually :D

13:28 <z3ntu> bamse: Could you please pick this patch up to fix -next on arm32? :) https://lore.kernel.org/linux-arm-msm/20230921-pm7250b-sid-fixup-v1-1-231c1a65471f@fairphone.com/T/#u

15:11 <vknecht[m]> bryanodonoghue: downstream 8939 has this block added for VFE compared to 8916, which doesn't seem to have an equivalent in mainline, at least for vfe40/41... any idea how important that is ? could it explain the lower half of TPG image not showing the bars ?... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/wCldNGLuxJkJgifBBnBPFqNB>)

15:14 <bryanodonoghue> I don't think you need that to get the Raw Data Interface => RDI working

15:14 <bryanodonoghue> actually you already have that working

15:14 <bryanodonoghue> CSID -> RDI

15:15 <bryanodonoghue> the bit to focus on is the CSIPHY and the init sequence for it

15:15 <vknecht[m]> so the problem would be more about subtle clocks & freqs differences ?

15:15 <bryanodonoghue> hmm well the band of green down the bottom => all zeros

15:15 <bryanodonoghue> you should verify the contents of the frame increments as expected

15:16 <bryanodonoghue> perhaps generating 0xA5 would be easier

15:16 <bryanodonoghue> since any non 0xA5 data is invalid and indicates a bug

15:16 <bryanodonoghue> *gym

15:21 <vknecht[m]> doesn't look how it should I guess ?

15:25 <vknecht[m]> the first 2 frames are different... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/cRSvdqxGYKWDCaaggggBiwWb>)

15:49 <vknecht[m]> with 8916, all frames are identical, and hexdump gives... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/abvBISjeGKQmRIEqlDhCmhub>)

18:14 <bryanodonoghue> yep the 8916 is correct...

18:14 <bryanodonoghue> I was about to say it looks byteswapped but

18:14 <bryanodonoghue> 0001400 5555 5555 5555 5555 5555 5555 5555 5555

18:17 <bryanodonoghue> vknecht[m] you might thing about cherry-picking the debugfs stuff I have here

18:18 <bryanodonoghue> https://git.codelinaro.org/bryan.odonoghue/kernel/-/commit/2bba0a41cd157150706f7514222f79fd6043498f

18:18 <bryanodonoghue> and applying it for your gen1

18:18 <bryanodonoghue> would be interested to see if some of the error counters bump

18:36 <vknecht[m]> thanks, I'll look into that

20:20 <z3ntu> lumag: not sure how fast it would be for you, but if you add dpu support for msm8953, I'd be happy to test that ;) I checked for the 8996 patch how the mdp5->dpu relate and I definitely saw where some of the values are from but for quite a few others it wasn't immediately obvious so I'd need to spend quite some time on it I guess

20:21 <lumag> z3ntu, hmm, no SMP? definitely doable.

20:23 <z3ntu> If that's shown by no qcom,mdss-smp-data usage downstream then yeah, no SMP I guess^^

20:28 <lumag> anybody volunteering for msm8937 or msm8917 ?

20:34 <z3ntu> I'm sure we can find testers somewhere, either here or in the postmarketOS mainline channel

20:44 <aka_[m]> <lumag> "anybody volunteering for msm8937..." <- Affe Null: have 8917

20:44 <aka_[m]> i do have too kinda but not even ported device

21:19 <bamse> z3ntu: does "also need to" imply that things are currently broken?

21:20 <z3ntu> bamse: Well commit https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=8e2d56f64572 now requires the #define to be set before including the file, otherwise there will be a build failure as we see now

21:20 <z3ntu> I updated fp4 dts but missed this arm32 dts file so build of that fails

21:21 <mal> z3ntu: link the mailing list report of -next failure here

21:22 <z3ntu> https://lore.kernel.org/lkml/20230921084252.3c5ab501@canb.auug.org.au/

21:24 <bamse> z3ntu: okay, that's what i was wondring about...

21:25 <bamse> z3ntu: and now i saw the report in my inbox. thank you for the ping

21:26 <z3ntu> sorry for breaking it :)

21:28 <bamse> z3ntu: i should have paid more attention, missed it due to another build error in allmodconfg when building -rc1 :(

21:29 <z3ntu> Breaking arm32 when merging arm64 dts patches is quite rare I think ;)

21:33 <bamse> not if you're up to the crazy things we're doing ;)

21:33 <bamse> the problem there is that i do dt-validation etc on the dts and arm64 branch separately, and i don't think i merged any arm changes, so i didn't retest that build...

21:50 <lumag> z3ntu, I've sent experimental patches for 8953/8937/8917. Completely untested

21:51 <lumag> any feedback is appreciated.

21:51 <lumag> Note, I have enabled 'cursor' bit for the DMA plane, so that by default it will be used for the cursor display

21:57 <z3ntu> lumag: Nice, thanks! Compiling, hopefully can still test today :)

22:30 <z3ntu> lumag: Screen is initializing and displaying stuff :) But there's some errors

22:31 <z3ntu> [ 22.774205] [drm:dpu_kms_hw_init:1164] dpu hardware revision:0x10100000 - init is fine

22:31 <z3ntu> [ 23.099806] [drm:_dpu_encoder_phys_cmd_wait_for_ctl_start:657] [dpu error]enc31 intf1 ctl start interrupt wait failed

22:31 <z3ntu> [ 23.099821] [drm:dpu_kms_wait_for_commit_done:495] [dpu error]wait for commit done returned -22

22:32 <z3ntu> these messages appear ~13 times per second but screen is still updating

22:37 <lumag> z3ntu, heh, the ctl start again

22:38 <z3ntu> also what was the environment variable

22:38 <z3ntu> * for running kmscube with llvmpipe again? My current build doesn't have gpu in

22:40 <z3ntu> but need to go to bed now :) So in short: screen is updating but quite laggily, a few times person second I'd say. For sure not the full Hz it's supposed to run at

22:42 <z3ntu> ah and you're missing `"qcom,msm8953-mdp5"` in `msm_mdp5_dpu_migration` in the patch (+the other platforms), I don't think the code ever considers dpu with this missing