search

GalliumOS / galliumos-distro

Docs, issues, and artwork sources for GalliumOS
https://galliumos.org/
GNU General Public License v2.0
347 stars 11 forks source link

Internal audio does not work on CYAN #317

Closed reynhout closed 6 years ago

reynhout commented 7 years ago

CYAN is the only Braswell with the Maxim MAX98090 audio chip.

Current kernel builds (4.9.4-galliumos) include drivers for this chip, but they are not loading properly and internal audio is not working.

Temporary workarounds: Bluetooth or USB audio.

ghost commented 7 years ago

What's the priority for this issue looking like?

reynhout commented 7 years ago

kernel.org thread here: https://bugzilla.kernel.org/show_bug.cgi?id=151521

Kernel 4.9.4 with the patch in c14 (but without the @plbossart patch for rt5450) yields some new log messages: https://paste.debian.net/913490

reynhout commented 7 years ago

Init of MAX98090 gets further along with @mildred's patch, but now we hit a null pointer deref in the jack configuration. Perhaps there are more bits to pull in from the ChromiumOS tree?

In case the debian pastebin copy expires:

[    0.000000] Linux version 4.9.4-galliumos-braswell (reynhout@galliumos) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #1 SMP PREEMPT galliumos1+wip3.cyan.2 Thu Feb 9 02:52:48 UTC 201
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.4-galliumos-braswell root=UUID=7c0f7ebd-5854-4517-a97f-9424ddb76850 ro nosplash noplymouth boot=local acpi_osi=Linux acpi_backlight=vendor add_efi_memmap intel_pstate=enable i915.modeset=1 tpm_tis.force=1 tpm_tis.interrupts=0 nmi_watchdog=panic,lapic elevator=noop noresume gpiolib.acpi_lookup_can_try_crs=1
[    4.731933] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[    4.732357] intel_sst_acpi 808622A8:00: LPE base: 0xd1000000 size:0x200000
[    4.732363] intel_sst_acpi 808622A8:00: IRAM base: 0xd10c0000
[    4.732420] intel_sst_acpi 808622A8:00: DRAM base: 0xd1100000
[    4.732429] intel_sst_acpi 808622A8:00: SHIM base: 0xd1140000
[    4.732436] intel_sst_acpi 808622A8:00: Mailbox base: 0xd1144000
[    4.732441] intel_sst_acpi 808622A8:00: DDR base: 0x20000000
[    4.737903] intel_sst_acpi 808622A8:00: Got drv data max stream 25
[    4.849061] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1b.0/sound/card1/input7
[    4.849214] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1b.0/sound/card1/input8
[    4.849346] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1b.0/sound/card1/input9
[    4.918101] SSE version of gcm_enc/dec engaged.
[    5.074758] intel_rapl: Found RAPL domain core
[    5.078629] max98090 i2c-193C9890:00: MAX98090 REVID=0x43
[    5.085279] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
[    5.087321] IP: [<ffffffffc0463d40>] snd_jack_set_key+0x30/0x80 [snd]
[    5.087324] PGD 0 
[    5.087327] Oops: 0000 [#1] PREEMPT SMP
[    5.087377] Modules linked in: intel_rapl intel_powerclamp coretemp kvm_intel snd_soc_sst_cht_bsw_max98090_ti(+) kvm joydev irqbypass arc4 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw iwlmvm gf128mul glue_helper ablk_helper mac80211 cryptd snd_hda_codec_hdmi uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 snd_intel_sst_acpi snd_hda_intel videobuf2_core snd_intel_sst_core iwlwifi snd_hda_codec videodev btusb snd_soc_sst_mfld_platform snd_soc_ts3a227e btrtl snd_soc_max98090 snd_soc_sst_match snd_hwdep media snd_soc_core btbcm snd_pcm_oss snd_hda_core btintel snd_compress snd_mixer_oss bluetooth cfg80211 snd_pcm_dmaengine snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer int3403_thermal int3400_thermal snd elan_i2c processor_thermal_device
[    5.087400]  int340x_thermal_zone acpi_thermal_rel chromeos_pstore lpc_ich intel_soc_dts_iosf shpchp soundcore elants_i2c mfd_core 8250_dw acpi_cpufreq mac_hid autofs4 dm_mirror dm_region_hash dm_log mmc_block i915 video i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm sdhci_acpi sdhci
[    5.087404] CPU: 2 PID: 324 Comm: systemd-udevd Not tainted 4.9.4-galliumos-braswell #1
[    5.087406] Hardware name: GOOGLE Cyan, BIOS          08/21/2016
[    5.087408] task: ffff8ab43708d940 task.stack: ffffad80c0cc0000
[    5.087417] RIP: 0010:[<ffffffffc0463d40>]  [<ffffffffc0463d40>] snd_jack_set_key+0x30/0x80 [snd]
[    5.087419] RSP: 0018:ffffad80c0cc3a10  EFLAGS: 00010282
[    5.087421] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e
[    5.087422] RDX: 00000000000000e2 RSI: 0000000000004000 RDI: 0000000000000000
[    5.087423] RBP: ffffad80c0cc3a30 R08: ffff8ab4399ea3f8 R09: 0000000000000000
[    5.087425] R10: 0000000000000022 R11: 000000000001cd10 R12: 0000000000004000
[    5.087426] R13: 0000000000000000 R14: ffff8ab436446a68 R15: ffff8ab4364469f0
[    5.087429] FS:  00007f8aac3568c0(0000) GS:ffff8ab43fd00000(0000) knlGS:0000000000000000
[    5.087430] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    5.087432] CR2: 0000000000000028 CR3: 0000000177666000 CR4: 00000000001006e0
[    5.087433] Stack:
[    5.087439]  ffff8ab436446ad8 ffff8ab43947b858 ffff8ab439778318 ffff8ab436446ad8
[    5.087442]  ffffad80c0cc3a50 ffffffffc059110d ffff8ab436446a00 ffffffffc08820c0
[    5.087446]  ffffad80c0cc3a60 ffffffffc0880019 ffffad80c0cc3aa0 ffffffffc065fb51
[    5.087447] Call Trace:
[    5.087456]  [<ffffffffc059110d>] ts3a227e_enable_jack_detect+0x2d/0x80 [snd_soc_ts3a227e]
[    5.087463]  [<ffffffffc0880019>] cht_max98090_headset_init+0x19/0x20 [snd_soc_sst_cht_bsw_max98090_ti]
[    5.087491]  [<ffffffffc065fb51>] soc_probe_component+0x281/0x3c0 [snd_soc_core]
[    5.087506]  [<ffffffffc06620f7>] snd_soc_register_card+0x737/0x1020 [snd_soc_core]
[    5.087521]  [<ffffffffc0670281>] devm_snd_soc_register_card+0x41/0x80 [snd_soc_core]
[    5.087530]  [<ffffffffc08802ec>] snd_cht_mc_probe+0x6c/0xc8 [snd_soc_sst_cht_bsw_max98090_ti]
[    5.087539]  [<ffffffff864fd93b>] platform_drv_probe+0x3b/0xa0
[    5.087542]  [<ffffffff864fb794>] driver_probe_device+0x224/0x430
[    5.087546]  [<ffffffff864fba7f>] __driver_attach+0xdf/0xf0
[    5.087549]  [<ffffffff864fb9a0>] ? driver_probe_device+0x430/0x430
[    5.087552]  [<ffffffff864f9444>] bus_for_each_dev+0x64/0xa0
[    5.087555]  [<ffffffff864faefe>] driver_attach+0x1e/0x20
[    5.087557]  [<ffffffff864fa9fd>] bus_add_driver+0x1fd/0x270
[    5.087560]  [<ffffffffc01da000>] ? 0xffffffffc01da000
[    5.087563]  [<ffffffff864fc400>] driver_register+0x60/0xe0
[    5.087566]  [<ffffffff864fd8b6>] __platform_driver_register+0x36/0x40
[    5.087570]  [<ffffffffc01da017>] snd_cht_mc_driver_init+0x17/0x1000 [snd_soc_sst_cht_bsw_max98090_ti]
[    5.087575]  [<ffffffff86002190>] do_one_initcall+0x50/0x180
[    5.087582]  [<ffffffff86195950>] do_init_module+0x5f/0x1f6
[    5.087587]  [<ffffffff8610ced7>] load_module+0x2647/0x2a20
[    5.087590]  [<ffffffff86109620>] ? __symbol_put+0x70/0x70
[    5.087598]  [<ffffffff8610d4cc>] SYSC_finit_module+0xbc/0xf0
[    5.087603]  [<ffffffff8610d51e>] SyS_finit_module+0xe/0x10
[    5.087608]  [<ffffffff867629fb>] entry_SYSCALL_64_fastpath+0x1e/0xad
[    5.087656] Code: 55 b9 ff ff ff ff 89 c8 48 89 e5 41 55 41 54 53 41 89 f4 be 00 40 00 00 41 0f bd cc 0f bd c6 29 c8 48 83 ec 08 48 89 fb 41 89 c5 <8b> 47 28 85 c0 75 25 85 d2 74 3a 41 83 fd 05 77 34 49 63 c5 44 
[    5.087663] RIP  [<ffffffffc0463d40>] snd_jack_set_key+0x30/0x80 [snd]
[    5.087665]  RSP <ffffad80c0cc3a10>
[    5.087666] CR2: 0000000000000028
[    5.087868] ---[ end trace c107d479510d8b9c ]---
reynhout commented 7 years ago

