<diederik>
You addressed Mark's comment, but without the 'Done' it's still listed as unresolved
<qschulz>
diederik: thanks, we actually have the complete opposite workflow internallyt
<qschulz>
you're not allowed to mark a comment as done except if it is your comment
<diederik>
let's say I'm not a fan of Gerrit ... ;-)
* qschulz
M.U.S.T. R.E.S.I.S.T. S.T.A.R.T.I.N.G. A. F.L.A.M.E. W.A.R.
<diederik>
I like your workflow better and makes much more sense
<qschulz>
except if the commenter just disappears for some reason
<qschulz>
or simply forgets
<diederik>
yeah, those are exceptions
<diederik>
FWIW: I don't (actually) know, but my remark is based on what I have observed ... and a bit wondering why it takes so long for a follow-up
<qschulz>
diederik: I don't remember who publicly complained about TF-A contributions taking WAY too long but it's been reported to arm already IIRC
<diederik>
could've been me ;-P
<diederik>
I had hoped/expected (1.5 years ago?) to have proper support for rk356x and possibly rk3588 in Trixie ... but that was too optimistic
<qschulz>
I had hoped my seemingly trivial fixes could have been merged in time for v2.12 but -rc0 has been released already, so it probably won't make it :(
<qschulz>
seems like people are pushing on that one, but I geuss the branch is incorrect? why lts-2.8?
xha has joined #linux-rockchip
<mmind00>
naoki qschulz: running RUSTICL_ENABLE=panfrost clpeak on my (headless) rk3576 firefly works just fine "Device: Mali-G52 r1 (Panfrost)" + "Driver version : 24.3.0~rc2+rocket-1 (Linux ARM64)"
<mmind00>
so having the gpu even without graphics definitly makes sense
<qschulz>
maybe something was added recently for headless support in mesa?
<qschulz>
or maybe it was an issue with glmark itself?
<diederik>
qschulz: it seems to me that targetting lts-v2.8 was incorrect as I'd expect that targetting master is the norm after which it could be backported to a lts version
<mmind00>
qschulz: ah .... glmark won't run without a display
<qschulz>
diederik: especially since 2.8 doesn't have rk3568 support IIRC?
<mmind00>
was more thinking about the CL side of a lone gpu ;-)
<qschulz>
mmind00: but there's an --off-screen option, why does it need a display :)
<diederik>
qschulz: master doesn't have it either, but having the build config is a requirement for the CI to succeed
<mmind00>
qschulz: something something about needing render-properties (depth, size or so)
<qschulz>
diederik: rk3568 is support in master
<qschulz>
supported*
<qschulz>
the source code
<diederik>
sorry, you're right. But scmi support for rk3568 is not
<qschulz>
ci script, don't care :)
<diederik>
My guess is that having things like unresolved comments or no checkmark in 'V' in https://review.trustedfirmware.org/q/rockchip could be a reason for things to not move forward
<qschulz>
diederik: so my guess is that RK356x won't work without this scmi stuff, correct?
<qschulz>
(I don't have an RK356x device nor do we plan to do products with it, but I am trying to push meta-rockchip to use upstream TF-A, so would rather want to know if I'm driving stuff in the ravine :) )
<qschulz>
diederik: well, you could have some clocks in secure mode and not need them from Linux perspective :)
<qschulz>
but I guess the fact I see some "gpu clk path" comment, it's probably a bit important :)
<diederik>
yeah and I'm about to test a workaround for it ... which does not make me happy (always-on)
warpme_ has joined #linux-rockchip
<qschulz>
diederik: I assume this is used for gpufreq too, so you'd need only one OPP for it?
<qschulz>
diederik: you could enable and set the rate in TPL or SPL
warpme_ has quit [Client Quit]
<qschulz>
before entering TF-A (provided TF-A doesn't reset those right now :) )
warpme_ has joined #linux-rockchip
<qschulz>
but that won't be upstreamable
<qschulz>
so not sure which kind of patches you want to maintain out-of-tree yourself :)
<diederik>
my whole goal is to get (all) things upstream, so that the PineNote could be supported with (pure) Debian
<warpme_>
test
<qschulz>
diederik: I get that, but why the GPU always-on then?
<diederik>
to see if that would be needed for resume to work as that currently does not work
<qschulz>
with the patch in TF-A's Gerrit you mean I guess?
<diederik>
Hopefully this is just a debugging step which could provide info for a 'proper' solution
<diederik>
yep
<qschulz>
gotcha
<qschulz>
i'm fortunate enough to not have anything requiring suspend right now :)
<diederik>
I'm generally interested in saving energy, but for the PN it's rather essential
warpme_ has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]