Bug 98001

The chip is indeed unknown.  Could you give alsa-info.sh output (run it with --no-upload option) and the output of lspci -vv?

Created attachment 178681 [details]
lspci -vv on surface 3

Created attachment 178691 [details]
dmesg kernel 4.0.2

Created attachment 178701 [details]
alsa-info

let me know if you need more data :)

[    5.860609] intel_sst_acpi 808622A8:00: No matching machine driver found
This is printed in sst_apci.c

The 808622A8 is CHV ACPI device. I think we need to add an entry in static struct sst_machines sst_acpi_chv for surface 3 machine

Do we know which codec this uses. I will try to ask around...

(In reply to Vinod Koul from comment #6)
> Do we know which codec this uses. I will try to ask around...

Chen Yu will have access to a Surface 3.

Windows just says "Realtek I2S Audio Codec".

+Libin & Aaron,

Hi, Libin, do you know how to check the codec that is use in a Surface 3?
 thanks

It's ASoC audio. Add Mengdong

The ACPI table on the Surface 3 lists the codec used as "ALC5642". Unfortunately there is no codec driver for this chip yet, nor is the datasheet publicly available.

Based on these, I don't think it is possible to get audio working on the Surface 3 at this time :(

I will check with realtek folks on 5642(In reply to Stephen Just from comment #10)
> The ACPI table on the Surface 3 lists the codec used as "ALC5642".
> Unfortunately there is no codec driver for this chip yet, nor is the
> datasheet publicly available.

Can you tell me ACPI ID for this? 

 
> Based on these, I don't think it is possible to get audio working on the
> Surface 3 at this time :(

I will check with Realtek on that

(In reply to Vinod Koul from comment #11)
> I will check with realtek folks on 5642(In reply to Stephen Just from
> comment #10)
> > The ACPI table on the Surface 3 lists the codec used as "ALC5642".
> > Unfortunately there is no codec driver for this chip yet, nor is the
> > datasheet publicly available.
> 
> Can you tell me ACPI ID for this? 
> 
>  
> > Based on these, I don't think it is possible to get audio working on the
> > Surface 3 at this time :(
> 
> I will check with Realtek on that

This is the start of the definition for that device:

Device (RTEK)
{
    Name (_ADR, Zero)  // _ADR: Address
    Name (_HID, "10EC5640" /* Realtek I2S Audio Codec */)  // _HID: Hardware ID 
    Name (_CID, "10EC5640" /* Realtek I2S Audio Codec */)  // _CID: Compatible ID
    Name (_SUB, "10EC1070")  // _SUB: Subsystem ID
    Name (_DDN, "ALC5642")  // _DDN: DOS Device Name 
    Name (_UID, One)  // _UID: Unique ID
    Name (_PR0, Package (0x01)  // _PR0: Power Resources for D0

okay we got hold off a surface table, do have any steps to boot this off a linux USB driver?

https://wiki.gnome.org/BastienNocera/Surface%203 has some details on startup hot-keys.

Any 64-bit Linux distribution should work, usually as long as you pass nomodeset to avoid graphics problems with older kernels. The current upstream kernel should have support for the GPU though. Don't forget to disable Secure Boot, there are bugs in the downstream kernel support for all versions of it.

Okay I wasn't able to run the device off USB. Since it was borrowed device couldn't install..

Dumping the DSDT:
Device (LPEA)
        {
            Name (_HID, "808622A8")  // _HID: Hardware ID
            Name (_CID, "808622A8")  // _CID: Compatible ID
            Name (_DDN, "Intel(R) Low Power Audio Controller - 808622A8")  // _DDN: DOS Device Name
            Name (_UID, One)  // _UID: Unique ID


Device (RTEK)
            {
                Name (_ADR, Zero)  // _ADR: Address
                Name (_HID, "10EC5640")  // _HID: Hardware ID
                Name (_CID, "10EC5640")  // _CID: Compatible ID
                Name (_SUB, "10EC1070")  // _SUB: Subsystem ID
                Name (_DDN, "ALC5642")  // _DDN: DOS Device Name
                Name (_UID, One)  // _UID: Unique ID
                Name (_PR0, Package (0x01)  // _PR0: Power Resources for D0


We have netry for these in upstream driver:

        /* some CHT-T platforms rely on RT5640, use Baytrail machine driver */
        {"10EC5640", "bytcr_rt5640", "intel/fw_sst_22a8.bin", "bytcr_rt5640", NULL,
                                                &chv_platform_data },


Can you try this again on latest kernel. and ensure we have this commit

commit fdf841937e4fa08e767dbe83f1c65696cfec67c9
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Thu Mar 3 21:36:39 2016 -0600

    ASoC: Intel: Atom: add support for CHT w/ RT5640

    Some CHT-T platforms make use of the Realtek RT5640 codec. Make use
    of the machine driver developed for Baytrail.

    Tested on Tronsmart Ara X5.

    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>


Please let me know if this works. Thnx

Created attachment 217841 [details]
Dmesg with Comment 15 module enabled

With the module enabled, the following is logged:

[   14.765613] rt5640 i2c-10EC5640:00: Device with ID register 0x6308 is not rt5640/39
[   14.803939] bytcr_rt5640 bytcr_rt5640: ASoC: CODEC DAI rt5640-aif1 not registered
[   14.804002] bytcr_rt5640 bytcr_rt5640: devm_snd_soc_register_card failed -517

Interestingly, the rt5645 driver uses that particular ID register value.

I'll also attach an i2cdump from the audio codec - that also looks very much like the default settings stored in the rt5645 driver.

Created attachment 217851 [details]
Output of "i2cdump -y 1 0x1a w"

Okay, I got update from RTEK that 0x6308  is rt5645 codec.

So we need to do following now.

1. Update rt5645:

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 7af5e7380d61..131b37bb51fb 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -3533,6 +3533,7 @@ MODULE_DEVICE_TABLE(i2c, rt5645_i2c_id);
 static const struct acpi_device_id rt5645_acpi_match[] = {
        { "10EC5645", 0 },
        { "10EC5650", 0 },
+       { "10EC5640", 0 },
        {},
 };


2. Update CHT machine table to load 5445 machine driver:

diff --git a/sound/soc/intel/atom/sst/sst_acpi.c b/sound/soc/intel/atom/sst/sst_acpi.c
index 3bc4b63b2f9d..d9723e0f2b07 100644
--- a/sound/soc/intel/atom/sst/sst_acpi.c
+++ b/sound/soc/intel/atom/sst/sst_acpi.c
@@ -343,7 +343,7 @@ static struct sst_acpi_mach sst_acpi_chv[] = {
        {"193C9890", "cht-bsw-max98090", "intel/fw_sst_22a8.bin", "cht-bsw", NULL,
                                                &chv_platform_data },
        /* some CHT-T platforms rely on RT5640, use Baytrail machine driver */
-       {"10EC5640", "bytcr_rt5640", "intel/fw_sst_22a8.bin", "bytcr_rt5640", NULL,
+       {"10EC5640", "cht-bsw-rt5645", "intel/fw_sst_22a8.bin", "bytcr_rt5640", NULL,
                                                &chv_platform_data },

        {},

It is unfortunate that BIOS used 5640 ACPI ID for 5645 :( We need to do some smart solution here, perhaps DMI override for this device.

Thanks for the update. I just tried your changes, but I had to add a third one to prevent an oops:

---
diff --git a/sound/soc/intel/boards/cht_bsw_rt5645.c b/sound/soc/intel/boards/cht_bsw_rt5645.c
index 2a6f808..fdbb405 100644
--- a/sound/soc/intel/boards/cht_bsw_rt5645.c
+++ b/sound/soc/intel/boards/cht_bsw_rt5645.c
@@ -340,6 +340,7 @@ static struct snd_soc_card snd_soc_card_chtrt5650 = {
 };
 
 static struct cht_acpi_card snd_soc_cards[] = {
+       {"10EC5640", CODEC_TYPE_RT5645, &snd_soc_card_chtrt5645},
        {"10EC5645", CODEC_TYPE_RT5645, &snd_soc_card_chtrt5645},
        {"10EC5650", CODEC_TYPE_RT5650, &snd_soc_card_chtrt5650},
 };
@@ -365,6 +366,9 @@ static int snd_cht_mc_probe(struct platform_device *pdev)
                        break;
                }
        }
+       if (!drv->acpi_card)
+               return -ENODEV;
+
        card->dev = &pdev->dev;
        sprintf(codec_name, "i2c-%s:00", drv->acpi_card->codec_id);

---

Now, this gives me a lot of errors when pulseaudio tries to initialize the card:
[  +0.001357]  Audio Port: ASoC: no backend DAIs enabled for Audio Port
[  +0.000493]  Audio Port: ASoC: no backend DAIs enabled for Audio Port
[  +0.000286]  Audio Port: ASoC: no backend DAIs enabled for Audio Port
[  +0.001103]  Audio Port: ASoC: no backend DAIs enabled for Audio Port

And in the end, the init fails and pulseaudio doesn't load the card. alsamixer shows it (and I can even change the controls), but aplay refuses to shout anything from the speakers.

Are we missing anything else?

Okay we modified above bits after getting RTEK confirmation and happy to report we have audio working on Surface 3.

Kernel changes: (slightly modified from above)
Add ACPI ID in RT5645

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c index 7af5e73..131b37b 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -3533,6 +3533,7 @@ MODULE_DEVICE_TABLE(i2c, rt5645_i2c_id);  static const struct acpi_device_id rt5645_acpi_match[] = {
 	{ "10EC5645", 0 },
 	{ "10EC5650", 0 },
+	{ "10EC5640", 0 },
 	{},

Then machine entry (note we need cht-bsw not Byt-cr here

diff --git a/sound/soc/intel/atom/sst/sst_acpi.c b/sound/soc/intel/atom/sst/sst_acpi.c
index 3bc4b63..b5e433f8 100644
--- a/sound/soc/intel/atom/sst/sst_acpi.c
+++ b/sound/soc/intel/atom/sst/sst_acpi.c
@@ -343,9 +343,8 @@ static struct sst_acpi_mach sst_acpi_chv[] = {
 	{"193C9890", "cht-bsw-max98090", "intel/fw_sst_22a8.bin", "cht-bsw", NULL,
 						&chv_platform_data },
 	/* some CHT-T platforms rely on RT5640, use Baytrail machine driver */
-	{"10EC5640", "bytcr_rt5640", "intel/fw_sst_22a8.bin", "bytcr_rt5640", NULL,
-						&chv_platform_data },
-
+	{"10EC5640", "cht-bsw-rt5645", "intel/fw_sst_22a8.bin", "cht-bsw", NULL,
+	       					&chv_platform_data },	
 	{},
 };

Lastly add in machine:
diff --git a/sound/soc/intel/boards/cht_bsw_rt5645.c b/sound/soc/intel/boards/cht_bsw_rt5645.c
index 2a6f808..9e272ea 100644
--- a/sound/soc/intel/boards/cht_bsw_rt5645.c
+++ b/sound/soc/intel/boards/cht_bsw_rt5645.c
@@ -340,6 +340,7 @@ static struct snd_soc_card snd_soc_card_chtrt5650 = {  };
 
 static struct cht_acpi_card snd_soc_cards[] = {
+	{"10EC5640", CODEC_TYPE_RT5645, &snd_soc_card_chtrt5645},
 	{"10EC5645", CODEC_TYPE_RT5645, &snd_soc_card_chtrt5645},
 	{"10EC5650", CODEC_TYPE_RT5650, &snd_soc_card_chtrt5650},  };


Then to set mixers: First one for speaker and second one for HS

# Surface 3: Speaker Playback Mixer Settings

amixer -c 0 cset  name='codec_out1 mix 0 pcm0_in Switch' on
amixer -c 0 cset  name='media0_out mix 0 media1_in Switch' on

amixer -c 0 cset  name='media1_in Gain 0 Ramp Delay' 50
amixer -c 0 cset  name='media1_in Gain 0 Switch' on
amixer -c 0 cset  name='media1_in Gain 0 Volume' 80% 80%

amixer -c 0 cset  name='pcm0_in Gain 0 Ramp Delay' 50
amixer -c 0 cset  name='pcm0_in Gain 0 Switch' on
amixer -c 0 cset  name='pcm0_in Gain 0 Volume' 80% 80%

amixer -c 0 cset  name='codec_out1 Gain 0 Ramp Delay' 50
amixer -c 0 cset  name='codec_out1 Gain 0 Switch' on
amixer -c 0 cset  name='codec_out1 Gain 0 Volume' 70% 70%

amixer -c 0 cset  name='Ext Spk Switch' on
amixer -c 0 cset  name='Speaker Channel Switch' on
amixer -c 0 cset  name='Ext HP Switch' off

amixer -c 0 cset  name='DAC R2 Mux' 'IF1 DAC'
amixer -c 0 cset  name='DAC L2 Mux' 'IF1 DAC'
amixer -c 0 cset  name='Mono DAC MIXL DAC L2 Switch' on
amixer -c 0 cset  name='Mono DAC MIXR DAC R2 Switch' on
amixer -c 0 cset  name='DAC2 Playback Switch' on

amixer -c 0 cset  name='HPOVOL MIXL DAC2 Switch' on
amixer -c 0 cset  name='HPOVOL MIXR DAC2 Switch' on
amixer -c 0 cset  name='HPO MIX HPVOL Switch' on
amixer -c 0 cset  name='HPOVOL L Switch' on
amixer -c 0 cset  name='HPOVOL R Switch' on

amixer -c 0 cset  name='SPK MIXL DAC L2 Switch' on
amixer -c 0 cset  name='SPK MIXR DAC R2 Switch' on
amixer -c 0 cset  name='SPOL MIX SPKVOL L Switch' on
amixer -c 0 cset  name='SPOR MIX SPKVOL R Switch' on
amixer -c 0 cset  name='SPKVOL L Switch' on
amixer -c 0 cset  name='SPKVOL R Switch' on

amixer -c 0 cset  name='Speaker Playback Volume' 39


# Surface 3: Headphone Playback Mixer Settings

amixer -c 0 cset  name='Ext Spk Switch' off
amixer -c 0 cset  name='Speaker Channel Switch' off
amixer -c 0 cset  name='Headphone Switch' on
amixer -c 0 cset  name='Headphone Channel Switch' on
amixer -c 0 cset  name='Headphone Playback Volume' 39

Once verified, we will upstream the change. They need to be modified a bit for upstream

Thanks for the update.

After running the first set of amixer commands (Surface 3: Speaker Playback Mixer Settings) -> pulseaudio was still not detecting the audio card.

After running the second set (Surface 3: Headphone Playback Mixer Settings) pulseaudio now detects the headphones on the chtrt5645. I tested the headphones, and they worked :)

So I played a little bit with alsamixer, and somehow managed to duplicate the headphone output to the internal speakers, but couldn't make pulseaudio detecting the speakers (nor the internal mic).

I would then believe that there is a missing configuration for alsa for our card, so I think the kernel part is OK.

Thanks again!

ya first we wnated to get independent verification of HW and kernel. We tried aplay only.

Next is getting UCM and PA to work, stay tuned :)

Created attachment 219531 [details]
UCM config settings

We are happy to report that Pulse Audio is up and working on Surface 3 with the attached UCM config settings.

Please extract and place the above directory in /usr/share/alsa/ucm/

You may need to reset alsaucm & restart pulseaudio through the following commands:

sudo alsaucm reset
pulseaudio -k
pulseaudio -vv

Sink settings have to be done in Pulse Audio Volume Controls (PAVU) to enable Audio to be played on Speaker or HS by default.

Works as advertised: PA recognizes the main output, but can't select Speaker or HS. There is no Input too, but I don't know if this thing has one Mic somewhere or only in the HS.

The default main output i.e Speaker or HS can be selected from the Output Devices tab found in Pulse Audio Volume Controls (PAVU) UI navigating from Dashboard. 

As far as Capture is concerned, first verify if arecord is working by first setting the following mixer controls:

#Capture Mixer Settings Headset Mic
amixer -c 0 cset  name='Headset Mic Switch' on
amixer -c 0 cset  name='Int Mic Switch' off
amixer -c 0 cset  name='Sto1 ADC MIXL ADC2 Switch' 0
amixer -c 0 cset  name='Sto1 ADC MIXR ADC2 Switch' 0
amixer -c 0 cset  name='RECMIXL BST1 Switch' 1
amixer -c 0 cset  name='RECMIXR BST1 Switch' 1
amixer -c 0 cset  name='Sto1 ADC MIXL ADC1 Switch' 1
amixer -c 0 cset  name='Sto1 ADC MIXR ADC1 Switch' 1
amixer -c 0 cset  name='ADC Capture Switch' on
amixer -c 0 cset  name='Stereo1 DMIC Mux' 0
amixer -c 0 cset  name='Stereo1 ADC2 Mux' 1
amixer -c 0 cset  name='I2S2 Func Switch' 0
amixer -c 0 cset  name='pcm1_out mix 0 media_loop2_in Switch' 1
amixer -c 0 cset  name='media_loop2_out mix 0 codec_in0 Switch' 1
amixer -c 0 cset  name='codec_in0 Gain 0 Ramp Delay' 50
amixer -c 0 cset  name='codec_in0 Gain 0 Switch' on
amixer -c 0 cset  name='codec_in0 Gain 0 Volume' 80% 80%
amixer -c 0 cset  name='media_loop2_out Gain 0 Ramp Delay' 50
amixer -c 0 cset  name='media_loop2_out Gain 0 Switch' on
amixer -c 0 cset  name='media_loop2_out Gain 0 Volume' 80% 80%
amixer -c 0 cset  name='pcm1_out Gain 0 Ramp Delay' 50
amixer -c 0 cset  name='pcm1_out Gain 0 Switch' on
amixer -c 0 cset  name='pcm1_out Gain 0 Volume' 80% 80%

amixer -c 0 cset  name='ADC Boost Capture Volume' 3
amixer -c 0 cset  name='Mono ADC Capture Volume' 3
amixer -c 0 cset  name='Mono ADC Capture Volume' 63
amixer -c 0 cset  name='IN Capture Volume' 63
amixer -c 0 cset  name='ADC Capture Volume' 31
amixer -c 0 cset  name='Mono ADC Boost Capture Volume' 2

arecord command would be:
arecord -Dhw:0,0 cap.wav -f S16_LE -r 48000 -c 2 -vv

If arecord works, the UCM config settings contains capture feature as well, that can be selected from PAVU controls.

Created attachment 220051 [details]
pulseaudio log

I'm having some difficulty making this work under Fedora 24 with kernel 4.7.0-rc3 + patches [1].

The attached log shows that Pulseaudio is picking up the card and its UCM configuration, but it's failing to configure the DAI link.

Using the same ucm config files, I had some success on an Arch-linux based install. I am not completely sure what I did differently there for it to work.

I am under the impression that with the UCM file, the audio card should "just work" once it is selected in pavucontrol, once I can get it to show up at all.

(My goal is to build a live-image with audio working out-of-the-box.)

[1] https://copr.fedorainfracloud.org/coprs/stephenjust/kernel-surface3/build/341216/

D: [pulseaudio] alsa-util.c: Managed to open hw:chtrt5645,0
D: [pulseaudio] alsa-util.c: Maximum hw buffer size is 4266 ms
I: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed: Invalid argument
I: [pulseaudio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_PREPARE failed (-22)
I: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed: Invalid argument
I: [pulseaudio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_PREPARE failed (-22)
D: [pulseaudio] alsa-util.c: Set neither period nor buffer size.
I: [pulseaudio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_PREPARE failed (-22)
I: [pulseaudio] alsa-util.c: snd_pcm_hw_params failed: Invalid argument
D: [pulseaudio] alsa-util.c: Trying hw:chtrt5645,0 without SND_PCM_NO_AUTO_FORMAT ...
D: [pulseaudio] alsa-util.c: Managed to open hw:chtrt5645,0


do the driver suppport maximum buffer size for more than 4 seconds ?


D: [pulseaudio] alsa-util.c: Maximum hw buffer size is 4266 ms
I: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed: Invalid argument
I: [pulseaudio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_PREPARE failed (-22)
I: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed: Invalid argument
I: [pulseaudio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_PREPARE failed (-22)
D: [pulseaudio] alsa-util.c: Set neither period nor buffer size.
I: [pulseaudio] (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_PREPARE failed (-22)
I: [pulseaudio] alsa-util.c: snd_pcm_hw_params failed: Invalid argument
D: [pulseaudio] alsa-util.c: Trying plug:hw:chtrt5645,0 with SND_PCM_NO_AUTO_FORMAT ...
I: [pulseaudio] (alsa-lib)conf.c: Unknown parameter 1
I: [pulseaudio] (alsa-lib)conf.c: Parse arguments error: No such file or directory
I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM plug:hw:chtrt5645,0
I: [pulseaudio] alsa-util.c: Error opening PCM device plug:hw:chtrt5645,0: No such file or directory
D: [pulseaudio] alsa-mixer.c: Profile set 0x55f93a854e70, auto_profiles=no, probed=yes, n_mappings=0,

(In reply to Raymond from comment #28)
> do the driver suppport maximum buffer size for more than 4 seconds ?
> 

I think it does. I get the same buffer size on my Arch install where audio is working. (I also checked to make sure both installs were using latest sst firmware)


D: [pulseaudio] alsa-util.c: Trying hw:chtrt5645,0 with SND_PCM_NO_AUTO_FORMAT ...
D: [pulseaudio] alsa-util.c: Managed to open hw:chtrt5645,0
D: [pulseaudio] alsa-util.c: Maximum hw buffer size is 4266 ms
I: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed: Invalid argument

==== This bit below is different though ===

D: [pulseaudio] alsa-util.c: Set period size first (to 1199 samples), buffer size second (to 4797 samples).
I: [pulseaudio] alsa-util.c: Device hw:chtrt5645,0 doesn't support 44100 Hz, changed to 48000 Hz.
D: [pulseaudio] alsa-util.c: Trying hw:chtrt5645,0 with SND_PCM_NO_AUTO_FORMAT ...
D: [pulseaudio] alsa-util.c: Managed to open hw:chtrt5645,0
D: [pulseaudio] alsa-util.c: Maximum hw buffer size is 4266 ms
I: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed: Invalid argument
D: [pulseaudio] alsa-util.c: Set period size first (to 1199 samples), buffer size second (to 4797 samples).
I: [pulseaudio] alsa-util.c: Device hw:chtrt5645,0 doesn't support 44100 Hz, changed to 48000 Hz.
D: [pulseaudio] alsa-ucm.c: Profile HiFi supported.
I: [pulseaudio] (alsa-lib)conf.c: Unknown parameter 1
I: [pulseaudio] (alsa-lib)conf.c: Parse arguments error: No such file or directory
I: [pulseaudio] (alsa-lib)control.c: Invalid CTL hw:chtrt5645,0
I: [pulseaudio] alsa-util.c: Unable to attach to mixer hw:chtrt5645,0: No such file or directory
I: [pulseaudio] alsa-util.c: Successfully attached to mixer 'hw:0'

Oops, my mistake, apparently you do need to run those amixer commands prior to enabling UCM. I was playing with alsa before, so I must have messed something up. Resetting alsa configs, running the amixer commands above, and then adding the UCM file works.

That is definitely somewhat clunky though...

With the attached UCM config files, Audio "just works" even without running the amixer commands. However the sequence that you have mentioned above needs a slight modification. 

First, we need to place the UCM config files directory in /usr/share/alsa/ucm/

Next, we need to reset alsaucm so that alsaucm can parse the new UCM config files. The command would be:
sudo alsaucm reset

Then we need to restart pulseaudio through the following commands:
pulseaudio -k
pulseaudio -vv

Finally, Sink settings have to be done in Pulse Audio Volume Controls (PAVU) to enable Audio to be played on Speaker or HS by default.

This should be a one time effort to enable Pulse Audio to use the new UCM config files and henceforth Audio should work without changing any settings.

We have verified it with PulseAudio version as low as 2.0. Please let us know if you are facing any issues further!

I have a couple more comments now after more playing around with this:

1) I cannot confirm Sanchin's comment about amixer commands not being necessary. Working from live-media directly to enforce using a clean system, I was unable to get Pulseaudio to detect the audio device without first running the amixer commands. On an install with persistent storage, the amixer configuration is saved between reboots, so the amixer commands are not required afterwards.

2) It is possible to write the UCM file such that pulseaudio does work without any user intervention from a live-image. In particular, if you enable the SST audio path in the SectionVerb part of the UCM file, Pulseaudio will properly power up the card and detect everything on its own.

3) I can't seem to get any plug/unplug events on "chtrt5645 Headset" device - is anyone else having this problem too? (The input device was also named incorrectly in the earlier UCM file).

4) I will attach the latest HiFi.conf file I've been using to try to get things going. I have not had any success with microphones, but both outputs work.

5) Be careful with playing around with switches in alsamixer - it is possible to blow your device's speakers (oops, my right speaker is toast now)

SectionVerb {
	# ALSA PCM
	Value {
		TQ "HiFi"

		# ALSA PCM device for HiFi
		PlaybackPCM "hw:chtrt5645,0"
		CapturePCM "hw:chtrt5645,0"
	}

	EnableSequence [
		cdev "hw:chtrt5645"

		# Enable audio output path
		cset "name='codec_out1 mix 0 pcm0_in Switch' on"
		cset "name='media0_out mix 0 media1_in Switch' on"

		cset "name='media1_in Gain 0 Ramp Delay' 50"
		cset "name='media1_in Gain 0 Switch' on"
		cset "name='media1_in Gain 0 Volume' 80% 80%"

		cset "name='pcm0_in Gain 0 Ramp Delay' 50"
		cset "name='pcm0_in Gain 0 Switch' on"
		cset "name='pcm0_in Gain 0 Volume' 80% 80%"

		cset "name='codec_out1 Gain 0 Ramp Delay' 50"
		cset "name='codec_out1 Gain 0 Switch' on"
		cset "name='codec_out1 Gain 0 Volume' 70% 70%"

		# Enable audio input path
		cset "name='pcm1_out mix 0 media_loop2_in Switch' on"
		cset "name='media_loop2_out mix 0 codec_in0 Switch' on"

		cset "name='codec_in0 Gain 0 Ramp Delay' 50"
		cset "name='codec_in0 Gain 0 Switch' on"
		cset "name='codec_in0 Gain 0 Volume' 80% 80%"

		cset "name='media_loop2_out Gain 0 Ramp Delay' 50"
		cset "name='media_loop2_out Gain 0 Switch' on"
		cset "name='media_loop2_out Gain 0 Volume' 80% 80%"

		cset "name='pcm1_out Gain 0 Ramp Delay' 50"
		cset "name='pcm1_out Gain 0 Switch' on"
		cset "name='pcm1_out Gain 0 Volume' 80% 80%"
	]

	DisableSequence [
		cdev "hw:chtrt5645"

		# Disable audio output path
		cset "name='codec_out1 mix 0 pcm0_in Switch' off"
		cset "name='media0_out mix 0 media1_in Switch' off"

		cset "name='media1_in Gain 0 Switch' off"
		cset "name='pcm0_in Gain 0 Switch' off"
		cset "name='codec_out1 Gain 0 Switch' off"

		# Disable audio input path
		cset "name='pcm1_out mix 0 media_loop2_in Switch' off"
		cset "name='media_loop2_out mix 0 codec_in0 Switch' off"

		cset "name='media_loop2_out Gain 0 Switch' off"
		cset "name='pcm1_out Gain 0 Switch' off"
		cset "name='codec_in0 Gain 0 Switch' off"
	]
}

Created attachment 220201 [details]
UCM HiFi.conf

(In reply to Stephen Just from comment #32)
> 3) I can't seem to get any plug/unplug events on "chtrt5645 Headset" device
> - is anyone else having this problem too? (The input device was also named
> incorrectly in the earlier UCM file).

Still not getting any input events after the initial state being set at boot, but the input device names were actually correct. My mistake again.

Hello ! I'm happy to seeing this audio SOC is the same of my Chuwi Hi10 tablet, same ACPID, i've uploaded the dump of ACPI table here if it can help to merge the support of this tablet with the Surface 3 => http://vavar60.online.fr/share/tablet/chuwi_hi10/ACPI_Table_Dump_Chuwi-Hi10-DualOS.7z

Created attachment 221541 [details]
0001-ASoC-rt5645-Add-support-for-Surface-3-tablet.patch

We also need a DMI match against Surface 3 in the codec driver for headphone jack-detection and internal mic to work properly.

(In reply to Vinod Koul from comment #21)
> Once verified, we will upstream the change. They need to be modified a bit
> for upstream

Is there anything else specific that needs to be taken care of before a patch can be pushed upstream?

Created attachment 221701 [details]
0002-ASoC-Intel-Atom-add-quirk-for-CHT-w-RT5645.patch

It's not pretty, but I found a way to hopefully not break other hardware while supporting Surface 3.

If there are no objections or alternative suggestions in the next few days, I'll try to ferry these patches to upstream so that they may make it in time for v4.8.

(In reply to Stephen Just from comment #38)
> Created attachment 221701 [details]
> 0002-ASoC-Intel-Atom-add-quirk-for-CHT-w-RT5645.patch
> 
> It's not pretty, but I found a way to hopefully not break other hardware
> while supporting Surface 3.

Looks like it's as clean as it could be for a quirk. Does that also fix the jack detection and internal mic as mentioned in comment 36? Will you also upstream the ucm configuration file?

> If there are no objections or alternative suggestions in the next few days,
> I'll try to ferry these patches to upstream so that they may make it in time
> for v4.8.

(In reply to Bastien Nocera from comment #39)
> Looks like it's as clean as it could be for a quirk. Does that also fix the
> jack detection and internal mic as mentioned in comment 36?

Patch 0001 takes care of that.

> Will you also upstream the ucm configuration file?

That's the plan. I've modified it a bit since I got the internal mic and jack detection working. Feedback on it would be nice.

Created attachment 221711 [details]
UCM HiFi.conf

I tested last UCM profile and only jack worked. No internal sound yet. With that profile pulseaudio server get segmentation fault when it starts.

I tested tar from comment #29 and internal sound worked and pulseaudio started, but any sound in jack (sound go through internal sound).

(In reply to Francisco Panis Kaseker from comment #43)
> I tested tar from comment #29 and internal sound worked and pulseaudio
> started, but any sound in jack (sound go through internal sound).

Are you using the kernel patches from comment 36 and comment 38? Without the Comment 36 patch the presence of headphones is only detected after rebooting, so it may appear that either internal speaker or headphones don't work. (Verify using evtest that input events happen on the chtrt5645 device.)

As for Pulseaudio segfaulting, what versions of alsa-lib and PA are you using?

Created attachment 222331 [details]
Upstream patches for Surface 3 Audio

Hi All,

Thank you for your review. Interestingly, the attached patches are already in the process of up-streaming and would be merged once the maintainers give their review comments, if any! Meanwhile you could verify these patches on your device and update us if you are facing any issues. 

Stephen, As far as your DMI override patch is concerned, thankfully we had a foresight to add a quirk callback in machine table. So we are using that to override the machine entry, once we hit a match. 

Please verify the above set of patches and let us know the results!

attachment 222331 [details] looks like a .tar.gz (in case anyone else tries to open it). I would agree that this looks far better than my attempt at a quirk. I can't immediately test it.

Through what list is this being submitted? I haven't seen it in alsa-devel.

I think that the diff below is still needed on top of that series for jack detection to work:

@@ -, +, @@ 
---
 sound/soc/codecs/rt5645.c | 7 +++++++
 1 file changed, 7 insertions(+)
--- a/sound/soc/codecs/rt5645.c	
+++ a/sound/soc/codecs/rt5645.c	
@@ -3561,6 +3562,12 @@ static const struct dmi_system_id dmi_platform_intel_braswell[] = {
 			DMI_MATCH(DMI_PRODUCT_NAME, "Setzer"),
 		},
 	},
+	{
+		.ident = "Microsoft Surface 3",
+		.matches = {
+			DMI_MATCH(DMI_PRODUCT_NAME, "Surface 3"),
+		},
+	},
 	{ }
 };
 
--

Have posted these on alaa-devel, psl do sent your tested by.

(In reply to Takashi Iwai from comment #1)
Takashi, Jarsolav,

Can you please mark this as resolved

patches are merged to broonie/topic/intel

OK, the UCM patch also merged to alsa-lib git repo, too.

Sorry if this is not the correct place for this but it seems directly related. 
The Chuwi Hi12 Atom z8300 tablet looks like it has the same audio as the Surface 3.  The dmesg log had the same error message 
   "intel_sst_acpi 808622A8:00: No matching machine driver found"
This fix is in alsa-lib 1.1.2 correct?  How do I install and test this? 

Chuwi Hi12 (full ACPI table data dump: http://pastebin.com/84cjD8kp):
 
Device (LPEA)
        {
            Name (_HID, "808622A8")  // _HID: Hardware ID
            Name (_CID, "808622A8")  // _CID: Compatible ID
            Name (_DDN, "Intel(R) Low Power Audio Controller - 808622A8")  // _DDN: DOS Device Name
            Name (_UID, One)  // _UID: Unique ID

Device (RTEK)
            {
                Name (_ADR, Zero)  // _ADR: Address
                Name (_HID, "10EC5640" /* Realtek I2S Audio Codec */)  // _HID: Hardware ID
                Name (_CID, "10EC5640" /* Realtek I2S Audio Codec */)  // _CID: Compatible ID
                Name (_DDN, "ALC5642")  // _DDN: DOS Device Name
                Name (_UID, One)  // _UID: Unique ID
                Name (_PR0, Package (0x01)  // _PR0: Power Resources for D0

Brad, I'll follow up with you via email, and if you still think there's something that can be done, file a new issue.