Messages in this thread | | | Subject | RE: 2.6.22-rc1-mm1 - s390 vs. md | Date | Fri, 18 May 2007 09:30:09 -0700 | From | "Williams, Dan J" <> |
| |
> From: Cornelia Huck [mailto:cornelia.huck@de.ibm.com] > Finer granularity is certainly better here, but I'm not quite sure if > this solves our s390 problem (we don't have dma support). All those > backends should also have a non-dma version...
In fact that is already there. Here is the form of async_memcpy for example: ... async_memcpy( ... ) { struct dma_chan *chan = async_tx_find_channel(depend_tx, DMA_MEMCPY); struct dma_device *device = chan ? chan->device : NULL; int int_en = callback ? 1 : 0; struct dma_async_tx_descriptor *tx = device ? device->device_prep_dma_memcpy(chan, len, int_en) : NULL;
if (tx) { /* run the memcpy asynchronously */
...
} else { /* run the memcpy synchronously */
... } }
When CONFIG_DMA_ENGINE=n async_tx_find_channel takes the form: ... async_tx_find_channel( ... ) { return NULL; }
So in the S390 case the entire asynchronous path will be compiled away.
-- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |