linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <bh40@calva.net>
To: Dan Malek <dan@netx4.com>, linuxppc-dev@lists.linuxppc.org
Subject: Re: SndConfig for Linux/PPC
Date: Mon, 27 Sep 1999 10:57:28 +0200	[thread overview]
Message-ID: <19990927105728.005663@mailhost.mipsys.com> (raw)
In-Reply-To: <37EE3B3A.F40E0D62@netx4.com>


On Sun, Sep 26, 1999, Dan Malek <dan@netx4.com> wrote:

>What version are you looking at?  The current version works and
>has mixer support.  The Rigth Way is always a personal opinion,
>and rewriting something for the sake of changing variable names
>or personal coding style is a waste of time.
>
>If you decide you have time to waste on this, make sure you start
>with the latest 2.3.x version, and ask me for all of the updates
>I have queued to test and check in over the next couple of weeks.

By the way, if someone is working on the sound driver, I'd be glad if
this person could have a look at the sleep/wakeup code and especially
make sure it works fine when a sound is currently playing. (In this case,
playback should be either resumed on wakeup or samples just killed and
the driver would then wait for more samples).

It works fine on my machine, but several users are experiencing trouble
with it, and I won't have time to do much work on linux this week. (With
luck, I'll be able to finish the new BootX version and cleanup a couple
of patches I have here, but that's all).

It looks like when atyfb.c is present, sleep tends to keep sound alive
which is not the case when disabling atyfb. The main difference is that
atyfb introduces a pause of approximately 500ms before the actual sleep
(and just after the wakeup).

Also, Geert, I don't know if you manage to find better default values for
MCLK, but it looks like the hangs on sleep/wakeup with chipID = 4c50 are
due to too high MCLK values. Lowering down the MCLK to 60 allowed one
user to sleep and wakeup without my horrible hack (which was to abort the
wait-chip-to-be-suspend when chipID 4c50 is encountered). 
I'm wondering if we should add code to limit the default MCLK (unless
manually specified) to 60 on the chips known to be in powerbooks. (or do
this whenever we are on a powerbook).


-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~1999-09-27  8:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-24 15:46 SndConfig for Linux/PPC Jeramy B Smith
1999-09-24 17:57 ` Anirudh Joshi
1999-09-26 15:26   ` Dan Malek
1999-09-27  8:57     ` Benjamin Herrenschmidt [this message]
1999-09-26 20:10   ` Geert Uytterhoeven
1999-09-26 21:35     ` Tom Rini
  -- strict thread matches above, loose matches on Subject: below --
1999-09-27 17:19 jeramy b smith
1999-09-27 17:24 ` Geert Uytterhoeven
     [not found] <37F32EBC.FAFD82E2@zib.de>
1999-09-30  9:41 ` Geert Uytterhoeven

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=19990927105728.005663@mailhost.mipsys.com \
    --to=bh40@calva.net \
    --cc=dan@netx4.com \
    --cc=linuxppc-dev@lists.linuxppc.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;
as well as URLs for NNTP newsgroup(s).