Hi Akash, On 4/8/20 15:17, Akash Asthana wrote: > Hi Mark, Evan, Georgi, > > On 4/7/2020 4:25 PM, Mark Brown wrote: >> On Tue, Apr 07, 2020 at 03:24:42PM +0530, Akash Asthana wrote: >>> On 3/31/2020 4:53 PM, Mark Brown wrote: >>>>> + ctrl->avg_bw_cpu = Bps_to_icc(speed_hz); >>>>> + ctrl->peak_bw_cpu = Bps_to_icc(2 * speed_hz); >>>> I thought you were going to factor this best guess handling of peak >>>> bandwidth out into the core? >>> I can centralize this for SPI, I2C and UART in Common driver(QUP wrapper) >>> but still for QSPI I have to keep this piece of code as is because It is not >>> child of QUP wrapper(it doesn't use common code). >> Why not? >> >>> I am not sure whether I can move this " Assume peak_bw as twice of avg_bw if >>> nothing is mentioned explicitly" to ICC core because the factor of 2 is >>> chosen randomly by me. >> That's the whole point - if this is just a random number then we may as >> well at least be consistently random. > > Can we centralize below logic of peak_bw selection for all the clients to ICC core? I don't think this is a good idea for now, because this is very hardware specific. A scaling factor that works for one client might not work for another. My questions here is how did you decide on this "multiply by two"? I can imagine that the traffic can be bursty on some interfaces, but is the factor here really a "random number" or is this based on some data patterns or performance analysis? Thanks, Georgi
