1. 16 6月, 2009 40 次提交
    • S
      USB: xhci: Avoid compiler reordering in Link TRB giveback. · b7116ebc
      Sarah Sharp 提交于
      Force the compiler to write the cycle bit of the Link TRB last.  This
      ensures that the hardware doesn't think it owns the Link TRB before we set
      the chain bit.  Reported by Oliver in this thread:
      	http://marc.info/?l=linux-usb&m=124091532410219&w=2Reported-by: NOliver Neukum <oliver@neukum.org>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b7116ebc
    • S
      USB: xhci: Clean up xhci_irq() function. · c96a2b81
      Sarah Sharp 提交于
      Drop spinlock in xhci_irq() error path.
      This fixes the issue reported by Oliver Neukum on this thread:
      	http://marc.info/?l=linux-usb&m=124090924401444&w=2
      
      Remove unnecessary register read reported by Viral Mehta:
      	http://marc.info/?l=linux-usb&m=124091326007398&w=2Reported-by: NOliver Neukum <oliver@neukum.org>
      Reported-by: NViral Mehta <viral.mehta@einfochips.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c96a2b81
    • S
      USB: xhci: Avoid global namespace pollution. · 23e3be11
      Sarah Sharp 提交于
      Make all globally visible functions start with xhci_ and mark functions as
      static if they're only called within the same C file.  Fix some long lines
      while we're at it.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      23e3be11
    • S
      USB: xhci: Fix Link TRB handoff bit twiddling. · 06e7a148
      Sarah Sharp 提交于
      Make sure to preserve all bits *except* the TRB_CHAIN bit when giving a
      Link TRB to the hardware.  We need to save things like TRB type and the
      toggle bit in the control dword.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      06e7a148
    • S
      USB: xhci: Fix register write order. · 3841d56e
      Sarah Sharp 提交于
      The 0.95 xHCI spec says that if the xHCI HW support 64-bit addressing, you
      must write the whole 64-bit address as one atomic operation, or write the
      low 32 bits, and then the high 32 bits.  I had the register writes
      swapped in some places.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3841d56e
    • G
      USB: xhci: fix some compiler warnings in xhci.h · 045f123d
      Greg Kroah-Hartman 提交于
      This fixes the warning:
      drivers/usb/host/xhci.h:1083: warning: passing argument 1 of ‘xhci_to_hcd’ discards qualifiers from pointer target type
      drivers/usb/host/xhci.h:1083: warning: passing argument 1 of ‘xhci_to_hcd’ discards qualifiers from pointer target type
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      045f123d
    • G
      USB: xhci: fix lots of compiler warnings. · 700e2052
      Greg Kroah-Hartman 提交于
      Turns out someone never built this code on a 64bit platform.
      
      Someone owes me a beer...
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      700e2052
    • S
      USB: xhci: use xhci_handle_event instead of handle_event · b7258a4a
      Stephen Rothwell 提交于
      The former is way to generic for a global symbol.
      
      Fixes this build error:
      
      drivers/usb/built-in.o: In function `.handle_event': (.text+0x67dd0): multiple definition of `.handle_event'
      drivers/pcmcia/built-in.o:(.text+0xcfcc): first defined here
      drivers/usb/built-in.o: In function `handle_event': (.opd+0x5bc8): multiple definition of `handle_event'
      drivers/pcmcia/built-in.o:(.opd+0xed0): first defined here
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b7258a4a
    • S
      USB: xhci: URB cancellation support. · ae636747
      Sarah Sharp 提交于
      Add URB cancellation support to the xHCI host controller driver.  This
      currently supports cancellation for endpoints that do not have streams
      enabled.
      
      An URB is represented by a number of Transaction Request Buffers (TRBs),
      that are chained together to make one (or more) Transaction Descriptors
      (TDs) on an endpoint ring.  The ring is comprised of contiguous segments,
      linked together with Link TRBs (which may or may not be chained into a TD).
      
      To cancel an URB, we must stop the endpoint ring, make the hardware skip
      over the TDs in the URB (either by turning them into No-op TDs, or by
      moving the hardware's ring dequeue pointer past the last TRB in the last
      TD), and then restart the ring.
      
      There are times when we must drop the xHCI lock during this process, like
      when we need to complete cancelled URBs.  We must ensure that additional
      URBs can be marked as cancelled, and that new URBs can be enqueued (since
      the URB completion handlers can do either).  The new endpoint ring
      variables cancels_pending and state (which can only be modified while
      holding the xHCI lock) ensure that future cancellation and enqueueing do
      not interrupt any pending cancellation code.
      
      To facilitate cancellation, we must keep track of the starting ring
      segment, first TRB, and last TRB for each URB.  We also need to keep track
      of the list of TDs that have been marked as cancelled, separate from the
      list of TDs that are queued for this endpoint.  The new variables and
      cancellation list are stored in the xhci_td structure.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ae636747
    • S
      USB: xhci: Scatter gather list support for bulk transfers. · 8a96c052
      Sarah Sharp 提交于
      Add support for bulk URBs that pass scatter gather lists to xHCI.  This allows
      xHCI to more efficiently enqueue these transfers, and allows the host
      controller to take advantage of USB 3.0 "bursts" for bulk endpoints.
      
      Use requested length to calculate the number of TRBs needed for a scatter gather
      list transfer, instead of using the number of sglist entries.  The application
      can pass down a scatter gather list that is bigger than it needs for the
      requested transfer.
      
      Scatter gather entries can cross 64KB boundaries, so be careful to setup TRBs
      such that no buffer crosses a 64KB boundary.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8a96c052
    • S
      USB: Push scatter gather lists down to host controller drivers. · e04748e3
      Sarah Sharp 提交于
      This is the original patch I created before David Vrabel posted a better
      patch (http://marc.info/?l=linux-usb&m=123377477209109&w=2) that does
      basically the same thing.  This patch will get replaced with his
      (modified) patch later.
      
      Allow USB device drivers that use usb_sg_init() and usb_sg_wait() to push
      bulk endpoint scatter gather lists down to the host controller drivers.
      This allows host controller drivers to more efficiently enqueue these
      transfers, and allows the xHCI host controller to better take advantage of
      USB 3.0 "bursts" for bulk endpoints.
      
      This patch currently only enables scatter gather lists for bulk endpoints.
      Other endpoint types that use the usb_sg_* functions will not have their
      scatter gather lists pushed down to the host controller.  For periodic
      endpoints, we want each scatterlist entry to be a separate transfer.
      Eventually, HCDs could parse these scatter-gather lists for periodic
      endpoints also.  For now, we use the old code and call usb_submit_urb()
      for each scatterlist entry.
      
      The caller of usb_sg_init() can request that all bytes in the scatter
      gather list be transferred by passing in a length of zero.  Handle that
      request for a bulk endpoint under xHCI by walking the scatter gather list
      and calculating the length.  We could let the HCD handle a zero length in
      this case, but I'm not sure if the core layers in between will get
      confused by this.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e04748e3
    • S
      USB: xhci: Bulk transfer support · b10de142
      Sarah Sharp 提交于
      Allow device drivers to submit URBs to bulk endpoints on devices under an
      xHCI host controller.  Share code between the control and bulk enqueueing
      functions when it makes sense.
      
      To get the best performance out of bulk transfers, SuperSpeed devices must
      have the bMaxBurst size copied from their endpoint companion controller
      into the xHCI device context.  This allows the host controller to "burst"
      up to 16 packets before it has to wait for the device to acknowledge the
      first packet.
      
      The buffers in Transfer Request Blocks (TRBs) can cross page boundaries,
      but they cannot cross 64KB boundaries.  The buffer must be broken into
      multiple TRBs if a 64KB boundary is crossed.
      
      The sum of buffer lengths in all the TRBs in a Transfer Descriptor (TD)
      cannot exceed 64MB.  To work around this, the enqueueing code must enqueue
      multiple TDs.  The transfer event handler may incorrectly give back the
      URB in this case, if it gets a transfer event that points somewhere in the
      first TD.  FIXME later.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b10de142
    • S
      USB: xhci: Bandwidth allocation support · f94e0186
      Sarah Sharp 提交于
      Since the xHCI host controller hardware (xHC) has an internal schedule, it
      needs a better representation of what devices are consuming bandwidth on
      the bus.  Each device is represented by a device context, with data about
      the device, endpoints, and pointers to each endpoint ring.
      
      We need to update the endpoint information for a device context before a
      new configuration or alternate interface setting is selected.  We setup an
      input device context with modified endpoint information and newly
      allocated endpoint rings, and then submit a Configure Endpoint Command to
      the hardware.
      
      The host controller can reject the new configuration if it exceeds the bus
      bandwidth, or the host controller doesn't have enough internal resources
      for the configuration.  If the command fails, we still have the older
      device context with the previous configuration.  If the command succeeds,
      we free the old endpoint rings.
      
      The root hub isn't a real device, so always say yes to any bandwidth
      changes for it.
      
      The USB core will enable, disable, and then enable endpoint 0 several
      times during the initialization sequence.  The device will always have an
      endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
      device is disconnected or gets a SetAddress 0 request.  So we don't pay
      attention for when xhci_check_bandwidth() is called for a re-add of
      endpoint 0.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      f94e0186
    • S
      USB: Support for bandwidth allocation. · 79abb1ab
      Sarah Sharp 提交于
      Originally, the USB core had no support for allocating bandwidth when a
      particular configuration or alternate setting for an interface was
      selected.  Instead, the device driver's URB submission would fail if
      there was not enough bandwidth for a periodic endpoint.  Drivers could
      work around this, by using the scatter-gather list API to guarantee
      bandwidth.
      
      This patch adds host controller API to allow the USB core to allocate or
      deallocate bandwidth for an endpoint.  Endpoints are added to or dropped
      from a copy of the current schedule by calling add_endpoint() or
      drop_endpoint(), and then the schedule is atomically evaluated with a
      call to check_bandwidth().  This allows all the endpoints for a new
      configuration or alternate setting to be added at the same time that the
      endpoints from the old configuration or alt setting are dropped.
      
      Endpoints must be added to the schedule before any URBs are submitted to
      them.  The HCD must be allowed to reject a new configuration or alt
      setting before the control transfer is sent to the device requesting the
      change.  It may reject the change because there is not enough bandwidth,
      not enough internal resources (such as memory on an embedded host
      controller), or perhaps even for security reasons in a virtualized
      environment.
      
      If the call to check_bandwidth() fails, the USB core must call
      reset_bandwidth().  This causes the schedule to be reverted back to the
      state it was in just after the last successful check_bandwidth() call.
      
      If the call succeeds, the host controller driver (and hardware) will have
      changed its internal state to match the new configuration or alternate
      setting.  The USB core can then issue a control transfer to the device to
      change the configuration or alt setting.  This allows the core to test new
      configurations or alternate settings before unbinding drivers bound to
      interfaces in the old configuration.
      
      WIP:
      
      The USB core must add endpoints from all interfaces in a configuration
      to the schedule, because a driver may claim that interface at any time.
      A slight optimization might be to add the endpoints to the schedule once
      a driver claims that interface.  FIXME
      
      This patch does not cover changing alternate settings, but it does
      handle a configuration change or de-configuration.  FIXME
      
      The code for managing the schedule is currently HCD specific.  A generic
      scheduling algorithm could be added for host controllers without
      built-in scheduling support.  For now, if a host controller does not
      define the check_bandwidth() function, the call to
      usb_hcd_check_bandwidth() will always succeed.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      79abb1ab
    • S
      USB: Parse and store the SuperSpeed endpoint companion descriptors. · 663c30d0
      Sarah Sharp 提交于
      The USB 3.0 bus specification added an "Endpoint Companion" descriptor that is
      supposed to follow all SuperSpeed Endpoint descriptors.  This descriptor is used
      to extend the bus protocol to allow more packets to be sent to an endpoint per
      "microframe".  The word microframe was removed from the USB 3.0 specification
      because the host controller does not send Start Of Frame (SOF) symbols down the
      USB 3.0 wires.
      
      The descriptor defines a bMaxBurst field, which indicates the number of packets
      of wMaxPacketSize that a SuperSpeed device can send or recieve in a service
      interval.  All non-control endpoints may set this value as high as 16 packets
      (bMaxBurst = 15).
      
      The descriptor also allows isochronous endpoints to further specify that they
      can send and receive multiple bursts per service interval.  The bmAttributes
      allows them to specify a "Mult" of up to 3 (bmAttributes = 2).
      
      Bulk endpoints use bmAttributes to report the number of "Streams" they support.
      This was an extension of the endpoint pipe concept to allow multiple mass
      storage device commands to be outstanding for one bulk endpoint at a time.  This
      should allow USB 3.0 mass storage devices to support SCSI command queueing.
      Bulk endpoints can say they support up to 2^16 (65,536) streams.
      
      The information in the endpoint companion descriptor must be stored with the
      other device, config, interface, and endpoint descriptors because the host
      controller needs to access them quickly, and we need to install some default
      values if a SuperSpeed device doesn't provide an endpoint companion descriptor.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      663c30d0
    • S
      USB: xhci: Control transfer support. · d0e96f5a
      Sarah Sharp 提交于
      Allow device drivers to enqueue URBs to control endpoints on devices under
      an xHCI host controller.  Each control transfer is represented by a
      series of Transfer Descriptors (TDs) written to an endpoint ring.  There
      is one TD for the Setup phase, (optionally) one TD for the Data phase, and
      one TD for the Status phase.
      
      Enqueue these TDs onto the endpoint ring that represents the control
      endpoint.  The host controller hardware will return an event on the event
      ring that points to the (DMA) address of one of the TDs on the endpoint
      ring.  If the transfer was successful, the transfer event TRB will have a
      completion code of success, and it will point to the Status phase TD.
      Anything else is considered an error.
      
      This should work for control endpoints besides the default endpoint, but
      that hasn't been tested.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d0e96f5a
    • S
      USB: xhci: Allocate and address USB devices · 3ffbba95
      Sarah Sharp 提交于
      xHCI needs to get a "Slot ID" from the host controller and allocate other
      data structures for every USB device.  Make usb_alloc_dev() and
      usb_release_dev() allocate and free these device structures.  After
      setting up the xHC device structures, usb_alloc_dev() must wait for the
      hardware to respond to an Enable Slot command.  usb_alloc_dev() fires off
      a Disable Slot command and does not wait for it to complete.
      
      When the USB core wants to choose an address for the device, the xHCI
      driver must issue a Set Address command and wait for an event for that
      command.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3ffbba95
    • S
      USB: Support for addressing a USB device under xHCI · c6515272
      Sarah Sharp 提交于
      Add host controller driver API and a slot_id variable to struct
      usb_device.  This allows the xHCI host controller driver to ask the
      hardware to allocate a slot for the device when a struct usb_device is
      allocated.  The slot needs to be allocated at that point because the
      hardware can run out of internal resources, and we want to know that very
      early in the device connection process.  Don't call this new API for root
      hubs, since they aren't real devices.
      
      Add HCD API to let the host controller choose the device address.  This is
      especially important for xHCI hardware running in a virtualized
      environment.  The guests running under the VM don't need to know which
      addresses on the bus are taken, because the hardware picks the address for
      them.  Announce SuperSpeed USB devices after the address has been assigned
      by the hardware.
      
      Don't use the new get descriptor/set address scheme with xHCI.  Unless
      special handling is done in the host controller driver, the xHC can't
      issue control transfers before you set the device address.  Support for
      the older addressing scheme will be added when the xHCI driver supports
      the Block Set Address Request (BSR) flag in the Address Device command.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c6515272
    • S
      USB: xhci: Root hub support. · 0f2a7930
      Sarah Sharp 提交于
      Add functionality for getting port status and hub descriptor for xHCI root
      hubs.  This is WIP because the USB 3.0 hub descriptor is different from
      the USB 2.0 hub descriptor.  For now, we lie about the root hub descriptor
      because the changes won't effect how the core talks to the root hub.
      Later we will need to add the USB 3.0 hub descriptor for real hubs, and
      this code might change.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0f2a7930
    • S
      USB: Add route string to struct usb_device. · 7206b001
      Sarah Sharp 提交于
      This patch adds a hex route string to each USB device.  The route string is used
      by the USB 3.0 host controller to send packets through the device tree.  USB 3.0
      hubs use this string to route packets to the correct port.  This is fundamental
      bus change from USB 2.0, where all packets were broadcast across the bus.
      
      Devices (including hubs) under a root port receive the route string 0x0.  Every
      four bits in the route string represent a port on a hub.  This length works
      because USB 3.0 hubs are limited to 15 ports, and USB 2.0 hubs (with potentially
      more ports) will never see packets with a route string.  A port number of 0
      means the packet is destined for that hub.
      
      For example, a peripheral device might have a route string of 0x00097.
      This means the device is connected to port 9 of the hub at depth 1.
      The hub at depth 1 is connected to port 7 of a hub at depth 0.
      The hub at depth 0 is connected to a root port.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7206b001
    • S
      USB: Don't reset USB 3.0 devices on port change detection. · e7b77172
      Sarah Sharp 提交于
      The USB 3.0 bus specification defines a new connection sequence for USB 3.0
      hubs and roothubs.  USB 3.0 devices are reset and link trained by the hub
      before the port status change notification is sent to the host OS.  This means
      that an entire tree of devices can be trained in parallel on power up, and the
      OS no longer needs to reset USB 3.0 devices.  Change the USB core's hub port
      init sequence so that it does not reset USB 3.0 devices.
      
      The port status change from the roothub and from the USB 3.0 hub will report
      the SuperSpeed connect correctly.  This patch currently only handles the
      roothub case.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e7b77172
    • S
      USB: Add USB 3.0 roothub support to USB core. · d2e9b4d6
      Sarah Sharp 提交于
      Add USB 3.0 root hub descriptors.  This is a kludge because I reused the old
      USB 2.0 descriptors, instead of using the new USB 3.0 hub descriptors with
      endpoint companion descriptors and other descriptors.  I did this because I
      wasn't ready to add USB 3.0 hub changes to khubd.  For now, a USB 3.0 roothub
      looks like a USB 2.0 roothub, with a higher speed.
      
      USB 3.0 hubs have no transaction translator (TT).
      
      Make USB core debugging handle super speed ports.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d2e9b4d6
    • S
      USB: Add SuperSpeed to the list of USB device speeds. · 6b403b02
      Sarah Sharp 提交于
      Modify the USB core to handle the new USB 3.0 speed, "SuperSpeed".  This
      is 5.0 Gbps (wire speed).  There are probably more places that check for
      speed that I've missed.
      
      SuperSpeed devices have a 512 byte endpoint 0 max packet size.  This shows
      up as a bMaxPacketSize0 set to 0x09 (see table 9-8 of the USB 3.0 bus
      spec).
      
      xHCI spec says that the xHC can handle intervals up to 2^15 microframes.  That
      might change when real silicon becomes available.
      
      Add FIXME note for SuperSpeed isochronous endpoints.  They can transmit up
      to 16 packets in one "burst" before they wait for an acknowledgment of the
      packets.  They can do up to 3 bursts per microframe (determined by the
      mult value in the endpoint companion descriptor).  The xHCI driver doesn't
      have support for isoc yet, so fix this later.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6b403b02
    • S
      USB: xhci: No-op command queueing and irq handler. · 7f84eef0
      Sarah Sharp 提交于
      xHCI host controllers can optionally implement a no-op test.  This
      simple test ensures the OS has correctly setup all basic data structures
      and can correctly respond to interrupts from the host controller
      hardware.
      
      There are two rings exercised by the no-op test:  the command ring, and
      the event ring.
      
      The host controller driver writes a no-op command TRB to the command
      ring, and rings the doorbell for the command ring (the first entry in
      the doorbell array).  The hardware receives this event, places a command
      completion event on the event ring, and fires an interrupt.
      
      The host controller driver sees the interrupt, and checks the event ring
      for TRBs it can process, and sees the command completion event.  (See
      the rules in xhci-ring.c for who "owns" a TRB.  This is a simplified set
      of rules, and may not contain all the details that are in the xHCI 0.95
      spec.)
      
      A timer fires every 60 seconds to debug the state of the hardware and
      command and event rings.  This timer only runs if
      CONFIG_USB_XHCI_HCD_DEBUGGING is 'y'.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7f84eef0
    • S
      USB: xhci: Device context array allocation. · a74588f9
      Sarah Sharp 提交于
      Instead of keeping a "frame list" like older host controllers, the xHCI
      host controller keeps internal representations of the USB devices, with a
      transfer ring per endpoint.  The host controller queues Transfer Request
      Blocks (TRBs) to the endpoint ring, and then "rings the doorbell" for that
      device.  The host controller processes the transfer, places a transfer
      completion event on the event ring, and interrupts the system.
      
      The device context base address array must be allocated by the xHCI host
      controller driver, along with the device contexts it points to.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      a74588f9
    • S
      USB: xhci: Ring allocation and initialization. · 0ebbab37
      Sarah Sharp 提交于
      Allocate basic xHCI host controller data structures.  For every xHC, there
      is a command ring, an event ring, and a doorbell array.
      
      The doorbell array is used to notify the host controller that work has
      been enqueued onto one of the rings.  The host controller driver enqueues
      commands on the command ring.  The HW enqueues command completion events
      on the event ring and interrupts the system (currently using PCI
      interrupts, although the xHCI HW will use MSI interrupts eventually).
      
      All rings and the doorbell array must be allocated by the xHCI host
      controller driver.
      
      Each ring is comprised of one or more segments, which consists of 16-byte
      Transfer Request Blocks (TRBs) that can be chained to form a Transfer
      Descriptor (TD) that represents a multiple-buffer request.  Segments are
      linked into a ring using Link TRBs, which means they are dynamically
      growable.
      
      The producer of the ring enqueues a TD by writing one or more TRBs in the
      ring and toggling the TRB cycle bit for each TRB.  The consumer knows it
      can process the TRB when the cycle bit matches its internal consumer cycle
      state for the ring.  The consumer cycle state is toggled an odd amount of
      times in the ring.
      
      An example ring (a ring must have a minimum of 16 TRBs on it, but that's
      too big to draw in ASCII art):
      
                    chain  cycle
                     bit    bit
       ------------------------
      | TD A TRB 1 |  1  |  1  |<-------------  <-- consumer dequeue ptr
       ------------------------               |     consumer cycle state = 1
      | TD A TRB 2 |  1  |  1  |              |
       ------------------------               |
      | TD A TRB 3 |  0  |  1  |  segment 1   |
       ------------------------               |
      | TD B TRB 1 |  1  |  1  |              |
       ------------------------               |
      | TD B TRB 2 |  0  |  1  |              |
       ------------------------               |
      | Link TRB   |  0  |  1  |-----         |
       ------------------------     |         |
                                    |         |
                    chain  cycle    |         |
                     bit    bit     |         |
       ------------------------     |         |
      | TD C TRB 1 |  0  |  1  |<----         |
       ------------------------               |
      | TD D TRB 1 |  1  |  1  |              |
       ------------------------               |
      | TD D TRB 2 |  1  |  1  |   segment 2  |
       ------------------------               |
      | TD D TRB 3 |  1  |  1  |              |
       ------------------------               |
      | TD D TRB 4 |  1  |  1  |              |
       ------------------------               |
      | Link TRB   |  1  |  1  |-----         |
       ------------------------     |         |
                                    |         |
                    chain  cycle    |         |
                     bit    bit     |         |
       ------------------------     |         |
      | TD D TRB 5 |  1  |  1  |<----         |
       ------------------------               |
      | TD D TRB 6 |  0  |  1  |              |
       ------------------------               |
      | TD E TRB 1 |  0  |  1  |   segment 3  |
       ------------------------               |
      |            |  0  |  0  |              | <-- producer enqueue ptr
       ------------------------               |
      |            |  0  |  0  |              |
       ------------------------               |
      | Link TRB   |  0  |  0  |---------------
       ------------------------
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0ebbab37
    • S
      USB: xhci: BIOS handoff and HW initialization. · 66d4eadd
      Sarah Sharp 提交于
      Add PCI initialization code to take control of the xHCI host controller
      away from the BIOS, halt, and reset the host controller.  The xHCI spec
      says that BIOSes must give up the host controller within 5 seconds.
      
      Add some host controller glue functions to handle hardware initialization
      and memory allocation for the host controller.  The current xHCI
      prototypes use PCI interrupts, but the xHCI spec requires MSI-X
      interrupts.  Add code to support MSI-X interrupts, but use the PCI
      interrupts for now.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      66d4eadd
    • S
      USB: xhci: Support xHCI host controllers and USB 3.0 devices. · 74c68741
      Sarah Sharp 提交于
      This is the first of many patches to add support for USB 3.0 devices and
      the hardware that implements the eXtensible Host Controller Interface
      (xHCI) 0.95 specification.  This specification is not yet publicly
      available, but companies can receive a copy by becoming an xHCI
      Contributor (see http://www.intel.com/technology/usb/xhcispec.htm).
      
      No xHCI hardware has made it onto the market yet, but these patches have
      been tested under the Fresco Logic host controller prototype.
      
      This patch adds the xHCI register sets, which are grouped into five sets:
       - Generic PCI registers
       - Host controller "capabilities" registers (cap_regs) short
       - Host controller "operational" registers (op_regs)
       - Host controller "runtime" registers (run_regs)
       - Host controller "doorbell" registers
      
      These some of these registers may be virtualized if the Linux driver is
      running under a VM.  Virtualization has not been tested for this patch.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      74c68741
    • G
      USB: usbtmc: fix switch statment · a92b63e7
      Greg Kroah-Hartman 提交于
      Steve Holland pointed out that we forgot to call break; in the switch
      statment.  This probably resolves a lot of the bug reports I've gotten
      for the driver lately.
      
      Stupid me...
      Reported-by: NSteve Holland <sdh4@iastate.edu>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      a92b63e7
    • M
      USB: usbtest fix endless loop in unlink tests. · 3b6c023f
      Martin Fuzzey 提交于
      In tests 11 and 12 if the URB completes with an error status (eg babble)
      the asynchrous unlink entered an endless loop trying to unlink
      a non resubmitted URB.
      Signed-off-by: NMartin Fuzzey <mfuzzey@gmail.com>
      Acked-by: NDavid Brownell <david-b@pacbell.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3b6c023f
    • N
      USB: atmel_usba_udc: change way of specifying bias function · e60c65d3
      Nicolas Ferre 提交于
      The toggle_bias() function was specified differently for avr32 and at91
      architectures. Now, new at91 have the same behavior as avr32.
      Consequently, we change to a particular chip function definition: only for
      at91sam9rl.
      Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      Acked-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e60c65d3
    • F
      USB: Avoid PM error messages during resume if a device was disconnected · 23a54e56
      Frans Pop 提交于
      Currently if a laptop is suspended e.g. while docked and then resumed after
      undocking it, the following errors get generated because the USB hub in the
      docking station and the devices connected to it are no longer available:
      pm_op(): usb_dev_resume+0x0/0x10 returns -19
      PM: Device 1-2 failed to resume: error -19
      pm_op(): usb_dev_resume+0x0/0x10 returns -19
      PM: Device 1-2.2 failed to resume: error -19
      pm_op(): usb_dev_resume+0x0/0x10 returns -19
      PM: Device 1-2.3 failed to resume: error -19
      
      As the removal of USB devices while a system is suspended is a relatively
      common use case and in most cases not an error, just return success on
      -ENODEV. The user gets informed anyway as the USB subsystem generates
      regular disconnect messages for the devices shortly afterwards:
      usb 1-2: USB disconnect, address 3
      usb 1-2.2: USB disconnect, address 4
      usblp0: removed
      usb 1-2.3: USB disconnect, address 5
      Signed-off-by: NFrans Pop <elendil@planet.nl>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      23a54e56
    • H
      USB: Add Intel Langwell USB OTG Transceiver Drive · 453f7755
      Hao Wu 提交于
      Description:
      This driver is used for Intel Langwell* USB OTG controller in Intel
      Moorestown* platform. It tries to implement host/device role switch
      according to OTG spec.  The actual hsot and device functions are
      accomplished in modified EHCI driver and Intel Langwell USB OTG client
      controller driver.
      
      * Langwell and Moorestown are names used in development. They are not
        approved official name.
      
      Note:
      This patch is the first version Intel Langwell USB OTG Transceiver
      driver. The development is not finished, and the bug fixing is on going
      for some hardware and software issues. The main purpose of this
      submission is for code view.
      
      Supported features:
      - Data-line Pulsing SRP
      - Support HNP to switch roles
      - PCI D0/D3 power management support
      
      Known issues:
      - HNP is only tested with another Moorestown platform.
      - PCI D0/D3 power management support is not fully tested.
      - VBus Pulsing SRP is not support in current version.
      Signed-off-by: NHao Wu <hao.wu@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      453f7755
    • X
      USB: Add Intel Langwell USB Device Controller driver · 5be19a9d
      Xiaochen Shen 提交于
      Intel Langwell USB Device Controller is a High-Speed USB OTG device
      controller in Intel Moorestown platform. It can work in OTG device mode
      with Intel Langwell USB OTG transceiver driver as well as device-only
      mode. The number of programmable endpoints is different through
      controller revision.
      
      NOTE:
      This patch is the first version Intel Langwell USB OTG device controller
      driver. The bug fixing is on going for some hardware and software
      issues.  Intel Langwell USB OTG transceiver driver and EHCI driver
      patches will be submitted later.
      
      Supported features:
       - USB OTG protocol support with Intel Langwell USB OTG transceiver
         driver (turn on CONFIG_USB_LANGWELL_OTG)
       - Support control, bulk, interrupt and isochronous endpoints
         (isochronous not tested)
       - PCI D0/D3 power management support
       - Link Power Management (LPM) support
      
      Tested gadget drivers:
       - g_file_storage
       - g_ether
       - g_zero
      
      The passed tests:
       - g_file_storage: USBCV Chapter 9 tests
       - g_file_storage: USBCV MSC tests
       - g_file_storage: from/to host files copying
       - g_ether: ping, ftp and scp files from/to host
       - Hotplug, with and without hubs
      
      Known issues:
       - g_ether: failed part of USBCV chap9 tests
       - LPM support not fully tested
      
      TODO:
       - g_ether: pass all USBCV chap9 tests
       - g_zero: pass usbtest tests
       - Stress tests on different gadget drivers
       - On-chip private SRAM caching support
      Signed-off-by: NXiaochen Shen <xiaochen.shen@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5be19a9d
    • A
      USB: usb-serial: replace shutdown with disconnect, release · f9c99bb8
      Alan Stern 提交于
      This patch (as1254) splits up the shutdown method of usb_serial_driver
      into a disconnect and a release method.
      
      The problem is that the usb-serial core was calling shutdown during
      disconnect handling, but drivers didn't expect it to be called until
      after all the open file references had been closed.  The result was an
      oops when the close method tried to use memory that had been
      deallocated by shutdown.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      f9c99bb8
    • A
      USB: usb-serial: call port_probe and port_remove at the right times · c706ebdf
      Alan Stern 提交于
      This patch (as1253) prevents the usb-serial core from calling a
      driver's port_probe and port_remove methods more than once per port.
      It also removes some unnecessary try_module_get() calls and adds a
      missing port_remove method call in a failure path.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c706ebdf
    • B
      USB: gadget: add USB Audio Gadget driver · c6994e6f
      Bryan Wu 提交于
      Funtions added:
       - setup all the USB audio class device descriptors
       - handle class specific setup request
       - receive data from USB host by ISO transfer
       - play audio data by ALSA sound card
       - open and setup playback PCM interface
       - set default playback PCM parameters
       - provide playback functions for USB audio driver
       - provide PCM parameters set/get functions
      
      Test on:
       - Host: Ubuntu 8.10, kernel 2.6.27
       - Gadget: EZKIT-BF548 with ASoC AD1980 codec
      
      Todo:
       - add real Mute control code
       - add real Volume control code
       - maybe find another way to replace dynamic buffer handling
         with static buffer allocation
       - test on Windows system
       - provide control interface to handle mute/volume control
       - provide capture interface in the future
       - test on BF527, other USB device controler and other audio codec
      Signed-off-by: NBryan Wu <cooloney@kernel.org>
      Signed-off-by: NMike Frysinger <vapier@gentoo.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c6994e6f
    • B
      USB: Gadget driver for Samsung HS/OtG block · 5b7d70c6
      Ben Dooks 提交于
      Driver support for the new high-speed/OtG block that is
      in the newer line of Samsung SoC devices such as the
      S3C64XX series.
      
      This driver does not currntly have DMA support enabled due
      to issues with buffer alignment which need to be sorted out.
      Signed-off-by: NBen Dooks <ben@simtec.co.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5b7d70c6
    • G
      USB: gadget: Add i.MX3x support to the fsl_usb2_udc driver · 54e4026b
      Guennadi Liakhovetski 提交于
      This patch adds support for i.MX3x (only tested with i.MX31 so far) ARM
      SoCs to the fsl_usb2_udc driver. It also moves PHY configuration before
      controller reset, because otherwise an ULPI PHY doesn't get a reset and
      doesn't function after a reboot. The problem with longer control transfers
      is still not fixed. The patch renames the fsl_usb2_udc.c file to
      fsl_udc_core.c to preserve the same module name for user-space
      backwards compatibility.
      Signed-off-by: NGuennadi Liakhovetski <lg@denx.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      54e4026b
    • J
      USB: usb_serial: only allow sysrq on a console port · 568d422e
      Jason Wessel 提交于
      The only time a sysrq should get processed is if the attached device
      is a console.  This is intended to protect sysrq execution on a host
      connected with a terminal program.
      
      Here is the problem scenario:
      
      host A <-- rs232 link --> host B
      
      Host A is using mincom and a usb pl2303 device to connect to host b
      which is a linux system with a usb pl2303 device acting as the serial
      console.  When host B is rebooted the pl2303 emits random junk
      characters on reset.  These character sequences contain serial break
      signals most of the time and when translated to a sysrq have caused
      host A to get random processes killed, reboots or power down.
      
      It is true that in this setup with this patch host B might still have
      the same problem as host A if you reboot host A.  In most cases host A
      is a development host which seldom gets rebooted, and you could turn
      off sysrq temporarily on host B if you need to reboot host A.
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      568d422e