Bug 110561 - Macbook8,1 12-inch (Early 2015) No speaker sound output
Summary: Macbook8,1 12-inch (Early 2015) No speaker sound output
Status: REOPENED
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-09 19:11 UTC by Leif Liddy
Modified: 2019-08-28 23:09 UTC (History)
15 users (show)

See Also:
Kernel Version: 4.4.0
Tree: Mainline
Regression: No


Attachments
alsa-info.sh output (38.98 KB, text/plain)
2016-01-09 19:11 UTC, Leif Liddy
Details
alsa-info.sh output (w/ patch comment #3) (38.70 KB, application/octet-stream)
2016-01-13 02:33 UTC, Leif Liddy
Details
image-speakers (155.80 KB, image/jpeg)
2016-01-13 16:18 UTC, Leif Liddy
Details
win-gpio-controls (403.49 KB, image/png)
2016-01-16 02:36 UTC, Leif Liddy
Details
0x1d Pin Configuration (175.95 KB, image/png)
2016-01-16 02:40 UTC, Leif Liddy
Details
cs4208_24.inf (185.84 KB, text/plain)
2016-01-16 17:53 UTC, Leif Liddy
Details
codec-graph (228.34 KB, image/jpeg)
2016-01-24 15:55 UTC, Leif Liddy
Details
alsa-info.sh w/ mba81 patch h/p unplugged (39.93 KB, text/plain)
2016-02-02 23:13 UTC, Leif Liddy
Details
alsa-info.sh w/ mba81 patch h/p plugged in (39.93 KB, text/plain)
2016-02-02 23:17 UTC, Leif Liddy
Details
alsa-info.sh w/ mba81 v2 patch hp unplugged (41.25 KB, text/plain)
2016-02-03 15:37 UTC, Leif Liddy
Details
alsa-info.sh w/ mba81 v2 patch hp plugged-in (41.25 KB, text/plain)
2016-02-03 15:40 UTC, Leif Liddy
Details
alsa-info-macbookair6,1 (for comparison) (47.25 KB, text/plain)
2017-09-29 21:55 UTC, Leif Liddy
Details
macbook9,1 alsa-info.sh (42.73 KB, text/plain)
2017-09-29 21:58 UTC, Leif Liddy
Details
cs4208_27.inf (windows driver) (195.12 KB, text/plain)
2017-09-29 22:50 UTC, Leif Liddy
Details
HDAudio.Cirrus_CONF_0807 (4.14 KB, text/plain)
2017-09-30 00:05 UTC, Leif Liddy
Details
init-verbs and pin-config-overrides (1.86 KB, text/plain)
2017-09-30 23:49 UTC, Leif Liddy
Details
init-verbs and pin-config-overrides v2 (1.95 KB, text/plain)
2017-10-01 15:45 UTC, Leif Liddy
Details
alsa-info.sh (with init verbs + pin config patch) (44.59 KB, text/plain)
2017-10-01 16:26 UTC, Leif Liddy
Details
amixer -c0 output (1.96 KB, text/plain)
2017-10-02 02:35 UTC, Leif Liddy
Details
patch_cirrus.c patch (5.57 KB, patch)
2017-10-19 10:19 UTC, Leif Liddy
Details | Diff
patch_cirrus.c patch v2 (5.82 KB, patch)
2017-10-25 07:34 UTC, Leif Liddy
Details | Diff
window-sound-device-screenshots (165.59 KB, image/png)
2017-10-27 09:39 UTC, Leif Liddy
Details
hda-tool-pin-out (118.02 KB, image/png)
2017-10-27 10:01 UTC, Leif Liddy
Details
hda-verb results Linux + OSX (8.15 KB, text/plain)
2017-10-29 21:00 UTC, Leif Liddy
Details

Description Leif Liddy 2016-01-09 19:11:45 UTC
Created attachment 199111 [details]
alsa-info.sh output

There is no sound output using the internal speakers on the MacBook8,1. Both the internal microphone as well the combined microphone/headphone jack seem to work properly. I've tried passing model={mba6,mba42,auto}to snd-hda-intel, but still no sound. The startup chime does come through the speakers when the laptop is powered on. There are other issues with the Macbook8,1 --the trackpad, keyboard, and bluetooth are not detected. I don't believe those issues would be related to this one though.
Comment 1 Raymond 2016-01-12 02:16:52 UTC
Node 0x1d is digital pin commplex which connected to digital output node 0x0a but driver put it in analog path

You need to use hdajackretask to find out the real speaker pin from those unconnected pin complex 



Node 0x1d [Pin Complex] wcaps 0x406301: 8-Channels Digital 
Pincap 0x00000010: OUT 
Pin Default 0x90100110: [Fixed] Speaker at Int N/A Conn = Unknown, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Misc = NO_PRESENCE 
Pin-ctls: 0x40: OUT 
Connection: 1 0x0a


6.971108] input: HDA Intel HDMI HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:03.0/sound/card0/input7 
[ 6.985493] snd_hda_codec_cirrus hdaudioC1D0: autoconfig for CS4208: line_outs=1 (0x1d/0x0/0x0/0x0/0x0) type:speaker 
[ 6.985496] snd_hda_codec_cirrus hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) 
[ 6.985499] snd_hda_codec_cirrus hdaudioC1D0: hp_outs=1 (0x10/0x0/0x0/0x0/0x0) [ 6.985501] snd_hda_codec_cirrus hdaudioC1D0: mono: mono_out=0x0 
[ 6.985502] snd_hda_codec_cirrus hdaudioC1D0: inputs: 
[ 6.985507] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x19 
[ 6.985511] snd_hda_codec_cirrus hdaudioC1D0: Mic=0x18
Comment 2 Raymond 2016-01-12 02:23:37 UTC
Node 0x10 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Line Out Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x42, nsteps=0x42, stepsize=0x03, mute=1 Amp-Out vals: [0x42 0x42] Pincap 0x0000001c: OUT HP Detect Pin Default 0x002b4020: [Jack] HP Out at Ext N/A Conn = Comb, Color = Green DefAssociation = 0x2, Sequence = 0x0 Pin-ctls: 0xc0: OUT HP Unsolicited: tag=01, enabled=1 Power states: D0 D3 EPSS Power: setting=D3, actual=D3 Connection: 1 0x02 

Node 0x11 [Pin Complex] wcaps 0x400581: Stereo Pincap 0x00000054: OUT Detect Balanced Pin Default 0x400000f0: [N/A] Line Out at Ext N/A Conn = Unknown, Color = Unknown DefAssociation = 0xf, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Power states: D0 D3 EPSS Power: setting=D3, actual=D3 Connection: 1 0x02 

Node 0x12 [Pin Complex] wcaps 0x400501: Stereo Pincap 0x00000050: OUT Balanced Pin Default 0x400000f0: [N/A] Line Out at Ext N/A Conn = Unknown, Color = Unknown DefAssociation = 0xf, Sequence = 0x0 Pin-ctls: 0x00: Power states: D0 D3 EPSS Power: setting=D3, actual=D3 Connection: 1 0x03 

Node 0x13 [Pin Complex] wcaps 0x400501: Stereo Pincap 0x00000050: OUT Balanced Pin Default 0x400000f0: [N/A] Line Out at Ext N/A Conn = Unknown, Color = Unknown DefAssociation = 0xf, Sequence = 0x0 Pin-ctls: 0x00: Power states: D0 D3 EPSS Power: setting=D3, actual=D3 Connection: 1 0x04 