Data sheet for the TS3A227E (Autonomous Audio Accessory Detection and Configuration Switch):

http://www.ti.com/lit/ds/symlink/ts3a227e.pdf

anorom commented 7 years ago

Are the new patches on https://bugzilla.kernel.org/show_bug.cgi?id=151521 helpful? Thanks

reynhout commented 7 years ago

@anorom No, they're not working yet. I haven't had a chance to see if I can push things any further, but the patches as-is do not resolve the issue.

anorom commented 7 years ago

It looked like the patches would not fix the issue but your testing and feedback seems to keep things moving. Appreciate your help.

chuckhacker commented 7 years ago

Any updates?

nkalupahana commented 7 years ago

Anything?

reynhout commented 7 years ago

@chuckhacker @nkalupahana When there is news, it will be posted here. You can subscribe to this ticket for email updates.

gordonthegopher commented 7 years ago

@reynhout Is this of any use?

https://aur.archlinux.org/packages/linux-max98090/

Apologies if not, I was just browsing the Arch AUR. I have no technical knowledge to help out and you may well know all this already.

Other sources:

https://bugs.archlinux.org/task/48936

https://wiki.archlinux.org/index.php/Chrome_OS_devices (Specifically Post Installation Configuration>Fixing audio>Baytrail based models)

