Fix USB multiplexing to avoid lockups
Attempts to run firmware_FAFTSetup autotest in a continuous loop have
shown that after some time the system comes into a state when swinging
the usb_mux_sel1 multiplexer between DUT and host does not cause the
new USB device in servo port J3 to show up on neither side.
Further investigation has shown that the problem was actually with the
USB flash itself - unplugging it and plugging back in restored its
ability to initialize when the mux is connected to either DUT or host.
One of the reasons for such behavior could be the fact that the
switching process does not power down the USB interface when moving it
between DUT and host and back.
This change modifies the switching code such that every time the USB
flash is reconnected, it is powered off first.
The servo API in servo.py:Servo class is also being modified:
- a new method, switch_usbkey(), is being added to control which side
the USB flash is connected to, instead of direct manipulating of the
multiplexer state. The new method makes sure that proper power
management takes place when reconnecting.
- another new method can be used to find out current state of the USB
flash multiplexer: usb_flash_direction()
- enable_usb_hub() and disable_usb_hub() methods are being removed,
instead of disabling the USB device it is now connected to the host
BUG=chrome-os-partner:15610
TEST=manual
. ran firmware_FAFTSetup autotest more than 50 times in a row,
observed it succeed each run, will leave it running overnight.
. also ran firmware_FwScreenCloseLid, firmware_FwScreenPressPower and
firmware_InvalidUSB tests, they all succeeded
Change-Id: I3aa34c14ec3929762520492587973db4c7b604da
Reviewed-on: https://gerrit.chromium.org/gerrit/39983
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Yusuf Mohsinally <mohsinally@google.com>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
7 files changed