An error occurred fetching the project authors.
  1. 18 Nov, 2014 17 commits
    • Alex Elder's avatar
      greybus: cancel buffers via magic cookie · a9163b2c
      Alex Elder authored
      Change the interface for canceling in-flight buffers to take a magic
      cookie value as argument rather than a gbuf.  Right now we pass the
      gbuf->hcd_data pointer that's assumed to have been set by the submit
      routine.  But the next patch will change the submit routine to
      return the cookie to be used, and the caller will be responsible for
      keeping track of it.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      a9163b2c
    • Alex Elder's avatar
      greybus: free space without gbufs · 9ec5411a
      Alex Elder authored
      Switch the host driver free routine to take a pointer to the
      previously-allocated buffer that should be freed.
      
      Rename the method to reflect it's no longer tied to a gbuf.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      9ec5411a
    • Alex Elder's avatar
      greybus: allocate space without gbufs · d2a259f2
      Alex Elder authored
      This begins the transition to buffer allocation that does not rely
      on the gbuf construct.
      
      The host driver allocation routine will return a pointer to the
      buffer to be used, and the caller will be responsible for keeping
      track of that pointer, as well as the requested buffer size.
      
      Rename the allocation method to reflect it's no longer tied to a
      gbuf.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      d2a259f2
    • Alex Elder's avatar
      greybus: fill in destination data at send time · 0f4c808a
      Alex Elder authored
      For ES1 we need to insert the destination CPort id before the data
      to be sent over UniPro.  Currently this is done at the time the
      buffer is created, but there's no need to do so until we're actually
      going to send the content of the buffer.
      
      Move the setting of that destination information into submit_gbuf().
      Note that this allows us to defer initializing a few other gbuf
      fields until after we know the buffer allocation has succeeded.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      0f4c808a
    • Alex Elder's avatar
      greybus: improve data buffer alignment · 06a4a061
      Alex Elder authored
      For ES1 we need to insert the destination CPort id in whatever we
      supply for sending over UniPro.  Currently we allocate one extra
      byte supply the caller with an address that's offset by one from
      the beginning of the allocated space.
      
      As a result we always return a poorly-aligned buffer pointer.
      
      Instead, allocate enough space so that we can return a better
      aligned buffer to the caller.
      
      Notes:
          - It may be that it's more important to supply an aligned
            address to the hardware.
          - We probably need to be more careful about writing into
            these buffers at unaligned offsets anyway.  (E.g., writing
            a 2-byte value at an odd offset can't be assumed to work.)
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      06a4a061
    • Alex Elder's avatar
      greybus: prepend cport byte for all gbufs · 5259ef13
      Alex Elder authored
      Treat communication buffers for both inbound and outbound data the
      same way, prepending a "destination cport id" byte before the data
      in the buffer.  Currently this is done only for outbound data
      buffers.
      
      This isn't needed for inbound data, but handling it this way
      allows the free routine to work without knowing whether the
      buffer was used for sending or receiving.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      5259ef13
    • Alex Elder's avatar
      greybus: fix an allocation flag bug · 4f83b8d3
      Alex Elder authored
      We allocate message buffers with GFP_KERNEL allocation flags if
      possible.  However when an incoming request message is received we
      can be in interrupt context, so we must use GFP_ATOMIC in that case.
      
      The computation of gfp_flags in gb_operation_message_init() is
      wrong.  It is needlessly using GFP_ATOMIC when allocating outbound
      response buffers.  Fix the flawed logic.
      
      Change the name of "data_out" to be "outbound" to be consistent with
      usage elsewhere.  (Data/messages are "inbound" or "outbound";
      requests are "incoming" or "outgoing".)
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      4f83b8d3
    • Alex Elder's avatar
      greybus: kill off the last of gbuf.c · 374e6a26
      Alex Elder authored
      Only three functions remain in "gbuf.c".  Move one of them into
      "connection.c" and the other two into "operation.c".
      
      Some more cleanup is coming that will further straighten out gbufs
      but for now there's no sense in drawing this out any longer.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      374e6a26
    • Alex Elder's avatar
      greybus: kill the gbuf slab cache · 4e5007e5
      Alex Elder authored
      Nobody dynamically allocates gbufs any more, so we can get rid of
      the allocation and free routines, as as the slab cache and its
      related code.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      4e5007e5
    • Alex Elder's avatar
      greybus: embed gbufs into operation message structure · bc46fabc
      Alex Elder authored
      Embed the gbuf structures for operation messages into the message
      structure rather than pointing to a dynamically allocated one.
      
      Use a null gbuf->transfer_buffer pointer rather than a null gbuf
      pointer to indicate an unused gbuf.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      bc46fabc
    • Alex Elder's avatar
      greybus: use null gbuf->transfer_buffer · f7935e33
      Alex Elder authored
      Make sure gbuf->transfer_buffer gets reset to NULL when the buffer
      is freed.  We can leverage that to do a little extra error checking.
      We'll also use a null transfer buffer in the next patch to indicate
      an unused gbuf.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      f7935e33
    • Alex Elder's avatar
      greybus: move gbuf initialization to caller · bb88896e
      Alex Elder authored
      Change greybus_alloc_gbuf() so all it does is allocate the gbuf data
      structure.  Move all of the initialization of the gbuf structure in
      the caller.  Do the inverse in the caller prior to freeing the gbuf
      structure via greybus_free_gbuf().  Use a null gbuf->transfer_buffer
      pointer rather than a null gbuf pointer to indicate an unused gbuf.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      bb88896e
    • Alex Elder's avatar
      greybus: start using struct gb_message · c7f82d5d
      Alex Elder authored
      This converts some of the operation code to start leveraging the
      new gb_message type.  Instead of creating the request and response
      gbufs, we initialize (and tear down with a new function) the
      request and response message structures.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      c7f82d5d
    • Alex Elder's avatar
      greybus: define struct gb_message · 3690a826
      Alex Elder authored
      A Greybus buffer (gbuf) is a generic buffer used for data transfer
      over a Greybus interconnect.  We only ever use gbufs in operations,
      which always involve exactly two of them.  The lifetime of a gbuf is
      therefore directly connected to the lifetime of an operation, so
      there no real need to manage gbufs separate from operations.
      
      This patch begins the process of removing the gbuf abstraction, on
      favor of a new data type, gb_message.  The purpose of a gb_message
      is--like a gbuf--to represent data to be transferred over Greybus.
      However a gb_message is oriented toward the more restrictive way
      we do Greybus transfers--as operation messages (either a request or
      a response).
      
      This patch simply defines the structure in its initial form, and
      defines the request and response fields in a Greybus operation
      structure as embedded instances of that type.  The gbuf pointer
      is defined within the gb_message structure, and as a result lots
      of code needs to be tweaked to reference the request and response
      gbufs as subfields of the request and response structures.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      3690a826
    • Alex Elder's avatar
      greybus: move the definition of struct gbuf · 3c3cef40
      Alex Elder authored
      We no longer need struct gbuf defined in "greybus.h".  An upcoming
      patch will embed a gbuf struct (not a pointer) into the operation
      structure, and to do that we'll need the struct defined prior to the
      operation.  Just move the gbuf definition into "operation.h".
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      3c3cef40
    • Alex Elder's avatar
      greybus: kill gbuf->kref · 2f528c8b
      Alex Elder authored
      Since there is only ever one reference to a gbuf, we don't need a
      kref to figure out when it can be freed.  Get rid of the kref and
      its supporting code.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      2f528c8b
    • Alex Elder's avatar
      greybus: kill greybus_{get,put}_gbuf() · 6e5dd0bb
      Alex Elder authored
      These functions are never used, so we can get rid of them.
      Since there's no reference-getting function any more, we no
      longer need "gbuf_mutex" to avoid racing gets and puts, so
      get rid of that too.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      6e5dd0bb
  2. 17 Nov, 2014 12 commits
  3. 16 Nov, 2014 1 commit
    • Greg Kroah-Hartman's avatar
      greybus: Greybus UART connection driver · b4be4043
      Greg Kroah-Hartman authored
      Flush out the Greybus UART driver to actually implement greybus
      requests.  The number of Greybus Protocol operations has been reduced
      down to a managable number, and, if you look closely, you will notice it
      follows the CDC ACM USB specification, which can drive UART devices
      quite well, no need for complex UART state changes, leave all of that
      logic up to the firmware, if it wants/needs it.
      
      The Greybus Protocol spec has been updated to match the driver.
      
      TODO: There are 2 requests from the device to the host that need to be
      implemented.  As this isn't fully hooked up in the Greybus core, that is
      not implemented here yet either.
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      b4be4043
  4. 15 Nov, 2014 1 commit
  5. 14 Nov, 2014 9 commits