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. >> 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? 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. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
