From: Johannes Berg <johannes@sipsolutions.net>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>, alsa-devel@alsa-project.org
Subject: Re: snd-aoa: g5 tas codec problems
Date: Fri, 07 Jul 2006 10:03:34 +0200 [thread overview]
Message-ID: <1152259414.15068.12.camel@localhost> (raw)
In-Reply-To: <1152258426.9862.44.camel@localhost.localdomain>
[-- Attachment #1.1: Type: text/plain, Size: 2332 bytes --]
On Fri, 2006-07-07 at 17:47 +1000, Benjamin Herrenschmidt wrote:
> Ok, so now I have it working on the G5 :)
Great :)
Powerbook woke itself an hour ago, no idea why, sorry for confusing you
on irc.
> - Maybe it's me or maybe it's just too complicated, but I haven't quite
> grasped the whole interaction between the soundbus,i2sbus,fabric and
> codecs... especially initialisation ordering. It would be nice if we
> could spend some time going through that and simplifying :) It leads to
> at least one of the problems
Yeah, well... I sorta know.
> - The patch fixes a couple of nits related to having the modules
> built-in: soundbus must really be a subsys_initcall() so it's
> initialized before anybody else, and I've put the soundbus/ dir before
> the codecs in the link order because the TAS is unhappy if loaded before
> i2s (see below)
Right.
> - The TAS is a nasty beast. It needs the i2s clocks enabled or it goes
> bunk... That's the problem with the G5. I've added a clock notifier and
> reset it completely when the clocks come back, that's what fixes the G5
> sound (looks like it loses state somewhat when not clocked). It would be
> nice to streamline/cleanup some of the TAS handling, maybe with register
> shadows like darwin or just with proper state variables to re-consitute
> the whole thing and have a "fast mode" load since we need to do it so
> often
Ahrg
> - Because of the above, starting to play a sound 1- takes some time to
> init things and 2- clacks (setting the mutes on TAS before losing clocks
> isn't enough, I think the fact that it goes bonk makes it parasite the
> analog outputs). We need to also mute the amps around that. I haven't
> quite figured how to do that from i2sbus though :) Also, we should try
> (if not already the case) to cache our clock/i2s state so that
> subsequent prepare() don't try to change things that are already ok.
> That way we avoid having to blast the codec each time. But right now,
> the important thing is to add mutes. People with external amplifiers
> will really not like those clacs...
Right. The way I did that with the onyx is that I told the GPIOs to mute
all amps from the clock switch callback.
I see you added DRC too, thanks :) I'll take a closer look after
breakfast ;)
johannes
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
[-- Attachment #2: Type: text/plain, Size: 299 bytes --]
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
[-- Attachment #3: Type: text/plain, Size: 161 bytes --]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Berg <johannes@sipsolutions.net>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>, alsa-devel@alsa-project.org
Subject: Re: snd-aoa: g5 tas codec problems
Date: Fri, 07 Jul 2006 10:03:34 +0200 [thread overview]
Message-ID: <1152259414.15068.12.camel@localhost> (raw)
In-Reply-To: <1152258426.9862.44.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2332 bytes --]
On Fri, 2006-07-07 at 17:47 +1000, Benjamin Herrenschmidt wrote:
> Ok, so now I have it working on the G5 :)
Great :)
Powerbook woke itself an hour ago, no idea why, sorry for confusing you
on irc.
> - Maybe it's me or maybe it's just too complicated, but I haven't quite
> grasped the whole interaction between the soundbus,i2sbus,fabric and
> codecs... especially initialisation ordering. It would be nice if we
> could spend some time going through that and simplifying :) It leads to
> at least one of the problems
Yeah, well... I sorta know.
> - The patch fixes a couple of nits related to having the modules
> built-in: soundbus must really be a subsys_initcall() so it's
> initialized before anybody else, and I've put the soundbus/ dir before
> the codecs in the link order because the TAS is unhappy if loaded before
> i2s (see below)
Right.
> - The TAS is a nasty beast. It needs the i2s clocks enabled or it goes
> bunk... That's the problem with the G5. I've added a clock notifier and
> reset it completely when the clocks come back, that's what fixes the G5
> sound (looks like it loses state somewhat when not clocked). It would be
> nice to streamline/cleanup some of the TAS handling, maybe with register
> shadows like darwin or just with proper state variables to re-consitute
> the whole thing and have a "fast mode" load since we need to do it so
> often
Ahrg
> - Because of the above, starting to play a sound 1- takes some time to
> init things and 2- clacks (setting the mutes on TAS before losing clocks
> isn't enough, I think the fact that it goes bonk makes it parasite the
> analog outputs). We need to also mute the amps around that. I haven't
> quite figured how to do that from i2sbus though :) Also, we should try
> (if not already the case) to cache our clock/i2s state so that
> subsequent prepare() don't try to change things that are already ok.
> That way we avoid having to blast the codec each time. But right now,
> the important thing is to add mutes. People with external amplifiers
> will really not like those clacs...
Right. The way I did that with the onyx is that I told the GPIOs to mute
all amps from the clock switch callback.
I see you added DRC too, thanks :) I'll take a closer look after
breakfast ;)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2006-07-07 8:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-07 7:47 snd-aoa: g5 tas codec problems Benjamin Herrenschmidt
2006-07-07 7:47 ` Benjamin Herrenschmidt
2006-07-07 7:50 ` Benjamin Herrenschmidt
2006-07-07 7:50 ` Benjamin Herrenschmidt
2006-07-07 13:43 ` Johannes Berg
2006-07-07 13:43 ` Johannes Berg
2006-07-07 8:03 ` Johannes Berg [this message]
2006-07-07 8:03 ` Johannes Berg
2006-07-07 8:12 ` Benjamin Herrenschmidt
2006-07-07 8:12 ` Benjamin Herrenschmidt
2006-07-07 8:49 ` Johannes Berg
2006-07-07 8:49 ` Johannes Berg
2006-07-07 8:56 ` Benjamin Herrenschmidt
2006-07-07 8:56 ` Benjamin Herrenschmidt
2006-07-07 9:04 ` Johannes Berg
2006-07-07 9:04 ` Johannes Berg
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=1152259414.15068.12.camel@localhost \
--to=johannes@sipsolutions.net \
--cc=alsa-devel@alsa-project.org \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.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 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.