ChanServ changed the topic of #linux-msm to:
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
pespin has joined #linux-msm
<aka_[m]> konradybcio: what are these "shared" rcgs?
<konradybcio> aka_: commit 7ef6f11887bd3676fc64517ca685f613d7f230ef
<aka_[m]> konradybcio damn, being so dumb hurts, i get 50/50 there
<aka_[m]> i just get that there is some main rcg and it can have rcgs(child mux/divs) and there is possibility that one of these childs might be controlled by TZ lets say?
<konradybcio> yes that's the whole point
<aka_[m]> then tz could control main rcg?
<konradybcio> On ds it's called safe config
<aka_[m]> konradybcio: oh shit i was trying to figure harder when porting 8953 to 4.19
<aka_[m]> i noticed this flag was translated to that once adding dispcc for 6115
<aka_[m]> i wonder, on 3.18 there is no such flag
<aka_[m]> any idea if they do it in different way?
<aka_[m]> msm8937 also had no such flags on 3.18/4.9 but 4.19 sdm439 gcc does have it
<konradybcio> no clue, i've been free of <msm-4.x for some time..
<aka_[m]> Heh
<aka_[m]> konradybcio: for patches can i base on qcom/linux.git instead of waiting for next to be updated?
<konradybcio> if it only touches things that are covered by qcom/linux.git, sure
<aka_[m]> dts alone
<aka_[m]> konradybcio: would you mind taking a look?:
<aka_[m]> still have to compile-test and binding checks
<djakov> konradybcio: hey, i discussed the QoS stuff with with some qcom folks and they confirmed that writing to QoS registers is persistant (they are reset only by the primary chip reset, they are retained during power collapse etc.), so we can program them just once, and not on every bandwidth request.
<aka_[m]> interconnect moment i see
<aka_[m]> konradybcio: when sending patches?
<aka_[m]> i might depend on .channels prop
<djakov> the support for specifying channel num should be already in -next
<aka_[m]> <djakov> "the support for specifying..." <- imma just have a look, regarding icc, do you know why some nodes return -6 error during probe?
<aka_[m]> ones with weird names like mas_spdm/mas_dehr
pespin has quit []
<djakov> on which platform is this?
<aka_[m]> 8976
<aka_[m]> last time i tested year ago
<aka_[m]> so maybe something changed
<aka_[m]> need to wire it again
<aka_[m]> prob something like this
<djakov> spdm is a debug thing, mostly used during board bringup and testing. not really useful upstream. recently we also removed the spdm from clock drivers
<aka_[m]> on very old source i have comments for each where i had errors:
<aka_[m]> dehr/lpass/spdm/xm_usb_hs
<aka_[m]> i guess as long as we don't request any of these it won't make diff if they even exist in driver?
<aka_[m]> or by default it sends some request for each during probe?
<djakov> by default we go through each node and try to set initial bandwidth
<aka_[m]> i see.
<aka_[m]> so it would be better to drop node or just set rpm/slave ids to -1?
<djakov> well if the RPM complains about these mas/slv ids, then we should send them.. maybe these are not supported. odd that they exist in downstream.
<djakov> set the ids to -1. they may still be part of some path and removing them may break it...
enok has quit [Remote host closed the connection]
enok has joined #linux-msm
<aka_[m]> based on pmos glossary page dehr is "DMA Engine for Hardware Retention"
Caterpillar has joined #linux-msm
<DavidHeidelberg[m]> anyone managed to upload kernel, initramfs over tftp to HDK 888?