Add a module for controlling and interacting with GPUs. The module
currently supports kgsl/adreno based GPUs. This allows for querying
and setting the governor on the GPU, as well as seeing the frequencies
at which the the GPU can can operate.
Change-Id: I02bb997b51426ddaa13e1f8da375aa4c4a0d341a
Elsewhere in devlib, we strip '\r' characters and then handle it as if
it was just normal unix style '\n'.
However in adb_shell, we have a newline_separator option which defaults
to windows style '\r\n'.
This commit removes the newline_separator() function in the
AdbConnection class, removes the use of this function in execute()
function, and removes the parameter from adb_shell() function.
Instead, in the adb_shell() function, the same action as elsewhere in
devlib is performed: replace('\r\n', '\n').replace('\r', '\n')
Currently if you never call wait_for, the underlying pexpect will not
read bytes from the logcat command's output into the log file. So
when we get into get_log, we need to force it to read all the
already-available bytes.
Once an ACME cape instrument is released, if the stop() method has not
been called by the client code, let's ensure to release the channels by
killing the corresponding iio-caputure process.
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Using a pexpect.spawn object simplifies the LogcatMonitor by removing
the need for a separate thread along with the synchronization that
brings. Since pexpect.spawn creates a logfile that is flushed with
each write, it also removes the need for code to handle flushing.
I originally wrote this to allow more complex features that are made
possible by the pexpect API, however I then discovered those features
are not necessary and did not submit this for merging.
However I then discovered that in Python 2.7,
threading.Event.wait (used in the `wait_for` method) makes the task
uninterriptible (i.e. can't be killed with Ctrl+C/SIGINT), which is
rather frustrating. This issue doesn't arise when using pexpect's
expect method, so that's why I'm submitting this now.
Recently I've been seeing some errors with enabling airplane mode on
hikey960 - firstly I get a 'broken pipe' error followed by a 'cmd:
Can't find service: settings'. This missing boolean was the first
thing I found that had changed wrt. the code I used to use, and
adding it back appears to fix the issue.
'adb logcat -c' has been observed to fail when called twice concurrently. Rather
than requiring all devlib users to fix their usage patterns, let's just delay
whenever clear_logcat is called twice.
Due to the new read_tree_values API, some devlib modules now use
shutils in their __init__, which happens from
Target::connect(). Therefore ensure we have busybox on the target
before we get to that stage.
The previous fix for read_tree_values fixed the issue with sh not
supporting arrays, but looping over paths and counting them. Hover each
count increment requires spawning a subshell. For a large number of paths,
this can eat away any performance benefits of using read_tree_values.
Since we only care whether the count is greater than one, detect that
and break out of the loop early to re-introduce the performance
improvement.
My bash fu was off on my previous list. The output of find was being
treated as a single string, rather than an array of paths; which ment
that the test that there was more than one path returned failed,
resulting in null output not just for empty directories but for
everyting.
This fixes the issue by converting find output to an array.
grep was existing with 1 when passed an empty directory, resulting in
TargetError being raised unless explicitly suppressed with
check_exit_code=False. This case is now fixed to correctly return an
empty dict without error.
read_tree_values bash function has also been optimized to not
unnecessarily run find in a subshell if the path passed to the function
does not exist.
Optimize cpuidle module initialization by using the new Target.grep_values
call to get information about all idle states in a single call to the
target during module intialization, rather lazily fetching them from the
target afterwards.
