Commit graph

4 commits

Author SHA1 Message Date
Kevin Tang
8b8602393c Fix for CR 692085, error mapping incorrect in one of the cases
eLOC_CLIENT_FAILURE_INTERNAL returned from loc_api_v02 was mapped
to LOC_API_ADAPTER_ERR_FAILUR, however in loc_eng_start_handle it
is LOC_API_ADAPTER_ERR_GENERAL_FAILURE that is being checked for.
Created a new error ID LOC_API_ADAPTER_ERR_INTERNAL specifically
for this error case.

Change-Id: Ib2ad6e983d6c598ec57f1a2584166da2be95946b
CRs-Fixed: 706520
2015-01-24 15:40:03 +01:00
Kevin Tang
4b98dbfeaa fixing the SSR recovery race condition
There is a race condition where when startFix is
called right at the time when modem or griffon
subsystem is down, GPS HAL doesn't get the correct
error code, and therefore the right handling.

Mapped ENGINE_DOWN to ENGINE_OFFLINE, as they are
the same; and modified loc_eng_start_handler to
update the state upon the right error code.

There is a one problem though. General failure is
also handled as SSR. This is because of an unhandled
race condition in the kernel, so the error code
returned and propagated is not deterministic enough
for us to tell if this is SSR. Until that fix is in
place, we might have to treat general failure as SSR
although the side effect should be none. Only
semantically incorrect.

Change-Id: If93823f08428275da171bb22d73a06e38365585b
CR-Fixed: 692085
2015-01-24 15:39:27 +01:00
Rox-
e80c501630 msm8226-common: Update GPS hal 2014-12-22 00:59:33 +01:00
Robert Rozic
b2ca1464c3 msm8226: Initial commit
Split s3ve3g device tree
2014-12-20 01:57:55 +01:00