On Thu, Jun 10, 2011 at 4:27 PM, Jassi Brar wrote:
Though if then everything works fine with system and internal DMA, maybe it is better to assign platform_name string at runtime from some module parameter, and leaving the default to normal system DMA ?
OK, I will leaving the default to system DMA,
But I had found some problem and want to share. Like this patch, If different platform driver is used for each channel, 1st channel is overwritten by platform driver of 2nd channel. Have you ever experienced before like this problem?
IIRC, I successfully tested using system DMA with primary and iDMA with secondary channel. Only the sec chan would keep playing when the system went to suspend. Though tt was long time ago and I don't remember which Samsung kernel version.
Your test condition is little different with my test condition. You are using wrapper architecture. But I used each driver architecture. Like in this patch, I assigned like below
{ /* Primary DAI i/f */ .name = "WM8994 AIF1", .stream_name = "Pri_Dai", .cpu_dai_name = "samsung-i2s.0", .codec_dai_name = "wm8994-aif1", .platform_name = "samsung-audio", .codec_name = "wm8994-codec", .init = smdk_wm8994_init_paiftx, .ops = &smdk_ops, }, { /* Sec_Fifo Playback i/f */ .name = "Sec_FIFO TX", .stream_name = "Sec_Dai", .cpu_dai_name = "samsung-i2s.4", .codec_dai_name = "wm8994-aif1", .platform_name = "samsung-idma", .codec_name = "wm8994-codec", .ops = &smdk_ops, },
Primary is used by system dma, Secondary is used by idma,
I try to use secondary by aplay, It can work fine. ============================================================================ ============== [root@samsung ~]# /mars/bin/aplay -Dplughw:0,1,0 /mars/share/sounds/alsa/Front_Center.wav Entered idma_open Playing WAVE '/mars/share/sounds/alsa/Front_Center.wav' [I2S] Initialize sec_fifo idma [I2S] Done hw params Entered idma_hw_params idma_setcallbk:125 dma_period=2000 DmaAddr=@2020000 Total=96000bytes PrdSz=8192 #Prds=11 dma_area=0xd0840000 Entered idma_mmap Entered idma_prepare : Signed 16 bit Little Endian, Rate 48000 Hz, Mono Entered idma_trigger Entered idma_pointer, regs=d0822000 Pointer 2020004 Snip................. Entered idma_pointer, regs=d0822000 Pointer 202e00c Entered idma_pointer, regs=d0822000 Pointer 203000c Entered idma_pointer, regs=d0822000 Pointer 203200c Entered idma_pointer, regs=d0822000 Pointer 203400c Entered idma_pointer, regs=d0822000 Pointer 203600c Entered idma_trigger Entered idma_hw_free Entered idma_hw_free Entered idma_close, prtd = cedb8bc0 [root@Samsung ~]# ============================================================================ ============== There is no problem and sound is good,
But If I try to use primary i/f, It can't work properly. ============================================================================ ============== [root@samsung ~]# /mars/bin/aplay -Dplughw:0,0,0 /mars/share/sounds/alsa/Front_Center.wav Entered dma_open Playing WAVE '/mars/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono [I2S] Done hw params Entered dma_hw_params params cf82e6b0, client cf82e6b0, channel 16 Entered idma_mmap Entered dma_prepare Entered dma_enqueue dma_enqueue: loaded 0, limit 12 dma_loaded: 0 dma_loaded: 1 dma_loaded: 2 dma_loaded: 3 dma_loaded: 4 dma_loaded: 5 dma_loaded: 6 dma_loaded: 7 dma_loaded: 8 dma_loaded: 9 dma_loaded: 10 dma_loaded: 11 Entered dma_trigger Entered idma_pointer, regs=d0822000 Pointer 2020000 Entered audio_buffdone
Snip....................
Pointer 2020000 Entered audio_buffdone Entered idma_pointer, regs=d0822000 Pointer 2020000 Entered dma_trigger Entered audio_buffdone Entered dma_prepare Entered audio_buffdone Entered audio_buffdone Entered dma_enqueue dma_enqueue: loaded 0, limit 12 dma_loaded: 0 dma_loaded: 1 dma_loaded: 2 dma_loaded: 3 dma_loaded: 4 dma_loaded: 5 dma_loaded: 6 dma_loaded: 7 dma_loaded: 8 dma_loaded: 9 dma_loaded: 10 dma_loaded: 11 underrun!!! (at least 0.072 ms long) Entered dma_trigger Entered idma_pointer, regs=d0822000 Pointer 2020000 Entered audio_buffdone Entered idma_pointer, regs=d0822000 Pointer 2020000 Snip................ Entered audio_buffdone Entered idma_pointer, regs=d0822000 Pointer 2020000 Entered dma_trigger Entered audio_buffdone Entered dma_prepare Entered audio_buffdone Entered audio_buffdone Entered audio_buffdone Entered audio_buffdone Entered dma_enqueue dma_enqueue: loaded 0, limit 12 dma_loaded: 0 dma_loaded: 1 dma_loaded: 2 dma_loaded: 3 dma_loaded: 4 dma_loaded: 5 dma_loaded: 6 dma_loaded: 7 dma_loaded: 8 dma_loaded: 9 dma_loaded: 10 dma_loaded: 11 Entered dma_trigger underrun!!! (at least 0.030 ms long) Entered audio_buffdone Entered idma_pointer, regs=d0822000 Pointer 2020000 Entered audio_buffdone Entered idma_pointer, regs=d0822000 Pointer 2020000 Entered audio_buffdone Snip ............ Entered audio_buffdone Entered idma_pointer, regs=d0822000 Pointer 2020000 Entered dma_trigger Entered audio_buffdone Entered dma_hw_free Entered audio_buffdone Entered audio_buffdone Entered audio_buffdone Entered audio_buffdone Entered audio_buffdone Entered dma_hw_free Entered dma_close ============================================================================ ==== As you see above debugging log, Although system dma is assigned, instead using dma api, idma api is used. This is not a dma & idma driver's bug. This is platform driver handling bugs. There is no machine driver using different platform driver in the ASoC. So I guess that It is never confirmed before. I want to share this problem. and I want to fix this problem. So I want to get your opinion. Please check the above debug log and give your advice.
Thanks, SB Kim