Danct12 has quit [Read error: Connection reset by peer]
Danct12 has joined #linux-msm
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
Danct12 has quit [Quit: WeeChat 3.8]
Danct12 has joined #linux-msm
pespin has joined #linux-msm
Danct12 has quit [Ping timeout: 480 seconds]
<aka_[m]>
konradybcio: any idea if rpm firmware on 8976 will respond to setting state of regulator which was not defined as rpmpd on downstream?
<aka_[m]>
On 8953 3.18 model mss supply as regulator and 4.9 as rpmpd
<aka_[m]>
I was thinking if I can just add first smpa as rpmpd on 8976 and then just reuse 8953 conf
<aka_[m]>
Back in time I had modem up from what i remember with added s1 to rpmpd
<aka_[m]>
Or I just mod bindings to allow 2 pd
<lumag>
aka_[m], 2 pd is harder because you have to bind both of them manually
<aka_[m]>
lumag: q6v5_mss.c have attach function for domains
<lumag>
aka_[m], good then
<aka_[m]>
Now I wonder how it's going to deal with mss domain
<aka_[m]>
For 8953 mss domain was added
<aka_[m]>
It's smpa1 regulator
<aka_[m]>
Which state it goes to vote on it?
<aka_[m]>
It can also be attached via pll-supply which sets 1v on it
<aka_[m]>
I should probably just give it a spin and check /sys/kernel/debug
<lumag>
aka_[m], I'd probably ask Vladimir Lypak. He added md domain, however I don't see it downstream.
<lumag>
Unlike VDD_CX, VDD_MX, etc. it is registered only as a voltage regulator. And then the pill-q6v5-mss sets it to 1V (well, between 1V and 1.15V).
<minecrell>
the main question is if this was combined with a rpm firmware update to make that work
<minecrell>
or if it works with all rpm firmware versions for 8953
<lumag>
I see. Good question
<lumag>
What was the main customer kernel for 8953? 3.18 or 4.9?
<minecrell>
lumag: Both I think, iirc 8953 itself used 3.18 but sdm632 exists only in 4.9 and is a minor subvariant of it with different CPU cores
<minecrell>
but iirc someone tested the mss patch on a real 8953 and said that it works
<minecrell>
which doesn't necessarily say that the voltage was set correctly but maybe it's good enough
<lumag>
Judging from 4.9, the kernel sets the TURBO level, then drops it once modem comes from reset
<lumag>
so it is a typical proxy vote
Guest7507 has quit []
Daanct12 has joined #linux-msm
Daanct12 is now known as Danct12
pespin has quit [Remote host closed the connection]
<aka_[m]>
So far we don't really die on 8953 with MD because we setup s1 in rpm regulators anyway
<aka_[m]>
No idea what would happen if we don't
<aka_[m]>
lumag: issue is, you know Vladimir is Ukrainian and he had already episodes of deleting accounts and hiding on some alts, so I guess it's not that easy to ask.
<aka_[m]>
You know what's going on in Ukraine
<lumag>
aka_[m], yes :-(
<aka_[m]>
minecrell: I could try deleting smpa1 node and leaving domain alone
<aka_[m]>
Then read voltage statistics from registers
<lumag>
that would be a good test
<lumag>
konradybcio, might argue that it might be the voltage being set by the bootloader beforehand
<aka_[m]>
lumag: but what kind of state would mainline vote for on that
<aka_[m]>
That would be valid point tho
<aka_[m]>
Depends how many subsystems s1 supply
<aka_[m]>
I would have to look schmeatics
<aka_[m]>
There was some doc for pm8953 with table sayinh which regulators are on from bl
<aka_[m]>
Or I remember seeing such
<lumag>
aka_[m], it votes for 'INT_MAX', which means maximum supported state = TURBO
<lumag>
See q6v5_mba_load() -> q6v5_pds_enable()
<aka_[m]>
lumag: ok from pm8953 specification s1 is disabled by default
<aka_[m]>
0.87v default
<lumag>
So, if it works with the power domain voting, you know that it works correctly
<aka_[m]>
Range for 8953 .0.4-1.14
<aka_[m]>
Programmable range 0.32-2.04
<aka_[m]>
This shit sheet appears to have quite valuable info