00:01 <lumag_> Marijn[m], dsi clocks? I have a plan to drop clocks which became unused after dropping manual clock setting, but that's it for now.

00:02 <lumag_> Marijn[m], or do you mean replacing msm_clk_get with plain clk_get?

00:02 <Marijn[m]> aka_: afraid of more delays for 8976?

00:03 <Marijn[m]> Refres your inbox, I replied 15 minutes ago

00:03 <aka_[m]> oh nice, i guess this kind of patch for changing pagetable formats might be used on 8953 too as old firmware setup 32bit ones(not sure if im right on that)

00:04 <Marijn[m]> lumag_: the clock tree built internally in the dsi pll drivers. Those also still use names instead of .hw pointers

00:06 <lumag_> Ah

00:06 <lumag_> This is not on my plate for now.

00:06 <Marijn[m]> Great, I'll try to finish my approach at some point then :)

00:06 <lumag_> So I'd keep in mind that you are looking onto that

00:07 <Marijn[m]> Yes, let me know if anything related pops up

00:10 <lumag_> My next goal is rebasing the multirect + few related issues

00:23 <lumag_> another issue that bugs me (but not to the level of actually rushing into the code) is the HDCP for the HDMI (db820c). My board doesn't have correct fuses for the HDCP 1.4 to work (or maybe the driver is looking in the wrong place). And according to the downstream it should be possible to get HDCP 2.x even w/o fuses.

00:24 <lumag_> Sounds like a fun item to take a look sometime in the future.

00:25 <lumag_> And I also have a debt of finishing patchset for proper active CTLs support.

07:55 <bhsharma> ndec: alimon: I am seeing sdx55-mtp related failures with OE CI jobs again. Here are the logs: https://ci.linaro.org/job/lt-qcom-openembedded-meta-qcom-premerge-master/171/MACHINE=sdx55-mtp,TCLIBC=glibc,label=docker-buster-amd64/console

07:56 <bhsharma> ndec: alimon: compilation seems to break with lttng-modules

07:56 <bhsharma> not sure, if its a known issue

08:38 <Marijn[m]> <lumag_> "And I also have a debt of..." <- What's missing now, and what does it mean for a ctl to be active in the first place? I found `CTL configuration is specified using active blocks` in a downstream kernel (would love if docs for missing enum entries could be added upstream) but it seems the mainline kernel is also able to set up blocks when the feature is not set, by calling non-v1 functions that write very similar values to

08:38 <Marijn[m]> different registers.

10:42 <Marijn[m]> vkoul: Looking through the GPI DMA i2c patch right now - is there any meaningful difference between "GPI" and "GSI"?

10:43 <Marijn[m]> lumag_: I see you just joined again - did you see my question about active ctls? Not sure if you might have received that through lumag instead :)

10:51 <lumag_> Marijn[m], I see it now :D

10:53 <lumag_> Marijn[m], active CTLs = v1 CTLs (they are used on sm8150 and later platforms). Bonded DSI setup (where two DSI hosts drive single panel/bridge) requires special configuration (using single CTL and specifying the master interface). I have patches in our Linaro tree, but I do not quite like them.

10:59 <Marijn[m]> lumag_: Ah thanks - I have indeed been messing around with the ctl vs ctl_v1 functions on a downstream kernel to understand the code flow. Looking forward to bonded DSI updates, afaik we have a few Sony phones that leverage this (massive screens) and they're all cmdmode too

10:59 <Marijn[m]> lumag_: Looking around on your repo there are a bunch of branches. Which one should I look at for this active CTL support in particular?

11:00 <Marijn[m]> lumag_: I do recognize a bunch of them from the lists, and even have some of your patches picked locally. I wish I could provide more tested-by's when our devices are more stable :)

11:04 <lumag_> Marijn[m], https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=tracking-qcomlt-sm8250

11:06 <lumag_> Marijn[m], oh, btw: can you recommend good (easy to flash & hack) device with the DSI panel in cmdmode?

11:07 <lumag_> I have the several panels for the dragonboards, but they work in video mode only.

11:09 <Marijn[m]> lumag_: Cool, I'll look through the patches and see if I can learn anything from them :)

11:14 <Marijn[m]> regarding `dpu_hw_ctl_intf_cfg_v1`, does it matter in what order the registers are written? Seeing as you read merge_3d first, write some other registers, and finally write it back. Also, shouldn't some of the bits in these registers be unset at some point? Or is the hardware doing that somehow elsewhere before the register is read back?

