1. 12 Aug, 2016 5 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 3 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