mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Thadeu Lima de Souza Cascardo <cascardo@minaslivre.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Wait for all codecs to be ready if doing a cold reset
Date: Thu, 18 Dec 2008 08:18:40 +0100	[thread overview]
Message-ID: <s5hiqpix86n.wl%tiwai@suse.de> (raw)
In-Reply-To: <20081217220829.GF3672@vespa.holoscopio.com>

At Wed, 17 Dec 2008 20:08:30 -0200,
Thadeu Lima de Souza Cascardo wrote:
> 
> On Mon, Jul 14, 2008 at 09:10:39PM -0300, Thadeu Lima de Souza Cascardo wrote:
> > On Wed, Jul 16, 2008 at 01:47:03AM +0200, Takashi Iwai wrote:
> > > Thanks.
> > > 
> > > Meanwhile, I reconsidered about this problem.  I think the check of
> > > the whole "active" codec slots can be done better in a way like the
> > > following.  Could you give it a try?
> > > 
> > > If this still doesn't work, I suspect it's really the matter of
> > > additional delay.
> > > 
> 
> I've put some more effort on this issue last weekend. Here is the
> result:
> 
> The codec I have is AD1881A. The additional delay makes a pretty
> difference, right. Only the delay is enough to solve it.

It's a good news, at least.

> However, I agree this is not the right solution. The codec_init_bits
> solution does not work.
> 
> I have diff'ed the value of the codec registers and they are different
> from all the other situations I tested, that are:
> 
> * booted my notebook: OK
> * suspended, resumed, reloaded the driver: OK
> * loaded the driver with no cold reset
>   (no AC97_POWER_SAVE on intel8x0): OK
> * same as above, after resuming: OK
> * AC97_POWER_SAVE enabled (cold reset), after resume: NOT ok
> 
> As previously reported, even when probing, after loading the driver, we
> get a different behaviour if we cold reset. When probing, we wait for
> those HZ/4, which may explain why everything works.
> 
> I tested if ac97_resume was writing the same values to the same
> registers if I had the delay or if I didn't. It was. However, the values
> I read from /proc were still different, very similar to what the codec
> specification refered to as the default values.
> 
> The best solution would be to do whatever is needed to do after cold
> resetting that we are not doing, unless it is a hardware issue and the
> driver can't really do anything about it but wait. Reading the Intel
> ICH3 doc and AD1881A doc, I couldn't figure out anything that the driver
> is doing wrong.
> 
> So, right now, the alternatives amount to:
> 
> * Wait for the HZ/4 additional delay. Probing is doing it and my
> previously submitted patch does not add any delay for the probe case
> and, it the resume case, it only adds a delay if we are cold resetting,
> that is, AC97_POWER_SAVE is enabled.
> 
> * Do not do the cold reset at all. It works pretty well for me if ac97
> power save is enabled and we only do a warm reset.
> 
> * Do only one of the above as a quirk for my controller or codec or
> their combination.

I feel it's not only your machine that a similar thing happens.
OTOH, adding the delay selectively would be good, at least, for an old
driver with AC97.  So, checking the machine could be a better option
at this stage.

So, my bet is the third one, adding a (sort of) quirk to disable the
cold reset.  I'm not sure whether yet another module option is the
best way, though...


thanks,

Takashi

      reply	other threads:[~2008-12-18  7:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-06 17:15 Thadeu Lima de Souza Cascardo
2008-07-07 16:39 ` Takashi Iwai
2008-07-07 17:36   ` Thadeu Lima de Souza Cascardo
2008-07-08 10:16     ` Takashi Iwai
2008-07-08 16:59       ` Thadeu Lima de Souza Cascardo
2008-07-09 15:07         ` Takashi Iwai
2008-07-08 17:31           ` Thadeu Lima de Souza Cascardo
     [not found]             ` <s5h63rezzlb.wl%tiwai@suse.de>
2008-07-09 17:26               ` Thadeu Lima de Souza Cascardo
2008-07-15 23:47                 ` Takashi Iwai
2008-07-15  0:10                   ` Thadeu Lima de Souza Cascardo
2008-12-17 22:08                     ` Thadeu Lima de Souza Cascardo
2008-12-18  7:18                       ` Takashi Iwai [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hiqpix86n.wl%tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=cascardo@minaslivre.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®