165 lines
4.3 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.
*/
#define LOG_TAG "common_time"
#include <utils/Log.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.h"
namespace android {
void Timeout::setTimeout(int msec) {
if (msec < 0) {
mSystemEndTime = 0;
return;
}
mSystemEndTime = systemTime() + (static_cast<nsecs_t>(msec) * 1000000);
}
int Timeout::msecTillTimeout(nsecs_t nowTime) {
if (!mSystemEndTime) {
return -1;
}
if (mSystemEndTime < nowTime) {
return 0;
}
nsecs_t delta = mSystemEndTime - nowTime;
delta += 999999;
delta /= 1000000;
if (delta > 0x7FFFFFFF) {
return 0x7FFFFFFF;
}
return static_cast<int>(delta);
}
LogRing::LogRing(const char* header, size_t entries)
: mSize(entries)
, mWr(0)
, mIsFull(false)
, mHeader(header) {
mRingBuffer = new Entry[mSize];
if (NULL == mRingBuffer)
ALOGE("Failed to allocate log ring with %u entries.", mSize);
}
LogRing::~LogRing() {
if (NULL != mRingBuffer)
delete[] mRingBuffer;
}
void LogRing::log(int prio, const char* tag, const char* fmt, ...) {
va_list argp;
va_start(argp, fmt);
internalLog(prio, tag, fmt, argp);
va_end(argp);
}
void LogRing::log(const char* fmt, ...) {
va_list argp;
va_start(argp, fmt);
internalLog(0, NULL, fmt, argp);
va_end(argp);
}
void LogRing::internalLog(int prio,
const char* tag,
const char* fmt,
va_list argp) {
if (NULL != mRingBuffer) {
Mutex::Autolock lock(&mLock);
String8 s(String8::formatV(fmt, argp));
Entry* last = NULL;
if (mIsFull || mWr)
last = &(mRingBuffer[(mWr + mSize - 1) % mSize]);
if ((NULL != last) && !last->s.compare(s)) {
gettimeofday(&(last->last_ts), NULL);
++last->count;
} else {
gettimeofday(&mRingBuffer[mWr].first_ts, NULL);
mRingBuffer[mWr].last_ts = mRingBuffer[mWr].first_ts;
mRingBuffer[mWr].count = 1;
mRingBuffer[mWr].s.setTo(s);
mWr = (mWr + 1) % mSize;
if (!mWr)
mIsFull = true;
}
}
if (NULL != tag)
LOG_PRI_VA(prio, tag, fmt, argp);
}
void LogRing::dumpLog(int fd) {
if (NULL == mRingBuffer)
return;
Mutex::Autolock lock(&mLock);
if (!mWr && !mIsFull)
return;
char buf[1024];
int res;
size_t start = mIsFull ? mWr : 0;
size_t count = mIsFull ? mSize : mWr;
static const char* kTimeFmt = "%a %b %d %Y %H:%M:%S";
res = snprintf(buf, sizeof(buf), "\n%s\n", mHeader);
if (res > 0)
write(fd, buf, res);
for (size_t i = 0; i < count; ++i) {
struct tm t;
char timebuf[64];
char repbuf[96];
size_t ndx = (start + i) % mSize;
if (1 != mRingBuffer[ndx].count) {
localtime_r(&mRingBuffer[ndx].last_ts.tv_sec, &t);
strftime(timebuf, sizeof(timebuf), kTimeFmt, &t);
snprintf(repbuf, sizeof(repbuf),
" (repeated %d times, last was %s.%03ld)",
mRingBuffer[ndx].count,
timebuf,
mRingBuffer[ndx].last_ts.tv_usec / 1000);
repbuf[sizeof(repbuf) - 1] = 0;
} else {
repbuf[0] = 0;
}
localtime_r(&mRingBuffer[ndx].first_ts.tv_sec, &t);
strftime(timebuf, sizeof(timebuf), kTimeFmt, &t);
res = snprintf(buf, sizeof(buf), "[%2d] %s.%03ld :: %s%s\n",
i, timebuf,
mRingBuffer[ndx].first_ts.tv_usec / 1000,
mRingBuffer[ndx].s.string(),
repbuf);
if (res > 0)
write(fd, buf, res);
}
}
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