Re: [PATCH] [PPC32] ADMA support for PPC 440SPe processors.
From: Dan Williams <hidden>
Date: 2007-03-17 18:17:58
Also in:
linux-raid
On 3/17/07, Stefan Roese [off-list ref] wrote:
quoted hunk ↗ jump to hunk
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.