1. 18 4月, 2009 5 次提交
    • S
      USB: musb: fix isochronous TXDMA (take 2) · 6b6e9710
      Sergei Shtylyov 提交于
      Multi-frame isochronous TX URBs transfers in DMA mode never
      complete with CPPI DMA because musb_host_tx() doesn't restart
      DMA on the second frame, only emitting a debug message.
      With Inventra DMA they complete, but in PIO mode.  To fix:
      
       - Factor out programming of the DMA transfer from
         musb_ep_program() into musb_tx_dma_program();
      
       - Reorder the code at the end of musb_host_tx() to
         facilitate the fallback to PIO iff DMA fails;
      
       - Handle the buffer offset consistently for both
         PIO and DMA modes;
      
       - Add an argument to musb_ep_program() for the same
         reason (it only worked correctly with non-zero
         offset of the first frame in PIO mode);
      
       - Set the completed isochronous frame descriptor's
         'actual_length' and 'status' fields correctly in
         DMA mode.
      
      Also, since CPPI reportedly doesn't like sending isochronous
      packets in the RNDIS mode, change the criterion for this
      mode to be used only for multi-packet transfers.  (There's
      no need for that mode in the single-packet case anyway.)
      
      [ dbrownell@users.sourceforge.net: split comment paragraph
      into bullet list, shrink patch delta, style tweaks ]
      Signed-off-by: NPavel Kiryukhin <pkiryukhin@ru.mvista.com>
      Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6b6e9710
    • S
      USB: musb: sanitize clearing TXCSR DMA bits (take 2) · b6e434a5
      Sergei Shtylyov 提交于
      The MUSB code clears TXCSR_DMAMODE incorrectly in several
      places, either asserting that TXCSR_DMAENAB is clear (when
      sometimes it isn't) or clearing both bits together.  Recent
      versions of the programmer's guide require DMAENAB to be
      cleared first, although some older ones didn't.
      
      Fix this and while at it:
      
       - In musb_gadget::txstate(), stop clearing the AUTOSET
         and DMAMODE bits for the CPPI case since they never
         get set anyway (the former bit is reserved on DaVinci);
         but do clear the DMAENAB bit on the DMA error path.
      
       - In musb_host::musb_ep_program(), remove the duplicate
         DMA controller specific code code clearing the TXCSR
         previous state, add the code to clear TXCSR DMA bits
         on the Inventra DMA error path, to replace such code
         (executed late) on the PIO path.
      
       - In musbhsdma::dma_channel_abort()/dma_controller_irq(),
         add/use the 'offset' variable to avoid MUSB_EP_OFFSET()
         invocations on every RXCSR/TXCSR access.
      
      [dbrownell@users.sourceforge.net: don't introduce CamelCase,
      shrink diff]
      Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b6e434a5
    • S
      USB: musb: bugfixes for multi-packet TXDMA support · c7bbc056
      Sergei Shtylyov 提交于
      We really want to use DMA mode 1 for all multi-packet transfers;
      that's one IRQ on DMA completion, instead of one per packet.
      
      There is an important issue with such transfers, especially on
      the host side:  when such transfers end with a full-size packet,
      we must defer musb_dma_completion() calls until the FIFO empties.
      Else we report URB completions too soon, and may clobber data in
      the FIFO fifo when writing the next packet (losing data).
      
      The Inventra DMA support uses DMA mode 1, but it ignores that
      issue.  The CPPI DMA support uses mode 0, but doesn't handle
      its TXPKTRDY interrupts quite right either; it can get stale
      "packet ready" interrupts, and report transfer completion too
      early using slightly different code paths, also losing data.
      
      So I'm solving it in a generic way -- by adding a sort of the
      "interrupt filter" into musb_host_tx(), catching these cases
      where a DMA completion IRQ doesn't suffice and removing some
      needlessly controller-specific logic.  When a TXDMA interrupt
      happens and DMA request mode 1 is active, that filter resets
      to mode 0 and defers URB completion processing until TXPKTRDY,
      unless the FIFO is already empty.  Related filtering logic in
      Inventra and CPPI code gets removed.
      
      Since it should be competely safe now to use the DMA request
      mode 1 for host side transfers with the CPPI DMA controller,
      set it in musb_h_tx_dma_start() ... now renamed (and shared).
      
      [ dbrownell@users.sourceforge.net: don't introduce more
      CamElCase; use more concise explanations ]
      Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
      Cc: Felipe Balbi <felipe.balbi@nokia.com>
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c7bbc056
    • D
      USB: musb_host, fix ep0 fifo flushing · 78322c1a
      David Brownell 提交于
      The MUSB host side can't share generic TX FIFO flush logic
      with EP0; the EP0 TX status register bits are different
      from those for other entpoints.
      
      Resolve this issue by providing a new EP0-specific routine
      to flush and reset the FIFO, which pays careful attention to
      restrictions listed in the latest programmer's guide.  This
      gets rid of an open issue whereby the usbtest control write
      test (#14) failed.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      78322c1a
    • D
      USB: musb_host, minor enqueue locking fix (v2) · 74bb3508
      David Brownell 提交于
      Someone noted that the enqueue path used an unlocked access
      for usb_host_endpoint->hcpriv ... fix that, by being safe
      and always accessing it under spinlock protection.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      74bb3508
  2. 25 3月, 2009 6 次提交
  3. 28 2月, 2009 10 次提交
  4. 28 1月, 2009 8 次提交
  5. 08 1月, 2009 11 次提交