ChanServ changed the topic of #linux-msm to:
anholt has joined #linux-msm
Danct12 has joined #linux-msm
Danct12 has quit []
Danct12 has joined #linux-msm
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
<aka_[m]> lumag: so I should get someone to test
<aka_[m]> Msm8953 still my main device.
<lumag> aka_[m], gentle reminder regarding a510 patch ;-)
<aka_[m]> In job now
<aka_[m]> 2h left
<lumag> aka_[m], excuse me then
alexeymin_ has quit [Remote host closed the connection]
alexeymin has joined #linux-msm
<aka_[m]> lumag: so i have something like this:... (full message at <>)
<lumag> aka_[m], just move the declaration to the top of the function close to the rest of variable declarations, if there are any
<aka_[m]> minute
<aka_[m]> lumag
<lumag> aka_[m], yes, why not
<lumag> And your signed-off-by at the end of the commit message
<aka_[m]> ok, will send tomorrow, on this recent install of linux i haven't setup git-send-mail yet
<aka_[m]> i will generate patch with -s like always
<aka_[m]> and second install is on HDD and it takes like 20minutes to boot to end, 9y old drive at the end.
<lumag> aka_[m], ugh :-(
<flamingradian[m]> konradybcio: regarding sdm670 icc consumers, can I just send the same patch with a different message?
<flamingradian[m]> or do I have to split it
anholt has quit [Quit: Leaving]
anholt has joined #linux-msm