<brgl>
steev definitely but I have one more crease to iron out and it's merge window anyway ATM
svarbanov__ has joined #linux-msm
macc24 has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: WeeChat 4.4.2]
Daanct12 has joined #linux-msm
macc24 has joined #linux-msm
<marc|gonzalez>
lumag: thanks, I'll have a close look at apq8096-db820c for HDMI audio
<lumag>
marc|gonzalez, at least it knowingly works :-D
<marc|gonzalez>
and I probably won't have time for cpufreq before moving on
<marc|gonzalez>
what does "it knowingly works" mean?
<marc|gonzalez>
lumag: what does "it knowingly works" mean?
<lumag>
"I have verified it few months ago"
<marc|gonzalez>
OK thanks
<marc|gonzalez>
Where is 6.12-rc1? I thought it was supposed to come out Sunday or Monday?
<lumag>
marc|gonzalez, -rc1 is two weeks
<marc|gonzalez>
So rc7 was Sep 8. Then on Sep 15, Torvalds made 6.11 final instead of spinning an rc8, so the merge window is open from Sep 15 to Sep 29?
srinik has joined #linux-msm
srinik has quit [Ping timeout: 480 seconds]
srinik has joined #linux-msm
Daanct12 has quit [Quit: WeeChat 4.4.2]
ektor5 has joined #linux-msm
shawnguo has joined #linux-msm
srinik has quit [Ping timeout: 480 seconds]
tmerciai1 has joined #linux-msm
<marc|gonzalez>
lumag: I find it confusing that db820c nowhere imports asoc_qcom_lpass_hdmi_dai_ops... This means this code is NOT required for HDMI audio, and thus what is it used for?
<lumag>
marc|gonzalez, I think it's for the DP playback. apq8096 didn't have lpass
<lumag>
also it well might be that it's only for the ChromeOS cases, they had slightly different TZ / DSP organisation
<lumag>
aka_[m], I'm not sure why you end up in that condition.
<lumag>
The platform should have max widths set to 2048
<aka_[m]>
function logs max_linewidth to it
<lumag>
Hmm. The condition seems incorrect. It should be if ((width != width || height != height || MSM_FORMAT_IS_YUV()) && !test_bit && !test_bit) error_out
<lumag>
Hm. Or no
<lumag>
We shouldn't proceed if there is no SDMA
<lumag>
so this one is correct
<aka_[m]>
maybe it shouldn't even go inside that first if
<lumag>
Which mode are you trying to set?
<lumag>
Can you lower the fps?
<lumag>
(or clock in the panel definition)
<lumag>
Also, let me check, how does it calculate max_core_clk_rate
<lumag>
Can you possibly check it in the debugfs?
<aka_[m]>
will printk soon
<lumag>
thanks
<lumag>
If it is less than 400M we might have found the issue
<lumag>
aka_[m], you might want to add opp-table to the MDP with the following values: 400M, 320M, 266.67M, 200M, 160M, 80M, 50M.
<lumag>
See how it's done on other platforms
<lumag>
But it's interesting, we should find a way to work w/o opp tables