ChanServ changed the topic of #linux-msm to:
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
jhovold has joined #linux-msm
pevik has joined #linux-msm
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
mirsal[m] is now known as mirsal
pespin has joined #linux-msm
pevik has quit [Quit: Lost terminal]
pevik has joined #linux-msm
<aka_[m]> Any idea how can i read registers on android?
<aka_[m]> with userspace tools
<aka_[m]> iotools requires /dev/mem which is accessible since kernel 4.0 and this crap ship with 3.10
<aka_[m]> or this is wrong
<aka_[m]> maybe its wrong because 3.10 config has
<aka_[m]> # CONFIG_DEVMEM is not set
<lumag> aka_[m], build it as a separate module?
<lumag> out-of-tree module
<aka_[m]> well im not really linux guy tbh so i doubt i would be able to do it xD
<aka_[m]> just gonna give it a try if it works great
<aka_[m]> then i can get some cpufreq action on 8976.
<aka_[m]> lumag: on the way, planning to resend dpu bindings patches?
<aka_[m]> isn't it funny, i cannot program, nor i know linux, yet i push myself into messing with something i have no idea about.
<lumag> aka_[m], yes, just too many stuff happening lately.
<aka_[m]> noticed
<lumag> The dpu, mdss and mdp5 bindings are still on my plate.
<aka_[m]> there is a lot of stuff going
<Marijn[m]> The DPU bindings refactor? Not sure what the context is of this, but since I have at least 2 platforms with pending HW catalog changes... this is relevant for me :)
<lumag> Marijn[m], yes, this patchset
<lumag> aka_[m], Marijn[m], please ping me after the weekend if I fail to send them before Monday.
<Marijn[m]> lumag: is the link missing from your message? I'm wondering what `this` refers to :) - all I remember is a `dt-bindings` refactor
<aka_[m]> nice, /dev/mem is there on 3.10
<Marijn[m]> lumag: Do the same to me if I don't end up sending DSC v4 _and_ the first iteration of INTF-PP support
* Marijn[m] realizes there isn't actually any day between now and Monday with time available to look into this.
<lumag> :D
pevik has quit [Ping timeout: 480 seconds]
<flamingradian[m]> how are we going to add iommu support for new socs now
<aka_[m]> flamingradian[m]: do they revamp smmu compatibles adding too?
<aka_[m]> well bit good because its pain to just add compatible instead of reusing
<flamingradian[m]> I did a v2 with review and ack tags, then a resend, then lumag commented on the original series:
<flamingradian[m]> so we seem to not be doing anything to add new soc support right now
<aka_[m]> flamingradian[m]: that would be great tbh
<aka_[m]> save a hassle with adding it and documenting
<aka_[m]> bamse: are you familiar with PLL internals?
<flamingradian[m]> aka_[m]: problem is I'd have to use something like sdm845 compat until it gets cleared up
<flamingradian[m]> and add an unnecessary quirk
<aka_[m]> ok great
<aka_[m]> i almost sorted situation with HFPLL on 8976
<aka_[m]> SR one need bit tweak
<aka_[m]> now i have to read CCI PLL and try on mainline
<aka_[m]> still one quirk im not sure about tho >_>
jhovold has quit [Ping timeout: 480 seconds]
<aka_[m]> Can anyone explain me this code snippet?... (full message at <>)
<aka_[m]> user_vco_mask is BIT(20)
<aka_[m]> rate comes from HW_get_rate or something
<aka_[m]> long unsigned, whatever i do && with it gives 1
<aka_[m]> if (1 > low_vco_rate)
<aka_[m]> then it does regmap write?
<aka_[m]> because low_vco_rate is UL which is big
pespin has quit [Remote host closed the connection]
<calebccff> there are two VCO's, I'm guessing one handles lower frequency and one handles higher frequency. If the rate (frequency) is beyond low_vco_max_rate then set some bits to tell the hardware to use the high rate VCO instead
<aka_[m]> calebccff: yes but there is an issue
<aka_[m]> downstream while doing that it also changes config register
<aka_[m]> and i don't understand what is result of mask && rate
<calebccff> it's checking that the user_vco_mask variable is valid and contains some value
<aka_[m]> because i tried to do that calc by providing freq in same format like low_vco_max_rate
<aka_[m]> if(1<<20 && 652800000 > 902400000)
<aka_[m]> thats what does not give me peace
<calebccff> it's just checking that user_vco_mask is non-zero, ie that whatever platform we're running on supports that feature I guess
<calebccff> and then it's also checking if the rate is high enough that we should use "user_vco" instead of "low_vco" or whatever
<aka_[m]> but how it knows if it has to toggle VCO 0/1 if it only checks and not compare what we want to achieve with what we define "too high"
<aka_[m]> wiat
<aka_[m]> wait
<aka_[m]> i might get it
<aka_[m]> first it compare freqs
<aka_[m]> then it check if mask exist?
<aka_[m]> so if ((1<<20) (freq > freq2) )
<aka_[m]> ?
<calebccff> I'm not sure i understand your confusion
<aka_[m]> i first tried to AND 1<<20 and first rate
<aka_[m]> and then compare if lower
<calebccff> it checks that the mask is set, ie there is a user_vco_mask, it is possible to apply that to achieve some desire behaviour. It also checks at the same time if we actually want to make use of user_vco_mask or not, depending on the rate
<aka_[m]> instead of checking if 1 AND rate_is_lower
<aka_[m]> well you have academic education and i hardly passed math in highschool, math and logic isn't my great strength
<aka_[m]> calebccff: i have one funny thing where vco is always toggled to low
<aka_[m]> so should i set max low vco rate equal to max PLL rate?
<calebccff> I'm afraid I can't really help from here. I don't know anything about qcom clock stuff - or much about clocks in general tbh..
<aka_[m]> calebccff: so in this snipped there is also regval after if and then write there is no brackets so i assume regval is only done when if fits criteria otherwise it goes straight to write?
<calebccff> yeah, the regmap_write happens regardless, the mask is only applied if the condition is tru
<calebccff> true*
<aka_[m]> now i need to do something ugly
<aka_[m]> either, define low_vco_max rate to be bit bigger than supported freq because on a72 vco is always 1
<aka_[m]> or just remove vco mask and set it inside user_val
<Marijn[m]> <aka_[m]> "long unsigned, whatever i do..." <- `&&` is the logical AND operator, treating both sides as a boolean. For that it has to convert the integer value in `hd->user_vco_mask` to a boolean, which'll be `true` if the value is _non_-zero, `false` otherwise.
<Marijn[m]> In other words, if the user didn't configure any bitmask to set for any rate higher than `low_vco_max_rate`, it doesn't set it
<Marijn[m]> Not that it really matters though, and only adds confusion IMO: if `hd->user_vco_mask` is zero, `regval |= hd->user_vco_mask;` is a no-op so it doesn't matter to check it inside the `if`
<Marijn[m]> aka_: does that help?
telent has quit [Quit: Ping timeout (120 seconds)]
telent has joined #linux-msm