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#L51 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@xxxxxxxxx> 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@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
