[alsa-devel] CS8409 Macbook Pro 2016 2017

David Ulricht david.ulricht434 at gmail.com
Fri Nov 16 15:02:15 CET 2018 

Lukas Wunner helped with investigation on the topic, check his last post
at: https://bugzilla.kernel.org/show_bug.cgi?id=110561
I am looking at sound/i2c/i2c.c and sound/i2c/cs8427.c but i don't
understand how to initialize the i2c bus having the Windows10 ini hexes
about I2C.
I believe you are more familiar with the code and you can help with a brief
example how to initialize i2c bus and how to send the InitI2C hex to the
I2C bus. Still  i2c.c is from 1998 should be of help.
Please advise.

On Sun, Aug 5, 2018 at 9:05 PM Takashi Iwai <tiwai at suse.de> wrote:

> On Sat, 04 Aug 2018 22:30:29 +0200,
> David Ulricht wrote:
> >
> >  Excuse me for dropping CC..
> >
> > I set the direction bit to 0 and used get_gpio_data and get only:  value
> =
> > 0x0
> > also checking "IO[0-7] data=0-1" value in  /proc/asound/card0/codec#0
> shows
> > no changes at all when insert audio jack.
>
> OK, then it's not about GPIO, something else.
> It's hard to know without the datasheet...
>
> > I tried also booting with "acpi=off". I tried older kernels from few
> years
> > ago. Nothing helps.
> > I wonder if there is some tool for Windows that I use to debug and see
> what
> > is sent to the codec so i replicate in Linux with hda-verb?
>
> acpi=off wouldn't work at all on modern machines.
>
> > What am I doing wrong ?  Is the below script correct for testing the
> GPIOs ?
> > for x in range(0,256):
> >     mhex=("0x%0.2X" % x)
> >     os.system("hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK "+mhex)
> >     os.system("hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIRECTION "+mhex)
> >     os.system("hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA "+mhex)
> > I think its not correct gpio_direction i guess could be only 0 or 1?
> > What happens when I pass a different value to data than 0/1 ? this should
> > also not be correct.
> > I guess 0x01 is the NID value is it okay to use 0x01 only or I have to
> pass
> > other values to it also ?
>
> Yes, NID 0x01 is usually the right value, which means AFG.
>
> BTW, I noticed that there is some downstream patch.  Is it the repo
> you mentioned earlier?
>
> https://github.com/joelkraehemann/hda-tool/blob/master/patch_cirrus.c.patch
>
> Did you try that?
>
>
> Takashi
>
> > On Sat, Aug 4, 2018 at 8:13 PM, Takashi Iwai <tiwai at suse.de> wrote:
> >
> > > Please don't drop Cc to ML.  Also avoid top-posting.
> > >
> > > On Sat, 04 Aug 2018 19:02:53 +0200,
> > > David Ulricht wrote:
> > > >
> > > > How can I do that ?
> > > > I tried verifying if /proc/asound/card0/codec#0 changes when i put
> > > > handphone jack in and out with "diff ver1 ver2" and it is exactly the
> > > same.
> > >
> > > Just do for each bit as you tried for GPIO output.  In this case, the
> > > direction bit should be different (set 0), and you need to read.
> > >
> > > >
> > > > One strange thing I note is hda-jack-retask.fw contains:
> > > > [pincfg]
> > > > 0x24 0x90100080
> > > > 0x25 0x90100082
> > > > I have 0x90100080 for 0x24 but in /proc/asound/card0/codec#0 :
> > > > Node 0x24 [Pin Complex] wcaps 0x400101: Stereo
> > > >   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
> > > >      0x02
> > > >
> > > > Shouldn't "Pin Default 0x90100110" be 0x90100080 after applying the
> > > patch ?
> > >
> > > No, the codec config value itself won't change, the driver uses the
> > > given value only internally.
> > >
> > >
> > > Takashi
> > >
> > > > I can see that  Applying patch firmware 'hda-jack-retask.fw' is
> before
> > > > hdaudioC0D0: autoconfig for Generic: line_outs=2
> (0x24/0x25/0x0/0x0/0x0)
> > > > type:speaker
> > > > in dmesg and this worries me, maybe the pins are overriden by generic
> > > > cirrus logic ?
> > > >
> > > >
> > > > On Sat, Aug 4, 2018 at 7:26 PM, Takashi Iwai <tiwai at suse.de> wrote:
> > > >
> > > > > On Sat, 04 Aug 2018 17:44:59 +0200,
> > > > > David Ulricht wrote:
> > > > > >
> > > > > > I used the following script running as root to verify the 8 GPIOs
> > > while
> > > > > > playing long youtube video,
> > > > > > I have running pulseaudio meanwhile and not restarting it, i
> think
> > > its
> > > > > okay
> > > > > > like that people on the ubuntu forums say that after using
> > > > > > hda-verb and setting a gpio active immediately sound appears, so
> i
> > > guess
> > > > > > there is no need to restart pulseaudio.
> > > > > > I have done the same test with headphones in.
> > > > > > No sound in both scenarios, no input no output detected (i'm
> watching
> > > > > > pavucontrol for input detection).
> > > > >
> > > > > This codec is fairly unique and doesn't provide the standard jack
> > > > > detection on each pin.  Maybe it's via either GPIO or any other
> > > > > method.  You can try to read GPIO pins (set as input) to see
> whether
> > > > > any of them corresponds to the jack detection, for example.
> > > > >
> > > > >
> > > > > Takashi
> > > > >
> > > > > >
> > > > > > #!/usr/bin/env python3
> > > > > > import os,time
> > > > > > for x in range(0,256):
> > > > > >     mhex=("0x%0.2X" % x)
> > > > > >     os.system("hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK
> "+mhex)
> > > > > >     os.system("hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIRECTION
> > > "+mhex)
> > > > > >     os.system("hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA
> "+mhex)
> > > > > >     time.sleep(3)
> > > > > >
> > > > > > Meanwhile script is running I'm watching
> /proc/asound/card0/codec#0
> > > and
> > > > > > IO[0-7] changes its configuration,
> > > > > > in comparison Joel Krahemann in his scripts is changing the hex
> right
> > > > > after
> > > > > > /dev/snd/hwC0D0 (0x01) e.g. i dont think he is modifiying the
> GPIOs
> > > > > > correctly.
> > > > > >
> > > > > > I found the following post:
> > > > > > https://forum.manjaro.org/t/sound-not-working-on-a-2017-
> > > > > imac-27-5k-retina/43638
> > > > > > According to https://bugzilla.kernel.org/show_bug.cgi?id=195671
> > > iMac27
> > > > > has
> > > > > > a similar soundcard.
> > > > > > How can i setup with command line or any other utility:
> > > > > > """select “off” in the top menu that propose to setup the Digital
> > > > > > Surround"""
> > > > > > this is some setting in xfce4-mixer package which is not
> available
> > > for
> > > > > > ubuntu since 2 LTS versions behind. I tried current Manjaro and
> > > couldn't
> > > > > > find this setting in audio mixer of xfce4 either.
> > > > > >
> > > > > > On Sat, Aug 4, 2018 at 9:48 AM, Takashi Iwai <tiwai at suse.de>
> wrote:
> > > > > >
> > > > > > > On Sat, 04 Aug 2018 04:07:43 +0200,
> > > > > > > David Ulricht wrote:
> > > > > > > >
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > Macbook pro models containing CS8409 for sure are:
> > > > > > > > MBP131 MBP141.I own MBP 14,1 e.g. 2017 model.
> > > > > > > >
> > > > > > > > I'm attaching working sound configuration from Windows 10
> > > registry
> > > > > (note
> > > > > > > > that the cs420x might need to be ignored or might be
> important i
> > > > > don't
> > > > > > > > really know). I believe what is really used is in the
> > > > > PinConfigOverride
> > > > > > > > section.
> > > > > > >
> > > > > > > Comparing between BIOS default (init_pin_cfg in alsa-info.sh
> > > output)
> > > > > > > and your override (user_pin_cfg), there aren't so many changes.
> > > > > > > All changes are pretty minor, and I guess it won't influence
> on the
> > > > > > > driver behavior.
> > > > > > >
> > > > > > > > Interesting thing to note is that sound in MacOS is much
> louder
> > > than
> > > > > > > > Bootcamp Windows, would be nice to hear how loud is on linux.
> > > > > > >
> > > > > > > This is possibly with some vendor-specific GPIO or COEF verbs.
> > > > > > > Or it's some direct I2C control.  The INI file mentions it.
> > > > > > > And that's above HD-audio driver's responsibility.
> > > > > > >
> > > > > > > > I did convert PinConfigOverride HEX strings to [pincfg]
> format
> > > in the
> > > > > > > > attached hda-jack-retask.fw thanks to Takashi's guidance.
> > > > > > > >
> > > > > > > > I'm attaching also alsamixer ASCII. Only PCM, no Master ?
> > > > > > >
> > > > > > > It's because the codec chip has no output amplifier at all.
> > > > > > > So there can be neither output volume nor mute control on this
> > > chip.
> > > > > > >
> > > > > > > > What I have tried is execute:
> > > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x@@
> > > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIRECTION 0x@@
> > > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x@@
> > > > > > > > putting @@ from 0x00 to 0x50
> > > > > > >
> > > > > > > There are eight GPIOs, so you'd need to test each bit, i.e.
> 0x01,
> > > > > > > 0x02, 0x04, 0x08, ... 0x80.
> > > > > > >
> > > > > > > And how is the current situation?  You can't play *and* record
> > > > > > > anything from any inputs / outputs?
> > > > > > >
> > > > > > >
> > > > > > > Takashi
> > > > > > >
> > > > > > [2  <text/html; UTF-8 (quoted-printable)>]
> > > > > >
> > > > >
> > > > [2  <text/html; UTF-8 (quoted-printable)>]
> > > >
> > >
> > [2  <text/html; UTF-8 (quoted-printable)>]
> >
>

More information about the Alsa-devel mailing list