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

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

[Iain Sandoe]

Wed, Mar 28, 2001, Kostas Gewrgiou wrote:
> On Wed, 28 Mar 2001, Iain Sandoe wrote:
>> > 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.

ahhh.  I was wondering if you'd tried this.

Unfortunately you can't just re-load the frame with an adjusted count - you
need to bump the data start address as well - which is the reason for
introducing the emergency cmd buffer.

OK... well, I'll try and post the emergency dbdma cmd version soon.

> 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 :(

changes in PCI IDE drivers or bus arbitration control?

(the bug has the appearance of a bus lock-out preventing dma transfer in
time).

Some interesting figures (if I've got this right) - IIRC the minimum PCI dma
transfer is 64 bytes - which corresponds to 16 sample frames (stereo, 2
bytes per ch).

At 44k1 (fastest) this would occur every 363us (approx.).  That's a long
time for the PCI bus to be locked up for (depending on how far ahead the
controller tries to fetch the next block of data).

anybody able to check?

I don't think it's IRQ-blocking because the residue count in DEAD frames is
non-zero (if the frame had finished but IRQs were blocked too long - I think
the residue would have to be zero)...

Iain.

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

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

[Benjamin Herrenschmidt]

>At 44k1 (fastest) this would occur every 363us (approx.).  That's a long
>time for the PCI bus to be locked up for (depending on how far ahead the
>controller tries to fetch the next block of data).
>
>anybody able to check?
>
>I don't think it's IRQ-blocking because the residue count in DEAD frames is
>non-zero (if the frame had finished but IRQs were blocked too long - I think
>the residue would have to be zero)...

I've heard about possible bugs in some DBDMA implementations that could cause
the DBDMA to fail is the bus was locked up for more than a few clock cycles.
the IDE DMA may cause such lockups.

Another issue (that may be related to your bmac issue, Takashi). It
appears that
one some older Apple PCI bridges, there could occasionally be some cache
coherency
issues (especially with transfers not aligned on a cache line boundary).
I think
Paul experienced some problems with the DEC ethernet controller of his old
PowerBook 3400 for example. It may be useful to flush the dbdma command buffer
after modifying and invalidate it before it gets modified by the controller...

Ben.


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

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

[Iain Sandoe]

> Paul experienced some problems with the DEC ethernet controller of his old
> PowerBook 3400 for example. It may be useful to flush the dbdma command buffer
> after modifying and invalidate it before it gets modified by the controller...

OK, that's not too difficult - we get a chance to do this before the cmd
block is queued on TX... and after we read the data on RX.

(although we don't *seem* to be seeing a coherency problem here - the
xfer_status is {AFAICT} getting updated properly for dmasound).

I'll figure it into the next lot of changes.

Iain.

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

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

[Iain Sandoe]

 Wed, Mar 28, 2001, Kostas Gewrgiou wrote:
> On Wed, 28 Mar 2001, Iain Sandoe wrote:

>> 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/

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

[Kostas Gewrgiou]

On Wed, 28 Mar 2001, Iain Sandoe wrote:

>
> > 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/

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

[Benjamin Herrenschmidt]

>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/

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

[Iain Sandoe]

Hi,

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.

ciao,
Iain.

=====

static void
pmac_awacs_tx_intr(int irq, void *devid, struct pt_regs *regs)
{
 int i = write_sq.front;
 int stat;
 volatile struct dbdma_cmd *cp;

 while (write_sq.active > 0) {
  cp = &awacs_tx_cmds[i];
  stat = ld_le16(&cp->xfer_status);
  if ( ((stat & ACTIVE) == 0) ) {
   if (stat & DEAD) {
    int count = 300 ; /* > 2 samples at slowest AWACS rate */
    out_le32(&awacs_txdma->control, (RUN) << 16);
    st_le16(&cp->xfer_status, 0); /* reset the xfer status */

    /* this is a bit nasty - we could hold IRQs off for up to
       300 us
    */
    while ( (in_le32(&awacs_txdma->status) & RUN) && count--)
     udelay(1) ;
/* debug */
if (count <= 0)
 printk("dmasound_pmac: tx IRQ: timed out trying to restart DEAD dma\n") ;

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

    return; /* we want to be as quick out of here as possible */
   } else {
    break; /* this frame is still going */
   }
  }
  --write_sq.count;
  --write_sq.active;
  if (++i >= write_sq.max_count)
   i = 0;
 }

 if (i != write_sq.front)
  WAKE_UP(write_sq.action_queue);
 write_sq.front = i;

 PMacPlay();

 if (!write_sq.active)
  WAKE_UP(write_sq.sync_queue);
}

=========

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

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

[Kostas Gewrgiou]

On Wed, 28 Mar 2001, Iain Sandoe wrote:

>
> Hi,
>
> 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, here is what i
do at the moment, its not perfect but its the best we can do i think without
the emergency dbdma_cmd.

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


  Kostas

.....
#define DEADFRAME_RESTART 1
                if ( ((stat & ACTIVE) == 0) ) {
                        if( stat & DEAD ) {
                                int req_count, res_count;

                                req_count = ld_le16(&cp->req_count);
                                res_count = ld_le16(&cp->res_count);

                                /*
                                printk("dmasound: status = 0x%x\n",stat);
                                printk("dmasound: req_count = %d\n",req_count);
                                printk("dmasound: res_count = %d\n",res_count);
                                */

                                out_le32(&awacs_txdma->control, (RUN|PAUSE|FLUSH|WAKE|DEAD) << 16);
                                st_le16(&cp->xfer_status, 0);

#if(DEADFRAME_RESTART)
                                st_le16(&cp->req_count, res_count);
                                out_le32(&awacs_txdma->cmdptr, virt_to_bus(cp));
#endif

                                out_le32(&awacs_txdma->control, ((RUN|WAKE) << 16) + (RUN|WAKE));

#if(DEADFRAME_RESTART)
                                return;
#endif
                        } else {
........


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