<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in Makefile</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>d6948c13 - PM: domains: Move genpd and its governor to the pmdomain subsystem</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#d6948c13</link>
        <description>PM: domains: Move genpd and its governor to the pmdomain subsystemIt seems reasonable to collect the core parts for the generic PM domain,along with its corresponding provider drivers. Therefore let&apos;s move thefiles from drivers/base/power/ to drivers/pmdomain/ and while at it, let&apos;salso rename the files accordingly.Moreover, let&apos;s also update MAINTAINERS to reflect the update.Cc: Kevin Hilman &lt;khilman@kernel.org&gt;Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;Acked-by: Rafael J. Wysocki &lt;rafael@kernel.org&gt;Link: https://lore.kernel.org/r/20231213113305.29098-1-ulf.hansson@linaro.org

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Wed, 13 Dec 2023 11:33:05 +0000</pubDate>
        <dc:creator>Ulf Hansson &lt;ulf.hansson@linaro.org&gt;</dc:creator>
    </item>
<item>
        <title>14e08757 - PM / QoS: Initial kunit test</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#14e08757</link>
        <description>PM / QoS: Initial kunit testThe pm_qos family of APIs are used in relatively difficult to reproducescenarios such as thermal throttling so they benefit from unit testing.Start by adding basic tests from the the freq_qos APIs. It includestests for issues that were brought up on mailing lists:https://patchwork.kernel.org/patch/11252425/#23017005https://patchwork.kernel.org/patch/11253421/Signed-off-by: Leonard Crestez &lt;leonard.crestez@nxp.com&gt;Reviewed-by: Matthias Kaehlcke &lt;mka@chromium.org&gt;Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Tue, 26 Nov 2019 15:17:10 +0000</pubDate>
        <dc:creator>Leonard Crestez &lt;leonard.crestez@nxp.com&gt;</dc:creator>
    </item>
