Re: Regression found (Stop-marking-clocks-as-CLK_IS_CRITICAL)

From: Hans de Goede
Date: Thu Jan 24 2019 - 05:35:22 EST


Hi,

On 21-01-19 06:55, Mogens Jensen wrote:
âââââââ Original Message âââââââ
On Friday, January 18, 2019 3:35 PM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:

Hi,

On 1/17/19 8:30 PM, Mogens Jensen wrote:

âââââââ Original Message âââââââ
On Thursday, January 17, 2019 12:05 PM, Hans de Goede hdegoede@xxxxxxxxxx wrote:

Hi,
On 17-01-19 10:12, Dean Wallace wrote:

Hi Hans, Mogens,
On 17-01-19, Mogens Jensen wrote:

Kernel is compiled with SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH and the quirk seems to have fixed the problem caused by commit 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL"), as sound is now working if running "speaker-test" on my system which is clean ALSA.

Note being "clean ALSA" is really not a good thing now a days,
for lots of things we depend on pulseaudio (like setting
up UCM mixer profiles).

I'm using UCM mixer profile from:
https://github.com/plbossart/UCM/tree/master/chtmax98090
This is enabled with:
alsaucm -c chtmax98090 set _verb HiFi set _enadev Speakers

Unfortunately, SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH driver is unusable on Clapper Chromebooks as audio played from everything but "speaker-test" as video players or web browsers is extremly low and sounds like played at 10x speed. At the same time kernel log is spammed with messages like this:
max98090 i2c-193C9890:00: PLL unlocked
intel_sst_acpi 80860F28:00: FW Version 01.0c.00.01
writing to lpe: 00000000: 01 01 01 01 00 00 08 00 ff ff ff ff 55 00 00 00 ............U...
writing to lpe: 00000000: 01 01 01 01 00 00 1a 00 ff ff ff ff 75 00 12 00 ............u...
This is probably not related to the problem discussed in this thread, but the result is that I have to use the legacy driver SND_SOC_INTEL_BYT_MAX98090_MACH and therefore still has to revert commit 648e921888ad for sound to work.
Is it possible to create a fix for SND_SOC_INTEL_BYT_MAX98090_MACH on kernel 4.19? Kernel 4.19 is a long term release so it would be very nice to have fix for this version upstream.

I have been reverting "clk: x86: Stop marking clocks as CLK_IS_CRITICAL"
and the patch that initially added the quirk for swanky because of sound
instability issues as you described. I'm compiling vanilla Archlinux
kernel with SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH, using pulseaudio,
and have sound in all my apps.
Baytrail sound has always been a little touchy, especially using headset
with mic, but since the clk patch breaking sound and the quirk patch to
fix it, there is a lot more instability. Just running pavucontrol, or
plugging in headset sets it off. It's a head scratcher.

Mogens, Dean, can you please try the SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH
driver, without reverting any patches, with the attached patch on top and
see if that helps?
Thanks & Regards,
Hans

I have applied the patch to kernel 4.19.15 and unfortunately this has not solved the problems.
Audio generated from "speaker-test" is normal, but from everything else is very low and played at 10x speed. However, I'm not seeing the "max98090 i2c-193C9890:00: PLL unlocked" message in kernel log anymore, but it's still spammed with "writing to lpe: ...".

Hmm, I've a feeling the problem is your using alsa directly, do you have
dmix enabled ? You probably need dmix since the SST sound support
only supports 48KHz AFAIK.

Can you perhaps give things a try with pulseaudio ?

Regards,

Hans

You are absolutely correct, software mixing was apparently not enabled on my system and this caused the audio problems. I thought that dmix was enabled by default if hardware mixing was not supported. Thank you very much.

I was completely wrong about "SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH driver seems to be unusable on Clapper Chromebooks". Sorry about that.

To sum up, audio is working perfectly on my Clapper Chromebook running kernel 4.19.15 with SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH + "0001-ASoC-intel-cht_bsw_max98090_ti-Enable-codec-clock-on.patch", even better than before with the legacy driver.

Thank you for testing this. Given that things now work for both you and Dean I've
submitted the patch you both have tested upstream.

Regards,

Hans