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]
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-msm
pevik_ has joined #linux-msm
pevik__ has joined #linux-msm
Danct12 has quit [Ping timeout: 480 seconds]
Danct12 has joined #linux-msm
Danct12 has quit [Remote host closed the connection]
<narmstrong> Marijn[m]: I'm testing your INTF TE changes, I'm a total noob in CMD mode, but I have something on the screen only when DRM does a vblank update, then screen goes black
<narmstrong> Marijn[m]: so this means the TE event doesn't go through ?
<narmstrong> well not really, I only have something persistent when I run `modetest -r` otherwise the kernel fbcon only flashes when drm does vblank updates
<narmstrong> but in this case instead of a full smpte I only have the gray & blue colours :/
<z3ntu> Anyone know about the BAT_THERM vadc? My downstream kernel uses ADC5_BAT_THERM_30K_PU (downstream: ADC_BAT_THERM_PU1) but with a custom lookup table that (from what I can tell) corresponds to the thermistor behavior (=NTC) that is found in the battery pack itself so that it can correctly map voltage from vadc to temperature. Currently there's already some of these lookup tables hardcoded in qcom-vadc-common.c but it feels quite wrong to have it
<z3ntu> there, since it's not SoC-specific and here not even really board-specific but could change depending on which battery pack you use.
<z3ntu> This NTC in the battery pack is also 10kOhm so not even 30k as per the name, which is why I guess the values are now different compared to Qualcomm baseline
<z3ntu> I think to be correct the kernel would need to find correct battery definition in dts (based on ID pin because there could be multiple for a given device), grab this lookup table from there and only then it could correctly read the BATT_THERM vadc with that lookup table
Daanct12 has quit [Remote host closed the connection]
<aka_[m]> bryanodonoghue: don't you have issues with wifi while having BT enabled on 8939?
<aka_[m]> well, it doesnt even work well with bt disabled, 3 timed out auths and then SMD_EVENT (312) not supported
<aka_[m]> and device locking probably WDT kicking in
<aka_[m]> cuz i see flashed red led for few times
<aka_[m]> hmmm
<aka_[m]> is SMD_EVENT here in %d?
<aka_[m]> ok appears its %d in log
<aka_[m]> 312 in decimal converts to 0x138 in hex and appears to be unsupported WCN36XX_HAL_P2P_NOA_ATTR_IND
<aka_[m]> is that possible?
<aka_[m]> as i package WCNSS_qcom_cfg.ini i wonder, is it even needed/
<minecrell> aka_[m]: no, you just need the _nv.bin
<aka_[m]> WCNSS_qcom_wlan_nv.bin
<aka_[m]> so i might drop stuff from fw packages
<aka_[m]> still sad it keeps getting worse with newer kernels
<aka_[m]> no idea how this stuff works and wanted to just grab unixbench for testing and decided to enable wifi to see it derping on me >_>
<minecrell> aka_[m]: what is getting worse?
<aka_[m]> minecrell: wcn on 8976 doesnt like power saving commits
<aka_[m]> it crash
<minecrell> weird
<aka_[m]> after reverting it allow me to see networks but with BT on it keeps trying to connect and error
<aka_[m]> optional reboot thanks to wdt, ofc no msg from remoteproc core
<aka_[m]> sometimes ti just say "detected crash"
<aka_[m]> well, it does this before i revert power saving commit
<aka_[m]> yes, i added pronto v3 commit
<aka_[m]> eh, even more issues now on 6.1_rc7, pretty often some timming calc returns -22 for dsi_phy and it hangs
<aka_[m]> on 662 i get quite a lot of failed to lock pll for like minute during boot and after some time it manage to work
<aka_[m]> weird, it appears it really wants to use IPv6 to connect to AP
pevik__ has quit [Ping timeout: 480 seconds]
pevik_ has quit [Ping timeout: 480 seconds]
<bryanodonoghue> aka_[m] I noticed recently on linux-next that WiFi is pretty broken
<bryanodonoghue> so its not just you
<bryanodonoghue> I'm not sure where the regression was intorduced
<bryanodonoghue> I just rebased to linux-next this evening
<bryanodonoghue> I haven't checked stable since before christmas
<bryanodonoghue> I did use it on 8916 yesterday for another reason on linux-next and it "just worked"
<bryanodonoghue> I'm in the process of messing with the 8939 core dtsi so if you happened to have picked up anything I published to consider it potentially not working
<bryanodonoghue> let's have a quick look at today's -next...