On Thu, Nov 5, 2015 at 3:46 PM, Roberto Fichera <kernel@xxxxxxxxxxxxx> wrote:
> 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?
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@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