Node 0x14 [Pin Complex] wcaps 0x400501: Stereo Pincap 0x00000050: OUT Balanced Pin Default 0x400000f0: [N/A] Line Out at Ext N/A Conn = Unknown, Color = Unknown DefAssociation = 0xf, Sequence = 0x0 Pin-ctls: 0x00: Power states: D0 D3 EPSS Power: setting=D3, actual=D3 Connection: 1 0x05
Comment 3 Raymond 2016-01-12 07:46:32 UTC
			if (cfg->speaker_outs >= ARRAY_SIZE(cfg->speaker_pins)) {
				codec_info(codec,
					   "ignore pin 0x%x, too many assigned pins\n",
					   nid);
				continue;
			}
+			if (get_wcaps(codec, nid) & AC_WCAP_DIGITAL) {
+				codec_info(codec, "ignore pin 0x%x, digital wcaps\n", nid);
+				continue;
+			}
			speaker_out[cfg->speaker_outs].pin = nid;
			speaker_out[cfg->speaker_outs].seq = (assoc << 4) | seq;
			cfg->speaker_outs++;
			break;
Comment 4 Leif Liddy 2016-01-13 02:30:41 UTC
I've added your patch, and have posted the output of alsa-info.sh (without having configured any unconnected pins). I've tried a few different combinations of configuring the unconnected pins, but with no success. I need to know what the best practices are when using hdajackretask. I've gone one by one, from pin 0x10 to 0x14 and clicking override, selecting internal speaker {default, LFE, back}, installing boot override and rebooting. Setting some pins will disable the internal speaker completely (according to pulse audio). I've also tried selecting internal speaker for all 3,4, and 5 different pins at the same time. I could use some direction though. Let me know what configurations/logs you would find the most useful.
Comment 5 Leif Liddy 2016-01-13 02:33:24 UTC
Created attachment 199481 [details]
alsa-info.sh output (w/ patch comment #3)
Comment 6 Raymond 2016-01-13 04:05:54 UTC
seem segfault in your system log

[  572.640000] do not call blocking ops when !TASK_RUNNING; state=2 set at [<ffffffff810fc960>] prepare_to_wait_event 0x60/0xf0
[  572.640003] Modules linked in: intel_rapl iosf_mbi x86_pkg_temp_thermal nls_utf8 coretemp hfsplus iTCO_wdt kvm_intel iTCO_vendor_support kvm irqbypass crct10dif_pclmul crc32_pclmul applesmc input_polldev joydev brcmfmac brcmutil cfg80211 snd_hda_codec_cirrus snd_hda_codec_generic snd_hda_codec_hdmi mmc_core pcspkr i2c_i801 rfkill intel_pch_thermal snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep sbs sbshc snd_seq acpi_als snd_seq_device kfifo_buf industrialio snd_pcm mei_me spi_pxa2xx_platform apple_bl mei snd_timer snd lpc_ich tpm_tis soundcore tpm shpchp btrfs xor raid6_pq r8152 mii i915 crc32c_intel i2c_algo_bit drm_kms_helper nvme drm video fjes
[  572.640099] CPU: 3 PID: 794 Comm: wpa_supplicant Tainted: G        W       4.4.0-macbook.fc23.x86_64 #1




The patch only ignore the incorrect digital pin node 0x10 from the analog path

how many speakers do you have since there are four [Audio Output] ?

Try node 0x12, 0x13 or 0x14 since node 0x11 share volume control [Audio Output] 0x02 with headphone
Comment 7 Raymond 2016-01-13 05:19:49 UTC
You can use hdajacksensetest to verify node 0x10 is headphone when you olug and unplug the headphone
Comment 8 Raymond 2016-01-13 15:56:57 UTC
Node 0x02 [Audio Output] wcaps 0xd043d: Stereo Amp-Out Stripe Control: name="Line Out Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Device: name="CS4208 Analog", type="Audio", device=0 Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x01, mute=1 Amp-Out vals: [0x7f 0x7f] Converter: stream=5, channel=0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1e]: 16 20 24 32 formats [0x3]: PCM FLOAT Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Delay: 13 samples

 Node 0x03 [Audio Output] wcaps 0xd043d: Stereo Amp-Out Stripe Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x01, mute=1 Amp-Out vals: [0xff 0xff] Converter: stream=0, channel=0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1e]: 16 20 24 32 formats [0x3]: PCM FLOAT Power states: D0 D3 EPSS Power: setting=D3, actual=D3 Delay: 13 samples

 Node 0x04 [Audio Output] wcaps 0xd043d: Stereo Amp-Out Stripe Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x01, mute=1 Amp-Out vals: [0xff 0xff] Converter: stream=0, channel=0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1e]: 16 20 24 32 formats [0x3]: PCM FLOAT Power states: D0 D3 EPSS Power: setting=D3, actual=D3 Delay: 13 samples

 Node 0x05 [Audio Output] wcaps 0xd043d: Stereo Amp-Out Stripe Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x01, mute=1 Amp-Out vals: [0xff 0xff] Converter: stream=0, channel=0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1e]: 16 20 24 32 formats [0x3]: PCM FLOAT Power states: D0 D3 EPSS Power: setting=D3, actual=D3 Delay: 13 samples
Comment 9 Leif Liddy 2016-01-13 16:18:13 UTC
Created attachment 199531 [details]
image-speakers

I'll perform some more testing when I get home. In the meantime, I've found an image of the speakers in this laptop.
Comment 10 Leif Liddy 2016-01-13 18:29:50 UTC
0x10 is definitely the headphone jack.  I've tried setting 0x12, 0x13 or 0x14 and other various combinations. I've made sure every source was unmuted in alsamixer. 
Is there a way to set 0x02, 0x03, 0x04, and 0x05? I don't see those with hdajackretask. I could always reinstall OSX on the laptop if it would help us gather any useful information regarding the audio configuration.
Comment 11 Takashi Iwai 2016-01-13 19:12:32 UTC
You likely need to pass a proper pin configuration *in addition* to GPIO0 workaround.

BTW, how did you try model option?  Since Cirrus codec is the secondary one, you'd have to pass like "model=,mba6" -- note the comma before "mba6".
For CS4208, you can try either mba6, mbp11 or gpio0 model.

If any or them are really not working, keep "model=,gpio0" and try to figure out the pin configuration.
Comment 12 Leif Liddy 2016-01-13 20:15:46 UTC
I'll try start trying now. Can't I just pass index=1 to reference the 2nd card?
Comment 13 Takashi Iwai 2016-01-13 20:34:08 UTC
Yes it would work, too.
Comment 14 Leif Liddy 2016-01-13 20:52:33 UTC
I see the difference --if I use index=1, it changes the PCH device to card 0. 
I'll stick with your method to keep the order consistent.
Comment 15 Leif Liddy 2016-01-13 21:34:13 UTC
I've tried model=,mba6 and model=,mbp11. With model=,gpio0 I'm a bit out of my depth. Can you just give me a basic run down of how to set a pin configuration?
Comment 16 Leif Liddy 2016-01-13 21:47:24 UTC
I figured it out....
Comment 17 Leif Liddy 2016-01-13 23:32:48 UTC
It looks like 0x12 is definitely a speaker. The default value 0x90170150 for internal speaker doesn't work. I just need to find the right value to modify user_pin_configs with. Based on what I've seen in patch_cirrus.c --the value I'm looking for should be 0x90100010XXX
Comment 18 Raymond 2016-01-14 09:35:19 UTC
Bit 8 of pin default should be set as internal speaker does not support Jack detection

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/patch_cirrus.c?id=b5bf0a929d7ca35b9ccfc24647a397899d307659
Comment 19 Leif Liddy 2016-01-16 02:36:21 UTC
Created attachment 199771 [details]
win-gpio-controls