chuckhacker commented 7 years ago

@reynhout Sounds good. Feel free to ping me so we can work out some sort of compensation agreement, if you're interested.

wommy commented 7 years ago

i would love to help with this in anyway i can

fixed gordonthegopher's link from above: https://wiki.archlinux.org/index.php/Chrome_OS_devices#Haswell_based_models

gluax commented 7 years ago

Is there any update for this issue?

electricduck commented 7 years ago

@gluaxspeed This is a high priority issue, so if there's an update, we will know about it. Posting things like this isn't constructive: keep GitHub Issues clean :)

wommy commented 7 years ago

would love to help in anyway I can

Velyro commented 7 years ago

How's it going so far?

jeffkub commented 7 years ago

I've been digging into the audio issue on CYAN, and becoming convinced its due to missing initialization code that chromeos does in the depthcharge payload.

https://plus.google.com/u/0/+TimoJyrinki/posts/R1AqYCSPru8

Here is the board setup function in depthcharge

https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/firmware-cyan-7287.57.B/src/board/cyan/board.c

I'm narrowing down specifically on the I2S interface (SSP2). The Linux driver doesn't seem to ioremap or touch these control registers.

https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/firmware-cyan-7287.57.B/src/drivers/bus/i2s/braswell/braswell.c

My theory is that for the MAX98090 codec on Braswell, the SSP2 interface needs to be initialized. I'll try to modify the driver to do the initialization... My experience is with ARM platforms, not Intel, so I'll see how far I can get.

