This change stores the period size (fraction of the pipe buffer size)
in the submix device's configuration which is then used to calculate
the input and output stream buffer size.
In addition, accessors for the input / output stream format have been
modified to use the pipe format in the device configuration rather than
returning hard coded values.
Bug: 11273000
Change-Id: I9c14f8d549f4b4a6d7f77a9aeab4edfa5ba6bd1a
This change cleans up casting from contained to container structures.
Such that if..
struct child {
struct parent;
int child_data;
};
is changed to...
struct child {
int child_data;
struct parent;
};
functions that cast from "parent" to "child" will continue to function
correctly.
Change-Id: I88d70930d4d4df2e291239e562971b07d8b92f94
Follow up from change Ibe4300275286ef275b2097534c84f1029d761d87
which extends comments to the nfc_nci_module_t and nfc_nci_device_t
structures.
Change-Id: I060bda450912ff3fc041027faa8f03c24e310870
Inheritance of HAL object is performed by composing a child structure of a
single parent structure located at offset 0 followed by new data members
and function pointers in the child structure.
For example,
struct child {
struct parent common;
int a_data_member;
void (*a_method)(struct child *c, int v);
};
HAL code assumes this layout when accessing child structures given a pointer
to a parent structure such that users write code like the following...
void child_method(struct *parent, int v) {
struct child * c = (struct child*)parent;
// do stuff with c
}
Code above will break if a member is added before "common" in "struct child".
This change adds comments that describe the restriction on the location of
parent HAL objects within a derived HAL object. HAL objects that already
have comments that describe the required location of parent objects are not
modified.
Change-Id: Ibe4300275286ef275b2097534c84f1029d761d87
Along with the following minor changes:
* Fixed all referenced variable compiler warnings.
* Ordered headers in alphabetical order.
Change-Id: I122ef67d25b78056a60b85baf897005293a9efa0
The existing API exposed to clients for software lock/unlock forces the gralloc
implementation to complete these operations synchronously. This change adds new
entry points for lock/unlock functionality that is suited for use with Android's
explicit synchronisation concept. This provides scope for the gralloc module
to internally optimise the work it must do for lock/unlock and to hide this cost
from the client.
Change-Id: If4b1bb5490ab2b20d796214a7da8a96427cfe52d
The existing API exposed to clients for software lock/unlock forces the gralloc
implementation to complete these operations synchronously. This change adds new
entry points for lock/unlock functionality that is suited for use with Android's
explicit synchronisation concept. This provides scope for the gralloc module
to internally optimise the work it must do for lock/unlock and to hide this cost
from the client.
Change-Id: I6c41f4a532b705fc76c7777b2f04ea293506b381
