<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
<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)]