At Fri, 10 Jul 2009 02:27:57 +0200,
Andreas Nüßlein wrote:
>
> On Thursday 09 July 2009 09:18:57 you wrote:
> > At Wed, 8 Jul 2009 18:11:29 +0200,
> >
> > Andreas Nüßlein wrote:
> > > On Wednesday 08 July 2009 16:49:34 you wrote:
> > > > At Tue, 07 Jul 2009 12:53:48 +0200,
> > > >
> > > > I wrote:
> > > > > At Tue, 7 Jul 2009 11:49:57 +0200,
> > > > >
> > > > > Andreas Nüßlein wrote:
> > > > > > On Tuesday 07 July 2009 08:00:19 you wrote:
> > > > > > > At Mon, 6 Jul 2009 22:14:56 +0200,
> > > > > > >
> > > > > > > Andreas Nüßlein wrote:
> > > > > > > > On Monday 06 July 2009 21:26:18 you wrote:
> > > > > > > > > At Mon, 06 Jul 2009 11:16:35 -0600,
> > > > > > > > >
> > > > > > > > > Sean Burke wrote:
> > > > > > > > > > Scríobh Takashi Iwai:
> > > > > > > > > > > At Mon, 6 Jul 2009 17:53:46 +0200,
> > > > > > > > > > >
> > > > > > > > > > > Andreas Nüßlein wrote:
> > > > > > > > > > >>> The missing pin configuration initialization was
> > > > > > > > > > >>> already fixed by the driver overriding it after
> > > > > > > > > > >>> checking PCI SSID (which is different from the codec
> > > > > > > > > > >>> SSID). So, this should be no problem.
> > > > > > > > > > >>>
> > > > > > > > > > >>> However, the reason why the analog output doesn't work
> > > > > > > > > > >>> might be different from that. There might be something
> > > > > > > > > > >>> else missing, but I don't know.
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>> Takashi
> > > > > > > > > > >>
> > > > > > > > > > >> oh =(
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >> hmm.. anything i can do? would it help if i tried
> > > > > > > > > > >> changing values randomly with hda-analyzer.py?
> > > > > > > > > > >
> > > > > > > > > > > Well, did the driver without my change work more or less
> > > > > > > > > > > with the analog audio, or have you never gotten the
> > > > > > > > > > > analog output? You can use the generic parser (i.e. the
> > > > > > > > > > > state without cirrus patch) by passing model=generic
> > > > > > > > > > > option to snd-hda-intel.
> > > > > > > > > >
> > > > > > > > > > For my part, nothing worked with the generic driver. I
> > > > > > > > > > can't confirm digital out, but I can confirm that the kfree
> > > > > > > > > > error is gone. What options are open for figuring out what
> > > > > > > > > > remains?
> > > > > > > > >
> > > > > > > > > Easy things to test are GPIO bits. Run hda-verb like
> > > > > > > > >
> > > > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
> > > > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > > > > > > or
> > > > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
> > > > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > > > > > >
> > > > > > > > > etc. CS4206 seems to have 4 GPIO lines, and each bit (0-3)
> > > > > > > > > corresponds to each GPIO. In many case, GPIO0 or GPIO1
> > > > > > > > > corresponds to the amplifier (EAPD) bit.
> > > > > > > > > Define the GPIO direction of each GPIO bit by SET_GPIO_DIR,
> > > > > > > > > and turn on/off the GPIO bits by SET_GPIO_DATA. Running
> > > > > > > > > hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DATA 0
> > > > > > > > > will show the current GPIO data bits. Or you can check it in
> > > > > > > > > codec#* proc file.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Takashi
> > > > > > > >
> > > > > > > > w000000000000000000000000000000000t! =)
> > > > > > > >
> > > > > > > > takashi, thank you _so_ much!
> > > > > > > >
> > > > > > > > after running all 4 of those:
> > > > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
> > > > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > > > > > > or
> > > > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
> > > > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > > > > >
> > > > > > > > i suddendly had sound!! :D :D :D :D :D :D :D
> > > > > > > > only via speakers though - there is no sound via headphones
> > > > > > > > right now.
> > > > > > > >
> > > > > > > > mixer channels:
> > > > > > > > - Master (with Mutebutton), PCM and Front (also with Mute) all
> > > > > > > > work =) - i don't know what surround would do (or it's extra
> > > > > > > > switch) - headphones-volumes and mute button don't affect the
> > > > > > > > speakers, which is good =)
> > > > > > > >
> > > > > > > >
> > > > > > > > is there a way to reset what i did with hda-verb, so that i can
> > > > > > > > figure out which combination it was exactly?
> > > > > > >
> > > > > > > You can just change the value 0x0f to a different value.
> > > > > > > At least, you can try commands like
> > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
> > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
> > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x04
> > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x08
> > > > > > > and check the speaker output at each time.
> > > > > > > Also, check the GPIO direction,
> > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x01
> > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
> > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x02
> > > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
> > > > > > > ...
> > > > > > >
> > > > > > > Regarding the headphone: is the speaker muted when you plug in
> > > > > > > the headphone? If not, it's likely an issue of the jack
> > > > > > > detection. If the speaker is muted but no headphone output, it's
> > > > > > > a missing initialization (or wrong GPIO setup).
> > > > > > >
> > > > > > >
> > > > > > > Takashi
> > > > > >
> > > > > > so here are my findings so far:
> > > > > >
> > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x08
> > > > > >
> > > > > >
> > > > > > is sufficient to turn on the right functionality for the speakers;
> > > > > > meaning: - 'front speaker'-channel actually controls the two front
> > > > > > speakers within the macbookpro - even controlling left and right
> > > > > > channel seperately works =) - 'surround' mute-switch and
> > > > > > volume-control (why are those not within on thing btw?) also work
> > > > > > and control a third speaker in the mac, which really seems
> > > > > > responsibly for surround :)
> > > > > >
> > > > > > headphones do not yet work, however i made a diff of
> > > > > > "/proc/asound/card0/codec#0" with and without something plugged in:
> > > > >
> > > > > OK, so actually the driver works as expected, but the hardware
> > > > > doesn't behave as expected. For muting the speaker, something else
> > > > > (like toggling that GPIO) is needed.
> > > > >
> > > > > The mystery about the silent HP output still remains, though.
> > > >
> > > > One another thing we can try is to use only one PCM stream instead of
> > > > multi streams. For example, try the patch below. This will enable
> > > > only the pin for the headphone, thus only one DAC is used.
> > > >
> > > >
> > > > Takashi
> > > >
> > > > ---
> > > > diff --git a/sound/pci/hda/patch_cirrus.c
> > > > b/sound/pci/hda/patch_cirrus.c index 57251d7..d7f52b1 100644
> > > > --- a/sound/pci/hda/patch_cirrus.c
> > > > +++ b/sound/pci/hda/patch_cirrus.c
> > > > @@ -1086,13 +1086,17 @@ struct cs_pincfg {
> > > >
> > > > static struct cs_pincfg mbp55_pincfgs[] = {
> > > > { 0x09, 0x012b4030 },
> > > > - { 0x0a, 0x90100121 },
> > > > - { 0x0b, 0x90100120 },
> > > > + // { 0x0a, 0x90100121 },
> > > > + { 0x0a, 0x400000f0 },
> > > > + // { 0x0b, 0x90100120 },
> > > > + { 0x0b, 0x400000f0 },
> > > > { 0x0c, 0x400000f0 },
> > > > - { 0x0d, 0x90a00110 },
> > > > + // { 0x0d, 0x90a00110 },
> > > > + { 0x0d, 0x400000f0 },
> > > > { 0x0e, 0x400000f0 },
> > > > { 0x0f, 0x400000f0 },
> > > > - { 0x10, 0x014be040 },
> > > > + // { 0x10, 0x014be040 },
> > > > + { 0x10, 0x400000f0 },
> > > > { 0x12, 0x400000f0 },
> > > > { 0x15, 0x400000f0 },
> > > > {} /* terminator */
> > >
> > > =( no - that doesn't work either
> > >
> > > (there is obivously no sound via built-in speakers either anymore)
> >
> > Hmm, then I have really no clue.
> > At best, you can try again GPIO pins and reverting COEF setup by my
> > earlier patch, and try some more adjustments of widgets amp or pinctl
> > via hda-verb or hda-analyzer...
> >
> >
> > Takashi
>
>
> still no luck on my end =(
>
> however i found this, while google-ing on datasheetarchive.com:
> http://nutz.unfoog.de/cs4206.pdf
>
> there's a lot of stuff about the pins and all that. maybe this is helpfull?
>
>
> is there anything i can do, though? like: try a bunch of different keys/codes
> somewhere?
>
> to get this right: Node[0x09] is getting "sound" just like 0x0a and 0x0b; 0x0a
> passes the sound to 0x03 (which is surround) and 0x0b passes it to 0x04 (which
> is front speaker).
> 0x09 should pass the sound to 0x02, then? and is that definitely working,
> making 0x02 the problem? or is maybe 0x09 wrong somehow already? i don't
> really get the alsa-interna yet. =(
Well, your question is rather HD-audio codec specific than ALSA.
CS420x has a 1:1 static connection between DAC and pin, according to the
codec verbs. The pin 0x09 corresponds to the DAC 0x02, and this appears
to be a HP output. It's just labeled so, and thus it's a guess.
You can change the pin configs in mbp55_pincfgs[] just to point one
pin. In the case above, 0x012b4030 is set to 0x09 (which represents
a HP output) and others are 0x400000f0 (which represents empty).
Similarly, you can assign the value to another pin and check which I/O
actually works...
And, this might be together with GPIO setup. So, a lot of
trial-and-error procedure.
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
