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