ChanServ changed the topic of #linux-msm to:
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
jhovold has quit [Quit: WeeChat 3.7.1]
<alfayt[m]> Any update on sm8450 display issue?
jhovold has joined #linux-msm
abhinav__ has quit [Quit: The Lounge - https://thelounge.chat]
lumag has quit [Quit: ZNC 1.8.1 - https://znc.in]
jessica_24 has quit [Quit: The Lounge - https://thelounge.chat]
lumag has joined #linux-msm
abhinav__ has joined #linux-msm
rohiiyer0 has joined #linux-msm
lumag is now known as Guest6554
<aka_[m]> bryanodonoghue: do you remember anything regarding 8939 and power domains?
<aka_[m]> I can recall seeing some mention of MX domain supporting bit higher state than CX and im almost sure thats stuff also happen on 8976
<bryanodonoghue> hrmm doesn't ring a bell
<bryanodonoghue> "Vdd_Mx must be greater than or equal to Vdd_Cx at all times"
<bryanodonoghue> if that helps
<bryanodonoghue> the RPM should enforce that
<bryanodonoghue> I'd see no logical reason to depart from that truism on other SoCs
<aka_[m]> im still thinking on reboot on 8976 when wcnss core vote for max state which now is set to be turbo_hgh
<aka_[m]> Konrad noticed ds only mentions turbo_high in notes for CCI,DDR
<bryanodonoghue> OnePlus One bacon is an 8976 right ?
<bryanodonoghue> Ahh... CCI
<konradybcio> bryanodonoghue: does the "MX >= CX" hold for 8939 or all SMD RPM socs?
<aka_[m]> konradybcio: tho in cpu code there is no turbo_high macro
<konradybcio> if the latter, we should enforce it in the rpmpd driver
<bryanodonoghue> You need CPR
<z3ntu> OnePlus One (bacon) is msm8974
<aka_[m]> i had some feeling of cpr also using these voltage levels
<aka_[m]> so it could be used on cpr controlled apcX regulator and not on rpmpd one
<bryanodonoghue> Yeah but if you are ramping the CCI frequency
<bryanodonoghue> without upping the voltage
<bryanodonoghue> likely your root-cause
<bryanodonoghue> konradybcio IDK
<aka_[m]> not exactly sure what's all this about but mine issue is if rpmpd have turbo_high defined like now, and wcnss code starts bumping all domains to current max state it reboot
<bryanodonoghue> But I guess it should hold
<aka_[m]> if i drop it to turbo its fine
<bryanodonoghue> Not sure how easy an experiment it would be for you to run
<aka_[m]> i had some idea that CX cannot be voted for turbo_high
<bryanodonoghue> but set the CCI CPR voltage to max
<aka_[m]> but MX could
<bryanodonoghue> and then mess with the rpm*
<aka_[m]> CCI CPR reffers to main supply for block?
<aka_[m]> it appears to be shared with APC0
<bryanodonoghue> so... turbo_high is defined for 8976 wcnss downstream ?
<bryanodonoghue> or you are trying to set ?
<aka_[m]> bryanodonoghue: ds is capping states for wcnss and any remoteproc to turbo
<bryanodonoghue> Sorry mentioning the CCI just sets me off - because on 8939 the AP needs to do the voltage ramping not the RPM
<aka_[m]> i cannot find any binding with RPM_SMD_LEVEL_TURBO_HIGH
<bryanodonoghue> Soo...
<bryanodonoghue> I'd say its not supported
<aka_[m]> only CCI devfreq have some lack of notes in freqtables
<aka_[m]> or notes like < 614400 >; /* STURBO */
<aka_[m]> bryanodonoghue: i would just send commit decreasing max state but don't want then have others yell at me because it somehow happens MX does support that
<aka_[m]> so i had idea of changing wcnss code and just trying setting turbo_high on MX only and noticing if it will crash
<bryanodonoghue> as i read the dtsi
<bryanodonoghue> only turbo is supported
<bryanodonoghue> interesting name there "BINNING"
<aka_[m]> its like 4xx
<bryanodonoghue> does it imply binning as in process node compensation ?
<aka_[m]> bryanodonoghue: it appears maybe these state can be different per regulator
<aka_[m]> binning is only on s6_level
<aka_[m]> s6 is MX
<aka_[m]> s2 is CX
<aka_[m]> qcom,wcnss-wlan have table for both
<aka_[m]> turbo_high is mentioned in mx-thermal node or something
<aka_[m]> or not
<aka_[m]> here you ho
<aka_[m]> *go