On 11/06/2015 12:30 AM, Caleb Crome wrote: > On Thu, Nov 5, 2015 at 3:28 PM, Roberto Fichera <kernel@xxxxxxxxxxxxx> wrote: >> >> On 11/06/2015 12:21 AM, Caleb Crome wrote: >>> On Thu, Nov 5, 2015 at 3:01 PM, Roberto Fichera <kernel@xxxxxxxxxxxxx> wrote: >>>> On 11/05/2015 11:49 PM, Caleb Crome wrote: >>>>> On Thu, Nov 5, 2015 at 2:40 PM, Roberto Fichera <kernel@xxxxxxxxxxxxx> wrote: >>>>>> On 11/05/2015 11:25 PM, Caleb Crome wrote: >>>>>>> On Thu, Nov 5, 2015 at 2:08 PM, Roberto Fichera <kernel@xxxxxxxxxxxxx> wrote: >>>>>>>> On 11/05/2015 10:34 PM, Caleb Crome wrote: >>>>>>>>> On Thu, Nov 5, 2015 at 3:48 AM, Roberto Fichera <kernel@xxxxxxxxxxxxx> wrote: >>>>>>>>>> On 11/05/2015 12:30 PM, Fabio Estevam wrote: >>>>>>>>>>> On Thu, Nov 5, 2015 at 8:03 AM, Roberto Fichera <kernel@xxxxxxxxxxxxx> wrote: >>>>>>>>>>> >>>>>>>>>>>> Following your suggestion, I've increased the buffer size to 2K and set the period to fifo_length - 2 (13), >>>>>>>>>>>> with that I'm now running substantially smooth except 3 EVTERR on RX DMA over 4 million of interrupts. >>>>>>>>>>>> >>>>>>>>>>>> Thanks Nicolin! I'm quite happy now! >>>>>>>>>>> That's good progress, Roberto. >>>>>>>>>>> >>>>>>>>>>> It would be nice if you and Caleb could post the patches to the mailing list. >>>>>>>>>>> >>>>>>>>> Yes, when I get something quite solid, I'd like to submit it all to >>>>>>>>> the list, and hope to get it into the kernel so nobody else has to go >>>>>>>>> through this pain again. >>>>>>>>> >>>>>>>>>> Indeed! Now the TDM is stable, I've also found the reason of the EVTERRs, which was related to some stale >>>>>>>>>> code I've used to enable and disable both RDMAE and TDMAE bits to try to reset the transfers. >>>>>>>>>> Once removed that code everything is looks ok now. >>>>>>>>>> >>>>>>>>>> Regarding patches, well, from my side there isn't nothing special compared to the original fsl_ssi.c code. >>>>>>>>>> I'm basically running against a very skinny fsl_ssi.c version, I've just setup a bit larger DMA buffer, from >>>>>>>>>> 16bytes to 2K, and now reduced the DMA period to 8 because I'm mostly comfortable with that size to simplify >>>>>>>>>> sampling exchange against DAHDI subsystem within my DMA callbacks. >>>>>>>>>> >>>>>>>>>> In a few words, my problem was related due to a DMA buffer too small. >>>>>>>>>> >>>>>>>>>> What eventually might be interesting to have is the INTRMASK and EVTERR DMA setting to trigger DMA >>>>>>>>>> related errors, but I guess this need to be discussed elsewhere. >>>>>>>>> I have implemented roberto's patch on the 4.2 kernel, and I get a huge >>>>>>>>> number of EVTERR interrupts. Something like 7200/second at 16kHz >>>>>>>>> sample rate. But strangely, the audio seems to be correct. >>>>>>>> I've notice that clearing the EVTERR bit seems restarting the given SDMA. >>>>>>>> >>>>>>>>> My patch is slightly different in that it just enables EVTERR for all >>>>>>>>> channels, not just for the SSI. Might as well see if there are any >>>>>>>>> other problems. >>>>>>>> Oh yes! This will overload the SDMA isr. >>>>>>> It didn't seem to. There didn't seem to be any other DMA happening in >>>>>>> my system, definitely none that made the EVTRR trigger. However, I >>>>>>> changed it back to the way you had it. No differences, still got a >>>>>>> TON of EVTERRs. >>>>>> This might be related to SDMA request when another is pending. >>>>>> >>>>>>>> How bigger is your audio buffer? >>>>>>>> In your case I guess you will need something like 16KHz * 16 channels * >>>>>>>> 2 bytes (16bits) = 512K minimum. >>>>>>>> I would try to start from 1MB or maybe more. >>>>>>> That's 2 seconds of audio! We definitely need less buffering than >>>>>>> that. We pretty much need a latency of 100ms, worst case, or 1600 >>>>>>> frames, or 51,200 bytes. >>>>>> I haven't checked in detail how the DAI buffering is working, but likely >>>>>> the samples are passed not in buffer size chunks but instead with less >>>>>> granularity. Having a large buffer gives more chance to the SSI to not >>>>>> overlap DMA requests, hence no more EVTERRs. >>>>>> >>>>>> I would give it a try. >>>>>>> I did change the max buffer size to 1MB though, but I'm not sure how >>>>>>> much is actually being used. >>>>>> I guess it's 64K, look for IMX_SSI_DMABUF_SIZE. >>>>>> >>>>>> >>>>> Exactly, I changed that to 1024*1024, but still I don't get zero >>>>> EVTERRs, even when I set my periods long and number of periods high. >>>> They decreased? >>>> >>> the big win was going to dual fifo, but they're still there at >>> something like 17/second. >> What about your current fifo_depth? Are you using the full length? >> > Do you mean in the SSI watermark, or some other FIFO depth? Sorry! SSI watermark. > I'm currently operating at watermark = 6 & DMA maxburst of 12 (dual fifo mode). > > That's the best performing so far. Have you already played to see if increasing the watermark to 8 and maxburst to 15 decrease the EVTERRs? I haven't check how the SDMA script works in dual fifo mode, but I think that in this operating mode, maxburst might be also 16. > -Caleb > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@xxxxxxxxxxxxxxxx > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
