On Thu, Sep 8, 2016 at 2:40 PM, Peter Ujfalusi <peter.ujfalusi@xxxxxx> wrote: > On 09/06/16 19:48, Ran Shalit wrote: >> I have found a very good working example by Kevin Hilman in >> https://github.com/khilman/omap-test-dmatest/blob/master/main.c > > yeah, this is doing memcpy. > >> 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); > > What does the '*2' tries to achieve here? And why '(0x00800000+0x00012000)' > and not '0x00812000' ? > I assume that this is the base address of the area you want to write to, is it > valid to write buf_size bytes after this base address? > What you have set for dest_buf_phys? The DMA needs physical address. > > Have you changed the buf_size to fit your needs? > Right! After updating dest_buf_phys everything works fine. (Thanks again to Kevin Hilman for the clean example) Now, I plan to change the example from dma_alloc_coherent to dma_map_single. And for this would like to ask one last thing on this issue please: When using dma_map_single , should we do for >each transmit< the following sequence : send dma buffer: ================= 1. dma_map_single 2. omap_request_dma 3. omap_set_dma_transfer_params 4. omap_set_dma_dest_params 5. omap_start_dma and on receiving dma buffer: ============ 1. omap_free_dma 2. dma_unmap_single As you can see, the above sequence is different than the dmatest (Kevin) example , in which omap_request_dma&dma_alloc_coherent are done only one time in initialization - instead of repeating them in each transmit as written above): Is the above sequence for dma_map_single would be correct ? Regards, Ran >> #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 ? > > > -- > 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
