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.
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.
-Dean
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).
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
On Thu, Jan 17, 2019 at 01:05:35PM +0100, Hans de Goede wrote:
On 17-01-19 10:12, Dean Wallace wrote:
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).
FWIW I disagree because PA never worked for me. I simply used "alsaucm -c chtcx2072x set _verb HiFi". But I was surprised that PA does the ALSA UCM setup but it's not documented well that you need to do it by other means if you don't use PA. https://bugzilla.kernel.org/show_bug.cgi?id=115531#c72
Regards, Johannes
On 17-01-19, Hans de Goede wrote:
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?
Hi Hans. Just compiled 4.20.3 with your new patch and no other patches. First impressions are, this is now as stable as it has ever been in my experiences with this baytrail drama. A quick run down on my tests/findings:-
No PLL messages on boot, good. Played audio using mpd, all fine. Plugged in headphones, switches, stays stable, no messages. Unplugged/plugged again few times, no issues. Ran pavucontrol, stayed stable, no messages. I can still make it lose the lock and turn on the dalek distortion by switching profiles in pavucontrol (from stereo output to any other, like putput + input) but that has always been the case afaik for this machine. So basically this is now back to working as it was before the 4.18.5 'clk' breakage.
One thing to mention, I don;t normally use UCM files, tho I have in the past, which is where I assume my asound.state file has come from, which makes my sound work /shrug. Well I've just tested using the UCM, and things are a little less stable regarding plugging/unplugging headset a few times. It loses lock, but, what's different now is after maybe 3-4 seconds it corrects itself. Not sure if it matters, but shows things are a little more stable with this patch than previously known.
I'll test a little longer and report (if) any problems. It will be interesting to see how my buddy who uses headset/mic a lot gets on, as he needs to use usb audio device because internal sound and mic don't work properly.
-Dean
Hi,
On 1/17/19 2:16 PM, Dean Wallace wrote:
On 17-01-19, Hans de Goede wrote:
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?
Hi Hans. Just compiled 4.20.3 with your new patch and no other patches. First impressions are, this is now as stable as it has ever been in my experiences with this baytrail drama. A quick run down on my tests/findings:-
No PLL messages on boot, good. Played audio using mpd, all fine. Plugged in headphones, switches, stays stable, no messages. Unplugged/plugged again few times, no issues. Ran pavucontrol, stayed stable, no messages. I can still make it lose the lock and turn on the dalek distortion by switching profiles in pavucontrol (from stereo output to any other, like putput + input) but that has always been the case afaik for this machine. So basically this is now back to working as it was before the 4.18.5 'clk' breakage.
One thing to mention, I don;t normally use UCM files, tho I have in the past, which is where I assume my asound.state file has come from, which makes my sound work /shrug. Well I've just tested using the UCM, and things are a little less stable regarding plugging/unplugging headset a few times. It loses lock, but, what's different now is after maybe 3-4 seconds it corrects itself. Not sure if it matters, but shows things are a little more stable with this patch than previously known.
Ok, thank you for testing. Lets wait a bit and then if no problems show up I will submit the patch upstream.
Regards,
Hans
linux-stable-mirror@lists.linaro.org
-
Dean Wallace -
Hans de Goede -
Johannes Stezenbach