)]}'
{
  "log": [
    {
      "commit": "5c87579e65ee4f419b2369407f82326d38b5d2d8",
      "tree": "3e015ba93eb6eefb7ed4318daf95be0771d596a8",
      "parents": [
        "130c6b98984a058068ea595c465fba2beb48b9ef"
      ],
      "author": {
        "name": "Arjan van de Ven",
        "email": "arjan@linux.intel.com",
        "time": "Sat Sep 30 23:27:17 2006 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Sun Oct 01 00:39:19 2006 -0700"
      },
      "message": "[PATCH] maximum latency tracking infrastructure\n\nAdd infrastructure to track \"maximum allowable latency\" for power saving\npolicies.\n\nThe reason for adding this infrastructure is that power management in the\nidle loop needs to make a tradeoff between latency and power savings\n(deeper power save modes have a longer latency to running code again).  The\ncode that today makes this tradeoff just does a rather simple algorithm;\nhowever this is not good enough: There are devices and use cases where a\nlower latency is required than that the higher power saving states provide.\n An example would be audio playback, but another example is the ipw2100\nwireless driver that right now has a very direct and ugly acpi hook to\ndisable some higher power states randomly when it gets certain types of\nerror.\n\nThe proposed solution is to have an interface where drivers can\n\n* announce the maximum latency (in microseconds) that they can deal with\n* modify this latency\n* give up their constraint\n\nand a function where the code that decides on power saving strategy can\nquery the current global desired maximum.\n\nThis patch has a user of each side: on the consumer side, ACPI is patched\nto use this, on the producer side the ipw2100 driver is patched.\n\nA generic maximum latency is also registered of 2 timer ticks (more and you\nlose accurate time tracking after all).\n\nWhile the existing users of the patch are x86 specific, the infrastructure\nis not.  I\u0027d like to ask the arch maintainers of other architectures if the\ninfrastructure is generic enough for their use (assuming the architecture\nhas such a tradeoff as concept at all), and the sound/multimedia driver\nowners to look at the driver facing API to see if this is something they\ncan use.\n\n[akpm@osdl.org: cleanups]\nSigned-off-by: Arjan van de Ven \u003carjan@linux.intel.com\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\nAcked-by: Jesse Barnes \u003cjesse.barnes@intel.com\u003e\nCc: \"Brown, Len\" \u003clen.brown@intel.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    }
  ]
}