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@xxxxxxx> 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@xxxxxxx> 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@xxxxxxxxx> 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@xxxxxxx> 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 >> >> _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
