1. 16 7月, 2007 10 次提交
    • D
      [SPARC64]: Initial LDOM cpu hotplug support. · 4f0234f4
      David S. Miller 提交于
      Only adding cpus is supports at the moment, removal
      will come next.
      
      When new cpus are configured, the machine description is
      updated.  When we get the configure request we pass in a
      cpu mask of to-be-added cpus to the mdesc CPU node parser
      so it only fetches information for those cpus.  That code
      also proceeds to update the SMT/multi-core scheduling bitmaps.
      
      cpu_up() does all the work and we return the status back
      over the DS channel.
      
      CPUs via dr-cpu need to be booted straight out of the
      hypervisor, and this requires:
      
      1) A new trampoline mechanism.  CPUs are booted straight
         out of the hypervisor with MMU disabled and running in
         physical addresses with no mappings installed in the TLB.
      
         The new hvtramp.S code sets up the critical cpu state,
         installs the locked TLB mappings for the kernel, and
         turns the MMU on.  It then proceeds to follow the logic
         of the existing trampoline.S SMP cpu bringup code.
      
      2) All calls into OBP have to be disallowed when domaining
         is enabled.  Since cpus boot straight into the kernel from
         the hypervisor, OBP has no state about that cpu and therefore
         cannot handle being invoked on that cpu.
      
         Luckily it's only a handful of interfaces which can be called
         after the OBP device tree is obtained.  For example, rebooting,
         halting, powering-off, and setting options node variables.
      
      CPU removal support will require some infrastructure changes
      here.  Namely we'll have to process the requests via a true
      kernel thread instead of in a workqueue.  workqueues run on
      a per-cpu thread, but when unconfiguring we might need to
      force the thread to execute on another cpu if the current cpu
      is the one being removed.  Removal of a cpu also causes the kernel
      to destroy that cpu's workqueue running thread.
      
      Another issue on removal is that we may have interrupts still
      pointing to the cpu-to-be-removed.  So new code will be needed
      to walk the active INO list and retarget those cpus as-needed.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f0234f4
    • D
      [SPARC64]: Fix setting of variables in LDOM guest. · b3e13fbe
      David S. Miller 提交于
      There is a special domain services capability for setting
      variables in the OBP options node.  Guests don't have permanent
      store for the OBP variables like a normal system, so they are
      instead maintained in the LDOM control node or in the SC.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b3e13fbe
    • D
      [SPARC64]: Fix MD property lifetime bugs. · 83292e0a
      David S. Miller 提交于
      Property values cannot be referenced outside of
      mdesc_grab()/mdesc_release() pairs.  The only major
      offender was the VIO bus layer, easily fixed.
      
      Add some commentary to mdesc.h describing these rules.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83292e0a
    • D
      [SPARC64]: Abstract out mdesc accesses for better MD update handling. · 43fdf274
      David S. Miller 提交于
      Since we have to be able to handle MD updates, having an in-tree
      set of data structures representing the MD objects actually makes
      things more painful.
      
      The MD itself is easy to parse, and we can implement the existing
      interfaces using direct parsing of the MD binary image.
      
      The MD is now reference counted, so accesses have to now take the
      form:
      
      	handle = mdesc_grab();
      
      	... operations on MD ...
      
      	mdesc_release(handle);
      
      The only remaining issue are cases where code holds on to references
      to MD property values.  mdesc_get_property() returns a direct pointer
      to the property value, most cases just pull in the information they
      need and discard the pointer, but there are few that use the pointer
      directly over a long lifetime.  Those will be fixed up in a subsequent
      changeset.
      
      A preliminary handler for MD update events from domain services is
      there, it is rudimentry but it works and handles all of the reference
      counting.  It does not check the generation number of the MDs,
      and it does not generate a "add/delete" list for notification to
      interesting parties about MD changes but that will be forthcoming.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      43fdf274
    • D
      [SPARC64]: Use more mearningful names for IRQ registry. · 133f09a1
      David S. Miller 提交于
      All of the interrupts say "LDX RX" and "LDX TX" currently
      which is next to useless.  Put a device specific prefix
      before "RX" and "TX" instead which makes it much more
      useful.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      133f09a1
    • D
      [SPARC64]: Export powerd facilities for external entities. · 13077d80
      David S. Miller 提交于
      Besides the existing usage for power-button interrupts, we'll
      want to make use of this code for domain-services where the
      LDOM manager can send reboot requests to the guest node.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      13077d80
    • D
      [SPARC64]: Assorted LDC bug cures. · cb481235
      David S. Miller 提交于
      1) LDC_MODE_RELIABLE is deprecated an unused by anything, plus
         it and LDC_MODE_STREAM were mis-numbered.
      
      2) read_stream() should try to read as much as possible into
         the per-LDC stream buffer area, so do not trim the read_nonraw()
         length by the caller's size parameter.
      
      3) Send data ACKs when necessary in read_nonraw().
      
      4) In read_nonraw() when we get a pure ACK, advance the RX head
         unconditionally past it.
      
      5) Provide the ACKID field in the ldcdgb() packet dump in read_nonraw().
         This helps debugging stream mode LDC channel problems.
      
      6) Decrease verbosity of rx_data_wait() so that it is more useful.
         A debugging message each loop iteration is too much.
      
      7) In process_data_ack() stop the loop checking when we hit lp->tx_tail
         not lp->tx_head.
      
      8) Set the seqid field properly in send_data_nack().
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cb481235
    • D
      [SPARC64]: Add LDOM virtual channel driver and VIO device layer. · e53e97ce
      David S. Miller 提交于
      Virtual devices on Sun Logical Domains are built on top
      of a virtual channel framework.  This, with help of hypervisor
      interfaces, provides a link layer protocol with basic
      handshaking over which virtual device clients and servers
      communicate.
      
      Built on top of this is a VIO device protocol which has it's
      own handshaking and message types.  At this layer attributes
      are exchanged (disk size, network device addresses, etc.)
      descriptor rings are registered, and data transfers are
      triggers and replied to.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e53e97ce
    • A
      frv: missing __clear_user() · b4a06918
      Al Viro 提交于
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b4a06918
    • A
      fix return type of skb_checksum_complete() · 4381ca3c
      Al Viro 提交于
      It returns __sum16, not unsigned int
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4381ca3c
  2. 15 7月, 2007 16 次提交
  3. 14 7月, 2007 3 次提交
  4. 13 7月, 2007 11 次提交
    • D
      ioatdma: add the unisys "i/oat" pci vendor/device id · 3039f073
      Dan Williams 提交于
      Cc: John Magolan <john.magolan@unisys.com>
      Signed-off-by: NShannon Nelson <shannon.nelson@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      3039f073
    • D
      iop3xx: surface the iop3xx DMA and AAU units to the iop-adma driver · 2492c845
      Dan Williams 提交于
      Adds the platform device definitions and the architecture specific support
      routines (i.e. register initialization and descriptor formats) for the
      iop-adma driver.
      
      Changelog:
      * add support for > 1k zero sum buffer sizes
      * added dma/aau platform devices to iq80321 and iq80332 setup
      * fixed the calculation in iop_desc_is_aligned
      * support xor buffer sizes larger than 16MB
      * fix places where software descriptors are assumed to be contiguous, only
        hardware descriptors are contiguous for up to a PAGE_SIZE buffer size
      * convert to async_tx
      * add interrupt support
      * add platform devices for 80219 boards
      * do not call platform register macros in driver code
      * remove switch() statements for compatible register offsets/layouts
      * change over to bitmap based capabilities
      * remove unnecessary ARM assembly statement
      * checkpatch.pl fixes
      * gpl v2 only correction
      * phys move to dma_async_tx_descriptor
      
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      2492c845
    • D
      iop13xx: surface the iop13xx adma units to the iop-adma driver · 39a8d7d1
      Dan Williams 提交于
      Adds the platform device definitions and the architecture specific
      support routines (i.e. register initialization and descriptor formats) for the
      iop-adma driver.
      
      Changelog:
      * added 'descriptor pool size' to the platform data
      * add base support for buffer sizes larger than 16MB (hw max)
      * build error fix from Kirill A. Shutemov
      * rebase for async_tx changes
      * add interrupt support
      * do not call platform register macros in driver code
      * remove unnecessary ARM assembly statement
      * checkpatch.pl fixes
      * gpl v2 only correction
      
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      39a8d7d1
    • D
      dmaengine: driver for the iop32x, iop33x, and iop13xx raid engines · c2110923
      Dan Williams 提交于
      The Intel(R) IOP series of i/o processors integrate an Xscale core with
      raid acceleration engines.  The capabilities per platform are:
      
      iop219:
       (2) copy engines
      iop321:
       (2) copy engines
       (1) xor and block fill engine
      iop33x:
       (2) copy and crc32c engines
       (1) xor, xor zero sum, pq, pq zero sum, and block fill engine
      iop34x (iop13xx):
       (2) copy, crc32c, xor, xor zero sum, and block fill engines
       (1) copy, crc32c, xor, xor zero sum, pq, pq zero sum, and block fill engine
      
      The driver supports the features of the async_tx api:
      * asynchronous notification of operation completion
      * implicit (interupt triggered) handling of inter-channel transaction
        dependencies
      
      The driver adapts to the platform it is running by two methods.
      1/ #include <asm/arch/adma.h> which defines the hardware specific
         iop_chan_* and iop_desc_* routines as a series of static inline
         functions
      2/ The private platform data attached to the platform_device defines the
         capabilities of the channels
      
      20070626: Callbacks are run in a tasklet.  Given the recent discussion on
      LKML about killing tasklets in favor of workqueues I did a quick conversion
      of the driver.  Raid5 resync performance dropped from 50MB/s to 30MB/s, so
      the tasklet implementation remains until a generic softirq interface is
      available.
      
      Changelog:
      * fixed a slot allocation bug in do_iop13xx_adma_xor that caused too few
      slots to be requested eventually leading to data corruption
      * enabled the slot allocation routine to attempt to free slots before
      returning -ENOMEM
      * switched the cleanup routine to solely use the software chain and the
      status register to determine if a descriptor is complete.  This is
      necessary to support other IOP engines that do not have status writeback
      capability
      * make the driver iop generic
      * modified the allocation routines to understand allocating a group of
      slots for a single operation
      * added a null xor initialization operation for the xor only channel on
      iop3xx
      * support xor operations on buffers larger than the hardware maximum
      * split the do_* routines into separate prep, src/dest set, submit stages
      * added async_tx support (dependent operations initiation at cleanup time)
      * simplified group handling
      * added interrupt support (callbacks via tasklets)
      * brought the pending depth inline with ioat (i.e. 4 descriptors)
      * drop dma mapping methods, suggested by Chris Leech
      * don't use inline in C files, Adrian Bunk
      * remove static tasklet declarations
      * make iop_adma_alloc_slots easier to read and remove chances for a
        corrupted descriptor chain
      * fix locking bug in iop_adma_alloc_chan_resources, Benjamin Herrenschmidt
      * convert capabilities over to dma_cap_mask_t
      * fixup sparse warnings
      * add descriptor flush before iop_chan_enable
      * checkpatch.pl fixes
      * gpl v2 only correction
      * move set_src, set_dest, submit to async_tx methods
      * move group_list and phys to async_tx
      
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      c2110923
    • D
      md: handle_stripe5 - add request/completion logic for async read ops · b5e98d65
      Dan Williams 提交于
      When a read bio is attached to the stripe and the corresponding block is
      marked R5_UPTODATE, then a read (biofill) operation is scheduled to copy
      the data from the stripe cache to the bio buffer.  handle_stripe flags the
      blocks to be operated on with the R5_Wantfill flag.  If new read requests
      arrive while raid5_run_ops is running they will not be handled until
      handle_stripe is scheduled to run again.
      
      Changelog:
      * cleanup to_read and to_fill accounting
      * do not fail reads that have reached the cache
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Acked-By: NNeilBrown <neilb@suse.de>
      b5e98d65
    • D
      md: handle_stripe5 - add request/completion logic for async compute ops · f38e1219
      Dan Williams 提交于
      handle_stripe will compute a block when a backing disk has failed, or when
      it determines it can save a disk read by computing the block from all the
      other up-to-date blocks.
      
      Previously a block would be computed under the lock and subsequent logic in
      handle_stripe could use the newly up-to-date block.  With the raid5_run_ops
      implementation the compute operation is carried out a later time outside
      the lock.  To preserve the old functionality we take advantage of the
      dependency chain feature of async_tx to flag the block as R5_Wantcompute
      and then let other parts of handle_stripe operate on the block as if it
      were up-to-date.  raid5_run_ops guarantees that the block will be ready
      before it is used in another operation.
      
      However, this only works in cases where the compute and the dependent
      operation are scheduled at the same time.  If a previous call to
      handle_stripe sets the R5_Wantcompute flag there is no facility to pass the
      async_tx dependency chain across successive calls to raid5_run_ops.  The
      req_compute variable protects against this case.
      
      Changelog:
      * remove the req_compute BUG_ON
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Acked-By: NNeilBrown <neilb@suse.de>
      f38e1219
    • D
      md: raid5_run_ops - run stripe operations outside sh->lock · 91c00924
      Dan Williams 提交于
      When the raid acceleration work was proposed, Neil laid out the following
      attack plan:
      
      1/ move the xor and copy operations outside spin_lock(&sh->lock)
      2/ find/implement an asynchronous offload api
      
      The raid5_run_ops routine uses the asynchronous offload api (async_tx) and
      the stripe_operations member of a stripe_head to carry out xor+copy
      operations asynchronously, outside the lock.
      
      To perform operations outside the lock a new set of state flags is needed
      to track new requests, in-flight requests, and completed requests.  In this
      new model handle_stripe is tasked with scanning the stripe_head for work,
      updating the stripe_operations structure, and finally dropping the lock and
      calling raid5_run_ops for processing.  The following flags outline the
      requests that handle_stripe can make of raid5_run_ops:
      
      STRIPE_OP_BIOFILL
       - copy data into request buffers to satisfy a read request
      STRIPE_OP_COMPUTE_BLK
       - generate a missing block in the cache from the other blocks
      STRIPE_OP_PREXOR
       - subtract existing data as part of the read-modify-write process
      STRIPE_OP_BIODRAIN
       - copy data out of request buffers to satisfy a write request
      STRIPE_OP_POSTXOR
       - recalculate parity for new data that has entered the cache
      STRIPE_OP_CHECK
       - verify that the parity is correct
      STRIPE_OP_IO
       - submit i/o to the member disks (note this was already performed outside
         the stripe lock, but it made sense to add it as an operation type
      
      The flow is:
      1/ handle_stripe sets STRIPE_OP_* in sh->ops.pending
      2/ raid5_run_ops reads sh->ops.pending, sets sh->ops.ack, and submits the
         operation to the async_tx api
      3/ async_tx triggers the completion callback routine to set
         sh->ops.complete and release the stripe
      4/ handle_stripe runs again to finish the operation and optionally submit
         new operations that were previously blocked
      
      Note this patch just defines raid5_run_ops, subsequent commits (one per
      major operation type) modify handle_stripe to take advantage of this
      routine.
      
      Changelog:
      * removed ops_complete_biodrain in favor of ops_complete_postxor and
        ops_complete_write.
      * removed the raid5_run_ops workqueue
      * call bi_end_io for reads in ops_complete_biofill, saves a call to
        handle_stripe
      * explicitly handle the 2-disk raid5 case (xor becomes memcpy), Neil Brown
      * fix race between async engines and bi_end_io call for reads, Neil Brown
      * remove unnecessary spin_lock from ops_complete_biofill
      * remove test_and_set/test_and_clear BUG_ONs, Neil Brown
      * remove explicit interrupt handling for channel switching, this feature
        was absorbed (i.e. it is now implicit) by the async_tx api
      * use return_io in ops_complete_biofill
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Acked-By: NNeilBrown <neilb@suse.de>
      91c00924
    • D
      raid5: refactor handle_stripe5 and handle_stripe6 (v3) · a4456856
      Dan Williams 提交于
      handle_stripe5 and handle_stripe6 have very deep logic paths handling the
      various states of a stripe_head.  By introducing the 'stripe_head_state'
      and 'r6_state' objects, large portions of the logic can be moved to
      sub-routines.
      
      'struct stripe_head_state' consumes all of the automatic variables that previously
      stood alone in handle_stripe5,6.  'struct r6_state' contains the handle_stripe6
      specific variables like p_failed and q_failed.
      
      One of the nice side effects of the 'stripe_head_state' change is that it
      allows for further reductions in code duplication between raid5 and raid6.
      The following new routines are shared between raid5 and raid6:
      
      	handle_completed_write_requests
      	handle_requests_to_failed_array
      	handle_stripe_expansion
      
      Changes:
      * v2: fixed 'conf->raid_disk-1' for the raid6 'handle_stripe_expansion' path
      * v3: removed the unused 'dirty' field from struct stripe_head_state
      * v3: coalesced open coded bi_end_io routines into return_io()
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Acked-By: NNeilBrown <neilb@suse.de>
      a4456856
    • D
      async_tx: add the async_tx api · 9bc89cd8
      Dan Williams 提交于
      The async_tx api provides methods for describing a chain of asynchronous
      bulk memory transfers/transforms with support for inter-transactional
      dependencies.  It is implemented as a dmaengine client that smooths over
      the details of different hardware offload engine implementations.  Code
      that is written to the api can optimize for asynchronous operation and the
      api will fit the chain of operations to the available offload resources. 
       
      	I imagine that any piece of ADMA hardware would register with the
      	'async_*' subsystem, and a call to async_X would be routed as
      	appropriate, or be run in-line. - Neil Brown
      
      async_tx exploits the capabilities of struct dma_async_tx_descriptor to
      provide an api of the following general format:
      
      struct dma_async_tx_descriptor *
      async_<operation>(..., struct dma_async_tx_descriptor *depend_tx,
      			dma_async_tx_callback cb_fn, void *cb_param)
      {
      	struct dma_chan *chan = async_tx_find_channel(depend_tx, <operation>);
      	struct dma_device *device = chan ? chan->device : NULL;
      	int int_en = cb_fn ? 1 : 0;
      	struct dma_async_tx_descriptor *tx = device ?
      		device->device_prep_dma_<operation>(chan, len, int_en) : NULL;
      
      	if (tx) { /* run <operation> asynchronously */
      		...
      		tx->tx_set_dest(addr, tx, index);
      		...
      		tx->tx_set_src(addr, tx, index);
      		...
      		async_tx_submit(chan, tx, flags, depend_tx, cb_fn, cb_param);
      	} else { /* run <operation> synchronously */
      		...
      		<operation>
      		...
      		async_tx_sync_epilog(flags, depend_tx, cb_fn, cb_param);
      	}
      
      	return tx;
      }
      
      async_tx_find_channel() returns a capable channel from its pool.  The
      channel pool is organized as a per-cpu array of channel pointers.  The
      async_tx_rebalance() routine is tasked with managing these arrays.  In the
      uniprocessor case async_tx_rebalance() tries to spread responsibility
      evenly over channels of similar capabilities.  For example if there are two
      copy+xor channels, one will handle copy operations and the other will
      handle xor.  In the SMP case async_tx_rebalance() attempts to spread the
      operations evenly over the cpus, e.g. cpu0 gets copy channel0 and xor
      channel0 while cpu1 gets copy channel 1 and xor channel 1.  When a
      dependency is specified async_tx_find_channel defaults to keeping the
      operation on the same channel.  A xor->copy->xor chain will stay on one
      channel if it supports both operation types, otherwise the transaction will
      transition between a copy and a xor resource.
      
      Currently the raid5 implementation in the MD raid456 driver has been
      converted to the async_tx api.  A driver for the offload engines on the
      Intel Xscale series of I/O processors, iop-adma, is provided in a later
      commit.  With the iop-adma driver and async_tx, raid456 is able to offload
      copy, xor, and xor-zero-sum operations to hardware engines.
       
      On iop342 tiobench showed higher throughput for sequential writes (20 - 30%
      improvement) and sequential reads to a degraded array (40 - 55%
      improvement).  For the other cases performance was roughly equal, +/- a few
      percentage points.  On a x86-smp platform the performance of the async_tx
      implementation (in synchronous mode) was also +/- a few percentage points
      of the original implementation.  According to 'top' on iop342 CPU
      utilization drops from ~50% to ~15% during a 'resync' while the speed
      according to /proc/mdstat doubles from ~25 MB/s to ~50 MB/s.
       
      The tiobench command line used for testing was: tiobench --size 2048
      --block 4096 --block 131072 --dir /mnt/raid --numruns 5
      * iop342 had 1GB of memory available
      
      Details:
      * if CONFIG_DMA_ENGINE=n the asynchronous path is compiled away by making
        async_tx_find_channel a static inline routine that always returns NULL
      * when a callback is specified for a given transaction an interrupt will
        fire at operation completion time and the callback will occur in a
        tasklet.  if the the channel does not support interrupts then a live
        polling wait will be performed
      * the api is written as a dmaengine client that requests all available
        channels
      * In support of dependencies the api implicitly schedules channel-switch
        interrupts.  The interrupt triggers the cleanup tasklet which causes
        pending operations to be scheduled on the next channel
      * Xor engines treat an xor destination address differently than a software
        xor routine.  To the software routine the destination address is an implied
        source, whereas engines treat it as a write-only destination.  This patch
        modifies the xor_blocks routine to take a an explicit destination address
        to mirror the hardware.
      
      Changelog:
      * fixed a leftover debug print
      * don't allow callbacks in async_interrupt_cond
      * fixed xor_block changes
      * fixed usage of ASYNC_TX_XOR_DROP_DEST
      * drop dma mapping methods, suggested by Chris Leech
      * printk warning fixups from Andrew Morton
      * don't use inline in C files, Adrian Bunk
      * select the API when MD is enabled
      * BUG_ON xor source counts <= 1
      * implicitly handle hardware concerns like channel switching and
        interrupts, Neil Brown
      * remove the per operation type list, and distribute operation capabilities
        evenly amongst the available channels
      * simplify async_tx_find_channel to optimize the fast path
      * introduce the channel_table_initialized flag to prevent early calls to
        the api
      * reorganize the code to mimic crypto
      * include mm.h as not all archs include it in dma-mapping.h
      * make the Kconfig options non-user visible, Adrian Bunk
      * move async_tx under crypto since it is meant as 'core' functionality, and
        the two may share algorithms in the future
      * move large inline functions into c files
      * checkpatch.pl fixes
      * gpl v2 only correction
      
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Acked-By: NNeilBrown <neilb@suse.de>
      9bc89cd8
    • D
      xor: make 'xor_blocks' a library routine for use with async_tx · 685784aa
      Dan Williams 提交于
      The async_tx api tries to use a dma engine for an operation, but will fall
      back to an optimized software routine otherwise.  Xor support is
      implemented using the raid5 xor routines.  For organizational purposes this
      routine is moved to a common area.
      
      The following fixes are also made:
      * rename xor_block => xor_blocks, suggested by Adrian Bunk
      * ensure that xor.o initializes before md.o in the built-in case
      * checkpatch.pl fixes
      * mark calibrate_xor_blocks __init, Adrian Bunk
      
      Cc: Adrian Bunk <bunk@stusta.de>
      Cc: NeilBrown <neilb@suse.de>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      685784aa
    • D
      dmaengine: make clients responsible for managing channels · d379b01e
      Dan Williams 提交于
      The current implementation assumes that a channel will only be used by one
      client at a time.  In order to enable channel sharing the dmaengine core is
      changed to a model where clients subscribe to channel-available-events.
      Instead of tracking how many channels a client wants and how many it has
      received the core just broadcasts the available channels and lets the
      clients optionally take a reference.  The core learns about the clients'
      needs at dma_event_callback time.
      
      In support of multiple operation types, clients can specify a capability
      mask to only be notified of channels that satisfy a certain set of
      capabilities.
      
      Changelog:
      * removed DMA_TX_ARRAY_INIT, no longer needed
      * dma_client_chan_free -> dma_chan_release: switch to global reference
        counting only at device unregistration time, before it was also happening
        at client unregistration time
      * clients now return dma_state_client to dmaengine (ack, dup, nak)
      * checkpatch.pl fixes
      * fixup merge with git-ioat
      
      Cc: Chris Leech <christopher.leech@intel.com>
      Signed-off-by: NShannon Nelson <shannon.nelson@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      d379b01e