)]}'
{
  "log": [
    {
      "commit": "ab5f299f51259fd2466cf35c89d79bd960e0fc32",
      "tree": "2c8b409511e48e04833b57457acdb98207201b0b",
      "parents": [
        "e4c9d8efe6bdc844071d68960dfa2003c5cf6449"
      ],
      "author": {
        "name": "MyungJoo Ham",
        "email": "myungjoo.ham@samsung.com",
        "time": "Fri Mar 16 21:54:53 2012 +0100"
      },
      "committer": {
        "name": "Rafael J. Wysocki",
        "email": "rjw@sisk.pl",
        "time": "Sat Mar 17 21:51:34 2012 +0100"
      },
      "message": "PM / devfreq: add relation of recommended frequency.\n\nThe semantics of \"target frequency\" given to devfreq driver from\ndevfreq framework has always been interpretted as \"at least\" or GLB\n(greatest lower bound). However, the framework might want the\ndevice driver to limit its max frequency (LUB: least upper bound),\nespecially if it is given by thermal framework (it\u0027s too hot).\n\nThus, the target fuction should have another parameter to express\nwhether the framework wants GLB or LUB. And, the additional parameter,\n\"u32 flags\", does it.\n\nWith the update, devfreq_recommended_opp() is also updated.\n\nSigned-off-by: MyungJoo Ham \u003cmyungjoo.ham@samsung.com\u003e\nSigned-off-by: Kyungmin Park \u003ckyungmin.park@samsung.com\u003e\nReviewed-by: Mike Turquette \u003cmturquette@ti.com\u003e\nSigned-off-by: Rafael J. Wysocki \u003crjw@sisk.pl\u003e\n"
    },
    {
      "commit": "6530b9dea1b7f33eaf79ba625e3a99f2455f3eb1",
      "tree": "70beddf04779d5941ba6ef851b30e02c7fa0c86c",
      "parents": [
        "a95e1f5dbca385908aa4087bb98470b0e0ac58d8"
      ],
      "author": {
        "name": "MyungJoo Ham",
        "email": "myungjoo.ham@samsung.com",
        "time": "Fri Dec 09 16:42:19 2011 +0900"
      },
      "committer": {
        "name": "MyungJoo Ham",
        "email": "myungjoo.ham@samsung.com",
        "time": "Fri Jan 20 10:12:38 2012 +0900"
      },
      "message": "PM / devfreq: add min/max_freq limit requested by users.\n\nThe frequency requested to devfreq device driver from devfreq governors\nis restricted by min_freq and max_freq input.\n\nSigned-off-by: MyungJoo Ham \u003cmyungjoo.ham@samsung.com\u003e\nSigned-off-by: Kyungmin Park \u003ckyungmin.park@samsung.com\u003e\n"
    },
    {
      "commit": "a95e1f5dbca385908aa4087bb98470b0e0ac58d8",
      "tree": "4b661241be03f97bb025457010ac31af11466b8e",
      "parents": [
        "e0d44e8ab06885a5bb980f3d6d4cf64ad430d406"
      ],
      "author": {
        "name": "MyungJoo Ham",
        "email": "myungjoo.ham@samsung.com",
        "time": "Wed Jan 11 17:44:28 2012 +0900"
      },
      "committer": {
        "name": "MyungJoo Ham",
        "email": "myungjoo.ham@samsung.com",
        "time": "Fri Jan 20 10:12:38 2012 +0900"
      },
      "message": "PM / devfreq: fixed syntax errors.\n\nIf devfreq.h was included without CONFIG_PM_DEVFREQ, there has been a\ncompiler error with an additional semicolon added. This patch removes\nthat errorneous semicolon.\n\nSigned-off-by: MyungJoo Ham \u003cmyungjoo.ham@samsung.com\u003e\nSigned-off-by: Kyungmin Park \u003ckyungmin.park@samsung.com\u003e\n"
    },
    {
      "commit": "1a51cfdc4516a6e1f2c1f8a579630a027c30331a",
      "tree": "e5bd9e80887009225f264a1ba84588f733caa8f0",
      "parents": [
        "5f11161675be1351cadb96c83850e20bf5bcdc48"
      ],
      "author": {
        "name": "Jonathan Corbet",
        "email": "corbet@lwn.net",
        "time": "Mon Nov 07 23:54:53 2011 +0100"
      },
      "committer": {
        "name": "Rafael J. Wysocki",
        "email": "rjw@sisk.pl",
        "time": "Mon Nov 07 23:54:53 2011 +0100"
      },
      "message": "PM / devfreq: fix private_data\n\nThe \"private_date\" field in struct devfreq_dev_status almost certainly\nwants to be \"private_data\"; since there are no in-tree users of this\nfunctionality, now seems like an easy time to make the fix.\n\nSigned-off-by: Jonathan Corbet \u003ccorbet@lwn.net\u003e\nSigned-off-by: Rafael J. Wysocki \u003crjw@sisk.pl\u003e\n"
    },
    {
      "commit": "ce26c5bb9569d8b826f01b8620fc16d8da6821e9",
      "tree": "3960fee73ec26f939295c92a231a09abcb4c816e",
      "parents": [
        "9005b65099ee4f14b6be691c4574612fe947531a"
      ],
      "author": {
        "name": "MyungJoo Ham",
        "email": "myungjoo.ham@samsung.com",
        "time": "Sun Oct 02 00:19:34 2011 +0200"
      },
      "committer": {
        "name": "Rafael J. Wysocki",
        "email": "rjw@sisk.pl",
        "time": "Sun Oct 02 00:19:34 2011 +0200"
      },
      "message": "PM / devfreq: Add basic governors\n\nFour cpufreq-like governors are provided as examples.\n\npowersave: use the lowest frequency possible. The user (device) should\nset the polling_ms as 0 because polling is useless for this governor.\n\nperformance: use the highest freqeuncy possible. The user (device)\nshould set the polling_ms as 0 because polling is useless for this\ngovernor.\n\nuserspace: use the user specified frequency stored at\ndevfreq.user_set_freq. With sysfs support in the following patch, a user\nmay set the value with the sysfs interface.\n\nsimple_ondemand: simplified version of cpufreq\u0027s ondemand governor.\n\nWhen a user updates OPP entries (enable/disable/add), OPP framework\nautomatically notifies devfreq to update operating frequency\naccordingly. Thus, devfreq users (device drivers) do not need to update\ndevfreq manually with OPP entry updates or set polling_ms for powersave\n, performance, userspace, or any other \"static\" governors.\n\nNote that these are given only as basic examples for governors and any\ndevices with devfreq may implement their own governors with the drivers\nand use them.\n\nSigned-off-by: MyungJoo Ham \u003cmyungjoo.ham@samsung.com\u003e\nSigned-off-by: Kyungmin Park \u003ckyungmin.park@samsung.com\u003e\nReviewed-by: Mike Turquette \u003cmturquette@ti.com\u003e\nAcked-by: Kevin Hilman \u003ckhilman@ti.com\u003e\nSigned-off-by: Rafael J. Wysocki \u003crjw@sisk.pl\u003e\n"
    },
    {
      "commit": "a3c98b8b2ede1f4230f49f9af7135cd902e71e83",
      "tree": "7016d0409796b8bbe7443b18addd93eaba869d68",
      "parents": [
        "03ca370fbf7b76d6d002380dbdc2cdc2319f9c80"
      ],
      "author": {
        "name": "MyungJoo Ham",
        "email": "myungjoo.ham@samsung.com",
        "time": "Sun Oct 02 00:19:15 2011 +0200"
      },
      "committer": {
        "name": "Rafael J. Wysocki",
        "email": "rjw@sisk.pl",
        "time": "Sun Oct 02 00:19:15 2011 +0200"
      },
      "message": "PM: Introduce devfreq: generic DVFS framework with device-specific OPPs\n\nWith OPPs, a device may have multiple operable frequency and voltage\nsets. However, there can be multiple possible operable sets and a system\nwill need to choose one from them. In order to reduce the power\nconsumption (by reducing frequency and voltage) without affecting the\nperformance too much, a Dynamic Voltage and Frequency Scaling (DVFS)\nscheme may be used.\n\nThis patch introduces the DVFS capability to non-CPU devices with OPPs.\nDVFS is a techique whereby the frequency and supplied voltage of a\ndevice is adjusted on-the-fly. DVFS usually sets the frequency as low\nas possible with given conditions (such as QoS assurance) and adjusts\nvoltage according to the chosen frequency in order to reduce power\nconsumption and heat dissipation.\n\nThe generic DVFS for devices, devfreq, may appear quite similar with\n/drivers/cpufreq.  However, cpufreq does not allow to have multiple\ndevices registered and is not suitable to have multiple heterogenous\ndevices with different (but simple) governors.\n\nNormally, DVFS mechanism controls frequency based on the demand for\nthe device, and then, chooses voltage based on the chosen frequency.\ndevfreq also controls the frequency based on the governor\u0027s frequency\nrecommendation and let OPP pick up the pair of frequency and voltage\nbased on the recommended frequency. Then, the chosen OPP is passed to\ndevice driver\u0027s \"target\" callback.\n\nWhen PM QoS is going to be used with the devfreq device, the device\ndriver should enable OPPs that are appropriate with the current PM QoS\nrequests. In order to do so, the device driver may call opp_enable and\nopp_disable at the notifier callback of PM QoS so that PM QoS\u0027s\nupdate_target() call enables the appropriate OPPs. Note that at least\none of OPPs should be enabled at any time; be careful when there is a\ntransition.\n\nSigned-off-by: MyungJoo Ham \u003cmyungjoo.ham@samsung.com\u003e\nSigned-off-by: Kyungmin Park \u003ckyungmin.park@samsung.com\u003e\nReviewed-by: Mike Turquette \u003cmturquette@ti.com\u003e\nAcked-by: Kevin Hilman \u003ckhilman@ti.com\u003e\nSigned-off-by: Rafael J. Wysocki \u003crjw@sisk.pl\u003e\n"
    }
  ]
}