| 79489c4c65d3c8e628991995b4a18f2a81802ee6 |
|
20-Jul-2012 |
John Grossman <johngro@google.com> |
common_time: Turn the logging up to 11
Hand merge from ics-aah
> DO NOT MERGE: common_time: Turn the logging up to 11
>
> Actually, despite the CL title, no addition log messages are being
> sent to logcat. Generally speaking, the common_time service tends to
> be rather quiet from a log perspective. Events related to master
> election and arbitration as well as state changes tend to be
> infrequent in steady state operation. Unfortunately, if there is a
> problem with the system, it frequently gets pushed out of logcat by
> other messages and is missing from the logs when a bugreport is
> finally taken.
>
> This change adds a utility class which can be used to store the last N
> log message in a ring buffer to be dumped later during a dumpsys
> operation. Three internal log buffers were added to the system. One
> to record messages having to do with state transitions. Another was
> added to record traffic relating to master election, and one final
> buffer to record basic data on packets which were received but
> discarded for any reason. During a bugreport, these common_time.clock
> service will be able to dump these messages regardless of the amt of
> other logcat activity, which should assist in debugging long running
> issues.
>
> Change-Id: Ic3bbf7480c8978f9bf82bafaba04cf4586db60cf
> Signed-off-by: John Grossman <johngro@google.com>
Change-Id: If7156d41ce4553d5ba5c3a8e1dd616564a569711
Signed-off-by: John Grossman <johngro@google.com>
/frameworks/base/services/common_time/utils.cpp
|
| c7f57c6f9289d0e3aaecc0bca4ae7b6eed1c93d7 |
|
26-Jun-2012 |
John Grossman <johngro@google.com> |
Fix for bug 6691452
Hand merge from ics-aah
> Fix for bug 6691452 : DO NOT MERGE
>
> As it so happens, there seem to be panels out there who disapprove of
> sudden changes in their HDMI clock rate. In particular, Sony LCD
> panels made from around 2010-2011 (including the Sony GTV panel) seem
> to dislike this behavior. When exposed to a large jump in the clock
> rate (say from -100pmm to +100ppm in about 30mSec), they seem to
> panic, blank their audio and video, and then resync. The whole
> panic process takes about 2 seconds.
>
> The HDMI spec says that its clock jitter requirements are defined by
> their differential signalling eye diagram requirements relative to an
> "Ideal Recovery Clock" (see section 4.2.3.1 of the HDMI 1.3a spec).
> Basically, if you pass the eye diagram tests, you pass the clock
> jitter requirements. We have determined in lab that even being
> extremely aggressive in our VCXO rate changes does not come even close
> to violating the HDMI eye diagrams. Its just this era of Sony panels
> which seem to be upset by this behavior.
>
> One way or the other, experiments which the GTV devices have seemed to
> indicate that a full range sweep of the VCXO done in 10mSec steps over
> anything faster than 190mSec can cause trouble. Adding a healthy
> degree of margin to this finding, the fix is to limit the rate of VCXO
> control change such that it never goes at a rate faster than
> FullRange/300mSec.
>
> Change flagged as do not merge due to the code structure changes to master.
> This will need to be merged by hand.
>
> Signed-off-by: John Grossman <johngro@google.com>
> Change-Id: Ibfd361fe1cc2cbd4909489e3317fb12e005c6a75
Change-Id: If62f791c826f1145262a6b546b1dc1f9776c37d8
Signed-off-by: John Grossman <johngro@google.com>
/frameworks/base/services/common_time/utils.cpp
|