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),
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
