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
|