)]}'
{
  "log": [
    {
      "commit": "d685894212e6dbeac1fda4996903c1da115d49a6",
      "tree": "c52d05c78811e79a869afbcdbe55a906e38f2fa1",
      "parents": [
        "9fa49cc3308f6af593d780581121afc3c1d7e046"
      ],
      "author": {
        "name": "Ying Wang",
        "email": "wangying@google.com",
        "time": "Tue Apr 09 21:54:12 2013 -0700"
      },
      "committer": {
        "name": "Ying Wang",
        "email": "wangying@google.com",
        "time": "Tue Apr 09 21:54:12 2013 -0700"
      },
      "message": "Add liblog\n\nBug: 8580410\nChange-Id: I746aa8258866508c3a725d0773faf4518096548f\n"
    },
    {
      "commit": "c7f57c6f9289d0e3aaecc0bca4ae7b6eed1c93d7",
      "tree": "a3c374452a4a1ea70587b1e356c8233cea537250",
      "parents": [
        "c59c168508542018401ca6149bc41eb809f6399a"
      ],
      "author": {
        "name": "John Grossman",
        "email": "johngro@google.com",
        "time": "Tue Jun 26 12:50:28 2012 -0700"
      },
      "committer": {
        "name": "John Grossman",
        "email": "johngro@google.com",
        "time": "Fri Jun 29 10:22:19 2012 -0700"
      },
      "message": "Fix for bug 6691452\n\nHand merge from ics-aah\n\n\u003e Fix for bug 6691452 : DO NOT MERGE\n\u003e\n\u003e As it so happens, there seem to be panels out there who disapprove of\n\u003e sudden changes in their HDMI clock rate.  In particular, Sony LCD\n\u003e panels made from around 2010-2011 (including the Sony GTV panel) seem\n\u003e to dislike this behavior.  When exposed to a large jump in the clock\n\u003e rate (say from -100pmm to +100ppm in about 30mSec), they seem to\n\u003e panic, blank their audio and video, and then resync.  The whole\n\u003e panic process takes about 2 seconds.\n\u003e\n\u003e The HDMI spec says that its clock jitter requirements are defined by\n\u003e their differential signalling eye diagram requirements relative to an\n\u003e \"Ideal Recovery Clock\" (see section 4.2.3.1 of the HDMI 1.3a spec).\n\u003e Basically, if you pass the eye diagram tests, you pass the clock\n\u003e jitter requirements.  We have determined in lab that even being\n\u003e extremely aggressive in our VCXO rate changes does not come even close\n\u003e to violating the HDMI eye diagrams.  Its just this era of Sony panels\n\u003e which seem to be upset by this behavior.\n\u003e\n\u003e One way or the other, experiments which the GTV devices have seemed to\n\u003e indicate that a full range sweep of the VCXO done in 10mSec steps over\n\u003e anything faster than 190mSec can cause trouble.  Adding a healthy\n\u003e degree of margin to this finding, the fix is to limit the rate of VCXO\n\u003e control change such that it never goes at a rate faster than\n\u003e FullRange/300mSec.\n\u003e\n\u003e Change flagged as do not merge due to the code structure changes to master.\n\u003e This will need to be merged by hand.\n\u003e\n\u003e Signed-off-by: John Grossman \u003cjohngro@google.com\u003e\n\u003e Change-Id: Ibfd361fe1cc2cbd4909489e3317fb12e005c6a75\n\nChange-Id: If62f791c826f1145262a6b546b1dc1f9776c37d8\nSigned-off-by: John Grossman \u003cjohngro@google.com\u003e\n"
    },
    {
      "commit": "11bc45fcba96cf7ccc5f67b3c47088c2c89c8e7a",
      "tree": "695a1b922cd01ddac3afdda7e2ac46fa8d74020d",
      "parents": [
        "30e2fbe0d2565952928feaf9d3d9194340113af4"
      ],
      "author": {
        "name": "Kent Ryhorchuk",
        "email": "kryhorchuk@google.com",
        "time": "Mon Feb 13 16:24:29 2012 -0800"
      },
      "committer": {
        "name": "Mike Lockwood",
        "email": "lockwood@google.com",
        "time": "Fri Feb 17 09:46:37 2012 -0800"
      },
      "message": "New clock sync control loop.\n\nChange clock sync control to velicity form PI loop. Tuned for office LAN and\nWiFi conditions, will probably perform better in clean environments.\nImprove packet filtering to prevent clock sync on bad rtt.\nChanged diag interface to take rtt times, P, I, D are no longer supported.\n\nChange-Id: Iad2b26eb44cd222ec5f219b49669e2d6baec9d1c\n"
    },
    {
      "commit": "6c929510474caa14dc9d56826b2c65552861d6b3",
      "tree": "cfa4a959e65db46ae2469104ba5ccdc63e15cd38",
      "parents": [
        "cb46d80d217899e51c3d1ad6fc930d9b61883cf9"
      ],
      "author": {
        "name": "Mike J. Chen",
        "email": "mjchen@google.com",
        "time": "Mon Aug 15 11:59:47 2011 -0700"
      },
      "committer": {
        "name": "John Grossman",
        "email": "johngro@google.com",
        "time": "Thu Feb 16 13:45:10 2012 -0800"
      },
      "message": "Upintegrate the common_time service from ics-aah.\n\nMove the common_time service developed in the ics-aah branch back into\nmaster.\n\nThe common_time service is a small service build to synchronize an\narbitrary timeline amongst peers on a local sub-net.  While running\nand configured, the service will elect a master from the set of\navailable devices within the subnet, define a relationship between the\ncommon_time timeline the local time timeline (provided by the local\ntime HAL), and then attempt to maintain synchronization between common\nand local time by controlling the frequency of the local time clock\nvia the HAL, or by disciplining local time in the digital domain if\nthe local time HAL implementation does not support HW slewing.\n\nOn its own, the native common time service will do nothing until it is\nconfigured.  The CommonTimeManagementService (running out of the\nsystem server process) is responsible for implementing policy\nregarding configuration and operation of the common_time service and\nwill be added in a subsequent CL.\n\nChange-Id: I71292f9b9b1797665865689c4572c9d3a0552f64\nSigned-off-by: John Grossman \u003cjohngro@google.com\u003e\n"
    }
  ]
}