After I modified user_pin_configs, I tried echo 1 > reconfig to get the configuration to take --but I always receive the message "echo: write error: Device or resource busy". I've tried disabling pulseaudio, running alsactl nrestore...etc --but to no avail. I could use some advice on how to do this. In the meantime, I've loaded windows on the laptop, and have run High Definition Audio tool. Windows shows the playback device as "Digital Speaker Amplifier". I'm uploading a couple screenshots from the audio tool. If you have used this tool before, let me know what information you would find most useful.
Comment 20 Leif Liddy 2016-01-16 02:40:02 UTC
Created attachment 199781 [details]
0x1d Pin Configuration

device 0x1d is apparently used as the output device.
Comment 21 Leif Liddy 2016-01-16 17:53:13 UTC
Created attachment 199841 [details]
cs4208_24.inf

This is the windows driver file. 
Not sure if this is important, but both playback devices (headphones + digital speaker amplifier) show that they are of device type Cirrus Logic CS4208 (AB 100)
Comment 22 Raymond 2016-01-17 02:43:27 UTC
Use "set as boot default" instead of dynamic reconfigurstion since you have top stop all applications to use the sound card, e.g. disable pulseaudio auto spwan


Codec: Cirrus Logic CS4208 
Address: 0 
AFG Function Id: 0x1 (unsol 1) 
Vendor Id: 0x10134208 
Subsystem Id: 0x106b6400 
Revision Id: 0x100401

Using hda emu to compare those verbs used by alsa driver and windows
Comment 23 Leif Liddy 2016-01-24 15:55:51 UTC
Created attachment 201311 [details]
codec-graph

I've posted the output of codecgraph

# ./codecgraph /proc/asound/card1/codec#0 
Codec: Cirrus Logic CS4208
Node 0x06: Amp-In vals count is wrong: values found: 3. expected: 1
Node 0x07: Amp-In vals count is wrong: values found: 3. expected: 1
Comment 24 Takashi Iwai 2016-02-02 20:51:15 UTC
If NID 0x12 is the speaker, the firmware patch below may work.

Crrete a file /lib/firmware/alsa/mb81 containing the following:

[codec]
0x10134208 0x106b6400 0

[pincfg]
0x10 0x002b4020
0x12 0x90100120
0x18 0x00ab9030
0x19 0x90a60100

# [hint]
# inv_jack_detect = true


Then pass it via patch module option, e.g. put the following to /etc/modprobe.d/50-alsa-hda.conf containing:

options snd-hda-intel patch=,alsa/mb81

Note that the comma before "alsa/mb81".  It means the secondary card entry.

You may notice that the last two lines of the firmware patch are commented out.
In case the jack detection is inverted, try to enable these lines.

If the above still doesn't work, take alsa-info.sh output at the headphone plugged and unplugged states, and upload to Bugzilla for further analysis.
Comment 25 Leif Liddy 2016-02-02 23:13:49 UTC
Created attachment 202791 [details]
alsa-info.sh w/ mba81 patch h/p unplugged

alas-info.sh output w/ mba81 firmware patch. Headphones unplugged. 
No sound from speakers. **didn't need to apply inverse_jack_detect.
Comment 26 Leif Liddy 2016-02-02 23:17:15 UTC
Created attachment 202801 [details]
alsa-info.sh w/ mba81 patch h/p plugged in

alas-info.sh output w/ mba81 firmware patch. Headphones plugged in and audio is coming through.
Comment 27 Raymond 2016-02-03 03:48:42 UTC
You need to fixup node 0x1d,  hda_auto_parser place digial pin in analog path 



Node 0x0a [Audio Output] wcaps 0x46631: 8-Channels Digital Stripe 
Device: name="CS4208 Analog", type="Audio", device=0 Converter: stream=5, channel=0 Digital: Enabled Non-Copyright 
Digital category: 0x1 
IEC Coding Type: 0x0 
PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM 
Power states: D0 D3 EPSS 
Power: setting=D0, actual=D0 
Delay: 4 samples

Node 0x1d [Pin Complex] wcaps 0x406301: 8-Channels Digital 
Pincap 0x00000010: OUT 
Pin Default 0x90100110: [Fixed] Speaker at Int N/A Conn = Unknown, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Misc = NO_PRESENCE 
Pin-ctls: 0x40: OUT 
Connection: 1 0x0a
Comment 28 Raymond 2016-02-03 03:52:05 UTC
snd_hda_codec_cirrus hdaudioC1D0: autoconfig for CS4208: line_outs=2 (0x1d/0x12/0x0/0x0/0x0) type:speaker 
snd_hda_codec_cirrus hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
snd_hda_codec_cirrus hdaudioC1D0: hp_outs=1 (0x10/0x0/0x0/0x0/0x0) 
snd_hda_codec_cirrus hdaudioC1D0: mono: mono_out=0x0
snd_hda_codec_cirrus hdaudioC1D0: inputs: 
snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x19
snd_hda_codec_cirrus hdaudioC1D0: Mic=0x18
Comment 29 Takashi Iwai 2016-02-03 08:17:04 UTC
Right, it was missing.  Judging from alsa-info.sh output, the HP jack sensing looks working normally.  So inv_jack_detect things can be dropped.  So it'll be like:

[codec]
0x10134208 0x106b6400 0

[pincfg]
0x10 0x002b4020
0x12 0x90100120
0x18 0x00ab9030
0x19 0x90a60100
0x1d 0x400000f0

If this still doesn't work, please give alsa-info.sh outputs again at both HP plugged and unplugged.
Comment 30 Leif Liddy 2016-02-03 15:37:30 UTC
Created attachment 202811 [details]
alsa-info.sh w/ mba81 v2 patch hp unplugged

alsa-info.sh
*no audio internal speakers
Comment 31 Leif Liddy 2016-02-03 15:40:31 UTC
Created attachment 202821 [details]
alsa-info.sh w/ mba81 v2 patch hp plugged-in

alsa-info.sh
*headphone audio working
Comment 32 derarnold 2016-04-17 12:10:01 UTC
Hello hello.

