All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryan Dunn <oryandunn.ml@gmail.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: module snd-atiixp issue with suspend/hibernate/resume
Date: Thu, 30 Apr 2009 07:49:57 -0400	[thread overview]
Message-ID: <bf4fda4a0904300449v7a5db4d6vfdf2f772ce102543@mail.gmail.com> (raw)
In-Reply-To: <s5h1vralmag.wl%tiwai@suse.de>

Thanks Takashi,

I did a bit more testing last night.  The LED does work after a reboot (I
don't know what I was doing that I thought it didn't).  It also retains
state after a reboot if I muted it before the reboot.  One thing I noticed,
if I have it muted when I suspend, on resume, it looks like the mute led
flashes back on for a split second, then turns off.  Maybe the resume code
is overwriting the register?  I'll start digging through that code tonight.

Ryan

On Thu, Apr 30, 2009 at 1:53 AM, Takashi Iwai <tiwai@suse.de> wrote:

> At Thu, 30 Apr 2009 00:43:02 -0400,
> Ryan Dunn wrote:
> >
> > Thanks Lee,
> >
> > I grabbed the kernel source from the repos and started perusing the
> code.  It
> > looks like when the module is installed, the call chain starts in
> atiixp.c and
> > moves into ac97/ac97_codec.c via a call to snd_ac97_tune_hardware() which
> > ultimately twiddles a bit in the AC97_POWERDOWN register.  I'm not sure
> yet if
> > the suspend method properly saves this register on suspend or not;
>
> It should.  snd_ac97_resume() writes the cached value.
> Check /proc/asound/card0/codec97#0/ac97#*+regs files before and after
> suspend.  You can change the codec register value directly via proc
> file, e.g.
>    # echo 0x12 0x1234 > /proc/asound/card0/codec97#0/ac97#0-0+regs
> (only when you build with the debug option).
>
> The bit 0x8000 of the power-down register should correspond to LED.
>
>
> Takashi
>
> > or if the
> > same call chain needs to be repeated on a resume.  I appreciate your
> quick and
> > relevant answer.  When I get time, I'll start adding some debug printouts
> to
> > try this out.
> >
> > Also, the struct ac97_quirk ac97_quirks[] array has a couple of entries
> in it
> > currently (in the atiixp.c file).  How do I get the subvender/subdevice
> id's
> > for my system (I didn't seem to have luck with lspci, unless I'm not
> looking
> > in the right fields)?  Would it be possible to edit the driver so that an
> > explict module option would not be needed on my hardware?
> >
> > Thanks,
> > Ryan
> >
> > On Wed, Apr 29, 2009 at 10:42 PM, Lee Revell <rlrevell@joe-job.com>
> wrote:
> >
> >     On Wed, Apr 29, 2009 at 12:06 AM, Ryan Dunn <oryandunn.ml@gmail.com>
> >     wrote:
> >     > I have a Compaq V2000 laptop with the ATI IXP chipset and make use
> of
> >     the
> >     > snd-atiixp module.  The laptop needs to have the ac97_quirk option
> set
> >     to 7
> >     > to enable the mute LED.  After setting this option in the
> >     > /etc/modprobe.d/options.conf file, the mute LED works after a
> reboot.
> >     > However, after a resume from suspend or hibernate, the mute LED
> does not
> >     > work.  The alsa-info.sh script reports that the quirk is still set
> with
> >     7.
> >     > At this point a reboot will NOT fix the problem.  The only way to
> fix it
> >     is
> >     > to remove and reinsert the module with modprobe.
> >     >
> >     > This is on a fresh Ubuntu 9.04 install.  Any ideas?  I wasn't sure
> if
> >     this
> >     > should be reported here or on the kernel list.  I saw a similar
> issue
> >     with
> >     > the ac97_quirk on the kernel list and they were referred here.  I'm
> a
> >     > software developer, so I'd be willing to try ideas/possible
> solutions if
> >     you
> >     > have them.
> >
> >     Get the Ubuntu source code for the package that owns that ALSA
> driver,
> >     find the place in the driver's initialization code where ac97_quirk=7
> >     is handled, then check the driver's suspend and resume callbacks and
> >     make sure the suspend callback is correctly saving the LED state and
> >     that the resume callback is re-initializing the LED from the saved
> >     state in the same way the init code does.  grep and printk() are your
> >     friends ;-)
> >
> >     HTH,
> >
> >     Lee
> >
> >
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

  reply	other threads:[~2009-04-30 11:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-29  4:06 module snd-atiixp issue with suspend/hibernate/resume Ryan Dunn
2009-04-30  2:42 ` Lee Revell
2009-04-30  4:43   ` Ryan Dunn
2009-04-30  5:53     ` Takashi Iwai
2009-04-30 11:49       ` Ryan Dunn [this message]
2009-05-01  2:12         ` Ryan Dunn
2009-05-01  2:24           ` Ryan Dunn
2009-05-04  7:02             ` Takashi Iwai
2009-05-05  0:21               ` Ryan Dunn
2009-05-05 10:52                 ` Takashi Iwai

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=bf4fda4a0904300449v7a5db4d6vfdf2f772ce102543@mail.gmail.com \
    --to=oryandunn.ml@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=tiwai@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.