ChanServ changed the topic of #linux-msm to:
lumag_ has quit [Ping timeout: 480 seconds]
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
cxl000 has quit [Quit: Leaving]
Daanct12 has joined #linux-msm
jhovold has joined #linux-msm
cxl000 has joined #linux-msm
pespin has joined #linux-msm
<aka_[m]> Mis012: so any idea which icc link can fail in such scenario?
<aka_[m]> GPU or MDP0 one
<aka_[m]> for gpu i was using mid value between bus-min/bus-max
<aka_[m]> im bit not sure about mdp
<aka_[m]> on 8953 there is only one ap-owned
<aka_[m]> 8976 have mdp0/mdp1
<aka_[m]> oh damn
<aka_[m]> second line has mdp1
<aka_[m]> does not happen on 8953
<aka_[m]> alikates (he/they): have you got something done with that freedreno issue?
<alikateshethey[m]> I have 0 idea about mesa so i was waiting for someone to pick up the issue
<aka_[m]> so its mesa issue?
<alikateshethey[m]> Yep
<aka_[m]> not kernel?
<alikateshethey[m]> Well, maybe its both
<Mis012[m]> aka_: you can probably read the QoS registers on downstream
<aka_[m]> so after i upgraded my rootfs to latest i should probably see same
<aka_[m]> Mis012: now i would like to try add additional link to interconnects
<aka_[m]> but not sure if mdp5 code takes any links
<aka_[m]> or it has to be one of "few"
<aka_[m]> struct icc_path *path0 = of_icc_get(&pdev->dev, "mdp0-mem");
<aka_[m]> struct icc_path *path1 = of_icc_get(&pdev->dev, "mdp1-mem");
<aka_[m]> struct icc_path *path_rot = of_icc_get(&pdev->dev, "rotator-mem");
<aka_[m]> interconnect-names = "mdp0-mem", "cpu-cfg";
<aka_[m]> uhh?
<aka_[m]> sdm630 have these with ok props
<aka_[m]> and it has OPP table
<aka_[m]> i have no idea where mdp freq table comes from downstream while i have idea its about assigned-clocks = <&mmcc MDSS_MDP_CLK>,
<aka_[m]> because vsync one is probably 19.2Mhz always
<aka_[m]> or how it was
<aka_[m]> ok so there is ftbl_mdp_clk_src inside mmcc for sdm660 now i need to find freq ->icc mappings
<aka_[m]> ok i get it i think.
<aka_[m]> bw tables freqs represent each link.... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/vGrjqTjHRmeunAqVIWwoHcUi)
<aka_[m]> mainlining is not really good thing for dumb ppl, too easy to get frustrated
<Mis012[m]> it's in bytes?
<Mis012[m]> interesting choice
<aka_[m]> downstream qcom,msm-bus,vectors-KBps
<Mis012[m]> well, big K definitely isn't a thing, so idk xD
<aka_[m]> Mis012: btw how bad is sending DTS with OPP tables but without them wired
<aka_[m]> or with nodes disabled
<Mis012[m]> seems pointless
<aka_[m]> like add node for gpu but keep it disabled because lacking iommu.
<Mis012[m]> hm, right
<Mis012[m]> the thing is, can you verify that it's correct and works
<aka_[m]> if someone didnt had it working then why he would to that
<aka_[m]> sometimes you know there are non upstreamable hacks
<Mis012[m]> then maybe
Daanct12 has quit [Ping timeout: 480 seconds]
<calebccff> elder_: I discovered that the IPA driver uncoditionally suspends the hardware 5-10 seconds after the kernel suspends, breaking the "wake up on data" feature.
<calebccff> I tried disabling runtime PM, but it seems like that causes pm_runtime_get_sync to return some error so I wind up hitting the WARN_ON in ipa_isr_thread and the devices wakes up immediately after suspend
<calebccff> I plan on taking a look when I get the chance, I thought I should let you know. On that note, do you think it makes more sense to have userspace disable runtime PM explicitly if they want to make use of the wake-on-data feature? Or should the IPA just never sleep if there are open connections?
<calebccff> (or maybe there's some much smarter solution I haven't thought of)
cxl000 has quit [Quit: Leaving]
cxl000 has joined #linux-msm
<aka_[m]> Do anyone knows anything about rotator?
<aka_[m]> on msm8976 there is old mdss_mdp_rotator.c driver and on 8953 we have mdss_rotator.c
<aka_[m]> interconnect path for mdss_rotator.c sits in dts and points to some slave one and on 8976 i have no idea if i should provide that link
<aka_[m]> Upstreamed Angelo's tree have this interconnect path defined but only have two usecases with lowest vote(0) and max one which seems to be lowest one from other than 0 on 8953
<aka_[m]> Somehow it turned out after adding opp table and MDP PORT1 icc link i don't see blue stuff anymore
<aka_[m]> worst case scenario will be i request bandwidth for something what does not work right?
<elder_> @calebccff You know more about how this behaves than I do. Like I said before, I was never able to reproduce the IPA-triggered system resume behavior and so I haven't spent a lot of time investigating oddities like this. There is a recent bug fix to the interconnect driver that could have something to do with you're seeing; we should make sure you have that.
<alikateshethey[m]> <aka_[m]> "Somehow it turned out after..." <- You still have low framerates when scrolling?
<aka_[m]> feels kinda smooth now
<aka_[m]> still terminal cursor sometimes blinks like twice fast
<aka_[m]> uh scrolling if i pull and let it run slowly
<aka_[m]> it jumps
<aka_[m]> a bit
<aka_[m]> top bottom
<alikateshethey[m]> Well maybe the touchscreen has something to do...
<aka_[m]> still i havent been able to launch settings
<aka_[m]> they just crash
cxl000 has quit [Remote host closed the connection]
<elder_> The WARN_ON() in ipa_isr_thread makes sense, again, something that would have been fixed had I been able to reproduce that condition. The way I want to make it work is that the interrupt would have both a hard and a soft interrupt handler function. The hard handler would trigger a system wake, the soft handler would cause the IPA hardware to wake up.
<elder_> I do not believe user space should be involved in managing runtime PM at all in the IPA driver. At least, outside of the generic prevention mechanisms. The driver should do it all correctly regardless of the system suspend state, and should not require user space intervention.
cxl000 has joined #linux-msm
<aka_[m]> alikates (he/they): well, on 8976 setting are also broken
<aka_[m]> just finished updating from aport
<alikateshethey[m]> It uses adreno 5xx?
<aka_[m]> 510
<aka_[m]> twice of perf of 506
<alikateshethey[m]> Then it sure is a mesa issue
<alikateshethey[m]> I mean, what else can it be...
calebccff has quit []
calebccff has joined #linux-msm
pundir has joined #linux-msm
<calebccff> had some IRC mishaps and lost my backlog, can anyone send logs from here from today?
<aka_[m]> calebccff: thats what was to you
<aka_[m]> everything else is me Alikates and maybe Mis, unrelated
<calebccff> thanks
lumag_ has joined #linux-msm
pespin has quit [Remote host closed the connection]
jhovold has quit [Ping timeout: 480 seconds]