[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <s5hskiwx21w.wl%tiwai@suse.de>
Date: Fri, 22 May 2009 23:25:47 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] sound fixes
At Fri, 22 May 2009 13:47:52 -0700 (PDT),
Linus Torvalds wrote:
>
>
>
> On Fri, 22 May 2009, Takashi Iwai wrote:
> >
> > please pull ALSA updates for v2.6.30-rc6 from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git for-linus
> >
> > containing just the following trivial fixes.
>
> Thanks, pulled.
>
> I also note that you've been active on
>
> http://bugzilla.kernel.org/show_bug.cgi?id=13250
>
> but quite frankly, my opinion is that the workaround listed there isn't a
> fix at all. Why isn't such a frontpanel configuration choice exported as a
> switch, so that you can access it with alsamixer, rather than playing
> crazy games with some magic sysfs files?
>
> If it cannot be autodetected, it should still be visible as a mixer
> option, not some magic. No?
Yeah, the method I suggested there is a typical "debug" procedure
and no right "fix" yet.
[Short background:
Basically the HD-audio is designed in a way that BIOS could specify
the proper h/w configuration, and the driver needs just to follow
that. The problem now is when the hardware doesn't match really with
what BIOS assumes -- i.e. the driver is fooled. In the bug above, the
box isn't connected to the front panel as BIOS expected. And, a
recent fix for the Headphone volume control appears now as if a
regression for his use case.]
We can of course add some mixer element to change the DAC assignment.
Some codecs have a mixer "Channel Mode" to change the surround mode.
In a similar way, the front HP / mic could be changed. But, the
implementation in patch_sigmatel.c is a bit complex to put such a
mixer element into the middle, so I'm afraid it would be a bit risky
at this stage.
Alternatively, what we did in most cases for such a case are to create
a specific quirk and let user pass via model option. For this
particular case, this would be a simpler fix because basically we just
need to give a new pin-config map like an (untested) patch below.
Anyway, I'll follow up the bug there with that patch...
thanks,
Takashi
---
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index 03b3646..922d05e 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -150,6 +150,7 @@ enum {
STAC_D965_REF,
STAC_D965_3ST,
STAC_D965_5ST,
+ STAC_D965_5ST_NO_FP,
STAC_DELL_3ST,
STAC_DELL_BIOS,
STAC_927X_MODELS
@@ -2154,6 +2155,13 @@ static unsigned int d965_5st_pin_configs[14] = {
0x40000100, 0x40000100
};
+static unsigned int d965_5st_no_fp_pin_configs[14] = {
+ 0x40000100, 0x40000100, 0x0181304e, 0x01014010,
+ 0x01a19040, 0x01011012, 0x01016011, 0x40000100,
+ 0x40000100, 0x40000100, 0x40000100, 0x01442070,
+ 0x40000100, 0x40000100
+};
+
static unsigned int dell_3st_pin_configs[14] = {
0x02211230, 0x02a11220, 0x01a19040, 0x01114210,
0x01111212, 0x01116211, 0x01813050, 0x01112214,
@@ -2166,6 +2174,7 @@ static unsigned int *stac927x_brd_tbl[STAC_927X_MODELS] = {
[STAC_D965_REF] = ref927x_pin_configs,
[STAC_D965_3ST] = d965_3st_pin_configs,
[STAC_D965_5ST] = d965_5st_pin_configs,
+ [STAC_D965_5ST_NO_FP] = d965_5st_no_fp_pin_configs,
[STAC_DELL_3ST] = dell_3st_pin_configs,
[STAC_DELL_BIOS] = NULL,
};
@@ -2176,6 +2185,7 @@ static const char *stac927x_models[STAC_927X_MODELS] = {
[STAC_D965_REF] = "ref",
[STAC_D965_3ST] = "3stack",
[STAC_D965_5ST] = "5stack",
+ [STAC_D965_5ST_NO_FP] = "5stack-no-fp",
[STAC_DELL_3ST] = "dell-3stack",
[STAC_DELL_BIOS] = "dell-bios",
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists