ChanServ changed the topic of #linux-msm to:
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
<niej> abhinav__: Do you have any finding on MDSS DPU register dump from 1mixer/1DSC/1intf topology? The only difference I can find is the panel resolution. But the width limitation does not explain the LCD content distortion.
srinik has joined #linux-msm
srinik has quit [Ping timeout: 480 seconds]
srinik has joined #linux-msm
srinik has quit [Ping timeout: 480 seconds]
pespin has joined #linux-msm
<aka_[m]> @krzk I will be soon home and will test bindings but answering part of questions
<aka_[m]> 'why there is no clocks'
<aka_[m]> Seems I got wrong idea and ipa rpmcc clock is not required so it was dropped
<aka_[m]> Changes to description: as 8953 got accepted after my series I got some obvious idea of coping it if it was deemed proper&accepted
<aka_[m]> I only put an effort for testing code with w=1 and no bindings
aarch64enjoyer has joined #linux-msm
mripard has quit [Quit: mripard]
dliviu has quit [Ping timeout: 480 seconds]
<aka_[m]> krzk: do you see backlog?
dliviu has joined #linux-msm
<aka_[m]> uh
<aka_[m]> now i wonder
<aka_[m]> if 8976 and 8937 don't need much more, can i shove them into qcom,rpm.yaml instead?
<aka_[m]> i would need singular case for snoc-mm
<aka_[m]> or move them into 8939 yaml
<aka_[m]> 8939 was split from common
<lumag> marc|gonzalez, I wrote that I won't check the math, but one thing looks strange. I don't see a PD_CTL write that should enable the PHY.
<lumag> Interesting, downstream also there is no such write
<rawoul> lumag: it's a copy paste of downstream... I had tried to simplify the code to make it similar to msm8996 but it wasn't working. This code was in #if 0 defines in marc|gonzalez first submission
<rawoul> but since the downstream code passes HDMI certification it's tempting to keep it as is
<lumag> rawoul, yes, I found the write that I was looking for
<lumag> rawoul, marc|gonzalez I picked up the patch locally and I'm trying to integrate it into my old HDMI PHY rework.
<aka_[m]> lumag: HDMI_PHY_PD_CTL ?
<lumag> aka_[m], yes. On msm8996 there is a final write of 0x1f to that reg.
<lumag> on msm8998 there is none
<rawoul> yes, it's called REG_HDMI_8998_PHY_PD_CTL in the submitted patch
<rawoul> same as 8998
<aka_[m]> maybe they baked it somewhere in code
<rawoul> oups no you're right, it's different
<aka_[m]> PD reg is about hdmi power domain?
<aka_[m]> or idk power delivery
<rawoul> 8998 just sets RESET_TSYNC_EN=1 in PHY_TX[0123]_LANE_CONFIG instead
<rawoul> and then the PHY_TX[0123]_LANE_CONFIG is set to 0x1f in _prepare
<lumag> rawoul, yes. I was looking for PHY_CFG instead - a register write that kicks PHY alive
<aka_[m]> both same value on 8996/8998
<aka_[m]> on reset ofc
ungeskriptet is now known as Guest602
ungeskriptet has joined #linux-msm
Guest602 has quit [Ping timeout: 480 seconds]
<rawoul> aka_[m]: are you sure ? I see bit 6 is reserved on msm8996 while it's HP_EN on msm8998, and the code reflects this
<aka_[m]> seems like sheet might miss some fields
<aka_[m]> ah
<aka_[m]> okay
<aka_[m]> i means reset value is same
<aka_[m]> 0x5
ungeskriptet is now known as Guest607
pespin has quit [Remote host closed the connection]
Guest607 has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #linux-msm
<aka_[m]> bamse: Luca Weiss im quite a big dumb but i guess i hit some kind of dependency hell
<aka_[m]> so in short:
<aka_[m]> GCC depends on rpmcc, rpmcc depends on smd-edge, smd-edge depends on mailbox, mailbox depends on gcc
<aka_[m]> Luca Weiss: so known?
<aka_[m]> Luca Weiss: moved from mbox back to ipc on smd-edge
<aka_[m]> and seems to work
<z3ntu> oh did I break something there with my patches?
<aka_[m]> well its dependecy you talked about
<aka_[m]> so you know exactly what breaks
<z3ntu> can you be a more explicit? Which SoC are you talking about now?
<z3ntu> I definitely didn't mean to break anything...
<aka_[m]> 8976
<aka_[m]> same cpufreq setup like 8226
<z3ntu> can you replace rpmcc to xo_board in &gcc like I did on 8226? Does that work for you?
<aka_[m]> probably would work
<aka_[m]> as long as it breaks dependency chain
<aka_[m]> but what would be real solution
<z3ntu> <z3ntu> "ah and https://lore.kernel.org/..."; <- ^ konradybcio mentioned something
<aka_[m]> also any idea what about cpr being not so great with default governor?
<aka_[m]> for 8976 i need to split mem-acc codepath into separate functions to have it atleast not failing on me, not sure about working
<z3ntu> I've got no clue about cpr myself, sorry
<z3ntu> aka_: but for apcs, can you let me know whether xo_board for gcc works, if so I'll send a patch to fix it up. And also scan for other SoCs that I might have also broken in the same way
<aka_[m]> i would say ones where apcs binds apcs-clk-msm8916 or how its called
<aka_[m]> so 8939 and i guess qcs404?
jhovold has quit [Ping timeout: 480 seconds]