I just tested with 4.6rc3 on a ubuntu 16.04 an the issue is still there :( What is surprising is that the sound in (MIC) is working fine!

If I can help with traces. Pls let me know

derarnold

P.s. Perhaps it is an ALSA issue and not a kernel issue ...
Comment 33 Leif Liddy 2017-09-29 21:55:49 UTC
Created attachment 258651 [details]
alsa-info-macbookair6,1 (for comparison)
Comment 34 Leif Liddy 2017-09-29 21:58:39 UTC
Created attachment 258653 [details]
macbook9,1 alsa-info.sh

macbook9,1 (2016) model
Comment 35 Leif Liddy 2017-09-29 22:09:09 UTC
the macbookair6,1 and 6,2 has a really similar config to that of the macbook8,1 + 9,1

this shows what the init pin config of the macbookair6,1 looks like, compared to that which the patch_cirrus driver has modified. 

init_pin_configs	modified (driver) pin_configs	
0x10 0x002b4020		0x10 0x032120f0	  #stereo Amp-Out      #HP  
0x11 0x400000f0		0x11 0x500000f0   #stereo 
0x12 0x90100110		0x12 0x90100010   #stereo              #Speaker
0x13 0x400000f0		0x13 0x500000f0	  #stereo
0x14 0x400000f0		0x14 0x500000f0	  #stereo
0x15 0x400000f0		0x15 0x770000f0	  #Stereo Amp-In
0x16 0x400000f0		0x16 0x770000f0	  #Stereo Amp-In
0x17 0x400000f0		0x17 0x430000f0   #Stereo Amp-In
0x18 0x00ab9030		0x18 0x43ab9030   #Mono Amp-In
0x19 0x400000f0		0x19 0x770000f0   #Stereo Amp-In
0x1a 0x400000f0		0x1a 0x770000f0   #Stereo Amp-In
0x1b 0x400000f0		0x1b 0x770000f0   #Stereo Amp-In
0x1c 0x90a60100		0x1c 0x90a00090   #Stereo Amp-In       #Int Mic
0x1d 0x400000f0		0x1d 0x500000f0   #8-Channels Digital
0x1e 0x400000f0		0x1e 0x500000f0   #8-Channels Digital
0x1f 0x400000f0		0x1f 0x500000f0   #8-Channels Digital
0x20 0x400000f0		0x20 0x500000f0   #8-Channels Digital
0x21 0x400000f0		0x21 0x430000f0   #Stereo Digital
0x22 0x400000f0		0x22 0x430000f0   #Stereo Digital

Pin-ctrls:
HP:       0xc0
Speaker:  0x40
Int Mic:  0x20
Comment 36 Leif Liddy 2017-09-29 22:18:28 UTC
this is that the default config looks like for the macbook9,1

0x10 0x002b4020		#stereo amp-out        #HP
0x11 0x400000f0		#stereo 
0x12 0x400000f0		#stereo 
0x13 0x400000f0		#stereo 
0x14 0x400000f0		#stereo 
0x15 0x400000f0		#stereo Amp-In
0x16 0x400000f0		#stereo Amp-In
0x17 0x400000f0		#stereo Amp-In
0x18 0x00ab9030		#mono Amp-In          #Mic Jack
0x19 0x90a60100		#Stereo Amp-In        #internal Mic
0x1a 0x400000f0		#stereo Amp-In
0x1b 0x400000f0		#stereo Amp-In
0x1c 0x400000f0		#stereo Amp-In
0x1d 0x90100110		#8-Channels Digital   #speaker
0x1e 0x400000f0		#8-Channels Digital
0x1f 0x400000f0		#8-Channels Digital
0x20 0x400000f0		#8-Channels Digital
0x21 0x400000f0		#stereo digital
0x22 0x400000f0		#stereo digital


Pin-ctrls:
HP:       0xc0
Speaker:  0x40
Mic Jack: 0x24
Int Mic:  0x20
Comment 37 Leif Liddy 2017-09-29 22:43:08 UTC
on the macbook9,1 headphone output works, microphone works. Just need to get the speakers to work. 

this is current I'm trying out (modifying patch_cirrus and rebooting). Aside from a few minor touch ups, the main change is assigning 0x12 the speaker role. 

0x10 0x042b20f0   #stereo amp-out        #HP
0x11 0x500000f0   #stereo
0x12 0x90100010   #stereo                #speaker
0x13 0x500000f0   #stereo
0x14 0x500000f0   #stereo
0x15 0x770000f0   #stereo Amp-In
0x16 0x770000f0   #stereo Amp-In
0x17 0x430000f0   #stereo Amp-In
0x18 0x04ab2050   #mono Amp-In          #Mic Jack
0x19 0x90a00070   #stereo Amp-In        #internal Mic
0x1a 0x770000f0   #stereo Amp-In
0x1b 0x770000f0   #stereo Amp-In
0x1c 0x770000f0   #stereo Amp-In
0x1d 0x500000f0   #8-Channels Digital
0x1e 0x500000f0   #8-Channels Digital
0x1f 0x500000f0   #8-Channels Digital
0x20 0x500000f0   #8-Channels Digital
0x21 0x430000f0   #stereo digital
0x22 0x430000f0   #stereo digital

However, 0x1d is still using pin-ctrl 0x40
So, I've run these commands to assign 0x12 pin-ctrl 0x40

hda-verb /dev/snd/hwC0D0 0x1d SET_PIN_WIDGET_CONTROL 0
hda-verb /dev/snd/hwC0D0 0x12 SET_PIN_WIDGET_CONTROL 0x40 

the issue is that 0x12 has transitioned to a D0 power state with this config:

Node 0x12 [Pin Complex] wcaps 0x400501: Stereo
  Pincap 0x00000050: OUT Balanced
  Pin Default 0x400000f0: [N/A] Line Out at Ext N/A
    Conn = Unknown, Color = Unknown
    DefAssociation = 0xf, Sequence = 0x0
  Pin-ctls: 0x40: OUT
  Power states:  D0 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 1
     0x03

Does anyone know how I can power on 0x12?
Comment 38 Leif Liddy 2017-09-29 22:50:52 UTC
Created attachment 258655 [details]
cs4208_27.inf (windows driver)

**in case anybody understands how to read this

macbook8,1
HdAudioFunctionDriver.CS4208_106B6400.DeviceDesc = "Cirrus Logic CS4208 (AB 100)"

macbook9,1
HdAudioFunctionDriver.CS4208_106B6500.DeviceDesc = "Cirrus Logic CS4208 (AB 101)"
Comment 39 Leif Liddy 2017-09-30 00:05:26 UTC
Created attachment 258657 [details]
HDAudio.Cirrus_CONF_0807

The macbook9,1 (and 8,1) uses the HDAudio.Cirrus_CONF_0807 configuration. I've extracted the CONF_0807 configuration bits from inf file, so you don't have to trawl through it. Even, thought the macbook9,1 and macbookair6.x uses the same codec, a Cirrus Logic CS4208, the underlying configuration is quite different.

this document lists the initverbs, pinconfig override verbs...etc
what's odd, is this document references an SpdifOut, but this macbook doesn't have an physical spdif port as part of the headphone jack. so, it must be using that internally. If anyone can help decode this document, it would be extremely helpful. Even if it's something as simple as explaining what TDMQuadTopo means.
Comment 40 Leif Liddy 2017-09-30 23:31:29 UTC
I've used the HDA audio tool on windows to analyze the configuration in a bit more in depth. This is the exact pin configuration windows uses:

0x10 0x042b20f0  #stereo amp-out        #HP jack
0x11 0x500000f0  #stereo
0x12 0x500000f0  #stereo
0x13 0x500000f0  #stereo
0x14 0x500000f0  #stereo
0x15 0x770000f0  #stereo Amp-In
0x16 0x770000f0  #stereo Amp-In
0x17 0x430000f0  #stereo Amp-In
0x18 0x04ab2050  #mono Amp-In          #Mic Jack
0x19 0x90a00070  #stereo Amp-In        #internal Mic
0x1a 0x770000f0  #stereo Amp-In        
0x1b 0x770000f0  #stereo Amp-In
0x1c 0x770000f0  #stereo Amp-In
0x1d 0x90400010  #8-Channels Digital   #digital speaker amplifier
0x1e 0x500000f0  #8-Channels Digital
0x1f 0x500000f0  #8-Channels Digital
0x20 0x500000f0  #8-Channels Digital
0x21 0x430000f0  #stereo digital
0x22 0x430000f0  #stereo digital


**windows shows the output device as a 'Digital Speaker Amplifier', the volume control is marked as digital output/spdif

**in Linux (with this pin configuration), the analog speaker output is seen as unplugged. I believe the digital stereo (IEC958) output profile needs to be used with this setup. 

alsamixer shows 7 SPDIF items:
S/PDIF
S/PDIF Default PCM
S/PDIF 1
S/PDIF 2
S/PDIF 3
S/PDIF 4
S/PDIF 16

has anyone else come across an all digital audio setup like this before? 

**I would like to test with just ALSA, however it seems that ALSA is dependent upon pulseaudio running.
Comment 41 Leif Liddy 2017-09-30 23:49:56 UTC
Created attachment 258677 [details]
init-verbs and pin-config-overrides

I've translated the init verbs and pin-config-overrides to hda-verb commands. I just kind of worked out of to translate the values in the windows registry --based on the values I saw in patch_cirrus.c. It's possible I made some mistakes...

**the most interesting lines are:

#CIR=04h, coeff=0C04h (TX1 ch 0: slot  4, ch 1: slot 12)
hda-verb /dev/snd/hwC0D0 0X24 0X500 0X04 
hda-verb /dev/snd/hwC0D0 0X24 0X40C 0X04

#CIR=05h, coeff=1000h (TX1 ch 2: slot  0, ch 3: slot 16)
hda-verb /dev/snd/hwC0D0 0X24 0X500 0X05
hda-verb /dev/snd/hwC0D0 0X24 0X410 0X00

#TX1: ASSN=1h, SEQ=0h COL=unkn DD=SPDO, CTYP=unkn PCON=fixed, LOC=int
hda-verb /dev/snd/hwC0D0 0x1d 0x71c 0x10 
hda-verb /dev/snd/hwC0D0 0x1d 0x71d 0x00
hda-verb /dev/snd/hwC0D0 0x1d 0x71e 0x40
hda-verb /dev/snd/hwC0D0 0x1d 0x71f 0x90
Comment 42 Leif Liddy 2017-09-30 23:54:30 UTC
**not sure how to translate the GPIO values
Gpio0ExtAmpCfg,	0A,00,00,01  #GPIO0 is an output controlled by TX1 PS-Set
Gpio4ExtAmpCfg,	01,00,00,01  #GPIO4 is an output controlled by AFG PS-Set (to HS3 DFET)
Gpio5ExtAmpCfg  01,00,00,01   #GPIO5 is an output controlled by AFG PS-Set (to HS4 DFET)

**although, I don't think anything needs to been done GPIO0, that fixup already exists in patch_cirrus.c

The (windows) HDA audio tool did show a gpio mask and dir values of 0x31

hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x31
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x31
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0
Comment 43 Leif Liddy 2017-10-01 15:45:07 UTC
Created attachment 258681 [details]
init-verbs and pin-config-overrides v2

**fixed errors with AC_VERB_SET_PROC_COEF values.
Comment 44 Leif Liddy 2017-10-01 15:52:55 UTC
static const struct hda_verb cs4208_coef_init_verbs[] = {
        {0x01, AC_VERB_SET_POWER_STATE, 0x00}, /* AFG: D0 */
        {0x24, AC_VERB_SET_PROC_STATE, 0x01},  /* VPW: processing on */
        {0x24, AC_VERB_SET_COEF_INDEX, 0x0000},
        {0x24, AC_VERB_SET_PROC_COEF, 0x0080}, //SPCC = 10b, SP1M = 0b//
        {0x24, AC_VERB_SET_COEF_INDEX, 0x0004},
        {0x24, AC_VERB_SET_PROC_COEF, 0x0C04}, /*TX1 ch0: slot4, ch1: slot12 */
        {0x24, AC_VERB_SET_COEF_INDEX, 0x0005},
        {0x24, AC_VERB_SET_PROC_COEF, 0x1000}, /*TX1 ch2: slot0, ch3: slot16 */
        {0x24, AC_VERB_SET_COEF_INDEX, 0x001D},
        {0x24, AC_VERB_SET_PROC_COEF, 0x0BF6}, //DC detect level = 36h//
        {0x24, AC_VERB_SET_COEF_INDEX, 0x0033},
        {0x24, AC_VERB_SET_PROC_COEF, 0x4493}, //A/CGat, A2/CInv, A1/A2/C ICS//
        {0x24, AC_VERB_SET_COEF_INDEX, 0x0034},
        {0x24, AC_VERB_SET_PROC_COEF, 0x1B13}, /* A1 Enable, A Thresh=250mV */
        {0x24, AC_VERB_SET_COEF_INDEX, 0x0050},
        {0x24, AC_VERB_SET_PROC_COEF, 0x008B}, //jack sense hysteresis //
        {0x24, AC_VERB_SET_COEF_INDEX, 0x0040},
        {0x24, AC_VERB_SET_PROC_COEF, 0x9999}, //VPW: test mode on//
        {} /* terminator */
};

I've modified this data structure in patch_cirrus.c to use the init verbs found in the windows driver. I could use some guidance at this point. I think I'm on the right path, but it hard to know for sure, since the sound still isn't working.
Comment 45 Leif Liddy 2017-10-01 16:09:42 UTC
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x31
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x31
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0

#running these commands enables GPIO4 + 5 "comment 42"

GPIO: io=6, o=2, i=0, unsolicited=1, wake=1
  IO[0]: enable=1, dir=1, wake=0, sticky=0, data=0, unsol=0
  IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
  IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
  IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
  IO[4]: enable=1, dir=1, wake=0, sticky=0, data=0, unsol=0
  IO[5]: enable=1, dir=1, wake=0, sticky=0, data=0, unsol=0
Comment 46 Leif Liddy 2017-10-01 16:26:56 UTC
Created attachment 258687 [details]
alsa-info.sh (with init verbs + pin config patch)

This is the alsa-info.sh output using the pin configs from "comment 40", the cs4208_coef_init_verbs from "comment 44", and the hda-verb commands from "comment 42" 

**I think we may have a SPDIF (IEC958) mixing issue. 
node 0x0a is the DAC audio output that feeds node 0x1d "digital amplifier?" 
there may be something off with the way the audio is being routed

there are some definite improvements:

original alsa-info.sh:

 Node 0x0a [Audio Output] wcaps 0x46631: 8-Channels Digital Stripe
  Converter: stream=5, channel=0
  Digital: Enabled Non-Copyright
  Digital category: 0x1
  IEC Coding Type: 0x0
  PCM:
    rates [0x60]: 44100 48000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D3 EPSS
  Power: setting=D0, actual=D0
  Delay: 4 samples

new alsa-info.sh:

Node 0x0a [Audio Output] wcaps 0x46631: 8-Channels Digital Stripe
  Control: name="IEC958 Playback Con Mask", index=16, device=0
  Control: name="IEC958 Playback Pro Mask", index=16, device=0
  Control: name="IEC958 Playback Default", index=16, device=0
  Control: name="IEC958 Playback Switch", index=16, device=0
  Control: name="IEC958 Default PCM Playback Switch", index=0, device=0
  Device: name="CS4208 Digital", type="SPDIF", device=1
  Converter: stream=1, channel=0
  Digital: Enabled GenLevel
  Digital category: 0x2
  IEC Coding Type: 0x0
  PCM:
    rates [0x60]: 44100 48000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D3 EPSS
  Power: setting=D0, actual=D0
  Delay: 4 samples
Comment 47 Leif Liddy 2017-10-01 19:34:57 UTC
the (windows) hda audio tool shows that:
Node 0x0a has a wcaps value of 0x42631
while Linux reports a value of 0x46631

**this is the only wcaps value that differs

If I'm understand this correctly, the difference is that a wcaps value of  0x42631 indicates a channel count value of 0x4 while a wcaps value of 0x46631 indicates a channel count value of 0x8

That seems a bit odd to say the least, I'd like to change this value in Linux but have no idea how to do it. Does anyone have any ideas?
Comment 48 Leif Liddy 2017-10-01 21:06:49 UTC
[root@mac ~]# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: CS4208 Analog [CS4208 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 1: CS4208 Digital [CS4208 Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
...
Comment 49 Leif Liddy 2017-10-02 02:35:53 UTC
Created attachment 258691 [details]
amixer -c0 output

amixer -c0 output
shows 7 seperate mixer controls for IEC958
Comment 50 Leif Liddy 2017-10-02 04:00:25 UTC
HKR,cs420x,n0AWidgetCaps    0x00042631  ; TX1: override widget caps: CCE=1
HKR,cs420x,n0ASuppBitsRates 0x000E0040	; TX1: override rate caps: -R6

Regarding the Node 0x0a wcaps issue, I found these two lines in the windows driver file. Can someone tell me how to perform the equivalent operation with Linux?
Comment 51 Leif Liddy 2017-10-02 23:51:23 UTC
I added this code to patch_cirrus.c to override the wcaps value for node 0x0a and set it to 0x42631 (271921 decimal)

        chans = get_wcaps(codec, 0x0a);
        chans = get_wcaps_channels(chans);
        printk("0x0a chans is %u\n", chans);

        snd_hda_override_wcaps(codec, 0x0a, 271921);
        printk("0x0a wcaps is %u\n", get_wcaps(codec, 0x0a));

        chans = get_wcaps(codec, 0x0a);
        chans = get_wcaps_channels(chans);
        printk("0x0a chans is %u\n", chans);

dmesg shows that it did change the wcaps value and the channel count did change from 8 to 4, exactly what I wanted it to do!

[    5.874826] 0x0a chans is 8
[    5.874827] 0x0a wcaps is 271921
[    5.874827] 0x0a chans is 4

However, when I cat out codec#0, I find the original wcaps value:

# cat /proc/asound/card0/codec#0 | grep 'Node 0x0a'
Node 0x0a [Audio Output] wcaps 0x46631: 8-Channels Digital Stripe


There are existing wcap override statements in patch_cirrus.c, such as:
        snd_hda_override_wcaps(codec, 0x18,
                               get_wcaps(codec, 0x18) | AC_WCAP_STEREO);


/proc/asound/card0/codec#0 does not show the modified wcaps value for 0x18.

So either 'snd_hda_override_wcaps' doesn't work or /proc/asound/card0/codec#0 doesn't show modified wcaps values.
Comment 52 Leif Liddy 2017-10-03 01:25:08 UTC
It doesn't looks like 'snd_hda_override_wcaps' works correctly (or I'm using it wrong). 

