Re: [PATCH 00/09] OMAP PM interface implementation using Shared resource f/w
Hi Rajendra, Hi, The patches which follow implement the API's defined by Paul Walmsley as part of the OMAP PM Interface on OMAP3430sdp. Shared resource f/w is used for the underlying implementation. The following resources are modeled 1) MPU/CORE latency resources 2) Power Domain latency resources (One for each Power domain) 3) OPP/Freq resources (For DVFS) The below API from the OMAP PM interface is yet to be implemented. void omap_pm_set_min_bus_tput(struct device *dev, struct bus_type *bus, unsigned long r) I tried to apply this to linux-omap, but when compiling I get the following error message : arch/arm/mach-omap2/clockdomain.c:38:30: error: asm/arch/omap-pm.h: No such file or directory arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_clk_enable': arch/arm/mach-omap2/clockdomain.c:572: error: implicit declaration of function 'omap_pm_pwrdm_active' arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_clk_disable': arch/arm/mach-omap2/clockdomain.c:626: error: implicit declaration of function 'omap_pm_pwrdm_inactive' make[1]: *** [arch/arm/mach-omap2/clockdomain.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 Seems there is a file missing from the patchset. Thanks, Peter. -- goa is a state of mind -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 00/09] OMAP PM interface implementation using Sharedresource f/w
-Original Message- From: Peter 'p2' De Schrijver [mailto:[EMAIL PROTECTED] Sent: Friday, July 11, 2008 5:23 PM To: ext Rajendra Nayak Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 00/09] OMAP PM interface implementation using Sharedresource f/w Hi Rajendra, Hi, The patches which follow implement the API's defined by Paul Walmsley as part of the OMAP PM Interface on OMAP3430sdp. Shared resource f/w is used for the underlying implementation. The following resources are modeled 1) MPU/CORE latency resources 2) Power Domain latency resources (One for each Power domain) 3) OPP/Freq resources (For DVFS) The below API from the OMAP PM interface is yet to be implemented. void omap_pm_set_min_bus_tput(struct device *dev, struct bus_type *bus, unsigned long r) I tried to apply this to linux-omap, but when compiling I get the following error message : arch/arm/mach-omap2/clockdomain.c:38:30: error: asm/arch/omap-pm.h: No such file or directory This file was part of Paul's no-op patch for omap-pm layer. You should be able to fix this if you apply the no-op patch. arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_clk_enable': arch/arm/mach-omap2/clockdomain.c:572: error: implicit declaration of function 'omap_pm_pwrdm_active' arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_clk_disable': arch/arm/mach-omap2/clockdomain.c:626: error: implicit declaration of function 'omap_pm_pwrdm_inactive' make[1]: *** [arch/arm/mach-omap2/clockdomain.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 Seems there is a file missing from the patchset. Thanks, Peter. -- goa is a state of mind -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: CPUIDLE PM: check_bm fix.
ext Woodruff, Richard [EMAIL PROTECTED] writes: The current check will: On activity raise a cpuidle bus master activity failure for some number of seconds. This allows normal typing for extended periods. It does this by marking UART function IRQs with a time stamp and it checks internal state to make sure RX/TX engine is not busy or has queued data waiting. Isn't this exactly what is done in Added sleep support to UART patch in workaround patch set? See last mail. It probably is. I assumed that was derived from our code which has been available for a long time before. I didn't actually look at it very closely with that assumption. This activity assertion will gate the usage of C states where its F- CLOCK is cut. At the same time its natural wake up events are enabled (along with the above hack as the tx events are not currenly hooked into the wakeup logic). When OFF/RET mode is selected IO pad is enabled for the port wakeup. I have seen this in CDP reference code. Is there some specific reason why this is enabled dynamically in code? Not that I am aware. Do you think there is a need to toggle it? Today only the global IOPAD enable is toggled (which is necessary for pad state latching). No, I might have seen this global IOPAD enable. This is valuable information. Currently in linux-omap setting IOPAD enable bit is done on initialization. We haven't noticed any problems this far, but this feature haven't been used too much. So probably we have been just lucky? -- Jouni Högander -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: CPUIDLE PM: check_bm fix.
When OFF/RET mode is selected IO pad is enabled for the port wakeup. I have seen this in CDP reference code. Is there some specific reason why this is enabled dynamically in code? Not that I am aware. Do you think there is a need to toggle it? Today only the global IOPAD enable is toggled (which is necessary for pad state latching). No, I might have seen this global IOPAD enable. This is valuable information. Currently in linux-omap setting IOPAD enable bit is done on initialization. We haven't noticed any problems this far, but this feature haven't been used too much. So probably we have been just lucky? The TRM does highlight this procedure of set-before-wake and clear-after-wake in several spots. Search on PM_WKEN_WKUP. I think I may have not worded that completely right. To clarify, it was my understanding that the wakeup event generated by a pad event wouldn't be cleared with out the toggle. After you wake up you can read pad status to find out which ball was responsible for the wakeup event. After your done inspecting them, use the toggle to clear it. Each wakeup capable ball at MUX register has a status bit you read to see if it was the one which woke you up (if you care). Unlike say an IRQ register status register there is no way to clear this at that interface. Note there is no selectable polarity for that pin, so status reflects a change from latched state at sleep. What is clearly written somewhere is the wake up daisy chain is enabled by turning it on, and disabled and _reset_ at turn off time. The actual state latching happens at time of transition to sleep. The current level is captured, current padconfs saved into wakeup domain scratch memory and, wakeup armed. On event it all unwinds. Regards, Richard W. Regards, Richard W.
