On 09/10/16 11:47, Ran Shalit wrote: > 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 You don't need to request/free the dma every time. Keep the dma channel as long as the driver is loaded. As for the memory: it depends on your use case, but if you map/unmap the same region every time, then there is no point of doing it for every transfer. > > 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 -- 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
