1. 12 Aug, 2016 2 commits
  2. 11 Aug, 2016 7 commits
  3. 10 Aug, 2016 9 commits
  4. 06 Aug, 2016 1 commit
  5. 05 Aug, 2016 3 commits
  6. 04 Aug, 2016 12 commits
  7. 03 Aug, 2016 6 commits
    • Vaibhav Hiremath's avatar
      greybus: arche-platform: Add support for SPI bus sharing for Mihi · 921dbe52
      Vaibhav Hiremath authored
      In case of Mihi, SPI bus is shared between APB1 and APB2
      SPI ROMs, so their FW flashing must be sequential and
      arche-platform driver should make sure that they are mutual
      exclusive in nature.
      
      So this patch adds certain restrictions to the user of the
      arche-platform driver,
      
       - User can no longer flash APB1 and APB2 SPI ROM in parallel
       - SPI bus becomes an resource, so user must claim it by moving
         respective APB device into FW_FLASHING mode and release it
         by exiting FW_FLASHING mode. User can exit FW_FLASHING mode by
         switching to any other modes (ACTIVE, OFF, STANDBY).
       - If APB1 is in FW_FLASHING mode, APB2 can no longer enter into
         FW_FLASHING mode. User will get -EBUSY.
      
      Having said that, while APB1 is into FW_FLASHING mode,
      APB2 can independently boot from its own SPI ROM.
      
      Testing Done: Tested by simulating usecase on EVT2.
       - Made sure that APB1 and APB2 FW_FLASHING mode is mutual exclusive
         in nature. Confirmed that an attempt on second device return -EBUSY.
       - Added simulating code, where printed state of dummy gpio for
         spi-en and verified that it shows right pin status for both APBs
      Signed-off-by: default avatarVaibhav Hiremath <vaibhav.hiremath@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      921dbe52
    • Vaibhav Hiremath's avatar
      greybus: arche-platform: Reset SVC & APB only if turned off by SUSPEND_PREPARE · 8ef0b538
      Vaibhav Hiremath authored
      There is possible race condition in arche platform driver for
      maintaining of ->state field, when shared with timesync driver.
      
      Assume device booted fine, all connected modules have been enumerated
      correctly. As part of suspend-resume operation we have pm_notifier
      callback, where we turn off SVC & APB and coldboot on resume.
      In the process of resume, all modules gets enumerated again, and
      timesync driver does come into picture everytime.
      So when timesync driver requests arche-platform to change the state
      to TIMESYNC and in the middle of sync operation, if suspend gets
      triggered, then execution lands into arche-platform->pm_notifier callback,
      leading to race condition in the driver, where it checks for (state != ACTIVE)
      in PM_SUSPEND_PREPARE and returns, but in PM_POST_SUSPEND it just simply
      coldboots SVC & APB, which would inbalance all resources (including IRQ).
      
      So we need a add check in PM_POST_SUSPEND, to make sure that, we only
      coldboot devices if they are in to off state,
      i.e. if (state != OFF) then return.
      
      Testing Done: Done regressive suspend/resume testing on EVT2 platform.
      Note that, I some time hit issue.
      Signed-off-by: default avatarVaibhav Hiremath <vaibhav.hiremath@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      8ef0b538
    • Johan Hovold's avatar
      greybus: es2: rename USB vendor-request timeout define · 60793c9b
      Johan Hovold authored
      Give the USB vendor-request timeout define a more descriptive name.
      
      Also drop the since-long obsolete comments about allowing "the SVC to do
      something" and "SVC messages go down our control pipe".
      Signed-off-by: default avatarJohan Hovold <johan@hovoldconsulting.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      60793c9b
    • Johan Hovold's avatar
      greybus: es2: add define for ARPC CPort requests · 54f34e1e
      Johan Hovold authored
      Add dedicated define for ARPC CPort requests instead of using the
      default timeout for USB vendor requests.
      
      We still allow responses to take 500 ms to arrive, but note that this
      adds on top of the 500ms already allowed for a requests to be
      acknowledged. This should probably be tightened up at some point.
      Signed-off-by: default avatarJohan Hovold <johan@hovoldconsulting.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      54f34e1e
    • Johan Hovold's avatar
      greybus: es2: allow ARPC result to be ignored · 121bae2b
      Johan Hovold authored
      Allow user of ARPC to pass a NULL pointer for the ARPC result.
      
      For simple requests there may only be one error code for remote errors,
      or the caller may simply not care to differentiate them.
      Signed-off-by: default avatarJohan Hovold <johan@hovoldconsulting.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      121bae2b
    • Johan Hovold's avatar
      greybus: es2: always set result value · 4ae2d962
      Johan Hovold authored
      Make sure to always set the result value for ARPC instead of forcing
      every caller to do it in order to avoid compiler warnings.
      
      The ARPC result should still be ignored unless arpc_sync returns
      -EREMOTEIO.
      Signed-off-by: default avatarJohan Hovold <johan@hovoldconsulting.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      4ae2d962