| Message ID | 87liw8agk4.fsf@ti.com |
|---|---|
| State | New |
| Headers | show |
Hi, * Madhusudhan.Gowda@elektrobit.com <Madhusudhan.Gowda@elektrobit.com> [120127 10:25]: > Hi Tony, > > Please pull the PM EMU off mode fix for v3.3 It's best that Kevin queues this as it affects PM. Or it at least needs an ack from Kevin. Regards, Tony > Thanks > Gowda > > The following changes since commit > 1c6ece3c23e58d0dbc687407d606f3560ded582a: > > Merge branch 'omap_fixes_a_3.3rc' of git://git.pwsan.com/linux-2.6 > (2012-01-26 16:48:37 -0800) > > are available in the git repository at: > > git://github.com/elektrobit/linux.git linux-omap-emu-fix > > Madhusudhan Gowda (1): > ARM: OMAP3 PM:Save and restore EMU context across MPU OFF > > arch/arm/mach-omap2/cm2xxx_3xxx.c | 16 ++++++++++++---- > arch/arm/mach-omap2/cm2xxx_3xxx.h | 2 ++ > arch/arm/mach-omap2/pm34xx.c | 8 ++++++++ > 3 files changed, 22 insertions(+), 4 deletions(-) > > > ---------------------------------------------------------------- > Please note: This e-mail may contain confidential information > intended solely for the addressee. If you have received this > e-mail in error, please do not disclose it to anyone, notify > the sender promptly, and delete the message from your system. > Thank you. >
Thanks Tony Hi Kevin Please do the needful and pull the same. Best Regards Gowda -----Original Message----- From: linux-arm-kernel-bounces@lists.infradead.org [mailto:linux-arm-kernel-bounces@lists.infradead.org] On Behalf Of Tony Lindgren Sent: 27 January 2012 21:03 To: Gowda Madhusudhan Cc: Kevin Hilman; linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org Subject: Re: [GIT PULL] OMAP PM EMU fix for v3.3 Hi, * Madhusudhan.Gowda@elektrobit.com <Madhusudhan.Gowda@elektrobit.com> [120127 10:25]: > Hi Tony, > > Please pull the PM EMU off mode fix for v3.3 It's best that Kevin queues this as it affects PM. Or it at least needs an ack from Kevin. Regards, Tony > Thanks > Gowda > > The following changes since commit > 1c6ece3c23e58d0dbc687407d606f3560ded582a: > > Merge branch 'omap_fixes_a_3.3rc' of git://git.pwsan.com/linux-2.6 > (2012-01-26 16:48:37 -0800) > > are available in the git repository at: > > git://github.com/elektrobit/linux.git linux-omap-emu-fix > > Madhusudhan Gowda (1): > ARM: OMAP3 PM:Save and restore EMU context across MPU OFF > > arch/arm/mach-omap2/cm2xxx_3xxx.c | 16 ++++++++++++---- > arch/arm/mach-omap2/cm2xxx_3xxx.h | 2 ++ > arch/arm/mach-omap2/pm34xx.c | 8 ++++++++ > 3 files changed, 22 insertions(+), 4 deletions(-) > > > ---------------------------------------------------------------- > Please note: This e-mail may contain confidential information intended > solely for the addressee. If you have received this e-mail in error, > please do not disclose it to anyone, notify the sender promptly, and > delete the message from your system. > Thank you. >
Hi Kevin, I think you have missed my last mail. Could you please ACK the pull request and pull the same. Best Regards Gowda -----Original Message----- From: linux-arm-kernel-bounces@lists.infradead.org [mailto:linux-arm-kernel-bounces@lists.infradead.org] On Behalf Of linux-arm-kernel-bounces+madhusudhan.gowda=elektrobit.com@lists.infradea d.org Sent: 28 January 2012 09:58 To: tony@atomide.com; khilman@ti.com Cc: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org Subject: RE: [GIT PULL] OMAP PM EMU fix for v3.3 Thanks Tony Hi Kevin Please do the needful and pull the same. Best Regards Gowda -----Original Message----- From: linux-arm-kernel-bounces@lists.infradead.org [mailto:linux-arm-kernel-bounces@lists.infradead.org] On Behalf Of Tony Lindgren Sent: 27 January 2012 21:03 To: Gowda Madhusudhan Cc: Kevin Hilman; linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org Subject: Re: [GIT PULL] OMAP PM EMU fix for v3.3 Hi, * Madhusudhan.Gowda@elektrobit.com <Madhusudhan.Gowda@elektrobit.com> [120127 10:25]: > Hi Tony, > > Please pull the PM EMU off mode fix for v3.3 It's best that Kevin queues this as it affects PM. Or it at least needs an ack from Kevin. Regards, Tony > Thanks > Gowda > > The following changes since commit > 1c6ece3c23e58d0dbc687407d606f3560ded582a: > > Merge branch 'omap_fixes_a_3.3rc' of git://git.pwsan.com/linux-2.6 > (2012-01-26 16:48:37 -0800) > > are available in the git repository at: > > git://github.com/elektrobit/linux.git linux-omap-emu-fix > > Madhusudhan Gowda (1): > ARM: OMAP3 PM:Save and restore EMU context across MPU OFF > > arch/arm/mach-omap2/cm2xxx_3xxx.c | 16 ++++++++++++---- > arch/arm/mach-omap2/cm2xxx_3xxx.h | 2 ++ > arch/arm/mach-omap2/pm34xx.c | 8 ++++++++ > 3 files changed, 22 insertions(+), 4 deletions(-) > > > ---------------------------------------------------------------- > Please note: This e-mail may contain confidential information intended > solely for the addressee. If you have received this e-mail in error, > please do not disclose it to anyone, notify the sender promptly, and > delete the message from your system. > Thank you. >
+Paul Paul maintains the CM core code and should take this patch if he's OK with it. Also, it is most helpful if you describe what platforms it was tested on and exactly how you tested it. Thanks, Kevin <Madhusudhan.Gowda@elektrobit.com> writes: > Hi Kevin, > > I think you have missed my last mail. Could you please ACK the pull > request and pull the same. > > Best Regards > Gowda > > > -----Original Message----- > From: linux-arm-kernel-bounces@lists.infradead.org > [mailto:linux-arm-kernel-bounces@lists.infradead.org] On Behalf Of > linux-arm-kernel-bounces+madhusudhan.gowda=elektrobit.com@lists.infradea > d.org > Sent: 28 January 2012 09:58 > To: tony@atomide.com; khilman@ti.com > Cc: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org > Subject: RE: [GIT PULL] OMAP PM EMU fix for v3.3 > > Thanks Tony > > Hi Kevin > Please do the needful and pull the same. > > Best Regards > Gowda > > > -----Original Message----- > From: linux-arm-kernel-bounces@lists.infradead.org > [mailto:linux-arm-kernel-bounces@lists.infradead.org] On Behalf Of Tony > Lindgren > Sent: 27 January 2012 21:03 > To: Gowda Madhusudhan > Cc: Kevin Hilman; linux-omap@vger.kernel.org; > linux-arm-kernel@lists.infradead.org > Subject: Re: [GIT PULL] OMAP PM EMU fix for v3.3 > > Hi, > > * Madhusudhan.Gowda@elektrobit.com <Madhusudhan.Gowda@elektrobit.com> > [120127 10:25]: >> Hi Tony, >> >> Please pull the PM EMU off mode fix for v3.3 > > It's best that Kevin queues this as it affects PM. Or it at least needs > an ack from Kevin. > > Regards, > > Tony > >> Thanks >> Gowda >> >> The following changes since commit >> 1c6ece3c23e58d0dbc687407d606f3560ded582a: >> >> Merge branch 'omap_fixes_a_3.3rc' of git://git.pwsan.com/linux-2.6 >> (2012-01-26 16:48:37 -0800) >> >> are available in the git repository at: >> >> git://github.com/elektrobit/linux.git linux-omap-emu-fix >> >> Madhusudhan Gowda (1): >> ARM: OMAP3 PM:Save and restore EMU context across MPU OFF >> >> arch/arm/mach-omap2/cm2xxx_3xxx.c | 16 ++++++++++++---- >> arch/arm/mach-omap2/cm2xxx_3xxx.h | 2 ++ >> arch/arm/mach-omap2/pm34xx.c | 8 ++++++++ >> 3 files changed, 22 insertions(+), 4 deletions(-) >> >> >> ---------------------------------------------------------------- >> Please note: This e-mail may contain confidential information intended > >> solely for the addressee. If you have received this e-mail in error, >> please do not disclose it to anyone, notify the sender promptly, and >> delete the message from your system. >> Thank you. >> > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > > ---------------------------------------------------------------- > Please note: This e-mail may contain confidential information intended > solely for the addressee. If you have received this e-mail in error, > please do not disclose it to anyone, notify the sender promptly, and > delete the message from your system. > Thank you. > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@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
Hi Kevin / Paul, I have tested this on beagle board as well as on OMAP3630 based propriatory phone using SDTI serial trace interface. Also you can test it by just observing the CM_EMU (48005100) clkstctrl register 48 => 00000001 Across MPU OFF alone [root@beagleboard /]# echo 0 > /sys/kernel/debug/pm_debug/neon_pwrdm/suspend [root@beagleboard /]# echo 0 > /sys/kernel/debug/pm_debug/mpu_pwrdm/suspend [root@beagleboard /]# echo 1 > /sys/kernel/debug/pm_debug/core_pwrdm/suspend [root@beagleboard /]# echo 1 > /sys/kernel/debug/pm_debug/per_pwrdm/suspend [root@beagleboard /]# echo mem >/sys/power/state [ 59.694671] PM: Syncing filesystems ... done. [ 59.758209] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 59.789947] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 59.820709] Suspending console(s) (use no_console_suspend to debug) [ 60.055816] PM: suspend of devices complete after 212.493 msecs [ 60.059661] PM: late suspend of devices complete after 3.784 msecs [ 60.059753] Disabling non-boot CPUs ... [ 64.299865] Successfully put all powerdomains to target state [ 64.302551] PM: early resume of devices complete after 2.319 msecs [ 64.636444] PM: resume of devices complete after 332.336 msecs [ 64.688446] Restarting tasks ... done. [root@beagleboard /]# And then print again the CM_EMU (48005100) clkstctrl register offset 48 this will have the reset value and PRM_EMU (48307100) offset e4 => 00000100 register confirms the domain wakeup reset from OFF. At this moment the SDTI serial trace interface looses connection. With my patch applied the CM_EMU (48005100) clkstctrl register restores it initial setting across MPU OFF. Thanks Gowda -----Original Message----- From: Kevin Hilman [mailto:khilman@ti.com] Sent: 20 February 2012 17:30 To: Gowda Madhusudhan; Paul Walmsley Cc: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org; tony@atomide.com Subject: Re: [GIT PULL] OMAP PM EMU fix for v3.3 +Paul Paul maintains the CM core code and should take this patch if he's OK with it. Also, it is most helpful if you describe what platforms it was tested on and exactly how you tested it. Thanks, Kevin <Madhusudhan.Gowda@elektrobit.com> writes: > Hi Kevin, > > I think you have missed my last mail. Could you please ACK the pull > request and pull the same. > > Best Regards > Gowda > > > -----Original Message----- > From: linux-arm-kernel-bounces@lists.infradead.org > [mailto:linux-arm-kernel-bounces@lists.infradead.org] On Behalf Of > linux-arm-kernel-bounces+madhusudhan.gowda=elektrobit.com@lists.infrad > linux-arm-kernel-bounces+ea > d.org > Sent: 28 January 2012 09:58 > To: tony@atomide.com; khilman@ti.com > Cc: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org > Subject: RE: [GIT PULL] OMAP PM EMU fix for v3.3 > > Thanks Tony > > Hi Kevin > Please do the needful and pull the same. > > Best Regards > Gowda > > > -----Original Message----- > From: linux-arm-kernel-bounces@lists.infradead.org > [mailto:linux-arm-kernel-bounces@lists.infradead.org] On Behalf Of > Tony Lindgren > Sent: 27 January 2012 21:03 > To: Gowda Madhusudhan > Cc: Kevin Hilman; linux-omap@vger.kernel.org; > linux-arm-kernel@lists.infradead.org > Subject: Re: [GIT PULL] OMAP PM EMU fix for v3.3 > > Hi, > > * Madhusudhan.Gowda@elektrobit.com <Madhusudhan.Gowda@elektrobit.com> > [120127 10:25]: >> Hi Tony, >> >> Please pull the PM EMU off mode fix for v3.3 > > It's best that Kevin queues this as it affects PM. Or it at least > needs an ack from Kevin. > > Regards, > > Tony > >> Thanks >> Gowda >> >> The following changes since commit >> 1c6ece3c23e58d0dbc687407d606f3560ded582a: >> >> Merge branch 'omap_fixes_a_3.3rc' of git://git.pwsan.com/linux-2.6 >> (2012-01-26 16:48:37 -0800) >> >> are available in the git repository at: >> >> git://github.com/elektrobit/linux.git linux-omap-emu-fix >> >> Madhusudhan Gowda (1): >> ARM: OMAP3 PM:Save and restore EMU context across MPU OFF >> >> arch/arm/mach-omap2/cm2xxx_3xxx.c | 16 ++++++++++++---- >> arch/arm/mach-omap2/cm2xxx_3xxx.h | 2 ++ >> arch/arm/mach-omap2/pm34xx.c | 8 ++++++++ >> 3 files changed, 22 insertions(+), 4 deletions(-) >> >> >> ---------------------------------------------------------------- >> Please note: This e-mail may contain confidential information >> intended > >> solely for the addressee. If you have received this e-mail in error, >> please do not disclose it to anyone, notify the sender promptly, and >> delete the message from your system. >> Thank you. >> > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > > ---------------------------------------------------------------- > Please note: This e-mail may contain confidential information intended > solely for the addressee. If you have received this e-mail in error, > please do not disclose it to anyone, notify the sender promptly, and > delete the message from your system. > Thank you. > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@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
Hello Gowda, A few questions... On Wed, 22 Feb 2012, Madhusudhan.Gowda@elektrobit.com wrote: > I have tested this on beagle board as well as on OMAP3630 based > propriatory phone using SDTI serial trace interface. What driver are you using for SDTI? Does it use pm_runtime* or call clk_enable() on some clock when it is in use? Are you defining a hwmod for it? I don't see an SDTI driver in mainline, but maybe I am just missing it. If it's not there, could you please post it or post a link to it so we can take a look at what it's doing? > Also you can test it by just observing the > CM_EMU (48005100) clkstctrl register > 48 => 00000001 > Across MPU OFF alone > > [root@beagleboard /]# echo 0 > > /sys/kernel/debug/pm_debug/neon_pwrdm/suspend > [root@beagleboard /]# echo 0 > > /sys/kernel/debug/pm_debug/mpu_pwrdm/suspend > [root@beagleboard /]# echo 1 > > /sys/kernel/debug/pm_debug/core_pwrdm/suspend > [root@beagleboard /]# echo 1 > > /sys/kernel/debug/pm_debug/per_pwrdm/suspend > [root@beagleboard /]# echo mem >/sys/power/state > [ 59.694671] PM: Syncing filesystems ... done. > [ 59.758209] Freezing user space processes ... (elapsed 0.02 seconds) > done. > [ 59.789947] Freezing remaining freezable tasks ... (elapsed 0.02 > seconds) done. > [ 59.820709] Suspending console(s) (use no_console_suspend to debug) > [ 60.055816] PM: suspend of devices complete after 212.493 msecs > [ 60.059661] PM: late suspend of devices complete after 3.784 msecs > [ 60.059753] Disabling non-boot CPUs ... > [ 64.299865] Successfully put all powerdomains to target state > [ 64.302551] PM: early resume of devices complete after 2.319 msecs > [ 64.636444] PM: resume of devices complete after 332.336 msecs > [ 64.688446] Restarting tasks ... done. > [root@beagleboard /]# > > And then print again the CM_EMU (48005100) clkstctrl register offset 48 > this will have the reset value and PRM_EMU (48307100) offset e4 => > 00000100 register confirms the domain wakeup reset from OFF. > > At this moment the SDTI serial trace interface looses connection. > > With my patch applied the CM_EMU (48005100) clkstctrl register restores > it initial setting across MPU OFF. Maybe you can walk through these thoughts with me and see if it makes sense to you. When the PM code initializes, it will put the EMU clockdomain to software-supervised sleep. (Ideally it would put it to hardware-supervised idle, but Jouni turned this off a long time ago, apparently due to some PRCM usecounting problem with it -- which may simply have been some software problem on our part?) That accounts for CM_CLKSTCTRL_EMU being set to 0x1 before MPU OFF. Does the SDTI work for you when CM_CLKSTCTRL_EMU is set to 0x1? There's no FCLKEN/ICLKEN bit for the PRCM to use-count, it seems :-( Although maybe this is done through the SDTI_WINCTRL register? I observe the same phenomenon that you do, that when MPU comes back from OFF, CM_CLKSTCTRL_EMU is set to 0x2. From reading the TRM, it's not clear to me what is causing that, although I'd agree with your conclusion that it's related to the MPU's reset line. But here's the part that's unclear to me about your description: according to the TRM, 0x2 means software-supervised wakeup. So the EMU clockdomain should be awake at that point. That shouldn't prevent the SDTI from working; in fact quite the opposite. So I don't really understand how your patch would fix anything in this regard. Any thoughts? My suspicion, by the way, is that the underlying problem may be with the SDTI driver that you're using. My guess would be that it's not integrated with the OMAP power management infrastructure (via pm_runtime* calls), and that's what's causing the problem. - Paul
Hi Paul, Please find my comments inlined. Thanks Gowda -----Original Message----- From: linux-arm-kernel-bounces@lists.infradead.org [mailto:linux-arm-kernel-bounces@lists.infradead.org] On Behalf Of Paul Walmsley Sent: 23 February 2012 06:09 To: Gowda Madhusudhan Cc: khilman@ti.com; tony@atomide.com; linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org Subject: RE: [GIT PULL] OMAP PM EMU fix for v3.3 Hello Gowda, A few questions... On Wed, 22 Feb 2012, Madhusudhan.Gowda@elektrobit.com wrote: > I have tested this on beagle board as well as on OMAP3630 based > propriatory phone using SDTI serial trace interface. What driver are you using for SDTI? Does it use pm_runtime* or call clk_enable() on some clock when it is in use? Are you defining a hwmod for it? I don't see an SDTI driver in mainline, but maybe I am just missing it. If it's not there, could you please post it or post a link to it so we can take a look at what it's doing? > Also you can test it by just observing the CM_EMU (48005100) clkstctrl > register > 48 => 00000001 > Across MPU OFF alone > > [root@beagleboard /]# echo 0 > > /sys/kernel/debug/pm_debug/neon_pwrdm/suspend > [root@beagleboard /]# echo 0 > > /sys/kernel/debug/pm_debug/mpu_pwrdm/suspend > [root@beagleboard /]# echo 1 > > /sys/kernel/debug/pm_debug/core_pwrdm/suspend > [root@beagleboard /]# echo 1 > > /sys/kernel/debug/pm_debug/per_pwrdm/suspend > [root@beagleboard /]# echo mem >/sys/power/state > [ 59.694671] PM: Syncing filesystems ... done. > [ 59.758209] Freezing user space processes ... (elapsed 0.02 seconds) > done. > [ 59.789947] Freezing remaining freezable tasks ... (elapsed 0.02 > seconds) done. > [ 59.820709] Suspending console(s) (use no_console_suspend to debug) > [ 60.055816] PM: suspend of devices complete after 212.493 msecs > [ 60.059661] PM: late suspend of devices complete after 3.784 msecs > [ 60.059753] Disabling non-boot CPUs ... > [ 64.299865] Successfully put all powerdomains to target state > [ 64.302551] PM: early resume of devices complete after 2.319 msecs > [ 64.636444] PM: resume of devices complete after 332.336 msecs > [ 64.688446] Restarting tasks ... done. > [root@beagleboard /]# > > And then print again the CM_EMU (48005100) clkstctrl register offset > 48 this will have the reset value and PRM_EMU (48307100) offset e4 => > 00000100 register confirms the domain wakeup reset from OFF. > > At this moment the SDTI serial trace interface looses connection. > > With my patch applied the CM_EMU (48005100) clkstctrl register > restores it initial setting across MPU OFF. Maybe you can walk through these thoughts with me and see if it makes sense to you. When the PM code initializes, it will put the EMU clockdomain to software-supervised sleep. (Ideally it would put it to hardware-supervised idle, but Jouni turned this off a long time ago, apparently due to some PRCM usecounting problem with it -- which may simply have been some software problem on our part?) That accounts for CM_CLKSTCTRL_EMU being set to 0x1 before MPU OFF. Does the SDTI work for you when CM_CLKSTCTRL_EMU is set to 0x1? There's no FCLKEN/ICLKEN bit for the PRCM to use-count, it seems :-( Although maybe this is done through the SDTI_WINCTRL register? I observe the same phenomenon that you do, that when MPU comes back from OFF, CM_CLKSTCTRL_EMU is set to 0x2. From reading the TRM, it's not clear to me what is causing that, although I'd agree with your conclusion that it's related to the MPU's reset line. But here's the part that's unclear to me about your description: according to the TRM, 0x2 means software-supervised wakeup. So the EMU clockdomain should be awake at that point. That shouldn't prevent the SDTI from working; in fact quite the opposite. So I don't really understand how your patch would fix anything in this regard. Any thoughts? My suspicion, by the way, is that the underlying problem may be with the SDTI driver that you're using. My guess would be that it's not integrated with the OMAP power management infrastructure (via pm_runtime* calls), and that's what's causing the problem. [Gowda] I found this BUG in the CM code while trying to use both SDTI as well as requirement of enabling Hardware supervised transition CLKTRCTRL_EMU to 0x3. SDTI requires the softwre supervised transition to keep connected, by enabling Hardware supervised transition SDTI does not like it so Jouni had commented out the HW supervised transtion. Which I agree it is fine on SDTI part. .flags = /* CLKDM_CAN_ENABLE_AUTO | */CLKDM_CAN_SWSUP, But my point here is when I set the HW supervised transition, across MPU OFF the register loses its previous value and changes to reset value 0x2 (SW supervised) is not correct. So I submitted this patch for fixing this general CM code bug. Please let me know if my comments answers your question. - Paul
Hi On Thu, 23 Feb 2012, Madhusudhan.Gowda@elektrobit.com wrote: > [Gowda] I found this BUG in the CM code while trying to use both SDTI as > well as requirement of enabling Hardware supervised transition > CLKTRCTRL_EMU to 0x3. > > SDTI requires the softwre supervised transition to keep connected, by > enabling Hardware supervised transition SDTI does not like it so Jouni > had commented out the HW supervised transtion. Which I agree it is fine > on SDTI part. > .flags = /* CLKDM_CAN_ENABLE_AUTO | */CLKDM_CAN_SWSUP, > > But my point here is when I set the HW supervised transition, across MPU > OFF the register loses its previous value and changes to reset value 0x2 > (SW supervised) is not correct. So I submitted this patch for fixing > this general CM code bug. Okay, that's a little more clear. So this patch does not affect the SDTI functionality with your driver? Your patch description reads: "Embedded trace debug tools like Serial Trace Interface(sti) using EMU domain loses connection across MPU OFF. The patch fixes this issue" But it sounds like that's not the case? At least, if the reset value for CM_CLKSTCTRL_EMU is 0x2, I don't understand how this patch could fix it. About the patch - I'm fine with the basic underlying idea, but so far it looks like this is material for 3.4 rather than 3.3-rc, since it's not a regression? > Please let me know if my comments answers your question. Well I was hoping that you might answer my earlier questions about whether the driver you're using calls into the OMAP infrastructure via pm_runtime*(), and whether its clocks and hwmod data are defined. - Paul
Hi Paul, Please find my comments inlined Thanks Gowda -----Original Message----- From: Paul Walmsley [mailto:paul@pwsan.com] Sent: 24 February 2012 02:11 To: Gowda Madhusudhan Cc: khilman@ti.com; tony@atomide.com; linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org Subject: RE: [GIT PULL] OMAP PM EMU fix for v3.3 Hi On Thu, 23 Feb 2012, Madhusudhan.Gowda@elektrobit.com wrote: > [Gowda] I found this BUG in the CM code while trying to use both SDTI > as well as requirement of enabling Hardware supervised transition > CLKTRCTRL_EMU to 0x3. > > SDTI requires the softwre supervised transition to keep connected, by > enabling Hardware supervised transition SDTI does not like it so Jouni > had commented out the HW supervised transtion. Which I agree it is > fine on SDTI part. > .flags = /* CLKDM_CAN_ENABLE_AUTO | */CLKDM_CAN_SWSUP, > > But my point here is when I set the HW supervised transition, across > MPU OFF the register loses its previous value and changes to reset > value 0x2 (SW supervised) is not correct. So I submitted this patch > for fixing this general CM code bug. Okay, that's a little more clear. So this patch does not affect the SDTI functionality with your driver? Your patch description reads: "Embedded trace debug tools like Serial Trace Interface(sti) using EMU domain loses connection across MPU OFF. The patch fixes this issue" But it sounds like that's not the case? At least, if the reset value for CM_CLKSTCTRL_EMU is 0x2, I don't understand how this patch could fix it. [GOWDA] I think I should edit the commit log to avoid any confusion on SDTI functionality, is it ok if I do this on the GIT PULL branch ? About the patch - I'm fine with the basic underlying idea, but so far it looks like this is material for 3.4 rather than 3.3-rc, since it's not a regression? [GOWDA] I agree it is not a regression patch so can be queued for 3.4. > Please let me know if my comments answers your question. Well I was hoping that you might answer my earlier questions about whether the driver you're using calls into the OMAP infrastructure via pm_runtime*(), and whether its clocks and hwmod data are defined. [GOWDA] It does not use the runtime pm infrastructure. In my environment # CONFIG_PM_RUNTIME is not set - Paul
On Fri, 24 Feb 2012, Madhusudhan.Gowda@elektrobit.com wrote: > [GOWDA] I think I should edit the commit log to avoid any confusion on > SDTI functionality, is it ok if I do this on the GIT PULL branch ? I'll just download your patch off the list, since I have some local changes to make. So if you'd like to edit the patch description, I'd suggest just replying with the updated message to this thread. > [GOWDA] I agree it is not a regression patch so can be queued for 3.4. Great. > [GOWDA] It does not use the runtime pm infrastructure. In my environment > # CONFIG_PM_RUNTIME is not set Interesting. - Paul
Tony, Please pull the I2C cleanup changes below for v3.1. This is the same series from Andy Green that has been posted/reviewed/tested many times except the omap_hwmod data patches have been separated out into a separate series. This version also has an Ack from Ben Dooks for merge via linux-omap. Kevin The following changes since commit fe0d42203cb5616eeff68b14576a0f7e2dd56625: Linux 3.0-rc6 (2011-07-04 15:56:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.1/i2c-andy Andy Green (15): I2C: OMAP2+: Name registers in I2C IP V2 only accordingly I2C: OMAP2+: Introduce I2C IP versioning constants I2C: OMAP: add rev to omap i2c platform data I2C: OMAP1: set IP revision in platform data I2C: OMAP2+: Pass hwmod rev knowledge via platform_data when i2c bus added I2C: OMAP2+: use platform_data ip revision to select register map I2C: OMAP2+: Solve array bounds overflow error on i2c idle I2C: OMAP2+: address confused probed version naming I2C: OMAP2+: increase omap_i2c_dev_attr flags from u8 to u32 I2C: OMAP1/OMAP2+: add flags field to omap i2c platform data I2C: OMAP2+: Pass flags up to omap i2c platform_data as well I2C: OMAP1/OMAP2+: create omap I2C functionality flags for each cpu_... test I2C: OMAP1: set i2c unit feature implementation flags in platform data I2C: OMAP2+: Convert omap I2C driver to use feature implementation flags from platform data I2C: OMAP1/OMAP2+: prepend I2C IP version to probed version shown in dev_info arch/arm/plat-omap/i2c.c | 27 +++++++++ arch/arm/plat-omap/include/plat/i2c.h | 3 +- drivers/i2c/busses/i2c-omap.c | 100 ++++++++++++++++++--------------- include/linux/i2c-omap.h | 29 ++++++++++ 4 files changed, 113 insertions(+), 46 deletions(-)