RE: [PATCH 2/4] async_tx: kill tx_set_src and tx_set_dest methods
From: Sosnowski, Maciej
Date: Mon Jan 07 2008 - 11:59:13 EST
>From: Williams, Dan J
>
>The tx_set_src and tx_set_dest methods were originally
>implemented to allow
>an array of addresses to be passed down from async_xor to the dmaengine
>driver while minimizing stack overhead. Removing these methods allows
>drivers to have all transaction parameters available at 'prep'
>time, saves
>two function pointers in struct dma_async_tx_descriptor, and
>reduces the
>number of indirect branches..
>
>A consequence of moving this data to the 'prep' routine is that
>multi-source routines like async_xor need temporary storage to
>convert an
>array of linear addresses into an array of dma addresses. In
>order to keep
>the same stack footprint of the previous implementation the
>input array is
>reused as storage for the dma addresses. This requires that
>sizeof(dma_addr_t) be less than or equal to sizeof(void *). As a
>consequence CONFIG_DMADEVICES now depends on
>!CONFIG_HIGHMEM64G. It also
>requires that drivers be able to make descriptor resources
>available when
>the 'prep' routine is polled.
>
>Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx>
>---
>From ioat_dma point of view this change just makes life easier as it
simplifies dma_async_tx_descriptor - it looks ok.
Maciej Sosnowski
---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
z siedziba w Gdansku
ul. Slowackiego 173
80-298 Gdansk
Sad Rejonowy Gdansk Polnoc w Gdansku,
VII Wydzial Gospodarczy Krajowego Rejestru Sadowego,
numer KRS 101882
NIP 957-07-52-316
Kapital zakladowy 200.000 zl
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/