<item>
        <title>c8377adf - PM / wakeup: Show wakeup sources stats in sysfs</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#c8377adf</link>
        <description>PM / wakeup: Show wakeup sources stats in sysfsAdd an ID and a device pointer to &apos;struct wakeup_source&apos;. Use them to toexpose wakeup sources statistics in sysfs under/sys/class/wakeup/wakeup&lt;ID&gt;/*.Co-developed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;Co-developed-by: Stephen Boyd &lt;swboyd@chromium.org&gt;Signed-off-by: Stephen Boyd &lt;swboyd@chromium.org&gt;Signed-off-by: Tri Vo &lt;trong@android.com&gt;Tested-by: Kalesh Singh &lt;kaleshsingh@google.com&gt;Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Wed, 07 Aug 2019 01:48:46 +0000</pubDate>
        <dc:creator>Tri Vo &lt;trong@android.com&gt;</dc:creator>
    </item>
<item>
        <title>b2441318 - License cleanup: add SPDX GPL-2.0 license identifier to files with no license</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#b2441318</link>
        <description>License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseMany source files in the tree are missing licensing information, whichmakes it harder for compliance tools to determine the correct license.By default all files without license information are under the defaultlicense of the kernel, which is GPL version 2.Update the files which contain no license information with the &apos;GPL-2.0&apos;SPDX license identifier.  The SPDX identifier is a legally bindingshorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart andPhilippe Ombredanne.How this work was done:Patches were generated and checked against linux-4.14-rc6 for a subset ofthe use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up caseswhere non-standard license headers were used, and references to licensehad to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied toa file was done in a spreadsheet of side by side results from of theoutput of two independent scanners (ScanCode &amp; Windriver) producing SPDXtag:value files created by Philippe Ombredanne.  Philippe prepared thebase worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 filesassessed.  Kate Stewart did a file by file comparison of the scannerresults in the spreadsheet to determine which SPDX license identifier(s)to be applied to the file. She confirmed any determination that was notimmediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained &gt;5   lines of source - File already had some variant of a license header in it (even if &lt;5   lines).All documentation files were explicitly excluded.The following heuristics were used to determine which SPDX licenseidentifiers to apply. - when both scanners couldn&apos;t find any license traces, file was   considered to have no license information in it, and the top level   COPYING file license applied.   For non */uapi/* files that summary was:   SPDX license identifier                            # files   ---------------------------------------------------|-------   GPL-2.0                                              11139   and resulted in the first patch in this series.   If that file was a */uapi/* path one, it was &quot;GPL-2.0 WITH   Linux-syscall-note&quot; otherwise it was &quot;GPL-2.0&quot;.  Results of that was:   SPDX license identifier                            # files   ---------------------------------------------------|-------   GPL-2.0 WITH Linux-syscall-note                        930   and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one   of the */uapi/* ones, it was denoted with the Linux-syscall-note if   any GPL family license was found in the file or had no licensing in   it (per prior point).  Results summary:   SPDX license identifier                            # files   ---------------------------------------------------|------   GPL-2.0 WITH Linux-syscall-note                       270   GPL-2.0+ WITH Linux-syscall-note                      169   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17   LGPL-2.1+ WITH Linux-syscall-note                      15   GPL-1.0+ WITH Linux-syscall-note                       14   ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5   LGPL-2.0+ WITH Linux-syscall-note                       4   LGPL-2.1 WITH Linux-syscall-note                        3   ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3   ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1   and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became   the concluded license(s). - when there was disagreement between the two scanners (one detected a   license but the other didn&apos;t, or they both detected different   licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file   resulted in a clear resolution of the license that should apply (and   which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was   confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier,   the file was flagged for further research and to be revisited later   in time.In total, over 70 hours of logged manual review was done on thespreadsheet to determine the SPDX license identifiers to apply to thesource files by Kate, Philippe, Thomas and, in some cases, confirmationby lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base fromFOSSology, and compared selected files where the other two scannersdisagreed against that SPDX file, to see if there was new insights.  TheWindriver scanner is based on an older version of FOSSology in part, sothey are related.Thomas did random spot checks in about 500 files from the spreadsheetsfor the uapi headers and agreed with SPDX license identifier in thefiles he inspected. For the non-uapi files Thomas did random spot checksin about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to havecopy/paste license identifier errors, and have been fixed to reflect thecorrect identifier.Additionally Philippe spent 10 hours this week doing a detailed manualinspection and review of the 12,461 patched files from the initial patchversion early this week with: - a full scancode scan run, collecting the matched texts, detected   license ids and scores - reviewing anything where there was a license detected (about 500+   files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license   was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied   SPDX license was correctThis produced a worksheet with 20 files needing minor correction.  Thisworksheet was then exported into 3 different .csv files for thedifferent types of files to be modified.These .csv files were then reviewed by Greg.  Thomas wrote a script toparse the csv files and add the proper SPDX tag to the file, in theformat that the file expected.  This script was further refined by Gregbased on the output to detect more types of files automatically and todistinguish between header and source .c files (which need differentcomment types.)  Finally Greg ran the script using the .csv files togenerate the patches.Reviewed-by: Kate Stewart &lt;kstewart@linuxfoundation.org&gt;Reviewed-by: Philippe Ombredanne &lt;pombredanne@nexb.com&gt;Reviewed-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Wed, 01 Nov 2017 14:07:57 +0000</pubDate>
        <dc:creator>Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;</dc:creator>
    </item>
<item>
        <title>7813dd6f - PM / OPP: Move the OPP directory out of power/</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#7813dd6f</link>
        <description>PM / OPP: Move the OPP directory out of power/The drivers/base/power/ directory is special and contains code relatedto power management core like system suspend/resume, hibernation, etc.It was fine to keep the OPP code inside it when we had just one file forit, but it is growing now and already has a directory for itself.Lets move it directly under drivers/ directory, just like cpufreq andcpuidle.Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;Acked-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Tue, 26 Sep 2017 22:12:40 +0000</pubDate>
        <dc:creator>Viresh Kumar &lt;viresh.kumar@linaro.org&gt;</dc:creator>
    </item>
<item>
        <title>33692dc3 - PM / OPP: Move opp core to its own directory</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#33692dc3</link>
        <description>PM / OPP: Move opp core to its own directoryOPP code is expanding and is already present in multiple directories(cpufreq and power). Lets move it to its own directory, to manage itbetter.This also moves/renames the cpufreq_opp file to cpu.c, as it willcontain helpers for cpu device. Its not just about cpufreq, otherframeworks can use OPPs as well.Reviewed-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Fri, 04 Sep 2015 08:17:25 +0000</pubDate>
        <dc:creator>Viresh Kumar &lt;viresh.kumar@linaro.org&gt;</dc:creator>
    </item>
<item>
        <title>4990d4fe - PM / Wakeirq: Add automated device wake IRQ handling</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#4990d4fe</link>
        <description>PM / Wakeirq: Add automated device wake IRQ handlingTurns out we can automate the handling for the device_may_wakeup()quite a bit by using the kernel wakeup source list as suggestedby Rafael J. Wysocki &lt;rjw@rjwysocki.net&gt;.And as some hardware has separate dedicated wake-up interruptin addition to the IO interrupt, we can automate the handling byadding a generic threaded interrupt handler that just calls thedevice PM runtime to wake up the device.This allows dropping code from device drivers as we currentlyare doing it in multiple ways, and often wrong.For most drivers, we should be able to drop the followingboilerplate code from runtime_suspend and runtime_resumefunctions:	...	device_init_wakeup(dev, true);	...	if (device_may_wakeup(dev))		enable_irq_wake(irq);	...	if (device_may_wakeup(dev))		disable_irq_wake(irq);	...	device_init_wakeup(dev, false);	...We can replace it with just the following init and exittime code:	...	device_init_wakeup(dev, true);	dev_pm_set_wake_irq(dev, irq);	...	dev_pm_clear_wake_irq(dev);	device_init_wakeup(dev, false);	...And for hardware with dedicated wake-up interrupts:	...	device_init_wakeup(dev, true);	dev_pm_set_dedicated_wake_irq(dev, irq);	...	dev_pm_clear_wake_irq(dev);	device_init_wakeup(dev, false);	...Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Mon, 18 May 2015 22:40:29 +0000</pubDate>
        <dc:creator>Tony Lindgren &lt;tony@atomide.com&gt;</dc:creator>
    </item>
<item>
        <title>37f20416 - PM: Add pm_runtime_suspend|resume_force functions</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#37f20416</link>
        <description>PM: Add pm_runtime_suspend|resume_force functionsThis patch provides two new runtime PM helper functions which intend tobe used from system suspend/resume callbacks, to make sure devices areput into low power state during system suspend and brought back to fullpower at system resume.The prerequisite is to have all levels of a device&apos;s runtime PMcallbacks to be defined through the SET_PM_RUNTIME_PM_OPS macro, whichmeans these are available for CONFIG_PM.By using the new runtime PM helper functions especially the twoscenarios below will be addressed.1) The PM core prevents .runtime_suspend callbacks from being invokedduring system suspend. That means even for a runtime PM centricsubsystem and driver, the device needs to be put into low power statefrom a system suspend callback. Otherwise it may very well be left infull power state (runtime resumed) while the system is suspended. Byusing the new helper functions, we make sure to walk the hierarchy ofa device&apos;s power domain, subsystem and driver.2) Subsystems and drivers need to cope with all the combinations ofCONFIG_PM_SLEEP and CONFIG_PM_RUNTIME. The two new helper functionssmothly addresses this.Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Sat, 01 Mar 2014 10:56:05 +0000</pubDate>
        <dc:creator>Ulf Hansson &lt;ulf.hansson@linaro.org&gt;</dc:creator>
    </item>
<item>
        <title>b02c999a - PM / Domains: Add device stop governor function (v4)</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#b02c999a</link>
        <description>PM / Domains: Add device stop governor function (v4)Add a function deciding whether or not devices should be stopped inpm_genpd_runtime_suspend() depending on their PM QoS constraintsand stop/start timing values.  Make it possible to add informationused by this function to device objects.Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;Acked-by: Magnus Damm &lt;damm@opensource.se&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Wed, 30 Nov 2011 23:02:05 +0000</pubDate>
        <dc:creator>Rafael J. Wysocki &lt;rjw@sisk.pl&gt;</dc:creator>
    </item>
<item>
        <title>91ff4cb8 - PM QoS: Implement per-device PM QoS constraints</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#91ff4cb8</link>
        <description>PM QoS: Implement per-device PM QoS constraintsImplement the per-device PM QoS constraints by creating a devicePM QoS API, which calls the PM QoS constraints management core code.The per-device latency constraints data strctures are storedin the device dev_pm_info struct.The device PM code calls the init and destroy of the per-device constraintsdata struct in order to support the dynamic insertion and removal of thedevices in the system.To minimize the data usage by the per-device constraints, the data structis only allocated at the first call to dev_pm_qos_add_request.The data is later free&apos;d when the device is removed from the system.A global mutex protects the constraints users from the data beingallocated and free&apos;d.Signed-off-by: Jean Pihet &lt;j-pihet@ti.com&gt;Reviewed-by: Kevin Hilman &lt;khilman@ti.com&gt;Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Thu, 25 Aug 2011 13:35:41 +0000</pubDate>
        <dc:creator>Jean Pihet &lt;j-pihet@ti.com&gt;</dc:creator>
    </item>
<item>
        <title>ef27bed1 - PM: Reference counting of power.subsys_data</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#ef27bed1</link>
        <description>PM: Reference counting of power.subsys_dataSince the power.subsys_data device field will be used by multiplefilesystems, introduce a reference counting mechanism for it to avoidfreeing it prematurely or changing its value at a wrong time.Make the PM clocks management code that currently is the only user ofpower.subsys_data use the new reference counting.Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Thu, 25 Aug 2011 13:34:01 +0000</pubDate>
        <dc:creator>Rafael J. Wysocki &lt;rjw@sisk.pl&gt;</dc:creator>
    </item>
<item>
        <title>f721889f - PM / Domains: Support for generic I/O PM domains (v8)</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#f721889f</link>
        <description>PM / Domains: Support for generic I/O PM domains (v8)Introduce common headers, helper functions and callbacks allowingplatforms to use simple generic power domains for runtime powermanagement.Introduce struct generic_pm_domain to be used for representingpower domains that each contain a number of devices and may beparent domains or subdomains with respect to other power domains.Among other things, this structure includes callbacks to beprovided by platforms for performing specific tasks related topower management (i.e. -&gt;stop_device() may disable a device&apos;sclocks, while -&gt;start_device() may enable them, -&gt;power_off() issupposed to remove power from the entire power domainand -&gt;power_on() is supposed to restore it).Introduce functions that can be used as power domain runtime PMcallbacks, pm_genpd_runtime_suspend() and pm_genpd_runtime_resume(),as well as helper functions for the initialization of a powerdomain represented by a struct generic_power_domain object,adding a device to or removing a device from it and adding orremoving subdomains.Introduce configuration option CONFIG_PM_GENERIC_DOMAINS to beselected by the platforms that want to use the new code.Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;Acked-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;Reviewed-by: Kevin Hilman &lt;khilman@ti.com&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Fri, 01 Jul 2011 20:12:45 +0000</pubDate>
        <dc:creator>Rafael J. Wysocki &lt;rjw@sisk.pl&gt;</dc:creator>
    </item>
<item>
        <title>c650da23 - PM: Remove CONFIG_PM_VERBOSE</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#c650da23</link>
        <description>PM: Remove CONFIG_PM_VERBOSENow that we have CONFIG_DYNAMIC_DEBUG there is no need for yetanother flag causing dev_dbg() and pr_debug() statements in thecore PM code to produce output.  Moreover, CONFIG_PM_VERBOSEcauses so much output to be generated that it&apos;s not really usefuland almost no one sets it.References: https://bugzilla.kernel.org/show_bug.cgi?id=23182Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Tue, 17 May 2011 21:25:10 +0000</pubDate>
        <dc:creator>Rafael J. Wysocki &lt;rjw@sisk.pl&gt;</dc:creator>
    </item>
<item>
        <title>85eb8c8d - PM / Runtime: Generic clock manipulation rountines for runtime PM (v6)</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#85eb8c8d</link>
        <description>PM / Runtime: Generic clock manipulation rountines for runtime PM (v6)Many different platforms and subsystems may want to disable deviceclocks during suspend and enable them during resume which is going tobe done in a very similar way in all those cases.  For this reason,provide generic routines for the manipulation of device clocks duringsuspend and resume.Convert the ARM shmobile platform to using the new routines.Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Fri, 29 Apr 2011 22:25:44 +0000</pubDate>
        <dc:creator>Rafael J. Wysocki &lt;rjw@sisk.pl&gt;</dc:creator>
    </item>
<item>
        <title>aa338601 - PM: Remove CONFIG_PM_OPS</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#aa338601</link>
        <description>PM: Remove CONFIG_PM_OPSAfter redefining CONFIG_PM to depend on (CONFIG_PM_SLEEP ||CONFIG_PM_RUNTIME) the CONFIG_PM_OPS option is redundant and can bereplaced with CONFIG_PM.Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Thu, 10 Feb 2011 23:06:54 +0000</pubDate>
        <dc:creator>Rafael J. Wysocki &lt;rjw@sisk.pl&gt;</dc:creator>
    </item>
<item>
        <title>e1f60b29 - PM: Introduce library for device-specific OPPs (v7)</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#e1f60b29</link>
        <description>PM: Introduce library for device-specific OPPs (v7)SoCs have a standard set of tuples consisting of frequency andvoltage pairs that the device will support per voltage domain. Theseare called Operating Performance Points or OPPs. The actualdefinitions of OPP varies over silicon versions. For a specific domain,we can have a set of {frequency, voltage} pairs. As the kernel bootsand more information is available, a default set of these are activatedbased on the precise nature of device. Further on operation, based onconditions prevailing in the system (such as temperature), some OPPavailability may be temporarily controlled by the SoC frameworks.To implement an OPP, some sort of power management support is necessaryhence this library depends on CONFIG_PM.Contributions include:Sanjeev Premi for the initial concept:	http://patchwork.kernel.org/patch/50998/Kevin Hilman for converting original design to device-based.Kevin Hilman and Paul Walmsey for cleaning up many of the functionabstractions, improvements and data structure handling.Romit Dasgupta for using enums instead of opp pointers.Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes andcleanups.Linus Walleij for recommending this layer be made generic for usagein other architectures beyond OMAP and ARM.Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney forvaluable improvements.Discussions and comments from:http://marc.info/?l=linux-omap&amp;m=126033945313269&amp;w=2http://marc.info/?l=linux-omap&amp;m=125482970102327&amp;w=2http://marc.info/?t=125809247500002&amp;r=1&amp;w=2http://marc.info/?l=linux-omap&amp;m=126025973426007&amp;w=2http://marc.info/?t=128152609200064&amp;r=1&amp;w=2http://marc.info/?t=128468723000002&amp;r=1&amp;w=2incorporated.v1: http://marc.info/?t=128468723000002&amp;r=1&amp;w=2Signed-off-by: Nishanth Menon &lt;nm@ti.com&gt;Signed-off-by: Kevin Hilman &lt;khilman@deeprootsystems.com&gt;Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Tue, 12 Oct 2010 22:13:10 +0000</pubDate>
        <dc:creator>Nishanth Menon &lt;nm@ti.com&gt;</dc:creator>
    </item>
<item>
        <title>c125e96f - PM: Make it possible to avoid races between wakeup and system sleep</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#c125e96f</link>
        <description>PM: Make it possible to avoid races between wakeup and system sleepOne of the arguments during the suspend blockers discussion was thatthe mainline kernel didn&apos;t contain any mechanisms making it possibleto avoid races between wakeup and system suspend.Generally, there are two problems in that area.  First, if a wakeupevent occurs exactly when /sys/power/state is being written to, itmay be delivered to user space right before the freezer kicks in, sothe user space consumer of the event may not be able to process itbefore the system is suspended.  Second, if a wakeup event occursafter user space has been frozen, it is not generally guaranteed thatthe ongoing transition of the system into a sleep state will beaborted.To address these issues introduce a new global sysfs attribute,/sys/power/wakeup_count, associated with a running counter of wakeupevents and three helper functions, pm_stay_awake(), pm_relax(), andpm_wakeup_event(), that may be used by kernel subsystems to controlthe behavior of this attribute and to request the PM core to abortsystem transitions into a sleep state already in progress.The /sys/power/wakeup_count file may be read from or written to byuser space.  Reads will always succeed (unless interrupted by asignal) and return the current value of the wakeup events counter.Writes, however, will only succeed if the written number is equal tothe current value of the wakeup events counter.  If a write issuccessful, it will cause the kernel to save the current value of thewakeup events counter and to abort the subsequent system transitioninto a sleep state if any wakeup events are reported after the writehas returned.[The assumption is that before writing to /sys/power/state user spacewill first read from /sys/power/wakeup_count.  Next, user spaceconsumers of wakeup events will have a chance to acknowledge orveto the upcoming system transition to a sleep state.  Finally, ifthe transition is allowed to proceed, /sys/power/wakeup_count willbe written to and if that succeeds, /sys/power/state will be writtento as well.  Still, if any wakeup events are reported to the PM coreby kernel subsystems after that point, the transition will beaborted.]Additionally, put a wakeup events counter into struct dev_pm_info andmake these per-device wakeup event counters available via sysfs,so that it&apos;s possible to check the activity of various wakeup eventsources within the kernel.To illustrate how subsystems can use pm_wakeup_event(), make thelow-level PCI runtime PM wakeup-handling code use it.Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;Acked-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;Acked-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;Acked-by: markgross &lt;markgross@thegnar.org&gt;Reviewed-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Mon, 05 Jul 2010 20:43:53 +0000</pubDate>
        <dc:creator>Rafael J. Wysocki &lt;rjw@sisk.pl&gt;</dc:creator>
    </item>
<item>
        <title>d690b2cd - PM: Provide generic subsystem-level callbacks</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#d690b2cd</link>
        <description>PM: Provide generic subsystem-level callbacksThere are subsystems whose power management callbacks only need toinvoke the callbacks provided by device drivers.  Still, their systemsleep PM callbacks should play well with the runtime PM callbacks,so that devices suspended at run time can be left in that state fora system sleep transition.Provide a set of generic PM callbacks for such subsystems anddefine convenience macros for populating dev_pm_ops structures.Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Sat, 06 Mar 2010 20:28:37 +0000</pubDate>
        <dc:creator>Rafael J. Wysocki &lt;rjw@sisk.pl&gt;</dc:creator>
    </item>
<item>
        <title>5e928f77 - PM: Introduce core framework for run-time PM of I/O devices (rev. 17)</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#5e928f77</link>
        <description>PM: Introduce core framework for run-time PM of I/O devices (rev. 17)Introduce a core framework for run-time power management of I/Odevices.  Add device run-time PM fields to &apos;struct dev_pm_info&apos;and device run-time PM callbacks to &apos;struct dev_pm_ops&apos;.  Introducea run-time PM workqueue and define some device run-time PM helperfunctions at the core level.  Document all these things.Special thanks to Alan Stern for his help with the design andmultiple detailed reviews of the pereceding versions of this patchand to Magnus Damm for testing feedback.Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;Acked-by: Magnus Damm &lt;damm@igel.co.jp&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Tue, 18 Aug 2009 21:38:32 +0000</pubDate>
        <dc:creator>Rafael J. Wysocki &lt;rjw@sisk.pl&gt;</dc:creator>
    </item>
<item>
        <title>90dda1cb - PM: Make PM_TRACE more architecture independent</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/base/power/Makefile#90dda1cb</link>
        <description>PM: Make PM_TRACE more architecture independentWhen trying to debug a suspend failure I started implementingPM_TRACE for powerpc. I then noticed that I&apos;m debugging a suspendfailure and so PM_TRACE isn&apos;t useful at all, but thought thatnonetheless this could be useful in the future.Basically, to support PM_TRACE, you add a Kconfig option thatselects PM_TRACE and provides the infrastructure as per thehelp text of PM_TRACE.Signed-off-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;

            List of files:
            /linux-6.15/drivers/base/power/Makefile</description>
        <pubDate>Mon, 19 Nov 2007 22:46:16 +0000</pubDate>
        <dc:creator>Johannes Berg &lt;johannes@sipsolutions.net&gt;</dc:creator>
    </item>
</channel>
</rss>
