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
