10:34 <z3ntu> bryanodonoghue: didn't check much yet but rebasing my camera things on your "arm-laptop/wip/x1e80100-6.13-rc1+camss" branch gives me this error when starting the camera stream: [ 175.502226] qcom-camss acb3000.camss: could not sync v4l2 controls: -95

10:37 <bryanodonoghue> what about if you only go as far as https://git.codelinaro.org/bryan.odonoghue/kernel/-/commit/3e78a0a6fc80a7048b6badf8a9be1caf91216f47

10:41 <z3ntu> bryanodonoghue: definitely getting into the return -EOPNOTSUPP in csid_set_test_pattern. I will try dropping the other commits

10:43 <z3ntu> bryanodonoghue: just 3e78a0a6 plus my patches works as expected

10:43 <bryanodonoghue> ok thanks I've only really tested that branch on x1e - not across rb3, rb5, rb3-gen2 yet

10:44 <bryanodonoghue> i had a few merge conflicts probably broke something in the resolve

10:51 <z3ntu> hm one thing I'm noticing now is that media-ctl -p says the cam is linked with msm_csiphy0 even though in DTS I connect the endpoint to port@1 (so csiphy1)

11:00 <z3ntu> bryanodonoghue: anyways, it works as expected when dropping just the TPG-optional commit, so I've got debugfs with the imx858 in higher resolution which just hangs. Not sure you can see anything useful there? https://public.lucaweiss.eu/tmp/camss-broken.txt

11:18 <z3ntu> bryanodonoghue: actually something else is wrong with that branch, with the sensor driver that should work, I also don't get any picture, it just seems to hang

11:20 <bryanodonoghue> CSID_CSI2_RX_TOTAL_PKTS_RCVD 0x00000000

11:20 <bryanodonoghue> CSID_CSI2_RX_TOTAL_PKTS_RCVD 0x00000000

11:20 <bryanodonoghue> CSID_CSI2_RX_STATS_ECC 0x00000000

11:20 <bryanodonoghue> CSID_CSI2_RX_CRC_ERRORS 0x00000000

11:21 <bryanodonoghue> no bueno

11:21 <bryanodonoghue> nothing is coming from your CSIPHY to your CSI Decoder

11:22 <bryanodonoghue> does a lower resolution work ?

11:22 <bryanodonoghue> I'd verify that stream_on actually did something

11:23 <bryanodonoghue> i.e. that you didn't get a semi-silent failure in the sensor or in the camss setup

11:24 <bryanodonoghue> and does your link_freq support the bandwidth you are pushing @ the higher resolution

11:24 <bryanodonoghue> probably not if a lower resolution works for you

11:24 <z3ntu> I think right now nothing works, not even the same setup as was working on my own branch without your patches

11:25 <bryanodonoghue> so if you just go to https://git.codelinaro.org/bryan.odonoghue/kernel/-/commit/35da38474cb001865cdb09f2bc09b5d8fb6a5ab4

11:25 <bryanodonoghue> thats basically 6.13-rcX

11:25 <bryanodonoghue> let me know

11:29 <z3ntu> bryanodonoghue: so on https://git.codelinaro.org/bryan.odonoghue/kernel/-/commit/3e78a0a6fc80 (the commit you sent + sc7280 commits) it works fine

11:29 <z3ntu> shall I try to bisect?

12:00 <bryanodonoghue> up to yourself

12:31 <z3ntu> bryanodonoghue: oh, I think it's just "media: qcom: camss: Add an id property to struct resources" not including sc7280 when adding the IDs so I guess it's always 0

12:34 <bryanodonoghue> ah yes that makes sense I haven't been carrying the 7280 patches in my tree until yesterday

12:34 <bryanodonoghue> thx

12:50 <Tofe_> I wonder, if I want to have a node in /dev for my uart device (a touchscreen), is it necessary to declare a "serial" alias, or is there another way? Currently I get a ttyMSM node, but I get strange data via uart (many more zero bits than expected), so I'm looking for clues

12:50 <Tofe_> I mean, I don't really need a tty for this, just a device node

13:10 <z3ntu> bryanodonoghue: also can confirm now with .id=0 to .id=4 added to csiphy_res_7280 it works fine, or at least as before without your patches

13:10 <z3ntu> bryanodonoghue: for imx858 with higher resolution hanging, now CSID_CSI2_RX_TOTAL_PKTS_RCVD is going up, e.g. 0x00bb4756 but capture is still hanging. And vfe0 debugfs has 0 for all values so that's also not helpful

13:11 <z3ntu> did we conclude something with the virtual channel stuff used with this mode, if this second stream of type PDAF might break this

