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

Message

Peter Ujfalusi Nov. 14, 2018, 12:46 p.m. UTC

Hi,

This series is on top of the pm_qos changes I have sent earlier today.

I have sent this originally two years ago:
https://patchwork.kernel.org/patch/9119551/

But needed to revert it as the MFD and clk changes were not merged in time:
https://patchwork.kernel.org/patch/9287431/

The dts patches are already upstream, only the patch for McPDM is missing.

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.

Regards,
Peter
---
Peter Ujfalusi (2):
  dt-bindings: sound: omap-mcpdm: Update documentation for pdmclk
  ASoC: omap-mcpdm: Add support for pdmclk clock handling

 .../devicetree/bindings/sound/omap-mcpdm.txt  | 10 ++++++++
 sound/soc/omap/omap-mcpdm.c                   | 23 +++++++++++++++++++
 2 files changed, 33 insertions(+)

Comments

Mark Brown Nov. 15, 2018, 10:30 p.m. UTC | #1

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.

Peter Ujfalusi Nov. 16, 2018, 7:58 a.m. UTC | #2

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. 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

H. Nikolaus Schaller Nov. 16, 2018, 12:04 p.m. UTC | #3

Hi Peter,

> Am 16.11.2018 um 08:58 schrieb Peter Ujfalusi <[e-mail]>:
> 
> 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