# hda-verb /dev/snd/hwC0D0 0x0a 0xf00 0x09
nid = 0xa, verb = 0xf00, param = 0x9
value = 0x46631
Comment 53 Takashi Iwai 2017-10-04 13:17:23 UTC
The function changes the cached value in the driver and doesn't actually change the value read from the codec (you can't change -- it's a read-only).  That's why the value shown in the proc file doesn't change after overriding it.
Comment 54 Leif Liddy 2017-10-19 10:19:20 UTC
Created attachment 260291 [details]
patch_cirrus.c patch

this is a work-in-progress patch. It contains the correct pin configuration, gpio mask, and wcaps value for node 0x0a. I've also overridden cs4208_coef_init_verbs to match the init verbs listed in the windows driver.
Comment 55 Leif Liddy 2017-10-19 10:43:53 UTC
I need to sort out how to do the following:
the windows driver contains this line:
HKR,cs420x,n0ASuppBitsRates,%REG_DWORD%, 0x000E0040; TX1: override rate caps: -R6

**what is means is that node 0x0a only supports PCM rates of 48000

The value linux has is 0xe0060

hda-verb /dev/snd/hwC0D0 0x0a 0xf00 0xa
nid = 0xa, verb = 0xf00, param = 0xa
value = 0xe0060


