public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Liam Girdwood <liam.girdwood@wolfsonmicro.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [BUG] unsafe reset in ac97_codec.c
Date: Thu, 05 Feb 2004 16:31:57 +0000	[thread overview]
Message-ID: <1075998717.5204.1003.camel@cearnarfon> (raw)
In-Reply-To: <40216306.2010602@pobox.com>

On Wed, 2004-02-04 at 21:24, Jeff Garzik wrote:

> In general it's important for Linux to be able to reset a device 
> reliable.  Where in Other Operating Systems one must reboot the 
> computer, Linux users can just re-load the driver quite often.
> 
> So I think there are two comments here:
> 
> * I can certainly see -probing- being unreliable (but not necessarily reset)

I agree, but I think we need to be aware of the codec type before we do
a register reset. This type of codec is now becoming popular in PDA's.

> 
> * If the default state for some devices is power-down, the driver should 
> be aware of that -anyway-, and we should power up on startup or on-demand.
> 

I can see another problem with the current probe implementation.
Currently it sends the register reset command without first checking the
codec ready bit. This assumes that the AC97 link is up and completely
working before probe is called.

I would like to suggest some changes to probe:-

1. We have a new flag AC97_DEFAULT_POWER_OFF in ac97_codec_ids[] to mark
codecs that have a default power state of "off".

2. Probe checks the codec ready bit (or waits 10uS) first before doing
anything else.

3. Probe reads the codec ID (hardwired codec registers) and if the codec
is of type AC97_DEFAULT_POWER_OFF then goes to step 6. In this case the
code that calls probe will have done a warm reset to wake the codec in
the first place.

4. Send register reset to codec.

5. wait for codec ready bit. 

6. carry on as original probe, by reading register AC97_RESET

I'll implement this if it's acceptable as I can test it on both types of
codec.

Liam




  reply	other threads:[~2004-02-05 16:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-03 15:42 [BUG] unsafe reset in ac97_codec.c Liam Girdwood
2004-02-04 21:24 ` Jeff Garzik
2004-02-05 16:31   ` Liam Girdwood [this message]
2004-02-05 17:59     ` Alan Cox
2004-02-26 15:55       ` Liam Girdwood
2004-02-29 18:38         ` Jeff Garzik

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=1075998717.5204.1003.camel@cearnarfon \
    --to=liam.girdwood@wolfsonmicro.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=jgarzik@pobox.com \
    --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