[alsa-devel] CS8409 Macbook Pro 2016 2017
Takashi Iwai
tiwai at suse.de
Fri Nov 16 15:36:26 CET 2018
On Fri, 16 Nov 2018 15:02:15 +0100,
David Ulricht wrote:
>
> 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.
The stuff in sound/i2c/* are mostly for the i2c bus on a PCI sound
cards, an implementation independent from the standard i2c stuff.
And, in your case, it's hard to know how the i2c bus is connected.
If it's controlled over HD-audio GPIO pin (one for clk and one for
data), then some stuff in sound/i2c can be re-used. Or, if it's on
another i2c bus, the story will be completely different...
Takashi
> 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
N> > 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