13:24 <bryanodonoghue> best place to discuss PDAF is #libcamera

13:29 <bryanodonoghue> i.e. I'm not sure if the SoC needs to somehow interact with the autofocus or if its just magic in the sensor

13:29 <bryanodonoghue> I'd imagine the SoC needs to be involved somehow more than just a magic write sequence to the sensor

13:31 <z3ntu> bryanodonoghue: I'm happy just ignoring this PDAF stream for now and only taking the cam stream but I feel like (without any evidence) that the sensor sending this stream messes up the receiving side on qcom somehow

13:31 <bryanodonoghue> I think that is sensible

13:32 <z3ntu> actually I could try the 8192*6144@30fps (4:3) mode, that one only has one stream defined in the xml

13:32 <bryanodonoghue> that should work

13:35 <z3ntu> This virtual channel thing is part of CSI2 standard I imagine?

13:36 <z3ntu> there's actually decent text in the CCS spec, reading now...

13:39 <z3ntu> "17.4.2 Data Type PDAF Interleaving" based on the xml I'm guessing the init sequence is doing this

13:40 <z3ntu> "17.4.1 Virtual Channel PDAF Interleaving" I'm guessing would be if the xml had vc=0 for 10-bit raw and vc=1 for PDAF

14:46 <Pan[m]> <flamingradian[m]> "looking at your dmesg again..." <- im still struggling with this, i've checked every bit on the kernel, and every node seems okay, my guess is that i could be missing firmware files that are required on xiaomi devices but not on others (?, beryllium has these acdb and dsp folders that i don't have

14:46 <Pan[m]> https://gitlab.com/sdm845-mainline/firmware-xiaomi-beryllium/-/tree/master/usr/share/qcom/sdm845/Xiaomi/beryllium?ref_type=heads

14:48 <z3ntu> bryanodonoghue: I'm also seeing there's some clamps to 8191 for height & width, is this some old limitation that's not applicable to the newer HW because this sensor mode is 8192x6144 and Android can also capture a 50MP photo?

14:48 <z3ntu> [0:06:48.780467647] [4281] DEBUG SimplePipeline simple.cpp:764 Source 'imx858 17-0029':0 produces 8192x6144-SRGGB10_1X10, sink 'msm_csiphy1':0 requires 8191x6144-SRGGB10_1X10

14:49 <z3ntu> ah found something on the list https://lore.kernel.org/linux-arm-msm/20240802152435.35796-2-jorcrous@amazon.com/

16:07 <bryanodonoghue> z3ntu I forgot about that series

16:07 <bryanodonoghue> if jordan doesn't reup it would appreciate it if you could

16:07 <bryanodonoghue> since you have hw to test

16:12 <z3ntu> bryanodonoghue: I don't have 8250 but at least for the higher resolution patch, while it doesn't fail anymore during pipeline setup, it's also not actually capturing a frame, not sure what the problem is now again

16:16 <z3ntu> hopefully I figure this out at some point soon, would be nice... :)

16:22 <Pan[m]> <Pan[m]> "im still struggling with this, i..." <- oh okay, systemctl is more useful, that status=4/NOPERMISSION is interestting, but i don't think it is the problem ```Dec 06 16:18:42 xiaomi-nabu systemd[1]: Started Qualcomm... (full message at <https://matrix.org/oftc/media/v1/media/download/AYbCfJ6LDdclexyNF5P7_QA5bkma1lqYHZTXksjnpB7NUx2yq9_S7V1Oqsg7gk5uDV0EhaltyXqGO4TZw6PQ2WFCeT5OD0cgAG1hdHJpeC5vcmcvbGZYa1lkbFpCbnhvU1RoRkJ6SWRibW11>)

16:23 <Pan[m]> > <@kypanteru:beeper.com> im still struggling with this, i've checked every bit on the kernel, and every node seems okay, my guess is that i could be missing firmware files that are required on xiaomi devices but not on others (?, beryllium has these acdb and dsp folders that i don't have https://gitlab.com/sdm845-mainline/firmware-xiaomi-beryllium/-/tree/master/usr/share/qcom/sdm845/Xiaomi/beryllium?ref_type=heads

16:23 <Pan[m]> * oh okay, systemctl is more useful, that status=4/NOPERMISSION is interestting, but i don't think it is the problem

16:27 <Pan[m]> oh wait, i should try first with openrc again, i think there were issues even with op6

16:27 <Pan[m]> * with op6 (on systemd)

17:38 <Pan[m]> ig ```iov_base=NULL``` could also be part of the problem, where is this value grabbed from?