11:16 <Marijn[m]> lumag_: I'm currently using a Sony Xperia 10 mark II, simply because that one has eMMC storage and no DSC, unlike the other Sonys here that have a suicide-UFS (without quirks one of the flush commands sent by the kernel will wipe the bootloader, iirc also the partition table, and a bunch other important things) rendering the device an expensive paperweight

11:16 <lumag_> no, the order should not matter

11:17 <lumag_> Unsetting the bits is one the parts that is missing. That's why these patches were not sent to the ML

11:18 <lumag_> We miss few pieces of teardown, when disabling the crtc/encoder

11:19 <lumag_> Marijn[m], regarding the Xperia 10, is it easy to unlock/flash it? Never touched sony before

11:19 <Marijn[m]> lumag_: But those Sony UFS devices can still boot from sdcards, so they're next on the list now that we have the DPU "properly" working on cmdmode panels - and it'll allow us to help test on DSC too

11:21 <Marijn[m]> lumag_: Same problem here, have a patch lined up for submission but lacks the proper "unset" path. Downstream flushes the intf when it disables the command encoder, but we don't do any of that upstream (yet?), not sure if it matters. I don't have a way to test I guess, will have to check how to turn off and on the encoder but it probably only matters when switching to a different intf

11:22 <Marijn[m]> lumag_: Xperia's are a breeze to flash, you just have to "register" your IMEI on the Sony website (so they know you unlocked it 👀)

11:22 <Marijn[m]> Everything goes through `fasboot`

11:24 <lumag_> Marijn[m], sounds easy.

11:26 <Marijn[m]> lumag_: The only downside is that all these devices have a lot of outstanding work pending on our forks, we simply don't have the "workforce" to continuously create, review, iterate and send it all upstream

11:26 <Marijn[m]> Or rather, we have just enough time to work on the devices, but things usually block on something that takes much longer to polish and send upstream :)

11:27 <lumag_> Marijn[m], yep, sounds familiar.

11:27 <lumag_> For my tests I don't even need a storage (I usually use huge initramfs populated with all the tools and tests).

11:28 <Marijn[m]> lumag_: You caught my attention with "tools and tests" :)

11:29 <Marijn[m]> If you have a repo that builds an initramfs with all the tools you use to test DRM that's invaluable for us/me

11:29 <lumag_> Ah, simple. kmscube. libdrm-tests, i2c-tools, etc.

11:30 <lumag_> Unfortuntately no. I'm basing upon meta-qcom's initramfs-test-image, but heavily extended with additional packages

11:31 <lumag_> Firmware files, alsa-ucm, aplay/arecord, etc.

11:31 <lumag_> and of course iw/wpa-supplicant, iproute & iperf

11:32 <Marijn[m]> That sounds like something I must be able to piece together too, already have a bunch of initramfs and rootfs combos but none are ideal, or far too large

11:51 <lumag_> as I said, nothing fancy. modetest can do a lot.

11:51 <lumag_> (from libdrm-tests)

12:15 <lumag_> Marijn[m], (and btw: anything less fancy than that Xperia? I'm with second hand market phones or tablets).

12:16 <Marijn[m]> lumag_: Thanks for the suggestion, will start with libdrm-tests - but as mentioned above I have something tricky that probably requires an interface switch to function properly, so I need a more-fancy phone with ie. displayport output

12:17 <lumag_> I see

12:17 <Marijn[m]> lumag_: I'm pretty much completely locked in to Xperia, don't know much outside of these smartphones

12:18 <lumag_> Xperia is fine, just feeling bad buying new fancy phone and then using it to just occasionally test displays.

12:19 <Marijn[m]> lumag_: Yeah that's true - I'm mainlining these devices for the sake of having them already and wanting to run an upstream kernel

12:19 <lumag_> D

12:20 <Marijn[m]> If there's any testing you need on cmdmode panels feel free to loop us in otherwise - in all other cases we'll probably attempt to do the bringup and fixing ourselves to make these devices usable :)

12:31 <lumag_> Marijn[m], well, there are two patches from kholk[m] lingering in the patchwork.

12:31 <Marijn[m]> The early-out in `dpu_encoder_phys_cmd_wait_for_commit_done`?

12:44 <lumag_> yep

13:05 <Marijn[m]> lumag_: Will have to check that up with Angelo. From the looks of it wait_for_commit_done is probably only interested in said flush/wait_for_idle, so we might be able to get away with not waiting for the ctl to be started at all