diff options
| author | hqu <hqu@codeaurora.org> | 2018-03-09 21:59:33 +0800 |
|---|---|---|
| committer | Gerrit - the friendly Code Review server <code-review@localhost> | 2018-04-06 11:37:59 -0700 |
| commit | a7e5e49ea1ed895052b9fa4f49a6acca5bd8ee4f (patch) | |
| tree | 17906d1b0a6aaecd13e4a508f31f5a0489b1ef2f /tools/perf/scripts/python | |
| parent | f492575243c78a50fdca7444f52e47088a9b9f7c (diff) | |
qcacld-2.0: Introduce and enable HDD Request Manager infrastructure
propagation from qcacld-3.0 to qcacld-2.0
List qcacld-3.0 changes as following:
"Change-Id: I4e598e51983475318bc668e786aca690a934bd6c",
"Change-Id: I31e268ca02b4b5c2831c540933ee059a27bd9c7e",
"Change-Id: If4d5912710f8a3b5e87adf76f828a646b7cc2983".
Many operations within the wlan driver occur in an asynchronous
manner. Requests are received by HDD via one of the kernel interfaces
(ioctl, nl80211, virtual file system, etc.). The requests are
translated to an internal format and are then passed to lower layers
for processing. For requests which require a response, that response
comes up from the lower layers in a separate thread of execution,
ultimately resulting in a call to a callback function that was
provided by HDD as part of the initial request. So a mechanism is
needed to synchronize the request and response.
Currently there are various mechanisms which perform these
synchronizations, but experience with them has revealed some flaws.
So an universal mechanism is needed to synchronize the request and
response which addresses all of the known flaws. This framework
provides that mechanism. Enable the HDD Request Manager by invoking
the init() and deinit() APIs as appropriate.
Change-Id: Ic4267507dcdbe550d49422bf3e75450ba66021aa
CRs-Fixed: 2205626
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions
