Subject: Re: Assabet UDA1341/DMA patch

From: Tak-Shing Chan <[email-masked]>
Date: Mon, 19 Jun 2000 20:43:27 +0800 (CST)

Hi Nicolas,

     The last patch is actually a wrong one (my fault), please
move PPAR |= PPAR_SPR down three lines (or use the following
patch instead).

Tak-Shing Chan

--- /usr/src/linux-2.4.0-test1-ac19-rmk1-np1/arch/arm/kernel/dma-sa1100.c.orig	Mon Jun 19 10:44:21 2000
+++ /usr/src/linux-2.4.0-test1-ac19-rmk1-np1/arch/arm/kernel/dma-sa1100.c	Mon Jun 19 17:33:07 2000
@@ -110,13 +110,13 @@
 	if( use_bufa ){
 		DMA->ClrDCSR = DCSR_DONEA|DCSR_STRTA;
 		DMA->DBSA = dma_ptr;
-		DMA->DBTA = size-1;
+		DMA->DBTA = size;
 		DMA->SetDCSR = DCSR_STRTA|DCSR_IE|DCSR_RUN;
 		DPRINTK(" with a\n");
 	}else{
 		DMA->ClrDCSR = DCSR_DONEB|DCSR_STRTB;
 		DMA->DBSB = dma_ptr;
-		DMA->DBTB = size-1;
+		DMA->DBTB = size;
 		DMA->SetDCSR = DCSR_STRTB|DCSR_IE|DCSR_RUN;
 		DPRINTK(" with b\n");
 	}

--- /usr/src/linux-2.4.0-test1-ac19-rmk1-np1/drivers/sound/sa1100-uda1341.c.orig	Mon Jun 19 10:44:21 2000
+++ /usr/src/linux-2.4.0-test1-ac19-rmk1-np1/drivers/sound/sa1100-uda1341.c	Mon Jun 19 20:34:06 2000
@@ -272,7 +272,8 @@
 #define AUDIO_CHANNELS_DEFAULT	2
 #define AUDIO_RATE_DEFAULT	44100
 #define AUDIO_NBFRAGS_DEFAULT	8
-#define AUDIO_FRAGSIZE_DEFAULT	8192
+#define AUDIO_FRAGSIZE_DEFAULT	4096
+#define AUDIO_DMA_OVERSHOOT	64

 /* 
@@ -546,7 +547,7 @@
 			output_stream.dma_spin = 0;
 		}
 		if( s->dma_spin ){
-			while( sa1100_start_dma(s->DMA, (void*)FLUSH_BASE_PHYS, MAX_DMA_SIZE) == 0 )
+			while( sa1100_start_dma(s->DMA, (void*)FLUSH_BASE_PHYS, MAX_DMA_SIZE-AUDIO_DMA_OVERSHOOT) == 0 )
 				s->dma_spin_ref++;
 		}
 		break;
@@ -556,7 +557,7 @@
 	 * Let's try to start DMA on the current buffer.  
 	 * If no DMA is available then we stop here.
 	 */
