| Message ID | CAG5mAdz+RDM8r1o+Q5WHhQM134Lp7Dxn78+ixX1D_u7G=WqE8w@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 11/05/2015 10:34 PM, Caleb Crome wrote: > On Thu, Nov 5, 2015 at 3:48 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: >> On 11/05/2015 12:30 PM, Fabio Estevam wrote: >>> On Thu, Nov 5, 2015 at 8:03 AM, Roberto Fichera <kernel@tekno-soft.it> 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. 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. > > And it puts the stats file at > /sys/kernel/debug/20ec000.sdma/stats > > When I aplay a file for 10 seconds I get ~366 EVTERR interrupts. > When I arecord for 10 seconds, I get 1 EVTERR interrupt > When I run my application for 10 seconds, which does full duplex, I > get 72703 EVTERR interrupts, but the data integrity checks out okay. > > Interstingly, when I enable dual fifo, it goes from about 7200 > EVTERR's/sec to about 18 EVTERRs/sec. Much better, but still a long > way from working perfectly. > Cyclic DMA is particular scatter-gater DMA list dedicated for repetitive tasks looping over the same buffer, so audio. The associated callback is triggered every period (fifo_depth-2) but the job will last only when the buffer is filled in the request length. All this "tasks" will be managed by SDMA ISR. You can follow the SG_LOOP flag if you want understand more. > When I get a 'hang' from my application (no more portaudio callbacks), > I'm actually getting repeated calls to sdma_prep_dma_cyclic, though I > don't know how that call gets triggered. But once that starts > happening, no more audio data gets through. If I remember correctly portaudio has a thread that controls your callback that receive/play all samples, but I don't remember if the callback is responsible to stop recording or playing in case of error. I've to check this in my last app.
On Thu, Nov 5, 2015 at 2:08 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: > On 11/05/2015 10:34 PM, Caleb Crome wrote: >> On Thu, Nov 5, 2015 at 3:48 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>> On 11/05/2015 12:30 PM, Fabio Estevam wrote: >>>> On Thu, Nov 5, 2015 at 8:03 AM, Roberto Fichera <kernel@tekno-soft.it> 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. > 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 did change the max buffer size to 1MB though, but I'm not sure how much is actually being used. > >> >> And it puts the stats file at >> /sys/kernel/debug/20ec000.sdma/stats >> >> When I aplay a file for 10 seconds I get ~366 EVTERR interrupts. >> When I arecord for 10 seconds, I get 1 EVTERR interrupt >> When I run my application for 10 seconds, which does full duplex, I >> get 72703 EVTERR interrupts, but the data integrity checks out okay. >> >> Interstingly, when I enable dual fifo, it goes from about 7200 >> EVTERR's/sec to about 18 EVTERRs/sec. Much better, but still a long >> way from working perfectly. >> > > Cyclic DMA is particular scatter-gater DMA list dedicated for repetitive > tasks looping over the same buffer, so audio. > The associated callback is triggered every period (fifo_depth-2) but the > job will last only when the buffer is > filled in the request length. All this "tasks" will be managed by SDMA > ISR. You can follow the SG_LOOP flag if you > want understand more. I don't want to understand more. I just want it to work :-) > >> When I get a 'hang' from my application (no more portaudio callbacks), >> I'm actually getting repeated calls to sdma_prep_dma_cyclic, though I >> don't know how that call gets triggered. But once that starts >> happening, no more audio data gets through. > > If I remember correctly portaudio has a thread that controls your > callback that receive/play all samples, but I don't remember if the > callback is responsible to stop recording or playing in case of error. > I've to check this in my last app. > Yeah, it does normally restart by itself.
On 11/05/2015 11:25 PM, Caleb Crome wrote: > On Thu, Nov 5, 2015 at 2:08 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >> On 11/05/2015 10:34 PM, Caleb Crome wrote: >>> On Thu, Nov 5, 2015 at 3:48 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>> On 11/05/2015 12:30 PM, Fabio Estevam wrote: >>>>> On Thu, Nov 5, 2015 at 8:03 AM, Roberto Fichera <kernel@tekno-soft.it> 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.
On Thu, Nov 5, 2015 at 2:40 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: > On 11/05/2015 11:25 PM, Caleb Crome wrote: >> On Thu, Nov 5, 2015 at 2:08 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>> On 11/05/2015 10:34 PM, Caleb Crome wrote: >>>> On Thu, Nov 5, 2015 at 3:48 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>>> On 11/05/2015 12:30 PM, Fabio Estevam wrote: >>>>>> On Thu, Nov 5, 2015 at 8:03 AM, Roberto Fichera <kernel@tekno-soft.it> 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.
On 11/05/2015 11:49 PM, Caleb Crome wrote: > On Thu, Nov 5, 2015 at 2:40 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >> On 11/05/2015 11:25 PM, Caleb Crome wrote: >>> On Thu, Nov 5, 2015 at 2:08 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>> On 11/05/2015 10:34 PM, Caleb Crome wrote: >>>>> On Thu, Nov 5, 2015 at 3:48 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>>>> On 11/05/2015 12:30 PM, Fabio Estevam wrote: >>>>>>> On Thu, Nov 5, 2015 at 8:03 AM, Roberto Fichera <kernel@tekno-soft.it> 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?
On Thu, Nov 5, 2015 at 3:01 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: > > > On 11/05/2015 11:49 PM, Caleb Crome wrote: >> On Thu, Nov 5, 2015 at 2:40 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>> On 11/05/2015 11:25 PM, Caleb Crome wrote: >>>> On Thu, Nov 5, 2015 at 2:08 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>>> On 11/05/2015 10:34 PM, Caleb Crome wrote: >>>>>> On Thu, Nov 5, 2015 at 3:48 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>>>>> On 11/05/2015 12:30 PM, Fabio Estevam wrote: >>>>>>>> On Thu, Nov 5, 2015 at 8:03 AM, Roberto Fichera <kernel@tekno-soft.it> 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. -Caleb
On 11/06/2015 12:21 AM, Caleb Crome wrote: > On Thu, Nov 5, 2015 at 3:01 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >> >> On 11/05/2015 11:49 PM, Caleb Crome wrote: >>> On Thu, Nov 5, 2015 at 2:40 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>> On 11/05/2015 11:25 PM, Caleb Crome wrote: >>>>> On Thu, Nov 5, 2015 at 2:08 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>>>> On 11/05/2015 10:34 PM, Caleb Crome wrote: >>>>>>> On Thu, Nov 5, 2015 at 3:48 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>>>>>> On 11/05/2015 12:30 PM, Fabio Estevam wrote: >>>>>>>>> On Thu, Nov 5, 2015 at 8:03 AM, Roberto Fichera <kernel@tekno-soft.it> 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?
On Thu, Nov 5, 2015 at 3:28 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: > > > On 11/06/2015 12:21 AM, Caleb Crome wrote: >> On Thu, Nov 5, 2015 at 3:01 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>> >>> On 11/05/2015 11:49 PM, Caleb Crome wrote: >>>> On Thu, Nov 5, 2015 at 2:40 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>>> On 11/05/2015 11:25 PM, Caleb Crome wrote: >>>>>> On Thu, Nov 5, 2015 at 2:08 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>>>>> On 11/05/2015 10:34 PM, Caleb Crome wrote: >>>>>>>> On Thu, Nov 5, 2015 at 3:48 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>>>>>>> On 11/05/2015 12:30 PM, Fabio Estevam wrote: >>>>>>>>>> On Thu, Nov 5, 2015 at 8:03 AM, Roberto Fichera <kernel@tekno-soft.it> 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? I'm currently operating at watermark = 6 & DMA maxburst of 12 (dual fifo mode). That's the best performing so far. -Caleb
On 11/06/2015 12:30 AM, Caleb Crome wrote: > On Thu, Nov 5, 2015 at 3:28 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >> >> On 11/06/2015 12:21 AM, Caleb Crome wrote: >>> On Thu, Nov 5, 2015 at 3:01 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>> On 11/05/2015 11:49 PM, Caleb Crome wrote: >>>>> On Thu, Nov 5, 2015 at 2:40 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>>>> On 11/05/2015 11:25 PM, Caleb Crome wrote: >>>>>>> On Thu, Nov 5, 2015 at 2:08 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>>>>>> On 11/05/2015 10:34 PM, Caleb Crome wrote: >>>>>>>>> On Thu, Nov 5, 2015 at 3:48 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>>>>>>>> On 11/05/2015 12:30 PM, Fabio Estevam wrote: >>>>>>>>>>> On Thu, Nov 5, 2015 at 8:03 AM, Roberto Fichera <kernel@tekno-soft.it> 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@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Thu, Nov 5, 2015 at 3:46 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: > On 11/06/2015 12:30 AM, Caleb Crome wrote: >> On Thu, Nov 5, 2015 at 3:28 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>> >>> On 11/06/2015 12:21 AM, Caleb Crome wrote: >>>> On Thu, Nov 5, 2015 at 3:01 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>>> On 11/05/2015 11:49 PM, Caleb Crome wrote: >>>>>> On Thu, Nov 5, 2015 at 2:40 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>>>>> On 11/05/2015 11:25 PM, Caleb Crome wrote: >>>>>>>> On Thu, Nov 5, 2015 at 2:08 PM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>>>>>>> On 11/05/2015 10:34 PM, Caleb Crome wrote: >>>>>>>>>> On Thu, Nov 5, 2015 at 3:48 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>>>>>>>>> On 11/05/2015 12:30 PM, Fabio Estevam wrote: >>>>>>>>>>>> On Thu, Nov 5, 2015 at 8:03 AM, Roberto Fichera <kernel@tekno-soft.it> 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? 16kHz, wm=8, maxburst = 15: total data integrity failure. data coming out the port is not in order. Also, get EVTERRs on ch 1 and ch 2. 48kHz, wm=8, maxburst = 16: 100 EVTERRs/sec, but data is right. 16kHz, wm=8, maxburst = 16: 0 EVTERRs/sec but data on SSI is wrong. 48kHz, wm=7, maxburst = 14: total system lockup. (might be infinite printk's or something, but it's dead). Interestingly, even with I'm getting many EVTERRs, I'm not getting SSI FIFO under/overruns. How is that possible? Will try more tomorrow... -caleb > 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@alsa-project.org >> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index 9d375bc..a3a2317 100644 --- a/drivers/dma/imx-sdma.c +++ b/drivers/dma/imx-sdma.c @@ -38,6 +38,8 @@ #include <linux/of_address.h> #include <linux/of_device.h> #include <linux/of_dma.h> +#include <linux/debugfs.h> +#include <linux/seq_file.h> #include <asm/irq.h> #include <linux/platform_data/dma-imx-sdma.h> @@ -50,6 +52,8 @@ /* SDMA registers */ #define SDMA_H_C0PTR 0x000 +#define SDMACORE_EVENTS 0x005 +#define SDMACORE_EVENTS2 0x01f #define SDMA_H_INTR 0x004 #define SDMA_H_STATSTOP 0x008 #define SDMA_H_START 0x00c @@ -385,6 +389,9 @@ struct sdma_engine { const struct sdma_driver_data *drvdata; u32 spba_start_addr; u32 spba_end_addr; + u32 evterrchannel[MAX_DMA_CHANNELS]; + struct dentry *dbg_dir; + struct dentry *dbg_stats; }; static struct sdma_driver_data sdma_imx31 = { @@ -562,7 +569,19 @@ static int sdma_config_ownership(struct sdma_channel *sdmac, static void sdma_enable_channel(struct sdma_engine *sdma, int channel) { + struct sdma_channel *sdmac = &sdma->channel[channel]; + u32 msk; + writel(BIT(channel), sdma->regs + SDMA_H_START); + /* + * enable EVTERR interrupts on this channel + */ + if ((sdmac->peripheral_type == IMX_DMATYPE_SSI_SP) || + (sdmac->peripheral_type == IMX_DMATYPE_SSI_DUAL)) { + msk = readl(sdma->regs + SDMA_H_INTRMSK); + writel(msk | BIT(channel), sdma->regs + SDMA_H_INTRMSK); + printk(KERN_INFO "%s: enabling EVTERR for channel %d\n", __func__, channel); + } }