1. 09 May, 2016 3 commits
    • Viresh Kumar's avatar
      greybus: bootrom: Implement timeouts to detect Module failures · a956d939
      Viresh Kumar authored
      Its possible that the Module may fail to download the next stage
      firmware, or to jump into it and boot into the new personality.
      
      We have already seen examples of both of these cases on EVT 1.5.
      
      This patch implements timeouts in the bootrom bundle driver, which now
      expects the next request from the Module to be received at the AP within
      1 second of the previous request/response. The time interval can be
      increased later if required.
      
      The timeouts are added between:
      - AP_READY and FIRMWARE_SIZE operations
      - FIRMWARE_SIZE and GET_FIRMWARE operations
      - Two GET_FIRMWARE operations
      - GET_FIRMWARE and READY_TO_BOOT operations
      - READY_TO_BOOT operation and the call to the ->disconnect() event of
        the bootrom bundle (once the new hotplug request is received).
      
      The timeout for the last case is kept at 5 seconds right now (random
      value), as it may take a bit longer.
      
      Because 'bootrom->fw' can be accessed simultaneously (from timeout
      handler and incoming requests) and one of them can potentially free the
      '->fw' structure, a mutex is also added to take care of such races while
      accessing 'bootrom->fw' structure.
      
      Also note that the '!bootrom->fw' check is moved to free_firmware()
      routine.
      
      Note that this version uses delayed-work (instead of timers used in
      earlier attempt), as we need to call routines that can sleep from the
      timeout handler.
      
      Tested on EVT 1.5, by faking errors on certain requests, so that the
      bootrom doesn't send any more requests. Normal case is working just fine
      for audio and GP modules. This is tested with build arche_440.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      a956d939
    • Jeffrey Carlyle's avatar
      greybus: svc: implement svc_intf_activate · 140026b3
      Jeffrey Carlyle authored
      With upcoming firmware changes we will switch from an SVC-driven module
      boot sequence to an AP-driven module sequence. This operation allows the
      AP to request the SVC to boot a module to which the AP has previouslt
      requested power be applied. This operation will also determine if the
      remote interface is a dummy module, UniPro-only module, or full Greybus
      module.
      
      Testing done: Tested together with "new" firmware boot sequence to
                    verify that modules are detected and booted as expected.
      Signed-off-by: default avatarJeffrey Carlyle <jcarlyle@google.com>
      Reviewed-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      140026b3
    • Jeffrey Carlyle's avatar
      greybus: svc: implement svc_intf_{vsys,refclk,unipro}_{enable,disable} operations · 144763bf
      Jeffrey Carlyle authored
      Add SVC operations for fine grain control over vsys, refclk, and unipro
      port power.
      
      Testing done: used "new" firmware boot sequence to verify that modules
                    were correctly detected and booted.
      Signed-off-by: default avatarJeffrey Carlyle <jcarlyle@google.com>
      Reviewed-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      144763bf
  2. 06 May, 2016 1 commit
  3. 05 May, 2016 24 commits
  4. 04 May, 2016 8 commits
  5. 29 Apr, 2016 4 commits