plbossart commented 7 years ago

The ACPI-related code does all the initialization of I2C (and the interaction with the maxim codec works fine), the SSP is configured by the audio firmware. I suggest you don't waste too much time on this. The only assumption which was made is that the clock is managed by the BIOS/Coreboot, if this was not correct then this would explain why there is no sound. Ideally we'd need to figure out how to enable a loopback inside of the maxim codec to see if the SSP connection works. I haven't had time to look into this but that's how we debugged other platforms.

  1. prove that the digital audio transfers work across the SSP link with a loopback
  2. do an analog loopback from mic to speakers to prove than the audio subsystem is not blown
  3. try digital to analog.
jeffkub commented 7 years ago

The MAX98090 driver appears to have the loopback bit LBEN already supported. My understanding of the driver and ALSA subsystem is that I can set this bit with the following commands.

amixer -c2 set 'LBENL Mux' 'Loopback'
amixer -c2 set 'LBENR Mux' 'Loopback'

However, when I play some audio, I'm seeing activity in pulse audio on the output channel but not the input channel. If the loopback was working, I was expecting to see activity on the input channel. I may be missing something...

I also added some code to print the SSP2 registers in the intel-sst-acpi driver

[   10.309277] intel_sst_acpi 808622A8:00: LPE base: 0xd1000000 size:0x200000
[   10.309279] intel_sst_acpi 808622A8:00: IRAM base: 0xd10c0000
[   10.309299] intel_sst_acpi 808622A8:00: DRAM base: 0xd1100000
[   10.309305] intel_sst_acpi 808622A8:00: SSP2 base: 0xd10a2000
[   10.309311] intel_sst_acpi 808622A8:00: SSCR1: 0x43000000
[   10.309314] intel_sst_acpi 808622A8:00: SSCR2: 0x800
[   10.309318] intel_sst_acpi 808622A8:00: SSCR3: 0x2c604
[   10.309321] intel_sst_acpi 808622A8:00: SSCR4: 0x0
[   10.309324] intel_sst_acpi 808622A8:00: SSCR5: 0x0
[   10.309328] intel_sst_acpi 808622A8:00: SSPSP: 0x0
[   10.309331] intel_sst_acpi 808622A8:00: SSTSA: 0x0
[   10.309334] intel_sst_acpi 808622A8:00: SSRSA: 0x0
[   10.309337] intel_sst_acpi 808622A8:00: SSSR: 0xf004
[   10.309341] intel_sst_acpi 808622A8:00: SSCR0: 0x0
[   10.309344] intel_sst_acpi 808622A8:00: SSTO: 0x0
[   10.309345] intel_sst_acpi 808622A8:00: SHIM base: 0xd1140000
[   10.309350] intel_sst_acpi 808622A8:00: Mailbox base: 0xd1144000
[   10.309355] intel_sst_acpi 808622A8:00: DDR base: 0x20000000

I can't find any documentation on the LPE or the SSP peripherals on the Braswell chip. However, from looking at the depthcharge code, bit 7 of the SSCR0 register is the SSP enable bit, which is read as 0. Though, it may be that this is early in the driver init before the audio firmware sets up the SSP2...

