[alsa-devel] HDA cs8409 codec support
Hi all
First of all, I am new to kernel programming and an other attempt already failed to do so.
However I got familiar with the Intel HDA Codec specification. So I did a start script to log dmesg and mixer controls of different configurations.
But I am not sure if I got a functional kernel driver setup to test things. It seems there is something wrong.
The codec has 8 GPIOs and first I didn't set any mask within the kernel. Now, I just compile a kernel set it to 0xff.
Any help is appreciated. Finally here is my work:
https://github.com/joelkraehemann/hda-tool/
Note: I have tried to subscribe using a different email address but didn't get approved message.
Thank you, Joël
Hi
I would like to know how GPIO works within the kernel and how it inerfaces with my HDA soundcard. The specification has good details about verbs. But GPIO is not described very good.
Bests, Joël
On Sun, May 14, 2017 at 2:16 AM, Joël Krähemann weedlight@gmail.com wrote:
Hi all
First of all, I am new to kernel programming and an other attempt already failed to do so.
However I got familiar with the Intel HDA Codec specification. So I did a start script to log dmesg and mixer controls of different configurations.
But I am not sure if I got a functional kernel driver setup to test things. It seems there is something wrong.
The codec has 8 GPIOs and first I didn't set any mask within the kernel. Now, I just compile a kernel set it to 0xff.
Any help is appreciated. Finally here is my work:
https://github.com/joelkraehemann/hda-tool/
Note: I have tried to subscribe using a different email address but didn't get approved message.
Thank you, Joël
On Sun, 14 May 2017 02:16:18 +0200, Joël Krähemann wrote:
Hi all
First of all, I am new to kernel programming and an other attempt already failed to do so.
However I got familiar with the Intel HDA Codec specification. So I did a start script to log dmesg and mixer controls of different configurations.
But I am not sure if I got a functional kernel driver setup to test things. It seems there is something wrong.
The codec has 8 GPIOs and first I didn't set any mask within the kernel. Now, I just compile a kernel set it to 0xff.
Any help is appreciated. Finally here is my work:
Well, from your description, it's not clear at all what you've tested on which machine, what result you got, and what still doesn't work.
How about to begin with explaining from that? Not many people have crystal balls and can't help you without the proper explanation.
Takashi
Hi all
First I was working with the cirrus datasheet of the wm8850 codec to get a better understanding of verbs and how a vendor specific implementation might look like.
Now, I am seeking for a working pin configuration. Thus I have created a systemd start script which does for the 17 reboots it does try a different firmware configuration.
It adjust different pins with the headphone address and does the appropriate pin complex configure as such.
In the beginning I tried to configure hp and speaker at the very same time. As a continues configuration block. But now I think it is easier to do it separately.
My biggest issue is to understand vendor coefficients and GPIO. The following vendor coefficient enables pins 0, 2 and 3.
static const struct hda_verb cs8409_coef_init_verbs[] = { { 0x01, AC_VERB_SET_POWER_STATE, 0x00 }, /* AFG: D0 */ { 0x47, AC_VERB_SET_PROC_STATE, 0x1 }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x3 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x146a }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x0033 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x0001 }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x0034 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x1c01 }, {} /* terminator */ };
I think the coefficient index 0x3 is responsible for it. What is the difference between enabling data pins by coefficient on vendor node 0x47 and by appropriate verb on node 0x1 audio configuration group?
I didn't have the chance to study the generic HDA driver. One of my faults was enabling streams during early firmware patching, thought. Since the datasheet says it shall be the last called verbs of a configuration sequence.
During early firmware patching I configured certain nodes as speaker left and right. But I am unsure what shall happen during early firmware patching and what does the generic driver.
Here is a piece of my systemd start script what configures speaker left:
# power D0 printf "0x%02x 0x705 0x0\n" $nid >> /lib/firmware/hda-jack-retask.fw # set processing state on printf "0x%02x 0x3 0x1\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x706 0x10\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x70c 0x2\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x773 0x0\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x705 0x00\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x707 0x45\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x708 0x80\n" $pin >> /lib/firmware/hda-jack-retask.fw # EAPD/BTL enable printf "0x%02x 0x70c 0x2\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71c 0x10\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71d 0x0\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71e 0x17\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71f 0x43\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x724 0x3\n" $nid >> /lib/firmware/hda-jack-retask.fw # enable stream 1 channel 0 printf "0x%02x 0x2 0x4011\n" $nid >> /lib/firmware/hda-jack-retask.fw
Bests, Joël
On Tue, May 16, 2017 at 7:38 AM, Takashi Iwai tiwai@suse.de wrote:
On Sun, 14 May 2017 02:16:18 +0200, Joël Krähemann wrote:
Hi all
First of all, I am new to kernel programming and an other attempt already failed to do so.
However I got familiar with the Intel HDA Codec specification. So I did a start script to log dmesg and mixer controls of different configurations.
But I am not sure if I got a functional kernel driver setup to test things. It seems there is something wrong.
The codec has 8 GPIOs and first I didn't set any mask within the kernel. Now, I just compile a kernel set it to 0xff.
Any help is appreciated. Finally here is my work:
Well, from your description, it's not clear at all what you've tested on which machine, what result you got, and what still doesn't work.
How about to begin with explaining from that? Not many people have crystal balls and can't help you without the proper explanation.
Takashi
Hi again
Excuse me. It is a macbook pro 2016 model 13,1 and the codec of the HDA soundcard is a Cirrus Logic 8409
bests, Joël
On Tue, May 16, 2017 at 2:29 PM, Joël Krähemann weedlight@gmail.com wrote:
Hi all
First I was working with the cirrus datasheet of the wm8850 codec to get a better understanding of verbs and how a vendor specific implementation might look like.
Now, I am seeking for a working pin configuration. Thus I have created a systemd start script which does for the 17 reboots it does try a different firmware configuration.
It adjust different pins with the headphone address and does the appropriate pin complex configure as such.
In the beginning I tried to configure hp and speaker at the very same time. As a continues configuration block. But now I think it is easier to do it separately.
My biggest issue is to understand vendor coefficients and GPIO. The following vendor coefficient enables pins 0, 2 and 3.
static const struct hda_verb cs8409_coef_init_verbs[] = { { 0x01, AC_VERB_SET_POWER_STATE, 0x00 }, /* AFG: D0 */ { 0x47, AC_VERB_SET_PROC_STATE, 0x1 }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x3 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x146a }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x0033 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x0001 }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x0034 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x1c01 }, {} /* terminator */ };
I think the coefficient index 0x3 is responsible for it. What is the difference between enabling data pins by coefficient on vendor node 0x47 and by appropriate verb on node 0x1 audio configuration group?
I didn't have the chance to study the generic HDA driver. One of my faults was enabling streams during early firmware patching, thought. Since the datasheet says it shall be the last called verbs of a configuration sequence.
During early firmware patching I configured certain nodes as speaker left and right. But I am unsure what shall happen during early firmware patching and what does the generic driver.
Here is a piece of my systemd start script what configures speaker left:
# power D0 printf "0x%02x 0x705 0x0\n" $nid >> /lib/firmware/hda-jack-retask.fw # set processing state on printf "0x%02x 0x3 0x1\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x706 0x10\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x70c 0x2\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x773 0x0\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x705 0x00\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x707 0x45\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x708 0x80\n" $pin >> /lib/firmware/hda-jack-retask.fw # EAPD/BTL enable printf "0x%02x 0x70c 0x2\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71c 0x10\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71d 0x0\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71e 0x17\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71f 0x43\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x724 0x3\n" $nid >> /lib/firmware/hda-jack-retask.fw # enable stream 1 channel 0 printf "0x%02x 0x2 0x4011\n" $nid >> /lib/firmware/hda-jack-retask.fw
Bests, Joël
On Tue, May 16, 2017 at 7:38 AM, Takashi Iwai tiwai@suse.de wrote:
On Sun, 14 May 2017 02:16:18 +0200, Joël Krähemann wrote:
Hi all
First of all, I am new to kernel programming and an other attempt already failed to do so.
However I got familiar with the Intel HDA Codec specification. So I did a start script to log dmesg and mixer controls of different configurations.
But I am not sure if I got a functional kernel driver setup to test things. It seems there is something wrong.
The codec has 8 GPIOs and first I didn't set any mask within the kernel. Now, I just compile a kernel set it to 0xff.
Any help is appreciated. Finally here is my work:
Well, from your description, it's not clear at all what you've tested on which machine, what result you got, and what still doesn't work.
How about to begin with explaining from that? Not many people have crystal balls and can't help you without the proper explanation.
Takashi
On Tue, 16 May 2017 14:41:03 +0200, Joël Krähemann wrote:
Hi again
Excuse me. It is a macbook pro 2016 model 13,1 and the codec of the HDA soundcard is a Cirrus Logic 8409
Ah I see. So you need to toggle GPIO pins. This should be easy to test, you can turn it on/off dynamically after configuring the stuff.
Takashi
bests, Joël
On Tue, May 16, 2017 at 2:29 PM, Joël Krähemann weedlight@gmail.com wrote:
Hi all
First I was working with the cirrus datasheet of the wm8850 codec to get a better understanding of verbs and how a vendor specific implementation might look like.
Now, I am seeking for a working pin configuration. Thus I have created a systemd start script which does for the 17 reboots it does try a different firmware configuration.
It adjust different pins with the headphone address and does the appropriate pin complex configure as such.
In the beginning I tried to configure hp and speaker at the very same time. As a continues configuration block. But now I think it is easier to do it separately.
My biggest issue is to understand vendor coefficients and GPIO. The following vendor coefficient enables pins 0, 2 and 3.
static const struct hda_verb cs8409_coef_init_verbs[] = { { 0x01, AC_VERB_SET_POWER_STATE, 0x00 }, /* AFG: D0 */ { 0x47, AC_VERB_SET_PROC_STATE, 0x1 }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x3 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x146a }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x0033 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x0001 }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x0034 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x1c01 }, {} /* terminator */ };
I think the coefficient index 0x3 is responsible for it. What is the difference between enabling data pins by coefficient on vendor node 0x47 and by appropriate verb on node 0x1 audio configuration group?
I didn't have the chance to study the generic HDA driver. One of my faults was enabling streams during early firmware patching, thought. Since the datasheet says it shall be the last called verbs of a configuration sequence.
During early firmware patching I configured certain nodes as speaker left and right. But I am unsure what shall happen during early firmware patching and what does the generic driver.
Here is a piece of my systemd start script what configures speaker left:
# power D0 printf "0x%02x 0x705 0x0\n" $nid >> /lib/firmware/hda-jack-retask.fw # set processing state on printf "0x%02x 0x3 0x1\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x706 0x10\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x70c 0x2\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x773 0x0\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x705 0x00\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x707 0x45\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x708 0x80\n" $pin >> /lib/firmware/hda-jack-retask.fw # EAPD/BTL enable printf "0x%02x 0x70c 0x2\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71c 0x10\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71d 0x0\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71e 0x17\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71f 0x43\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x724 0x3\n" $nid >> /lib/firmware/hda-jack-retask.fw # enable stream 1 channel 0 printf "0x%02x 0x2 0x4011\n" $nid >> /lib/firmware/hda-jack-retask.fw
Bests, Joël
On Tue, May 16, 2017 at 7:38 AM, Takashi Iwai tiwai@suse.de wrote:
On Sun, 14 May 2017 02:16:18 +0200, Joël Krähemann wrote:
Hi all
First of all, I am new to kernel programming and an other attempt already failed to do so.
However I got familiar with the Intel HDA Codec specification. So I did a start script to log dmesg and mixer controls of different configurations.
But I am not sure if I got a functional kernel driver setup to test things. It seems there is something wrong.
The codec has 8 GPIOs and first I didn't set any mask within the kernel. Now, I just compile a kernel set it to 0xff.
Any help is appreciated. Finally here is my work:
Well, from your description, it's not clear at all what you've tested on which machine, what result you got, and what still doesn't work.
How about to begin with explaining from that? Not many people have crystal balls and can't help you without the proper explanation.
Takashi
Hi
I have attached the log as text of the first reboot sequence. If you don't need additional information I would say hear of you 136 reboots later.
I have modified the script to do reboot sequences for each pin.
first it tried without any pin. Then pin 1, after this pin 2 and so on.
Since you told me the coefficients are very vendor specific I have just removed it. Then pins are now turned on by early firmware patching on pin 0x1 (audio configuration group)
Does it matter if pins are turned on first or afterwards? Currently the first thing I do is turning on pins.
bests, Joël
On Tue, May 16, 2017 at 3:16 PM, Takashi Iwai tiwai@suse.de wrote:
On Tue, 16 May 2017 14:41:03 +0200, Joël Krähemann wrote:
Hi again
Excuse me. It is a macbook pro 2016 model 13,1 and the codec of the HDA soundcard is a Cirrus Logic 8409
Ah I see. So you need to toggle GPIO pins. This should be easy to test, you can turn it on/off dynamically after configuring the stuff.
Takashi
bests, Joël
On Tue, May 16, 2017 at 2:29 PM, Joël Krähemann weedlight@gmail.com wrote:
Hi all
First I was working with the cirrus datasheet of the wm8850 codec to get a better understanding of verbs and how a vendor specific implementation might look like.
Now, I am seeking for a working pin configuration. Thus I have created a systemd start script which does for the 17 reboots it does try a different firmware configuration.
It adjust different pins with the headphone address and does the appropriate pin complex configure as such.
In the beginning I tried to configure hp and speaker at the very same time. As a continues configuration block. But now I think it is easier to do it separately.
My biggest issue is to understand vendor coefficients and GPIO. The following vendor coefficient enables pins 0, 2 and 3.
static const struct hda_verb cs8409_coef_init_verbs[] = { { 0x01, AC_VERB_SET_POWER_STATE, 0x00 }, /* AFG: D0 */ { 0x47, AC_VERB_SET_PROC_STATE, 0x1 }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x3 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x146a }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x0033 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x0001 }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x0034 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x1c01 }, {} /* terminator */ };
I think the coefficient index 0x3 is responsible for it. What is the difference between enabling data pins by coefficient on vendor node 0x47 and by appropriate verb on node 0x1 audio configuration group?
I didn't have the chance to study the generic HDA driver. One of my faults was enabling streams during early firmware patching, thought. Since the datasheet says it shall be the last called verbs of a configuration sequence.
During early firmware patching I configured certain nodes as speaker left and right. But I am unsure what shall happen during early firmware patching and what does the generic driver.
Here is a piece of my systemd start script what configures speaker left:
# power D0 printf "0x%02x 0x705 0x0\n" $nid >> /lib/firmware/hda-jack-retask.fw # set processing state on printf "0x%02x 0x3 0x1\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x706 0x10\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x70c 0x2\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x773 0x0\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x705 0x00\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x707 0x45\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x708 0x80\n" $pin >> /lib/firmware/hda-jack-retask.fw # EAPD/BTL enable printf "0x%02x 0x70c 0x2\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71c 0x10\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71d 0x0\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71e 0x17\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71f 0x43\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x724 0x3\n" $nid >> /lib/firmware/hda-jack-retask.fw # enable stream 1 channel 0 printf "0x%02x 0x2 0x4011\n" $nid >> /lib/firmware/hda-jack-retask.fw
Bests, Joël
On Tue, May 16, 2017 at 7:38 AM, Takashi Iwai tiwai@suse.de wrote:
On Sun, 14 May 2017 02:16:18 +0200, Joël Krähemann wrote:
Hi all
First of all, I am new to kernel programming and an other attempt already failed to do so.
However I got familiar with the Intel HDA Codec specification. So I did a start script to log dmesg and mixer controls of different configurations.
But I am not sure if I got a functional kernel driver setup to test things. It seems there is something wrong.
The codec has 8 GPIOs and first I didn't set any mask within the kernel. Now, I just compile a kernel set it to 0xff.
Any help is appreciated. Finally here is my work:
Well, from your description, it's not clear at all what you've tested on which machine, what result you got, and what still doesn't work.
How about to begin with explaining from that? Not many people have crystal balls and can't help you without the proper explanation.
Takashi
On Tue, 16 May 2017 18:52:37 +0200, Joël Krähemann wrote:
Hi
I have attached the log as text of the first reboot sequence. If you don't need additional information I would say hear of you 136 reboots later.
You don't have to reboot. Usually reloading the sound kernel modules suffice.
Did you figure out which pin correspond to which I/O? That's the most important information. For example, in most case you can see the jack detection state change for headphone or such jacks. The built-in fixed pins are a bit difficult but most of codecs have one or two pins that are supposed to be connected to such purposes, so you can guess via trial-and-error.
I have modified the script to do reboot sequences for each pin.
first it tried without any pin. Then pin 1, after this pin 2 and so on.
Since you told me the coefficients are very vendor specific I have just removed it. Then pins are now turned on by early firmware patching on pin 0x1 (audio configuration group)
The NID 0x01 no pin widget but it's the FG widget. It's assigned for some global config stuff like GPIO pins.
Does it matter if pins are turned on first or afterwards? Currently the first thing I do is turning on pins.
The pin default config is evaluated for determining the signal routes (paths) by the generic driver. The actual pin turn on/off is also dynamically managed by the HD-audio driver, although you can turn on/off manually on the fly, too.
Takashi
bests, Joël
On Tue, May 16, 2017 at 3:16 PM, Takashi Iwai tiwai@suse.de wrote:
On Tue, 16 May 2017 14:41:03 +0200, Joël Krähemann wrote:
Hi again
Excuse me. It is a macbook pro 2016 model 13,1 and the codec of the HDA soundcard is a Cirrus Logic 8409
Ah I see. So you need to toggle GPIO pins. This should be easy to test, you can turn it on/off dynamically after configuring the stuff.
Takashi
bests, Joël
On Tue, May 16, 2017 at 2:29 PM, Joël Krähemann weedlight@gmail.com wrote:
Hi all
First I was working with the cirrus datasheet of the wm8850 codec to get a better understanding of verbs and how a vendor specific implementation might look like.
Now, I am seeking for a working pin configuration. Thus I have created a systemd start script which does for the 17 reboots it does try a different firmware configuration.
It adjust different pins with the headphone address and does the appropriate pin complex configure as such.
In the beginning I tried to configure hp and speaker at the very same time. As a continues configuration block. But now I think it is easier to do it separately.
My biggest issue is to understand vendor coefficients and GPIO. The following vendor coefficient enables pins 0, 2 and 3.
static const struct hda_verb cs8409_coef_init_verbs[] = { { 0x01, AC_VERB_SET_POWER_STATE, 0x00 }, /* AFG: D0 */ { 0x47, AC_VERB_SET_PROC_STATE, 0x1 }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x3 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x146a }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x0033 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x0001 }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x0034 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x1c01 }, {} /* terminator */ };
I think the coefficient index 0x3 is responsible for it. What is the difference between enabling data pins by coefficient on vendor node 0x47 and by appropriate verb on node 0x1 audio configuration group?
I didn't have the chance to study the generic HDA driver. One of my faults was enabling streams during early firmware patching, thought. Since the datasheet says it shall be the last called verbs of a configuration sequence.
During early firmware patching I configured certain nodes as speaker left and right. But I am unsure what shall happen during early firmware patching and what does the generic driver.
Here is a piece of my systemd start script what configures speaker left:
# power D0 printf "0x%02x 0x705 0x0\n" $nid >> /lib/firmware/hda-jack-retask.fw # set processing state on printf "0x%02x 0x3 0x1\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x706 0x10\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x70c 0x2\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x773 0x0\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x705 0x00\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x707 0x45\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x708 0x80\n" $pin >> /lib/firmware/hda-jack-retask.fw # EAPD/BTL enable printf "0x%02x 0x70c 0x2\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71c 0x10\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71d 0x0\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71e 0x17\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71f 0x43\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x724 0x3\n" $nid >> /lib/firmware/hda-jack-retask.fw # enable stream 1 channel 0 printf "0x%02x 0x2 0x4011\n" $nid >> /lib/firmware/hda-jack-retask.fw
Bests, Joël
On Tue, May 16, 2017 at 7:38 AM, Takashi Iwai tiwai@suse.de wrote:
On Sun, 14 May 2017 02:16:18 +0200, Joël Krähemann wrote:
Hi all
First of all, I am new to kernel programming and an other attempt already failed to do so.
However I got familiar with the Intel HDA Codec specification. So I did a start script to log dmesg and mixer controls of different configurations.
But I am not sure if I got a functional kernel driver setup to test things. It seems there is something wrong.
The codec has 8 GPIOs and first I didn't set any mask within the kernel. Now, I just compile a kernel set it to 0xff.
Any help is appreciated. Finally here is my work:
Well, from your description, it's not clear at all what you've tested on which machine, what result you got, and what still doesn't work.
How about to begin with explaining from that? Not many people have crystal balls and can't help you without the proper explanation.
Takashi
Hi
The first iteration of sequences are done the script used is within the directory:
https://github.com/joelkraehemann/hda-tool/tree/master/base-conf
I would like to do it without restarting but /proc/asound/card0/codec#0 takes too long until it is up. Occasionally, I figured out that it comes up after 10 minutes or more.
With a clean boot it is no problem. I couldn't figure out any pin configuration, yet.
For now I try more advanced usage of verbs.
bests, Joël
On Tue, May 16, 2017 at 8:01 PM, Takashi Iwai tiwai@suse.de wrote:
On Tue, 16 May 2017 18:52:37 +0200, Joël Krähemann wrote:
Hi
I have attached the log as text of the first reboot sequence. If you don't need additional information I would say hear of you 136 reboots later.
You don't have to reboot. Usually reloading the sound kernel modules suffice.
Did you figure out which pin correspond to which I/O? That's the most important information. For example, in most case you can see the jack detection state change for headphone or such jacks. The built-in fixed pins are a bit difficult but most of codecs have one or two pins that are supposed to be connected to such purposes, so you can guess via trial-and-error.
I have modified the script to do reboot sequences for each pin.
first it tried without any pin. Then pin 1, after this pin 2 and so on.
Since you told me the coefficients are very vendor specific I have just removed it. Then pins are now turned on by early firmware patching on pin 0x1 (audio configuration group)
The NID 0x01 no pin widget but it's the FG widget. It's assigned for some global config stuff like GPIO pins.
Does it matter if pins are turned on first or afterwards? Currently the first thing I do is turning on pins.
The pin default config is evaluated for determining the signal routes (paths) by the generic driver. The actual pin turn on/off is also dynamically managed by the HD-audio driver, although you can turn on/off manually on the fly, too.
Takashi
bests, Joël
On Tue, May 16, 2017 at 3:16 PM, Takashi Iwai tiwai@suse.de wrote:
On Tue, 16 May 2017 14:41:03 +0200, Joël Krähemann wrote:
Hi again
Excuse me. It is a macbook pro 2016 model 13,1 and the codec of the HDA soundcard is a Cirrus Logic 8409
Ah I see. So you need to toggle GPIO pins. This should be easy to test, you can turn it on/off dynamically after configuring the stuff.
Takashi
bests, Joël
On Tue, May 16, 2017 at 2:29 PM, Joël Krähemann weedlight@gmail.com wrote:
Hi all
First I was working with the cirrus datasheet of the wm8850 codec to get a better understanding of verbs and how a vendor specific implementation might look like.
Now, I am seeking for a working pin configuration. Thus I have created a systemd start script which does for the 17 reboots it does try a different firmware configuration.
It adjust different pins with the headphone address and does the appropriate pin complex configure as such.
In the beginning I tried to configure hp and speaker at the very same time. As a continues configuration block. But now I think it is easier to do it separately.
My biggest issue is to understand vendor coefficients and GPIO. The following vendor coefficient enables pins 0, 2 and 3.
static const struct hda_verb cs8409_coef_init_verbs[] = { { 0x01, AC_VERB_SET_POWER_STATE, 0x00 }, /* AFG: D0 */ { 0x47, AC_VERB_SET_PROC_STATE, 0x1 }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x3 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x146a }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x0033 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x0001 }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x0034 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x1c01 }, {} /* terminator */ };
I think the coefficient index 0x3 is responsible for it. What is the difference between enabling data pins by coefficient on vendor node 0x47 and by appropriate verb on node 0x1 audio configuration group?
I didn't have the chance to study the generic HDA driver. One of my faults was enabling streams during early firmware patching, thought. Since the datasheet says it shall be the last called verbs of a configuration sequence.
During early firmware patching I configured certain nodes as speaker left and right. But I am unsure what shall happen during early firmware patching and what does the generic driver.
Here is a piece of my systemd start script what configures speaker left:
# power D0 printf "0x%02x 0x705 0x0\n" $nid >> /lib/firmware/hda-jack-retask.fw # set processing state on printf "0x%02x 0x3 0x1\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x706 0x10\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x70c 0x2\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x773 0x0\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x705 0x00\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x707 0x45\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x708 0x80\n" $pin >> /lib/firmware/hda-jack-retask.fw # EAPD/BTL enable printf "0x%02x 0x70c 0x2\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71c 0x10\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71d 0x0\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71e 0x17\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71f 0x43\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x724 0x3\n" $nid >> /lib/firmware/hda-jack-retask.fw # enable stream 1 channel 0 printf "0x%02x 0x2 0x4011\n" $nid >> /lib/firmware/hda-jack-retask.fw
Bests, Joël
On Tue, May 16, 2017 at 7:38 AM, Takashi Iwai tiwai@suse.de wrote:
On Sun, 14 May 2017 02:16:18 +0200, Joël Krähemann wrote: > > Hi all > > First of all, I am new to kernel programming and an other attempt > already failed to do so. > > However I got familiar with the Intel HDA Codec specification. So I > did a start script to log dmesg and mixer controls of different > configurations. > > But I am not sure if I got a functional kernel driver setup to test > things. It seems there is something wrong. > > The codec has 8 GPIOs and first I didn't set any mask within the > kernel. Now, I just compile a kernel set it to 0xff. > > Any help is appreciated. Finally here is my work: > > https://github.com/joelkraehemann/hda-tool/
Well, from your description, it's not clear at all what you've tested on which machine, what result you got, and what still doesn't work.
How about to begin with explaining from that? Not many people have crystal balls and can't help you without the proper explanation.
Takashi
Hi
It is just a guess but I think the enum has got wrong order.
https://github.com/joelkraehemann/hda-tool/blob/master/patch_cirrus.c.patch#...
Since it feels like one more infinite loop :/ Is there a documentation about common patterns in the kernel? Especially how the chain shall be enumerated or what ever might be related?
bests, Joël
On Wed, May 17, 2017 at 4:09 AM, Joël Krähemann weedlight@gmail.com wrote:
Hi
The first iteration of sequences are done the script used is within the directory:
https://github.com/joelkraehemann/hda-tool/tree/master/base-conf
I would like to do it without restarting but /proc/asound/card0/codec#0 takes too long until it is up. Occasionally, I figured out that it comes up after 10 minutes or more.
With a clean boot it is no problem. I couldn't figure out any pin configuration, yet.
For now I try more advanced usage of verbs.
bests, Joël
On Tue, May 16, 2017 at 8:01 PM, Takashi Iwai tiwai@suse.de wrote:
On Tue, 16 May 2017 18:52:37 +0200, Joël Krähemann wrote:
Hi
I have attached the log as text of the first reboot sequence. If you don't need additional information I would say hear of you 136 reboots later.
You don't have to reboot. Usually reloading the sound kernel modules suffice.
Did you figure out which pin correspond to which I/O? That's the most important information. For example, in most case you can see the jack detection state change for headphone or such jacks. The built-in fixed pins are a bit difficult but most of codecs have one or two pins that are supposed to be connected to such purposes, so you can guess via trial-and-error.
I have modified the script to do reboot sequences for each pin.
first it tried without any pin. Then pin 1, after this pin 2 and so on.
Since you told me the coefficients are very vendor specific I have just removed it. Then pins are now turned on by early firmware patching on pin 0x1 (audio configuration group)
The NID 0x01 no pin widget but it's the FG widget. It's assigned for some global config stuff like GPIO pins.
Does it matter if pins are turned on first or afterwards? Currently the first thing I do is turning on pins.
The pin default config is evaluated for determining the signal routes (paths) by the generic driver. The actual pin turn on/off is also dynamically managed by the HD-audio driver, although you can turn on/off manually on the fly, too.
Takashi
bests, Joël
On Tue, May 16, 2017 at 3:16 PM, Takashi Iwai tiwai@suse.de wrote:
On Tue, 16 May 2017 14:41:03 +0200, Joël Krähemann wrote:
Hi again
Excuse me. It is a macbook pro 2016 model 13,1 and the codec of the HDA soundcard is a Cirrus Logic 8409
Ah I see. So you need to toggle GPIO pins. This should be easy to test, you can turn it on/off dynamically after configuring the stuff.
Takashi
bests, Joël
On Tue, May 16, 2017 at 2:29 PM, Joël Krähemann weedlight@gmail.com wrote:
Hi all
First I was working with the cirrus datasheet of the wm8850 codec to get a better understanding of verbs and how a vendor specific implementation might look like.
Now, I am seeking for a working pin configuration. Thus I have created a systemd start script which does for the 17 reboots it does try a different firmware configuration.
It adjust different pins with the headphone address and does the appropriate pin complex configure as such.
In the beginning I tried to configure hp and speaker at the very same time. As a continues configuration block. But now I think it is easier to do it separately.
My biggest issue is to understand vendor coefficients and GPIO. The following vendor coefficient enables pins 0, 2 and 3.
static const struct hda_verb cs8409_coef_init_verbs[] = { { 0x01, AC_VERB_SET_POWER_STATE, 0x00 }, /* AFG: D0 */ { 0x47, AC_VERB_SET_PROC_STATE, 0x1 }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x3 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x146a }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x0033 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x0001 }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x0034 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x1c01 }, {} /* terminator */ };
I think the coefficient index 0x3 is responsible for it. What is the difference between enabling data pins by coefficient on vendor node 0x47 and by appropriate verb on node 0x1 audio configuration group?
I didn't have the chance to study the generic HDA driver. One of my faults was enabling streams during early firmware patching, thought. Since the datasheet says it shall be the last called verbs of a configuration sequence.
During early firmware patching I configured certain nodes as speaker left and right. But I am unsure what shall happen during early firmware patching and what does the generic driver.
Here is a piece of my systemd start script what configures speaker left:
# power D0 printf "0x%02x 0x705 0x0\n" $nid >> /lib/firmware/hda-jack-retask.fw # set processing state on printf "0x%02x 0x3 0x1\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x706 0x10\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x70c 0x2\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x773 0x0\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x705 0x00\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x707 0x45\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x708 0x80\n" $pin >> /lib/firmware/hda-jack-retask.fw # EAPD/BTL enable printf "0x%02x 0x70c 0x2\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71c 0x10\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71d 0x0\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71e 0x17\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71f 0x43\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x724 0x3\n" $nid >> /lib/firmware/hda-jack-retask.fw # enable stream 1 channel 0 printf "0x%02x 0x2 0x4011\n" $nid >> /lib/firmware/hda-jack-retask.fw
Bests, Joël
On Tue, May 16, 2017 at 7:38 AM, Takashi Iwai tiwai@suse.de wrote: > On Sun, 14 May 2017 02:16:18 +0200, > Joël Krähemann wrote: >> >> Hi all >> >> First of all, I am new to kernel programming and an other attempt >> already failed to do so. >> >> However I got familiar with the Intel HDA Codec specification. So I >> did a start script to log dmesg and mixer controls of different >> configurations. >> >> But I am not sure if I got a functional kernel driver setup to test >> things. It seems there is something wrong. >> >> The codec has 8 GPIOs and first I didn't set any mask within the >> kernel. Now, I just compile a kernel set it to 0xff. >> >> Any help is appreciated. Finally here is my work: >> >> https://github.com/joelkraehemann/hda-tool/ > > Well, from your description, it's not clear at all what you've tested > on which machine, what result you got, and what still doesn't work. > > How about to begin with explaining from that? Not many people have > crystal balls and can't help you without the proper explanation. > > > Takashi
On Tue, 16 May 2017 14:29:48 +0200, Joël Krähemann wrote:
Hi all
First I was working with the cirrus datasheet of the wm8850 codec to get a better understanding of verbs and how a vendor specific implementation might look like.
Well, I guess CS8409 is pretty different from WM codecs. But the basics of HD-audio are same, so it's still worth to study with that chip.
Now, I am seeking for a working pin configuration. Thus I have created a systemd start script which does for the 17 reboots it does try a different firmware configuration.
It adjust different pins with the headphone address and does the appropriate pin complex configure as such.
In the beginning I tried to configure hp and speaker at the very same time. As a continues configuration block. But now I think it is easier to do it separately.
So you already figured out which pin corresponds to headphone and which one to speaker? This is the very first step.
My biggest issue is to understand vendor coefficients and GPIO. The following vendor coefficient enables pins 0, 2 and 3.
static const struct hda_verb cs8409_coef_init_verbs[] = { { 0x01, AC_VERB_SET_POWER_STATE, 0x00 }, /* AFG: D0 */ { 0x47, AC_VERB_SET_PROC_STATE, 0x1 }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x3 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x146a }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x0033 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x0001 }, { 0x47, AC_VERB_SET_COEF_INDEX, 0x0034 }, { 0x47, AC_VERB_SET_PROC_COEF, 0x1c01 }, {} /* terminator */ };
I think the coefficient index 0x3 is responsible for it. What is the difference between enabling data pins by coefficient on vendor node 0x47 and by appropriate verb on node 0x1 audio configuration group?
I don't know where you got these COEF verbs, but in general, the COEF is very specific to the chip, thus you'll have to consult the datasheet to understand what it's doing.
Changing GPIO is done usually not via COEF but the standard GPIO verbs.
I didn't have the chance to study the generic HDA driver. One of my faults was enabling streams during early firmware patching, thought. Since the datasheet says it shall be the last called verbs of a configuration sequence.
During early firmware patching I configured certain nodes as speaker left and right. But I am unsure what shall happen during early firmware patching and what does the generic driver.
The generic driver tries to parse the given pin configs, sets up the mixer and the PCM streams.
Here is a piece of my systemd start script what configures speaker left:
# power D0 printf "0x%02x 0x705 0x0\n" $nid >> /lib/firmware/hda-jack-retask.fw # set processing state on printf "0x%02x 0x3 0x1\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x706 0x10\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x70c 0x2\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x773 0x0\n" $nid >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x705 0x00\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x707 0x45\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x708 0x80\n" $pin >> /lib/firmware/hda-jack-retask.fw # EAPD/BTL enable printf "0x%02x 0x70c 0x2\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71c 0x10\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71d 0x0\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71e 0x17\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x71f 0x43\n" $pin >> /lib/firmware/hda-jack-retask.fw printf "0x%02x 0x724 0x3\n" $nid >> /lib/firmware/hda-jack-retask.fw # enable stream 1 channel 0 printf "0x%02x 0x2 0x4011\n" $nid >> /lib/firmware/hda-jack-retask.fw
Usually you don't need to play with the power state of each pin. It's turned on/off dynamically if needed -- or it's kept turned on if the power-saving is disabled.
Also, EAPD/BLT can be changed on the fly without problem, and you can figure out which one is mandatory.
And, you still doesn't explain which hardware you're dealing with...
Takashi
Bests, Joël
On Tue, May 16, 2017 at 7:38 AM, Takashi Iwai tiwai@suse.de wrote:
On Sun, 14 May 2017 02:16:18 +0200, Joël Krähemann wrote:
Hi all
First of all, I am new to kernel programming and an other attempt already failed to do so.
However I got familiar with the Intel HDA Codec specification. So I did a start script to log dmesg and mixer controls of different configurations.
But I am not sure if I got a functional kernel driver setup to test things. It seems there is something wrong.
The codec has 8 GPIOs and first I didn't set any mask within the kernel. Now, I just compile a kernel set it to 0xff.
Any help is appreciated. Finally here is my work:
Well, from your description, it's not clear at all what you've tested on which machine, what result you got, and what still doesn't work.
How about to begin with explaining from that? Not many people have crystal balls and can't help you without the proper explanation.
Takashi
participants (2)
-
Joël Krähemann -
Takashi Iwai