On 3/17/07, Stefan Roese <sr@xxxxxxx> wrote:
Dan,
I just noticed that your patch "dmaengine: add the async_tx api":
@@ -22,6 +22,17 @@ config NET_DMA
Since this is the main user of the DMA engine, it should be enabled;
say Y here.
+config ASYNC_TX_DMA
+ tristate "Asynchronous Bulk Memory Transfers/Transforms API"
+ default y
+ ---help---
+ This enables the async_tx management layer for dma engines.
+ Subsystems coded to this API will use offload engines for bulk
+ memory operations where present. Software implementations are
+ called when a dma engine is not present or fails to allocate
+ memory to carry out the transaction.
+ Current subsystems ported to async_tx: MD_RAID4,5
+
adds ASYNC_TX_DMA unconditionally to _all_ platforms. You might what to bundle
this with something like DMA_ENGINE.
Yes, defaulting to 'y' is not necessary, but ASYNC_TX_DMA=y &&
DMA_ENGINE=n is an explicit feature of the interface. When DMA_ENGINE
is not selected all the asynchronous paths in the API are compiled
out. This allows subsytems, like md-raid5, to be written in an
asynchronous fashion without regard for the architecture[1] or
availability of offload engines.
Best regards,
Stefan
Regards,
Dan
[1] The API implicitly handles channel switching depending on the
offload engine architecture. Where an iop13xx engine can handle a
copy+xor sequence on one channel, a 440sp or iop3xx platform will need
to switch between copy and xor capable engines. Resolving operation
dependencies and channel switching is handled behind the scenes.
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
