[alsa-devel] HDA cs8409 codec support

[Joël Krähemann]

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 at gmail.com> 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 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
>>> >>