)]}'
{
  "commit": "40a5f8be2f482783de0f1f0fe856660e489734a8",
  "tree": "69c29c6d0fb16829fba230d800901611cbc7852a",
  "parents": [
    "767c0f3aed74be56f268709f5347e6c86d52b408"
  ],
  "author": {
    "name": "Rafael J. Wysocki",
    "email": "rjw@sisk.pl",
    "time": "Fri Dec 23 01:23:52 2011 +0100"
  },
  "committer": {
    "name": "Rafael J. Wysocki",
    "email": "rjw@sisk.pl",
    "time": "Sun Dec 25 23:39:41 2011 +0100"
  },
  "message": "PM / QoS: Introduce dev_pm_qos_add_ancestor_request()\n\nSome devices, like the I2C controller on SH7372, are not\nnecessary for providing power to their children or forwarding\nwakeup signals (and generally interrupts) from them.  They are\nonly needed by their children when there\u0027s some data to transfer,\nso they may be suspended for the majority of time and resumed\non demand, when the children have data to send or receive.  For this\npurpose, however, their power.ignore_children flags have to be set,\nor the PM core wouldn\u0027t allow them to be suspended while their\nchildren were active.\n\nUnfortunately, in some situations it may take too much time to\nresume such devices so that they can assist their children in\ntransferring data.  For example, if such a device belongs to a PM\ndomain which goes to the \"power off\" state when that device is\nsuspended, it may take too much time to restore power to the\ndomain in response to the request from one of the device\u0027s\nchildren.  In that case, if the parent\u0027s resume time is critical,\nthe domain should stay in the \"power on\" state, although it still may\nbe desirable to power manage the parent itself (e.g. by manipulating\nits clock).\n\nIn general, device PM QoS may be used to address this problem.\nNamely, if the device\u0027s children added PM QoS latency constraints\nfor it, they would be able to prevent it from being put into an\noverly deep low-power state.  However, in some cases the devices\nneeding to be serviced are not the immediate children of a\n\"children-ignoring\" device, but its grandchildren or even less\ndirect descendants.  In those cases, the entity wanting to add a\nPM QoS request for a given device\u0027s ancestor that ignores its\nchildren will have to find it in the first place, so introduce a new\nhelper function that may be used to achieve that.  This function,\ndev_pm_qos_add_ancestor_request(), will search for the first\nancestor of the given device whose power.ignore_children flag is\nset and will add a device PM QoS latency request for that ancestor\non behalf of the caller.  The request added this way may be removed\nwith the help of dev_pm_qos_remove_request() in the future, like\nany other device PM QoS latency request.\n\nSigned-off-by: Rafael J. Wysocki \u003crjw@sisk.pl\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "86de6c50fc4181f796c5d0e3d20e796380f112b0",
      "old_mode": 33188,
      "old_path": "drivers/base/power/qos.c",
      "new_id": "edf7687615e83b0ea0128a9f306c3a1bebc6bb3c",
      "new_mode": 33188,
      "new_path": "drivers/base/power/qos.c"
    },
    {
      "type": "modify",
      "old_id": "83b0ea302a8077a84c0eff688ff3322202a266f2",
      "old_mode": 33188,
      "old_path": "include/linux/pm_qos.h",
      "new_id": "fe247b33652d13cbb30faed2e8e9b7628d71a167",
      "new_mode": 33188,
      "new_path": "include/linux/pm_qos.h"
    }
  ]
}