Hi Laurent, On 02-03-20, 09:37, Laurent Pinchart wrote: > > I would be more comfortable in calling an API to do so :) > > The flow I am thinking is: > > > > - prep cyclic1 txn > > - submit cyclic1 txn > > - call issue_pending() (cyclic one starts) > > > > - prep cyclic2 txn > > - submit cyclic2 txn > > - signal_cyclic1_txn aka terminate_cookie() > > - cyclic1 completes, switch to cyclic2 (dmaengine driver) > > - get callback for cyclic1 (optional) > > > > To check if hw supports terminate_cookie() or not we can check if the > > callback support is implemented > > Two questions though: > > - Where is .issue_pending() called for cyclic2 in your above sequence ? > Surely it should be called somewhere, as the DMA engine API requires > .issue_pending() to be called for a transfer to be executed, otherwise > it stays in the submitted but not pending queue. Sorry missed that one, I would do that after submit cyclic2 txn step and then signal signal_cyclic1_txn termination > - With the introduction of a new .terminate_cookie() operation, we need > to specify that operation for all transfer types. What's its Correct > envisioned semantics for non-cyclic transfers ? And how do DMA engine > drivers report that they support .terminate_cookie() for cyclic > transfers but not for other transfer types (the counterpart of > reporting, in my proposition, that .issue_pending() isn't supported > replace the current cyclic transfer) ? Typically for dmaengine controller cyclic is *not* a special mode, only change is that a list provided to controller is circular. So, the .terminate_cookie() should be a feature for all type of txn's. If for some reason (dont discount what hw designers can do) a controller supports this for some specific type(s), then they should return -ENOTSUPP for cookies that do not support and let the caller know. -- ~Vinod
