ChanServ changed the topic of #msm8937-mainline to: Boot Linux on your MSM8917/37/40 and QM215 mobile! | GitHub: https://github.com/msm89x7-mainline | Logs: https://oftc.irclog.whitequark.org/msm8937-mainline | Bridged to #msm8937-mainline:kde.org on Matrix
fossdd has quit [Remote host closed the connection]
fossdd has joined #msm8937-mainline
<hacker420[m]> barni2000 which defconfig do I pick?
<barni2000[m]> my config based on msm8917 config from the pmaports but i can send my config
<barni2000[m]> i have not created a config fragment or a clean defconfig yet
<hacker420[m]> barni2000[m]: sure
<hacker420[m]> btw, charging on G5 seems to be wired to pmi8952
<barni2000[m]> pmi8952 is pmi8950
<hacker420[m]> battery as well
<barni2000[m]> for normal charging most msm8937 devices are using pmi8950_charger (pmic charger) and for fast charging they are using other smb charging chip
<barni2000[m]> so in general 2 charging chip is there
<hacker420[m]> yeah I am not interested in fast charge for now
<barni2000[m]> i have sent example from kenzo you can use that, i can help with the values
<hacker420[m]> especially seeing that I can't see that chip in schematics
<barni2000[m]> it seems cedric does not support fastcharge
<hacker420[m]> barni2000[m]: hmmm
<hacker420[m]> I remember it was advertising some quickcharge thing
<hacker420[m]> doesn't matter
<hacker420[m]> where is the kenzo example?
<barni2000[m]> you can search in chat history btw
<hacker420[m]> barni2000[m]: blame neochat for search being broken
<barni2000[m]> sad
<hacker420[m]> I assume I also need this
<hacker420[m]> so now how do I adapt these values?
<barni2000[m]> in recovery ```cat /sys/class/power_supply/.../*
<barni2000[m]> s//.../*//.../*```/
<barni2000[m]> <hacker420[m]> "https://github.com/MotorolaMobil..."; <- not really
<hacker420[m]> so this for example on battery?
<barni2000[m]> you will need full_design
<hacker420[m]> it's the same
<barni2000[m]> there are charger and bms under the power_supply
<hacker420[m]> ~ # cat /sys/class/power_supply/battery/voltage_max_design
<hacker420[m]> 4400000
<barni2000[m]> so you have the charge_full_design and voltage_design what is left?
<hacker420[m]> under bms
<hacker420[m]> ~ # cat /sys/class/power_supply/bms/voltage_min
<hacker420[m]> 0
<barni2000[m]> does not really matter
<hacker420[m]> so do I just chuck out voltage-min from dts?
<barni2000[m]> i always use 3.4v for 4.4v max
<hacker420[m]> here's what I have for now
<barni2000[m]> it seems fine you can set constant-charge-current-max lower to be more safe
<barni2000[m]> in my example it is 1A
<hacker420[m]> `constant-charge-current-max-microamp = <1000000>;`
<barni2000[m]> double check everything 0 + can mess up everything
<hacker420[m]> any changes in fg or smbcharger?
<barni2000[m]> * check everything one 0 +
<barni2000[m]> no just copy them
<hacker420[m]> looks good then
<hacker420[m]> anything else?
<barni2000[m]> have you cherry-picked the driver commits?
<hacker420[m]> which driver commits?
<barni2000[m]> fg and charger
<hacker420[m]> I grabbed your branch
<barni2000[m]> my branch does not contains pmi8959 charger/fg drivers yet
<barni2000[m]> s/pmi8959/pmi8950/
<hacker420[m]> ah
<barni2000[m]> from resin to kenzo dt
<hacker420[m]> do I grab all those?
<barni2000[m]> yes
<hacker420[m]> wait how do I pick them from a different fork
<barni2000[m]> you can add a new remote any time
<hacker420[m]> right
<hacker420[m]> but will this stupid ass internet let me fetch it
<hacker420[m]> I couldn't fully clone the git repo
<hacker420[m]> kept giving me errors
<hacker420[m]> unless there is some way for me to make them all into a patch
<hacker420[m]> ok idea
<hacker420[m]> I'll just grab the patches from all of them for now
<hacker420[m]> do I enable something else?
<hacker420[m]> ` │ │ <M> Qualcomm Switch-Mode Battery Charger │ │ `
<barni2000[m]> it is not that
<hacker420[m]> which one is it then?
<barni2000[m]> when you start make it will prompt the new drivers
<barni2000[m]> CHARGER_QCOM_SMBCHG but this is it
<hacker420[m]> barni2000[m]: that's the one I enabled
<hacker420[m]> also make didn't prompt anything
<barni2000[m]> i was not remembered correctly
<hacker420[m]> guess I just wait until this builds then enable it
<hacker420[m]> because didn't on this run
<hacker420[m]> do I set it as module or built in
<barni2000[m]> module is fine
<barni2000[m]> don't forget enable fg also
<hacker420[m]> ` │ │ <M> Qualcomm PMIC fuel gauge driver │ │ `
<hacker420[m]> do I need to modprobe them after startup?
<hacker420[m]> if I didn't put them in initfs
<hacker420[m]> wait no it's there
<hacker420[m]> why does phosh report 0 on the battery then
<hacker420[m]> oh I see
<hacker420[m]> [ 14.182092] genirq: Flags mismatch irq 23. 00002003 (usbin-src-det) vs. 00002003 (200f000.spmi:pmic@2:usb-detect@1300)
<hacker420[m]> [ 14.182157] qcom-smbchg 200f000.spmi:pmic@2:smbchager@1000: failed to request usbin-src-det IRQ: 0000000091861ea8
<hacker420[m]> [ 14.182174] qcom-smbchg 200f000.spmi:pmic@2:smbchager@1000: probe with driver qcom-smbchg failed with error -16
<hacker420[m]> so what to do with this
<hacker420[m]> did I miss something in dts?
<hacker420[m]> or is it a missing commit
<barni2000[m]> it is collision between the two usb-id
<hacker420[m]> weird
<hacker420[m]> I reverted it, rebuilt kernel, sideloaded the new kernel package and I still get the same error
<hacker420[m]> everything appears to have reverted fine
<barni2000[m]> ok then replace extcon with charger one and remove pmi8950_vbus
<barni2000[m]> ```extcon = <&pmi8950_smbcharger>;```
<hacker420[m]> removed vbus too
<barni2000[m]> and disable pmi8950_vbus
<barni2000[m]> i hope it is disabled ind pmi8950.dtsi
<hacker420[m]> disable or can I remove it entirely
<barni2000[m]> s/ind/in/
<hacker420[m]> add status disabled to this?
<barni2000[m]> yes
<hacker420[m]> still fails and now I have no usb
<barni2000[m]> wait try to disable the usb-id one
<hacker420[m]> reenable the vbus?
<barni2000[m]> not needed yet
<hacker420[m]> so have both disabled
<hacker420[m]> any dts changes?
<barni2000[m]> hacker420[m]: yes
<barni2000[m]> hacker420[m]: thats all
<hacker420[m]> now it sees the battery
<hacker420[m]> and knows that it's charging
<hacker420[m]> have to verify the level with twrp though
<hacker420[m]> looks to be valid
<hacker420[m]> twrp says 94%
<hacker420[m]> phosh said 95%
<hacker420[m]> ok it's valid now
<hacker420[m]> phosh says 94% too
<hacker420[m]> there was some app to see charging parameters
<hacker420[m]> but the name escapes me atm
<hacker420[m]> funnily enough this has less glitches than my j5 2016
<hacker420[m]> hm usb seems broken though
<barni2000[m]> you can use dummy-extcon then
<barni2000[m]> check riva or ugglite
<hacker420[m]> is this fine?
<hacker420[m]> ah wait I think the closing brackets are in the wrong place
<barni2000[m]> why you put it in the regulator config?
<barni2000[m]> it should be in the / block
<hacker420[m]> that's where it is on riva
<hacker420[m]> aj
<hacker420[m]> *ah
<barni2000[m]> idk why it is there maybe i have do some wrong cut/paste
<hacker420[m]> still nothing
<hacker420[m]> even in the right block
<barni2000[m]> ```extcon = <&pmi8950_smbcharger>;```
<barni2000[m]> replace the extcon
<hacker420[m]> ahhh
<hacker420[m]> to usb_vbus?
<hacker420[m]> btw does venus work?
<hacker420[m]> hacker420[m]: yeah works now
<barni2000[m]> i have updated riva's dt
<hacker420[m]> battery looks to be charging fine
<hacker420[m]> so I'll probably wait for you to merge in all the changes before I send my dts
<hacker420[m]> wait
<hacker420[m]> why does everything on the branch suddenly have 11 minutes ago commits
<barni2000[m]> because i have force pushed
<hacker420[m]> ah
<hacker420[m]> btw what would I need to do to try enabling OTG
<hacker420[m]> if that is even possible in the current state
<barni2000[m]> it depends from the device
<barni2000[m]> as far as i know motorolas using external direction detect
<barni2000[m]> charger is there for vbus supply
<barni2000[m]> but that also could be different
<barni2000[m]> qcom,usbid-gpio = <0xa7 0x61 0x00>;
<barni2000[m]> snps-femto-phy driver should be modfied to handle the init-seqs
<barni2000[m]> you will need gpio-extcon
<barni2000[m]> linux,extcon-usb-gpio
<barni2000[m]> CONFIG_EXTCON_USB_GPIO
<hacker420[m]> ok the hell
<hacker420[m]> so was benchmarking the phone with unixbench
<hacker420[m]> it randomly died and popped up the low power message from the bootloader
<hacker420[m]> I boot into BL and it says battery charge OK
<hacker420[m]> I boot into TWRP next and it shows 25% charge
<hacker420[m]> is the battery that badly degraded or what
<hacker420[m]> phosh iirc showed around 40-50%
<hacker420[m]> this phone isn't new so I can't count battery degradation out
<hacker420[m]> and it seems to benchmark fine under power
<hacker420[m]> so yeah it does really seem like degradation
<hacker420[m]> also lol
<hacker420[m]> unixbench results are better on mainline
<hacker420[m]> plasma mobile runs decently as well on here
<hacker420[m]> <barni2000[m]> "snps-femto-phy driver should..." <- you sure?
<hacker420[m]> in other dtses I just see it defined right in the device's dts
<hacker420[m]> unless you mean it's a different format or something
<barni2000[m]> hacker420[m]: yes 28nm-snp-femto-phy does not supports custom init seqs
<barni2000[m]> it is hardcoded
<hacker420[m]> ah
<hacker420[m]> barni2000[m]: guess for convenient testing?
<hacker420[m]> yeah I see it's hardcoded
<barni2000[m]> i can do some thing similar what is in the msm8916 driver
jojo_autoboy[m] has joined #msm8937-mainline
<jojo_autoboy[m]> <hacker420[m]> "unixbench results are better..." <- huh?