| Message ID | 20181114110623.30932-1-peter.ujfalusi@ti.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ASoC: omap: Fix and add pm_qos configuration | expand |
Hi, > Am 14.11.2018 um 13:45 schrieb H. Nikolaus Schaller <hns@goldelico.com>: > > Hi Peter, > >> Am 14.11.2018 um 12:06 schrieb Peter Ujfalusi <peter.ujfalusi@ti.com>: >> >> Hi, >> >> The defconfig for OMAP2+ now have the CPU_IDLE enabled which can cause audio >> artifacts because we try to enter too low power state from where the wakeup >> takes longer than the FIFO can tolerate on the dai side. >> >> While adding pm_qos to McPDM and DMIC I have noticed that the McBSP calculation >> was not correct as we need usec for the latency value. >> >> Regards, >> Peter >> --- >> Peter Ujfalusi (3): >> ASoC: omap-mcbsp: Fix latency value calculation for pm_qos >> ASoC: omap-mcpdm: Add pm_qos handling to avoid under/overruns with >> CPU_IDLE >> ASoC: omap-dmic: Add pm_qos handling to avoid overruns with CPU_IDLE >> >> sound/soc/omap/omap-dmic.c | 9 ++++++++ >> sound/soc/omap/omap-mcbsp.c | 6 +++--- >> sound/soc/omap/omap-mcpdm.c | 43 ++++++++++++++++++++++++++++++++++++- >> 3 files changed, 54 insertions(+), 4 deletions(-) > > I will test asap. I have now: * v4.20-rc2 * plus your new patches * plus letux-4.20-rc2 patches * including our private AESS patch set (mostly inactive, because it fails to load firmware) * CONFIG_CPU_IDLE=y and it works. I can use aplay and play to get handsfree audio as with CONFIG_CPU_IDLE=n Sometimes, there is a scratchy tenth of a second (in handsfree and headset), but the basic rhythm does not get interrupted any more and the play command does not get stuck. I have played an mp3 of 4 minutes and the play process did succeed and didn't report buffer underrun issues. So your patches seem to fix the issue. At least the basic problems. This scratchy thing needs further study, if it is a spurious thing on my Pyra protoype device. Or if it is still there if we disable CPU_IDLE again (I haven't tried that yet). BR and thanks for quick help, Nikolaus
Hi, On 2018-11-15 14:26, H. Nikolaus Schaller wrote: > Hi, > >> Am 14.11.2018 um 13:45 schrieb H. Nikolaus Schaller <hns@goldelico.com>: >> >> Hi Peter, >> >>> Am 14.11.2018 um 12:06 schrieb Peter Ujfalusi <peter.ujfalusi@ti.com>: >>> >>> Hi, >>> >>> The defconfig for OMAP2+ now have the CPU_IDLE enabled which can cause audio >>> artifacts because we try to enter too low power state from where the wakeup >>> takes longer than the FIFO can tolerate on the dai side. >>> >>> While adding pm_qos to McPDM and DMIC I have noticed that the McBSP calculation >>> was not correct as we need usec for the latency value. >>> >>> Regards, >>> Peter >>> --- >>> Peter Ujfalusi (3): >>> ASoC: omap-mcbsp: Fix latency value calculation for pm_qos >>> ASoC: omap-mcpdm: Add pm_qos handling to avoid under/overruns with >>> CPU_IDLE >>> ASoC: omap-dmic: Add pm_qos handling to avoid overruns with CPU_IDLE >>> >>> sound/soc/omap/omap-dmic.c | 9 ++++++++ >>> sound/soc/omap/omap-mcbsp.c | 6 +++--- >>> sound/soc/omap/omap-mcpdm.c | 43 ++++++++++++++++++++++++++++++++++++- >>> 3 files changed, 54 insertions(+), 4 deletions(-) >> >> I will test asap. > > I have now: > > * v4.20-rc2 > * plus your new patches > * plus letux-4.20-rc2 patches > * including our private AESS patch set (mostly inactive, because it fails to load firmware) > * CONFIG_CPU_IDLE=y > > and it works. I can use aplay and play to get handsfree audio as with CONFIG_CPU_IDLE=n Thanks for testing! > Sometimes, there is a scratchy tenth of a second (in handsfree and headset), If you set CONFIG_CPU_IDLE=n, do you still have the scratchy sound? Or with 4.19 kernel if you can cross check it? > but the basic rhythm does not get interrupted any more and the play command does > not get stuck. > > I have played an mp3 of 4 minutes and the play process did succeed and didn't report > buffer underrun issues. > > So your patches seem to fix the issue. At least the basic problems. This scratchy > thing needs further study, if it is a spurious thing on my Pyra protoype device. > Or if it is still there if we disable CPU_IDLE again (I haven't tried that yet). > > BR and thanks for quick help, > Nikolaus > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 2018-11-15 16:29, Peter Ujfalusi wrote: >> Sometimes, there is a scratchy tenth of a second (in handsfree and headset), > > If you set CONFIG_CPU_IDLE=n, do you still have the scratchy sound? Or > with 4.19 kernel if you can cross check it? If it is not there w/o CPU_IDLE then can you try one thing: print out the latency usec the patch is calculating and, by guess divide it by 10 and pass that to pm_qos API. My calculation of the usec is not correct or I'm calculating it in a wrong way? - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 11/15/18 2:26 PM, H. Nikolaus Schaller wrote: >>> Peter Ujfalusi (3): >>> ASoC: omap-mcbsp: Fix latency value calculation for pm_qos >>> ASoC: omap-mcpdm: Add pm_qos handling to avoid under/overruns with >>> CPU_IDLE >>> ASoC: omap-dmic: Add pm_qos handling to avoid overruns with CPU_IDLE >>> >>> sound/soc/omap/omap-dmic.c | 9 ++++++++ >>> sound/soc/omap/omap-mcbsp.c | 6 +++--- >>> sound/soc/omap/omap-mcpdm.c | 43 ++++++++++++++++++++++++++++++++++++- >>> 3 files changed, 54 insertions(+), 4 deletions(-) >> >> I will test asap. > > I have now: > > * v4.20-rc2 > * plus your new patches > * plus letux-4.20-rc2 patches > * including our private AESS patch set (mostly inactive, because it fails to load firmware) > * CONFIG_CPU_IDLE=y > > and it works. I can use aplay and play to get handsfree audio as with CONFIG_CPU_IDLE=n > > Sometimes, there is a scratchy tenth of a second (in handsfree and headset), > but the basic rhythm does not get interrupted any more and the play command does > not get stuck. > > I have played an mp3 of 4 minutes and the play process did succeed and didn't report > buffer underrun issues. > > So your patches seem to fix the issue. At least the basic problems. This scratchy > thing needs further study, if it is a spurious thing on my Pyra protoype device. > Or if it is still there if we disable CPU_IDLE again (I haven't tried that yet). > Peter: do you have some simple test case for N810 or N900? I tried to play with a few different aplay --buffer-size and --period-size combinations to see can I hit this. N810 most probably wasn't able to hit deep enough idle as the display is on due there is no driver for it. On N900 I have display blanked. I have one educational question on 1/3 but no any show stoppers. For all three: Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
On 2018-11-18 19:04, Jarkko Nikula wrote: > On 11/15/18 2:26 PM, H. Nikolaus Schaller wrote: >>>> Peter Ujfalusi (3): >>>> ASoC: omap-mcbsp: Fix latency value calculation for pm_qos >>>> ASoC: omap-mcpdm: Add pm_qos handling to avoid under/overruns with >>>> CPU_IDLE >>>> ASoC: omap-dmic: Add pm_qos handling to avoid overruns with CPU_IDLE >>>> >>>> sound/soc/omap/omap-dmic.c | 9 ++++++++ >>>> sound/soc/omap/omap-mcbsp.c | 6 +++--- >>>> sound/soc/omap/omap-mcpdm.c | 43 ++++++++++++++++++++++++++++++++++++- >>>> 3 files changed, 54 insertions(+), 4 deletions(-) >>> >>> I will test asap. >> >> I have now: >> >> * v4.20-rc2 >> * plus your new patches >> * plus letux-4.20-rc2 patches >> * including our private AESS patch set (mostly inactive, because it fails to load firmware) >> * CONFIG_CPU_IDLE=y >> >> and it works. I can use aplay and play to get handsfree audio as with CONFIG_CPU_IDLE=n >> >> Sometimes, there is a scratchy tenth of a second (in handsfree and headset), >> but the basic rhythm does not get interrupted any more and the play command does >> not get stuck. >> >> I have played an mp3 of 4 minutes and the play process did succeed and didn't report >> buffer underrun issues. >> >> So your patches seem to fix the issue. At least the basic problems. This scratchy >> thing needs further study, if it is a spurious thing on my Pyra protoype device. >> Or if it is still there if we disable CPU_IDLE again (I haven't tried that yet). >> > Peter: do you have some simple test case for N810 or N900? I tried to > play with a few different aplay --buffer-size and --period-size > combinations to see can I hit this. N810 most probably wasn't able to > hit deep enough idle as the display is on due there is no driver for it. > On N900 I have display blanked. If you have CPU_IDLE enabled (it should be by default) and you don't experience any crackling than it is working OK. Tony: or is there something else to look for in OMAP2/3 ? > I have one educational question on 1/3 but no any show stoppers. For all > three: > > Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com> > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Hi, The defconfig for OMAP2+ now have the CPU_IDLE enabled which can cause audio artifacts because we try to enter too low power state from where the wakeup takes longer than the FIFO can tolerate on the dai side. While adding pm_qos to McPDM and DMIC I have noticed that the McBSP calculation was not correct as we need usec for the latency value. Regards, Peter --- Peter Ujfalusi (3): ASoC: omap-mcbsp: Fix latency value calculation for pm_qos ASoC: omap-mcpdm: Add pm_qos handling to avoid under/overruns with CPU_IDLE ASoC: omap-dmic: Add pm_qos handling to avoid overruns with CPU_IDLE sound/soc/omap/omap-dmic.c | 9 ++++++++ sound/soc/omap/omap-mcbsp.c | 6 +++--- sound/soc/omap/omap-mcpdm.c | 43 ++++++++++++++++++++++++++++++++++++- 3 files changed, 54 insertions(+), 4 deletions(-)