ChanServ changed the topic of #linux-msm to:
Danct12 is now known as Guest8981
Danct12 has joined #linux-msm
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
Guest8981 has quit [Remote host closed the connection]
Daanct12 has joined #linux-msm
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #linux-msm
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #linux-msm
Daanct12 has quit [Remote host closed the connection]
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-msm
Daanct12 has joined #linux-msm
pespin has joined #linux-msm
Danct12 has quit [Quit: WeeChat 3.8]
<konradybcio> check the frequency in your downstream gcc driver
<konradybcio> aka_: it's off as far as Linux is concerned, you can't read the actual state from rpm(h), you can only see what Linux thinks it's true
<konradybcio> RPM does provide sleep stats but since you're interacting with the device, it's obviously not asleep
<aka_[m]> konradybcio: thats quite awful
<aka_[m]> would we be able to read it via registers maybe/
<aka_[m]> im still woried a bit about this modem supply shit
<aka_[m]> S1 domain goes into VDD_MODEM_X nowhere else
<konradybcio> no, it's not exposed via mmio at all
<aka_[m]> no idea how is that even wired
<aka_[m]> konradybcio: fug
<aka_[m]> wasnt it like spmi protocol or something?
<aka_[m]> extended i2c-like
<aka_[m]> konradybcio: how valid would be reusing struct in q6v5_mss.c?
<aka_[m]> i wanted to do something like... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/XHoQzJCSsuXEOopgeExuEsnr>)
<aka_[m]> its static const tho
<aka_[m]> you cannot really assign it this way i believe?
<aka_[m]> static const are like you cannot modify these at runtime
<aka_[m]> right?
<aka_[m]> or i can just assign msm8909 data tho
<aka_[m]> prob same core
<aka_[m]> or not it seems
<konradybcio> considering that would allocate an entire struct worth of ram anyway, just do it explicitly
<JIaxyga[m]> <konradybcio> "check the frequency in your..." <- But if I use 202 frequency in dts, I will get an error that 208 cannot be set
Caterpillar has joined #linux-msm
<JIaxyga[m]> I also looked at the sdhc frequency inside the android using a script, then I got exactly 202 frequency
<JIaxyga[m]> Today I will test what will happen if I set the values to 208 for dts. I think it will work, but I wouldn't count on long term stability
<JIaxyga[m]> <konradybcio> "check the frequency in your..." <- 208 in gcc and 202 in dts
<JIaxyga[m]> caf kernel
<JIaxyga[m]> When I ported gcc I didn't change frequencies
<aka_[m]> My limited understanding is that opp core will select closest freq to provided via dts and it will use it's power stage
<aka_[m]> *state
<JIaxyga[m]> konradybcio: I set the frequency to 208 in dts and left 208 in gcc and it doesn't throw any errors
<JIaxyga[m]> But the rate is still set to 201999975
<aka_[m]> Happens with alpha-pll
<aka_[m]> For me when I was dealing with gcc ones I had like 799.999999mhz
<aka_[m]> JIaxyga: you can set it to 202mhz in freq table too
<aka_[m]> And when sending you can explain that this is closest what can you get with these dividers
<konradybcio> what does debugcc say?
<konradybcio> note it will only report frequency when you're actively accessing the emmc
<konradybcio> or sdcard
<aka_[m]> It's not like you set clock to some 0.1mhz value you just set multiply/divide from source freq there is always margin on clocks
<JIaxyga[m]> <konradybcio> "what does debugcc say?" <- Is it enabled by default in downstream?
<konradybcio> hard to tell
<konradybcio> you'll need to port your platform though
pespin has quit [Remote host closed the connection]
<JIaxyga[m]> <konradybcio> "you'll need to port your..." <- so https://github.com/sm7150-mainline/debugcc/commit/6c27ed8aa4a7cf9408f61141faf2d34b2685a60c
<JIaxyga[m]> I think we need to write a generator for this
<aka_[m]> konradybcio: oh lol
<aka_[m]> msm8976 appears to also have "proxy vote" via s1
<aka_[m]> btw
<aka_[m]> i noticed something
<aka_[m]> vdd_pll-supply is nowhere mentioned in our mainline fork
<aka_[m]> we should do pll-supply = <&pm8953_l7> i believe
<aka_[m]> wait, we do it
<aka_[m]> so i wonder, should i add s1 as power domain to 8976?
<aka_[m]> ok weird, on 8953 there is vdd_mss-uV
<aka_[m]> with level defined
<aka_[m]> nothing on 8976 so maybe they don't do "level" votes and might set stuff from driver as regulator
<aka_[m]> binding name not specify if its pd or regulator
<aka_[m]> huh, main difference between s1 on 3.18 vs 4.9 is that min/max volts are numeric values vs votes
<aka_[m]> there is no "level", "floor", "corner"
<aka_[m]> there is flag "qcom,use-voltage-level"
<aka_[m]> i cannot even find this flag in repo xD
<aka_[m]> found,sadly it only assign ops