| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The command is used as follows:
importDomainWithSettingsXML <file path> [overwrite]
It reads the file given as first argument (path must be absolute) and imports
the domain found in it.
It does not check whether it overlaps with another domain (same elements in two
domains). It does, however, check if there is an existing domain with the same
name as the one being imported. If so and if the (optional) second argument
is "overwrite", it will first delete the existing domain; if not it will refuse
to import the new domain.
Change-Id: I7aaa225f2f1a296f52dc8a97f55e1ff70c06d567
Signed-off-by: David Wagner <david.wagner@intel.com>
|
|
|
|
|
|
|
|
|
|
| |
This allows diminishing the dependency on the parent element when creating a
Domain element from an XML document: the parent was used to get a handle to the
system class in order to check the existence of ConfigurableElements included
in the Domain.
Change-Id: Icba7c3c4db2b9728c0fb7c6840a254de9775f6a4
Signed-off-by: David Wagner <david.wagner@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Import and Export of ConfigurableDomains have different context needs: e.g. the
value representation is only used for export; auto-validation is only
meaningful for import whereas the "with settings" context is common to both.
We create two new classes, derived from XmlDomainSerializingContext and move
most of its content to each class it belongs to.
Change-Id: I56589cdb3a8ea417e11d2ed98ccd055d7cdead67
Signed-off-by: David Wagner <david.wagner@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.
|
|
|
|
|
|
|
| |
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: 102528
The PFW used to make a lot of useless log during init.
Delete those useless logs.
Change-Id: I9e4cf6461d4eb643444443ea57e90f97f79571a3
Signed-off-by: Kevin Rocard <kevinx.rocard@intel.com>
Reviewed-on: http://android.intel.com:8080/103882
Reviewed-by: cactus <cactus@intel.com>
Reviewed-by: Gonzalve, Sebastien <sebastien.gonzalve@intel.com>
Reviewed-by: Denneulin, Guillaume <guillaume.denneulin@intel.com>
Tested-by: Dixon, CharlesX <charlesx.dixon@intel.com>
Reviewed-by: buildbot <buildbot@intel.com>
Tested-by: buildbot <buildbot@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BZ: 88357
This patch aims to enable direct access to Configurations
without using the main blackboard. 2 additional commands are
available:
- getConfigurationParameter <domain> <configuration> <param path>:
Get value for parameter at given path from configuration.
- setConfigurationParameter <domain> <configuration> <param path> <value>
Set value for parameter at given path to configuration.
Change-Id: I9357ba5141feee558fa3f7c10f62db14406433b6
Signed-off-by: Frédéric Boisnard <fredericx.boisnard@intel.com>
Reviewed-on: http://android.intel.com:8080/92325
Reviewed-by: cactus <cactus@intel.com>
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: 76267
In the case of a hw subsystems reset, it's possible that its
parameter managed by the PFW may not be aligned with the PFW
blackboard.
A re-synchronization mechanism is implemented to ensure that the
subsystem is re-synchronized on the next configurations application.
Change-Id: I032150955d25a7020cf494e69456897b4c157916
Signed-off-by: Guillaume Denneulin <guillaume.denneulin@intel.com>
Reviewed-on: http://android.intel.com:8080/83015
Reviewed-by: Rocard, KevinX <kevinx.rocard@intel.com>
Reviewed-by: Centelles, Sylvain <sylvain.centelles@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: 56118
Update the "status" command of the PFW to display the current pending
configurations for all domains, that is to say configurations that
are waiting the next call to "applyConfiguration()" to be applied.
This improvement will help developers to better understand
the current state of the PFW, in particular when dealing with HAL
modifications.
Change-Id: I6300620ad8cedcb534fb2859b57b7ab2988fa618
Signed-off-by: Frédéric Boisnard <fredericx.boisnard@intel.com>
Reviewed-on: http://android.intel.com:8080/64796
Reviewed-by: De Chivre, Renaud <renaud.de.chivre@intel.com>
Reviewed-by: Benavoli, Patrick <patrick.benavoli@intel.com>
Reviewed-by: Rocard, KevinX <kevinx.rocard@intel.com>
Tested-by: Barthes, FabienX <fabienx.barthes@intel.com>
Reviewed-by: buildbot <buildbot@intel.com>
Tested-by: buildbot <buildbot@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: 44148
The save and restore operation would not work correctly when BitParameters
of a BitParameterBlock were used in more than a single Domain.
This patch aims to fixup this bug and introduces a new class: BitwiseAreaConfiguration.
Change-Id: I0aaccd57cf1cce33400f94a8879565171d283425
Orig-Change-Id: I7107f7db9f01cfff3c38cbac606a8c1e9bca8b5e
Signed-off-by: Frédéric Boisnard <fredericx.boisnard@intel.com>
Reviewed-on: http://android.intel.com:8080/58363
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: 15689
These changes enable handling changing the rules for configuration application
from the command line interface.
It is possible to assign a new rule, to display the existing one or to clear
it.
Restriction: like in XML, root rule must be compound.
Syntax is the following:
- Criterion rule expression:
<criterion> <verb> <object>
- Compound rule expression
(All|Any){<content>}
where <content> is a comma separated list of any kind of rules.
Example:
All{Any{SelectedOutputDevice Includes Headphones, SelectedOutputDevice
Includes Headset}, Any{Mode Is Normal, Mode Is RingTone}}
means the pertaining configuration will be applied when Selected device
includes either Headphones or Headset, while, ate the same time, Mode is
either Normal or RingTone.
Added dumpDomains remote command to show a summary of domains, configurations
as well as their application conditions (tree view).
Removed not anymore necessary guard against deletion of domains or
configurations that contain rules, ad now they're controlled from the CLI.
Change-Id: Iad2c183271b077b8bbc8ac2fc5f37c266004070f
Signed-off-by: Patrick Benavoli <patrickx.benavoli@intel.com>
Reviewed-on: http://android.intel.com:8080/26100
Reviewed-by: De Chivre, RenaudX <renaudx.de.chivre@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: 13152
- Introduced sequence notion in configurations:
Sequences are configuration specific and are controlled from the Settings
related XML files (order of settings appearance) as well as from the tuning
interface (new commands available to set and get the sequence
(setElementSequence / getElementSequence).
Notes:
- sequences will only matter for domains which new "SequenceAware"
attribute is set to true (false by default). This attribute is also
controlable through the tuning interface (setSequenceAware / getSequenceAware
commands).
- sequence unaware domain configurations will be applied before
sequence aware ones.
To allow for such functionality, the XML for settings format had to be
reworked, leading to an unfortunate compatibility break. However, one benefit
is that now a clear Settings section appears at the bottom of the domain
description, which is easier to maintain than the previous structure where the
settings appeared as sub-nodes of associated elements.
Change-Id: Ic93552fd510ed8847f9c8e7d9d6164f7ea3c8c45
Signed-off-by: Patrick Benavoli <patrickx.benavoli@intel.com>
Reviewed-on: http://android.intel.com:8080/22558
Reviewed-by: Centelles, Sylvain <sylvain.centelles@intel.com>
Tested-by: Barthes, FabienX <fabienx.barthes@intel.com>
Reviewed-by: buildbot <buildbot@intel.com>
Tested-by: buildbot <buildbot@intel.com>
Reviewed-on: http://android.intel.com:8080/26780
Reviewed-by: Barthes, FabienX <fabienx.barthes@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>
|