ChanServ changed the topic of #linux-msm to:
Danct12 has joined #linux-msm
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
Daaanct12 has joined #linux-msm
Danct12 has quit [Read error: Connection reset by peer]
<vkoul> Mis012[m]: yes i have the message, was busy with other things, bridge seems to work well...
Daaanct12 has quit [Read error: Connection reset by peer]
Danct12 has joined #linux-msm
cxl000 has quit [Quit: Leaving]
jhovold has joined #linux-msm
pespin has joined #linux-msm
cxl000 has joined #linux-msm
Danct12 has quit [Ping timeout: 480 seconds]
Danct12 has joined #linux-msm
Danct12 has quit [Remote host closed the connection]
<Tooniis[m]> is there a way to reboot a remoteproc?
<konradybcio> you can shut it down and power it up from sysfs
<Tooniis[m]> which file exactly?
<z3ntu> `echo stop > /sys/class/remoteproc/remoteprocN/state` and `echo start > /sys/class/remoteproc/remoteprocN/state` Some remoteprocs/driver don't really like it though so it might not work properly
<Tooniis[m]> well looks like mine is one of them
<Tooniis[m]> because the device reboots when i try to start the remoteproc again
<z3ntu> if you want to start it the first time later either make the remoteproc a kernel module, or set auto_boot to false in driver code
<z3ntu> or remove firmware before rebooting :D
Daanct12 is now known as Danct12
<calebccff> Mis012[m]: I hooked up to the SSC UART on the op6 and it didn't do anything, although I only tested it on mainline so SSC would be idle anyway
<Mis012[m]> calebccff: well, the debug one is presumably for debugging, like with Linux...
<Mis012[m]> I rather wonder what the one that goes to wcn3990 does
<Mis012[m]> it seems it's not a thing on 8998, at lest not on fxtec
<Mis012[m]> and 8998 SSC fw doesn't seem to mention it
<Mis012[m]> *at least
<konradybcio> wifi uart is probably for debug
<Mis012[m]> what kind
<Mis012[m]> and why it it hooked up to SSC UART
<konradybcio> to not let you snoop at super duper secure secret proprietary and unimaginable debug logs of qualcomm(tm) incorporated
<konradybcio> * qualcomm is a a trademark of QUALCOMM INC and it's subsidiaries
<Mis012[m]> konradybcio: tbh my best guess was some IZAT fuckery
<Mis012[m]> but that would be on the modem
<Mis012[m]> and the modem already conveniently hosts the atheros fw
dliviu has quit []
<calebccff> Mis012[m] any chance you could give wowlan a go? ath10k_snoc "should" support it but didn't wake up properly for me, the wakeirq is configured
<calebccff> it can wakeup on wifi disconnect, or when certain TCP data is recieved, neat stuff
<calebccff> if using networkmanager you need to disable it's power management stuff otherwise it turns off wifi when going into suspend
dliviu has joined #linux-msm
<Mis012[m]> calebccff: currently I'm trying to think of a way to charge my battery
<Mis012[m]> since it's so low that I need to use u-boot because eewEFI thinks there is no battery and dies
<Mis012[m]> and since mainline needed workarounds with lack of eewEFI hacks, I assume downstream would need them too
<calebccff> it doesn't charge in linux?
<Mis012[m]> mainline doesn't have smb1380 charging driver
<konradybcio> unless you overdischarged it, it should trickle charge
<Mis012[m]> by default hw settings?
<konradybcio> no idea
<calebccff> 845 devices with smb1355 (i think?) charge at full speed without a driver for it
<Mis012[m]> or by default eewEFI setting
<calebccff> and smb2 driver lets us do 1.5A+
<Mis012[m]> even without eewEFI?
<Mis012[m]> konradybcio: I mean, I definitely overdischarged it in some sense of that word
<konradybcio> the pmic charger has some threshold for how low it can go
<Mis012[m]> in hw?
<konradybcio> no, voltage is a software construct /s
<Mis012[m]> well, I had u-boot running with Linux rebooting because of reasons
<Mis012[m]> and it did that in a loop
<Mis012[m]> until ded
<Mis012[m]> since I went on vacation and didn't turn it off properly
pespin has quit [Ping timeout: 480 seconds]
pespin has joined #linux-msm
<Mis012[m]> konradybcio: also, rndis doesn't want to do dhcp when inside mainline, which makes me wonder if it just dies from lack of current provided by the laptop usb port before getting to that part
<Mis012[m]> fwiw switching between ports didn't make it stop appearing as a rndis device
Danct12 has quit [Remote host closed the connection]
<Mis012[m]> so I assume it took current from battery to stay in that low power crashed state?
<aka_[m]> how to get data for dsi_phy_14nm.c?... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/dmZylRVNRsUwBvipHMsFePHD)
<aka_[m]> its much different compared to sdm660/msm8953
Danct12 has joined #linux-msm
<konradybcio> check what's `vdda-supply` and if it's a votable regulator, i guess just drop it as they are modeled as PDs on mainline
<aka_[m]> MX domain
<aka_[m]> so
<aka_[m]> can i just ignore .reg_cfg?
<konradybcio> iirc there's a var like has_phy_regulator
<konradybcio> set it to false and
<konradybcio> and just don't configure the "regulators"
<aka_[m]> right
<Mis012[m]> konradybcio: considering they are backed by regulators, why not mske a reulator-backed-pd driver
<Mis012[m]> *make
<Mis012[m]> *regulator
<konradybcio> qc just modeled the PDs as regulators so that they didn't have to add genpd APIs into their drivers
<Mis012[m]> except the power domains are a construct backed by hardware regulators iirc
<aka_[m]> konradybcio: pretty much:... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/xgINUPCcRvLmhOeyftQYFboi)
<konradybcio> looks good i think
<konradybcio> has_phy_regulator is false by default, but i guess it makes sense for it to be explicit as this is a snowflake
jhovold has quit [Ping timeout: 480 seconds]
pespin has quit [Remote host closed the connection]
djakov_ has joined #linux-msm
djakov has quit [Ping timeout: 480 seconds]