** 0xe0060 corresponds to PCM rates: 44100 and 48000


Node 0x0a 
....
  PCM:
    rates [0x60]: 44100 48000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM

Does anyone know how I can set the supported PCM rate to 48000?
Comment 56 Takashi Iwai 2017-10-19 10:49:12 UTC
Instead of fiddling with the PCM capability bits override, you can limit the rates to be used by overriding the PCM rates bits in hda_pcm_stream definition.
See alc269_fixup_pcm_44k() in patch_realtek.c as an example.
Comment 57 Leif Liddy 2017-10-19 11:18:28 UTC
thanks! I'll check it out.
Comment 58 Leif Liddy 2017-10-19 11:18:49 UTC
If you look at the patch I've just posted, you'll see the following init verbs:

{0x24, AC_VERB_SET_COEF_INDEX, 0x0004},
{0x24, AC_VERB_SET_PROC_COEF, 0x0C04}, /*TX1 ch 0: slot  4, ch 1: slot 12 */
{0x24, AC_VERB_SET_COEF_INDEX, 0x0005},
{0x24, AC_VERB_SET_PROC_COEF, 0x1000}, /*TX1 ch 2: slot  0, ch 3: slot 16 */

TX1 --corresponds to node 0x1d, which is the digital speaker amplifier.

the following is found in in the windows driver:
;; Set default format to 48kHz, 24-bit, Quad
...
HKLM,"Software\\Cirrus\\APO\\FilterAPO","APOProcessMode",0x00010001,0x2		; quad (FL/FR - woofers, RL/RR - tweeters)

I'm guessing each TX1 channel listed above: 0,1,2,3 corresponds to one of these four speakers: FL/FR and RL/RR. 

**perhaps, this is why the channel count was changed to 4 for node 0x0a, see comment 51

**node 0x0a is the DAC audio output that feeds node 0x1d

I'm not sure how these init verbs are supposed to function, or how to verify they are working correctly. Shouldn't these init verbs bring these speakers online, what else needs to be done? 

It doesn't look like the mixer controls are set up properly for this configuration. 

the audio needs to be routed through card 0, device 1
card 0: PCH [HDA Intel PCH], device 1: CS4208 Digital [CS4208 Digital]

I have no idea on how adjust the mixer controls, and I'm a bit out of my depth here, if anyone has any ideas --please share them.
Comment 59 Leif Liddy 2017-10-23 07:18:05 UTC
Not sure if this is significant or not, but windows returns a different response then linux to the F0D verb (S/PDIF Converter Control)

windows:
0x00800215

