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