[OLPC-devel] Re: Audio suspend/resume status
Jim Gettys
jg at laptop.org
Thu Jun 15 09:23:38 EDT 2006
Jordan,
Can you reproduce Jaya's results?
Jaya, could you send us the source bits for the driver you have working?
Or are your bits committed to a git tree somewhere?
Regards,
- Jim
On Thu, 2006-06-15 at 11:37 +0800, Jaya Kumar wrote:
> 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
> > >
> > >
> >
> >
> >
> >
--
Jim Gettys
One Laptop Per Child
More information about the Devel
mailing list