lkml.org 
[lkml]   [2016]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Tearing down DMA transfer setup after DMA client has finished
    Date
    Sebastian Frias <sf84@laposte.net> writes:

    > On 09/12/16 07:59, Vinod Koul wrote:
    >> On Thu, Dec 08, 2016 at 04:48:18PM +0000, Måns Rullgård wrote:
    >>> Vinod Koul <vinod.koul@intel.com> writes:
    >>>
    >>>> To make it efficient, disregarding your Sbox HW issue, the solution is
    >>>> virtual channels. You can delink physical channels and virtual channels. If
    >>>> one has SW controlled MUX then a channel can service any client. For few
    >>>> controllers request lines are hard wired so they cant use any channel. But
    >>>> if you dont have this restriction then driver can queue up many transactions
    >>>> from different controllers.
    >>>
    >>> Have you been paying attention at all? This exactly what the driver
    >>> ALREADY DOES.
    >>
    >> And have you read what the question was?

    I wrote the driver. I think I know what Mason and I are asking.

    > I think many people appreciate the quick turn around time and
    > responsiveness of knowledgeable people making constructive remarks in
    > this thread, but it looks we are slowly drifting away from the main
    > problem.
    >
    > If we had to sum up the discussion, the current DMA API/framework in
    > Linux seems to lack a way to properly handle this HW (or if it has a
    > way, the information got lost somewhere).
    >
    > What concrete solution do you propose?
    >
    > Alternatively, one can think of the current issue (i.e.: the fact that
    > the IRQ arrives "too soon") in a different way. Instead of thinking
    > the IRQ indicates "transfer complete", it is indicating "ready to
    > accept another command", which in practice (and with proper API
    > support) can translate into efficient queuing of DMA operations.

    For multiple back to back transfers to the same peripheral, it is indeed
    a slight optimisation. What's apparently lacking is some way of doing a
    full flush

    --
    Måns Rullgård

    \
     
     \ /
      Last update: 2016-12-09 12:35    [W:4.233 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site