Skip to content
Snippets Groups Projects
  1. May 13, 2014
  2. May 09, 2014
  3. May 06, 2014
  4. May 05, 2014
  5. May 02, 2014
  6. May 01, 2014
    • 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
      implementation?
      
      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>
      2fc5dab2
  7. Apr 30, 2014
    • 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>
      a022c1e1
Loading