[OLPC-devel] Re: Audio suspend/resume status

Jaya Kumar jayakumar.lkml at gmail.com
Wed Jun 14 23:37:39 EDT 2006


On 6/14/06, Jim Gettys <jg at laptop.org> wrote:
> Jaya, Jordan, Marcelo,
>
> We're having trouble getting *any* audio input to work, much less the
> analog input "sensor" mode to work.

Regular mic input works fine for me.

I'm using 2.6.17 cs5535audio + cs5535audio PM + duplicate ac97 control
(this is the patch that I posted as a replacement for the initial OLPC
bringup patch). These patches are all in Jordan's tree too, I think.

>
> If any of you have time to look into this, it would be greatly
> appreciated.

Here's my test procedure:

insmod /tree/linux-2.6.17-rc5/sound/pci/cs5535audio/snd-cs5535audio.ko
amixer set PCM 100 on && amixer set Master 100 on && amixer set Mic
100 on && amixer set 'Mic Boost (+20dB)' on
arecord -d 10 > /tmp/out.wav
# talk for 10 seconds at this point
aplay /tmp/out.wav
# plays back fine for me

I assume your application may be different. Can you see if there are
any error messages in dmesg. Which source is your app reading from?
What levels are your mixer controls set to? What do you hear on
playback?

jaya

>                               Regards,
>                                 - Jim Gettys
>
>
> On Tue, 2006-06-13 at 22:26 +0800, Jaya Kumar wrote:
> > Hi guys,
> >
> > Just a note about the current status of audio suspend/resume. I just
> > tested cs5535audio suspend/resume. It does not work on the OLPC board.
> >
> > Here's what you will see with the current driver + the cs5535audio PM
> > patch (which is in the ALSA as well as Jordan's tree):
> >
> > insmod /tree/linux-2.6.17-rc5/sound/pci/cs5535audio/snd-cs5535audio.ko
> > amixer set PCM 100 on && amixer set Master 100 on
> > aplay /tree/test.wav
> > # this will work fine, ie: you should hear something
> > echo -n 3 > /sys/devices/pci0000\:00/0000\:00\:0f.3/power/state
> > # this should suspend everything. i'm not getting the typical dmesg
> > output i'm used to. so i suspect something weird at this point.
> > aplay /tree/test.wav
> > # playback is blocked as expected
> > echo -n 0 > /sys/devices/pci0000\:00/0000\:00\:0f.3/power/state
> > # ought to resume the playback, we appear to get interrupts but no
> > sound comes out. that suggests ad1888 codec is still down.
> > # nothing plays back at this point. no sound until i reload the driver
> >
> > So I suspect there's a problem with the AD1888 suspend or resume
> > sequence in this case even prior to attempting enhanced suspend.
> >
> > Here are my notes about Howard Ho (Insyde)'s (AD1888) patch which was
> > in the code drop labeled 1888:
> > - the patch is for the geode driver as opposed to current work which
> > is on the cs5535audio driver
> > - he mentions going into PR5 mode, but what I believe we want to go to
> > is Standby mode which is the 0 static power state. That is different
> > from PR5 as far as I can tell. The datasheet states:
> >
> > Parameter PR[K:I]1PR[6:0]1DVDD Typ AVDD Typ Unit
> > Standby 111 011 1111 0 0 mA
> >
> > - He mentions using alsactl to suspend/resume the codec and suggests
> > using the older release of alsa to get that ioctl. I believe that path
> > was deprecated. We switched to generic /sys based suspend/resume as
> > shown above since alsa 1.0.11 or so.
> >
> > - The code in the patch itself is not something that could be merged
> > into a generic tree. For example:
> >
> > pci/geode/amd_geode.c
> > #ifdef CONFIG_AD1888_PM
> >         snd_geode_SetPowerState(pGeode, GEODEAUDIO_D4);
> > #else
> >         snd_geode_SetPowerState(pGeode, GEODEAUDIO_D3);
> > #endif
> >         pci_disable_device(pAmd->pci);
> > #ifdef CONFIG_AD1888_PM
> >         snd_power_change_state(card, SNDRV_CTL_POWER_D3cold);
> >         --pm_f;
> > #else
> >         snd_power_change_state(card, SNDRV_CTL_POWER_D3hot);
> > #endif
> >
> > What we need to do is something that takes advantage of ALSA's
> > build_ops->suspend/resume layer so that the fix becomes generic and
> > applicable to all AD1888 boards rather than a hardcoded suspend. It's
> > not a lot of code to do it properly within the framework of ALSA so
> > I've started doing that.
> >
> > The next steps in the audio area are:
> > 1. resolve current codec suspend/resume problem
> > 2. develop Standby state support in ad1888 suspend/resume
> > 3. add mixer control for VREFOUT disable for sensor mode.
> >
> > I'll CC you guys on emails to Takashi/Jaroslav to figure out the least
> > intrusive path for 2.
> >
> > Thanks,
> > jaya
> --
> Jim Gettys
> One Laptop Per Child
>
>
>
>
> ---------- Forwarded message ----------
> From: "Mark J. Foster" <mfoster at laptop.org>
> To: jg at laptop.org
> Date: Wed, 07 Jun 2006 14:01:03 -0700
> Subject: Re: "Sensor Mode" and A-Test Schematics
> Hi, Jim,
>
> Since the EC code isn't available yet, which will normally control entry
> into "sensor mode", a hardware mod is instead required.  On the A-Test
> boards, you can either lift pin 4 of U24 and tie it to pin 5 of U24, or
> you can just short across C35 for now (this one's easier, since you just
> make a solder ball on top of the capacitor).  That serves to DC couple
> the input.
>
> The other step is software - you'll need to turn off the AD1888's
> external VREF_OUT function. I don't have the data sheet here, but this
> is a programmable feature - it's listed in the chip docs.
>
> Once those two are done, you should have a DC-coupled, normal A/D
> input.  After that, you program the sound chip as you would normally.
>
> I'm attaching the A-Test schematics, which also contains the change log
> from the pre-A Test PCBs.
>
> Cheers!
> MarkF
>
> Jim Gettys wrote:
> > A former media lab person, Miller Puckette, now a prof at UCSD, (and my
> > second cousin), is likely to recreate his 1976 demo of a conductor's
> > baton, built with a very cheap photo-diode (remember Semour pushing for
> > DC input? ;-)), for Barry Vercoe's keynote address in a few weeks.
> >
> > So do we have to do anything to go from AC coupled audio in to using the
> > codec as a a/d converter?  How was this done?  (our schematic reading
> > skills are not what they could be...).
> >                     Regards,
> >                          - Jim
> >
> >
>
>
>
>



More information about the Devel mailing list