Hi Vinod,
On 2017-03-02 06:10, Vinod Koul wrote:
On Fri, Feb 24, 2017 at 09:37:40PM +0100, Lars-Peter Clausen wrote:
On 02/24/2017 06:38 PM, Dave Jiang wrote:
On 02/24/2017 10:27 AM, Lars-Peter Clausen wrote:
On 02/24/2017 06:19 PM, Dave Jiang wrote:
On 02/23/2017 05:41 PM, Dan Williams wrote:
On Thu, Feb 23, 2017 at 4:13 PM, Vinod Koul <vinod.koul@xxxxxxxxx> wrote:
There have been discussions on need for change of dmaengine API for
a) allow sleepy invocation of the prepare descriptor so that drivers can
do the runtime pm (maybe move into core as well)
b) split the prepare operation to allocate and new prepare methods
I'm wondering if you should you go even further and move to a more
idiomatic model where a generic request is prepared outside the driver
and passed in, rather than the current situation of requiring the
driver to wrap a dma_async_tx_descriptor inside it's internal command
structure.
I wonder if we should support allowing proper batching of requests
before submission in the framework. Certain consumers of the DMA driver
can take advantage of that to improve performance.
Some drivers already do this and the API allows this. issue_pending() is the
operation that starts the transfer. So when a descriptor is submitted and
there are already other descriptors pending it is OK to batch those
descriptors together into one hardware-linked descriptor chain.
Right, a lot of the mechanism is in the driver. And the prep call leaves
the submission lock held does it not? That prevents more prep calls
being invoked.
That's not an issue, what you do is:
prep()
submit()
prep()
submit()
...
prep()
submit()
issue_pending()
All the descriptors submitted up to the issue_pending() can be batch into
one hardware-linked list of descriptors.
Yes but then should this be handled in drivers or moved to framework, I am
thinking latter :)
Just a naive question: is there any plan and volunteer for that work? (after
KS meeting and discussion).
I hope that this is not just a rough direction and if I need to have runtime
pm issues solved, I need to do all that works first...
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