Update: After receiving the firmware init message, I'm seeing the regs change. It looks like the audio firmware is setting up the SSP2

[   55.291762] intel_sst_acpi 808622A8:00: SSCR1: 0x41000003
[   55.291768] intel_sst_acpi 808622A8:00: SSCR2: 0x2801
[   55.291772] intel_sst_acpi 808622A8:00: SSCR3: 0x3c61f
[   55.291776] intel_sst_acpi 808622A8:00: SSCR4: 0x1400
[   55.291779] intel_sst_acpi 808622A8:00: SSCR5: 0x26
[   55.291783] intel_sst_acpi 808622A8:00: SSPSP: 0x140084
[   55.291787] intel_sst_acpi 808622A8:00: SSTSA: 0x0
[   55.291790] intel_sst_acpi 808622A8:00: SSRSA: 0x0
[   55.291794] intel_sst_acpi 808622A8:00: SSSR: 0xf004
[   55.291797] intel_sst_acpi 808622A8:00: SSCR0: 0xc0093f
[   55.291801] intel_sst_acpi 808622A8:00: SSTO: 0x0
plbossart commented 7 years ago

It could also be a recent bug that was discussed recently where settings up the clocks mucks with what the Coreboot firmware did. See https://www.spinics.net/lists/linux-clk/msg18650.html

jeffkub commented 7 years ago

Great news! I was able to get audio output through the speakers by mucking around with the alsamixer settings. It appears to have been a configuration issue.

I'll try to figure out what settings I changed and update here.

jeffkub commented 7 years ago

I have the speakers, headphone jack output, and built-in microphone working. The only bit not working yet is the headphone jack mic.

I modified the galliumos 4.12.0 kernel with the following patch, based on the findings here https://bugzilla.kernel.org/show_bug.cgi?id=151521

cyan-audio-driver-fix.patch.txt

I also used the ucm configuration files from the chromeos repo

https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/ucm-config/cyan/chtmax98090

with some modifications, as shown in this patch

ucm-mod-to-enable-audio.patch.txt

and placed the files at /usr/share/alsa/ucm/chtmax98090/. I can then reboot my computer and the settings persist.

Glad to finally have working audio on my chromebook 😄

ryanpcmcquen commented 7 years ago

@jeffkub, does that mean audio will soon work with GalliumOS on CYAN?

jeffkub commented 7 years ago

@ryanpcmcquen I'm not an active developer on the GalliumOS project, so I can't say if and when these changes will make it to release. That will be up to the distro maintainers.

lenlo commented 7 years ago

That's great @jeffkub! Thanks a ton for your sleuthing. Have you submitted your changes back to the GalliumOS project? I couldn't find your fork, but I'd love to try out your fixes. Would you be willing to make your precompiled custom kernel available for direct downloading until it's released? No warranties, of course. Cheers!

reynhout commented 7 years ago

@jeffkub Excellent, thanks for all of this work! I will try to repro today on the new 4.12 kernel and hopefully have something packaged up soon after.

plbossart commented 7 years ago

This is good progress, however I am confused on the fixes.

jeffkub commented 7 years ago

@plbossart the driver changes came from this bug on the Kernel.org bugzilla site. I specifically used the ACPI support, Fix I2S configs and remove useless code, and solve NULL dereference patches. All three look like patches that you had created back in February.

Here are the complete UCM files with my modifications

chtmax98090.conf HiFi.conf

plbossart commented 7 years ago

pretty funny, i didn't even remember my own patches. Gah. I'll give it a try on my cyan device, thanks.

friedman101 commented 7 years ago

Thanks for working on this guys, I'm looking forward to having working audio on my cyan :+1:

plbossart commented 7 years ago

The UCM config looks fine, the only weird thing is the reference to 'Ext HP Switch' which should really be replaced by 'Headphone Switch' My cyan device seems to be dead so unfortunately I couldn't test my cleaned-up patches. If someone was willing to test my branch it'd be a good thing. https://github.com/plbossart/sound/commits/topic/cyan

