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
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
