Re: Sound stoppage: TRIAL code to re-start DEAD dma

 Wed, Mar 28, 2001, Kostas Gewrgiou wrote:

On Wed, 28 Mar 2001, Iain Sandoe wrote:

quoted

attached is a replacement for the dmasound_awacs tx_irq routine to test out
Takashi's idea of clearing the DEAD status and then re-starting dma.

it is *not* a diff - you will have to replace the routine by cut-and-paste

(I've done it this way because my current tree has lots of other changes
which aren't relevant to this test).

I checked it builds - but can't test 'cos I don't have a PowerComputing
machine.

Please try it with big-ish fragments - so that there is a chance of hearing
whether resumed blocks repeat sound.

With a quick look it doesn't seem that it will work, you only need to return
if you restart the frame otherwise the driver will deadlock,

we do restart the frame - with the:

    /* may as well try anyway - I guess all bets are off now */
    out_le32(&awacs_txdma->control, ((RUN|WAKE) << 16) + (RUN|WAKE));

the difference from what you did is that I don't re-load the cmdptr register
- we are just going to see if the current state can be resumed.

It might lock up - but it's worth a try.

Do we need the in_le32(&awacs_txdma->status) & RUN check ? isn't dbdma
already inactive at that point ?

maybe - I think that the ACTIVE bit will be cleared.

but maybe not the RUN bit - because I think the transition *in the on-chip
register* from RUN to ~RUN acknowledges the clearing of the DEAD status.

then the command above restarts it...

well, that's what we're trying anyway - I've coded the emergency dbdma
method - so if this fails I'll post that instead.

ciao,
Iain.

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

On Wed, 28 Mar 2001, Iain Sandoe wrote:

quoted

With a quick look it doesn't seem that it will work, you only need to return
if you restart the frame otherwise the driver will deadlock,

we do restart the frame - with the:

    /* may as well try anyway - I guess all bets are off now */
    out_le32(&awacs_txdma->control, ((RUN|WAKE) << 16) + (RUN|WAKE));

the difference from what you did is that I don't re-load the cmdptr register
- we are just going to see if the current state can be resumed.

It might lock up - but it's worth a try.

Nope it doesn't restart the frame, thats why we need to either reload it
and return or continue as if it played correctly.

I was wondering again today why we get the DEAD status in the powercomputing
machines everything was working fine until 2.2.9/10 (there were no changes
in dmasound at that point) so some other change is causing this i can't
imagine anything though :(

  Kostas


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

Nope it doesn't restart the frame, thats why we need to either reload it
and return or continue as if it played correctly.

I was wondering again today why we get the DEAD status in the powercomputing
machines everything was working fine until 2.2.9/10 (there were no changes
in dmasound at that point) so some other change is causing this i can't
imagine anything though :(

Can this be the time when we added proper support for IDE M/DMA mode ?

Previously, our driver could do DMA, but couldn't configure the disk DMA
mode, leaving it in whatever state the firmware/MacOS set it up. Around
2.2.x (early, I don't remember when exactly), we added some code to
configure the timings properly.

Ben.


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