| Message ID | CAG5mAdz=TKSmXBOqKfSj0FYfk3c6syBa87OazyGRRF0NU4snXA@mail.gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On Wed, Oct 28, 2015 at 03:06:40PM -0700, Caleb Crome wrote: > > 2) Set the watermarks for both TX and RX to 8 while using burst sizes > > of 6. It'd be nicer to provisionally set these numbers using hard > > code than your current change depending on fifo_depth as it might > > be an odd value. > Ah, this is fascinating you say this. fifo_depth is definitely odd, > it's 15 as set in imx6qdl.dtsi: > fsl,fifo-depth = <15>; > But the DMA maxburst is made even later in the code... And odd number for burst size may course a similar problem like channel swapping in two-channel cases because the number of data FIFO is 2 -- an even number. But it seems not to be related to your problem here. > Setting the watermark to 8 and maxburst to 8 dramatically reduces the > channel slip rate, in fact, i didn't see a slip for more than 30 > minutes of playing. That's a new record for sure. But, eventually, > there was an underrun, and the channels slipped. > > Setting watermark to 8 and maxburst to 6 still had some slips, > seemingly more than 8 & 8. > > I feel like a monkey randomly typing at my keyboard though. I don't > know why maxburst=8 worked better. I get the > feeling that I was just lucky. That's actually another possible root cause -- performance issue. burst=8 will have less bus transaction number than the case when burst=6. As you have quite a lot channels comparing to normal 2 channels, you need to feed the FIFO more frequently. If SDMA does not feed the data before the input FIFO gets underrun, a channel swapping might happen: in your case, channel slip. > There does seem to be a correlation between user space reported > underruns and this channel slip, although they definitely are not 1:1 Reported by user space? Are you saying that's an ALSA underrun in the user space, not a hardware underrun reported by the IRQ in the driver? They are quite different. ALSA underrun comes from the DMA buffer gets underrun while the other one results from FIFO feeding efficiency. For ALSA underrun, enlarging the playback period size and period number will ease the problem: period number = buffer size / period size; An ALSA underrun may not be companied by a hardware underrun but they may co-exist. > ratio: underruns happen without slips and slips happen without > underruns. The latter is very disturbing because user space has no > idea something is wrong. > @@ -1260,8 +1260,8 @@ static int fsl_ssi_imx_probe(struct platform_device *pdev, > * We have burstsize be "fifo_depth - 2" to match the SSI > * watermark setting in fsl_ssi_startup(). > */ > - ssi_private->dma_params_tx.maxburst = ssi_private->fifo_depth - 2; > - ssi_private->dma_params_rx.maxburst = ssi_private->fifo_depth - 2; > + ssi_private->dma_params_tx.maxburst = 8; > + ssi_private->dma_params_rx.maxburst = 8; I am actually thinking about setting a watermark to a larger number. I forgot how the SDMA script handles this number. But if this burst size means the overall data count per transaction, it might indicate that each FIFO only gets half of the burst size due to dual FIFOs. Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space left, the largest safe burst size could be 14 (7 * 2) actually. Yes. That's kind of fine tunning the parameters. And for your case, you may try a larger number as the SSI is simultaneously consuming a large amount of data even though it sounds risky. But it's worth trying since you are using SSI which only has tight FIFOs not like ESAI has 128 depth. Nicolin
On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote: > On Wed, Oct 28, 2015 at 03:06:40PM -0700, Caleb Crome wrote: > >> > 2) Set the watermarks for both TX and RX to 8 while using burst sizes >> > of 6. It'd be nicer to provisionally set these numbers using hard >> > code than your current change depending on fifo_depth as it might >> > be an odd value. > >> Ah, this is fascinating you say this. fifo_depth is definitely odd, >> it's 15 as set in imx6qdl.dtsi: > >> fsl,fifo-depth = <15>; >> But the DMA maxburst is made even later in the code... > > And odd number for burst size may course a similar problem like > channel swapping in two-channel cases because the number of data > FIFO is 2 -- an even number. But it seems not to be related to > your problem here. > >> Setting the watermark to 8 and maxburst to 8 dramatically reduces the >> channel slip rate, in fact, i didn't see a slip for more than 30 >> minutes of playing. That's a new record for sure. But, eventually, >> there was an underrun, and the channels slipped. >> >> Setting watermark to 8 and maxburst to 6 still had some slips, >> seemingly more than 8 & 8. >> >> I feel like a monkey randomly typing at my keyboard though. I don't >> know why maxburst=8 worked better. I get the >> feeling that I was just lucky. > > That's actually another possible root cause -- performance issue. > burst=8 will have less bus transaction number than the case when > burst=6. As you have quite a lot channels comparing to normal 2 > channels, you need to feed the FIFO more frequently. If SDMA does > not feed the data before the input FIFO gets underrun, a channel > swapping might happen: in your case, channel slip. > >> There does seem to be a correlation between user space reported >> underruns and this channel slip, although they definitely are not 1:1 > > Reported by user space? Are you saying that's an ALSA underrun in > the user space, not a hardware underrun reported by the IRQ in the > driver? They are quite different. ALSA underrun comes from the DMA > buffer gets underrun while the other one results from FIFO feeding > efficiency. For ALSA underrun, enlarging the playback period size > and period number will ease the problem: > > period number = buffer size / period size; > > An ALSA underrun may not be companied by a hardware underrun but > they may co-exist. Sometimes they happen at the same time. So, I run aplay, and all is fine. Then the user space app will underrun, and then I look at the scope, and the channels have slipped. So somehow the start/restart after the underrun is not always perfect I guess. Is there any mechanism for the DMA fifo underruns to be reported back to user space? There certainly should be, because the consequences are catastrophic, yet the user space app goes on as if everything is just great. Much, much worse than the underrun that is reported (i.e. a skip in audio is bad but sometimes tolerable. A channel slip is permanent and absolutely intolerable). > >> ratio: underruns happen without slips and slips happen without >> underruns. The latter is very disturbing because user space has no >> idea something is wrong. > >> @@ -1260,8 +1260,8 @@ static int fsl_ssi_imx_probe(struct platform_device *pdev, >> * We have burstsize be "fifo_depth - 2" to match the SSI >> * watermark setting in fsl_ssi_startup(). >> */ >> - ssi_private->dma_params_tx.maxburst = ssi_private->fifo_depth - 2; >> - ssi_private->dma_params_rx.maxburst = ssi_private->fifo_depth - 2; >> + ssi_private->dma_params_tx.maxburst = 8; >> + ssi_private->dma_params_rx.maxburst = 8; > > I am actually thinking about setting a watermark to a larger number. > I forgot how the SDMA script handles this number. But if this burst > size means the overall data count per transaction, it might indicate > that each FIFO only gets half of the burst size due to dual FIFOs. > > Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space > left, the largest safe burst size could be 14 (7 * 2) actually. Oh, does this depend on the data size? I'm using 16-bit data, so I guess the bursts are measured in 2 byte units? Does this mean that the burst size should be dynamically adjusted depending on word size (I guess done in hw_params)? > > Yes. That's kind of fine tunning the parameters. And for your case, > you may try a larger number as the SSI is simultaneously consuming > a large amount of data even though it sounds risky. But it's worth > trying since you are using SSI which only has tight FIFOs not like > ESAI has 128 depth. > > Nicolin
On Thu, Oct 29, 2015 at 6:44 AM, Caleb Crome <caleb@crome.org> wrote: > On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote: >> >> I am actually thinking about setting a watermark to a larger number. >> I forgot how the SDMA script handles this number. But if this burst >> size means the overall data count per transaction, it might indicate >> that each FIFO only gets half of the burst size due to dual FIFOs. >> >> Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space >> left, the largest safe burst size could be 14 (7 * 2) actually. > > Oh, does this depend on the data size? I'm using 16-bit data, so I > guess the bursts are measured in 2 byte units? Does this mean that > the burst size should be dynamically adjusted depending on word size > (I guess done in hw_params)? > >> Nicolin Okay, so wm=8 and maxburst=14 definitely does not work at all,. wm=8, maxburst=8 works okay, but still not perfect. I just discovered some new information: With wm=8 and maxburst=8 (which is my best setting so far), I just captured a problem at the very start of playing a file, and restarted enough times to capture it starting wrong: Instead of the playback starting with (hex numbers: my ramp file has first nibble as channel, second nibble as frame) frame 0: 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0, f0 frame 1: 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1, f1 It started with: frame 0: 00, 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0 frame 1: f0, 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1 So, the transfer started wrong right out of the gate -- with an extra sample inserted at the beginning. Again, my setup is: 1) use scope to capture the TDM bus. Trigger on first data change 2) aplay myramp.wav 3) If okay, ctrl-c and goto 2. 4) The capture below shows everything off by 1 sample. The capture is here: https://drive.google.com/open?id=0B-KUa9Yf1o7iOXFtWXk2ZXdoUXc This test definitely reveals that there is a startup issue. Now for the $64,000 question: what to do with this knowledge? I'm quite unfamiliar with how the DMA works at all. I'll start poking around the DMA I guess. Thanks, -Caleb
On 10/29/2015 03:55 PM, Caleb Crome wrote: > On Thu, Oct 29, 2015 at 6:44 AM, Caleb Crome <caleb@crome.org> wrote: >> On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote: >>> I am actually thinking about setting a watermark to a larger number. >>> I forgot how the SDMA script handles this number. But if this burst >>> size means the overall data count per transaction, it might indicate >>> that each FIFO only gets half of the burst size due to dual FIFOs. >>> >>> Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space >>> left, the largest safe burst size could be 14 (7 * 2) actually. >> Oh, does this depend on the data size? I'm using 16-bit data, so I >> guess the bursts are measured in 2 byte units? Does this mean that >> the burst size should be dynamically adjusted depending on word size >> (I guess done in hw_params)? >> >>> Nicolin > Okay, so wm=8 and maxburst=14 definitely does not work at all,. wm=8, > maxburst=8 works okay, but still not perfect. > > I just discovered some new information: > > With wm=8 and maxburst=8 (which is my best setting so far), I just > captured a problem at the very start of playing a file, and restarted > enough times to capture it starting wrong: > > Instead of the playback starting with > > (hex numbers: my ramp file has first nibble as channel, second nibble as frame) > > frame 0: 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0, f0 > frame 1: 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1, f1 > > It started with: > > frame 0: 00, 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0 > frame 1: f0, 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1 > > So, the transfer started wrong right out of the gate -- with an extra > sample inserted at the beginning. Again, my setup is: > 1) use scope to capture the TDM bus. Trigger on first data change > 2) aplay myramp.wav > 3) If okay, ctrl-c and goto 2. > 4) The capture below shows everything off by 1 sample. > > The capture is here: > https://drive.google.com/open?id=0B-KUa9Yf1o7iOXFtWXk2ZXdoUXc > > This test definitely reveals that there is a startup issue. Now for > the $64,000 question: what to do with this knowledge? I'm quite > unfamiliar with how the DMA works at all. I'm my case for example, I'm using a iMX6SX SoC, I've changed fsl_ssi.c to start the SSI clock generated internally by setting both RDMAE and TDMAE just once I'm pretty sure that everything has been setup (DMA and callback). Note that I'm not using alsa because, my target is to integrate SSI in TDM network mode with my DAHDI driver for VoIP app. Back to the DMA question, in your case shouldn't be really a problem since all DMA stuff is handled by the linux audio framework. Regarding my SSI problem, I was able to keep the DMA working for few second once before it get stopped and never retriggered. Currently I've 2 DMA channel one for TX and another for RX I've changed my DTS and update my fsl_ssi to handle new clocks, I guess only the CLK_SPBA has improved my situation. I've also tried to enable both RIE and TIE to service the ISR, with and without SSI DMA support, but this end with a full system freeze. The ISR was never changed in my fsl_ssi.c. ssi1: ssi@02028000 { compatible = "fsl,imx6sx-ssi", "fsl,imx21-ssi"; reg = <0x02028000 0x4000>; interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX6SX_CLK_SSI1_IPG>, <&clks IMX6SX_CLK_SSI1>, --->>> <&clks IMX6SX_CLK_SPBA>, <&clks IMX6SX_CLK_SDMA>; clock-names = "ipg", "baud", "dma", "ahb"; dmas = <&sdma 37 1 0>, <&sdma 38 1 0>; dma-names = "rx", "tx"; Another thing I'm looking is the sdma events (37 and 38) which are reported by the reference manual to 37 -> SSI1 Receive 0 DMA request 38 -> SSI1 Transmit 0 DMA request along that there are also 35 -> SSI1 Receive 1 DMA request 36 -> SSI1 Transmit 1 DMA request I don't know actually how the two events types will behaves from the SDMA point of view. I'm also considering to make plain new audio driver to at least try to use something which is supposed to work fine with SSI. > > I'll start poking around the DMA I guess. I guess it's a SSI startup problem. > > Thanks, > -Caleb > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >
On Thu, Oct 29, 2015 at 8:37 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: > On 10/29/2015 03:55 PM, Caleb Crome wrote: >> On Thu, Oct 29, 2015 at 6:44 AM, Caleb Crome <caleb@crome.org> wrote: >>> On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote: >>>> I am actually thinking about setting a watermark to a larger number. >>>> I forgot how the SDMA script handles this number. But if this burst >>>> size means the overall data count per transaction, it might indicate >>>> that each FIFO only gets half of the burst size due to dual FIFOs. >>>> >>>> Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space >>>> left, the largest safe burst size could be 14 (7 * 2) actually. >>> Oh, does this depend on the data size? I'm using 16-bit data, so I >>> guess the bursts are measured in 2 byte units? Does this mean that >>> the burst size should be dynamically adjusted depending on word size >>> (I guess done in hw_params)? >>> >>>> Nicolin >> Okay, so wm=8 and maxburst=14 definitely does not work at all,. wm=8, >> maxburst=8 works okay, but still not perfect. >> >> I just discovered some new information: >> >> With wm=8 and maxburst=8 (which is my best setting so far), I just >> captured a problem at the very start of playing a file, and restarted >> enough times to capture it starting wrong: >> >> Instead of the playback starting with >> >> (hex numbers: my ramp file has first nibble as channel, second nibble as frame) >> >> frame 0: 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0, f0 >> frame 1: 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1, f1 >> >> It started with: >> >> frame 0: 00, 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0 >> frame 1: f0, 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1 >> >> So, the transfer started wrong right out of the gate -- with an extra >> sample inserted at the beginning. Again, my setup is: >> 1) use scope to capture the TDM bus. Trigger on first data change >> 2) aplay myramp.wav >> 3) If okay, ctrl-c and goto 2. >> 4) The capture below shows everything off by 1 sample. >> >> The capture is here: >> https://drive.google.com/open?id=0B-KUa9Yf1o7iOXFtWXk2ZXdoUXc >> >> This test definitely reveals that there is a startup issue. Now for >> the $64,000 question: what to do with this knowledge? I'm quite >> unfamiliar with how the DMA works at all. > > I'm my case for example, I'm using a iMX6SX SoC, I've changed fsl_ssi.c to start the SSI > clock generated internally by setting both RDMAE and TDMAE just once I'm pretty sure > that everything has been setup (DMA and callback). Note that I'm not using alsa because, > my target is to integrate SSI in TDM network mode with my DAHDI driver for VoIP app. > > Back to the DMA question, in your case shouldn't be really a problem since all DMA > stuff is handled by the linux audio framework. > > Regarding my SSI problem, I was able to keep the DMA working for few second once before > it get stopped and never retriggered. Currently I've 2 DMA channel one for TX and another for RX > I've changed my DTS and update my fsl_ssi to handle new clocks, I guess only the CLK_SPBA > has improved my situation. I've also tried to enable both RIE and TIE to service the ISR, with > and without SSI DMA support, but this end with a full system freeze. I got this system freeze too when enabling RIE and TIE because the interrupts TFE1IE, TFE0IE, TDE1IE, TDE0IE are *enabled* at reset. (Check ref manual 61.9.5). which I suspect was a livelock kind of situation where the ISR is just called infinitely often. After disabling those, then the system worked okay. Check out the previous patch I sent on the issue yesterday or the day before. > > Another thing I'm looking is the sdma events (37 and 38) which are reported by the reference > manual to > > 37 -> SSI1 Receive 0 DMA request > 38 -> SSI1 Transmit 0 DMA request > > along that there are also > > 35 -> SSI1 Receive 1 DMA request > 36 -> SSI1 Transmit 1 DMA request > > I don't know actually how the two events types will behaves from the SDMA point of view. The 35 and 36 are for Dual fifo mode only, and no current system (with fsl_ssi.c anyway) uses dual fifo mode. How do I know? Because the it's definitely broken in the fsl_ssi.c. I was just about to report that bug. hint: fsl_ssi.c: if (ssi_private->use_dma && !ret && dmas[3] == IMX_DMATYPE_SSI_DUAL) { should read if (ssi_private->use_dma && !ret && dmas[4] == IMX_DMATYPE_SSI_DUAL) { > > I'm also considering to make plain new audio driver to at least try to use something which > is supposed to work fine with SSI. Yeah, maybe that's the easiest way to go just to get operational. Start with just the bare minimum ssi driver so you know all the registers are locked into place the way you like. -caleb
On 10/29/2015 04:54 PM, Caleb Crome wrote: > On Thu, Oct 29, 2015 at 8:37 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: >> On 10/29/2015 03:55 PM, Caleb Crome wrote: >>> On Thu, Oct 29, 2015 at 6:44 AM, Caleb Crome <caleb@crome.org> wrote: >>>> On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote: >>>>> I am actually thinking about setting a watermark to a larger number. >>>>> I forgot how the SDMA script handles this number. But if this burst >>>>> size means the overall data count per transaction, it might indicate >>>>> that each FIFO only gets half of the burst size due to dual FIFOs. >>>>> >>>>> Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space >>>>> left, the largest safe burst size could be 14 (7 * 2) actually. >>>> Oh, does this depend on the data size? I'm using 16-bit data, so I >>>> guess the bursts are measured in 2 byte units? Does this mean that >>>> the burst size should be dynamically adjusted depending on word size >>>> (I guess done in hw_params)? >>>> >>>>> Nicolin >>> Okay, so wm=8 and maxburst=14 definitely does not work at all,. wm=8, >>> maxburst=8 works okay, but still not perfect. >>> >>> I just discovered some new information: >>> >>> With wm=8 and maxburst=8 (which is my best setting so far), I just >>> captured a problem at the very start of playing a file, and restarted >>> enough times to capture it starting wrong: >>> >>> Instead of the playback starting with >>> >>> (hex numbers: my ramp file has first nibble as channel, second nibble as frame) >>> >>> frame 0: 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0, f0 >>> frame 1: 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1, f1 >>> >>> It started with: >>> >>> frame 0: 00, 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0 >>> frame 1: f0, 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1 >>> >>> So, the transfer started wrong right out of the gate -- with an extra >>> sample inserted at the beginning. Again, my setup is: >>> 1) use scope to capture the TDM bus. Trigger on first data change >>> 2) aplay myramp.wav >>> 3) If okay, ctrl-c and goto 2. >>> 4) The capture below shows everything off by 1 sample. >>> >>> The capture is here: >>> https://drive.google.com/open?id=0B-KUa9Yf1o7iOXFtWXk2ZXdoUXc >>> >>> This test definitely reveals that there is a startup issue. Now for >>> the $64,000 question: what to do with this knowledge? I'm quite >>> unfamiliar with how the DMA works at all. >> I'm my case for example, I'm using a iMX6SX SoC, I've changed fsl_ssi.c to start the SSI >> clock generated internally by setting both RDMAE and TDMAE just once I'm pretty sure >> that everything has been setup (DMA and callback). Note that I'm not using alsa because, >> my target is to integrate SSI in TDM network mode with my DAHDI driver for VoIP app. >> >> Back to the DMA question, in your case shouldn't be really a problem since all DMA >> stuff is handled by the linux audio framework. >> >> Regarding my SSI problem, I was able to keep the DMA working for few second once before >> it get stopped and never retriggered. Currently I've 2 DMA channel one for TX and another for RX >> I've changed my DTS and update my fsl_ssi to handle new clocks, I guess only the CLK_SPBA >> has improved my situation. I've also tried to enable both RIE and TIE to service the ISR, with >> and without SSI DMA support, but this end with a full system freeze. > I got this system freeze too when enabling RIE and TIE because the > interrupts TFE1IE, TFE0IE, TDE1IE, TDE0IE are *enabled* at reset. > (Check ref manual 61.9.5). which I suspect was a livelock kind of > situation where the ISR is just called infinitely often. After > disabling those, then the system worked okay. Check out the previous > patch I sent on the issue yesterday or the day before. Ooohh!!! Forgot to check this!!! I'm now going to mask them!!! > >> Another thing I'm looking is the sdma events (37 and 38) which are reported by the reference >> manual to >> >> 37 -> SSI1 Receive 0 DMA request >> 38 -> SSI1 Transmit 0 DMA request >> >> along that there are also >> >> 35 -> SSI1 Receive 1 DMA request >> 36 -> SSI1 Transmit 1 DMA request >> >> I don't know actually how the two events types will behaves from the SDMA point of view. > The 35 and 36 are for Dual fifo mode only, and no current system (with > fsl_ssi.c anyway) uses dual fifo mode. How do I know? Because the > it's definitely broken in the fsl_ssi.c. I was just about to report > that bug. Ah! Thanks! The reference manual is really clear to explain it :-D ! > hint: fsl_ssi.c: if (ssi_private->use_dma && !ret && dmas[3] == > IMX_DMATYPE_SSI_DUAL) { > should read if (ssi_private->use_dma && !ret && dmas[4] == > IMX_DMATYPE_SSI_DUAL) { Yep! I know such piece of code. > >> I'm also considering to make plain new audio driver to at least try to use something which >> is supposed to work fine with SSI. > Yeah, maybe that's the easiest way to go just to get operational. > Start with just the bare minimum ssi driver so you know all the > registers are locked into place the way you like. > > -caleb > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >
On Thu, Oct 29, 2015 at 9:02 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: > On 10/29/2015 04:54 PM, Caleb Crome wrote: >> On Thu, Oct 29, 2015 at 8:37 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>> On 10/29/2015 03:55 PM, Caleb Crome wrote: >>> I don't know actually how the two events types will behaves from the SDMA point of view. >> The 35 and 36 are for Dual fifo mode only, and no current system (with >> fsl_ssi.c anyway) uses dual fifo mode. How do I know? Because the >> it's definitely broken in the fsl_ssi.c. I was just about to report >> that bug. > > Ah! Thanks! The reference manual is really clear to explain it :-D ! > >> hint: fsl_ssi.c: if (ssi_private->use_dma && !ret && dmas[2] == >> IMX_DMATYPE_SSI_DUAL) { >> should read if (ssi_private->use_dma && !ret && dmas[3] == >> IMX_DMATYPE_SSI_DUAL) { Oops, nevermid. I was looking at that wrong. It's correct as is. -Caleb
On 10/29/2015 05:02 PM, Roberto Fichera wrote: > On 10/29/2015 04:54 PM, Caleb Crome wrote: >> On Thu, Oct 29, 2015 at 8:37 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>> On 10/29/2015 03:55 PM, Caleb Crome wrote: >>>> On Thu, Oct 29, 2015 at 6:44 AM, Caleb Crome <caleb@crome.org> wrote: >>>>> On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote: >>>>>> I am actually thinking about setting a watermark to a larger number. >>>>>> I forgot how the SDMA script handles this number. But if this burst >>>>>> size means the overall data count per transaction, it might indicate >>>>>> that each FIFO only gets half of the burst size due to dual FIFOs. >>>>>> >>>>>> Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space >>>>>> left, the largest safe burst size could be 14 (7 * 2) actually. >>>>> Oh, does this depend on the data size? I'm using 16-bit data, so I >>>>> guess the bursts are measured in 2 byte units? Does this mean that >>>>> the burst size should be dynamically adjusted depending on word size >>>>> (I guess done in hw_params)? >>>>> >>>>>> Nicolin >>>> Okay, so wm=8 and maxburst=14 definitely does not work at all,. wm=8, >>>> maxburst=8 works okay, but still not perfect. >>>> >>>> I just discovered some new information: >>>> >>>> With wm=8 and maxburst=8 (which is my best setting so far), I just >>>> captured a problem at the very start of playing a file, and restarted >>>> enough times to capture it starting wrong: >>>> >>>> Instead of the playback starting with >>>> >>>> (hex numbers: my ramp file has first nibble as channel, second nibble as frame) >>>> >>>> frame 0: 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0, f0 >>>> frame 1: 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1, f1 >>>> >>>> It started with: >>>> >>>> frame 0: 00, 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0 >>>> frame 1: f0, 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1 >>>> >>>> So, the transfer started wrong right out of the gate -- with an extra >>>> sample inserted at the beginning. Again, my setup is: >>>> 1) use scope to capture the TDM bus. Trigger on first data change >>>> 2) aplay myramp.wav >>>> 3) If okay, ctrl-c and goto 2. >>>> 4) The capture below shows everything off by 1 sample. >>>> >>>> The capture is here: >>>> https://drive.google.com/open?id=0B-KUa9Yf1o7iOXFtWXk2ZXdoUXc >>>> >>>> This test definitely reveals that there is a startup issue. Now for >>>> the $64,000 question: what to do with this knowledge? I'm quite >>>> unfamiliar with how the DMA works at all. >>> I'm my case for example, I'm using a iMX6SX SoC, I've changed fsl_ssi.c to start the SSI >>> clock generated internally by setting both RDMAE and TDMAE just once I'm pretty sure >>> that everything has been setup (DMA and callback). Note that I'm not using alsa because, >>> my target is to integrate SSI in TDM network mode with my DAHDI driver for VoIP app. >>> >>> Back to the DMA question, in your case shouldn't be really a problem since all DMA >>> stuff is handled by the linux audio framework. >>> >>> Regarding my SSI problem, I was able to keep the DMA working for few second once before >>> it get stopped and never retriggered. Currently I've 2 DMA channel one for TX and another for RX >>> I've changed my DTS and update my fsl_ssi to handle new clocks, I guess only the CLK_SPBA >>> has improved my situation. I've also tried to enable both RIE and TIE to service the ISR, with >>> and without SSI DMA support, but this end with a full system freeze. >> I got this system freeze too when enabling RIE and TIE because the >> interrupts TFE1IE, TFE0IE, TDE1IE, TDE0IE are *enabled* at reset. >> (Check ref manual 61.9.5). which I suspect was a livelock kind of >> situation where the ISR is just called infinitely often. After >> disabling those, then the system worked okay. Check out the previous >> patch I sent on the issue yesterday or the day before. > Ooohh!!! Forgot to check this!!! I'm now going to mask them!!! Doesn't work for me! Still freeze the system! SIER=0x01d005f4 > >>> Another thing I'm looking is the sdma events (37 and 38) which are reported by the reference >>> manual to >>> >>> 37 -> SSI1 Receive 0 DMA request >>> 38 -> SSI1 Transmit 0 DMA request >>> >>> along that there are also >>> >>> 35 -> SSI1 Receive 1 DMA request >>> 36 -> SSI1 Transmit 1 DMA request >>> >>> I don't know actually how the two events types will behaves from the SDMA point of view. >> The 35 and 36 are for Dual fifo mode only, and no current system (with >> fsl_ssi.c anyway) uses dual fifo mode. How do I know? Because the >> it's definitely broken in the fsl_ssi.c. I was just about to report >> that bug. > Ah! Thanks! The reference manual is really clear to explain it :-D ! > >> hint: fsl_ssi.c: if (ssi_private->use_dma && !ret && dmas[3] == >> IMX_DMATYPE_SSI_DUAL) { >> should read if (ssi_private->use_dma && !ret && dmas[4] == >> IMX_DMATYPE_SSI_DUAL) { > Yep! I know such piece of code. > >>> I'm also considering to make plain new audio driver to at least try to use something which >>> is supposed to work fine with SSI. >> Yeah, maybe that's the easiest way to go just to get operational. >> Start with just the bare minimum ssi driver so you know all the >> registers are locked into place the way you like. >> >> -caleb >> _______________________________________________ >> Alsa-devel mailing list >> Alsa-devel@alsa-project.org >> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >> > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >
On Thu, Oct 29, 2015 at 9:34 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: > On 10/29/2015 05:02 PM, Roberto Fichera wrote: >> On 10/29/2015 04:54 PM, Caleb Crome wrote: >>> On Thu, Oct 29, 2015 at 8:37 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>> On 10/29/2015 03:55 PM, Caleb Crome wrote: >>>>> On Thu, Oct 29, 2015 at 6:44 AM, Caleb Crome <caleb@crome.org> wrote: >>>>>> On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote: >>>>>>> I am actually thinking about setting a watermark to a larger number. >>>>>>> I forgot how the SDMA script handles this number. But if this burst >>>>>>> size means the overall data count per transaction, it might indicate >>>>>>> that each FIFO only gets half of the burst size due to dual FIFOs. >>>>>>> >>>>>>> Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space >>>>>>> left, the largest safe burst size could be 14 (7 * 2) actually. >>>>>> Oh, does this depend on the data size? I'm using 16-bit data, so I >>>>>> guess the bursts are measured in 2 byte units? Does this mean that >>>>>> the burst size should be dynamically adjusted depending on word size >>>>>> (I guess done in hw_params)? >>>>>> >>>>>>> Nicolin >>>>> Okay, so wm=8 and maxburst=14 definitely does not work at all,. wm=8, >>>>> maxburst=8 works okay, but still not perfect. >>>>> >>>>> I just discovered some new information: >>>>> >>>>> With wm=8 and maxburst=8 (which is my best setting so far), I just >>>>> captured a problem at the very start of playing a file, and restarted >>>>> enough times to capture it starting wrong: >>>>> >>>>> Instead of the playback starting with >>>>> >>>>> (hex numbers: my ramp file has first nibble as channel, second nibble as frame) >>>>> >>>>> frame 0: 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0, f0 >>>>> frame 1: 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1, f1 >>>>> >>>>> It started with: >>>>> >>>>> frame 0: 00, 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0 >>>>> frame 1: f0, 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1 >>>>> >>>>> So, the transfer started wrong right out of the gate -- with an extra >>>>> sample inserted at the beginning. Again, my setup is: >>>>> 1) use scope to capture the TDM bus. Trigger on first data change >>>>> 2) aplay myramp.wav >>>>> 3) If okay, ctrl-c and goto 2. >>>>> 4) The capture below shows everything off by 1 sample. >>>>> >>>>> The capture is here: >>>>> https://drive.google.com/open?id=0B-KUa9Yf1o7iOXFtWXk2ZXdoUXc >>>>> >>>>> This test definitely reveals that there is a startup issue. Now for >>>>> the $64,000 question: what to do with this knowledge? I'm quite >>>>> unfamiliar with how the DMA works at all. >>>> I'm my case for example, I'm using a iMX6SX SoC, I've changed fsl_ssi.c to start the SSI >>>> clock generated internally by setting both RDMAE and TDMAE just once I'm pretty sure >>>> that everything has been setup (DMA and callback). Note that I'm not using alsa because, >>>> my target is to integrate SSI in TDM network mode with my DAHDI driver for VoIP app. >>>> >>>> Back to the DMA question, in your case shouldn't be really a problem since all DMA >>>> stuff is handled by the linux audio framework. >>>> >>>> Regarding my SSI problem, I was able to keep the DMA working for few second once before >>>> it get stopped and never retriggered. Currently I've 2 DMA channel one for TX and another for RX >>>> I've changed my DTS and update my fsl_ssi to handle new clocks, I guess only the CLK_SPBA >>>> has improved my situation. I've also tried to enable both RIE and TIE to service the ISR, with >>>> and without SSI DMA support, but this end with a full system freeze. >>> I got this system freeze too when enabling RIE and TIE because the >>> interrupts TFE1IE, TFE0IE, TDE1IE, TDE0IE are *enabled* at reset. >>> (Check ref manual 61.9.5). which I suspect was a livelock kind of >>> situation where the ISR is just called infinitely often. After >>> disabling those, then the system worked okay. Check out the previous >>> patch I sent on the issue yesterday or the day before. >> Ooohh!!! Forgot to check this!!! I'm now going to mask them!!! > > Doesn't work for me! Still freeze the system! SIER=0x01d005f4 You still have many per-frame interrupts enabled, which is still too many enabled. for example, you have RLSIE, TLSIE, RFSIE, TFSIE, etc. These all generate one interrupt per frame, and not necessarily at the same time, so you could be having 4 or more interrupts per frame. Be sure they're all zero except for the DMA enable and the specific ones you actually want enabled. -C
On 10/29/2015 05:39 PM, Caleb Crome wrote: > On Thu, Oct 29, 2015 at 9:34 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: >> On 10/29/2015 05:02 PM, Roberto Fichera wrote: >>> On 10/29/2015 04:54 PM, Caleb Crome wrote: >>>> On Thu, Oct 29, 2015 at 8:37 AM, Roberto Fichera <kernel@tekno-soft.it> wrote: >>>>> On 10/29/2015 03:55 PM, Caleb Crome wrote: >>>>>> On Thu, Oct 29, 2015 at 6:44 AM, Caleb Crome <caleb@crome.org> wrote: >>>>>>> On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote: >>>>>>>> I am actually thinking about setting a watermark to a larger number. >>>>>>>> I forgot how the SDMA script handles this number. But if this burst >>>>>>>> size means the overall data count per transaction, it might indicate >>>>>>>> that each FIFO only gets half of the burst size due to dual FIFOs. >>>>>>>> >>>>>>>> Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space >>>>>>>> left, the largest safe burst size could be 14 (7 * 2) actually. >>>>>>> Oh, does this depend on the data size? I'm using 16-bit data, so I >>>>>>> guess the bursts are measured in 2 byte units? Does this mean that >>>>>>> the burst size should be dynamically adjusted depending on word size >>>>>>> (I guess done in hw_params)? >>>>>>> >>>>>>>> Nicolin >>>>>> Okay, so wm=8 and maxburst=14 definitely does not work at all,. wm=8, >>>>>> maxburst=8 works okay, but still not perfect. >>>>>> >>>>>> I just discovered some new information: >>>>>> >>>>>> With wm=8 and maxburst=8 (which is my best setting so far), I just >>>>>> captured a problem at the very start of playing a file, and restarted >>>>>> enough times to capture it starting wrong: >>>>>> >>>>>> Instead of the playback starting with >>>>>> >>>>>> (hex numbers: my ramp file has first nibble as channel, second nibble as frame) >>>>>> >>>>>> frame 0: 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0, f0 >>>>>> frame 1: 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1, f1 >>>>>> >>>>>> It started with: >>>>>> >>>>>> frame 0: 00, 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0 >>>>>> frame 1: f0, 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1 >>>>>> >>>>>> So, the transfer started wrong right out of the gate -- with an extra >>>>>> sample inserted at the beginning. Again, my setup is: >>>>>> 1) use scope to capture the TDM bus. Trigger on first data change >>>>>> 2) aplay myramp.wav >>>>>> 3) If okay, ctrl-c and goto 2. >>>>>> 4) The capture below shows everything off by 1 sample. >>>>>> >>>>>> The capture is here: >>>>>> https://drive.google.com/open?id=0B-KUa9Yf1o7iOXFtWXk2ZXdoUXc >>>>>> >>>>>> This test definitely reveals that there is a startup issue. Now for >>>>>> the $64,000 question: what to do with this knowledge? I'm quite >>>>>> unfamiliar with how the DMA works at all. >>>>> I'm my case for example, I'm using a iMX6SX SoC, I've changed fsl_ssi.c to start the SSI >>>>> clock generated internally by setting both RDMAE and TDMAE just once I'm pretty sure >>>>> that everything has been setup (DMA and callback). Note that I'm not using alsa because, >>>>> my target is to integrate SSI in TDM network mode with my DAHDI driver for VoIP app. >>>>> >>>>> Back to the DMA question, in your case shouldn't be really a problem since all DMA >>>>> stuff is handled by the linux audio framework. >>>>> >>>>> Regarding my SSI problem, I was able to keep the DMA working for few second once before >>>>> it get stopped and never retriggered. Currently I've 2 DMA channel one for TX and another for RX >>>>> I've changed my DTS and update my fsl_ssi to handle new clocks, I guess only the CLK_SPBA >>>>> has improved my situation. I've also tried to enable both RIE and TIE to service the ISR, with >>>>> and without SSI DMA support, but this end with a full system freeze. >>>> I got this system freeze too when enabling RIE and TIE because the >>>> interrupts TFE1IE, TFE0IE, TDE1IE, TDE0IE are *enabled* at reset. >>>> (Check ref manual 61.9.5). which I suspect was a livelock kind of >>>> situation where the ISR is just called infinitely often. After >>>> disabling those, then the system worked okay. Check out the previous >>>> patch I sent on the issue yesterday or the day before. >>> Ooohh!!! Forgot to check this!!! I'm now going to mask them!!! >> Doesn't work for me! Still freeze the system! SIER=0x01d005f4 I thought the same but setting only RFF0, TFE0, RDMAE and TDMAE along the RIE and TIE still free the system. > You still have many per-frame interrupts enabled, which is still too > many enabled. for example, you have RLSIE, TLSIE, RFSIE, TFSIE, etc. > These all generate one interrupt per frame, and not necessarily at the > same time, so you could be having 4 or more interrupts per frame. Be > sure they're all zero except for the DMA enable and the specific ones > you actually want enabled. Yep! But I still think that the CPU should be able to handle all them. > > -C > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >
On Thu, Oct 29, 2015 at 06:44:12AM -0700, Caleb Crome wrote: > > Reported by user space? Are you saying that's an ALSA underrun in > > the user space, not a hardware underrun reported by the IRQ in the > > driver? They are quite different. ALSA underrun comes from the DMA > > buffer gets underrun while the other one results from FIFO feeding > > efficiency. For ALSA underrun, enlarging the playback period size > > and period number will ease the problem: > Sometimes they happen at the same time. So, I run aplay, and all is The 'they' is indicating ALSA underrun + hardware underrun or ALSA underrun + channel slip? It's not quite logical for a channel slip resulting from an ALSA underrun as it should restart by calling the trigger() functions in DAI drivers IIRC. > fine. Then the user space app will underrun, and then I look at the > scope, and the channels have slipped. So somehow the start/restart > after the underrun is not always perfect I guess. > Is there any mechanism for the DMA fifo underruns to be reported back > to user space? There certainly should be, because the consequences No. The release from Freescale official tree has a reset procedure applied to ESAI underrun but not SSI but I guess you may want to refer to that. > are catastrophic, yet the user space app goes on as if everything is > just great. Much, much worse than the underrun that is reported (i.e. > a skip in audio is bad but sometimes tolerable. A channel slip is > permanent and absolutely intolerable).
On Thu, Oct 29, 2015 at 04:37:35PM +0100, Roberto Fichera wrote: > Regarding my SSI problem, I was able to keep the DMA working for few second once before > it get stopped and never retriggered. Currently I've 2 DMA channel one for TX and another for rx DMA only stops when getting terminate_all() executed or FIFO doesn't reach the watermark so that no newer DMA request would be issued. > I've changed my DTS and update my fsl_ssi to handle new clocks, I guess only the CLK_SPBA > has improved my situation. I've also tried to enable both RIE and TIE to service the ISR, with Guessing? It'd weird that SPBA would ease the issue here as I was told by the IC team that SSI and SAI in SoloX don't require SPBA clock IIRC. > and without SSI DMA support, but this end with a full system freeze. The ISR was never changed > in my fsl_ssi.c. You mentioned that clock status from the Codec chip shows the bit clock stops but now it's related to DMA? I think you should first figure out where the problem locates as Caleb's problem is different from yours. As I mentioned, you may need to confirm that if the bit clock generation is stopped. DMA surely won't work when the bit clock ends as SSI may no longer consume the data FIFO so the watermark would never be reached again. Nicolin
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index 73778c2..b834f77 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c @@ -943,7 +943,7 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev, * size. */ if (ssi_private->use_dma) - wm = ssi_private->fifo_depth - 2; + wm = 8; else wm = ssi_private->fifo_depth; @@ -1260,8 +1260,8 @@ static int fsl_ssi_imx_probe(struct platform_device *pdev, * We have burstsize be "fifo_depth - 2" to match the SSI * watermark setting in fsl_ssi_startup(). */ - ssi_private->dma_params_tx.maxburst = ssi_private->fifo_depth - 2; - ssi_private->dma_params_rx.maxburst = ssi_private->fifo_depth - 2; + ssi_private->dma_params_tx.maxburst = 8; + ssi_private->dma_params_rx.maxburst = 8; ssi_private->dma_params_tx.addr = ssi_private->ssi_phys + CCSR_SSI_STX0; ssi_private->dma_params_rx.addr = ssi_private->ssi_phys + CCSR_SSI_SRX0;