Re: Sound stoppage

Yasso Kostas!!! (I thought you'd gone out of circulation),

quoted

quoted

I have no idea if how AWACS' tx dbdma behaves, but it may be necessary to
make the write to control register multi-step or something, i.e., clear
RUN [in order to clear DEAD bit] and wait until RUN bit is cleared by hw,
then set RUN|WAKE..

OK... that is different (in detail) from what was tried before - I think
I'll ask for a volunteer to test this...  Peter?

Thats more or less what i first tried (with no luck...)

The code I posted (this am) is a subtle modification of what you tried - I
have to admit I don't expect it to behave differently - but the savings
would be very good if it does...

quoted

quoted

quoted

If it would, then we could save all this hassle completely...

BTW: I don't *think* it does because one of my testers tried a similar
method to the one you proposed and said it chopped up/repeated sound.

quoted

Hmm, I think it has to be either "chopped up" or "repeated" not both..  As
far as dbdma is concerned, those two are quite different effects.

Well, with fragments of a few tens of ms - it's all highly subjective.

With any ide activity the dbdma commands can fail repeatedly for a looong time
in my machine (some times up to 10secs).....

even with IRQs allowed using hdparm ?

quoted

I see it like this:

The sound is chopped up (since some form of blocking has caused the problem
in the first place)  and then the "fix" causes part of the sound to be
repeated - I think this is the origin of the apparently conflicting report.

If the failed command is ignored then we have the "chopped up" effect (a
3min song finishes in less than 30secs this way under heavy ide activity..)
The "repeated" effect shows up if the packet is resend to dbdma.

well, OK - let's see if the (very slight) change to what you did makes any
difference.

btw about the sound related macos patch for some powercomputing machines
might have nothing to do with this problem. Sound works fine in macos in my
PowerWave without it, so macos already handles it right.

The MacOS extension patch fixes a "PCI timing problem" - specifically
claimed to stop PCI-based-IDE/Sound interaction (which is what we are
seeing).

- maybe later versions of MacOS already have the extension "built-in".

Iain.

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

The MacOS extension patch fixes a "PCI timing problem" - specifically
claimed to stop PCI-based-IDE/Sound interaction (which is what we are
seeing).

I quickly disassembled the extension, what it does is to write

  0x00000858 (swapped) -> 0xf2800000
  0x12 (byte)          -> 0xf2c00000

Which is basically writing 0x12 to byte at address 0x58 of Bandit
PCI bridge config space.

Now we need to figure out how to identify this machine/bandit model to
make sure we don't scew up bandit on another box.

Can someone try to figure out in the device-tree if there's anything like
a machine ID ? (the "old" mac-os like box ID is 0x66 I think, but I don't
know if it can be found in the device tree. It may be available via mother
board straps around 0xf3000000 however).

I'd also like to know the bandit deviceID & revisionID in it's PCI config
space.

Ben.


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