[alsa-devel] [RFC PATCH] ALSA: hda - Detect codecs on Intel DZ77SL-50K
From: Niraj kulkarniniraj@rediffmail.com
Apparently this board seems to need some extra initialization before a proper codec probe value can be read.
BugLink: https://bugs.launchpad.net/bugs/1155202 Signed-off-by: David Henningsson david.henningsson@canonical.com --- sound/pci/hda/hda_intel.c | 6 ++++++ 1 file changed, 6 insertions(+)
Hi Takashi,
Here's a patch from Niraj, which has found this code below to make audio work on the Intel DZ77SL-50K board. Without it, no codecs will be detected.
I'm not sure if you like it this way or if you want me or Niraj to change anything, or debug further. Or maybe add a new quirk for this particular device?
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index fa2879a..2bf46e9 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1306,6 +1306,12 @@ static void azx_init_chip(struct azx *chip, int full_reset)
/* reset controller */ azx_reset(chip, full_reset); + if (!chip->codec_mask) { + azx_writel(chip, GCTL, 0x100); + while(azx_readl(chip, GCTL) != 0x0); + azx_writel(chip, GCTL, 0x1); + azx_reset(chip, full_reset); + }
/* initialize interrupts */ azx_int_clear(chip);
At Wed, 22 Jan 2014 12:32:28 +0100, David Henningsson wrote:
From: Niraj kulkarniniraj@rediffmail.com
Apparently this board seems to need some extra initialization before a proper codec probe value can be read.
BugLink: https://bugs.launchpad.net/bugs/1155202 Signed-off-by: David Henningsson david.henningsson@canonical.com
sound/pci/hda/hda_intel.c | 6 ++++++ 1 file changed, 6 insertions(+)
Hi Takashi,
Here's a patch from Niraj, which has found this code below to make audio work on the Intel DZ77SL-50K board. Without it, no codecs will be detected.
I'm not sure if you like it this way or if you want me or Niraj to change anything, or debug further. Or maybe add a new quirk for this particular device?
Of course, I don't like this :)
The patch essentially disables the codec reset in *all* cases after a codec is probed. This smells badly of a future regression.
FWIW, you can set a forced codec probe mask in probe_mask_list[]. The bit 0x100 means to force the detection.
But, before going that direction, could you clarify how this fixes the probing at all? Which azx_init_chip() calls hinders the probing of an active codec?
thanks,
Takashi
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index fa2879a..2bf46e9 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1306,6 +1306,12 @@ static void azx_init_chip(struct azx *chip, int full_reset)
/* reset controller */ azx_reset(chip, full_reset);
if (!chip->codec_mask) {
azx_writel(chip, GCTL, 0x100);while(azx_readl(chip, GCTL) != 0x0);azx_writel(chip, GCTL, 0x1);azx_reset(chip, full_reset);}
/* initialize interrupts */ azx_int_clear(chip);
-- 1.7.9.5
On 01/22/2014 12:40 PM, Takashi Iwai wrote:
At Wed, 22 Jan 2014 12:32:28 +0100, David Henningsson wrote:
From: Niraj kulkarniniraj@rediffmail.com
Apparently this board seems to need some extra initialization before a proper codec probe value can be read.
BugLink: https://bugs.launchpad.net/bugs/1155202 Signed-off-by: David Henningsson david.henningsson@canonical.com
sound/pci/hda/hda_intel.c | 6 ++++++ 1 file changed, 6 insertions(+)
Hi Takashi,
Here's a patch from Niraj, which has found this code below to make audio work on the Intel DZ77SL-50K board. Without it, no codecs will be detected.
I'm not sure if you like it this way or if you want me or Niraj to change anything, or debug further. Or maybe add a new quirk for this particular device?
Of course, I don't like this :)
The patch essentially disables the codec reset in *all* cases after a codec is probed. This smells badly of a future regression.
Hmm, but I don't see how the patch *disables* any codec reset. It only does an *extra* controller reset in some cases.
FWIW, you can set a forced codec probe mask in probe_mask_list[]. The bit 0x100 means to force the detection.
Yes, we tried this and it did not help. If the codecs do not show up naturally in STATETS, then they cannot be communicated with either.
But, before going that direction, could you clarify how this fixes the probing at all? Which azx_init_chip() calls hinders the probing of an active codec?
It seems more like, the particular chip or board requires a special quirky initialization sequence.
thanks,
Takashi
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index fa2879a..2bf46e9 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1306,6 +1306,12 @@ static void azx_init_chip(struct azx *chip, int full_reset)
/* reset controller */ azx_reset(chip, full_reset);
if (!chip->codec_mask) {
azx_writel(chip, GCTL, 0x100);while(azx_readl(chip, GCTL) != 0x0);azx_writel(chip, GCTL, 0x1);azx_reset(chip, full_reset);}
/* initialize interrupts */ azx_int_clear(chip);
-- 1.7.9.5
At Wed, 22 Jan 2014 13:25:34 +0100, David Henningsson wrote:
On 01/22/2014 12:40 PM, Takashi Iwai wrote:
At Wed, 22 Jan 2014 12:32:28 +0100, David Henningsson wrote:
From: Niraj kulkarniniraj@rediffmail.com
Apparently this board seems to need some extra initialization before a proper codec probe value can be read.
BugLink: https://bugs.launchpad.net/bugs/1155202 Signed-off-by: David Henningsson david.henningsson@canonical.com
sound/pci/hda/hda_intel.c | 6 ++++++ 1 file changed, 6 insertions(+)
Hi Takashi,
Here's a patch from Niraj, which has found this code below to make audio work on the Intel DZ77SL-50K board. Without it, no codecs will be detected.
I'm not sure if you like it this way or if you want me or Niraj to change anything, or debug further. Or maybe add a new quirk for this particular device?
Of course, I don't like this :)
The patch essentially disables the codec reset in *all* cases after a codec is probed. This smells badly of a future regression.
Hmm, but I don't see how the patch *disables* any codec reset. It only does an *extra* controller reset in some cases.
Ah, yes. I misread the code.
FWIW, you can set a forced codec probe mask in probe_mask_list[]. The bit 0x100 means to force the detection.
Yes, we tried this and it did not help. If the codecs do not show up naturally in STATETS, then they cannot be communicated with either.
OK.
But, before going that direction, could you clarify how this fixes the probing at all? Which azx_init_chip() calls hinders the probing of an active codec?
It seems more like, the particular chip or board requires a special quirky initialization sequence.
The problem is that it doesn't explain exactly what this special initialization does. How does this magic sequence come? For example, why does it need to set UNSOL flag at first? Is the while loop guaranteed to quit for a reasonable time? Can't it be simply calling azx_reset() twice?
And, yet another question comes up: doesn't S4 need the similar workaround? If S4 works, what's the difference?
Takashi
thanks,
Takashi
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index fa2879a..2bf46e9 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1306,6 +1306,12 @@ static void azx_init_chip(struct azx *chip, int full_reset)
/* reset controller */ azx_reset(chip, full_reset);
if (!chip->codec_mask) {
azx_writel(chip, GCTL, 0x100);while(azx_readl(chip, GCTL) != 0x0);azx_writel(chip, GCTL, 0x1);azx_reset(chip, full_reset);}
/* initialize interrupts */ azx_int_clear(chip);
-- 1.7.9.5
-- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
participants (2)
-
David Henningsson -
Takashi Iwai