[alsa-devel] HDA regression on Fujitsu S7020 laptop (ALC260 codec)

[Takashi Iwai]

At Sun, 13 Jan 2013 15:09:36 +1030,
Jonathan Woithe wrote:
> 
> On Tue, Jan 08, 2013 at 03:48:57PM +0100, Takashi Iwai wrote:
> > > Node 0x10 is notionally labelled "headphone pin" in the ALC260 datasheet. 
> > 
> > You can forget the pin notion in the datasheet.  It's just pin
> > assignment Realtek thought as a standard arrangement.
> 
> Absolutely - that was abundantly clear when I first added the S7020 details
> years ago.  The comment was only made in an attempt to make the comments in
> the original driver clearer to those reading them now.
> 
> > > I've just looked now.  3.3.5 was booted, alsamixer does not show any
> > > "automute" control to enable or disable this.  In any case, automute is
> > > certainly not happening, so I'm guessing the answer to your question is no.
> > 
> > There is no automute behavior switching control in the 3.3.x kernel
> > driver, so no wonder :)
> 
> I wasn't surprised since I thought this too.  However, I was asked to test
> it so I did.
> 
> > I took a look at your alsa-info.sh outputs now, but unfortunately I
> > see no obvious problem there.  At least, the path to the speaker looks
> > sane:
> > :
> > And all GPIOs are cleared too.
> 
> Agreed.  Given that the headphone jack works and the respective pin
> definition is very similar, I also can't see any obvious reason why things
> are getting messed up.  Something subtle perhaps?

A possible cause I noticed later is the lack of the headphone amp on
the speaker pin.  This might be abused for controlling the speaker
amp.

> > The differences are that the old driver cleared unused pins such as
> > 0x0f, 0x11, 0x13 and 0x15.  Could you try to set the pin ctl to 0 for
> > these widgets via hda-verb on the fly?
> 
> I will try this, hopefully in the next few days.  Like you I suspect, I
> can't see that this should make any difference to the speaker's ability to
> put out audio or to ALSA's ability to populate alsa-mixer correctly, but
> it's easy enough to eliminate it through testing.
> 
> > Other than that, the headphone jack is set up with the HP amp and the
> > mic is with VREF 50.  They can be changed on the fly, too.
> 
> I'll run through some of these variations and let you know the result.
> 
> I noticed your big refactoring patch go past last week.  Is there anything  
> in there which I should test in relation to the ALC260 / Fujitsu issue
> we've been discussing, or should I await further info?

It's worth to test my latest code, yes.  There are lots of fixes
there, too, together with code refactoring.

You can test either master, test/hda-gen-parser or test/hda-migrate
branch of sound-unstable tree:
  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git

Or if you want to avoid the kernel rebuild, you can try alsa-driver
externally from a snapshot tarball:
  ftp://ftp.suse.com/pub/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz


thanks,

Takashi