We may be able to use the same machine driver for rambi, but same thing my test device is fried as well.

Bloomca commented 7 years ago

I would like to help, but unfortunately I have zero idea how to test it. Maybe you can point out to me, where can I start in order to apply your patches on my CYAN device?

Thanks!

plbossart commented 7 years ago

if it helps I can provide this set of patches rebased on the regular gallium OS (need git remote information), it's no big deal. You would just need to recompile.

reynhout commented 7 years ago

@plbossart Thanks so much for your help! I'm excited to get this working on our CYAN test device. I had hoped to work on it yesterday, but it now looks like late today or tomorrow -- in any event, as soon as I get a couple hours to pull it all together and build some kernels, we should have packages available for testing.

@Bloomca I think two of the three patches are already in the repo (on the 4.10.5 branch, I think). The missing patch fixes the null deref error, which should be the last piece required. I'm going to apply all of them to the 4.12 branch, and (unless there are unresolvable issues) will push the kernel pkg to the testing APT repo. If you make a build before we can get the pkg pushed, let us know how if you run into any issues!

mildred commented 7 years ago

How to test those patches (how I did it) is:

For me, I still can't get any sound, but it's better than ever. The sound card is recognized. alsamixer show some controls. I can play sound and I see in pavucontrol the audio level moving with the sound I am playing. Mic doesn't work either. Note: the sound hardware is working because I still get beeps when I boot and I fail to select the legacy boot right away.

edit: this is basically a rewrite of https://github.com/GalliumOS/galliumos-distro/issues/317#issuecomment-322658720

mildred commented 7 years ago

@jeffkub how did you tweak the alsa mixer to make it work, do you remember? Could you share your /var/lib/alsa/asound.state ? I believe that's where alsa stores its internal state.

plbossart commented 7 years ago

Just to be clear, the patches I have on my tree are different. I scrapped my initial null reference patches to use the cleaner ones posted on alsa-devel (but never merged somehow).

Velyro commented 7 years ago

@reynhout do you know exactly when the new kernels will be available for download?

On Fri, Aug 18, 2017 at 3:36 PM, Pierre Bossart notifications@github.com wrote:

Just to be clear, the patches I have on my tree are different. I scrapped my initial null reference patches to use the cleaner ones posted on alsa-devel (but never merged somehow).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GalliumOS/galliumos-distro/issues/317#issuecomment-323386880, or mute the thread https://github.com/notifications/unsubscribe-auth/AczACN8uguWbtyFHzgHtNIV9Ca8jg6Fzks5sZa9sgaJpZM4LnT_R .

jeffkub commented 7 years ago

@mildred ahah, I was trying to figure out where that file was. I've noticed that some ALSA settings were persistent across reboots; for a while i had my config messed up to the point that the LPE firmware was returning errors.

I've noticed that not all ALSA settings are in the UCM file... I suspect that those missing would be persistent across reboots. Most likely I have a persistent setting that makes the audio work.

I'll provide my asound.state file when I have access to my CYAN device this evening.

jeffkub commented 7 years ago

@mildred here is my asound.state file

I've found it useful to do a amixer -c2 > amixer.txt to dump all settings specific to the chtmax98090 device. You can do a diff to see what settings have changed. Here is my working configuration

amixer.txt

Unfortunately, I've messed with so many settings that I can't remember exactly what I did.

mildred commented 7 years ago

It just works! Thanks a million. To restore the settings from this state file just run sudo alsactl -f downloaded/asound.state.txt restore 1 where 1 is the card number. The same you can pass to amixer -c1 to see the settings.

For me the chtmax98090 device is the card 1, 0 being the HDMI sound device.

mildred commented 7 years ago

The most meaningful settings that appear changed seem to be:

Note: headphone detection is not working, perhaps due to this last setting.

Here is my asound.state which was probably saved when sound was not working still and the diff asound.state.diff which shows the difference with the working asound.state.

