OMAP I2C cleanups for v3.1

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(-)

Hi Tony,

Please pull the PM EMU off mode fix for v3.3

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,

It's best that Kevin queues this as it affects PM. Or it at least needs an ack from Kevin.

Regards,

Tony

Thanks Tony

Hi Kevin
Please do the needful and pull the same.

Best Regards
Gowda

-----Original Message-----
From: [email protected] [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of Tony Lindgren
Sent: 27 January 2012 21:03
To: Gowda Madhusudhan
Cc: Kevin Hilman; linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [GIT PULL] OMAP PM EMU fix for v3.3

Hi,

* Madhusudhan.Gowda at elektrobit.com <[email protected]> [120127 10:25]:

It's best that Kevin queues this as it affects PM. Or it at least needs an ack from Kevin.

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at 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.

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: [email protected] [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of linux-arm-kernel-bounces+madhusudhan.gowda=elektrobit.com at lists.infradea d.org
Sent: 28 January 2012 09:58
To: tony at atomide.com; khilman at ti.com
Cc: linux-omap at vger.kernel.org; linux-arm-kernel at 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: [email protected] [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of Tony Lindgren
Sent: 27 January 2012 21:03
To: Gowda Madhusudhan
Cc: Kevin Hilman; linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [GIT PULL] OMAP PM EMU fix for v3.3

Hi,

* Madhusudhan.Gowda at elektrobit.com <[email protected]> [120127 10:25]:

It's best that Kevin queues this as it affects PM. Or it at least needs an ack from Kevin.

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at 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 at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

+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

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 at beagleboard /]# echo 0 > /sys/kernel/debug/pm_debug/neon_pwrdm/suspend [root at beagleboard /]# echo 0 > /sys/kernel/debug/pm_debug/mpu_pwrdm/suspend [root at beagleboard /]# echo 1 > /sys/kernel/debug/pm_debug/core_pwrdm/suspend [root at beagleboard /]# echo 1 > /sys/kernel/debug/pm_debug/per_pwrdm/suspend [root at 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 at 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 at ti.com]
Sent: 20 February 2012 17:30
To: Gowda Madhusudhan; Paul Walmsley
Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; tony at 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

Hello Gowda,

A few questions...

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?

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: [email protected] [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of Paul Walmsley
Sent: 23 February 2012 06:09
To: Gowda Madhusudhan
Cc: khilman at ti.com; tony at atomide.com; linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: RE: [GIT PULL] OMAP PM EMU fix for v3.3

Hello Gowda,

A few questions...

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?

seconds)

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Hi

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?

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 at pwsan.com]
Sent: 24 February 2012 02:11
To: Gowda Madhusudhan
Cc: khilman at ti.com; tony at atomide.com; linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: RE: [GIT PULL] OMAP PM EMU fix for v3.3

Hi

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.

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

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.

Great.

Interesting.

- Paul