<aka_[m]>
jokes aside msm8996 perf would be plenty for most ppl i think.
ahalaney has joined #linux-msm
Danct12 has quit [Quit: Quitting]
Danct12 has joined #linux-msm
CosmicPenguin_ is now known as CosmicPenguin
<bamse>
konradybcio: damn it, Shawn fixed bits and pieces all over the place, so must have missed the discrepancy between $subject and the rest of the patch
<bamse>
konradybcio: and yes, that's a much more pleasant 8996 ;)
<konradybcio>
Tbf I am not sure
<konradybcio>
Maybe if you're not literally a guest on your device
<bamse>
konradybcio: it supposedly fix both the uSD and the USB transfer issue
<konradybcio>
woah
<konradybcio>
big if true
<bamse>
konradybcio: how's the stability on your 8996 btw? one of my db820c boards still locks up quite often during boot...
<konradybcio>
as far as I remember, it's really not that bad
<konradybcio>
even with the CBF clock patch
<bamse>
i tested linux-next/master last week and successfully booted 7 out of 20 times...on that board
Danct12 has quit [Ping timeout: 480 seconds]
<bamse>
so it really seems to not survive when we do the first frequency change on the performance cores
<bamse>
the times it survives that...i haven't seen any problems
<konradybcio>
i wonder if the situation will change once cpr + msm8996-specific-aging-algo happens
<konradybcio>
also iirc the current lmh driver works with 8996, but no guarantees as that's a faint memory
<bamse>
well...when we do cpr, we still start off with "static" voltage scaling and then adjusts from there
<bamse>
so i would expect that under light load we should be fine with just static voltage settings
<bamse>
for which i had some old patches laying around...and just pulling in those didn't seem to change anything
<konradybcio>
booting isn't exactly light load
<bamse>
perhaps true...but we're still quite early
<konradybcio>
don't you have any insider tools to check what happens inside the soc and why does it shut down?
<konradybcio>
for how complex it all is, there should be some way to retrieve how/when it crashes..
<bamse>
maybe
<bamse>
i don't have access to 8996 hardware where i can measure the voltage rails though :/
<konradybcio>
maybe it's trying to set a frequency that's not specified for your SKU of 8996 and clock tree goes crazy
<konradybcio>
that's not really probable, but possible..
<bamse>
well, the opp table doesn't have the frequency that we boot with at least
<konradybcio>
that's something..
<bamse>
becasue i do pass the "i don't know this frequency, picking another one"
<bamse>
and then it goes boom
<konradybcio>
i remember on 8939 the opp tables were one thing and whatever-the-pbl-set was another story
<konradybcio>
adding them made it "work" iirc, but that was a long long time ago
<bamse>
and given that the clocks are driven from Linux it shouldn't really matter
<konradybcio>
speaking of 8939, that's also on my long overdue list of to-upstream..
<bamse>
as long as we can safely switch off that first "invalid" frequency
<bamse>
you have an 8939 with psci?
<konradybcio>
but so is all of the 8994 hardware that's dependent on the seemingly never-to-be-finished 8974 iommu
<konradybcio>
8939 with psci, no
<konradybcio>
i had used a downstream patch from minecrell and it did work
<konradybcio>
(surprise surprise, 8939 is 2 8916s glued together with some changes to make 2 clusters work :P)
<minecrell>
It was a ported version of a patch Qualcomm tried to upstream at some point when they got lots of "you should use PSCI" hate
<bamse>
when i looked at it a long while back i noticed that psci is mentioned in the dtsi, but the firmware doesn't seem to have it enabled
<bamse>
but i also noted that there was some devices out there with psci...
<minecrell>
8939 has pretty much the same firmware as 8916
<bamse>
i just wish they tried to post that patch earlier, so we would have gotten more psci platforms
<minecrell>
bamse: Hm I think they started using it a year after 8916?
<minecrell>
8917/8937 have PSCI iirc
<bamse>
minecrell: i'm lost when it comes to which platform has which features...but it sounds reasonable
<bamse>
well, it seems not only to be individual platforms...but some of the exist with psci and without
<minecrell>
bamse: It's not a massive problem to be honest, since at least it's the same hardware that's already supported for the 32-bit platforms
<bamse>
minecrell: i fancy the platforms that we can run without any out-of-tree patches, but you're right
<bamse>
minecrell: i think the real problems comes when you're trying to go low power...
<minecrell>
bamse: There is still "spin-table". I recently got rid of most of the patches and moved core boot to an extra bootloader. It does some DT magic and now SMP works on mainline without any patches :)
<bamse>
nice
<minecrell>
and a nice side effect of my MSM8916 32-bit patches was that I added MSM8916 to the cpuidle-qcom-spm driver... so cpuidle only needs a 3 line patch to enable compiling it on arm64
<minecrell>
The main limitation is that cpuidle-qcom-spm doesn't do the cluster idle stuff
<bamse>
sc7180 is able to properly reach power collapse, so i hope we can bring that to adjacent platforms...but i haven't looked at all the details for your platforms
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #linux-msm
<minecrell>
The older platforms are probably missing pretty much anything that would be needed for low power stuff :(
<minecrell>
I think the RPM clock driver doesn't have the XO clock at all on msm8916 for example :P
<bamse>
right, but msm8916 at least have db410c, with psci...so that should be fully upstreamable...if someone finds it worth the effort
<minecrell>
bamse: you mean PSCI to reach the cluster idle state?
<bamse>
minecrell: well, yes...but i was thinking more in general terms, that so far i'm not aware of anything that can't go upstream
<minecrell>
bamse: I think PSCI should be only a limitation for 8939 and maybe some 8994... All of them could probably use spin-table as well, although it will certainly be more fun when you have to deal with multiple clusters
<minecrell>
bamse: oh, or you implement PSCI using HVC in the hypervisor :D
<minecrell>
just a matter of effort
<bamse>
:)
<minecrell>
bamse: FWIW, I don't think DB410c's PSCI firmware is really fully functional either. I made a register dump of the SAW/SPM configuration at some point and frankly speaking it looks like a half-baked backport from MSM8917 to me. In particular, the PMIC related registers are all 0 so I don't think it ever turns off the CPU power rail
<minecrell>
So, PSCI or not, it's all somewhat half baked :S
<bamse>
minecrell: and you can imagine that it will be hard to get someone to fix it for us ;)
<minecrell>
bamse: yeah, having to rely on others to provide binary firmware sucks :/
<aka_[m]>
Then steal keys and do it yourself :thinking:
<Mis012[m]>
don't even need to steal the keys
<aka_[m]>
For perma changes?
<Mis012[m]>
sure
<Mis012[m]>
just need to own the device
<Mis012[m]>
"just"
<konradybcio>
Minecrell on 8994 windows psci can only start cores
<konradybcio>
On 8994 sony it doesn't exist
<konradybcio>
On 8992 xiaomi it's also good-ish enough to start cores
<konradybcio>
On 8992/4 huawei/lg (google) it doesn't exist either iirc
<bamse>
konradybcio: so they use psci to start the cores, but then "manual" saw/spm for collapsing?
<konradybcio>
On downstream it's all via the custom enable method
<konradybcio>
PSCI is a byproduct of WP support, as PEP supposedly makes some PSCI calls
<bamse>
speaking of PEP, you don't happen to have some documentation on how to interpret the PEP nodes in dsdt?