On Tue, Sep 6, 2016 at 3:16 PM, Ran Shalit <ranshalit@xxxxxxxxx> wrote: > On Wed, Aug 24, 2016 at 9:58 AM, Peter Ujfalusi <peter.ujfalusi@xxxxxx> wrote: >> On 08/23/16 13:12, Ran Shalit wrote: >>>> The sDMA dmaengine driver was introduced with 3.6, the memcpy support is >>>> coming in at 4.2. >>>> In 3.4 you only have the legacy omap-dma support. This explains why the >>>> /sys/class/dma/ is empty for you. >>>> >>> >>> Peter, >>> Thank you very much. >>> >>> It seems that I can't upgrade the kernel at this point of development. >>> So, I will have to do it with legacy API (since I can't updared) using >>> omap-dma.c , memcpy transfer , 16-bits. >>> I think it is possible, Right ? >> >> Sure, if there is no dmaengine for sDMA, the legacy API is the only way to use >> sDMA. It is just a matter of how you configure the omap-dma, the API allows >> pretty much to use all features of sDMA. >> >>> I see there is also example (mcbsp.c) for using legacy in: >>> ftp://ftp.oregonstate.edu/.2/nslu2/sources/git/git.openmoko.org.git.kernel.git/arch/arm/plat-omap/mcbsp.c >> >> Hrm, this is more like 2.6.29-ish code... >> >>> As I understand, the transfer word length is set with >>> omap_set_dma_transfer_params(), used with OMAP_DMA_DATA_TYPE_S16 for >>> 16-bits with . >> >> McASP is using hw trigger, not sw trigger. It is not memcpy at all. Not sure >> if 2.6.29 had any memcpy users of sDMA. >> >>> Another last thing: >>> Do we need to confure dma channels in board file (I can't see any >>> reference to dma) ? >> >> This is only needed if the device have DMA request. In that case you want to >> have the hw request number as DMA resource on the device. But for memcpy you >> should not have hw request number as memcpy is sw triggered. >> > > Dear Peter, > > If I may please ask one more on dma issue, with legacy api: > > 1. How do we choose word length 16 bits, is it by using > OMAP_DMA_DATA_TYPE_S16 with: > omap_set_dma_transfer_params(tx->dma_ch, OMAP_DMA_DATA_TYPE_S16, ...) > > 2. I did not understand how to specify memoty-to-memory (sw trigger). > Is sw trigger same as burst mode ? > When should we use burst mode ? (I did not find documentation for > klegacy api, so I'm not sure, it also contain burst length which I am > not sure which value I should use in) > Do you think /drivers/media/video/omap/omap_vout_frfb.c can be > suited as example for memory-to-memory ? > > Regards, > Ran > I have found a very good working example by Kevin Hilman in https://github.com/khilman/omap-test-dmatest/blob/master/main.c I have made simple modifications for it to have 16-bit word (OMAP_DMA_DATA_TYPE_S16 instead OMAP_DMA_DATA_TYPE_S32, using buf_size/2 instead of buf_size/4, etc), which still works fine, when doing memory-to-memory. Now, I try to work with the device memory by using ioremap_nocache() instead of dma_alloc_coherent() as following: #if 1 dma_test[i].dest_buf = ioremap_nocache((0x00800000+0x00012000)*2, buf_size); #else dma_test[i].dest_buf = (unsigned long) dma_alloc_coherent(NULL, buf_size, (dma_addr_t *)&dma_test[i].dest_buf_phys, GFP_KERNEL | GFP_DMA); #endif But now I get exception in kernel: [ 18.231536] ------------[ cut here ]------------ [ 18.231567] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:117 l3_interrupt_handler+0x144/0x190() [ 18.231567] L3 custom error: MASTER:SDMA_Wr TARGET:GPMC [ 18.231567] Modules linked in: dma(O) fpga(O) btwilink bluetooth wl12xx wlcore mac80211 cfg80211 omapdrm_pvr(O) asix at24 wlcore_sdio [ 18.231628] [<c001cbe4>] (unwind_backtrace+0x0/0xfc) from [<c05c0af0>] (dump_stack+0x20/0x24) [ 18.231658] [<c05c0af0>] (dump_stack+0x20/0x24) from [<c00465a4>] (warn_slowpath_common+0x5c/0x74) [ 18.231689] [<c00465a4>] (warn_slowpath_common+0x5c/0x74) from [<c0046678>] (warn_slowpath_fmt+0x40/0x48) [ 18.231689] [<c0046678>] (warn_slowpath_fmt+0x40/0x48) from [<c003ab2c>] (l3_interrupt_handler+0x144/0x190) [ 18.231719] [<c003ab2c>] (l3_interrupt_handler+0x144/0x190) from [<c00c023c>] (handle_irq_event_percpu+0xb8/0x28c) [ 18.231750] [<c00c023c>] (handle_irq_event_percpu+0xb8/0x28c) from [<c00c045c>] (handle_irq_event+0x4c/0x6c) [ 18.231750] [<c00c045c>] (handle_irq_event+0x4c/0x6c) from [<c00c32dc>] (handle_fasteoi_irq+0xd8/0x144) [ 18.231781] [<c00c32dc>] (handle_fasteoi_irq+0xd8/0x144) from [<c00bfc28>] (generic_handle_irq+0x3c/0x50) [ 18.231781] [<c00bfc28>] (generic_handle_irq+0x3c/0x50) from [<c0015090>] (handle_IRQ+0x88/0xc8) [ 18.231811] [<c0015090>] (handle_IRQ+0x88/0xc8) from [<c00086d4>] (gic_handle_irq+0x54/0x74) [ 18.231842] [<c00086d4>] (gic_handle_irq+0x54/0x74) from [<c05c4a00>] (__irq_svc+0x40/0x70) [ 18.231842] Exception stack(0xeb6a9e88 to 0xeb6a9ed0) [ 18.231842] 9e80: c093836c 60070113 00000000 00000000 c093836c 60070113 [ 18.231872] 9ea0: 00000000 00000001 00000003 00000002 0000001c eb6a9edc eb6a9ee0 eb6a9ed0 [ 18.231872] 9ec0: c0074d7c c05c40b8 60070113 ffffffff [ 18.231903] [<c05c4a00>] (__irq_svc+0x40/0x70) from [<c05c40b8>] (_raw_spin_unlock_irqrestore+0x2c/0x54) [ 18.231903] [<c05c40b8>] (_raw_spin_unlock_irqrestore+0x2c/0x54) from [<c0074d7c>] (__wake_up+0x54/0x5c) [ 18.231933] [<c0074d7c>] (__wake_up+0x54/0x5c) from [<c009d6b0>] (sys_init_module+0x10cc/0x1174) [ 18.231964] [<c009d6b0>] (sys_init_module+0x10cc/0x1174) from [<c0013f00>] (ret_fast_syscall+0x0/0x30) [ 18.231964] ---[ end trace da227214a82491bb ]--- [ 18.231994] DMA transaction error with device 0 [ 18.231994] dma_callback(): lch=0x0, ch_status=0x0100, count=1/0 [ 23.350738] DMA copy failed at offset 0x0. Expected 0x00000000, got 0x00005678 Isn't it legal to work with the io mapped memory as done above ? Thank you, Ran >> >>> Thank you, >>> Ran >>> >>>>> >>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Ran >>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 2.Is there any example which shows how to use DMA (which shall call >>>>>>>>>>> the edma, and shall result in triggering a dma trsnaction in OMAP) ? >>>>>>>>>> >>>>>>>>>> git grep dmaengine_prep_dma_sg >>>>>>>>>> or >>>>>>>>>> git grep dmaengine_terminate_all >>>>>>>>>> >>>>>>>>>> will show you the drivers using dmaengine. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Péter >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Péter >>>>>> >>>>>> >>>>>> -- >>>>>> Péter >>>> >>>> >>>> -- >>>> Péter >> >> >> -- >> Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
