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
>
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox