Sosnowski, Maciej wrote:
Williams, Dan J wrote:
Channel switching is problematic for some dmaengine drivers as the
architecture precludes separating the ->prep from ->submit. In these
cases the driver can select ASYNC_TX_DISABLE_CHANNEL_SWITCH to modify
the async_tx allocator to only return channels that support all of the
required asynchronous operations.
For example MD_RAID456=y selects support for asynchronous xor, xor
validate, pq, pq validate, and memcpy. When
ASYNC_TX_DISABLE_CHANNEL_SWITCH=y any channel with all these
capabilities is marked DMA_ASYNC_TX allowing async_tx_find_channel() to
quickly locate compatible channels with the guarantee that dependency
chains will remain on one channel. When
ASYNC_TX_DISABLE_CHANNEL_SWITCH=n async_tx_find_channel() may select
channels that lead to operation chains that need to cross channel
boundaries using the async_tx channel switch capability.
Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx>
---
Signed-off-by: Maciej Sosnowski <maciej.sosnowski@xxxxxxxxx>
with one question:
+ /* note: this only matters in the
+ * CONFIG_ASYNC_TX_DISABLE_CHANNEL_SWITCH=y case
+ */
+ if (device_has_all_tx_types(device))
+ dma_cap_set(DMA_ASYNC_TX, device->cap_mask);
Why not to put this part plus device_has_all_tx_types()
into #ifdef CONFIG_ASYNC_TX_DISABLE_CHANNEL_SWITCH then?
Because device_has_all_tx_types() already has the necessary ifdefs per
operation type, and it does not rule out the possibility that code
outside of async_tx can make use of DMA_ASYNC_TX capability. We don't
gain anything by eliminating this call... although we would save an
entry in the dmaengine channel table by turning off DMA_ASYNC_TX in enum
dma_transaction_type. But we have already cleaned up
dma_transaction_type in this patchset so the net change from 2.6.31 to
2.6.32 is still positive in this area.
--
Dan
--
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
