swdefrgthfgjhk has quit [Remote host closed the connection]
swdefrgthfgjhk has joined #linux-msm
BobBeck has joined #linux-msm
pespin has quit [Remote host closed the connection]
pespin has joined #linux-msm
<minecrell>
aka_[m]: afaik this "finger slip" is on all older RPM chipsets for some reason and only for the qcom,notify-rpm state. I guess they wanted to increase the latency for that state but I don't know why they used this weird number either
Caterpillar has joined #linux-msm
<konradybcio>
Degdag_Med: didnt try
pg12_ has quit []
pg12 has joined #linux-msm
<mort_>
does anyone know if there's something I should do to get qmi_wwan to set my modem's link state to up? It's currently reporting unknown even though everything is working
<konradybcio>
sorry I meant jhovold and not you Jeffrey
Caterpillar has quit [Remote host closed the connection]
Caterpillar has joined #linux-msm
<jhovold>
konradybcio: see 27da533af9b0 ("clk: qcom: gcc-sc8280xp: use retention for USB power domains")
<jhovold>
and I belive mani_s's is about to respin the runtime pm series but that's not directly related to system suspend
<konradybcio>
jhovold oh wow I even reviewedthat but overlooked it :D
<konradybcio>
jhovold: rpm is necessary to deassert the CX vote, without which the thing won't sleep
<jhovold>
that sounds like a bit of a mess then
<jhovold>
as runtime pm is supposed to be orthogonal to system suspend and can be disabled (or be left disabled) by the user
<konradybcio>
btw jhovold, looking at downstream (if it's correct as it's not obvious for 8280 but 8350 seems to fall into this category too), we are missing the RETAIN_FF_ENABLE flag on almost all gdscs
<konradybcio>
that flag enables retention of the state of some(?) registers
<jhovold>
i would not be surprised if that turns out to be the case, but it's not set for any SoC currently
<jhovold>
and qcom supposedly fixed the PWRSTS_RET_ON implementation
<konradybcio>
it's set on a whole lot of newer socs.. the flag was upstreamed in 2020
<konradybcio>
if you grep for qcom,retain-regs in vendor dts, you'll get tooons of matches, esp on newer socs
<jhovold>
try git grep RETAIN_FF_ENABLE, there are no gcc hits
<konradybcio>
well linaro has been upstreaming gcc for new socs about since that flag was introduced.. so perhaps everybody missed it with the initial submissions
<konradybcio>
you'll notice they're there in some drivers submitted by qcom or yours truly (dispcc, gpucc, video)
<jhovold>
that's entirely possible
<konradybcio>
also in some !gcc drivers submitted by other linaro folks fwiw
<konradybcio>
you may find useful this little incomplete LUT of mine
<jhovold>
i'd rather see some actual documentation for once, rather than play this pattern matching game with vendor kernels...
<jhovold>
i can wish
<konradybcio>
I'm afraid neither of us can really do anything about it
<jhovold>
indeed
<jhovold>
but yeah, i would not be surprised if this is broken
<konradybcio>
fwiw sc7180 is able to hit the RPMh-managed low power states
<konradybcio>
so jhovold wanna look into that gdsc situation or should I do it?
<jhovold>
konradybcio: sure, please do, as it seems to affect all qcom SoCs
<jhovold>
konradybcio: once we manage to hit the low power states on sc8280xp I guess it will become apparent quickly whether that bit needs to be set or not though
<jhovold>
i also noticed that some of the non-gcc gdsc that has RETAIN_FF_ENABLE still use PWRSTS_OFF_ON rather than PWRSTS_RET_ON, so perhaps the two are distinct
<jhovold>
konradybcio:^
<konradybcio>
I believe it's about individual GDSCs losing state so it may even be apparent when we get any sort of dwc3 suspend
<konradybcio>
Or PCIe
<konradybcio>
Yeah on off and ret are three different states
<jhovold>
yes, but i was referring to RETAIN_FF_ENABLE vs PWRSTS_RET_ON
<jhovold>
konradybcio: regarding dwc3, that the reason we set it to PWRSTS_RET_ON, which effectively leaves the thing on until we hit a low power state were qcom magic makes retention work (it is rumoured)
<jhovold>
actualluy powering down the gdsc indeed breaks system resume
<konradybcio>
I wonder if it'd be a far cry to borrow the downstream "working" dwc3-msm implementation, make the bindings compatible and replace what we have upstream today eh
<jhovold>
the less we borrow from "downstream" the better...
<minecrell>
bamse: Since Rob applied my other of_reserved_mem changes it would be nice to get the remoteproc changes still in for 6.5 so DTs could start making use of it in 6.6 without regressions
<mani_s>
konradybcio, I plan to respin the series once I'm back later this week. Currently on medical leave
<mani_s>
konradybcio, I _think_ only on chrome platforms we were able to hit rpm(h) low power states with upstream
<mani_s>
it'd be a great achievement if we could do it on x13s
<mani_s>
sadly there are many obstacles and we need more debugging on the rpmh level
<bamse>
mani_s: but in particular on 8280 we always vote for CX=on...
<mani_s>
bamse, for obvious reasons ;)
<bamse>
mani_s: well, even after dropping the always-on from pcie
<mani_s>
bamse, oh, where exactly?
<bamse>
mani_s: i dropped all ALWAYS_ON from gcc gdscs and i switched the gdscs to RET_ON
<bamse>
mani_s: but, given that we're not actually dropping the votes on CX that's mostly a nop
<mani_s>
bamse, but that's a device driver level limitation, right
<bamse>
mani_s: what do you mean?
<bamse>
mani_s: that CX isn't dropped?
<mani_s>
bamse, not all drivers dropping CX vote
<bamse>
mani_s: right
<bamse>
mani_s: unfortunately i was trying to figure out why the sleep vote for ddr was 1...and once i found that it was your pci vote i had to go to bed ;)
<bamse>
should have chased the other issue ;)
<mani_s>
bamse, before going for leave, I did drop ALWAYS_ON and used RET_ON as you did. And it didn't cause any issues during suspend. But we could keep it that way for now I believe
<bamse>
mani_s: what i did notice though, is that if i drop vreg_misc_3p3 during suspend pcie dies
<bamse>
mani_s: need to take another glance at the schematics, but i think i'm pulling the plug on parts of wwan...
<bamse>
mani_s: but regarding RET_ON...as i said above, we don't know if it works or breaks until we can get CX out of the way...
<mani_s>
bamse, I was told by pcie team that RET should work most of the cases
<mani_s>
so I'm in favor of getting rid of ALWAYS_ON
<bamse>
mani_s: yeah, me too...but it doesn't seem to make a difference...given that something else is holding CX anyways
<mani_s>
bamse, agree
<bamse>
mani_s: and worst case we fix that other thing, just to have pcie break
<bamse>
mani_s: so let's hold off on that patch until we've seen that we can drop CX
<mani_s>
bamse, ack
<bamse>
mani_s: i did some improvements to the rpmh tracepoint, will send that patch out
<lumag>
vkoul, robclark, I'd ask for your opinion on https://patchwork.kernel.org/project/linux-phy/list/?series=750217. It has been there for like a month w/o any attention. I have identified a fix in one of the drivers, but I'd like to hear any response before sending v2.
<lumag>
robclark, among other things this fixes HDMI support for 8974/8084, where we currently lack HDMI PLL support
<lumag>
There are also pending patches for HDMI on 8998, but I'd like to get it into a proper place from the beginning, rather than hacking another QMP PHY driver under drivers/gpu/drm/msm
<robclark>
lumag, I guess vkoul would be a fan.. I don't really object but sometimes I think they 1000's of tiny dependent drivers can be a pain... could we have kconfig dependency from DRM_MSM_HDMI on the PHY subsystem (and perhaps appropriate phy drivers) to at least make it not impossible for a mere mortal to figure out a working .config?
<lumag>
robclark, ack, sounds like a good point.
<lumag>
I used `default DRM_MSM_HDMI && ARCH_MSM8xxx` so that the individual drivers are picked up by default
<robclark>
ok.. sg
swdefrgthfgjhk has quit [Remote host closed the connection]
swdefrgthfgjhk has joined #linux-msm
<konradybcio>
mani_s: i'll surprise you, xosd works on windows sc7180
<konradybcio>
as in, on the acer aspire windows laptop that we support upstream
<konradybcio>
(after fixing some bugs and making all the hw probe)
<konradybcio>
bamse: mani_s yes let's finally drop AON
<konradybcio>
powering it off would be perfect, but not keeping it fully on sounds good as a half-measure..
j`ey_ has joined #linux-msm
swdefrgthfgjhk has quit [Remote host closed the connection]
swdefrgthfgjhk has joined #linux-msm
pespin has quit [Remote host closed the connection]
Mis012[m] has quit [Ping timeout: 480 seconds]
Newbyte has quit [Ping timeout: 480 seconds]
AffeNull[m] has quit [Ping timeout: 480 seconds]
travmurav[m] has quit [Ping timeout: 480 seconds]
mothenjoyer69 has quit [Ping timeout: 480 seconds]
go4godvin has quit [Ping timeout: 480 seconds]
JoelSelvaraj[m] has quit [Ping timeout: 480 seconds]
ungeskriptet[m] has quit [Ping timeout: 480 seconds]
MatrixTravelerbot[m]1 has quit [Ping timeout: 480 seconds]
maxim[m] has quit [Ping timeout: 480 seconds]
exkcmoeAdmin[m] has quit [Ping timeout: 480 seconds]
JIaxyga[m] has quit [Ping timeout: 480 seconds]
Leandro[m] has quit [Ping timeout: 480 seconds]
flamingradian[m] has quit [Ping timeout: 480 seconds]
alikateshethey[m] has quit [Ping timeout: 480 seconds]
DavidHeidelberg[m] has quit [Ping timeout: 480 seconds]
aedancullen has quit [Ping timeout: 480 seconds]
DylanVanAssche has quit [Ping timeout: 480 seconds]
minecrell[m] has quit [Ping timeout: 480 seconds]
sepkov[m] has quit [Ping timeout: 480 seconds]
aka_[m] has quit [Ping timeout: 480 seconds]
cmeerw[m] has quit [Ping timeout: 480 seconds]
eliaselias[m] has quit [Ping timeout: 480 seconds]
mirsal has quit [Ping timeout: 480 seconds]
uclydde[m] has quit [Ping timeout: 480 seconds]
Tooniis[m] has quit [Ping timeout: 480 seconds]
konradybcio has quit [Ping timeout: 480 seconds]
adomerle[m] has quit [Ping timeout: 480 seconds]
underpantsgnome[m] has quit [Ping timeout: 480 seconds]
ajhalaney[m] has quit [Ping timeout: 480 seconds]
z3ntu has quit [Ping timeout: 480 seconds]
ywnkmn[m] has quit [Ping timeout: 480 seconds]
RayyanAnsari[m] has quit [Ping timeout: 480 seconds]
Degdag_Med[m] has quit [Ping timeout: 480 seconds]
AntoniAloyTorrens[m]1 has quit [Ping timeout: 480 seconds]
Marijn[m] has quit [Ping timeout: 480 seconds]
alfayt[m] has quit [Ping timeout: 480 seconds]
vknecht[m] has quit [Ping timeout: 480 seconds]
sergi has quit [Ping timeout: 480 seconds]
danylo has quit [Ping timeout: 480 seconds]
jrole_8tst-j[m] has quit [Ping timeout: 480 seconds]