[alsa-devel] HDA cs8409 codec support

Wed May 17 04:09:45 CEST 2017

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 at 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 at 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 at 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 at 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
>> >>