Hi Peter, > Am 16.11.2018 um 08:58 schrieb Peter Ujfalusi <peter.ujfalusi@xxxxxx>: > > 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@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@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