I suppose that booting the machine with the asound.state missing from /var/lib/alsa (be careful that when you shut down the computer, the file is going to be rewritten), it should have default settings.

jeffkub commented 7 years ago

@mildred I was able to reset my alsa settings by following this and deleting the ~/.config/pulse directory. I noticed that the default config had selected the headphone port as the output. I was able to switch to speakers in the audio settings.

reynhout commented 7 years ago

Audio is now working on our CYAN test device! Thanks to everyone for help on this ticket, we are making progress toward a public release. Please help test the new packages on your CYAN!

Updated packages are in the galliumos-testing repository for now. To enable, see https://wiki.galliumos.org/Repositories.

Relevant packages are:

ii  galliumos-braswell           2.0.6             all          GalliumOS Braswell customizations
ii  linux-image-4.12.0-galliumos 4.12.0-galliumos4 amd64        Linux kernel, version 4.12.0-galliumos

Notes, and questions

I ended up keeping the 'Ext HP Switch' labels in chtmax98090.conf, to suppress some ALSA complaints about the device names at startup.

I added some logic in /etc/pulse/default.pa to select the sink and source properly on different Chromebooks. The .ifexists flow control meta command only works on filenames or module names, so I ended up using a sysfs entry for each codec: https://github.com/GalliumOS/galliumos-braswell/blob/82d26eea721f6f643450f3fba5ea3e1d2e0c2e80/etc/pulse/default.pa#L179, e.g.:

.ifexists /sys/devices/platform/808622A8:00/cht-bsw-max98090

This works, but feels like the wrong way to do it. Is there a better way?

Relevant logfile excerpts, and more questions

galliumos% dmesg | grep -e 98090 -e snd -e sound
[   11.096396] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[   11.181702] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1b.0/sound/card1/input7
[   11.181842] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1b.0/sound/card1/input8
[   11.185319] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1b.0/sound/card1/input9
[   11.414670] max98090 i2c-193C9890:00: MAX98090 REVID=0x43
[   11.416181] cht-bsw-max98090 cht-bsw-max98090: snd-soc-dummy-dai <-> media-cpu-dai mapping ok
[   11.416235] cht-bsw-max98090 cht-bsw-max98090: snd-soc-dummy-dai <-> deepbuffer-cpu-dai mapping ok
[   11.416275] compress asoc: snd-soc-dummy-dai <-> compress-cpu-dai mapping ok
[   11.416786] cht-bsw-max98090 cht-bsw-max98090: HiFi <-> ssp2-port mapping ok
[   11.416891] cht-bsw-max98090 cht-bsw-max98090: ASoC: no DMI vendor name!
[   11.418536] input: chtmax98090 Headset Jack as /devices/platform/808622A8:00/cht-bsw-max98090/sound/card2/input10

The "ASoC: no DMI vendor name!" is caused by a missing mapping between the ID and a text label, right?

journalctl -p err | grep pulseaudio
Aug 23 13:06:03 cyan pulseaudio[1066]: [pulseaudio] alsa-ucm.c: Failed to get the verb HiFi
Aug 23 13:06:03 cyan pulseaudio[1066]: [pulseaudio] alsa-ucm.c: No UCM verb is valid for chtmax98090

Are these missing entries in the UCM files?

Both issues seem to be aesthetic, but does anyone know how to fix them?

Thanks again, and please let us all know if you have any issues with the new packages!

Velyro commented 7 years ago

Thanks for this!

On Wed, Aug 23, 2017 at 8:08 PM, reynhout notifications@github.com wrote:

Audio is now working on our CYAN test device! Thanks to everyone for help on this ticket, we are making progress toward a public release. Please help test the new packages on your CYAN!

Updated packages are in the galliumos-testing repository for now. To enable, see https://wiki.galliumos.org/Repositories.

Relevant packages are:

