dmasound problems

dmasound problems

[BenH]

On Mon, Nov 29, 1999, BenH <bh40@calva.net> wrote:

>BTW, dmasound is broken in Paul's current stable 2.2.14pre. I don't know yet
>what's going on but it looks like the driver had major changes (backported
>sound in from 2.3.x ?). I can't get any sound output on my wallstreet
anymore.
>I'll try to look into this next week.

It's not so broken finally, but I didn't find the solution yet. What
happens is that sometimes, the dmasound module has to be removed and
inserted back for sound to work.
Also, I don't think there is actually any difference between 2.2.13 and
2.2.14pre9 versions of the driver, the differences I experienced were
probably due to the state of the sound chip left by MacOS.

I've tried to track this down and found the following:

 - the sound chip can be controlled via 2 FCR bits in heathrow (mac-io +
0x38), 0x10000 must be cleared and 0x20000 must be set. (You should
endian-inverse them, those are the "readable" version matching
definitions in ohare.h ;) One is the power, the other one controls the
clock, and according to OF, the 0x10000 one is the power (and is inverted
logic). Looks a bit weird, I tend to think that it's actually a reset (OF
is sometimes wrong), but this is the way they work. Eventually, one of
them may be actually the amplifiers but I'm not sure (I'll try hacking
the i2c later).
Basically, look with xmon at mac-io + 0x39. If the byte you see contains
bit 0 unset and bit 1 set, that's ok. Any other combination means no
sound. (And I can somtimes hear a slight "click" when toggling the bits).

 - If I shut the chip down and re-enable it using xmon (dmasound.o not
installed), and then I do a insmod of the module, I have no sound

 - If I shut the chip down, re-enable it using xmon, and then insmod
dmasound.o, rmmod dmasound, and re-insmod dmasound.o immediately, then
sound works.

I tried reproducing the complete init-cleanup-init sequence in
dmasound_init() without luck (weird...). There must be some kind of
timing issue out there, or I missed something. I don't know the AWACS
chip very well so it's difficult to guess.

The machine is a wallstreet with an awacs revision 3 and no CUDA (so the
i2c code is not used).


Any clues ?


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

Re: dmasound problems

[Dan Malek]

BenH wrote:


> I tried reproducing the complete init-cleanup-init sequence in
> dmasound_init() without luck (weird...). There must be some kind of
> timing issue out there, or I missed something. I don't know the AWACS
> chip very well so it's difficult to guess.

If these are actually a power and reset to the audio codec, there
are timing constraints.  Usually, you have to power up and hold
reset at least 50 milliseconds before releasing reset (Crystal
codec specs).

This is why it may work with XMON if you set/clear bits
individually, but not work when you run the code.


	-- Dan

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

Re: dmasound problems

[Benjamin Herrenschmidt]

On Mon, Nov 29, 1999, Dan Malek <dan@netx4.com> wrote:

>If these are actually a power and reset to the audio codec, there
>are timing constraints.  Usually, you have to power up and hold
>reset at least 50 milliseconds before releasing reset (Crystal
>codec specs).
>
>This is why it may work with XMON if you set/clear bits
>individually, but not work when you run the code.

This was indeed a couple of timing issue (not only with those FCR bits
BTW). I traced MacOS and it sets both bits almost at the same time, so I
beleive this is not a reset issue, but I have to wait 1 sec
(mdelay(1000)) after setting the power bit and before programming the
chip if I want it to work. I tried various smaller delays, but 1s seems
the correct value. (with lower delays, I could still access the chip
registers and read the revision number, but I had no sound).

I still have one problem with the console beep not coming back after
sleep (if I launch mpg123, it plays fine and my beep is back. Also,
sleeping while mpg123 is playing correctly resume the play). This chip
seems to be very sensitive to timings in general.

A fix will be with my other patches (ibook, ...). Also, the sound chip is
now correctly powered off when the machine goes to sleep (or when
dmasound module is removed).


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

Re: dmasound problems

[Dan Malek]

Benjamin Herrenschmidt wrote:


> I still have one problem with the console beep not coming back after
> sleep (if I launch mpg123, it plays fine and my beep is back. Also,
> sleeping while mpg123 is playing correctly resume the play). This chip
> seems to be very sensitive to timings in general.

As I recall, the beep is a shortcut path through the driver and
makes assumptions about the sound interface configuration (i.e.
powered up, initialized, etc.).  Running some application that
follows the entire path to open and initialize the interface
will then make the beep happy.


> now correctly powered off when the machine goes to sleep (or when
> dmasound module is removed).

If you unload the module, I suspect console beep will go away
as well???


	-- Dan

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

Re: dmasound problems

[Benjamin Herrenschmidt]

On Tue, Nov 30, 1999, Dan Malek <dan@netx4.com> wrote:

>If you unload the module, I suspect console beep will go away
>as well???

Obiously, the beep goes away when the module is not here. However, I
managed to have the beep back as soon as the module is insmod'ed. (by
adding a 1ms delay after the awacs_write(0x6000)).


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