84 lines
2.2 KiB
C
Raw Normal View History

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>
2012-06-26 12:50:28 -07:00
/*
* Copyright (C) 2012 The Android Open Source Project
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#ifndef __UTILS_H__
#define __UTILS_H__
#include <stdint.h>
#include <unistd.h>
#include <utils/String8.h>
#include <utils/threads.h>
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>
2012-06-26 12:50:28 -07:00
#include <utils/Timers.h>
namespace android {
class Timeout {
public:
Timeout() : mSystemEndTime(0) { }
// Set a timeout which should occur msec milliseconds from now.
// Negative values will cancel any current timeout;
void setTimeout(int msec);
// Return the number of milliseconds until the timeout occurs, or -1 if
// no timeout is scheduled.
int msecTillTimeout(nsecs_t nowTime);
int msecTillTimeout() { return msecTillTimeout(systemTime()); }
private:
// The systemTime() at which the timeout will be complete, or 0 if no
// timeout is currently scheduled.
nsecs_t mSystemEndTime;
};
class LogRing {
public:
LogRing(const char* header, size_t entries);
~LogRing();
// Send a log message to logcat as well as storing it in the ring buffer.
void log(int prio, const char* tag, const char* fmt, ...);
// Add a log message the ring buffer, do not send the message to logcat.
void log(const char* fmt, ...);
// Dump the log to an fd (dumpsys style)
void dumpLog(int fd);
private:
class Entry {
public:
uint32_t count;
struct timeval first_ts;
struct timeval last_ts;
String8 s;
};
Mutex mLock;
Entry* mRingBuffer;
size_t mSize;
size_t mWr;
bool mIsFull;
const char* mHeader;
void internalLog(int prio, const char* tag, const char* fmt, va_list va);
};
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>
2012-06-26 12:50:28 -07:00
} // namespace android
#endif // __UTILS_H__