kcxt @ home4d ago

pros: learning a lot about Qualcomm's DRM code lately

cons: have to distill said code into something simpler, maintainable, and hopefully expandable for U-Boot

so like, only DSI interface support (for now!), either single or dual "bonded" DSI, and then it gets really fun and messy with Display Stream Compression and weird displays that require a total of 4 DSC sub-blocks running in "merge" mode

So far I have ~300 lines of code that takes a `dpu_resource_request` and returns a `dpu_topology` and it seems to be basically right for at least 1 case XD

Show threadVal Packett 馃4d ago
@cas most (all??) panels that support DSC can run without it btw! but if only there was ANY FUCKING DOCUMENTATION AT ALL for any of their command sets 馃槩
Show threadkcxt @ home

@valpackett yeah it's a shame things are so obscure. honestly i think with a reasonable amount of effort we could start to get a better idea of what the vendor commands do and the capabilities (like i haven't seen anyone trying to parse the device descriptors you can read from the panel)

idk, a productive place to start would be to try and debug the issues with the fairphone 5 where changing the brightness causes corruption in the display xd

Jun 21 at 4:36pmWeb
Show threadLuca Weiss2d ago
@cas @valpackett Someone investigated this here with a PoC patch that apparently fixes the issue https://gitlab.postmarketos.org/postmarketOS/pmaports/-/work_items/4274#note_543132
I've forwarded this to lumag recently, in case he knows how to more properly resolve this
Fairphone 5: Artifacts when smoothly adjusting brightness (#4274) 路 Issues 路 postmarketOS / pmaports 路 GitLab

Describe your issue What's the expected behaviour?

GitLab
Show threadkcxt @ home2d ago

@z3ntu @valpackett ohhh damn nice!!! that fix looks interesting, i do wonder then if the "correct" fix would be in the clock driver, the rates we set should be the same as the current rate so we shouldn't actually touch the hardware in that case

would be interesting to log all the ops for the pixel/byte/byte_div clocks and see what's happening in CCF.

also i just noticed kodiak has a byte_intf clock, it's parent is the byte_div clock, the parent of that is the byte_src clock, so calling set_rate on the byte clock and then on the byte_intf clock will result in the rates for the byte_src clock being recalculated twice, that could definitely be causing some weirdness

I'd be curious to know if just removing the set_rate call on the byte_intf clock if the byte clock is already enabled would fix the issue

Show threadkcxt @ home2d ago

@z3ntu @valpackett

i.e. this:

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 5ee2bfed0b1d..dfeb63d7428e 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -399,9 +399,9 @@ int dsi_link_clk_set_rate_6g(struct msm_dsi_host *msm_host)
pr_err("%s: Failed to set rate pixel clk, %d\n", __func__, ret);
return ret;
}

- if (msm_host->byte_intf_clk) {
+ if (msm_host->byte_intf_clk && !clk_hw_is_enabled(__clk_get_hw(msm_host->byte_clk))) {
ret = clk_set_rate(msm_host->byte_intf_clk, msm_host->byte_intf_clk_rate);
if (ret) {
pr_err("%s: Failed to set rate byte intf clk, %d\n",
__func__, ret);
Show threadVal Packett 馃2d ago
@z3ntu @cas omg i have the same issue on the moto, thanks for linking this