[alsa-devel] CS8409 Macbook Pro 2016 2017

David Ulricht david.ulricht434 at gmail.com
Sat Aug 4 22:30:29 CEST 2018


 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.

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?

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 ?


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)>]
> >
>


More information about the Alsa-devel mailing list