Quoting David Dai (2018-12-05 17:24:18) > > > On 12/4/2018 11:15 PM, Stephen Boyd wrote: > > Quoting David Dai (2018-12-04 17:14:10) > >> On 12/4/2018 2:34 PM, Stephen Boyd wrote: > >>> Quoting Alex Elder (2018-12-04 13:41:47) > >>>> > >>> But then we translate that clock rate into a bandwidth request to the > >>> BCM hardware? Seems really weird because it's doing the opposite of what > >>> you say is abusive. What does the IPA driver plan to do with this clk? > >>> Calculate a frequency by knowing that it really boils down to some > >>> bandwidth that then gets converted back into some clock frequency? Do we > >>> have the user somewhere that can be pointed to? > >> The clock rate is translated into a unitless threshold value sent as > >> part of the rpmh msg > >> that BCM takes to select a performance. In this case, the unit > >> conversion is based on > >> the unit value read from the aux data which is in Khz. I understand that > >> this wasn't > >> explicitly mentioned anywhere and I'll improve on that next patch. > > How is this different from bus bandwidth requests? In those cases the > > bandwidth is calculated in bits per second or something like that, and > > written to the hardware so it can convert that bandwidth into kHz and > > set a bus clk frequency in the clock controller? So in the IPA case > > we've skipped the bps to kHz conversion step and gone straight to the > > clk frequency setting part? Is a BCM able to aggregate units of > > bandwidth or kHz depending on how it's configured and this BCM is > > configured for kHz? > > The data written to the hardware is just a 14bit scalar value that it > takes to select a performance/frequency from a preset table. It's not > really doing any sort of conversion in hardware in this case, instead > the value is computed by software based on the aux data given. Think of > it as a generic aggregator as opposed to being strictly bandwidth and > the aggregator itself does not care what type of value it is(be it Khz > or BW/s). > Got it. Thanks!
