| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Bug 246391
Change-Id: I662b7b0f90c97cb169978e1b64ad1fe32c440cf5
Signed-off-by: Jean-Michel Trivi <jmtrivi@google.com>
|
|
|
|
| |
Signed-off-by: David Wagner <david.wagner@intel.com>
|
|
|
|
| |
Signed-off-by: David Wagner <david.wagner@intel.com>
|
|
|
|
|
|
|
|
| |
This patch removes the type mismatch warnings revealed by Windows 64
compiler. Wherever necessary, used size_t type for size related data.
Change-Id: Ie045ce95940cd83fe8d681168ac9526fc6028d43
Signed-off-by: Patrick Benavoli <patrick.benavoli@intel.com>
|
|
|
|
|
|
|
|
|
| |
Spurious execution mode removed from files:
- parameter/Element.cpp
- utility/convert.hpp
Change-Id: I5d47d505e8c3d9f55ad975c34b51d7caa4905ab9
Signed-off-by: Sebastien Gonzalve <sebastien.gonzalve@intel.com>
|
|
|
|
| |
Signed-off-by: Jules Clero <julesx.clero@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The toXml method has a default implementation that recursively calls toXml on
the children and set their "Name" attribute.
With this approach, the toplevel element's name isn't set unless its overrided
implementation explicitly does so.
A first approach for fixing that is to set the XmlElement's name and
recursively call toXml on children (without setting their name because it will
be done by their toXml method). However, the "CXmlElement" being created may or
may not be the object on which the toXml method is called, in which case the
name will be set on the wrong XmlElement.
Instead, in CElement::toXml, we set the XmlElement's name and call a new
virtual method, childrenToXml which only recursively call toXml on children.
This gives full flexibility to elements to choose how they want to serialize
themselves and how they want to serialize their children.
CConfigurableDomain::toXml is modified to take that change into account.
Change-Id: Id12a1023e91cb000e55c242c13643b1db7d46871
Signed-off-by: David Wagner <david.wagner@intel.com>
|
|
|
|
|
| |
This is a bad practice to have using in headers because it pollutes the
namespace of any user of that header.
|
|
|
|
|
|
|
|
|
|
|
|
| |
BZ: 186081
Due to upgrade klocwork (KW version from 9.6 to 10.0)
new issues have been raised.
This patch fix the new issues raised in PFW.
Change-Id: I54c14e4d6da1c9a5f8d82aec1769a9e7e948db50
Signed-off-by: Eduardo Mendi <eduardox.mendi@intel.com>
|
|
|
|
|
|
|
| |
Add license header in all source files and Makefiles,
Add a "COPYING" file containing the license text.
Signed-off-by: David Wagner <david.wagner@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BZ: 168727
In the PFW structure file, it is not possible to include a component
library from another XML file.
Implement the possibility to import component from another XML file
that would be included in a structure XML file and that would
describe a component library.
Change-Id: Id6125140de1c8e9882375d01199f695b929f45e2
Signed-off-by: Guillaume Denneulin <guillaume.denneulin@intel.com>
|
|
|
|
|
|
|
|
|
|
|
| |
BZ: 154623
When logging, the pfw was limited to 512 bytes.
Remove this limitation and optimize the buffer allocated.
Change-Id: I91537f30a519d93a4b1e55a23fe02f42dec3af8a
Signed-off-by: Guillaume Denneulin <guillaume.denneulin@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BZ: 85746
Create a log fonction to log a string table. Use it to call the log
function for each criterion.
Context:
When the PFW starts, it logs the criteria, their states and possible
values. All criterion logs where concatenate in a string and logged.
But if there is a lot of criteria, the 512 chars long log buffer might
be overfload and the log is truncated.
Change-Id: I72c89b25de9314b714763b3ac71a7d0cb9698910
Signed-off-by: Kevin Rocard <kevinx.rocard@intel.com>
Reviewed-on: http://android.intel.com:8080/90089
Reviewed-by: Gonzalve, Sebastien <sebastien.gonzalve@intel.com>
Tested-by: Dixon, CharlesX <charlesx.dixon@intel.com>
Reviewed-by: buildbot <buildbot@intel.com>
Tested-by: buildbot <buildbot@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BZ: 77959
The PFW will log criterion patch state at start before appling
configuration.
Change-Id: I4ac3676b9ba685c1e226a8495ffdbe98f0c08219
Signed-off-by: Kevin Rocard <kevinx.rocard@intel.com>
Reviewed-on: http://android.intel.com:8080/79965
Reviewed-by: De Chivre, Renaud <renaud.de.chivre@intel.com>
Tested-by: Dixon, CharlesX <charlesx.dixon@intel.com>
Reviewed-by: cactus <cactus@intel.com>
Tested-by: cactus <cactus@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BZ: 76263
When synchronization fails, the parameter-framework should
log a warning and continue synchronization instead of stopping
Change-Id: Ic12d8798ea25584db714ee26e644fac793c28881
Signed-off-by: Kevin Rocard <kevinx.rocard@intel.com>
Reviewed-on: http://android.intel.com:8080/81825
Reviewed-by: Centelles, Sylvain <sylvain.centelles@intel.com>
Reviewed-by: Denneulin, Guillaume <guillaume.denneulin@intel.com>
Tested-by: Dixon, CharlesX <charlesx.dixon@intel.com>
Reviewed-by: cactus <cactus@intel.com>
Tested-by: cactus <cactus@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BZ: 59348
bitParameterBlocks are limited to 32 bits, extend it to 64 bits.
This change includes:
- PFW code change
- XML schema update
Change-Id: I9861cea0538a17fcba77fa7d573faae36d8731e0
Signed-off-by: Guillaume Denneulin <guillaume.denneulin@intel.com>
Reviewed-on: http://android.intel.com:8080/68189
Reviewed-by: Gozalvez Herrero, Juan AntonioX <juan.antoniox.gozalvez.herrero@intel.com>
Tested-by: Gozalvez Herrero, Juan AntonioX <juan.antoniox.gozalvez.herrero@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BZ: 47701
As parameter framework code is proprietary, it should not be signed (patrick Benavoli name inside the header).
Change-Id: I198f2851ee2a6cffed64a552fa399b072a0cbd3e
orig-Change-Id: I335ecce2fa22ad11d6fa24f57c7cbbae3423bf1e
Signed-off-by: Kevin Rocard <kevinx.rocard@intel.com>
Reviewed-on: http://android.intel.com:8080/59560
Reviewed-by: Mendi, EduardoX <eduardox.mendi@intel.com>
Tested-by: Mendi, EduardoX <eduardox.mendi@intel.com>
Reviewed-by: buildbot <buildbot@intel.com>
Tested-by: buildbot <buildbot@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BZ: 15069
Adaptation nodes have been added to integer parameter types in the structural
description.
They all convert values between a platform value and the actual parameter
value.
When a conversion node affects the definition of an integer type parameter,
its interface type becomes "double" (instead of integer).
For now only linear adaptation type is supported.
Linear adaptation:
=================
Linear adaptation nodes consists of the following attributes:
- slope numerator (double, default = 1)
- slope denominator (double, defult = 1)
- offset (signed integer, default = 0)
Conversions from user (platform) values to blackboard are done the follwing
way:
blackboard_value = user_value * slope_numerator / slope_denominator + offset
Change-Id: I00abe9ba5961d8e541b616225531bbc7c8b465b0
Signed-off-by: Patrick Benavoli <patrickx.benavoli@intel.com>
Reviewed-on: http://android.intel.com:8080/25407
Reviewed-by: Barthes, FabienX <fabienx.barthes@intel.com>
Tested-by: Barthes, FabienX <fabienx.barthes@intel.com>
Reviewed-by: buildbot <buildbot@intel.com>
Tested-by: buildbot <buildbot@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BZ: 15065
Replaced high level string based parameter access interface with typed ones.
Now hosting platforms that want to control parameters must instantiate a
CParameterHandle object out of the desired parameter path.
CParameterHandle object may be used to access any kind of parameters, whatever
its internal type, whether it's an array or not.
Note that non rogue parameters offer a read access only. Any attempt to write
them will fail.
CParameterHandle objects offer the following kind of parameter accessing
interfaces:
- Boolean
- Integer (signed or unsigned)
- Double
- String
Note that those interfaces are available for scalar as well as for array
parameters.
Not all parameter types support all access kinds. Naturally, array parameters
are only accessed via array interfaces while scalar parameters are managed
through scalar interfaces.
Here's a list of parameter types that may be controlled through each kind of
access interface:
- Boolean access: boolean, bit (bit size must be one);
- Integer access: integer (sign must match), boolean (unsigned access only,
value <= 1), enumerations;
- Double access: for now only fixed points (soon integers will support them
also through platform adaptation objects)
- String access: all parameter types
In addition, cleaned up parameter access related code so as to make it more
generic and reusable.
Changed version to 2.0.0
Change-Id: Ib80868cdb773e90962e48f1f38d2ff0029189815
Signed-off-by: Patrick Benavoli <patrickx.benavoli@intel.com>
Reviewed-on: http://android.intel.com:8080/25406
Reviewed-by: Barthes, FabienX <fabienx.barthes@intel.com>
Tested-by: Barthes, FabienX <fabienx.barthes@intel.com>
Reviewed-by: buildbot <buildbot@intel.com>
Tested-by: buildbot <buildbot@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BZ: 7466
- Min/max values are now correctly computed. They concern integer and fixed point parameters
- tuning mode lock issue solved: created an AutoLock class for safe lock handling
- added configuration files for a demo on Ubuntu environment
- had AMIXER subsystem plugin compliant for derivation
- LPE library: add carriage return on logs
- removed obsolete files
- some cosmetics
Change-Id: Ife7a4799fd48dd4a1ca25dae666c4e453815881e
Orig-Change-Id: I72fc5c1ff6abf638b43266a75bc00e21ad412349
Signed-off-by: Patrick Benavoli <patrickx.benavoli@intel.com>
Reviewed-on: http://android.intel.com:8080/16880
Reviewed-by: Mahe, Erwan <erwan.mahe@intel.com>
Tested-by: Barthes, FabienX <fabienx.barthes@intel.com>
Reviewed-by: buildbot <buildbot@intel.com>
Tested-by: buildbot <buildbot@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BZ: 7137
Added showProperties remote command
Changed EQU to MONO_EQ for CAPTURE paths in LPE Subsystem structure definition
Had to create a generic class for Parameter and BitParameter classes
Change-Id: If6ab97ff002d8ba81df5a4a60bc3eb07dbe14e5e
Orig-Change-Id: I425f81cd414b1c721f5c11169e9a489f5c638ab9
Signed-off-by: Patrick Benavoli <patrickx.benavoli@intel.com>
Reviewed-on: http://android.intel.com:8080/16879
Reviewed-by: Mahe, Erwan <erwan.mahe@intel.com>
Tested-by: Barthes, FabienX <fabienx.barthes@intel.com>
Reviewed-by: buildbot <buildbot@intel.com>
Tested-by: buildbot <buildbot@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BZ: 6721
- Bug correction concerning selection criteria display (inclusive type)
- Adapted XML format to allow for only on parameter to be associated to
a domain
- Removed unused files in parameter project
Change-Id: I9f42d08ff8cb60354714fe3d6b0f0b321ad0a7bf
Orig-Change-Id: I837e553070f5acf2d275082c986ba29433493e31
Signed-off-by: Patrick Benavoli <patrickx.benavoli@intel.com>
Reviewed-on: http://android.intel.com:8080/16878
Reviewed-by: Mahe, Erwan <erwan.mahe@intel.com>
Tested-by: Barthes, FabienX <fabienx.barthes@intel.com>
Reviewed-by: buildbot <buildbot@intel.com>
Tested-by: buildbot <buildbot@intel.com>
|
|
BZ: 6081
Parameter-framework is still-under-development, Intel proprietary,
multi-platform (standard C++, for now only linux, no dependency on
Android) software that allows system-wide parameter management. It
relies on a number of configurations files, from which it knows how
/ when to hand out settings towards the hardware (subsystems) at
runtime.
3 kinds of configuration files are used:
- Structure description files indicating the actual parameter
structure, types, min/max values, data representation.
- Configurable domain description file containing the actual
distribution of parameters over different domains, that is, different
set of configurations, each of which being dynamically activated
based on selection criteria rules that are themselves configurable.
Configurable domains file contain the tuned settings along the tuning
process, that is during the period where the system is being tuned.
- Binary settings file used to store the settings when the tuning
process is complete.
Changing any of those files causes no recompilation of the framework.
This project is based on a open plugin architecture allowing any kind
of subsystems to be handled, whatever their respective Endianness.
It fully relies on the platform SW to provide it with with the
kowledge of exisitng selection criteria (selected device, current
mode), as well as change events that occuring on them, thus
triggering the application of corresponding configuration settings
wherever appropriate.
It supports handling mutliple parameter classes (Audio, Energy
management) through TCP/IP interface.
For now tuning commands can be sent to parameter-framework instances
through a command-line utility, via adb over USB or via ethernet/WIFI.
Change-Id: If7709c464db118f367f953e0824f49cce9fd0402
Orig-Change-Id: I7842e8808a4cfc0c615e0365e6d02101971ae2dc
Signed-off-by: Patrick Benavoli <patrickx.benavoli@intel.com>
Reviewed-on: http://android.intel.com:8080/16877
Reviewed-by: Mahe, Erwan <erwan.mahe@intel.com>
Tested-by: Barthes, FabienX <fabienx.barthes@intel.com>
Reviewed-by: buildbot <buildbot@intel.com>
Tested-by: buildbot <buildbot@intel.com>
|