Guest66867 has quit [Remote host closed the connection]
s_frit has joined #linux-rockchip
urjaman has quit [Read error: Connection reset by peer]
urjaman has joined #linux-rockchip
inode has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
stikonas has joined #linux-rockchip
field^Mop has joined #linux-rockchip
ldevulder has quit [Quit: Leaving]
ldevulder has joined #linux-rockchip
ldevulder_ has joined #linux-rockchip
ldevulder_ has quit [Remote host closed the connection]
ldevulder has quit [Ping timeout: 272 seconds]
robmur01_ is now known as robmur01
<robmur01>
hmm, the most recent changes I see to RK808 are my cleanup from a year ago, and it shouldn't have anything to do with the GPU which has a separate dedicated regulator anyway, but hey :/
ldevulder has joined #linux-rockchip
ldevulder has quit [Quit: Leaving]
ldevulder has joined #linux-rockchip
lkcl has quit [Ping timeout: 264 seconds]
lkcl has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 260 seconds]
macc24 has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
<ndufresne>
robmur01: indeed, my mistake, I have no clue why moving from rc7 to 5.11.0 made a difference
<robmur01>
perhaps noteworthy that roc-pc seems to be the only RK3399 board which actually allows the GPU supply to be turned off
<robmur01>
possibly we actually need to model vdd_gpu as supplying the whole voltage/power domain rather than just the GPU itself :/
kaspter has joined #linux-rockchip
ldevulder has quit [Read error: Connection reset by peer]
<vagrantc>
hrm, maybe https-everywhere is interfering and redirecting ... but i don't get the usual option to opt-out strangely
kaspter has quit [Quit: kaspter]
ldevulder has quit [Ping timeout: 240 seconds]
ldevulder has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 256 seconds]
<ndufresne>
robmur01: and the problem came back on 5.11.0, I wonder why it's intermitant
<ndufresne>
any advise/workaround you could think of ? I'm not familiar with that code for the context
<robmur01>
my best guess at this point would be a timing condition when suspending/resuming the GPU
<robmur01>
I'm assuming that the power domain needs the regulator switched on to be able to respond, but RPM control of the power domain and regulator aren't necessarily sequenced appropriately because it doesn't know
<robmur01>
I imagine the cheap hack to just ignore the issue would be to flag vdd_gpu with "regulator-always-on" like everyone else does
<ndufresne>
robmur01: the dts already has regulator-always-on;
<ndufresne>
robmur01: perhaps a red-flag, the error is about pd_gpu
<robmur01>
oh, it's not there in the rc3-based branch I'm currently working on :(
<robmur01>
...nor in next/master. I guess you're not using the upstream DT (or the bootloader's fiddling with it, maybe)?
<ndufresne>
ah wait, I was looking at the wrong tree
<ndufresne>
ok, so always-on, boot-on was there in 5.4
<ndufresne>
but gone now
<ndufresne>
let me at least try that
<ndufresne>
do I need to comment out the bit with regulator-off-in-suspend;
<robmur01>
nah, suspend doesn't work properly anyway :)
<robmur01>
(if you're using mainline TF-A)
<ndufresne>
I'm using mainline TF-A, so ok
<ndufresne>
never tried to suspend
<robmur01>
if you try, it'll probably whinge about the XHCI being slow and fail; if you do manage to suspend, not everything will come back upon resume ;)
<ndufresne>
ok, so good so far with the workaround
<ndufresne>
it's likely not super helpful for random users though ;-P
<ndufresne>
I'm curious why/when these hack were removed
<robmur01>
well, it's not *technically* necessary to keep the supply to the voltage domain enabled when the single power domain inside it is power-gated anyway, so on paper it saves a little more power and is the right thing to do
<robmur01>
it's just that doing so in practice apparently exposes race conditions that people haven't really thought about :)
<robmur01>
I imagine that ideally the rockchip-pm-domain code wants an explicit notion of regulator supplies for its voltage domains
<mmind00>
ndufresne: is the vsel gpio Robin mentioned configured on some way? ... Maybe it's just floating?
<mmind00>
if I read that correctly it was about a fan5xxx clone on the roc-pc?
<ndufresne>
I doubt mine is clone, it's the one from librecomputer
<ndufresne>
mmind00: how do I check this vsel2_pin ?
<mmind00>
ndufresne: hmm looking at the mainline dts, I see the vsel2-pin being configured as pull-down and the suspend-voltage-selector being configured as 1 ... so I guess 0 = active, 1 = suspend voltage, and in theory that should work as expected
<mmind00>
just read the lines above ... so with regulator-always-on etc it worked?
<ndufresne>
yes
<ndufresne>
on-boot + always-on (like it was in 5.4)
<ndufresne>
I'm a little green here, but I see regulator-ramp-delay, does it mean it will take a bit of time before it's actually powered ?
<mmind00>
ndufresne: I think the ramp-delay is for the delay when changing voltages ... actually I'm not sure if there is an equivalent power-on-delay
<mmind00>
ndufresne: ah ... there is: regulator-enable-ramp-delay
<ndufresne>
again very green question, but these delay, should that be reflected when calling readx_poll_timeout_atomic() instead of hardocding 0,10000
<ndufresne>
extra context, before the hang, we get an error in rockchip_pmu_set_idle_request()
<mmind00>
ndufresne: I guess the fun issue is, that we don't really handle the soc's voltage-domains at all at this point
<mmind00>
ndufresne: i.e. all power-domains are part of a voltage-domain ... there are 6 on rk3399 (core_b, core_l, center, logic, gpu, pmu) ... and I guess the supply for all except maybe gpu will be running just the whole time
<mmind00>
ndufresne: I'm slightly heavy on wine right now (virtual release party ;-) ) ... but I guess one option would be to have supply-properties for the power-domains?
<mmind00>
or as a stop-gap reintroduce the regulator-always-on property for now
<ndufresne>
yeah, workaround until we have something implemented that ensure it's all on sync, roc-pc is indeed the only one without this always-on thing
<mmind00>
ndufresne: so, patches welcome ;-)
<ndufresne>
I can propose the alway-on bit for sure, the second part is a bit over my head, I'm looking at how removed it in the first place
<ndufresne>
*how -> who
<mmind00>
ndufresne: yeah, I meant the stop-gap :-)
<ndufresne>
thanks for the support, makes me learn a bit
<ndufresne>
ok, it was still there at dts split time (got split to support a mezzanine board)
<ndufresne>
mmind00: was removed by Markus Reichl, he removed that and added mali-supply = <&vdd_gpu>;
<ndufresne>
to the gpu node
<mmind00>
ndufresne: hmm, maybe he tested with built-in mali driver ... i.e. power-domains are on on boot and get disabled before handing over to userspace
<ndufresne>
what is strange is that all rk3399 have this mali-supply, but kept the always-on stuff
<mmind00>
not surprising, mali-supply is necessary for voltage scaling as well
<ndufresne>
ah, make sense
<ndufresne>
but I have no example of supply that is not at least always-on
<ndufresne>
what is vin-supply vs pwn-supply ?
<mmind00>
ndufresne: for "no example of supply that is not at least always-on", probably a result of the not-modelled connection
<mmind00>
ndufresne: vin-supply vs pwn-supply ... dependent on the regulator(-driver) I guess ... i.e. fixed-regulator uses vin-supply to declare it's parent-regulator