Comment 29 for bug 1155202

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 <email address hidden>
> >>
> >> 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 <email address hidden>
> >> ---
> >> 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
>