1. 09 May, 2014 7 commits
  2. 08 May, 2014 5 commits
  3. 06 May, 2014 9 commits
  4. 05 May, 2014 10 commits
  5. 02 May, 2014 1 commit
  6. 01 May, 2014 1 commit
    • Stephen Warren's avatar
      usb: gadget: allow ci_udc to build with new gadget framework · 2fc5dab2
      Stephen Warren authored
      Allow ci_udc.o to be built when using the new(?) USB gadget framework,
      as enabled by CONFIG_USB_GADGET.
      Note that this duplicates the Makefile entry for ci_udc.o, since it's
      also included inside #ifdef CONFIG_USB_ETHER. I'm not sure what that
      define means; perhaps an old style of Ethernet-specific USB gadget
      I wonder if the line that this patch adds shouldn't be outside all of
      the ifdefs, so it stands on its own, similar to how e.g. epautoconf.o
      is shared between the two?
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
  7. 30 Apr, 2014 7 commits
    • Stephen Warren's avatar
      usb: ums: use only 1 buffer for CI_UDC · a022c1e1
      Stephen Warren authored
      ci_udc.c allocates only a single buffer for each endpoint, which
      ci_ep_alloc_request() returns as a hard-coded value rather than
      dynamically allocating. Consequently, storage_common.c must limit
      itself to using a single buffer at a time. Add a special case
      to the definition of FSG_NUM_BUFFERS for this.
      Another option would be to fix ci_ep_alloc_request() to dynamically
      allocate the buffers like some/all(?) other device mode drivers do.
      However, I don't think that ci_ep_queue() supports queueing up
      multiple buffers either yet, and I'm not familiar enough with the
      controller yet to implement that. As such, any attempt to use multiple
      buffers simply results in data corruption and other errors.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
    • Stephen Warren's avatar
      usb: ci_udc: support variants with hostpc register · fcf2ede1
      Stephen Warren authored
      Tegra's USB controller appears to be a variant of the ChipIdea
      controller; perhaps derived from it, or simply a different version of
      the IP core to what U-Boot supports today.
      In this variant, at least the following difference are present:
      - Some registers are moved about.
      - Setup transaction completion is reported in a separate 'epsetupstat'
        register, rather than in 'epstat' (which still exists, perhaps for
        other transaction types).
      - USB connection speed is reported in a separate 'hostpc1_devlc'
        register, rather than 'portsc'.
      - The registers used by ci_udc.c begin at offset 0x130 from the USB
        register base, rather than offset 0x140. However, this is handled
        by the associated EHCI controller driver, since the register address
        is stored in controller.ctrl->hcor.
      Introduce define CONFIG_CI_UDC_HAS_HOSTPC to indicate which variant of
      the controller should be supported. The "HAS_HOSTPC" part of this name
      mirrors the similar "has_hostpc" field used by the Linux EHCI controller
      core to represent the presence/absence of the hostpc1_devlc register.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
    • Stephen Warren's avatar
      usb: ci_udc: make PHY initialization conditional · 0c51dc6d
      Stephen Warren authored
      usb_gadget_register_driver() currently unconditionally programs PORTSC
      to select a ULPI PHY. This is incorrect on at least the Tegra boards I
      am testing with, which use a UTMI PHY for the OTG ports. Make the PHY
      selection code conditional upon the specific EHCI controller that is in
      Ideally, I believe that the PHY initialization code should be part of
      ehci_hcd_init() in the relevant EHCI controller driver, or some board-
      specific function that ehci_hcd_init() calls.
      For MX6, I'm not sure this PHY initialization code is correct even before
      this patch, since ehci-mx6's ehci_hcd_init() already configures PORTSC to
      a board-specific value, and it seems likely that the code in ci_udc.c is
      incorrectly undoing this. Perhaps this is not an issue if the PHY
      selection register bits aren't implemented on this instance of the MX6
      USB controller?
      ehci-mxs.c doens't appear to touch PORTSC, so this code is likely still
      required there.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
    • Stephen Warren's avatar
      usb: ci_udc: set ep->req.actual after transfer · 8aac6e9c
      Stephen Warren authored
      At least drivers/usb/gadget/storage_common.c expects that ep->req.actual
      contain the number of bytes actually transferred. (At least in practice,
      I observed it failing to work correctly unless this was the case).
      However, ci_udc.c modifies ep->req.length instead. I assume that .length
       is supposed to represent the allocated buffer size, whereas .actual is
      supposed to represent the actual number of bytes transferred. In the OUT
      transaction case, this may happen simply because the host sends a smaller
       packet than the max possible size, which is quite legal. In the IN case,
      transferring fewer bytes than requested could presumably happen as an
      Modify handle_ep_complete() to write to .actual rather than modifying
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
    • Stephen Warren's avatar
      usb: ci_udc: Support larger packets · f5c03006
      Stephen Warren authored
      ci_ep_queue() currently only fills in the page0/page1 fields in the
      queue item. If the buffer is larger than 4KiB (unaligned) or 8KiB
      (page-aligned), then this prevents the HW from knowing where to write
      the balance of the data.
      Fix this by initializing all 5 pageN pointers, which allows up to
      16KiB (potentially non-page-aligned) buffers.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
    • Lukasz Majewski's avatar
      dfu:fix: Replace wrong return value with proper one · 672ad18c
      Lukasz Majewski authored
      This patch remove always false (since we tested ret = 0) ternary operator
      with ret value returned.
      Signed-off-by: default avatarLukasz Majewski <l.majewski@samsung.com>
    • andrey.konovalov@linaro.org's avatar
      exynos: usb: Fix data abort on boards w/o vbus-gpio node in the DT · e6e493f3
      andrey.konovalov@linaro.org authored
      Commit 4a271cb1
       doesn't take into account that fdtdec_setup_gpio()
      returns success when the gpio passed to it is FDT_GPIO_NONE (no
      gpio node found in the fdtdec_decode_gpio() call). This results in
      calling gpio_direction_output() on invalid gpio. For this reason
      executing "usb start" command on Arndale causes data abort in the
      ehci-exynos driver.
      Add the fdt_gpio_isvalid() check to fix that problem.
      Signed-off-by: default avatarAndrey Konovalov <andrey.konovalov@linaro.org>
      Cc: Julius Werner <jwerner@chromium.org>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Minkyu Kang <mk7.kang@samsung.com>
      Cc: Marek Vasut <marex@denx.de>