<z3ntu>
Hi, I'm trying to get displayport to work on sm6350 but hitting a weird issue regarding link clk frequency. For the requested link rate=540000 in dp_ctrl_enable_mainlink_clocks we call dev_pm_opp_set_rate with target_freq=540000000 (clk name: disp_cc_mdss_dp_link_clk) but the clk_round_rate there makes this into freq=810000 and subsequently qmp_dp_link_clk_determine_rate fails because that's not a valid frequency, only for example 810000000.
<z3ntu>
Without any debug statements the visible error in kernel log is: "msm-dp-display ae90000.displayport-controller: _opp_config_clk_single: failed to set clock rate: -22"
<z3ntu>
So somewhere there seems to be confusion between how many zeroes should be where.. But not sure how this is working on other SoCs, I don't see anything much different for my SoC
<z3ntu>
Kernel base is 6.8.1 fwiw
<z3ntu>
clk_round_rate behavior feels correct as ftbl_disp_cc_mdss_dp_link_clk_src lists the frequencies as 162000/270000/540000/810000 so it rounds it to the highest available frequency of the clock
mort_2 has quit []
mort_2 has joined #linux-msm
<strongtz[m]>
krzk: Hi, I would like to get i2s codec working on 8550, but I wonder if that's even supported with the q6apm/audioreach stuff? I know Qualcomm reference designs don't usually utilize i2s interface.
Daanct12 has quit [Quit: WeeChat 4.2.1]
<krzk>
strongtz[m]: I have never tried, don't know. There is I2S pin function for some of LPASS LPI pins, LPA IF should support I2S, WSA macro also has I2S, because we have like 4 or 5 instances of I2S
<krzk>
This means they will be used differently than standard audio which we upstream.
<krzk>
But I don
<krzk>
I don't know what you need to do to use them.
<z3ntu>
Regarding what I was writing some hours ago with displayport clock issues, at least I'm guessing that's what causing this corruption on usb-c -> hdmi dongle. Or does anyone have an idea what else this could be? The picture issues are also flickering a bit fwiw
<travmurav[m]>
Luca Weiss: what resolution this is? btw
<travmurav[m]>
but perhaps robclark would know better
<z3ntu>
travmurav: oh you're thinking this might be a GPU issue, rather than a DisplayPort issue?
<travmurav[m]>
Luca Weiss: not sure, but if when you open a window and it looks "sane" only on every 4th "line", then the visual bug is the same as what I saw before ^^ fix
<robclark>
maybe.. I guess if it works it works. But at least in some cases the value depends on the memory type (which we do not have a good way of handling)
<lumag>
z3ntu, robclark strange, In msm_mdss.c sm6360 has HBB=1, which translates to 14.
<lumag>
z3ntu, could you please try whether setting ubwc_static to 0xe or to 0x16 (with hbb = 1 / 14) fixes the issue?
<lumag>
robclark, where do we calculate the size of UBWC planes?
<z3ntu>
lumag: so ubwc_static=0xe + hbb=1 and a different try ubwc_static=0x16+hbb=14?
<z3ntu>
Or what exactly do you mean?
<lumag>
no, msm_mdsss / hbb = 1, a6xx_gpu, hbb = 14, then in msm_mdss ubwc_static = 0xe or 0x16
<z3ntu>
We already have .highest_bank_bit = 1, in sm6350_data so I'll leave that be
<z3ntu>
Same corruption with `gpu->ubwc_config.highest_bank_bit = 14;` + `.ubwc_static = 0xe,`
<z3ntu>
Also with `gpu->ubwc_config.highest_bank_bit = 14;` + `.ubwc_static = 0x16,` :(
<z3ntu>
lumag: anything else you want me to test?
<lumag>
z3ntu, no ideas for now :-(
<z3ntu>
ok thanks :)
<lumag>
I don't have good reference for UBWC, so probably we can land your commit. I don't see anything else that might be wrong there.
<z3ntu>
Do you think there are any side effects setting hbb=13?
<robclark>
re: mismatch btwn dpu and gpu hbb, I've seen that in a couple places, which is why I didn't get too far with my idea about global ubwc config table. My guess is just that we don't properly understand the dpu regs for the different generations of ubwc
<lumag>
Hmm.
<lumag>
z3ntu, so the issue only appears on 1920x1080? or with some other resolutions too?
<z3ntu>
lumag: it's at least 5 resolutions that showed up in the Phosh/GNOME settings, some other ones inbetween did work (which I sent before)
<lumag>
<z3ntu> The other resolutions that work: 1440x900, 1600x900, 1600x1200, 1680x1050. The rest has this flickering
<lumag>
and also you mentioned 800x600
<lumag>
any other that didn't work?
<lumag>
robclark, I'm thinking whether using multirect + UBWC has this side-effect
<z3ntu>
At least 1920x1200 and 1920x1080 had it, I'd need to test again to see what other resolutions had this problem
<robclark>
hmm, not entirely sure why multirect would matter