linux:
0x111

the main differences are that windows has the VCFG (validity config) and KAE (keep alive enable) bits enabled. 

Does anyone know how I could enable these bits in Linux (or perform an equivalent operation)?
Comment 60 Leif Liddy 2017-10-23 08:36:04 UTC
..I sorted out how to change those bits:

hda-verb /dev/snd/hwC0D0 0x0a 0x70d 0x15
hda-verb /dev/snd/hwC0D0 0x0a 0x73e 0x80
Comment 61 Leif Liddy 2017-10-25 07:20:36 UTC
**simple method to cycle through all 64 coefficient indexes and retrieve the processing coefficient values. 

#!/bin/bash

cmd='hda-verb /dev/snd/hwC0D0 0x24'
$cmd SET_COEF_INDEX 0x0 &> /dev/null
while true; do
  index=$($cmd GET_COEF_INDEX 0 2>/dev/null | sed 's/value/index/')
  value=$($cmd GET_PROC_COEF 0 2>/dev/null)
  echo -e "$index\n$value"
  [[ $index -eq '0x3f' ]] && break
done

**output
index = 0x0
value = 0x80
index = 0x1
value = 0x0
index = 0x2
value = 0x3a
index = 0x3
value = 0xbaa
index = 0x4
value = 0xc04
index = 0x5
value = 0x1000
...
Comment 62 Leif Liddy 2017-10-25 07:34:39 UTC
Created attachment 260387 [details]
patch_cirrus.c patch v2

work-in-progress patch
Comment 63 Leif Liddy 2017-10-27 09:39:17 UTC
Created attachment 260413 [details]
window-sound-device-screenshots
Comment 64 Leif Liddy 2017-10-27 10:01:55 UTC
Created attachment 260415 [details]
hda-tool-pin-out

windows hda-tool pinout. Useful tool, unfortunately I'm not able to send verbs to extract current info. Receive error "Unable to execute verb. Only pin configurations can be set without the chk driver". I barely know how to use windows. Does anyone know how I can execute verbs on windows? 

This link looks promising:
https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/communicating-verbs-with-the-hd-audio-codec

I'm not sure what language this is written in (c++ ??). Anyways..if anyone's got any experience in this area please let me know. 

I'm particularly interested in sorting out whether any of the coefficient values in the vendor widget change in response to certain actions.  

here's an example of where a coefficient value affects amp gain:
"/* Speaker Amp Gain is controlled by the vendor widget's coef 4 */"
https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_cirrus.c#L943
Comment 65 Leif Liddy 2017-10-29 20:52:19 UTC
Back to square one...

I managed to hda-verb working on OSX! Here's what I've learned so far. 

The vendor coefficients don't need to be modified in Linux. The default values are correct. There were 3 coefficients near the end of the list that were different in OSX. However, changing these in Linux didn't have any effect.

The pin configuration doesn't need to be modified. 

The GPIO config in OSX, looks like:

headphones unplugged       headphones plugged-in
gpio mask --> 0x37         gpio mask --> 0x37
gpio dir  --> 0x31         gpio dir  --> 0x31
gpio data --> 0x7          gpio data --> 0x6


**GPIO0 powers the speakers. Interestingly enough, none of the GPIO pins power the headphone jack. I can't believe I never tested that before.

**digital converter value is 0x111 in OSX
hda-verb 0x0a 0xF0D 0 = 0x111

There were a few other insignificant changes, but that's basically it.

Is there a way to view this Control information in OSX (or something similar)?
ie
  Control: name="Line Out Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0

I'm wondering if there should be an amp controlled by node 0x0a

Node 0x0a [Audio Output] wcaps 0x46631: 8-Channels Digital Stripe
  Control: name="IEC958 Playback Con Mask", index=16, device=0
  Control: name="IEC958 Playback Pro Mask", index=16, device=0
  Control: name="IEC958 Playback Default", index=16, device=0
  Control: name="IEC958 Playback Switch", index=16, device=0
  Device: name="CS4208 Digital", type="SPDIF", device=1

The one thing missing from this is output (besides possibly an amp) is:
'Control: name="IEC958 Default PCM Playback Switch", index=0, device=0'

Why doesn't node 0x0a have a Default PCM Playback Switch? Nothing is controlling that output.
Comment 66 Leif Liddy 2017-10-29 21:00:19 UTC
Created attachment 260427 [details]
hda-verb results Linux + OSX

ran a full battery of hda-verbs on Linux and OSX. These are the results. I've removed lines where the result was 0x0. The left column show Linux results, the right column shows any differing OSX results.
Comment 67 Leif Liddy 2017-10-29 21:38:12 UTC
comment 65
my mistake:
Control: name="IEC958 Default PCM Playback Switch", index=0, device=0
does show up in the 'cat /proc/asound/card0/codec#0' output.
**was looking at older data
Comment 68 Leif Liddy 2017-10-30 12:28:32 UTC
I think I may have found an error with the way in which alsa initializes this sound device.

The default configuration register for node 0x1d is 90100110
However, if I make no modifications to the pin configs, alsa won't set up the IEC958 mixer controls (non-hdmi) or the CS4208 Digital audio device

ie:
card 0: PCH [HDA Intel PCH], device 1: CS4208 Digital [CS4208 Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

However, if I create the following pin configuration:

static const struct hda_pintbl mb9_pincfgs[] = {

        { 0x1d, 90100110 },
        {} /* terminator */
};

alsa sets digital mixer controls and playback device correctly. This is a bit counterintuitive since I'm using the same pin configuration found in /sys/class/sound/hwC0D0/init_pin_configs, but achieve different results.  

Takashi --do you why this is happening?
Comment 69 Leif Liddy 2017-11-03 23:24:36 UTC
I think I figured out what these lines refer to in the windows driver:

#CIR=04h, coeff=0C04h (TX1 ch 0: slot  4, ch 1: slot 12)
#CIR=05h, coeff=1000h (TX1 ch 2: slot  0, ch 3: slot 16)

these are slots used for each speaker for the TDM configuration
0x0C04 = 0000 1100 0000 0100    **read as two separate bytes
0x1000 = 0001 0000 0000 0000    **read as two separate bytes


in macOS, if I change these values to something random
ie
hda-verb 0x24 SET_COEF_INDEX 0x04
hda-verb 0x24 SET_PROC_COEF 0x0111

It severally degrades the sound quality and introduces heavy distortion.
Comment 70 Leif Liddy 2017-11-03 23:32:18 UTC
A kernel developer emailed me the other day, here's what he wrote:

- Get the schematics for the MB8,1 if you haven't done so already:
  http://laptopblue.vn/download3.php?id=1794

- One thing I notice in the schematics: GPIO51 on the PCH is AUD_PWR_EN,
  so this can power the CS codec on/off.  Looking at the DSDT this pin is
  toggled from _PS0 and _PS3 beneath the HDEF device.  Theoretically the
  ACPI core and PCI core should power the device on before a driver is
  loaded but I'm not sure.  Needs to be checked.

- There's I2S0 and I2S1 pins on the PCH.  The codec is missing in the
  schematics because it's not on the mainboard, it's on the RIO board
  and connected with a flex cable but the pinout of the flex connector
  is given on page 40. For some reason the left and right amplifiers
  *are* on the mainboard (page 38 and 39), as are the connectors to
  the speakers (page 40).

- On some chipsets audio is only working if the Intel GPU enables certain
  power wells.

I've just looked up the datasheet for the four (!) amplifiers (there's two on each side):

