[alsa-devel] [PATCH 0/2] ASoC: omap-mcpdm: Support for handling pdmclk

[H. Nikolaus Schaller]

Hi Peter,

> Am 16.11.2018 um 08:58 schrieb Peter Ujfalusi <peter.ujfalusi at ti.com>:
> 
> On 2018-11-16 00:30, Mark Brown wrote:
>> On Wed, Nov 14, 2018 at 02:46:29PM +0200, Peter Ujfalusi wrote:
>> 
>>> I have separated the binding document update and the driver patch and also
>>> added the return value check for the clk_prepare_enable() as per Mark's comment.
>> 
>> I guess this depends on your other series for pm_qos - it's fine itself
>> but doesn't apply, I'm leaving the pm_qos series for a bit longer in
>> case there's more reviews.
> 
> Yes, I moved this on top of the pm_qos, I think I have mentioned that in
> the cover letter.
> 
> Yes again, let's wait for Nikolaus to test the pm_qos w/o CPU_IDLE and
> hopefully 4.19 against the scratchy tenth of seconds observed.

It seems to depend on high volume at the speaker (amixer 'Handsfree') and
is also observable with CPU_IDLE=n

root at letux:~# gunzip </proc/config.gz |fgrep IDLE
CONFIG_NO_HZ_IDLE=y
# CONFIG_CPU_IDLE is not set
CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_POLL_SETUP=y
# CONFIG_IDLE_PAGE_TRACKING is not set
CONFIG_NETFILTER_XT_TARGET_IDLETIMER=m
root at letux:~# 

So it is a different issue for future study, e.g. with newer hardware or
older kernel binaries.

> Fwiw on
> omap5-uevm I was able to reproduce bad audio quality with CPU_IDLE which
> is fixed by the pm_qos patch.
> 
> - Péter
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


BR and thanks,
Nikolaus