Patchwork [GIT,PULL] OMAP I2C cleanups for v3.1

login
register
mail settings
Submitter Kevin Hilman
Date July 8, 2011, 4:22 p.m.
Message ID <87liw8agk4.fsf@ti.com>
Download mbox
Permalink /patch/103888/
State New
Headers show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.1/i2c-andy

Comments

Kevin Hilman - July 8, 2011, 4:22 p.m.
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(-)
Tony Lindgren - Jan. 27, 2012, 7:02 p.m.
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.
>
Madhusudhan.Gowda@elektrobit.com - Jan. 28, 2012, 7:58 a.m.
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.
>
Madhusudhan.Gowda@elektrobit.com - Feb. 20, 2012, 9:52 a.m.
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.
>
Kevin Hilman - Feb. 20, 2012, 3:29 p.m.
+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
Madhusudhan.Gowda@elektrobit.com - Feb. 22, 2012, 8:42 a.m.
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
Paul Walmsley - Feb. 23, 2012, 4:09 a.m.
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
Madhusudhan.Gowda@elektrobit.com - Feb. 23, 2012, 9:49 a.m.
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
Paul Walmsley - Feb. 24, 2012, 12:11 a.m.
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
Madhusudhan.Gowda@elektrobit.com - Feb. 24, 2012, 9:20 a.m.
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
Paul Walmsley - Feb. 24, 2012, 9:03 p.m.
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