ii galliumos-braswell 2.0.6 all GalliumOS Braswell customizations ii linux-image-4.12.0-galliumos 4.12.0-galliumos4 amd64 Linux kernel, version 4.12.0-galliumos

Notes, and questions

I ended up keeping the 'Ext HP Switch' labels in chtmax98090.conf, to suppress some ALSA complaints about the device names at startup.

I added some logic in /etc/pulse/default.pa to select the sink and source properly on different Chromebooks. The .ifexists flow control meta command only works on filenames or module names, so I ended up using a sysfs entry for each codec: https://github.com/GalliumOS/ galliumos-braswell/blob/82d26eea721f6f643450f3fba5ea3e 1d2e0c2e80/etc/pulse/default.pa#L179, e.g.:

.ifexists /sys/devices/platform/808622A8:00/cht-bsw-max98090

This works, but feels like the wrong way to do it. Is there a better way? Relevant logfile excerpts, and more questions

galliumos% dmesg | grep -e 98090 -e snd -e sound [ 11.096396] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 11.181702] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1b.0/sound/card1/input7 [ 11.181842] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1b.0/sound/card1/input8 [ 11.185319] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1b.0/sound/card1/input9 [ 11.414670] max98090 i2c-193C9890:00: MAX98090 REVID=0x43 [ 11.416181] cht-bsw-max98090 cht-bsw-max98090: snd-soc-dummy-dai <-> media-cpu-dai mapping ok [ 11.416235] cht-bsw-max98090 cht-bsw-max98090: snd-soc-dummy-dai <-> deepbuffer-cpu-dai mapping ok [ 11.416275] compress asoc: snd-soc-dummy-dai <-> compress-cpu-dai mapping ok [ 11.416786] cht-bsw-max98090 cht-bsw-max98090: HiFi <-> ssp2-port mapping ok [ 11.416891] cht-bsw-max98090 cht-bsw-max98090: ASoC: no DMI vendor name! [ 11.418536] input: chtmax98090 Headset Jack as /devices/platform/808622A8:00/cht-bsw-max98090/sound/card2/input10

The "ASoC: no DMI vendor name!" is caused by a missing mapping between the ID and a text label, right?

journalctl -p err | grep pulseaudio Aug 23 13:06:03 cyan pulseaudio[1066]: [pulseaudio] alsa-ucm.c: Failed to get the verb HiFi Aug 23 13:06:03 cyan pulseaudio[1066]: [pulseaudio] alsa-ucm.c: No UCM verb is valid for chtmax98090

Are these missing entries in the UCM files?

Both issues seem to be aesthetic, but does anyone know how to fix them?

Thanks again, and please let us all know if you have any issues with the new packages!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GalliumOS/galliumos-distro/issues/317#issuecomment-324433397, or mute the thread https://github.com/notifications/unsubscribe-auth/AczACEpvt1Uclgm9kNqr6lP-gm-CzDjmks5sbHiegaJpZM4LnT_R .

anorom commented 7 years ago

Thank you! Tested with CYAN - internal speakers working, headphone jack working (no detection, manually switched output device) the internal microphone does not seem to be working though

SanzSeraph commented 7 years ago

Tested with CYAN. Internal speakers are working!

vb216 commented 7 years ago

Great stuff! Updated to galliumos-testing, worked straight out of the box for me

Thanks!!

On 23 August 2017 at 22:34, Daniel Arant notifications@github.com wrote:

Tested with CYAN. Internal speakers are working!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GalliumOS/galliumos-distro/issues/317#issuecomment-324469213, or mute the thread https://github.com/notifications/unsubscribe-auth/AMYRJ7iP5yTC6sRpk72xXPTfGLccSDZeks5sbJr-gaJpZM4LnT_R .

lispykid commented 7 years ago

Just did a quick install and internal speakers worked. Headphones didn't. My Sennheiser USB-Headset was detected as sink but didn't play any audio instead the speaker stayed on. Will do further testing.