* Peter Ujfalusi <peter.ujfalusi@xxxxxx> [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 -- 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
