On Tue, 09 Jan 2018 16:40:09 +0100, Freaky wrote:

Hi,

the speaker is always working on this Mac, whilst the headphone is unplugged that is, haven't gotten it to not function. That said, the unplug/plug events switch data I/O flags and unplugging the headphones correctly enables the speakers voiding anything I had done with hda-verb.

I'm not sure what the parameters do btw :). I understand the last parameter is some value being written and that it's probably a bunch of binary flags, but have little clue on what they exactly do.

...

From flipping flags and looking at the alsa-info.sh it seems that each bit

corresponds to a data I/O channel. 0x1 being IO[0], 0x2 IO[1], 0x4 IO[2], 0x8 IO[3].

When IO[3]'s data=1 there's audio on the speakers (0x8) So we wrote 0x0 and verified alsa-info, all data IO's are disabled. Audio is gone. Wrote 0x8, enabling bit 4, which flipped IO[3]'s data back to 1 and we have audio on speaker. I presume that makes it safe to assume IO[3] is the Amp for speaker.

Plugged the headphone and looked at alsa-info. Now IO[1]'s data is enabled and that seems to be where it goes wrong. wrote 0x0 ensuring all IO's data are disabled (checked headphones - no sound obviously) and then 0x4 which enabled only IO[2]'s data and there's audio again. I presume IO[2] is the Amp for the headphones thus.

Using only 0x4 works as well thus. I have no clue if there are any Amps behind IO[0] and IO[1] and if so where they would be heading I'm afraid. The driver enables IO[1]'s data upon plugging the headphone, which should be IO[2]'s data on this system and unplugging enabled IO[3]'s data. That might also be why I never have seen it as broken as I need to unplug the headphone first, which switches flags correctly for the speaker output.

Plugging / unplugging doesn't seem to have any effect on the other flags required (direction and enabled). However, they do need to be set initially and in an earlier test, when booted with the headphone already plugged and then enabling them before any audio was played audio still didn't work. Needed to enable them again. Perhaps pulse did something with the flags then though (restoring the state at first audio playback or something). I can test this if desired. Plugging/unplugging the headphones doesn't seem to affect any of the IO's direction nor enabled flags, they remain the same as they were.

OK, so this looks like the gpio 2/3 case, and it corresponds to imac27_122 model.

Could you try to add the model option like below? Create a module config file, e.g. /etc/modprobe.d/50-hda.conf containing:

options snd-hda-intel model=,imac27_122

(Note the comma before imac27_122, it's no typo, but indicates to specify the second device -- where Haswell gives the HDMI/DP controller for the first PCI device while the second one is the analog I/O).

If this works, the patch like below should work without the model option above.

Takashi

--- diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c index 80bbadc83721..17660d03a314 100644 --- a/sound/pci/hda/patch_cirrus.c +++ b/sound/pci/hda/patch_cirrus.c @@ -408,6 +408,7 @@ static const struct snd_pci_quirk cs420x_fixup_tbl[] = { /*SND_PCI_QUIRK(0x8086, 0x7270, "IMac 27 Inch", CS420X_IMAC27),*/

/* codec SSID */ + SND_PCI_QUIRK(0x106b, 0x0600, "iMac 14,1", CS420X_IMAC27_122), SND_PCI_QUIRK(0x106b, 0x1c00, "MacBookPro 8,1", CS420X_MBP81), SND_PCI_QUIRK(0x106b, 0x2000, "iMac 12,2", CS420X_IMAC27_122), SND_PCI_QUIRK(0x106b, 0x2800, "MacBookPro 10,1", CS420X_MBP101),