Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1528286 > unrolled thread
| Started by | Mason <slash.tmp@free.fr> |
|---|---|
| First post | 2016-11-23 11:30 +0100 |
| Last post | 2016-12-08 12:50 +0100 |
| Articles | 20 on this page of 80 — 7 participants |
Back to article view | Back to linux.kernel
Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-11-23 11:30 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-11-23 13:20 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-11-23 13:50 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-11-23 18:30 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-11-24 12:00 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-11-24 15:20 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-11-24 16:30 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-11-24 17:40 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Vinod Koul <vinod.koul@intel.com> - 2016-11-25 05:50 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-11-25 13:00 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-11-25 15:10 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-11-25 15:20 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-11-25 15:30 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-11-25 15:50 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-11-25 13:50 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-11-25 14:10 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-11-25 14:40 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-11-25 15:00 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-11-25 15:10 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-11-25 15:30 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-11-25 15:50 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-11-25 16:00 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-11-25 16:30 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-11-25 16:10 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-11-25 16:20 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-11-25 16:30 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-11-25 16:30 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-11-25 15:00 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-11-25 13:50 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-11-25 14:20 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-11-25 15:30 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-11-25 15:40 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-11-25 16:50 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-11-29 19:30 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Vinod Koul <vinod.koul@intel.com> - 2016-12-06 06:10 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-12-06 13:50 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-12-06 14:20 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-12-06 16:30 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-12-06 16:40 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-12-07 00:00 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Vinod Koul <vinod.koul@intel.com> - 2016-12-07 17:40 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-12-07 17:50 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Vinod Koul <vinod.koul@intel.com> - 2016-12-08 11:40 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-12-08 12:00 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Geert Uytterhoeven <geert@linux-m68k.org> - 2016-12-08 12:20 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-12-08 12:50 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Geert Uytterhoeven <geert@linux-m68k.org> - 2016-12-08 13:10 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-12-08 13:20 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-12-08 13:30 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Vinod Koul <vinod.koul@intel.com> - 2016-12-08 17:40 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-12-08 17:50 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Vinod Koul <vinod.koul@intel.com> - 2016-12-09 08:10 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Sebastian Frias <sf84@laposte.net> - 2016-12-09 11:30 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-12-09 12:40 +0100
Re: Tearing down DMA transfer setup after DMA client has finished 1Måns Rullgård <mans@mansr.com> - 2016-12-09 12:40 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Vinod Koul <vinod.koul@intel.com> - 2016-12-09 18:20 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-12-09 18:30 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Vinod Koul <vinod.koul@intel.com> - 2016-12-09 19:00 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-12-09 18:40 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Vinod Koul <vinod.koul@intel.com> - 2016-12-09 19:00 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Vinod Koul <vinod.koul@intel.com> - 2016-12-09 19:20 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-12-09 19:30 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-12-08 12:50 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Geert Uytterhoeven <geert@linux-m68k.org> - 2016-12-08 13:10 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-12-08 13:30 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Geert Uytterhoeven <geert@linux-m68k.org> - 2016-12-08 13:40 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-12-08 13:50 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-12-08 14:40 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-12-08 14:40 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-12-08 13:50 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Vinod Koul <vinod.koul@intel.com> - 2016-12-08 16:50 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-12-08 17:40 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Vinod Koul <vinod.koul@intel.com> - 2016-12-08 16:40 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Mason <slash.tmp@free.fr> - 2016-12-08 16:50 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Vinod Koul <vinod.koul@intel.com> - 2016-12-08 17:30 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-12-08 17:50 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Vinod Koul <vinod.koul@intel.com> - 2016-12-07 17:40 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-12-07 17:50 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Vinod Koul <vinod.koul@intel.com> - 2016-12-08 11:30 +0100
Re: Tearing down DMA transfer setup after DMA client has finished Måns Rullgård <mans@mansr.com> - 2016-12-08 12:50 +0100
Page 1 of 4 [1] 2 3 4 Next page →
| From | Mason <slash.tmp@free.fr> |
|---|---|
| Date | 2016-11-23 11:30 +0100 |
| Subject | Tearing down DMA transfer setup after DMA client has finished |
| Message-ID | <sGCYp-3DP-15@gated-at.bofh.it> |
Hello, On my platform, setting up a DMA transfer is a two-step process: 1) configure the "switch box" to connect a device to a memory channel 2) configure the transfer details (address, size, command) When the transfer is done, the sbox setup can be torn down, and the DMA driver can start another transfer. The current software architecture for my NFC (NAND Flash controller) driver is as follows (for one DMA transfer). sg_init_one dma_map_sg dmaengine_prep_slave_sg dmaengine_submit dma_async_issue_pending configure_NFC_transfer wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT wait_for_NFC_idle dma_unmap_sg The problem is that the DMA driver tears down the sbox setup as soon as it receives the IRQ. However, when writing to the device, the interrupt only means "I have pushed all data from memory to the memory channel". These data have not reached the device yet, and may still be "in flight". Thus the sbox setup can only be torn down after the NFC is idle. How do I call back into the DMA driver after wait_for_NFC_idle, to request sbox tear down? The new architecture would become: sg_init_one dma_map_sg dmaengine_prep_slave_sg dmaengine_submit dma_async_issue_pending configure_NFC_transfer wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT wait_for_NFC_idle request_sbox_tear_down /*** HOW TO DO THAT ***/ dma_unmap_sg As far as I can tell, my NFC driver should call dmaengine_synchronize ?? (In other words request_sbox_tear_down == dmaengine_synchronize) So the DMA driver should implement the device_synchronize hook, and tear the sbox down in that function. Is that correct? Or am I on the wrong track? Regards.
[toc] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2016-11-23 13:20 +0100 |
| Message-ID | <sGEGR-4OI-11@gated-at.bofh.it> |
| In reply to | #1528286 |
Mason <slash.tmp@free.fr> writes: > Hello, > > On my platform, setting up a DMA transfer is a two-step process: > > 1) configure the "switch box" to connect a device to a memory channel > 2) configure the transfer details (address, size, command) > > When the transfer is done, the sbox setup can be torn down, > and the DMA driver can start another transfer. > > The current software architecture for my NFC (NAND Flash controller) > driver is as follows (for one DMA transfer). > > sg_init_one > dma_map_sg > dmaengine_prep_slave_sg > dmaengine_submit > dma_async_issue_pending > configure_NFC_transfer > wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT > wait_for_NFC_idle > dma_unmap_sg > > The problem is that the DMA driver tears down the sbox setup > as soon as it receives the IRQ. However, when writing to the > device, the interrupt only means "I have pushed all data from > memory to the memory channel". These data have not reached > the device yet, and may still be "in flight". Thus the sbox > setup can only be torn down after the NFC is idle. > > How do I call back into the DMA driver after wait_for_NFC_idle, > to request sbox tear down? > > The new architecture would become: > > sg_init_one > dma_map_sg > dmaengine_prep_slave_sg > dmaengine_submit > dma_async_issue_pending > configure_NFC_transfer > wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT > wait_for_NFC_idle > request_sbox_tear_down /*** HOW TO DO THAT ***/ > dma_unmap_sg > > As far as I can tell, my NFC driver should call dmaengine_synchronize ?? > (In other words request_sbox_tear_down == dmaengine_synchronize) > > So the DMA driver should implement the device_synchronize hook, > and tear the sbox down in that function. > > Is that correct? Or am I on the wrong track? dmaengine_synchronize() is not meant for this. See the documentation: /** * dmaengine_synchronize() - Synchronize DMA channel termination * @chan: The channel to synchronize * * Synchronizes to the DMA channel termination to the current context. When this * function returns it is guaranteed that all transfers for previously issued * descriptors have stopped and and it is safe to free the memory assoicated * with them. Furthermore it is guaranteed that all complete callback functions * for a previously submitted descriptor have finished running and it is safe to * free resources accessed from within the complete callbacks. * * The behavior of this function is undefined if dma_async_issue_pending() has * been called between dmaengine_terminate_async() and this function. * * This function must only be called from non-atomic context and must not be * called from within a complete callback of a descriptor submitted on the same * channel. */ This is for use after a dmaengine_terminate_async() call to wait for the dma engine to finish whatever it was doing. This is not the problem here. Your problem is that the dma engine interrupt fires before the transfer is actually complete. Although you get an indication from the target device when it has received all the data, there is no way to make the dma driver wait for this. -- Måns Rullgård
[toc] | [prev] | [next] | [standalone]
| From | Mason <slash.tmp@free.fr> |
|---|---|
| Date | 2016-11-23 13:50 +0100 |
| Message-ID | <sGF9T-4Yp-1@gated-at.bofh.it> |
| In reply to | #1528358 |
On 23/11/2016 13:13, Måns Rullgård wrote: > Mason wrote: > >> On my platform, setting up a DMA transfer is a two-step process: >> >> 1) configure the "switch box" to connect a device to a memory channel >> 2) configure the transfer details (address, size, command) >> >> When the transfer is done, the sbox setup can be torn down, >> and the DMA driver can start another transfer. >> >> The current software architecture for my NFC (NAND Flash controller) >> driver is as follows (for one DMA transfer). >> >> sg_init_one >> dma_map_sg >> dmaengine_prep_slave_sg >> dmaengine_submit >> dma_async_issue_pending >> configure_NFC_transfer >> wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT >> wait_for_NFC_idle >> dma_unmap_sg >> >> The problem is that the DMA driver tears down the sbox setup >> as soon as it receives the IRQ. However, when writing to the >> device, the interrupt only means "I have pushed all data from >> memory to the memory channel". These data have not reached >> the device yet, and may still be "in flight". Thus the sbox >> setup can only be torn down after the NFC is idle. >> >> How do I call back into the DMA driver after wait_for_NFC_idle, >> to request sbox tear down? >> >> The new architecture would become: >> >> sg_init_one >> dma_map_sg >> dmaengine_prep_slave_sg >> dmaengine_submit >> dma_async_issue_pending >> configure_NFC_transfer >> wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT >> wait_for_NFC_idle >> request_sbox_tear_down /*** HOW TO DO THAT ***/ >> dma_unmap_sg >> >> As far as I can tell, my NFC driver should call dmaengine_synchronize ?? >> (In other words request_sbox_tear_down == dmaengine_synchronize) >> >> So the DMA driver should implement the device_synchronize hook, >> and tear the sbox down in that function. >> >> Is that correct? Or am I on the wrong track? > > dmaengine_synchronize() is not meant for this. See the documentation: > > /** > * dmaengine_synchronize() - Synchronize DMA channel termination > * @chan: The channel to synchronize > * > * Synchronizes to the DMA channel termination to the current context. When this > * function returns it is guaranteed that all transfers for previously issued > * descriptors have stopped and and it is safe to free the memory assoicated > * with them. Furthermore it is guaranteed that all complete callback functions > * for a previously submitted descriptor have finished running and it is safe to > * free resources accessed from within the complete callbacks. > * > * The behavior of this function is undefined if dma_async_issue_pending() has > * been called between dmaengine_terminate_async() and this function. > * > * This function must only be called from non-atomic context and must not be > * called from within a complete callback of a descriptor submitted on the same > * channel. > */ > > This is for use after a dmaengine_terminate_async() call to wait for the > dma engine to finish whatever it was doing. This is not the problem > here. Your problem is that the dma engine interrupt fires before the > transfer is actually complete. Although you get an indication from the > target device when it has received all the data, there is no way to make > the dma driver wait for this. Hello Mans, I'm confused. Are you saying there is no solution to my problem within the existing DMA framework? In its current form, the tangox-dma.c driver will fail randomly for writes to a device (SATA, NFC). Maybe an extra hook can be added to the DMA framework? I'd like to hear from the framework's maintainers. Perhaps they can provide some guidance. Regards.
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2016-11-23 18:30 +0100 |
| Message-ID | <sGJwX-7LD-27@gated-at.bofh.it> |
| In reply to | #1528374 |
Mason <slash.tmp@free.fr> writes: > On 23/11/2016 13:13, Måns Rullgård wrote: > >> Mason wrote: >> >>> On my platform, setting up a DMA transfer is a two-step process: >>> >>> 1) configure the "switch box" to connect a device to a memory channel >>> 2) configure the transfer details (address, size, command) >>> >>> When the transfer is done, the sbox setup can be torn down, >>> and the DMA driver can start another transfer. >>> >>> The current software architecture for my NFC (NAND Flash controller) >>> driver is as follows (for one DMA transfer). >>> >>> sg_init_one >>> dma_map_sg >>> dmaengine_prep_slave_sg >>> dmaengine_submit >>> dma_async_issue_pending >>> configure_NFC_transfer >>> wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT >>> wait_for_NFC_idle >>> dma_unmap_sg >>> >>> The problem is that the DMA driver tears down the sbox setup >>> as soon as it receives the IRQ. However, when writing to the >>> device, the interrupt only means "I have pushed all data from >>> memory to the memory channel". These data have not reached >>> the device yet, and may still be "in flight". Thus the sbox >>> setup can only be torn down after the NFC is idle. >>> >>> How do I call back into the DMA driver after wait_for_NFC_idle, >>> to request sbox tear down? >>> >>> The new architecture would become: >>> >>> sg_init_one >>> dma_map_sg >>> dmaengine_prep_slave_sg >>> dmaengine_submit >>> dma_async_issue_pending >>> configure_NFC_transfer >>> wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT >>> wait_for_NFC_idle >>> request_sbox_tear_down /*** HOW TO DO THAT ***/ >>> dma_unmap_sg >>> >>> As far as I can tell, my NFC driver should call dmaengine_synchronize ?? >>> (In other words request_sbox_tear_down == dmaengine_synchronize) >>> >>> So the DMA driver should implement the device_synchronize hook, >>> and tear the sbox down in that function. >>> >>> Is that correct? Or am I on the wrong track? >> >> dmaengine_synchronize() is not meant for this. See the documentation: >> >> /** >> * dmaengine_synchronize() - Synchronize DMA channel termination >> * @chan: The channel to synchronize >> * >> * Synchronizes to the DMA channel termination to the current context. When this >> * function returns it is guaranteed that all transfers for previously issued >> * descriptors have stopped and and it is safe to free the memory assoicated >> * with them. Furthermore it is guaranteed that all complete callback functions >> * for a previously submitted descriptor have finished running and it is safe to >> * free resources accessed from within the complete callbacks. >> * >> * The behavior of this function is undefined if dma_async_issue_pending() has >> * been called between dmaengine_terminate_async() and this function. >> * >> * This function must only be called from non-atomic context and must not be >> * called from within a complete callback of a descriptor submitted on the same >> * channel. >> */ >> >> This is for use after a dmaengine_terminate_async() call to wait for the >> dma engine to finish whatever it was doing. This is not the problem >> here. Your problem is that the dma engine interrupt fires before the >> transfer is actually complete. Although you get an indication from the >> target device when it has received all the data, there is no way to make >> the dma driver wait for this. > > Hello Mans, > > I'm confused. Are you saying there is no solution to my problem > within the existing DMA framework? > > In its current form, the tangox-dma.c driver will fail randomly > for writes to a device (SATA, NFC). > > Maybe an extra hook can be added to the DMA framework? > > I'd like to hear from the framework's maintainers. Perhaps they > can provide some guidance. You could have the dma descriptor callback wait for the receiving device to finish. Bear in mind this runs from a tasklet, so it's not allowed to sleep. -- Måns Rullgård
[toc] | [prev] | [next] | [standalone]
| From | Mason <slash.tmp@free.fr> |
|---|---|
| Date | 2016-11-24 12:00 +0100 |
| Message-ID | <sGZUZ-1zn-27@gated-at.bofh.it> |
| In reply to | #1528621 |
On 23/11/2016 18:21, Måns Rullgård wrote:
> Mason writes:
>
>> On 23/11/2016 13:13, Måns Rullgård wrote:
>>
>>> Mason wrote:
>>>
>>>> On my platform, setting up a DMA transfer is a two-step process:
>>>>
>>>> 1) configure the "switch box" to connect a device to a memory channel
>>>> 2) configure the transfer details (address, size, command)
>>>>
>>>> When the transfer is done, the sbox setup can be torn down,
>>>> and the DMA driver can start another transfer.
>>>>
>>>> The current software architecture for my NFC (NAND Flash controller)
>>>> driver is as follows (for one DMA transfer).
>>>>
>>>> sg_init_one
>>>> dma_map_sg
>>>> dmaengine_prep_slave_sg
>>>> dmaengine_submit
>>>> dma_async_issue_pending
>>>> configure_NFC_transfer
>>>> wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT
>>>> wait_for_NFC_idle
>>>> dma_unmap_sg
>>>>
>>>> The problem is that the DMA driver tears down the sbox setup
>>>> as soon as it receives the IRQ. However, when writing to the
>>>> device, the interrupt only means "I have pushed all data from
>>>> memory to the memory channel". These data have not reached
>>>> the device yet, and may still be "in flight". Thus the sbox
>>>> setup can only be torn down after the NFC is idle.
>>>>
>>>> How do I call back into the DMA driver after wait_for_NFC_idle,
>>>> to request sbox tear down?
>>>>
>>>> The new architecture would become:
>>>>
>>>> sg_init_one
>>>> dma_map_sg
>>>> dmaengine_prep_slave_sg
>>>> dmaengine_submit
>>>> dma_async_issue_pending
>>>> configure_NFC_transfer
>>>> wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT
>>>> wait_for_NFC_idle
>>>> request_sbox_tear_down /*** HOW TO DO THAT ***/
>>>> dma_unmap_sg
>>>>
>>>> As far as I can tell, my NFC driver should call dmaengine_synchronize ??
>>>> (In other words request_sbox_tear_down == dmaengine_synchronize)
>>>>
>>>> So the DMA driver should implement the device_synchronize hook,
>>>> and tear the sbox down in that function.
>>>>
>>>> Is that correct? Or am I on the wrong track?
>>>
>>> dmaengine_synchronize() is not meant for this. See the documentation:
>>>
>>> /**
>>> * dmaengine_synchronize() - Synchronize DMA channel termination
>>> * @chan: The channel to synchronize
>>> *
>>> * Synchronizes to the DMA channel termination to the current context. When this
>>> * function returns it is guaranteed that all transfers for previously issued
>>> * descriptors have stopped and and it is safe to free the memory assoicated
>>> * with them. Furthermore it is guaranteed that all complete callback functions
>>> * for a previously submitted descriptor have finished running and it is safe to
>>> * free resources accessed from within the complete callbacks.
>>> *
>>> * The behavior of this function is undefined if dma_async_issue_pending() has
>>> * been called between dmaengine_terminate_async() and this function.
>>> *
>>> * This function must only be called from non-atomic context and must not be
>>> * called from within a complete callback of a descriptor submitted on the same
>>> * channel.
>>> */
>>>
>>> This is for use after a dmaengine_terminate_async() call to wait for the
>>> dma engine to finish whatever it was doing. This is not the problem
>>> here. Your problem is that the dma engine interrupt fires before the
>>> transfer is actually complete. Although you get an indication from the
>>> target device when it has received all the data, there is no way to make
>>> the dma driver wait for this.
>>
>> Hello Mans,
>>
>> I'm confused. Are you saying there is no solution to my problem
>> within the existing DMA framework?
>>
>> In its current form, the tangox-dma.c driver will fail randomly
>> for writes to a device (SATA, NFC).
>>
>> Maybe an extra hook can be added to the DMA framework?
>>
>> I'd like to hear from the framework's maintainers. Perhaps they
>> can provide some guidance.
>
> You could have the dma descriptor callback wait for the receiving device
> to finish. Bear in mind this runs from a tasklet, so it's not allowed
> to sleep.
Thanks for the suggestion, but I don't think it works :-(
This is my DMA desc callback:
static void tango_dma_callback(void *arg)
{
printk("%s from %pf\n", __func__, __builtin_return_address(0));
mdelay(10000);
printk("DONE FAKE SPINNING\n");
complete(arg);
}
I also added
printk("%s from %pf\n", __func__, __builtin_return_address(0));
after tangox_dma_pchan_detach(pchan);
And I get this output:
[ 35.085854] SETUP DMA
[ 35.088272] START NAND TRANSFER
[ 35.091670] tangox_dma_pchan_start from tangox_dma_irq
[ 35.096882] tango_dma_callback from vchan_complete
[ 45.102513] DONE FAKE SPINNING
So the IRQ rolls in, the ISR calls tangox_dma_pchan_start,
which calls tangox_dma_pchan_detach to tear down the sbox
setup; and only sometime later does the DMA framework call
my callback function.
So far, the work-arounds I've tested are:
1) delay sbox tear-down by 10 µs in tangox_dma_pchan_detach.
2) statically setup sbox in probe, and never touch it henceforth.
WA1 is fragile, it might break for devices other than NFC.
WA2 is what I used when I wrote the NFC driver.
Can tangox_dma_irq() be changed to have the framework call
the client's callback *before* tangox_dma_pchan_start?
(Thinking out loud) The DMA_PREP_INTERRUPT requests that the
DMA framework invoke the callback from tasklet context,
maybe a different flag DMA_PREP_INTERRUPT_EX can request
calling the call-back directly from within the ISR?
(Looking at existing flags) Could I use DMA_CTRL_ACK?
Description sounds like some kind hand-shake between
client and dmaengine.
Grepping for DMA_PREP_INTERRUPT, I don't see where the framework
checks that flag to spawn the tasklet? Or is that up to each
driver individually?
Regards.
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2016-11-24 15:20 +0100 |
| Message-ID | <sH32y-3T3-23@gated-at.bofh.it> |
| In reply to | #1529166 |
Mason <slash.tmp@free.fr> writes:
>>> I'm confused. Are you saying there is no solution to my problem
>>> within the existing DMA framework?
>>>
>>> In its current form, the tangox-dma.c driver will fail randomly
>>> for writes to a device (SATA, NFC).
>>>
>>> Maybe an extra hook can be added to the DMA framework?
>>>
>>> I'd like to hear from the framework's maintainers. Perhaps they
>>> can provide some guidance.
>>
>> You could have the dma descriptor callback wait for the receiving device
>> to finish. Bear in mind this runs from a tasklet, so it's not allowed
>> to sleep.
>
> Thanks for the suggestion, but I don't think it works :-(
>
> This is my DMA desc callback:
>
> static void tango_dma_callback(void *arg)
> {
> printk("%s from %pf\n", __func__, __builtin_return_address(0));
> mdelay(10000);
> printk("DONE FAKE SPINNING\n");
> complete(arg);
> }
>
> I also added
> printk("%s from %pf\n", __func__, __builtin_return_address(0));
> after tangox_dma_pchan_detach(pchan);
>
> And I get this output:
>
> [ 35.085854] SETUP DMA
> [ 35.088272] START NAND TRANSFER
> [ 35.091670] tangox_dma_pchan_start from tangox_dma_irq
> [ 35.096882] tango_dma_callback from vchan_complete
> [ 45.102513] DONE FAKE SPINNING
>
> So the IRQ rolls in, the ISR calls tangox_dma_pchan_start,
> which calls tangox_dma_pchan_detach to tear down the sbox
> setup; and only sometime later does the DMA framework call
> my callback function.
Yes, I realised this soon after I said it. The dma driver could be
rearranged to make it work though.
> So far, the work-arounds I've tested are:
>
> 1) delay sbox tear-down by 10 µs in tangox_dma_pchan_detach.
> 2) statically setup sbox in probe, and never touch it henceforth.
>
> WA1 is fragile, it might break for devices other than NFC.
> WA2 is what I used when I wrote the NFC driver.
>
> Can tangox_dma_irq() be changed to have the framework call
> the client's callback *before* tangox_dma_pchan_start?
>
> (Thinking out loud) The DMA_PREP_INTERRUPT requests that the
> DMA framework invoke the callback from tasklet context,
> maybe a different flag DMA_PREP_INTERRUPT_EX can request
> calling the call-back directly from within the ISR?
>
> (Looking at existing flags) Could I use DMA_CTRL_ACK?
> Description sounds like some kind hand-shake between
> client and dmaengine.
>
> Grepping for DMA_PREP_INTERRUPT, I don't see where the framework
> checks that flag to spawn the tasklet? Or is that up to each
> driver individually?
Those flags all have defined meanings and abusing them for other things
is a bad idea. As far as possible, device drivers should work with any
dma driver.
--
Måns Rullgård
[toc] | [prev] | [next] | [standalone]
| From | Mason <slash.tmp@free.fr> |
|---|---|
| Date | 2016-11-24 16:30 +0100 |
| Message-ID | <sH48j-4wC-71@gated-at.bofh.it> |
| In reply to | #1529328 |
On 24/11/2016 15:17, Måns Rullgård wrote: > Mason wrote: > >> [ 35.085854] SETUP DMA >> [ 35.088272] START NAND TRANSFER >> [ 35.091670] tangox_dma_pchan_start from tangox_dma_irq >> [ 35.096882] tango_dma_callback from vchan_complete >> [ 45.102513] DONE FAKE SPINNING >> >> So the IRQ rolls in, the ISR calls tangox_dma_pchan_start, >> which calls tangox_dma_pchan_detach to tear down the sbox >> setup; and only sometime later does the DMA framework call >> my callback function. > > Yes, I realised this soon after I said it. The dma driver could be > rearranged to make it work though. There is a way to make the tasklet run and invoke the callback before the interrupt service routine proceeds? Can you say more about this? >> So far, the work-arounds I've tested are: >> >> 1) delay sbox tear-down by 10 µs in tangox_dma_pchan_detach. >> 2) statically setup sbox in probe, and never touch it henceforth. >> >> WA1 is fragile, it might break for devices other than NFC. >> WA2 is what I used when I wrote the NFC driver. >> >> Can tangox_dma_irq() be changed to have the framework call >> the client's callback *before* tangox_dma_pchan_start? >> >> (Thinking out loud) The DMA_PREP_INTERRUPT requests that the >> DMA framework invoke the callback from tasklet context, >> maybe a different flag DMA_PREP_INTERRUPT_EX can request >> calling the call-back directly from within the ISR? >> >> (Looking at existing flags) Could I use DMA_CTRL_ACK? >> Description sounds like some kind hand-shake between >> client and dmaengine. >> >> Grepping for DMA_PREP_INTERRUPT, I don't see where the framework >> checks that flag to spawn the tasklet? Or is that up to each >> driver individually? > > Those flags all have defined meanings and abusing them for other things > is a bad idea. As far as possible, device drivers should work with any > dma driver. I was asking about introducing a new flag, not abusing existing flags. (I don't understand the semantics of DMA_CTRL_ACK.) (FWIW, both the NFC and the MBUS agent are custom designs, not third-party IP blocks.) Regards.
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2016-11-24 17:40 +0100 |
| Message-ID | <sH5e1-5eA-21@gated-at.bofh.it> |
| In reply to | #1529447 |
Mason <slash.tmp@free.fr> writes: > On 24/11/2016 15:17, Måns Rullgård wrote: > >> Mason wrote: >> >>> [ 35.085854] SETUP DMA >>> [ 35.088272] START NAND TRANSFER >>> [ 35.091670] tangox_dma_pchan_start from tangox_dma_irq >>> [ 35.096882] tango_dma_callback from vchan_complete >>> [ 45.102513] DONE FAKE SPINNING >>> >>> So the IRQ rolls in, the ISR calls tangox_dma_pchan_start, >>> which calls tangox_dma_pchan_detach to tear down the sbox >>> setup; and only sometime later does the DMA framework call >>> my callback function. >> >> Yes, I realised this soon after I said it. The dma driver could be >> rearranged to make it work though. > > There is a way to make the tasklet run and invoke the callback > before the interrupt service routine proceeds? No, but it would be possible to defer the teardown to the tasklet. Having said that, I'm not sure it's such a great idea since the tasklet could be held up for an arbitrary length of time waiting for the target to finish. >>> So far, the work-arounds I've tested are: >>> >>> 1) delay sbox tear-down by 10 µs in tangox_dma_pchan_detach. >>> 2) statically setup sbox in probe, and never touch it henceforth. >>> >>> WA1 is fragile, it might break for devices other than NFC. >>> WA2 is what I used when I wrote the NFC driver. >>> >>> Can tangox_dma_irq() be changed to have the framework call >>> the client's callback *before* tangox_dma_pchan_start? >>> >>> (Thinking out loud) The DMA_PREP_INTERRUPT requests that the >>> DMA framework invoke the callback from tasklet context, >>> maybe a different flag DMA_PREP_INTERRUPT_EX can request >>> calling the call-back directly from within the ISR? >>> >>> (Looking at existing flags) Could I use DMA_CTRL_ACK? >>> Description sounds like some kind hand-shake between >>> client and dmaengine. >>> >>> Grepping for DMA_PREP_INTERRUPT, I don't see where the framework >>> checks that flag to spawn the tasklet? Or is that up to each >>> driver individually? >> >> Those flags all have defined meanings and abusing them for other things >> is a bad idea. As far as possible, device drivers should work with any >> dma driver. > > I was asking about introducing a new flag, not abusing existing > flags. (I don't understand the semantics of DMA_CTRL_ACK.) This needs more than a new flag anyhow. > (FWIW, both the NFC and the MBUS agent are custom designs, > not third-party IP blocks.) Sure, but who knows what will be in the next chip? -- Måns Rullgård
[toc] | [prev] | [next] | [standalone]
| From | Vinod Koul <vinod.koul@intel.com> |
|---|---|
| Date | 2016-11-25 05:50 +0100 |
| Message-ID | <sHgCu-4he-7@gated-at.bofh.it> |
| In reply to | #1528286 |
On Wed, Nov 23, 2016 at 11:25:44AM +0100, Mason wrote: > Hello, > > On my platform, setting up a DMA transfer is a two-step process: > > 1) configure the "switch box" to connect a device to a memory channel > 2) configure the transfer details (address, size, command) > > When the transfer is done, the sbox setup can be torn down, > and the DMA driver can start another transfer. > > The current software architecture for my NFC (NAND Flash controller) > driver is as follows (for one DMA transfer). > > sg_init_one > dma_map_sg > dmaengine_prep_slave_sg > dmaengine_submit > dma_async_issue_pending > configure_NFC_transfer > wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT > wait_for_NFC_idle > dma_unmap_sg Looking at thread and discussion now, first thinking would be to ensure the transaction is completed properly and then isr fired. You may need to talk to your HW designers to find a way for that. It is quite common that DMA controllers will fire and complete whereas the transaction is still in flight. If that is not doable, then since you claim this is custom part which other vendors wont use (hope we are wrong down the line), then we can have a custom api, foo_sbox_configure(bool enable, ...); This can be invoked from NFC driver when required for configuration and teardown. For very specific cases where people need some specific configuration we do allow custom APIs. Only problem with that would be it wont be a generic solution and you seem to be fine with that. -- ~Vinod
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2016-11-25 13:00 +0100 |
| Message-ID | <sHnkG-8uw-11@gated-at.bofh.it> |
| In reply to | #1529792 |
Vinod Koul <vinod.koul@intel.com> writes: > On Wed, Nov 23, 2016 at 11:25:44AM +0100, Mason wrote: >> Hello, >> >> On my platform, setting up a DMA transfer is a two-step process: >> >> 1) configure the "switch box" to connect a device to a memory channel >> 2) configure the transfer details (address, size, command) >> >> When the transfer is done, the sbox setup can be torn down, >> and the DMA driver can start another transfer. >> >> The current software architecture for my NFC (NAND Flash controller) >> driver is as follows (for one DMA transfer). >> >> sg_init_one >> dma_map_sg >> dmaengine_prep_slave_sg >> dmaengine_submit >> dma_async_issue_pending >> configure_NFC_transfer >> wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT >> wait_for_NFC_idle >> dma_unmap_sg > > Looking at thread and discussion now, first thinking would be to ensure > the transaction is completed properly and then isr fired. You may need > to talk to your HW designers to find a way for that. It is quite common > that DMA controllers will fire and complete whereas the transaction is > still in flight. The hardware is what it is, and it has been deployed in some form or other for years. > If that is not doable, then since you claim this is custom part which > other vendors wont use (hope we are wrong down the line), then we can > have a custom api, > > foo_sbox_configure(bool enable, ...); > > This can be invoked from NFC driver when required for configuration and > teardown. For very specific cases where people need some specific > configuration we do allow custom APIs. > > Only problem with that would be it wont be a generic solution and you > seem to be fine with that. The same DMA unit is also used for SATA, which is an off the shelf Designware controller with an in-kernel driver. This interrupt timing glitch can actually explain some intermittent errors I've observed with it. One possible solution is to add a new function for device drivers to call when their end is complete. Existing DMA drivers would simply do nothing, and device drivers could have this call added whenever the need arises. -- Måns Rullgård
[toc] | [prev] | [next] | [standalone]
| From | Mason <slash.tmp@free.fr> |
|---|---|
| Date | 2016-11-25 15:10 +0100 |
| Message-ID | <sHpmr-1yD-41@gated-at.bofh.it> |
| In reply to | #1530143 |
On 25/11/2016 12:57, Måns Rullgård wrote: > The same DMA unit is also used for SATA, which is an off the shelf > Designware controller with an in-kernel driver. This interrupt timing > glitch can actually explain some intermittent errors I've observed with > it. FWIW, newer chips embed an AHCI controller, with a dedicated memory channel. FWIW2, the HW dev said memory channels are "almost free", and he would have no problem giving each device their own private channel read/write pair. Regards.
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2016-11-25 15:20 +0100 |
| Message-ID | <sHpwa-1F9-7@gated-at.bofh.it> |
| In reply to | #1530266 |
Mason <slash.tmp@free.fr> writes: > On 25/11/2016 12:57, Måns Rullgård wrote: > >> The same DMA unit is also used for SATA, which is an off the shelf >> Designware controller with an in-kernel driver. This interrupt timing >> glitch can actually explain some intermittent errors I've observed with >> it. > > FWIW, newer chips embed an AHCI controller, with a dedicated > memory channel. > > FWIW2, the HW dev said memory channels are "almost free", and he > would have no problem giving each device their own private channel > read/write pair. We still need to deal with the existing hardware. -- Måns Rullgård
[toc] | [prev] | [next] | [standalone]
| From | Mason <slash.tmp@free.fr> |
|---|---|
| Date | 2016-11-25 15:30 +0100 |
| Message-ID | <sHpFL-1In-19@gated-at.bofh.it> |
| In reply to | #1530270 |
On 25/11/2016 15:12, Måns Rullgård wrote: > Mason writes: > >> On 25/11/2016 12:57, Måns Rullgård wrote: >> >>> The same DMA unit is also used for SATA, which is an off the shelf >>> Designware controller with an in-kernel driver. This interrupt timing >>> glitch can actually explain some intermittent errors I've observed with >>> it. >> >> FWIW, newer chips embed an AHCI controller, with a dedicated >> memory channel. >> >> FWIW2, the HW dev said memory channels are "almost free", and he >> would have no problem giving each device their own private channel >> read/write pair. > > We still need to deal with the existing hardware. Can you confirm that your MBUS driver, in its current form, does not support memcpy-type transfers, which generate two IRQs (one from send agent, one from receive agent)? Do you plan to support that, or is it just too quirky? Regards.
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2016-11-25 15:50 +0100 |
| Message-ID | <sHpZ7-1P4-1@gated-at.bofh.it> |
| In reply to | #1530278 |
Mason <slash.tmp@free.fr> writes: > On 25/11/2016 15:12, Måns Rullgård wrote: > >> Mason writes: >> >>> On 25/11/2016 12:57, Måns Rullgård wrote: >>> >>>> The same DMA unit is also used for SATA, which is an off the shelf >>>> Designware controller with an in-kernel driver. This interrupt timing >>>> glitch can actually explain some intermittent errors I've observed with >>>> it. >>> >>> FWIW, newer chips embed an AHCI controller, with a dedicated >>> memory channel. >>> >>> FWIW2, the HW dev said memory channels are "almost free", and he >>> would have no problem giving each device their own private channel >>> read/write pair. >> >> We still need to deal with the existing hardware. > > Can you confirm that your MBUS driver, in its current form, > does not support memcpy-type transfers, which generate two > IRQs (one from send agent, one from receive agent)? It does not. > Do you plan to support that, or is it just too quirky? I hadn't planned on doing that, but I'm ruling it out entirely. -- Måns Rullgård
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2016-11-25 13:50 +0100 |
| Message-ID | <sHo70-CC-23@gated-at.bofh.it> |
| In reply to | #1529792 |
On Fri, Nov 25, 2016 at 10:25:49AM +0530, Vinod Koul wrote: > Looking at thread and discussion now, first thinking would be to ensure > the transaction is completed properly and then isr fired. You may need > to talk to your HW designers to find a way for that. It is quite common > that DMA controllers will fire and complete whereas the transaction is > still in flight. > > If that is not doable, then since you claim this is custom part which > other vendors wont use (hope we are wrong down the line), then we can > have a custom api, > > foo_sbox_configure(bool enable, ...); > > This can be invoked from NFC driver when required for configuration and > teardown. For very specific cases where people need some specific > configuration we do allow custom APIs. > > Only problem with that would be it wont be a generic solution and you > seem to be fine with that. Isn't this just the same problem as PL08x or any other system which has multiple requests from devices, but only a limited number of hardware channels - so you have to route the request signals to the appropriate hardware channels according to the requests queued up? If so, no new "custom" APIs are required, it's already able to be solved within the DMA engine drivers... (We also have more complex situations already supported, such as PL08x with a FPGA routing on three of its request signals.) -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2016-11-25 14:10 +0100 |
| Message-ID | <sHoqn-YR-67@gated-at.bofh.it> |
| In reply to | #1530181 |
Russell King - ARM Linux <linux@armlinux.org.uk> writes: > On Fri, Nov 25, 2016 at 10:25:49AM +0530, Vinod Koul wrote: >> Looking at thread and discussion now, first thinking would be to ensure >> the transaction is completed properly and then isr fired. You may need >> to talk to your HW designers to find a way for that. It is quite common >> that DMA controllers will fire and complete whereas the transaction is >> still in flight. >> >> If that is not doable, then since you claim this is custom part which >> other vendors wont use (hope we are wrong down the line), then we can >> have a custom api, >> >> foo_sbox_configure(bool enable, ...); >> >> This can be invoked from NFC driver when required for configuration and >> teardown. For very specific cases where people need some specific >> configuration we do allow custom APIs. >> >> Only problem with that would be it wont be a generic solution and you >> seem to be fine with that. > > Isn't this just the same problem as PL08x or any other system which > has multiple requests from devices, but only a limited number of > hardware channels - so you have to route the request signals to the > appropriate hardware channels according to the requests queued up? > > If so, no new "custom" APIs are required, it's already able to be > solved within the DMA engine drivers... That isn't the problem. The multiplexing of many devices on a limited number of hardware channels is working fine. The problem is that (some) client devices need the routing to remain for some time after the dma interrupt signals completion. I'd characterise this hardware as broken, but there's nothing we can do about that. The fix has to provide some way for the dma driver to delay reusing a hardware channel until the client device indicates completion. If only a short delay (a few bus cycles) is needed, it is probably acceptable to rework the driver such that the descriptor completion callback can do the necessary waiting (e.g. by busy-polling a device status register). If the delay can be longer, some other method needs to be devised. -- Måns Rullgård
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2016-11-25 14:40 +0100 |
| Message-ID | <sHoTo-18u-15@gated-at.bofh.it> |
| In reply to | #1530216 |
On Fri, Nov 25, 2016 at 01:07:05PM +0000, Måns Rullgård wrote: > Russell King - ARM Linux <linux@armlinux.org.uk> writes: > > > On Fri, Nov 25, 2016 at 10:25:49AM +0530, Vinod Koul wrote: > >> Looking at thread and discussion now, first thinking would be to ensure > >> the transaction is completed properly and then isr fired. You may need > >> to talk to your HW designers to find a way for that. It is quite common > >> that DMA controllers will fire and complete whereas the transaction is > >> still in flight. > >> > >> If that is not doable, then since you claim this is custom part which > >> other vendors wont use (hope we are wrong down the line), then we can > >> have a custom api, > >> > >> foo_sbox_configure(bool enable, ...); > >> > >> This can be invoked from NFC driver when required for configuration and > >> teardown. For very specific cases where people need some specific > >> configuration we do allow custom APIs. > >> > >> Only problem with that would be it wont be a generic solution and you > >> seem to be fine with that. > > > > Isn't this just the same problem as PL08x or any other system which > > has multiple requests from devices, but only a limited number of > > hardware channels - so you have to route the request signals to the > > appropriate hardware channels according to the requests queued up? > > > > If so, no new "custom" APIs are required, it's already able to be > > solved within the DMA engine drivers... > > That isn't the problem. The multiplexing of many devices on a limited > number of hardware channels is working fine. The problem is that (some) > client devices need the routing to remain for some time after the dma > interrupt signals completion. I'd characterise this hardware as broken, > but there's nothing we can do about that. > > The fix has to provide some way for the dma driver to delay reusing a > hardware channel until the client device indicates completion. If only > a short delay (a few bus cycles) is needed, it is probably acceptable to > rework the driver such that the descriptor completion callback can do > the necessary waiting (e.g. by busy-polling a device status register). > If the delay can be longer, some other method needs to be devised. What I understood from the original mail is: | The problem is that the DMA driver tears down the sbox setup | as soon as it receives the IRQ. However, when writing to the | device, the interrupt only means "I have pushed all data from | memory to the memory channel". These data have not reached | the device yet, and may still be "in flight". Thus the sbox | setup can only be torn down after the NFC is idle. The interrupt comes in after it's read the the last data from memory, but the data is still sitting in the engine's buffers and has not yet been passed to the device. It sounds like the DMA engine buffers the data on its way to the device, and it's not clear from the description whether that is done in response to a request from the device or whether the data is prefetched. IOW, what the lifetime of the data in the dma engine is. It seems odd that the DMA engine provides no way to know whether the channel still contains data that is in-flight to the device, whether by interrupt (from the descriptions the IRQ is way too early) or by polling some status register within the DMA engine itself. If the delay is predictable, why not use a delayed workqueue or a hrtimer to wait a period after the IRQ before completing the DMA transaction? If it's not predictable and you haven't some status register in the DMA engine hardware that indicates whether there's remaining data, then the design really is screwed up, and I don't think there's a reasonable solution to the problem - anything would be a horrid hack that would be specific to this SoC. It would be unfair to augment the API and add the burden on everyone for the new API when 99.999% of the world doesn't require it. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2016-11-25 15:00 +0100 |
| Message-ID | <sHpcK-1fd-25@gated-at.bofh.it> |
| In reply to | #1530247 |
On Fri, Nov 25, 2016 at 01:50:35PM +0000, Måns Rullgård wrote: > Russell King - ARM Linux <linux@armlinux.org.uk> writes: > > It would be unfair to augment the API and add the burden on everyone > > for the new API when 99.999% of the world doesn't require it. > > I don't think making this particular dma driver wait for the descriptor > callback to return before reusing a channel quite amounts to a horrid > hack. It certainly wouldn't burden anyone other than the poor drivers > for devices connected to it, all of which are specific to Sigma AFAIK. Except when you stop to think that delaying in a tasklet is exactly the same as randomly delaying in an interrupt handler - the tasklet runs on the return path back to the parent context of an interrupt handler. Even if you sleep in the tasklet, you're sleeping on behalf of the currently executing thread - if it's a RT thread, you effectively destroy the RT-ness of the thread. Let's hope no one cares about RT performance on that hardware... -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2016-11-25 15:10 +0100 |
| Message-ID | <sHpmq-1yD-25@gated-at.bofh.it> |
| In reply to | #1530260 |
Russell King - ARM Linux <linux@armlinux.org.uk> writes: > On Fri, Nov 25, 2016 at 01:50:35PM +0000, Måns Rullgård wrote: >> Russell King - ARM Linux <linux@armlinux.org.uk> writes: >> > It would be unfair to augment the API and add the burden on everyone >> > for the new API when 99.999% of the world doesn't require it. >> >> I don't think making this particular dma driver wait for the descriptor >> callback to return before reusing a channel quite amounts to a horrid >> hack. It certainly wouldn't burden anyone other than the poor drivers >> for devices connected to it, all of which are specific to Sigma AFAIK. > > Except when you stop to think that delaying in a tasklet is exactly > the same as randomly delaying in an interrupt handler - the tasklet > runs on the return path back to the parent context of an interrupt > handler. Even if you sleep in the tasklet, you're sleeping on behalf > of the currently executing thread - if it's a RT thread, you effectively > destroy the RT-ness of the thread. Let's hope no one cares about RT > performance on that hardware... That's why I suggested to do this only if the needed delay is known to be no more than a few bus cycles. The completion callback is currently the only post-transfer interaction we have between the dma and device drivers. To handle an arbitrarily long delay, some new interface will be required. -- Måns Rullgård
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2016-11-25 15:30 +0100 |
| Message-ID | <sHpFL-1In-17@gated-at.bofh.it> |
| In reply to | #1530263 |
On Fri, Nov 25, 2016 at 02:03:20PM +0000, Måns Rullgård wrote: > Russell King - ARM Linux <linux@armlinux.org.uk> writes: > > > On Fri, Nov 25, 2016 at 01:50:35PM +0000, Måns Rullgård wrote: > >> Russell King - ARM Linux <linux@armlinux.org.uk> writes: > >> > It would be unfair to augment the API and add the burden on everyone > >> > for the new API when 99.999% of the world doesn't require it. > >> > >> I don't think making this particular dma driver wait for the descriptor > >> callback to return before reusing a channel quite amounts to a horrid > >> hack. It certainly wouldn't burden anyone other than the poor drivers > >> for devices connected to it, all of which are specific to Sigma AFAIK. > > > > Except when you stop to think that delaying in a tasklet is exactly > > the same as randomly delaying in an interrupt handler - the tasklet > > runs on the return path back to the parent context of an interrupt > > handler. Even if you sleep in the tasklet, you're sleeping on behalf > > of the currently executing thread - if it's a RT thread, you effectively > > destroy the RT-ness of the thread. Let's hope no one cares about RT > > performance on that hardware... > > That's why I suggested to do this only if the needed delay is known to > be no more than a few bus cycles. The completion callback is currently > the only post-transfer interaction we have between the dma and device > drivers. To handle an arbitrarily long delay, some new interface will > be required. And now we're back at the point I made a few emails ago about undue burden which is just about quoted above... -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | linux.kernel
csiph-web