diff for duplicates of <87wrtmepum.fsf@deeprootsystems.com> diff --git a/a/1.txt b/N1/1.txt index a9bf04c..c4a0702 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -7,7 +7,7 @@ Grant Likely <grant.likely@secretlab.ca> writes: >>> On Thu, Jun 24, 2010 at 5:43 PM, Kevin Hilman >>> <khilman@deeprootsystems.com> wrote: >>>> Implement the new runtime PM framework as a thin layer on top of the ->>>> omap_device API. Since we don't have an OMAP-specific bus, override +>>>> omap_device API. ?Since we don't have an OMAP-specific bus, override >>>> the runtime PM hooks for the platform_bus for the OMAP specific >>>> implementation. >>>> @@ -25,19 +25,19 @@ Grant Likely <grant.likely@secretlab.ca> writes: >>> >>> Hi Kevin, >> ->> Hi Grant. Thanks for the review and suggestions. +>> Hi Grant. ?Thanks for the review and suggestions. >> >>> You shouldn't hijack the platform bus in this way, for a number of ->>> reasons. Not all platform devices in an OMAP system are internal OMAP +>>> reasons. ?Not all platform devices in an OMAP system are internal OMAP >>> devices (as you know since you do an explicit check for omap devices). ->>> Right there that says that the abstraction is at the wrong level. +>>> ?Right there that says that the abstraction is at the wrong level. >>> What happens when an mostly transparent bridge is added with its own ->>> peripherals and its own special operations? Does this routine then ->>> need to be extended for each new special case? It's not maintainable +>>> peripherals and its own special operations? ?Does this routine then +>>> need to be extended for each new special case? ?It's not maintainable >>> in the long run. >>> >>> This approach is also not multiplatform friendly (cc'ing Eric and ->>> Nicolas who are working on ARM multiplatform). It won't work for +>>> Nicolas who are working on ARM multiplatform). ?It won't work for >>> building a kernel that supports, say, both versatile and OMAP. >> >> Totally agree here, but this a separate issue not specifically created @@ -49,7 +49,7 @@ Grant Likely <grant.likely@secretlab.ca> writes: > severe. Don't follow the SH lead in this case. > >> The issue is that the current method to override bus methods is by ->> overriding weak symbols. This clearly doesn't scale to support multiple +>> overriding weak symbols. ?This clearly doesn't scale to support multiple >> platforms in the same image. > > Agreed. It scales better to change the hooks at runtime, which is @@ -58,21 +58,21 @@ Grant Likely <grant.likely@secretlab.ca> writes: > >> What would be needed (if we continue to override the platform_bus >> methods) is to have some sort of register function for overriding these ->> methods. I'll look into that based on the result of discussions +>> methods. ?I'll look into that based on the result of discussions >> below... >> ->>> The kernel already has the facility to do what you need. We talked +>>> The kernel already has the facility to do what you need. ?We talked >>> about it briefly at ELC, and now that I look at it closer, I thing ->>> gregkh is absolutely right. Just create a new bus type for OMAP ->>> devices. It is simple to add one. You can probably even call out to ->>> the platform bus ops for most of the operations. The fact that OMAP +>>> gregkh is absolutely right. ?Just create a new bus type for OMAP +>>> devices. ?It is simple to add one. ?You can probably even call out to +>>> the platform bus ops for most of the operations. ?The fact that OMAP >>> devices have special behaviour that needs to be handled at the bus ->>> type level means that they are not platform devices anymore. This +>>> type level means that they are not platform devices anymore. ?This >>> also eliminates all the omap_device_is_valid and OMAP_DEVICE_MAGIC >>> gymnastics. >>> >>> I see from the comments in omap_device.c that doing an ->>> omap_bus/omap_device is being considered anyway. Please don't merge +>>> omap_bus/omap_device is being considered anyway. ?Please don't merge >>> this patch and do the omap_bus_type instead. >> >> Agreed, it is logicially simpler in many ways and as you've noticed, @@ -80,13 +80,13 @@ Grant Likely <grant.likely@secretlab.ca> writes: >> >> However, I keep coming back to extending the platform bus, primarily >> since the resulting new bus code would look almost identical to the ->> platform bus. All I really needed is the ability to extend a small +>> platform bus. ?All I really needed is the ability to extend a small >> subset of the PM functions, so this led to me the "extend instead of >> duplicate" approach. >> >> In addition, I really don't want to duplicate all the platform_driver >> and platform_device code, again because it would be identical but ->> especially since this would seriously impact many drivers. For drivers +>> especially since this would seriously impact many drivers. ?For drivers >> that are used on OMAP and also on other platforms, do we want drivers to >> know (or care) if they are on the platform bus or on the OMAP bus? > @@ -121,7 +121,7 @@ should be re-usable, without OMAP-specific knowledge. >> I think this is how it is done for OF devices, but I'm not crazy about >> that approach (after our discussions at ELC, I remember thinking you'd >> been through this with the OF devices as well and are moving towards ->> using platform_bus/platform_device for those too. Did I understand +>> using platform_bus/platform_device for those too. ?Did I understand >> correctly?) > > Yes, I've got patches which merge of_platform_bus_type with the @@ -147,7 +147,7 @@ want to stay away from. > >> This affects many aspects of all drivers, from register and probe (for >> early devices/drivers too!) to all the plaform_get_resource() usage, all ->> of which assumes a platform_driver and platform_device. I didn't look +>> of which assumes a platform_driver and platform_device. ?I didn't look >> closely, but I didn't see if (or how) OF was handling early devices. > > You don't have to reimplement the entire platform bus. You could @@ -202,20 +202,20 @@ Kevin > >> All that being said, if I could create a custom bus, but continue to use ->> platform_devices, that would greatly simply the changes to drivers. Do ->> you think that's acceptable? If so, I can take a stab at that and see +>> platform_devices, that would greatly simply the changes to drivers. ?Do +>> you think that's acceptable? ?If so, I can take a stab at that and see >> what it looks like. > > Heh, I should read the whole email before replying. See above. > >>> Also, I notice that most of these hooks open-code the generic versions ->>> of the runtime hooks. Instead of open coding it, can the omap hooks +>>> of the runtime hooks. ?Instead of open coding it, can the omap hooks >>> call the generic hooks before/after doing the omap-specific work? >> >> Ah, good point. >> >> This patch pre-dates the creation of pm_generic_runtime_*, but certainly ->> should be upgraded to use those. Thanks. +>> should be upgraded to use those. ?Thanks. >> >> Kevin >> @@ -226,34 +226,34 @@ Kevin >>>> >>>> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> >>>> --- ->>>> arch/arm/mach-omap2/Makefile | 7 +++- ->>>> arch/arm/mach-omap2/pm_bus.c | 70 ++++++++++++++++++++++++++++++++++++++++++ ->>>> 2 files changed, 76 insertions(+), 1 deletions(-) ->>>> create mode 100644 arch/arm/mach-omap2/pm_bus.c +>>>> ?arch/arm/mach-omap2/Makefile | ? ?7 +++- +>>>> ?arch/arm/mach-omap2/pm_bus.c | ? 70 ++++++++++++++++++++++++++++++++++++++++++ +>>>> ?2 files changed, 76 insertions(+), 1 deletions(-) +>>>> ?create mode 100644 arch/arm/mach-omap2/pm_bus.c >>>> >>>> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile >>>> index ea52b03..8ed47ea 100644 >>>> --- a/arch/arm/mach-omap2/Makefile >>>> +++ b/arch/arm/mach-omap2/Makefile ->>>> @@ -46,12 +46,17 @@ obj-$(CONFIG_ARCH_OMAP2) += sdrc2xxx.o ->>>> ifeq ($(CONFIG_PM),y) ->>>> obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o ->>>> obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o ->>>> -obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o ->>>> +obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o \ ->>>> + pm_bus.o ->>>> obj-$(CONFIG_PM_DEBUG) += pm-debug.o +>>>> @@ -46,12 +46,17 @@ obj-$(CONFIG_ARCH_OMAP2) ? ? ? ? ? ?+= sdrc2xxx.o +>>>> ?ifeq ($(CONFIG_PM),y) +>>>> ?obj-$(CONFIG_ARCH_OMAP2) ? ? ? ? ? ? ? += pm24xx.o +>>>> ?obj-$(CONFIG_ARCH_OMAP2) ? ? ? ? ? ? ? += sleep24xx.o +>>>> -obj-$(CONFIG_ARCH_OMAP3) ? ? ? ? ? ? ? += pm34xx.o sleep34xx.o cpuidle34xx.o +>>>> +obj-$(CONFIG_ARCH_OMAP3) ? ? ? ? ? ? ? += pm34xx.o sleep34xx.o cpuidle34xx.o \ +>>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?pm_bus.o +>>>> ?obj-$(CONFIG_PM_DEBUG) ? ? ? ? ? ? ? ? += pm-debug.o >>>> ->>>> AFLAGS_sleep24xx.o :=-Wa,-march=armv6 ->>>> AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a +>>>> ?AFLAGS_sleep24xx.o ? ? ? ? ? ? ? ? ? ? :=-Wa,-march=armv6 +>>>> ?AFLAGS_sleep34xx.o ? ? ? ? ? ? ? ? ? ? :=-Wa,-march=armv7-a >>>> >>>> +ifeq ($(CONFIG_PM_VERBOSE),y) ->>>> +CFLAGS_pm_bus.o += -DDEBUG +>>>> +CFLAGS_pm_bus.o ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+= -DDEBUG >>>> +endif >>>> + ->>>> endif +>>>> ?endif >>>> ->>>> # PRCM +>>>> ?# PRCM >>>> diff --git a/arch/arm/mach-omap2/pm_bus.c b/arch/arm/mach-omap2/pm_bus.c >>>> new file mode 100644 >>>> index 0000000..9719a9f @@ -284,49 +284,49 @@ Kevin >>>> +#ifdef CONFIG_PM_RUNTIME >>>> +int platform_pm_runtime_suspend(struct device *dev) >>>> +{ ->>>> + struct platform_device *pdev = to_platform_device(dev); ->>>> + struct omap_device *odev = to_omap_device(pdev); ->>>> + int r, ret = 0; +>>>> + ? ? ? struct platform_device *pdev = to_platform_device(dev); +>>>> + ? ? ? struct omap_device *odev = to_omap_device(pdev); +>>>> + ? ? ? int r, ret = 0; >>>> + ->>>> + dev_dbg(dev, "%s\n", __func__); +>>>> + ? ? ? dev_dbg(dev, "%s\n", __func__); >>>> + ->>>> + if (dev->driver->pm && dev->driver->pm->runtime_suspend) ->>>> + ret = dev->driver->pm->runtime_suspend(dev); ->>>> + if (!ret && omap_device_is_valid(odev)) { ->>>> + r = omap_device_idle(pdev); ->>>> + WARN_ON(r); ->>>> + } +>>>> + ? ? ? if (dev->driver->pm && dev->driver->pm->runtime_suspend) +>>>> + ? ? ? ? ? ? ? ret = dev->driver->pm->runtime_suspend(dev); +>>>> + ? ? ? if (!ret && omap_device_is_valid(odev)) { +>>>> + ? ? ? ? ? ? ? r = omap_device_idle(pdev); +>>>> + ? ? ? ? ? ? ? WARN_ON(r); +>>>> + ? ? ? } >>>> + ->>>> + return ret; +>>>> + ? ? ? return ret; >>>> +}; >>>> + >>>> +int platform_pm_runtime_resume(struct device *dev) >>>> +{ ->>>> + struct platform_device *pdev = to_platform_device(dev); ->>>> + struct omap_device *odev = to_omap_device(pdev); ->>>> + int r, ret = 0; +>>>> + ? ? ? struct platform_device *pdev = to_platform_device(dev); +>>>> + ? ? ? struct omap_device *odev = to_omap_device(pdev); +>>>> + ? ? ? int r, ret = 0; >>>> + ->>>> + dev_dbg(dev, "%s\n", __func__); +>>>> + ? ? ? dev_dbg(dev, "%s\n", __func__); >>>> + ->>>> + if (omap_device_is_valid(odev)) { ->>>> + r = omap_device_enable(pdev); ->>>> + WARN_ON(r); ->>>> + } +>>>> + ? ? ? if (omap_device_is_valid(odev)) { +>>>> + ? ? ? ? ? ? ? r = omap_device_enable(pdev); +>>>> + ? ? ? ? ? ? ? WARN_ON(r); +>>>> + ? ? ? } >>>> + ->>>> + if (dev->driver->pm && dev->driver->pm->runtime_resume) ->>>> + ret = dev->driver->pm->runtime_resume(dev); +>>>> + ? ? ? if (dev->driver->pm && dev->driver->pm->runtime_resume) +>>>> + ? ? ? ? ? ? ? ret = dev->driver->pm->runtime_resume(dev); >>>> + ->>>> + return ret; +>>>> + ? ? ? return ret; >>>> +}; >>>> + >>>> +int platform_pm_runtime_idle(struct device *dev) >>>> +{ ->>>> + int ret; +>>>> + ? ? ? int ret; >>>> + ->>>> + ret = pm_runtime_suspend(dev); ->>>> + dev_dbg(dev, "%s [%d]\n", __func__, ret); +>>>> + ? ? ? ret = pm_runtime_suspend(dev); +>>>> + ? ? ? dev_dbg(dev, "%s [%d]\n", __func__, ret); >>>> + ->>>> + return 0; +>>>> + ? ? ? return 0; >>>> +}; >>>> +#endif /* CONFIG_PM_RUNTIME */ >>>> + @@ -336,11 +336,7 @@ Kevin >>>> >>>> _______________________________________________ >>>> linux-arm-kernel mailing list ->>>> linux-arm-kernel@lists.infradead.org +>>>> linux-arm-kernel at lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>>> >> --- -To unsubscribe from this list: send the line "unsubscribe linux-omap" in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 2564923..17d9519 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,14 +3,10 @@ "ref\0AANLkTim4p54brsmph6oaKfoEZwO1GOGfgRNV9vJykOjl@mail.gmail.com\0" "ref\0874ogrng3j.fsf@deeprootsystems.com\0" "ref\0AANLkTimMnJvOJrRHDiE6PH1BXpRz2-6pY1M9nKHw7vpn@mail.gmail.com\0" - "From\0Kevin Hilman <khilman@deeprootsystems.com>\0" - "Subject\0Re: [PATCH v2 1/3] OMAP: PM: initial runtime PM core support\0" + "From\0khilman@deeprootsystems.com (Kevin Hilman)\0" + "Subject\0[PATCH v2 1/3] OMAP: PM: initial runtime PM core support\0" "Date\0Fri, 25 Jun 2010 14:58:57 -0700\0" - "To\0Grant Likely <grant.likely@secretlab.ca>\0" - "Cc\0linux-omap@vger.kernel.org" - linux-arm-kernel@lists.infradead.org - Eric Miao <eric.miao@canonical.com> - " Nicolas Pitre <nico@fluxnic.net>\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "Grant Likely <grant.likely@secretlab.ca> writes:\n" @@ -22,7 +18,7 @@ ">>> On Thu, Jun 24, 2010 at 5:43 PM, Kevin Hilman\n" ">>> <khilman@deeprootsystems.com> wrote:\n" ">>>> Implement the new runtime PM framework as a thin layer on top of the\n" - ">>>> omap_device API. \302\240Since we don't have an OMAP-specific bus, override\n" + ">>>> omap_device API. ?Since we don't have an OMAP-specific bus, override\n" ">>>> the runtime PM hooks for the platform_bus for the OMAP specific\n" ">>>> implementation.\n" ">>>>\n" @@ -40,19 +36,19 @@ ">>>\n" ">>> Hi Kevin,\n" ">>\n" - ">> Hi Grant. \302\240Thanks for the review and suggestions.\n" + ">> Hi Grant. ?Thanks for the review and suggestions.\n" ">>\n" ">>> You shouldn't hijack the platform bus in this way, for a number of\n" - ">>> reasons. \302\240Not all platform devices in an OMAP system are internal OMAP\n" + ">>> reasons. ?Not all platform devices in an OMAP system are internal OMAP\n" ">>> devices (as you know since you do an explicit check for omap devices).\n" - ">>> \302\240Right there that says that the abstraction is at the wrong level.\n" + ">>> ?Right there that says that the abstraction is at the wrong level.\n" ">>> What happens when an mostly transparent bridge is added with its own\n" - ">>> peripherals and its own special operations? \302\240Does this routine then\n" - ">>> need to be extended for each new special case? \302\240It's not maintainable\n" + ">>> peripherals and its own special operations? ?Does this routine then\n" + ">>> need to be extended for each new special case? ?It's not maintainable\n" ">>> in the long run.\n" ">>>\n" ">>> This approach is also not multiplatform friendly (cc'ing Eric and\n" - ">>> Nicolas who are working on ARM multiplatform). \302\240It won't work for\n" + ">>> Nicolas who are working on ARM multiplatform). ?It won't work for\n" ">>> building a kernel that supports, say, both versatile and OMAP.\n" ">>\n" ">> Totally agree here, but this a separate issue not specifically created\n" @@ -64,7 +60,7 @@ "> severe. Don't follow the SH lead in this case.\n" ">\n" ">> The issue is that the current method to override bus methods is by\n" - ">> overriding weak symbols. \302\240This clearly doesn't scale to support multiple\n" + ">> overriding weak symbols. ?This clearly doesn't scale to support multiple\n" ">> platforms in the same image.\n" ">\n" "> Agreed. It scales better to change the hooks at runtime, which is\n" @@ -73,21 +69,21 @@ ">\n" ">> What would be needed (if we continue to override the platform_bus\n" ">> methods) is to have some sort of register function for overriding these\n" - ">> methods. \302\240I'll look into that based on the result of discussions\n" + ">> methods. ?I'll look into that based on the result of discussions\n" ">> below...\n" ">>\n" - ">>> The kernel already has the facility to do what you need. \302\240We talked\n" + ">>> The kernel already has the facility to do what you need. ?We talked\n" ">>> about it briefly at ELC, and now that I look at it closer, I thing\n" - ">>> gregkh is absolutely right. \302\240Just create a new bus type for OMAP\n" - ">>> devices. \302\240It is simple to add one. \302\240You can probably even call out to\n" - ">>> the platform bus ops for most of the operations. \302\240The fact that OMAP\n" + ">>> gregkh is absolutely right. ?Just create a new bus type for OMAP\n" + ">>> devices. ?It is simple to add one. ?You can probably even call out to\n" + ">>> the platform bus ops for most of the operations. ?The fact that OMAP\n" ">>> devices have special behaviour that needs to be handled at the bus\n" - ">>> type level means that they are not platform devices anymore. \302\240This\n" + ">>> type level means that they are not platform devices anymore. ?This\n" ">>> also eliminates all the omap_device_is_valid and OMAP_DEVICE_MAGIC\n" ">>> gymnastics.\n" ">>>\n" ">>> I see from the comments in omap_device.c that doing an\n" - ">>> omap_bus/omap_device is being considered anyway. \302\240Please don't merge\n" + ">>> omap_bus/omap_device is being considered anyway. ?Please don't merge\n" ">>> this patch and do the omap_bus_type instead.\n" ">>\n" ">> Agreed, it is logicially simpler in many ways and as you've noticed,\n" @@ -95,13 +91,13 @@ ">>\n" ">> However, I keep coming back to extending the platform bus, primarily\n" ">> since the resulting new bus code would look almost identical to the\n" - ">> platform bus. \302\240All I really needed is the ability to extend a small\n" + ">> platform bus. ?All I really needed is the ability to extend a small\n" ">> subset of the PM functions, so this led to me the \"extend instead of\n" ">> duplicate\" approach.\n" ">>\n" ">> In addition, I really don't want to duplicate all the platform_driver\n" ">> and platform_device code, again because it would be identical but\n" - ">> especially since this would seriously impact many drivers. \302\240For drivers\n" + ">> especially since this would seriously impact many drivers. ?For drivers\n" ">> that are used on OMAP and also on other platforms, do we want drivers to\n" ">> know (or care) if they are on the platform bus or on the OMAP bus?\n" ">\n" @@ -136,7 +132,7 @@ ">> I think this is how it is done for OF devices, but I'm not crazy about\n" ">> that approach (after our discussions at ELC, I remember thinking you'd\n" ">> been through this with the OF devices as well and are moving towards\n" - ">> using platform_bus/platform_device for those too. \302\240Did I understand\n" + ">> using platform_bus/platform_device for those too. ?Did I understand\n" ">> correctly?)\n" ">\n" "> Yes, I've got patches which merge of_platform_bus_type with the\n" @@ -162,7 +158,7 @@ ">\n" ">> This affects many aspects of all drivers, from register and probe (for\n" ">> early devices/drivers too!) to all the plaform_get_resource() usage, all\n" - ">> of which assumes a platform_driver and platform_device. \302\240I didn't look\n" + ">> of which assumes a platform_driver and platform_device. ?I didn't look\n" ">> closely, but I didn't see if (or how) OF was handling early devices.\n" ">\n" "> You don't have to reimplement the entire platform bus. You could\n" @@ -217,20 +213,20 @@ "\n" ">\n" ">> All that being said, if I could create a custom bus, but continue to use\n" - ">> platform_devices, that would greatly simply the changes to drivers. \302\240Do\n" - ">> you think that's acceptable? \302\240If so, I can take a stab at that and see\n" + ">> platform_devices, that would greatly simply the changes to drivers. ?Do\n" + ">> you think that's acceptable? ?If so, I can take a stab at that and see\n" ">> what it looks like.\n" ">\n" "> Heh, I should read the whole email before replying. See above.\n" ">\n" ">>> Also, I notice that most of these hooks open-code the generic versions\n" - ">>> of the runtime hooks. \302\240Instead of open coding it, can the omap hooks\n" + ">>> of the runtime hooks. ?Instead of open coding it, can the omap hooks\n" ">>> call the generic hooks before/after doing the omap-specific work?\n" ">>\n" ">> Ah, good point.\n" ">>\n" ">> This patch pre-dates the creation of pm_generic_runtime_*, but certainly\n" - ">> should be upgraded to use those. \302\240Thanks.\n" + ">> should be upgraded to use those. ?Thanks.\n" ">>\n" ">> Kevin\n" ">>\n" @@ -241,34 +237,34 @@ ">>>>\n" ">>>> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>\n" ">>>> ---\n" - ">>>> \302\240arch/arm/mach-omap2/Makefile | \302\240 \302\2407 +++-\n" - ">>>> \302\240arch/arm/mach-omap2/pm_bus.c | \302\240 70 ++++++++++++++++++++++++++++++++++++++++++\n" - ">>>> \302\2402 files changed, 76 insertions(+), 1 deletions(-)\n" - ">>>> \302\240create mode 100644 arch/arm/mach-omap2/pm_bus.c\n" + ">>>> ?arch/arm/mach-omap2/Makefile | ? ?7 +++-\n" + ">>>> ?arch/arm/mach-omap2/pm_bus.c | ? 70 ++++++++++++++++++++++++++++++++++++++++++\n" + ">>>> ?2 files changed, 76 insertions(+), 1 deletions(-)\n" + ">>>> ?create mode 100644 arch/arm/mach-omap2/pm_bus.c\n" ">>>>\n" ">>>> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile\n" ">>>> index ea52b03..8ed47ea 100644\n" ">>>> --- a/arch/arm/mach-omap2/Makefile\n" ">>>> +++ b/arch/arm/mach-omap2/Makefile\n" - ">>>> @@ -46,12 +46,17 @@ obj-$(CONFIG_ARCH_OMAP2) \302\240 \302\240 \302\240 \302\240 \302\240 \302\240+= sdrc2xxx.o\n" - ">>>> \302\240ifeq ($(CONFIG_PM),y)\n" - ">>>> \302\240obj-$(CONFIG_ARCH_OMAP2) \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 += pm24xx.o\n" - ">>>> \302\240obj-$(CONFIG_ARCH_OMAP2) \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 += sleep24xx.o\n" - ">>>> -obj-$(CONFIG_ARCH_OMAP3) \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 += pm34xx.o sleep34xx.o cpuidle34xx.o\n" - ">>>> +obj-$(CONFIG_ARCH_OMAP3) \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 += pm34xx.o sleep34xx.o cpuidle34xx.o \\\n" - ">>>> + \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240pm_bus.o\n" - ">>>> \302\240obj-$(CONFIG_PM_DEBUG) \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 += pm-debug.o\n" + ">>>> @@ -46,12 +46,17 @@ obj-$(CONFIG_ARCH_OMAP2) ? ? ? ? ? ?+= sdrc2xxx.o\n" + ">>>> ?ifeq ($(CONFIG_PM),y)\n" + ">>>> ?obj-$(CONFIG_ARCH_OMAP2) ? ? ? ? ? ? ? += pm24xx.o\n" + ">>>> ?obj-$(CONFIG_ARCH_OMAP2) ? ? ? ? ? ? ? += sleep24xx.o\n" + ">>>> -obj-$(CONFIG_ARCH_OMAP3) ? ? ? ? ? ? ? += pm34xx.o sleep34xx.o cpuidle34xx.o\n" + ">>>> +obj-$(CONFIG_ARCH_OMAP3) ? ? ? ? ? ? ? += pm34xx.o sleep34xx.o cpuidle34xx.o \\\n" + ">>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?pm_bus.o\n" + ">>>> ?obj-$(CONFIG_PM_DEBUG) ? ? ? ? ? ? ? ? += pm-debug.o\n" ">>>>\n" - ">>>> \302\240AFLAGS_sleep24xx.o \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 :=-Wa,-march=armv6\n" - ">>>> \302\240AFLAGS_sleep34xx.o \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 :=-Wa,-march=armv7-a\n" + ">>>> ?AFLAGS_sleep24xx.o ? ? ? ? ? ? ? ? ? ? :=-Wa,-march=armv6\n" + ">>>> ?AFLAGS_sleep34xx.o ? ? ? ? ? ? ? ? ? ? :=-Wa,-march=armv7-a\n" ">>>>\n" ">>>> +ifeq ($(CONFIG_PM_VERBOSE),y)\n" - ">>>> +CFLAGS_pm_bus.o \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240+= -DDEBUG\n" + ">>>> +CFLAGS_pm_bus.o ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+= -DDEBUG\n" ">>>> +endif\n" ">>>> +\n" - ">>>> \302\240endif\n" + ">>>> ?endif\n" ">>>>\n" - ">>>> \302\240# PRCM\n" + ">>>> ?# PRCM\n" ">>>> diff --git a/arch/arm/mach-omap2/pm_bus.c b/arch/arm/mach-omap2/pm_bus.c\n" ">>>> new file mode 100644\n" ">>>> index 0000000..9719a9f\n" @@ -299,49 +295,49 @@ ">>>> +#ifdef CONFIG_PM_RUNTIME\n" ">>>> +int platform_pm_runtime_suspend(struct device *dev)\n" ">>>> +{\n" - ">>>> + \302\240 \302\240 \302\240 struct platform_device *pdev = to_platform_device(dev);\n" - ">>>> + \302\240 \302\240 \302\240 struct omap_device *odev = to_omap_device(pdev);\n" - ">>>> + \302\240 \302\240 \302\240 int r, ret = 0;\n" + ">>>> + ? ? ? struct platform_device *pdev = to_platform_device(dev);\n" + ">>>> + ? ? ? struct omap_device *odev = to_omap_device(pdev);\n" + ">>>> + ? ? ? int r, ret = 0;\n" ">>>> +\n" - ">>>> + \302\240 \302\240 \302\240 dev_dbg(dev, \"%s\\n\", __func__);\n" + ">>>> + ? ? ? dev_dbg(dev, \"%s\\n\", __func__);\n" ">>>> +\n" - ">>>> + \302\240 \302\240 \302\240 if (dev->driver->pm && dev->driver->pm->runtime_suspend)\n" - ">>>> + \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 ret = dev->driver->pm->runtime_suspend(dev);\n" - ">>>> + \302\240 \302\240 \302\240 if (!ret && omap_device_is_valid(odev)) {\n" - ">>>> + \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 r = omap_device_idle(pdev);\n" - ">>>> + \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 WARN_ON(r);\n" - ">>>> + \302\240 \302\240 \302\240 }\n" + ">>>> + ? ? ? if (dev->driver->pm && dev->driver->pm->runtime_suspend)\n" + ">>>> + ? ? ? ? ? ? ? ret = dev->driver->pm->runtime_suspend(dev);\n" + ">>>> + ? ? ? if (!ret && omap_device_is_valid(odev)) {\n" + ">>>> + ? ? ? ? ? ? ? r = omap_device_idle(pdev);\n" + ">>>> + ? ? ? ? ? ? ? WARN_ON(r);\n" + ">>>> + ? ? ? }\n" ">>>> +\n" - ">>>> + \302\240 \302\240 \302\240 return ret;\n" + ">>>> + ? ? ? return ret;\n" ">>>> +};\n" ">>>> +\n" ">>>> +int platform_pm_runtime_resume(struct device *dev)\n" ">>>> +{\n" - ">>>> + \302\240 \302\240 \302\240 struct platform_device *pdev = to_platform_device(dev);\n" - ">>>> + \302\240 \302\240 \302\240 struct omap_device *odev = to_omap_device(pdev);\n" - ">>>> + \302\240 \302\240 \302\240 int r, ret = 0;\n" + ">>>> + ? ? ? struct platform_device *pdev = to_platform_device(dev);\n" + ">>>> + ? ? ? struct omap_device *odev = to_omap_device(pdev);\n" + ">>>> + ? ? ? int r, ret = 0;\n" ">>>> +\n" - ">>>> + \302\240 \302\240 \302\240 dev_dbg(dev, \"%s\\n\", __func__);\n" + ">>>> + ? ? ? dev_dbg(dev, \"%s\\n\", __func__);\n" ">>>> +\n" - ">>>> + \302\240 \302\240 \302\240 if (omap_device_is_valid(odev)) {\n" - ">>>> + \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 r = omap_device_enable(pdev);\n" - ">>>> + \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 WARN_ON(r);\n" - ">>>> + \302\240 \302\240 \302\240 }\n" + ">>>> + ? ? ? if (omap_device_is_valid(odev)) {\n" + ">>>> + ? ? ? ? ? ? ? r = omap_device_enable(pdev);\n" + ">>>> + ? ? ? ? ? ? ? WARN_ON(r);\n" + ">>>> + ? ? ? }\n" ">>>> +\n" - ">>>> + \302\240 \302\240 \302\240 if (dev->driver->pm && dev->driver->pm->runtime_resume)\n" - ">>>> + \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 ret = dev->driver->pm->runtime_resume(dev);\n" + ">>>> + ? ? ? if (dev->driver->pm && dev->driver->pm->runtime_resume)\n" + ">>>> + ? ? ? ? ? ? ? ret = dev->driver->pm->runtime_resume(dev);\n" ">>>> +\n" - ">>>> + \302\240 \302\240 \302\240 return ret;\n" + ">>>> + ? ? ? return ret;\n" ">>>> +};\n" ">>>> +\n" ">>>> +int platform_pm_runtime_idle(struct device *dev)\n" ">>>> +{\n" - ">>>> + \302\240 \302\240 \302\240 int ret;\n" + ">>>> + ? ? ? int ret;\n" ">>>> +\n" - ">>>> + \302\240 \302\240 \302\240 ret = pm_runtime_suspend(dev);\n" - ">>>> + \302\240 \302\240 \302\240 dev_dbg(dev, \"%s [%d]\\n\", __func__, ret);\n" + ">>>> + ? ? ? ret = pm_runtime_suspend(dev);\n" + ">>>> + ? ? ? dev_dbg(dev, \"%s [%d]\\n\", __func__, ret);\n" ">>>> +\n" - ">>>> + \302\240 \302\240 \302\240 return 0;\n" + ">>>> + ? ? ? return 0;\n" ">>>> +};\n" ">>>> +#endif /* CONFIG_PM_RUNTIME */\n" ">>>> +\n" @@ -351,13 +347,9 @@ ">>>>\n" ">>>> _______________________________________________\n" ">>>> linux-arm-kernel mailing list\n" - ">>>> linux-arm-kernel@lists.infradead.org\n" + ">>>> linux-arm-kernel at lists.infradead.org\n" ">>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel\n" ">>>>\n" - ">>\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-omap\" in\n" - "the body of a message to majordomo@vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + >> -9ea186bc57e0e001371db24ef91d8a15b02554c69d0c1c067678ccf2de8f1dde +3ce4c45c929a0e215dd683579383e97a3cd5200f9913d1d88c55cd2c713805d0
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.