Merge branch 'ioat-md-accel-for-linus' of git://lost.foo-projects.org/~dwillia2/git/iop

* 'ioat-md-accel-for-linus' of git://lost.foo-projects.org/~dwillia2/git/iop: (28 commits)
  ioatdma: add the unisys "i/oat" pci vendor/device id
  ARM: Add drivers/dma to arch/arm/Kconfig
  iop3xx: surface the iop3xx DMA and AAU units to the iop-adma driver
  iop13xx: surface the iop13xx adma units to the iop-adma driver
  dmaengine: driver for the iop32x, iop33x, and iop13xx raid engines
  md: remove raid5 compute_block and compute_parity5
  md: handle_stripe5 - request io processing in raid5_run_ops
  md: handle_stripe5 - add request/completion logic for async expand ops
  md: handle_stripe5 - add request/completion logic for async read ops
  md: handle_stripe5 - add request/completion logic for async check ops
  md: handle_stripe5 - add request/completion logic for async compute ops
  md: handle_stripe5 - add request/completion logic for async write ops
  md: common infrastructure for running operations with raid5_run_ops
  md: raid5_run_ops - run stripe operations outside sh->lock
  raid5: replace custom debug PRINTKs with standard pr_debug
  raid5: refactor handle_stripe5 and handle_stripe6 (v3)
  async_tx: add the async_tx api
  xor: make 'xor_blocks' a library routine for use with async_tx
  dmaengine: make clients responsible for managing channels
  dmaengine: refactor dmaengine around dma_async_tx_descriptor
  ...

1 files changed, 94 insertions, 3 deletions

diff --git a/include/linux/raid/raid5.h b/include/linux/raid/raid5.h
index d8286db60b96..93678f57ccbe 100644
--- a/include/linux/raid/raid5.h
+++ b/include/linux/raid/raid5.h
@@ -116,13 +116,46 @@
  *  attach a request to an active stripe (add_stripe_bh())
  *     lockdev attach-buffer unlockdev
  *  handle a stripe (handle_stripe())
- *     lockstripe clrSTRIPE_HANDLE ... (lockdev check-buffers unlockdev) .. change-state .. record io needed unlockstripe schedule io
+ *     lockstripe clrSTRIPE_HANDLE ...
+ *              (lockdev check-buffers unlockdev) ..
+ *              change-state ..
+ *              record io/ops needed unlockstripe schedule io/ops
  *  release an active stripe (release_stripe())
  *     lockdev if (!--cnt) { if  STRIPE_HANDLE, add to handle_list else add to inactive-list } unlockdev
  *
  * The refcount counts each thread that have activated the stripe,
  * plus raid5d if it is handling it, plus one for each active request
