)]}'
{
  "commit": "3abd5acfff0111809463bcfd7236a1bdf09e4e2d",
  "tree": "19d2577a3b8dac0b15103baf32a5e2a7b9dc8c1b",
  "parents": [
    "0b0c4c2a6974eae7b96066cb0da35b526fe58468"
  ],
  "author": {
    "name": "Mark A. Greer",
    "email": "mgreer@mvista.com",
    "time": "Wed Apr 15 12:41:54 2009 -0700"
  },
  "committer": {
    "name": "Kevin Hilman",
    "email": "khilman@deeprootsystems.com",
    "time": "Thu May 28 15:17:48 2009 -0700"
  },
  "message": "davinci: Add compare register support to timer code\n\nThe Timer64p timer has 8 compare registers that can\nbe used to generate interrupts when the timer value\nmatches the compare reg\u0027s value.  They do not disturb\nthe timer itself.  This can be useful when there is\nonly one timer available for both clock events and\nclocksource.\n\nWhen enabled, the clocksource remains a continuous\n32-bit counter but the clock event will no longer\nsupport periodic interrupts.  Instead only oneshot\ntimers will be supported and implemented by setting\nthe compare register to the current timer value plus\nthe period that the clock event subsystem is requesting.\n\nCompare registers support is enabled automatically\nwhen the following conditions are met:\n1) The same timer is being used for clock events\n   and clocksource.\n2) The timer is the bottom half (32 bits) of the\n   64-bit timer (hardware limitation).\n3) The the compare register offset and irq are\n   not zero.\n\nSince the timer is always running, there is a hardware\nrace in timer32_config() between reading the current\ntimer value, and adding the period to the current\ntimer value and writing the compare register.\nTesting on a da830 evm board with the timer clocked\nat 24 MHz and the processor clocked at 300 MHz,\nshowed the number of counter ticks to do this ranged\nfrom 20-53 (~1-2.2 usecs) but usually around 41 ticks.\nThis includes some artifacts from collecting the\ninformation.  So, the minimum period should be\nat least 5 usecs to be safe.\n\nThere is also an non-critical lower limit that\nthe period should be since there is no point in\nsetting an event that is much shorter than the\ntime it takes to set the event, and get \u0026 handle\nthe timer interrupt for that event.  There can\nalso be all sorts of delays from activities\noccuring elsewhere in the system (including\nhardware activitis like cache \u0026 TLB management).\nThese are virtually impossible to quantify so a\nminimum period of 50 usecs was chosen.  That will\ncertianly be enough to avoid the actual hardware\nrace but hopefully not large enough to cause\nunreasonably course-grained timers.\n\nSigned-off-by: Mark A. Greer \u003cmgreer@mvista.com\u003e\nSigned-off-by: Kevin Hilman \u003ckhilman@deeprootsystems.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "22db6774487505154c00eb8c7edc0c38bf5a665b",
      "old_mode": 33188,
      "old_path": "arch/arm/mach-davinci/include/mach/common.h",
      "new_id": "715528f0dbdb551162d460581206edca3f0d3651",
      "new_mode": 33188,
      "new_path": "arch/arm/mach-davinci/include/mach/common.h"
    },
    {
      "type": "modify",
      "old_id": "f80ae25a52e4c519efb9f48ec66574c068f37088",
      "old_mode": 33188,
      "old_path": "arch/arm/mach-davinci/time.c",
      "new_id": "fc90d3ee0eba7c3cb87c774257fe268af037a7d5",
      "new_mode": 33188,
      "new_path": "arch/arm/mach-davinci/time.c"
    }
  ]
}