[alsa-devel] HDA cs8409 codec support

[Takashi Iwai]

On Tue, 16 May 2017 14:29:48 +0200,
Joël Krähemann 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.

Well, I guess CS8409 is pretty different from WM codecs.
But the basics of HD-audio are same, so it's still worth to study with
that chip.

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

So you already figured out which pin corresponds to headphone and
which one to speaker?  This is the very first step.

> 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 don't know where you got these COEF verbs, but in general, the COEF
is very specific to the chip, thus you'll have to consult the
datasheet to understand what it's doing.

Changing GPIO is done usually not via COEF but the standard GPIO
verbs.

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

The generic driver tries to parse the given pin configs, sets up the
mixer and the PCM streams.


> 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

Usually you don't need to play with the power state of each pin.  It's
turned on/off dynamically if needed -- or it's kept turned on if the
power-saving is disabled.

Also, EAPD/BLT can be changed on the fly without problem, and you can
figure out which one is mandatory.

And, you still doesn't explain which hardware you're dealing with...


Takashi

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