Re: [alsa-devel] CS8409 Macbook Pro 2016 2017
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@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@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)>]
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@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@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@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)>]
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@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@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@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)>]
OK, then it's not about GPIO, something else. It's hard to know without the datasheet...
Can't we get a little help from Cirrus Logic, unofficially not breaking NDA someone from them to pretend to be a noob that tried few things and actually give us some hints? Doubt they will drop us the datasheet.
Yes, NID 0x01 is usually the right value, which means AFG.
At least I understood correctly and learned something.
Then what comes to mind is that my [pincfg] might be wrong or actually not applying correctly in the driver if I cannot verify it from the codec#0 file as you said, you sure the C code of that generic Cirrus Logic won't interfere somehow ? What comes to my mind is some type of simple test C code that sends to the device some continuous sound from C code using the [pincfg] I got from Windows, do you happen to have that ? Do those codecs have this Beep sound that is present in the codec#0 as an output device, can't we try to make the sound card beep ? Anything to prove we can interact with it somehow.
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?
Not really, I have checked his posts in the bugzilla and he says that this is the fixups for iMac27 and the card there is slightly different, and he mentioned December 2017 that none of he tried works, and the code age is earlier. Plus I don't see a single place where he uses my [pincfg] e.g. 0x24 and 0x25 for speakers, he mentioned he tried 0x2b 0x2c if not mistaken, and think that are the speakers. https://bugzilla.kernel.org/show_bug.cgi?id=195671 He mentions that he thinks its integrated circuit MAX98357BEWL.Which I can't confirm but well it might be.
I tried to get to debug Windows kernel driver but happens that the Macbook pro 2017 13 nontb has only 2 Thunderbolt3 ports, and to debug the kernel drive you need a supported Ethernet device officially by microsoft, and mine usb-c ethernet is a new Realtek that is not supported, I'll need to find a usb2,3 ethernet that has a supported chip which might be difficult, no guarantee I will understand anything from the windows kernel debugging.
Note that when you insert Thunderbolt3 adapter, that has HDMI adapter, the Audio over HDMI is working, multiple sources confirmed this. I suspect that the kernel enables HDMI audio and apple might have integrated hardware automatic switch when you enable HDMI internal sound card turns off, is there any way that I can prohibit HDMI audio codec#2 not even to load during kernel boot? Is that even possible to disable the HDMI audio if it comes from the i915 video card ? Does the above make sense at all ?
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@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@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@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@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)>]
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@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@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@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@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)>] >
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...
I have the schematics of the CS8409. the i2c is connected to the GPIO of the HDA.
MAX98374 has a Reset Low pin which is connected to GPIO 5 on the HDA controller CS8409. This must be driven high, then wait for 1.5 ms. Only then will the amps be out of device shutdown. GPIO6 is 8409_I2C_SCL GPIO7 is 8409_I2C_SDA
GPIO5 is AUD_SPKRAMP_RESET_L
Knowing GPIO6 is the clock and GPIO7 is the data, how can I use them? Can I use hda-verb /dev/snd/hwC0D0 0x01 XXX YYY ? what XXX YYY would be ?
On Fri, 16 Nov 2018 17:50:24 +0100, David Ulricht wrote:
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...I have the schematics of the CS8409. the i2c is connected to the GPIO of the HDA.
MAX98374 has a Reset Low pin which is connected to GPIO 5 on the HDA controller CS8409. This must be driven high, then wait for 1.5 ms. Only then will the amps be out of device shutdown. GPIO6 is 8409_I2C_SCL GPIO7 is 8409_I2C_SDA
GPIO5 is AUD_SPKRAMP_RESET_L
Knowing GPIO6 is the clock and GPIO7 is the data, how can I use them? Can I use hda-verb /dev/snd/hwC0D0 0x01 XXX YYY ? what XXX YYY would be ?
You need to set GPIO mask, direction then data. 0x01 SET_GPIO_MASK 0xXX 0x01 SET_GPIO_DIR 0xXX 0x01 SET_GPIO_DATA 0xXX
The value to be pass is the bits. GPIO0=0x01, GPIO1=0x02, GPIO3=0x04, ...
You can read the data after setting mask and dir by 0x01 GET_GPIO_DATA. Pass 0 for the value, and you'll get a byte value as a read result.
Takashi
I have found the schematics of the board its model A1708: http://sualaptop365.edu.vn/threads/apple-macbook-pro-13-a1708-820-00875-051-... page 48 CS8409 audio codec GPIO7 is SDA GPIO6 is SCL. page 50: the four SSM3515B amplifiers connected to CS8409's I2C SDA/SCL have found the datasheet of SSM3515 amplifiers as well: https://www.analog.com/media/en/technical-documentation/data-sheets/SSM3515.... Documentation says: If the REG_EN pin is tied to the PVDD the power-up sequence is performed internally. According to the SSM3515B REG_EN is also called C2. According to the 1708 schematics(page 50) REG_EN also called C2, is connected to ground. This means if REG_EN is connected to ground, it uses an external 1.8V regulator (page 19 of SSM3515 pdf). e.g. the device needs to be initialized via i2c commands. This means the 4 amplifiers SSM3515B need to be initialized via i2c, because simply apple decided to disable them by default for some reason probably save power while booting for example. Now I need to figure out how to send the i2c commands i have from windows10. page 21: describes the I2C control which should be of help
The following windows 10 registry about i2c maybe of help, it has the slaves addresses, the start/stop the powerup2c commands, everything needed...: "I2CSpeedMode"=dword:00000001 "I2CPolledMode"=dword:00000001 "I2CQuickMode"=dword:00000001 "I2CBusClear"=dword:00000006 "I2CSlave90Config"=dword:01002090 "InitI2C"=hex:01,90,3a,00,10,10,b0,00,1d,01,00,02,06,00,11,07,01,00,10,09,02,\
07,03,00,12,01,00,08,13,05,ff,06,00,07,20,02,0d,00,2a,02,02,03,00,04,00,05,\
02,06,00,07,20,08,02,09,00,0a,80,0b,02,0c,00,0d,a0,01,0c,00,29,02,01,03,02,\
04,00,05,00,01,01,00,11,01,0a,02,84,00,23,01,00,03,00,02,3f,00,20,01,03,00,\ 1b,75,b6,73,c2,00,11,29,01,21,f3,03,20,05,00,12,00,13,80,00,1c,03,c0 "n0AStreamStartI2C"=hex:01,90,02,00,11,01,02 "n0AStreamStopI2C"=hex:01,90,02,00,11,01,0a "I2CSlave28Config"=dword:00004028 "I2CSlave2AConfig"=dword:0000402a "I2CSlave2CConfig"=dword:0000402c "I2CSlave2EConfig"=dword:0000402e "n02PwrUpI2C"=hex:04,28,2a,2c,2e,07,00,81,01,11,02,32,03,48,04,11,05,10,00,80 "n03PwrUpI2C"=hex:01,28,01,05,00,01,2a,01,05,02,01,2c,01,05,01,01,2e,01,05,03 "ExitI2C"=hex:04,28,2a,2c,2e,01,00,83 "EQ1S1R7"=hex:1e,b2,9a,1a,df,15,c6,f4,11,19,91,ae,c6,f4,11,16,3b,23,16,3b,23,\ d3,89,b9,1f,88,d9,c0,78,b8 "EQ1S2R7"=hex:16,3d,23,16,3d,23,d3,85,bb,1f,8e,8e,c0,73,03,14,62,da,12,94,45,\ d9,23,c2,1d,b9,a4,c2,61,3d
Now comes the problem that I cannot write my own i2c driver to power up the 4 SSM3515B amps via the I2C on GPIO7/6 on CS8409. I have no idea how to get a pointer to the i2c interface knowing the GPIO7/6 are the i2c interface. If someone helps me to get a C pointer to the i2c bus, I might be able to read/write to it and test and figure it out. I have only experimented with real i2c bus on Raspberry Pi with C code, and it is completely different. I have there an /dev/i2c-l device that I can write to file handle the bytes. Please advise.
On Fri, Nov 16, 2018 at 7:31 PM Takashi Iwai tiwai@suse.de wrote:
On Fri, 16 Nov 2018 17:50:24 +0100, David Ulricht wrote:
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...I have the schematics of the CS8409. the i2c is connected to the GPIO of
the
HDA.
MAX98374 has a Reset Low pin which is connected to GPIO 5 on the HDA controller CS8409. This must be driven high, then wait for 1.5 ms. Only then will the amps be out of device shutdown. GPIO6 is 8409_I2C_SCL GPIO7 is 8409_I2C_SDA
GPIO5 is AUD_SPKRAMP_RESET_L
Knowing GPIO6 is the clock and GPIO7 is the data, how can I use them? Can I use hda-verb /dev/snd/hwC0D0 0x01 XXX YYY ? what XXX YYY would be ?
You need to set GPIO mask, direction then data. 0x01 SET_GPIO_MASK 0xXX 0x01 SET_GPIO_DIR 0xXX 0x01 SET_GPIO_DATA 0xXX
The value to be pass is the bits. GPIO0=0x01, GPIO1=0x02, GPIO3=0x04, ...
You can read the data after setting mask and dir by 0x01 GET_GPIO_DATA. Pass 0 for the value, and you'll get a byte value as a read result.
Takashi
On Mon, 19 Nov 2018 18:30:15 +0100, David Ulricht wrote:
I have found the schematics of the board its model A1708: http://sualaptop365.edu.vn/threads/apple-macbook-pro-13-a1708-820-00875-051-... page 48 CS8409 audio codec GPIO7 is SDA GPIO6 is SCL. page 50: the four SSM3515B amplifiers connected to CS8409's I2C SDA/SCL have found the datasheet of SSM3515 amplifiers as well: https://www.analog.com/media/en/technical-documentation/data-sheets/SSM3515.... Documentation says: If the REG_EN pin is tied to the PVDD the power-up sequence is performed internally. According to the SSM3515B REG_EN is also called C2. According to the 1708 schematics(page 50) REG_EN also called C2, is connected to ground. This means if REG_EN is connected to ground, it uses an external 1.8V regulator (page 19 of SSM3515 pdf). e.g. the device needs to be initialized via i2c commands. This means the 4 amplifiers SSM3515B need to be initialized via i2c, because simply apple decided to disable them by default for some reason probably save power while booting for example. Now I need to figure out how to send the i2c commands i have from windows10. page 21: describes the I2C control which should be of help
The following windows 10 registry about i2c maybe of help, it has the slaves addresses, the start/stop the powerup2c commands, everything needed...: "I2CSpeedMode"=dword:00000001 "I2CPolledMode"=dword:00000001 "I2CQuickMode"=dword:00000001 "I2CBusClear"=dword:00000006 "I2CSlave90Config"=dword:01002090 "InitI2C"=hex:01,90,3a,00,10,10,b0,00,1d,01,00,02,06,00,11,07,01,00,10,09,02,\ 07,03,00,12,01,00,08,13,05,ff,06,00,07,20,02,0d,00,2a,02,02,03,00,04,00,05,\ 02,06,00,07,20,08,02,09,00,0a,80,0b,02,0c,00,0d,a0,01,0c,00,29,02,01,03,02,\ 04,00,05,00,01,01,00,11,01,0a,02,84,00,23,01,00,03,00,02,3f,00,20,01,03,00,\ 1b,75,b6,73,c2,00,11,29,01,21,f3,03,20,05,00,12,00,13,80,00,1c,03,c0 "n0AStreamStartI2C"=hex:01,90,02,00,11,01,02 "n0AStreamStopI2C"=hex:01,90,02,00,11,01,0a "I2CSlave28Config"=dword:00004028 "I2CSlave2AConfig"=dword:0000402a "I2CSlave2CConfig"=dword:0000402c "I2CSlave2EConfig"=dword:0000402e "n02PwrUpI2C"=hex:04,28,2a,2c,2e,07,00,81,01,11,02,32,03,48,04,11,05,10,00,80 "n03PwrUpI2C"=hex:01,28,01,05,00,01,2a,01,05,02,01,2c,01,05,01,01,2e,01,05,03 "ExitI2C"=hex:04,28,2a,2c,2e,01,00,83 "EQ1S1R7"=hex:1e,b2,9a,1a,df,15,c6,f4,11,19,91,ae,c6,f4,11,16,3b,23,16,3b,23,\ d3,89,b9,1f,88,d9,c0,78,b8 "EQ1S2R7"=hex:16,3d,23,16,3d,23,d3,85,bb,1f,8e,8e,c0,73,03,14,62,da,12,94,45,\ d9,23,c2,1d,b9,a4,c2,61,3d
Now comes the problem that I cannot write my own i2c driver to power up the 4 SSM3515B amps via the I2C on GPIO7/6 on CS8409. I have no idea how to get a pointer to the i2c interface knowing the GPIO7/6 are the i2c interface. If someone helps me to get a C pointer to the i2c bus, I might be able to read /write to it and test and figure it out. I have only experimented with real i2c bus on Raspberry Pi with C code, and it is completely different. I have there an /dev/i2c-l device that I can write to file handle the bytes. Please advise.
You should try to initialize over i2c over HD-audio GPIO pins using a user-space program at first. The GPIO pins can be read/written via hda-verb as I already mentioned, hence you can access to i2c bus from the user-space directly.
Once when it's confirmed to work from user-space, we can think of the kernel-side implementation, too. Instead of setting up the whole complex i2c subsystem, we may wire up the existing stuff in sound/i2c/*, too.
Takashi
On Fri, Nov 16, 2018 at 7:31 PM Takashi Iwai tiwai@suse.de wrote:
On Fri, 16 Nov 2018 17:50:24 +0100, David Ulricht wrote: > > 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... > > I have the schematics of the CS8409. the i2c is connected to the GPIO of the > HDA. > > MAX98374 has a Reset Low pin which is connected to GPIO 5 on the HDA > controller CS8409. This must > be driven high, then wait for 1.5 ms. Only then will the amps be out of > device shutdown. > GPIO6 is 8409_I2C_SCL > GPIO7 is 8409_I2C_SDA > > GPIO5 is AUD_SPKRAMP_RESET_L > > Knowing GPIO6 is the clock and GPIO7 is the data, how can I use them? > Can I use hda-verb /dev/snd/hwC0D0 0x01 XXX YYY ? what XXX YYY would be ? You need to set GPIO mask, direction then data. 0x01 SET_GPIO_MASK 0xXX 0x01 SET_GPIO_DIR 0xXX 0x01 SET_GPIO_DATA 0xXX The value to be pass is the bits. GPIO0=0x01, GPIO1=0x02, GPIO3=0x04, ... You can read the data after setting mask and dir by 0x01 GET_GPIO_DATA. Pass 0 for the value, and you'll get a byte value as a read result. Takashi
Once when it's confirmed to work from user-space, we can think of the kernel-side implementation, too. Instead of setting up the whole complex i2c subsystem, we may wire up the existing stuff in sound/i2c/*, too.
Okay
You should try to initialize over i2c over HD-audio GPIO pins using a
user-space program at first. The GPIO pins can be read/written via hda-verb as I already mentioned, hence you can access to i2c bus from the user-space directly.
I have written the following bash script,
#!/bin/bash # DIR 0 (low) = out 40 (high) = in # low to write, high to read # SCL == 0x40 SDA == 0x80 function send() { str1=$1 str2=$2 str3=$3 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x$str1 # we send 0 to bus by enabling gpio_dir hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x$str2 # we send data=0 to send to the bus hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x$str3 } # reads the values I set, no different return value from i2c/codec function recv() { hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_MASK 0x$str1 hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DIR 0x$str2 hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DATA 0x$str3 }
function send_sequence() { data=$1 #split hexes by coma to be able to send 1 by 1 hexes=$(echo $data|tr "," "\n") for hex in $hexes; do echo 'sending hex: ' $hex send 40 0 0 # 0 to scl
mask of SCL enabled, data 0 , dir 0, is that correct ?
sleep 0.003 send 80 0 $hex # send 0x28 to sda if $hex=28
mask of SDA enabled, direction 0, hex to data
sleep 0.003 send 0 40 40 # 1 to scl
mask of SCL disabled, direction 1, data 1
sleep 0.003 echo sent done}
below i'm sending the hexes from Win10ini but in the exact same order, which worries me a bit, maybe they need to be reversed 4by4? like 01,90,02,00,11,01,02 could become: 00,02,90,01,02,01,11 .. because for the InitVerbs i did that reversing 4by4 and it works only correctly if the hexes are reversed 4by4. (at the end of the email i am attaching the exitverbs conversion which is perfect).
#initi2c send_sequence "01,90,3a,00,10,10,b0,00,1d,01,00,02,06,00,11,07,01,00,10,09,02,07,03,00,12,01,00,08,13,05,ff,06,00,07,20,02,0d,00,2a,02,02,03,00,04,00,05,02,06,00,07,20,08,02,09,00,0a,80,0b,02,0c,00,0d,a0,01,0c,00,29,02,01,03,02,04,00,05,00,01,01,00,11,01,0a,02,84,00,23,01,00,03,00,02,3f,00,20,01,03,00,1b,75,b6,73,c2,00,11,29,01,21,f3,03,20,05,00,12,00,13,80,00,1c,03,c0" #streamstarti2c send_sequence "01,90,02,00,11,01,02" #powerup-amps send_sequence "04,28,2a,2c,2e,07,00,81,01,11,02,32,03,48,04,11,05,10,00,80" send_sequence "01,28,01,05,00,01,2a,01,05,02,01,2c,01,05,01,01,2e,01,05,03" #streamstopi2c send_sequence "01,90,02,00,11,01,0a" #echo read #recv 0 0 0
For example something that works is "ExitVerbs"=hex:00,05,17,00,01,00,75,04,00,00,74,04,82,00,75,04,00,00,74,04,03,\
00,75,04,00,80,74,04,04,00,75,04,01,28,74,04,06,00,75,04,00,80,74,04,07,00,\ 75,04,01,28,74,04,65,00,75,04,00,00,74,04,00,03,77,04,03,05,17,00
hda-verb /dev/snd/hwC0D0 0x01 0x705 0x00 hda-verb /dev/snd/hwC0D0 0x47 0x500 0x01 hda-verb /dev/snd/hwC0D0 0x47 0x400 0x00 hda-verb /dev/snd/hwC0D0 0x47 0x500 0x82 hda-verb /dev/snd/hwC0D0 0x47 0x400 0x00 hda-verb /dev/snd/hwC0D0 0x47 0x500 0x03 hda-verb /dev/snd/hwC0D0 0x47 0x480 0x00 hda-verb /dev/snd/hwC0D0 0x47 0x500 0x04 hda-verb /dev/snd/hwC0D0 0x47 0x428 0x01 hda-verb /dev/snd/hwC0D0 0x47 0x500 0x06 hda-verb /dev/snd/hwC0D0 0x47 0x480 0x00 hda-verb /dev/snd/hwC0D0 0x47 0x500 0x07 hda-verb /dev/snd/hwC0D0 0x47 0x428 0x01 hda-verb /dev/snd/hwC0D0 0x47 0x500 0x65 hda-verb /dev/snd/hwC0D0 0x47 0x400 0x00 hda-verb /dev/snd/hwC0D0 0x47 0x703 0x00 hda-verb /dev/snd/hwC0D0 0x01 0x705 0x03
Also InitVerbs from windows10ini and ExitVerbs from windows10ini reversed
hexes 4by4 sent with hda-verb work perfect. They initiate the CS8409 codec or shut it down properly as i can see in the codec#0 status changing from D3 to D0 and D0 to D3. But the above exitverbs are sent to the widgets AFG node and the 0x47 widget, (InitVerbs have a few more widgets).
I tried to do the same for the InitI2C hexes, but apperently they are not supposed to be send as hexes directly to the widgets like InitVerbs or ExitVerbs. All the I2C related stuff are strictly I2C related for executing on the SDA/SCL GPIO7/6.
So my idea is, do I need to reverse the hexes 4 by 4, when sending to the SDA ? And if you have any examples how can i get a read value from the SDA please.
Btw: root@debian:~# cat /proc/asound/card0/codec#0 |head -n 25|tail -n 8 IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[4]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[5]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[6]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[7]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 the default values are IO7 which is GPIO7 which is SDA. is enabled=0 dir=0 data=0
root@debian:~# hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x80 nid = 0x1, verb = 0x716, param = 0x80 value = 0x0 root@debian:~# hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0 nid = 0x1, verb = 0x717, param = 0x0 value = 0x0 root@debian:~# hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x28 nid = 0x1, verb = 0x715, param = 0x28 value = 0x0 After i send the above, data becomes data=1 but i sent 0x28.
root@debian:~# cat /proc/asound/card0/codec#0 |head -n 25|tail -n 8 IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[4]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[5]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[6]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[7]: enable=1, dir=0, wake=0, sticky=0, data=1, unsol=0
But if i read GPIO_DATA, root@debian:~# hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DATA 0x0 nid = 0x1, verb = 0xf15, param = 0x0 value = 0x80
the value returned is 0x80. Which leads me to the idea the only type of data you can send is either 0x40 for 1 on SCL, 0x80 for 1 on SDA, or 0x00 for 0 on both( if you enable mask of SCL it will send 0 to SCL only, and if you enable mask of SDA it will send 0 to SDA only).
If thats true, you can only send 0/1 to the GPIOs, which means if i have to send the address of 1st SSM3515 "0x28", I have to send it as "101000" to the SDA.
How could I try to read register 0x00 of I2C address 0x28 (one of the four SSM3515 amplifier) ? It should return value 0x83 according to the documentation of SSM3515 as a "reset value for register 0x00".
If it is true that I can read data with GET_GPIO_DATA will it return as well only one bit of data like 0/1 at a time? If I need get a value of 0x83 thru the GPIO7 its binary value should be 10000011 , so this means that If i execute GET_GPIO_DATA 8 times in a row i will receive this piece by piece 1, 0 , 0 , 0 , 0 , 0 , 1, 1. Meanwhile I try to execute 8 times GET_GPIO_DATA should i be sending to the SCL (GPIO6) each time a clock value 0 ? or also a SET_GPIO_DATA value to the GPIO7 with value 0 for reading? Please advise.
One thing to note on all I2C interfaces is that when GPIO is driven high (IN direction,dir=0) on the master (e.g. CS8409), SDA should be a constant HIGH, e.g. data=1. No matter if there is any I2C device connected to the bus, if you have a pull-up it will always pull-up the constant value 1. This 1 is usually a NACK that get received if you dont find the address.
So far I couldn't get the IO[7] (SDA) with dir=0 (in,also known as HIGH direction) to deliver a data=1. IO[7] is with constant data=0. This means the pull-up is not pulling 1, and the I2C interface is not enabled by default after reset of the CS8409 codec. this is expected value for enabled I2C: IO[7]: enable=1, dir=0, wake=0, sticky=0, data=*1*, unsol=0 but what I get is: IO[7]: enable=1, dir=0, wake=0, sticky=0, data=0, unsol=0 which means I2C mode not initialized.
I was just going to give up totally, and i looked up into one of my emails where i found the following: IO[7]: enable=1, dir=0, wake=0, sticky=0, data=1, unsol=0 after using my amateur send_sequence script (when i had no idea how I2C works) or some random sequence of events i executed and I had at this point IO[7] data as HIGH which means I2C was working at that exact moment.
tho i did decipher the GPIO1ExtAmpCFG=hex:01,00,00,01 which if you check the schematics, the daisy-chained CS42L83A codec is powered by GPIO1 on CS8409 by keeping data=1, because there is pull-down on the CS42L83A's CODEC_RESET_L. There is also CODEC_INT_L which is the interrupt line, which is directly tied to GPIO[0] on CS8409. This actually returns a constant data=1, which gives some hope as well. IO[0]: enable=1, dir=0, wake=0, sticky=0, data=*1*, unsol=1
Opening AppleHDA in IDA reveals AppleHDAFunctionGroupCS4208::enableI2C(bool) Anyone knowing anything about TDM Config in Cirrus Logic ? Enabling I2C ? Is it Vendor specific verb ? Maybe it's some general way on most HDA's ? The reason to have I2C disabled on reset is that some of the devices like the amps and the speakers need to be configured in a specific order to save power and to avoid sound glitches.
On Fri, Nov 23, 2018 at 7:26 PM David Ulricht david.ulricht434@gmail.com wrote:
Once when it's confirmed to work from user-space, we can think of the
kernel-side implementation, too. Instead of setting up the whole complex i2c subsystem, we may wire up the existing stuff in sound/i2c/*, too.
Okay
You should try to initialize over i2c over HD-audio GPIO pins using a
user-space program at first. The GPIO pins can be read/written via hda-verb as I already mentioned, hence you can access to i2c bus from the user-space directly.
I have written the following bash script,
#!/bin/bash # DIR 0 (low) = out 40 (high) = in # low to write, high to read # SCL == 0x40 SDA == 0x80 function send() { str1=$1 str2=$2 str3=$3 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x$str1 # we send 0 to bus by enabling gpio_dir hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x$str2 # we send data=0 to send to the bus hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x$str3 } # reads the values I set, no different return value from i2c/codec function recv() { hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_MASK 0x$str1 hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DIR 0x$str2 hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DATA 0x$str3 }
function send_sequence() { data=$1 #split hexes by coma to be able to send 1 by 1 hexes=$(echo $data|tr "," "\n") for hex in $hexes; do echo 'sending hex: ' $hex send 40 0 0 # 0 to scl
mask of SCL enabled, data 0 , dir 0, is that correct ?
sleep 0.003 send 80 0 $hex # send 0x28 to sda if $hex=28mask of SDA enabled, direction 0, hex to data
sleep 0.003 send 0 40 40 # 1 to sclmask of SCL disabled, direction 1, data 1
sleep 0.003 echo sent done}
below i'm sending the hexes from Win10ini but in the exact same order, which worries me a bit, maybe they need to be reversed 4by4? like 01,90,02,00,11,01,02 could become: 00,02,90,01,02,01,11 .. because for the InitVerbs i did that reversing 4by4 and it works only correctly if the hexes are reversed 4by4. (at the end of the email i am attaching the exitverbs conversion which is perfect).
#initi2c send_sequence "01,90,3a,00,10,10,b0,00,1d,01,00,02,06,00,11,07,01,00,10,09,02,07,03,00,12,01,00,08,13,05,ff,06,00,07,20,02,0d,00,2a,02,02,03,00,04,00,05,02,06,00,07,20,08,02,09,00,0a,80,0b,02,0c,00,0d,a0,01,0c,00,29,02,01,03,02,04,00,05,00,01,01,00,11,01,0a,02,84,00,23,01,00,03,00,02,3f,00,20,01,03,00,1b,75,b6,73,c2,00,11,29,01,21,f3,03,20,05,00,12,00,13,80,00,1c,03,c0" #streamstarti2c send_sequence "01,90,02,00,11,01,02" #powerup-amps send_sequence "04,28,2a,2c,2e,07,00,81,01,11,02,32,03,48,04,11,05,10,00,80" send_sequence "01,28,01,05,00,01,2a,01,05,02,01,2c,01,05,01,01,2e,01,05,03" #streamstopi2c send_sequence "01,90,02,00,11,01,0a" #echo read #recv 0 0 0
For example something that works is
"ExitVerbs"=hex:00,05,17,00,01,00,75,04,00,00,74,04,82,00,75,04,00,00,74,04,03,\
00,75,04,00,80,74,04,04,00,75,04,01,28,74,04,06,00,75,04,00,80,74,04,07,00,\ 75,04,01,28,74,04,65,00,75,04,00,00,74,04,00,03,77,04,03,05,17,00
hda-verb /dev/snd/hwC0D0 0x01 0x705 0x00 hda-verb /dev/snd/hwC0D0 0x47 0x500 0x01 hda-verb /dev/snd/hwC0D0 0x47 0x400 0x00 hda-verb /dev/snd/hwC0D0 0x47 0x500 0x82 hda-verb /dev/snd/hwC0D0 0x47 0x400 0x00 hda-verb /dev/snd/hwC0D0 0x47 0x500 0x03 hda-verb /dev/snd/hwC0D0 0x47 0x480 0x00 hda-verb /dev/snd/hwC0D0 0x47 0x500 0x04 hda-verb /dev/snd/hwC0D0 0x47 0x428 0x01 hda-verb /dev/snd/hwC0D0 0x47 0x500 0x06 hda-verb /dev/snd/hwC0D0 0x47 0x480 0x00 hda-verb /dev/snd/hwC0D0 0x47 0x500 0x07 hda-verb /dev/snd/hwC0D0 0x47 0x428 0x01 hda-verb /dev/snd/hwC0D0 0x47 0x500 0x65 hda-verb /dev/snd/hwC0D0 0x47 0x400 0x00 hda-verb /dev/snd/hwC0D0 0x47 0x703 0x00 hda-verb /dev/snd/hwC0D0 0x01 0x705 0x03
Also InitVerbs from windows10ini and ExitVerbs from windows10ini reversed
hexes 4by4 sent with hda-verb work perfect. They initiate the CS8409 codec or shut it down properly as i can see in the codec#0 status changing from D3 to D0 and D0 to D3. But the above exitverbs are sent to the widgets AFG node and the 0x47 widget, (InitVerbs have a few more widgets).
I tried to do the same for the InitI2C hexes, but apperently they are not supposed to be send as hexes directly to the widgets like InitVerbs or ExitVerbs. All the I2C related stuff are strictly I2C related for executing on the SDA/SCL GPIO7/6.
So my idea is, do I need to reverse the hexes 4 by 4, when sending to the SDA ? And if you have any examples how can i get a read value from the SDA please.
Btw: root@debian:~# cat /proc/asound/card0/codec#0 |head -n 25|tail -n 8 IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[4]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[5]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[6]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[7]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 the default values are IO7 which is GPIO7 which is SDA. is enabled=0 dir=0 data=0
root@debian:~# hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x80 nid = 0x1, verb = 0x716, param = 0x80 value = 0x0 root@debian:~# hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0 nid = 0x1, verb = 0x717, param = 0x0 value = 0x0 root@debian:~# hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x28 nid = 0x1, verb = 0x715, param = 0x28 value = 0x0 After i send the above, data becomes data=1 but i sent 0x28.
root@debian:~# cat /proc/asound/card0/codec#0 |head -n 25|tail -n 8 IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[4]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[5]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[6]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[7]: enable=1, dir=0, wake=0, sticky=0, data=1, unsol=0
But if i read GPIO_DATA, root@debian:~# hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DATA 0x0 nid = 0x1, verb = 0xf15, param = 0x0 value = 0x80
the value returned is 0x80. Which leads me to the idea the only type of data you can send is either 0x40 for 1 on SCL, 0x80 for 1 on SDA, or 0x00 for 0 on both( if you enable mask of SCL it will send 0 to SCL only, and if you enable mask of SDA it will send 0 to SDA only).
If thats true, you can only send 0/1 to the GPIOs, which means if i have to send the address of 1st SSM3515 "0x28", I have to send it as "101000" to the SDA.
How could I try to read register 0x00 of I2C address 0x28 (one of the four SSM3515 amplifier) ? It should return value 0x83 according to the documentation of SSM3515 as a "reset value for register 0x00".
If it is true that I can read data with GET_GPIO_DATA will it return as well only one bit of data like 0/1 at a time? If I need get a value of 0x83 thru the GPIO7 its binary value should be 10000011 , so this means that If i execute GET_GPIO_DATA 8 times in a row i will receive this piece by piece 1, 0 , 0 , 0 , 0 , 0 , 1, 1. Meanwhile I try to execute 8 times GET_GPIO_DATA should i be sending to the SCL (GPIO6) each time a clock value 0 ? or also a SET_GPIO_DATA value to the GPIO7 with value 0 for reading? Please advise.
On Sat, Aug 04, 2018 at 11:30:29PM +0300, David Ulricht wrote:
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 ?
The speakers are driven by digital amplifiers MAX98706. The MBP13,3 has four (treble/bass x left/right). They're attached via i2c to GPIO 6 (SCL) and 7 (SDA) of the CS8409 HDA bridge. It's possible that you need to initialize the amps via i2c, in that case using the GPIOs in bitbanging mode is wrong.
Leif Liddy has been looking into this as well (+cc): https://bugzilla.kernel.org/show_bug.cgi?id=110561
Lukas
participants (3)
-
David Ulricht -
Lukas Wunner -
Takashi Iwai