- * on a cached buffer.
+ * on a cached buffer, and plus one if the stripe is undergoing stripe
+ * operations.
+ *
+ * Stripe operations are performed outside the stripe lock,
+ * the stripe operations are:
+ * -copying data between the stripe cache and user application buffers
+ * -computing blocks to save a disk access, or to recover a missing block
+ * -updating the parity on a write operation (reconstruct write and
+ *  read-modify-write)
+ * -checking parity correctness
+ * -running i/o to disk
+ * These operations are carried out by raid5_run_ops which uses the async_tx
+ * api to (optionally) offload operations to dedicated hardware engines.
+ * When requesting an operation handle_stripe sets the pending bit for the
+ * operation and increments the count.  raid5_run_ops is then run whenever
+ * the count is non-zero.
+ * There are some critical dependencies between the operations that prevent some
+ * from being requested while another is in flight.
+ * 1/ Parity check operations destroy the in cache version of the parity block,
+ *    so we prevent parity dependent operations like writes and compute_blocks
+ *    from starting while a check is in progress.  Some dma engines can perform
+ *    the check without damaging the parity block, in these cases the parity
+ *    block is re-marked up to date (assuming the check was successful) and is
+ *    not re-read from disk.
+ * 2/ When a write operation is requested we immediately lock the affected
+ *    blocks, and mark them as not up to date.  This causes new read requests
+ *    to be held off, as well as parity checks and compute block operations.
+ * 3/ Once a compute block operation has been requested handle_stripe treats
+ *    that block as if it is up to date.  raid5_run_ops guaruntees that any
+ *    operation that is dependent on the compute block result is initiated after
+ *    the compute block completes.
  */
 
 struct stripe_head {
@@ -136,15 +169,46 @@ struct stripe_head {
         spinlock_t              lock;
         int                     bm_seq; /* sequence number for bitmap flushes */
         int                     disks;                  /* disks in stripe */
+        /* stripe_operations
+         * @pending - pending ops flags (set for request->issue->complete)
+         * @ack - submitted ops flags (set for issue->complete)
+         * @complete - completed ops flags (set for complete)
+         * @target - STRIPE_OP_COMPUTE_BLK target
+         * @count - raid5_runs_ops is set to run when this is non-zero
+         */
+        struct stripe_operations {
+                unsigned long      pending;
+                unsigned long      ack;
+                unsigned long      complete;
+                int                target;
+                int                count;
+                u32                zero_sum_result;
+        } ops;
         struct r5dev {
                 struct bio      req;
                 struct bio_vec  vec;
                 struct page     *page;
-                struct bio      *toread, *towrite, *written;
+                struct bio      *toread, *read, *towrite, *written;
                 sector_t        sector;                 /* sector of this page */
                 unsigned long   flags;
         } dev[1]; /* allocated with extra space depending of RAID geometry */
 };
+
+/* stripe_head_state - collects and tracks the dynamic state of a stripe_head
+ *     for handle_stripe.  It is only valid under spin_lock(sh->lock);
+ */
+struct stripe_head_state {
+        int syncing, expanding, expanded;
+        int locked, uptodate, to_read, to_write, failed, written;
+        int to_fill, compute, req_compute, non_overwrite;
+        int failed_num;
+};
+
+/* r6_state - extra state data only relevant to r6 */
+struct r6_state {
+        int p_failed, q_failed, qd_idx, failed_num[2];
+};
+
 /* Flags */
 #define R5_UPTODATE     0       /* page contains current data */
 #define R5_LOCKED       1       /* IO has been submitted on "req" */
@@ -158,6 +222,15 @@ struct stripe_head {
 #define R5_ReWrite      9       /* have tried to over-write the readerror */
 
 #define R5_Expanded     10      /* This block now has post-expand data */
+#define R5_Wantcompute  11 /* compute_block in progress treat as
+                                    * uptodate
+                                    */
+#define R5_Wantfill     12 /* dev->toread contains a bio that needs
+                                    * filling
+                                    */
+#define R5_Wantprexor   13 /* distinguish blocks ready for rmw from
+                                    * other "towrites"
+                                    */
 /*
  * Write method
  */
@@ -180,6 +253,24 @@ struct stripe_head {
 #define STRIPE_EXPAND_SOURCE    10
 #define STRIPE_EXPAND_READY     11
 /*
+ * Operations flags (in issue order)
+ */
+#define STRIPE_OP_BIOFILL       0
+#define STRIPE_OP_COMPUTE_BLK   1
+#define STRIPE_OP_PREXOR        2
+#define STRIPE_OP_BIODRAIN      3
+#define STRIPE_OP_POSTXOR       4
+#define STRIPE_OP_CHECK 5
+#define STRIPE_OP_IO            6
+
+/* modifiers to the base operations
+ * STRIPE_OP_MOD_REPAIR_PD - compute the parity block and write it back
+ * STRIPE_OP_MOD_DMA_CHECK - parity is not corrupted by the check
+ */
+#define STRIPE_OP_MOD_REPAIR_PD 7
+#define STRIPE_OP_MOD_DMA_CHECK 8
+
+/*
  * Plugging:
  *
  * To improve write throughput, we need to delay the handling of some