https://datasheets.maximintegrated.com/en/ds/MAX98357A-MAX98357B.pdf

These chips accept digital audio (I2S or TDM). The DAC is integrated into each chip. I've never seen anything like that before. Pretty sure Apple uses the same digital audio architecture on the 2016+ MBPs.

The amps are powered via PP5V_S4, so even in sleep state S4.  But they
can be put into shutdown via the AUD_SPKRAMP_MODE pin A1. That pin is
going to the RIO flex connector, pity we don't have the schematics for
that board.
Comment 71 Leif Liddy 2018-03-18 15:10:27 UTC
started bounty to get this issue resolved. bounty is good for any of the following models: Macbook 8,1, 9,1 and 10,1. 

https://www.bountysource.com/issues/56233031-macbook8-1-12-inch-early-2015-no-speaker-sound-output/backers
Comment 72 Lukas Wunner 2018-11-15 17:27:44 UTC
David Ulricht prodded me to look into the audio situation on the MBP13,3, here's a braindump in the hope that it might be of use to someone (I don't own such a machine):

The MB8,1 uses MAX98357 amps, there's a public spec, it's linked above.

The MBP13,3 uses MAX98706 amps, there's no public spec, it may be a custom design for Apple. These amps are more complicated, they have a Reset pin which needs to be driven high for the amps to come out of shutdown and they're connected to the HDA controller with i2c.

Maxim introduced another amp this year, the MAX98374, there's a public spec and it looks similar to the amps in the MBP13,3:
https://datasheets.maximintegrated.com/en/ds/MAX98374.pdf

Specifically, this amp also has a Reset pin, see the timing characteristics on page 24: After driving the pin high, one needs to wait for 1.5 ms before the chip is ready. Presumably driving the pin low when the amps are not used saves power. The pin is attached to GPIO5 on the CS8409 HDA controller.

Page 49 specifies the power-up and power-down sequence: After powering up the chip using the Reset pin, the chip needs to be software-enabled via i2c. The i2c pins to drive are GPIO6 (SCL) and GPIO7 (SDA) on the HDA controller. It is unclear to me how the pins are supposed to be used: Is it possible to configure the pins as an i2c bus by sending appropriate commands to the HDA controller? Is this even supported on Linux? Is the i2c bus exposed as a struct i2c_adapter?

David Ulricht found i2c hex strings in the Windows 10 registry, presumably these are necessary to initialize the amps:
"I2CSpeedMode"=dword:00000001
"I2CPolledMode"=dword:00000001
"I2CQuickMode"=dword:00000001
"I2CBusClear"=dword:00000006
"I2CSlave90Config"=dword:01002090
"InitI2C"=hex:01,90,3a,00,10,10,b0,00,1d,01,00,02,06,00,11,07,01,00,10,09,02,\
  07,03,00,12,01,00,08,13,05,ff,06,00,07,20,02,0d,00,2a,02,02,03,00,04,00,05,\
  02,06,00,07,20,08,02,09,00,0a,80,0b,02,0c,00,0d,a0,01,0c,00,29,02,01,03,02,\
  04,00,05,00,01,01,00,11,01,0a,02,84,00,23,01,00,03,00,02,3f,00,20,01,03,00,\
  1b,75,b6,73,c2,00,11,29,01,21,f3,03,20,05,00,12,00,13,80,00,1c,03,c0
"n0AStreamStartI2C"=hex:01,90,02,00,11,01,02
"n0AStreamStopI2C"=hex:01,90,02,00,11,01,0a
"I2CSlave28Config"=dword:00004028
"I2CSlave2AConfig"=dword:0000402a
"I2CSlave2CConfig"=dword:0000402c
"I2CSlave2EConfig"=dword:0000402e
"n02PwrUpI2C"=hex:04,28,2a,2c,2e,07,00,81,01,11,02,32,03,48,04,11,05,10,00,80
"n03PwrUpI2C"=hex:01,28,01,05,00,01,2a,01,05,02,01,2c,01,05,01,01,2e,01,05,03
"ExitI2C"=hex:04,28,2a,2c,2e,01,00,83
"EQ1S1R7"=hex:1e,b2,9a,1a,df,15,c6,f4,11,19,91,ae,c6,f4,11,16,3b,23,16,3b,23,\
  d3,89,b9,1f,88,d9,c0,78,b8
"EQ1S2R7"=hex:16,3d,23,16,3d,23,d3,85,bb,1f,8e,8e,c0,73,03,14,62,da,12,94,45,\
  d9,23,c2,1d,b9,a4,c2,61,3d
"ExitVerbs"=hex:00,05,17,00,01,00,75,04,00,00,74,04,82,00,75,04,00,00,74,04,03,\
  00,75,04,00,80,74,04,04,00,75,04,01,28,74,04,06,00,75,04,00,80,74,04,07,00,\
  75,04,01,28,74,04,65,00,75,04,00,00,74,04,00,03,77,04,03,05,17,00

The MAX98374 spec contains a register map on page 41 and the command format is shown on page 55, but it doesn't really match the hex strings above:  The register map starts at 0x2000 and a command contains 1 byte for the device address, 2 bytes for the register address followed by data bytes.  And the commands above look like the register address might be 0x903a or 0x3a00 or something. So the command format and register map might not be identical, but maybe we don't have to fully understand the hex strings and it is sufficient to just send them to the amps verbatim.
Comment 73 Ronald 2018-12-11 02:03:42 UTC
(In reply to Lukas Wunner from comment #72)
> The MBP13,3 uses MAX98706 amps, there's no public spec, it may be a custom
> design for Apple. These amps are more complicated, they have a Reset pin
> which needs to be driven high for the amps to come out of shutdown and
> they're connected to the HDA controller with i2c.
> 
> Maxim introduced another amp this year, the MAX98374, there's a public spec
> and it looks similar to the amps in the MBP13,3:
> https://datasheets.maximintegrated.com/en/ds/MAX98374.pdf

Actually, I think this one is the right one to look at (see "Data Sheet" link):
https://www.maximintegrated.com/en/products/analog/audio/MAX98372.html

The pin configs of that one match those in the schematics for the MBP13,3 exactly, and so do the slave addresses (in the schematics they specify the addresses as the 7 MSB's, i.e. shift-right by one as compared to the data sheet).

The registers in this chip have only 1-byte addresses, and range from 0x00 to 0x66 (plus 0xff), but I still can't match this to the Init2C or Exit2C sequences.
Comment 74 Ronald 2018-12-24 05:45:52 UTC
I think the discussion on the MBP13,* specific parts is best continued on the corresponding bug for those devices, https://bugzilla.kernel.org/show_bug.cgi?id=195671 - I'm posting my results there.
Comment 75 Leif Liddy 2019-08-05 21:53:04 UTC
David Ulricht has managed to get the speakers working on my macbook 9,1!!!
I'll post updates on this in the coming days.
Comment 76 Leif Liddy 2019-08-15 18:36:52 UTC
I created a github project for the macbook12 audio driver (my first github project)  

https://github.com/leifliddy/macbook12-audio-driver  

It's definitely a bit rough around the edges and a bit hacky, but it works.
Please test out this driver and give me your feedback.

Note You need to log in before you can comment on or make changes to this bug.