-	chunksize = (b->size < MAX_DMA_SIZE) ? b->size : MAX_DMA_SIZE;
+	chunksize = (b->size < MAX_DMA_SIZE-AUDIO_DMA_OVERSHOOT) ? b->size : MAX_DMA_SIZE-AUDIO_DMA_OVERSHOOT;
 	DPRINTK("DMA buf %d (%d) chnk %d\n", s->dma_head_idx, b->ref, chunksize);
 	if( sa1100_start_dma( s->DMA, b->ptr, chunksize ) != 0 ){
 		DPRINTK("DMA busy\n");
@@ -1091,11 +1092,11 @@
 static inline void audio_ssp_init( void )
 {
 	/* Setup the uarts */
-	PPAR |= PPC_TXD4;
 	GAFR |= (GPIO_SSP_TXD | GPIO_SSP_RXD | GPIO_SSP_SCLK | 
 		 GPIO_SSP_SFRM | GPIO_SSP_CLK);
 	GPDR |= (GPIO_SSP_TXD | GPIO_SSP_SCLK | GPIO_SSP_SFRM );
 	GPDR &= ~(GPIO_SSP_RXD | GPIO_SSP_CLK);
+	PPAR |= PPAR_SPR;
 	Ser4SSCR0 = SSCR0_SSE + SSCR0_DataSize(16) + SSCR0_TI;
 	Ser4SSCR1 = SSCR1_SClkIactL + SSCR1_SClk1P + SSCR1_ExtClk;

unsubscribe: body of `unsubscribe linux-arm-kernel' to [email-masked]

---

From: [email-masked]
Date: Fri, 23 Jun 2000 15:08:15 -0400

I've got it working without audio artifacts that I can attribute to the driver.

 I have however been noticing some occasional lags and unresponsiveness from my
Assabets with the current linux-2.4.0-test1-ac19-rmk1-np1 doing other
activities, and not just with the sound.  ie. I'll type to the shell with
nothing beyond minimal system running and it will take a while to echo the
characters and occasionally am getting a complaint from the serial driver about
an overrun that I can't explain.

I'd be curious to see your patch.  I'd also be curious to know how much flash
you have available for bootloader/kernel/boot disk in your Bitsy?

Erik

Jamey Hicks <[email-masked]> on 06/23/2000 11:06:05 AM

To:   "'Tak-Shing Chan'" <[email-masked]>
cc:   Nicolas Pitre <[email-masked]>, [email-masked]
      (bcc: Erik Bunce/USER/US/LHS)
Fax to:
Subject:  RE: Assabet UDA1341/DMA patch

What is the status of this driver?  Does anyone have it working without
periodic artifacts in the sound?

I sent Nico a patch that makes this work on the iPaq 3600 handheld (Bitsy).

-Jamey

> -----Original Message-----
> From: Tak-Shing Chan [mailto:[email-masked]]
> Sent: Tuesday, June 20, 2000 4:19 AM
> To: Tak-Shing Chan
> Cc: Nicolas Pitre; [email-masked]
> Subject: Re: Assabet UDA1341/DMA patch
>
>
> Hi Nicolas,
>
>      AUDIO_DMA_OVERSHOOT=2 and AUDIO_FRAGSIZE_DEFAULT=8190 works
> fine.  Another observation: odd fragsizes break things (the last
> 16-bit sample became 8-bit).  It looks like DMA overshoot is not
> a problem at all because 8190 is the biggest possible even number.
> Maybe renaming AUDIO_DMA_OVERSHOOT to AUDIO_EVEN_HACK is a better
> idea.  ;)
>
>      Results so far:
>      * Odd fragsizes with tca=size-1 : failed
>      * Even fragsizes with tca=size-1: failed
>      * Odd fragsizes with tca=size   : failed
>      * Even fragsizes with tca=size  : passed
>      * Valid fragsize range          : 4096-8190
>
> Tak-Shing Chan
>
> On Tue, 20 Jun 2000, Tak-Shing Chan wrote:
>
> > Nicolas,
> >
> >      I think that involves two things.  First, regarding the
> > meaning of DBTA--from repeated listening experiments (from 4096
> > to 8176) I'm positive that it's value and not value-1.  The
> > result of missing samples in digital recordings are just too
> > obvious...  [by the way 11.6.1.4 says TCA is in bytes.]
> >
> >      Second, isn't the extra datum you detected caused by DMA
> > overshoot (and the value is supposed to be fetched and ignored)?
> > My patch explicitly takes DMA overshoot into account.
> >
> >      It seems like it's safe to specify AUDIO_DMA_OVERSHOOT as 16
> > and AUDIO_FRAGSIZE_DEFAULT as 8176.  Any confirmations?  IMHO
> > 8176 is big enough for most purposes.  Meanwhile 64 and 4096 are
> > ``failsafe'' values but not optimal.
> >
> > Tak-Shing Chan
> >
> > On Mon, 19 Jun 2000, Nicolas Pitre wrote:
> >
> >> However you're limitting the DMA buffer to 4096 bytes
> which might be quite
> >> small, especially if the system is under heavy load.
> >>
> >> The SA1100 manual explictly says that the DMA count
> register is 13 bit
> >> wide for a maximal DMA size of 8192 bytes, which is highly
> adviseable for
> >> audio.  However 13 bits can represent a max value of
> 0x1fff i.e. 8191.
> >> Since most registers on the SA1100 are defined as reg =
> value - 1, I
> >> though it was the case for the DMA too, although it is not strictly
> >> mentionned for the DMA count reg.  What I've noticed
> though is that even
> >> if you specify 0 for the DMA count reg, you'll get at
> least one datum
> >> through the DMA engine which tend to confirm the -1 guess.
> >>
> >> Anybody can confirm this?
> >>
> >>
> >> Nicolas
> >>
> >
> >
> >

unsubscribe: body of `unsubscribe linux-arm-kernel' to
[email-masked]