Searched hist:"0403 e3827788d878163f9ef0541b748b0f88ca5d" (Results 1 – 7 of 7) sorted by relevance
| /openbmc/linux/crypto/async_tx/ |
| H A D | async_raid6_recov.c | diff 0403e3827788d878163f9ef0541b748b0f88ca5d Tue Sep 08 19:42:50 CDT 2009 Dan Williams <dan.j.williams@intel.com> dmaengine: add fence support
Some engines optimize operation by reading ahead in the descriptor chain
such that descriptor2 may start execution before descriptor1 completes.
If descriptor2 depends on the result from descriptor1 then a fence is
required (on descriptor2) to disable this optimization. The async_tx
api could implicitly identify dependencies via the 'depend_tx'
parameter, but that would constrain cases where the dependency chain
only specifies a completion order rather than a data dependency. So,
provide an ASYNC_TX_FENCE to explicitly identify data dependencies.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
| H A D | async_memcpy.c | diff 0403e3827788d878163f9ef0541b748b0f88ca5d Tue Sep 08 19:42:50 CDT 2009 Dan Williams <dan.j.williams@intel.com> dmaengine: add fence support
Some engines optimize operation by reading ahead in the descriptor chain
such that descriptor2 may start execution before descriptor1 completes.
If descriptor2 depends on the result from descriptor1 then a fence is
required (on descriptor2) to disable this optimization. The async_tx
api could implicitly identify dependencies via the 'depend_tx'
parameter, but that would constrain cases where the dependency chain
only specifies a completion order rather than a data dependency. So,
provide an ASYNC_TX_FENCE to explicitly identify data dependencies.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
| H A D | async_pq.c | diff 0403e3827788d878163f9ef0541b748b0f88ca5d Tue Sep 08 19:42:50 CDT 2009 Dan Williams <dan.j.williams@intel.com> dmaengine: add fence support
Some engines optimize operation by reading ahead in the descriptor chain
such that descriptor2 may start execution before descriptor1 completes.
If descriptor2 depends on the result from descriptor1 then a fence is
required (on descriptor2) to disable this optimization. The async_tx
api could implicitly identify dependencies via the 'depend_tx'
parameter, but that would constrain cases where the dependency chain
only specifies a completion order rather than a data dependency. So,
provide an ASYNC_TX_FENCE to explicitly identify data dependencies.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
| H A D | async_xor.c | diff 0403e3827788d878163f9ef0541b748b0f88ca5d Tue Sep 08 19:42:50 CDT 2009 Dan Williams <dan.j.williams@intel.com> dmaengine: add fence support
Some engines optimize operation by reading ahead in the descriptor chain
such that descriptor2 may start execution before descriptor1 completes.
If descriptor2 depends on the result from descriptor1 then a fence is
required (on descriptor2) to disable this optimization. The async_tx
api could implicitly identify dependencies via the 'depend_tx'
parameter, but that would constrain cases where the dependency chain
only specifies a completion order rather than a data dependency. So,
provide an ASYNC_TX_FENCE to explicitly identify data dependencies.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
| /openbmc/linux/include/linux/ |
| H A D | async_tx.h | diff 0403e3827788d878163f9ef0541b748b0f88ca5d Tue Sep 08 19:42:50 CDT 2009 Dan Williams <dan.j.williams@intel.com> dmaengine: add fence support
Some engines optimize operation by reading ahead in the descriptor chain
such that descriptor2 may start execution before descriptor1 completes.
If descriptor2 depends on the result from descriptor1 then a fence is
required (on descriptor2) to disable this optimization. The async_tx
api could implicitly identify dependencies via the 'depend_tx'
parameter, but that would constrain cases where the dependency chain
only specifies a completion order rather than a data dependency. So,
provide an ASYNC_TX_FENCE to explicitly identify data dependencies.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
| H A D | dmaengine.h | diff 0403e3827788d878163f9ef0541b748b0f88ca5d Tue Sep 08 19:42:50 CDT 2009 Dan Williams <dan.j.williams@intel.com> dmaengine: add fence support
Some engines optimize operation by reading ahead in the descriptor chain
such that descriptor2 may start execution before descriptor1 completes.
If descriptor2 depends on the result from descriptor1 then a fence is
required (on descriptor2) to disable this optimization. The async_tx
api could implicitly identify dependencies via the 'depend_tx'
parameter, but that would constrain cases where the dependency chain
only specifies a completion order rather than a data dependency. So,
provide an ASYNC_TX_FENCE to explicitly identify data dependencies.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
| /openbmc/linux/drivers/md/ |
| H A D | raid5.c | diff 0403e3827788d878163f9ef0541b748b0f88ca5d Tue Sep 08 19:42:50 CDT 2009 Dan Williams <dan.j.williams@intel.com> dmaengine: add fence support
Some engines optimize operation by reading ahead in the descriptor chain
such that descriptor2 may start execution before descriptor1 completes.
If descriptor2 depends on the result from descriptor1 then a fence is
required (on descriptor2) to disable this optimization. The async_tx
api could implicitly identify dependencies via the 'depend_tx'
parameter, but that would constrain cases where the dependency chain
only specifies a completion order rather than a data dependency. So,
provide an ASYNC_TX_FENCE to explicitly identify data dependencies.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|