[alsa-devel] HDA cs8409 codec support

Tue May 16 18:52:37 CEST 2017

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.

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)

Does it matter if pins are turned on first or afterwards? Currently
the first thing I do is turning on pins.

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
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log.1
Type: application/octet-stream
Size: 32230 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20170516/2681c67f/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: biglog
Type: application/octet-stream
Size: 268357 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20170516/2681c67f/attachment-0003.obj>