* Peter Ujfalusi peter.ujfalusi@ti.com [160913 04:45]:
On 09/10/16 02:45, Tony Lindgren wrote:
In any way, according to the numbers: C7 is (7505 + 15274) vs (10000 + 30000) C6 is (7580 + 4134) vs (3000 + 8500) C5 is (855 + 1146) vs (2500 + 7500) C4 is (121 + 3374) vs (1500 + 1800) C3 is (107 + 410) vs (50 + 50)
with the 30ms QoS we set we will still hit OFF on OMAP3430, it should minimum 11.715ms for omap3430, but that will block C6 on omap36xx.
Yeah those don't seem to be correct. The Nokia N9(50) kernel seems to have some measured numbers for 36xx.
True, probably we should give those numbers a try? It looks like they have C1...C8 compared to mainline which have C1...C7.
Well some of those numbers are based on OSWR (Open SWitch Retention), not sure if that works properly with mainline. Worth trying though.
If we could have the data for the struct cpuidle_state coming from DT and not wired in the cpuidle34xx/44xx files then the McBSP driver could look up the C7 number and block that...
I'm now thinking that your fifo threshold calculation is what we should do, then fix the cpuidle latencies and playback should hit retention idle.
Right. So the QoS should be set time(FIFOsize - FIFOthreshold) - margin? What margin we should use? The DMA does not need setup time as it will just continue where it stopped, so probably we can ignore the margin and use the number we got from the FIFO use?
Yeah seems safe assuming the mystery numbers are wrong C state latencies :)
During hw_param we can calculate this, but we need to consider on more thing: we need to make sure that the QoS we place covers the capture and the playback as well, so we need to use the worst case number. the FIFO threshold can be different for capture and playback.
OK makes sense to me.
Regards,
Tony