1. 11 Jun, 2014 6 commits
  2. 01 Jun, 2014 7 commits
    • Stephen Warren's avatar
      usb: ci_udc: complete ep0 direction handling · 006c7026
      Stephen Warren authored
      
      
      handle_setup() currently assumes that the response to a Setup transaction
      will be an OUT transaction, and any subsequent packet (if any) will be an
      IN transaction. This appears to be valid in many cases; both USB
      enumeration and Mass Storage work OK with this restriction. However, DFU
      uses ep0 to transfer data in both directions. This renders the assumption
      invalid; when sending data from device to host, the Data Stage is an IN
      transaction, and the Status Stage is an OUT transaction. Enhance
      handle_setup() to deduce the correct direction for the USB transactions
      based on Setup transaction data.
      
      ep0's request object only needs to be automatically re-queued when the
      Data Stage completes, in order to implement the Status Stage. Once the
      Status Stage transaction is complete, there is no need to re-queue the
      USB request, so don't do that.
      
      Don't sent USB request completion callbacks for Status Stage transactions.
      These were queued by ci_udc itself, and only serve to confuse the USB
      function code. For example, f_dfu attempts to interpret the 0-length data
      buffers for Status Stage transactions as DFU packets. These buffers
      contain stale data from the previous transaction. This causes f_dfu to
      complain about a sequence number mismatch.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      006c7026
    • Stephen Warren's avatar
      usb: ci_udc: pre-allocate ep0 req · a2d8f929
      Stephen Warren authored
      Allocate ep0's USB request object when the UDC driver is probed. This
      solves a couple of issues in the current code:
      
      a) A request object always exists for ep0. Prior to this patch, if setup
      transactions arrived in an unexpected order, handle_setup() would need
      to reply to a setup transaction before any ep0 usb_req was created.
      
      This issue was introduced in commit 2813006f
      
       "usb: ci_udc: allow
      multiple buffer allocs per ep."
      
      b) handle_ep_complete no longer /has/ to queue the ep0 request again
      after every single request completion. This is currently required, since
      handle_setup() assumes it can find some request object in ep0's request
      queue. This patch doesn't actually stop handle_ep_complete() from always
      requeueing the request, but the next patch will.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      a2d8f929
    • Stephen Warren's avatar
      usb: ci_udc: use a single descriptor for ep0 · 054731b0
      Stephen Warren authored
      
      
      ci_udc currently points ep->desc at separate descriptors for IN and OUT.
      These descriptors only differ in the ep address IN/OUT field. Modify the
      code to use a single descriptor, and change that descriptor's ep address
      to indicate IN/OUT as required. This removes some data duplication.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      054731b0
    • Stephen Warren's avatar
      usb: ci_udc: detect queued requests on ep0 · 7484d84c
      Stephen Warren authored
      
      
      The flipping of ep0 between IN and OUT relies on ci_ep_queue() consuming
      the current IN/OUT setting immediately. If this is deferred to a later
      point when the req is pulled out of ci_req->queue, then the IN/OUT
      setting may have been changed since the req was queued, and state will
      get out of sync. This condition doesn't occur today, but could if bugs
      were introduced later, and this error-check will save a lot of debugging
      time.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      7484d84c
    • Stephen Warren's avatar
      usb: hub: remove CONFIG_USB_HUB_MIN_POWER_ON_DELAY · 77b83e6d
      Stephen Warren authored
      
      
      Now that we wait the correct specification-mandated time at the end of
      usb_hub_power_on(), I suspect that CONFIG_USB_HUB_MIN_POWER_ON_DELAY has
      no purpose.
      
      For cm_t35.h, we already wait longer than the original MIN_POWER_ON_DELAY,
      so this change is safe.
      
      For gw_ventana.h, we will wait as long as the original MIN_POWER_ON_DELAY
      iff pgood_delay was at least 200ms. I'm not sure if this is the case or
      not, hence I've CC'd relevant people to test this change.
      
      Cc: Igor Grinberg <grinberg@compulab.co.il>
      Cc: Tim Harvey <tharvey@gateworks.com>
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      77b83e6d
    • Stephen Warren's avatar
      usb: hub: fix power good delay timing · 0d437bca
      Stephen Warren authored
      
      
      usb_hub_power_on() currently waits for the maximum of (a) the hub port's
      power output to become good, (b) the max time the USB specification
      allows a device to take to connect.
      
      However, these two operations must occur in series rather than in
      parallel. First, the power supply ramps up to the level required to
      power the USB device, and then the device may take a certain amount of
      time to connect (assert D+/D- pullups).
      
      Related, the maximum time that a device has to assert pullups is 1s not
      100ms.
      
      This is explained in "Connect Timing ECN.pdf", itself part of
      usb_20_042814.zip from www.usb.org.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      0d437bca
    • Lukasz Majewski's avatar
      dfu: Introduction of the "dfu_hash_algo" env variable for checksum method setting · bd694244
      Lukasz Majewski authored
      
      
      Up till now the CRC32 of received data was calculated unconditionally.
      The standard crc32 implementation causes long delay when large images
      were uploaded.
      
      The "dfu_hash_algo" environment variable gives the opportunity to
      disable on demand the hash (crc32) calculation.
      It can be done without the need to recompile the u-boot binary.
      
      By default the crc32 is calculated, which means that legacy behavior
      has been preserved.
      
      Tests results:
      400 MiB ums.img file
      With 		crc32 calculation: 65 sec [avg 6.29 MB/s]
      Without 		crc32 calculation: 25 sec [avg 16.17 MB/s]
      Signed-off-by: default avatarLukasz Majewski <l.majewski@samsung.com>
      Cc: Marek Vasut <marex@denx.de>
      bd694244
  3. 30 May, 2014 1 commit
  4. 29 May, 2014 14 commits
  5. 27 May, 2014 4 commits
  6. 26 May, 2014 8 commits