* Peter Ujfalusi <peter.ujfalusi@xxxxxx> [160831 04:38]: > > > > + /* Prevent omap hardware from hitting off between fifo fills */ > > + pm_qos_add_request(&mcbsp->pm_qos_req, PM_QOS_CPU_DMA_LATENCY, > > + 30 * 1000); > > The latency value depends on the McBSP FIFO size and the speed the DMA can > transfer the data. > OMAP3.McBSP2 have 1280 word as buffer. All other McBSP across SoCs have 128 > words or no FIFO. Yeah this is with mcbsp2 using boards like the beaglebone variants. Probably the same issue on 900 as reported by Pavel earlier. > The DMA fill speed will depend on several factors, I guess it is faster on > OMAP4/5 then on OMAP3/2/1. Probably this is only issue with mcbsp2.. > If we have McBSP w/o FIFO there is no need for the qos AFAIK. > I'm fine with the 30ms, if you have done the testing on OMAP3.McBSP2, probably > setting 30ms for McBSP with 1280 FIFO, 3ms for 128 FIFO and no qos for McBSP > w/o FIFO might be better. Or: > > latency = mcbsp->pdata->buffer_size * 23; /* 29.44ms on omap3's mcbsp2 */ > > if (latency) > pm_qos_add_request(&mcbsp->pm_qos_req, PM_QOS_CPU_DMA_LATENCY, > latency); OK let me run some tests with that and mcbsp2 fifo set to 128. My guess is that things already work for that case with no patches with the existing fifo based snd_pcm_hw_constraint_step() setting limits low enough so we never enter deeper idle states, but let's see :) 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
