<bryanodonoghue>
you're entirely right about sensors
<bryanodonoghue>
I forgot to cc you on that series
<minecrell>
argh
<bryanodonoghue>
not to worry - its just software ;)
<konradybcio>
8939 seems like a matryoshka, except every doll is a can of worms..
<bryanodonoghue>
heh - don't look at the LPM
<minecrell>
bryanodonoghue: Are you going to post something for 8939 cpuidle in the near future (I guess either patches for cpuidle-qcom-spm or a magic PSCI firmware) or will you just continue using the ported downstream logic?
<bryanodonoghue>
If there was a chance of getting the LPM stuff in - yes
<bryanodonoghue>
But
<bryanodonoghue>
I think our collective conclusion is - its not going to happen
<bryanodonoghue>
I think CPR is the realistic extent of the upstream effort
<bryanodonoghue>
venus, camera, wifi, display, battery and out-of-tree LPM
<minecrell>
The cpuidle-qcom-spm code should be 95% identical to ARM32, so I think it should be possible to get that in at least. Once that happens (at this point probably more of a "if ever") the ~10 line diff to enable this on ARM64 could be discussed again or just kept out of tree
<konradybcio>
can you not get it in "for arm32 usecases" and then carry a downstream patch just to enable a64 compilation?
<minecrell>
which is still a big difference to completely out of tree
<minecrell>
konradybcio: yeah exactly
<bryanodonoghue>
we can have a go
<bryanodonoghue>
why not
<minecrell>
but first someone needs to do the changes for cluster spm idle (+ for 8939: cci spm idle) in cpuidle-qcom-spm
<minecrell>
I think it *should* be mostly copy paste from cpuidle-psci-domain but not sure
<konradybcio>
Bjorn will get a stroke reading this, but.. this cpuidle driver would also be nice for 8994..
<minecrell>
Fundamentally it should be equivalent to PSCI hierarchical power domains / operating system initiated (OSI) mode, just that you don't do a PSCI call but configure the SPM and then do the qcom-specific SCM call
* minecrell
should try to find some time to hack a quick proof of concept for that
<minecrell>
well, time it always too short :D
<aka_[m]>
which socs would benefit from that?
<aka_[m]>
I guess this thing is used up to "modern day" socs like 660?
<aka_[m]>
<konradybcio> "aka_: dont hesitate to send to..." <- i know its more beneficial from your point of view
<bryanodonoghue>
I thought qcom implemented PSCI sometime after the 8916/8976 series
<aka_[m]>
i can boot cores with psci on 8976
<bryanodonoghue>
and backported PSCI to 8916 for db410c
<aka_[m]>
not sure how is low power mode achieved tho
<Tooniis[m]>
bryanodonoghue: their psci impl is not fully up to spec i guess
<minecrell>
bryanodonoghue: The PSCI backport for db410c seems incomplete so I think even on db410c one might eventually want the non-PSCI way for full LPM
<alexeymin>
If I submitted dts with GPL-2-only license in the past, and it was accepted upstream, can I (or should I) change it to BSD-3 like others? What's policy on this?
<minecrell>
bryanodonoghue: I'm confused where you're getting these bits in the cover letter from, where do you see bit 13 downstream?
<minecrell>
or is that just an example?
<minecrell>
ah the old mainline code
<minecrell>
#define MSM8939_S9_P2_SHIFT_513
pespin has quit [Remote host closed the connection]
<konradybcio>
djakov: btw could you please confirm with qcom folks whether this non-volatility applies to all generations of msmbus (e.g. 8974, 8994, 8998, 8550)?
animist1 is now known as animist
<djakov>
konradybcio: applies to all rpmh based for sure. also for most rpm based. there might be a few exceptions where they had to do some workaround or something...
<konradybcio>
djakov: any chance we can get a list of these "exceptional" (heh) ones?