| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Possibility to run the test without having to lunch the 'make install'
command.
Signed-off-by: Adrien M <adrienx.martin@intel.com>
|
| |
|
|
| |
Signed-off-by: David Wagner <david.wagner@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Testing slightly-out-of-range values is failing (i.e. the value seems to be
wrongfully accepted by the parameter-framework) starting from high precisions,
e.g. q0.16.
The cause is:
1) When converting strings to fixed-points, the parameter-framework first
parses the input string as double. Doubles have 52 fraction bits and there for
15 decimal-digits-precision (52 * log10(2) == 15).
2) When displaying Qn.m numbers, we decided to display all representable digits
(i.e. m digits) instead of only displaying significant digits because that
would cause unpredictable behaviour. See
d299108157ee4d0eadb7683b2fa6a6635bc63d95 and
59cc1e33810c55e6fa1e3bd320e1cf29e24d23be for more information.
3) However, the precision for a Qn.m fixed-point number isn't m but
m * log10(2). This is guaranteed to be less than the precision of a double but
the tests mentioned at the beginning were written as if the precision was m,
which may be larger than the precision of a double. This is what caused the
test failures.
The tests are adapted to try and set a value of which the last significant
digit is one-off too far outside of the allowed range.
For lower-precision number, other less-far-off values could be correctly
rejected by the parameter-framework but that's only because of the underlying
implementation (using doubles as intermediate values) and it seems hardly
relevant to check.
Signed-off-by: David Wagner <david.wagner@intel.com>
|
| |
|
|
|
|
|
|
| |
We used to drop errors during "get" operation because it is unlikely to fail
and not in the scope of the fixed-point tests. However, we should catch such
error and abort immediately.
Signed-off-by: David Wagner <david.wagner@intel.com>
|
| |
|
|
|
|
|
| |
Using the python bindings is much faster and easier than using the network
interface.
Signed-off-by: David Wagner <david.wagner@intel.com>
|
| |
|
|
|
|
|
| |
The fixed-point tests are user-input tests. Since a user isn't likely to input
any trailing zeros, let's remove them.
Signed-off-by: David Wagner <david.wagner@intel.com>
|
| |
|
|
|
|
|
| |
The fixed-point tests did not return any error code even upon failure. This
lead to believing that they were passing.
Signed-off-by: David Wagner <david.wagner@intel.com>
|
| |
|
|
|
|
|
|
|
|
| |
The fix point parameter test used to display a warning if
it could not be run.
Transform it to an errors if the tests are explicitly activated
through the BUILD_TESTING option. BUILD_TESTING is declared by ctest.
Signed-off-by: Kevin Rocard <kevin.rocard@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Cmake can manage test with ctest. Running them when make test
is run. Unfortunately the only automatic tests the pfw has
(fix point parameter test) are not declared in cmake.
Add a test target and declare the fix point parameter test in cmake.
Thus a simple make test after the make install will run all tests.
Signed-off-by: Kevin Rocard <kevinx.rocard@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This only makes sense on the Android build system. However, these tests are
broken on Android because libremote-processor is compiled as
"libremote-processor_host.so" on Android whereas libparameter will only try to
load "libremote-processor.so" anyway.
For now, let's ignore the Android build system and only care about how we do it
with CMake: CMake builds libremote-processor.so, test-platform and
remote-process so let's remove the "_host" suffixes that were added for
compatibility with the output of the Android makefiles.
Signed-off-by: David Wagner <david.wagner@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
A lot of parameters were duplicated because we had one parameter for each size
(8, 16 and 32) and for each integral/fractional combination. However, they were
all at the root of the subsystem and a lot overlapped, e.g., q1.2 for 32bits
and q1.2 for 16 bits.
We fix this by:
- Adding a ParameterBlock for each size
- Modifying the tests to account for the change in the parameter paths
- Run the tests for 8, 16 and 32 bits
Signed-off-by: David Wagner <david.wagner@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BZ: 197723
This python script performs several checks on fixed point parameters:
- Bound check: Can we set a value?
- Sanity check: If we get this previously set parameter, is the
value approximately the same? There should be at maximum a
quantum difference between the original value and the returned value.
- Consistency check: Can we set the value we got from the sanity check?
- Bijectivity check: If we get the parameter we set a second time,
is the result the same as the value we got from the set we did in the
Sanity check?
Change-Id: I7b4d61ec740139b0ee70a44b6b38009507a569ee
Signed-off-by: Mattijs Korpershoek <mattijsx.korpershoek@intel.com>
|
|
|
BZ: 197723
This contains the configuration files which contains a lot of fixedpoint
parameters which can be used for testing.
Change-Id: I261120d16eb6f4d28b6b61a5b2845f1fdc18e91f
Signed-off-by: Mattijs Korpershoek <mattijsx.korpershoek@intel.com>
|
