15:47 <travmurav[m]> Could anyone who has access to qrb5165-rb5 confirm that the microphone (connected to va macro) works on it? I'm struggling to enable the same setup on sc7180 as I see adsp crash, would be nice to confirm it's not just broken

18:29 <aka_[m]> Any idea if we can read state of rpmpd power domain?

18:40 <konradybcio> no

18:41 <konradybcio> well, on 8974 the rpm apparently exposes it

18:49 <aka_[m]> <konradybcio> "no" <- somehow it shows value in mv

18:49 <aka_[m]> in debug/regulator

18:49 <aka_[m]> i wanted to test if rpm firmware will respond to setting smpa1

18:49 <aka_[m]> with level

18:50 <lumag> aka_[m], are you sure that you are reading rpmpd status, not SPMI regulator status?

18:50 <aka_[m]> lumag: i read spmi status for sure

18:50 <aka_[m]> for regulator exposed by rpmpd

18:51 <lumag> aka_[m], so it's the state of the regulator, not rpmpd domain

18:52 <aka_[m]> if we assume regulator is "real" hardware and rpmpd domain is "software" construct then reading state of base regulator would lend us with potential state of "domain"

18:52 <aka_[m]> ?

18:53 <lumag> up to some point. You still don't know what is the assumed 'level' of that domain

18:53 <aka_[m]> well

18:54 <aka_[m]> i seen some data so i can assume "level" correspond to some V value

18:55 <aka_[m]> might also be possible A draw if it can be reconfigured

19:23 <konradybcio> yes reading back spmi should do it

19:23 <konradybcio> though understandably you need some sort of a map

19:27 <aka_[m]> konradybcio: i want to put s1 as modem domain into rpmpd like its on 8953

19:27 <aka_[m]> and want to test if it enables it

19:28 <aka_[m]> but spmi has no status info for regulator

19:28 <aka_[m]> only supply map is shown and number of uses

19:31 <aka_[m]> regulator use open bypass opmode voltage current min max

19:31 <aka_[m]> ---------------------------------------------------------------------------------------

19:31 <aka_[m]> s1 0 0 0 fast 1050mV 0mA 0mV 0mV

19:34 <konradybcio> is s1 something like vdd_mss?

19:37 <aka_[m]> yes

19:37 <aka_[m]> exactly

19:37 <calebccff> lumag: to clarify about the panel stuff, just doing the reset results in a black screen on my device with a replacement panel. I need to either power cycle all 3 power supplies or skip prepare() entirelly for it to work proeprly

19:37 <aka_[m]> konradybcio: wanted to reuse 8953 and do fallback in yaml

19:39 <calebccff> lumag: analysing downstream, I'm certain that's the behaviour being done there. on boot it uses continuous splash (so panel init is skipped), then on suspend (if you aren't using AOD) the main power supply will get switched off and the panel switches to the "sleep" pinctrl which will cause the other two GPIO configured rails to switch off

19:39 <aka_[m]> konradybcio: where is s1 even connected?

19:39 <calebccff> so probably whoever designed the cheap replacement panel validated it with this, and while the original panel can properly reset itself just from the GPIO reset, the crappy replacement one cannot

20:01 <konradybcio> well if it doesn't work the modem wont start

20:02 <lumag> travmurav[m], I got boards reset on RB5 with the latest Linus's tree + clk_stop_mode1 patch

20:02 <lumag> I'll ping Srini

20:09 <aka_[m]> <konradybcio> "well if it doesn't work the..." <- so best way to test would be to take s1 away and try to boot modem

20:09 <konradybcio> yes