What is missing from musb - linux-omap merge?

What is missing from musb - linux-omap merge?

[Jarkko Nikula]

[-- Attachment #1: Type: text/plain, Size: 4902 bytes --]

Hi

I've been trying to hunt why the OMAP3 retention on Nokia N900 went
broken in 2.6.39-rc and reason is somewhere around musb code merge with
linux-omap code or vise versa.

I bisected this into:

commit 0df0914d414a504b975f3cc66ace0c16ef55b7f3
Merge: 6899608 05f6894
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Mar 17 19:28:15 2011 -0700

    Merge branch 'omap-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6

Yep, there were conflicts resolved by Linus but those didn't look that
they explain the problem.

So then I went to check the linux-omap branch omap-for-linus that got
pulled to vanilla. Top commit was:

commit 05f689400ea5fa3d71af82f910c8b140f87ad1f3
Merge: 17fe12c 02b7b94
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Mar 14 11:22:22 2011 -0700

    Merge branches 'devel-mux' and 'devel-misc' into omap-for-linus

Here retention and usb networking are working so all were fine in
linux-omap in 2.6.38-rc7.

Then back to vanilla and checking the usb pull.

commit 971f115a50afbe409825c9f3399d5a3b9aca4381
Merge: 2e270d8 500132a
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Mar 16 15:04:26 2011 -0700

    Merge branch 'usb-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6

Yes, musb doesn't compile here... trivial build fix attached as it's
not our interest now (but will bother all bisecters). Here retention
works but usb networking doesn't.

Then I went testing patches from linux-omap/omap-for-linus on top of
vanilla commit that precedes the omap-for-linus pull:

commit 6899608533410557e6698cb9d4ff6df553916e98
Merge: 411f5c7 92c260f
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Mar 17 19:13:18 2011 -0700

    Merge branch 'for-linus' of
git://codeaurora.org/quic/kernel/davidb/linux-ms

Some amount of conflict resolving, mostly trivial, some testing and
came around these commits (note local commit ids):

commit 5cd15f0ba7594e4cd1dd01a100dc94013930a6a9
Author: Hema HK <hemahk@ti.com>
Date:   Thu Feb 17 12:07:17 2011 +0530

    OMAP2430: hwmod data: Add USBOTG

-> Retention ok

commit 2d982bb2593ab64151c4a01758735e67d7db5d36
Author: Hema HK <hemahk@ti.com>
Date:   Thu Feb 17 12:07:18 2011 +0530

    OMAP3xxx: hwmod data: Add USBOTG

commit 6dc0c8ee8bdaac3ad11c4313431d8d7b3c886ede
Author: Hema HK <hemahk@ti.com>
Date:   Thu Feb 17 12:07:19 2011 +0530

    AM35xx: hwmod data: Add USBOTG
 
-> These don't boot

commit 4bd3924ed10bef872e1fbfbb590fb7132df7dd4c
Author: Hema HK <hemahk@ti.com>
Date:   Thu Feb 17 12:07:21 2011 +0530

    OMAP2+: musb: hwmod adaptation for musb registration

-> Boots, usb networking works and but no retention


Then arch/arm/mach-omap2 diff between

vanilla 0df0914d414a504b975f3cc66ace0c16ef55b7f3 (l-o pull)
and
l-o 05f689400ea5fa3d71af82f910c8b140f87ad1f3 (for linus)

doesn't show any suspicious to me. E.g. no differences in
omap_hwmod_3xxx_data.c and clock3xxx_data.c changes are just those
clock name changes that Linus complained. Rest seems to be unrelated.

 Kconfig                        |    1 
 Makefile                       |    2 
 board-3430sdp.c                |   10 
 board-3630sdp.c                |   10 
 board-4430sdp.c                |    1 
 board-am3517crane.c            |   10 
 board-am3517evm.c              |   12 
 board-cm-t35.c                 |   10 
 board-cm-t3517.c               |   10 
 board-devkit8000.c             |   10 
 board-igep0020.c               |   10 
 board-igep0030.c               |   10 
 board-omap3beagle.c            |   10 
 board-omap3evm.c               |   14 -
 board-omap3pandora.c           |   10 
 board-omap3stalker.c           |   10 
 board-omap3touchbook.c         |   10 
 board-omap4panda.c             |   11 
 board-overo.c                  |   10 
 board-zoom.c                   |   10 
 clock3xxx_data.c               |   19 +
 clock44xx_data.c               |   10 
 include/mach/board-zoom.h.orig |   11 
 include/mach/debug-macro.S     |   13 
 omap4-common.c                 |    7 
 omap_phy_internal.c            |   29 +-
 pm.h                           |    2 
 sleep24xx.S                    |    2 
 sleep34xx.S                    |    2 
 sram242x.S                     |    3 
 sram243x.S                     |    3 
 sram34xx.S                     |    1 
 usb-ehci.c                     |  522 -------------------------------------
 usb-host.c                     |  574 +++++++++++++++++++++++++++++++++++++++++
 usb-musb.c                     |    3 
 35 files changed, 737 insertions(+), 645 deletions(-)

These findings made me thinking are there some patch or patchset
missing for musb as there are these musb build breakages and usb
networking not working in mainline issues, retention breaks only when
applying patches from linux-omap/omap-for-linus but what are ok in
linux-omap 2.6.38-rc7?

-- 
Jarkko

[-- Attachment #2: musb.diff --]
[-- Type: text/x-diff, Size: 454 bytes --]

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 241fc94..5298949 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -214,10 +214,6 @@ void __init usb_musb_init(struct omap_musb_board_data *board_data)
 
 	if (platform_device_register(&musb_device) < 0)
 		printk(KERN_ERR "Unable to register HS-USB (MUSB) device\n");
-
-	if (cpu_is_omap44xx())
-		omap4430_phy_init(dev);
-
 }
 
 #else

Re: What is missing from musb - linux-omap merge?

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 6670 bytes --]

Hi,

On Wed, Apr 06, 2011 at 04:23:34PM +0300, Jarkko Nikula wrote:
> Hi
> 
> I've been trying to hunt why the OMAP3 retention on Nokia N900 went
> broken in 2.6.39-rc and reason is somewhere around musb code merge with
> linux-omap code or vise versa.
> 
> I bisected this into:

I guess it's the missing Hema's patch which should be queued already.
Here it is:

commit 84cebd52a4b5d590af476869dc5b786fe567c095
Author: Hema HK <hemahk@ti.com>
Date:   Thu Mar 17 16:11:58 2011 +0530

    usb: musb: Fix for merge issue
    
    There was conflict while merging 2 patches. Enabling vbus code
    is wrongly moved to error check if loop.
    
    This is a fix to resolve the merge issue.
    
    Signed-off-by: Hema HK <hemahk@ti.com>
    Cc: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 419ca3e..9ecb057 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1880,12 +1880,12 @@ int usb_gadget_probe_driver(struct usb_gadget_driver *driver,
                if (retval < 0) {
                        DBG(1, "add_hcd failed, %d\n", retval);
                        goto err2;
-
-                       if ((musb->xceiv->last_event == USB_EVENT_ID)
-                                               && musb->xceiv->set_vbus)
-                               otg_set_vbus(musb->xceiv, 1);
                }
 
+               if ((musb->xceiv->last_event == USB_EVENT_ID)
+                                       && musb->xceiv->set_vbus)
+                       otg_set_vbus(musb->xceiv, 1);
+
                hcd->self.uses_pio_for_control = 1;
 
                if (musb->xceiv->last_event == USB_EVENT_NONE)


you might also need the one below:

commit ee262c660a855864efa78181cf7b7095b6416098
Author: Hema HK <hemahk@ti.com>
Date:   Tue Mar 22 16:02:12 2011 +0530

    usb: musb: Fix the crash issue during reboot
    
    Below crash observed with commit 7acc6197b76edd0b932a7cbcc6cfad0a8a87f026
    (usb: musb: Idle path retention and offmode support for OMAP3)
    during board reboot.
    
    The musb clock was disabled when musb_shutdown() was called by
    platform_drv_shutdown in which there are register accesses.
    call pm_runtime_get_sync() and pm_runtime_put_sync() in the
    musb_shutdown function.
    
    / # [  172.368774] Unhandled fault: imprecise external abort (0x1406) at 0x400f0000
    [  172.376190] Internal error: : 1406 [#1] SMP
    [  172.380554] last sysfs file: /sys/devices/platform/omap/omap_i2c.4/i2c-4/i2c-dev/i2c-4/dev
    [  172.389221] Modules linked in:
    [  172.392456] CPU: 0    Tainted: G        W    (2.6.38-06671-geddecbb #33)
    [  172.399475] PC is at do_raw_spin_unlock+0x50/0xc0
    [  172.404418] LR is at _raw_spin_unlock_irqrestore+0x24/0x44
    [  172.410186] pc : [<c069bfdc>]    lr : [<c085a7f8>]    psr: 60000093
    [  172.410186] sp : ee993e40  ip : c0d00240  fp : bea9cf14
    [  172.422241] r10: 00000000  r9 : ee992000  r8 : c04b2fa8
    [  172.427703] r7 : 00000000  r6 : c0fa46c0  r5 : ef966124  r4 : ef966124
    [  172.434539] r3 : ef92cbc0  r2 : ef92cbc0  r1 : 00000000  r0 : ef966124
    [  172.441406] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
    [  172.448974] Control: 10c5387d  Table: ae8d804a  DAC: 00000015
    [  172.454986] Process init (pid: 1094, stack limit = 0xee9922f8)
    [  172.461120] Stack: (0xee993e40 to 0xee994000)
    [  172.465667] 3e40: a0000013 c085a7f8 ef966124 a0000013 c0fa46c0 c0761ab4 c0761a70 ef95c008
    [  172.474273] 3e60: ef95c014 c06e2fd0 c06e2fbc c06dea90 00000000 01234567 28121969 c04fccb4
    [  172.482849] 3e80: 00000000 c04fcd04 c0a302bc c04fce44 c0a02600 00000001 00000000 c085cd04
    [  172.491424] 3ea0: 00000000 00000002 c09ea000 c085afc0 ee993f24 00000000 00040001 00000445
    [  172.499999] 3ec0: a8eb9d34 00000027 00000000 00000000 00000000 c0a56a4c 00000000 00000000
    [  172.508575] 3ee0: 00000002 60000093 00000000 c0519aac 00000002 00000080 00000000 c0550420
    [  172.517150] 3f00: 00000000 00000002 ee970000 c0a56a3c c0a56a20 00000002 c0a56a3c 00000000
    [  172.525726] 3f20: c0a56a3c 0000000a c1580e00 c0a56a20 00000002 c0a56a3c c1580e00 c0a56a20
    [  172.534301] 3f40: ef92cbc0 c05173a0 00000001 ef92cbc0 c0576190 c04e3174 20000013 c0517324
    [  172.542877] 3f60: ef815c00 ee90b720 c04e3174 c0576190 00000001 ef92cbc0 c04b2f00 ffffffff
    [  172.551483] 3f80: 00000058 c0517324 00000000 00000000 ffffffff 00000000 00000000 ffffffff
    [  172.560058] 3fa0: 00000058 c04b2de0 00000000 00000000 fee1dead 28121969 01234567 00000000
    [  172.568634] 3fc0: 00000000 00000000 ffffffff 00000058 00000000 00000001 400aa000 bea9cf14
    [  172.577209] 3fe0: 000ea148 bea9c958 000aa750 40225728 60000010 fee1dead 00000000 00000000
    [  172.585784] [<c069bfdc>] (do_raw_spin_unlock+0x50/0xc0) from [<c085a7f8>] (_raw_spin_unlock_irqrestore+0x24/0x44)
    [  172.596588] [<c085a7f8>] (_raw_spin_unlock_irqrestore+0x24/0x44) from [<c0761ab4>] (musb_shutdown+0x44/0x88)
    [  172.606933] [<c0761ab4>] (musb_shutdown+0x44/0x88) from [<c06e2fd0>] (platform_drv_shutdown+0x14/0x18)
    [  172.616699] [<c06e2fd0>] (platform_drv_shutdown+0x14/0x18) from [<c06dea90>] (device_shutdown+0x74/0xb4)
    [  172.626647] [<c06dea90>] (device_shutdown+0x74/0xb4) from [<c04fccb4>] (kernel_restart_prepare+0x24/0x38)
    [  172.636688] [<c04fccb4>] (kernel_restart_prepare+0x24/0x38) from [<c04fcd04>] (kernel_restart+0xc/0x48)
    [  172.646545] [<c04fcd04>] (kernel_restart+0xc/0x48) from [<c04fce44>] (sys_reboot+0xfc/0x1d8)
    [  172.655426] [<c04fce44>] (sys_reboot+0xfc/0x1d8) from [<c04b2de0>] (ret_fast_syscall+0x0/0x3c)
    [  172.664459] Code: e3c3303f e594200c e593300c e1520003 (0a000002)
    [  172.670867] ------------[ cut here ]------------
    
    Signed-off-by: Hema HK <hemahk@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 630ae7f..f10ff00 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1030,6 +1030,7 @@ static void musb_shutdown(struct platform_device *pdev)
 	struct musb	*musb = dev_to_musb(&pdev->dev);
 	unsigned long	flags;
 
+	pm_runtime_get_sync(musb->controller);
 	spin_lock_irqsave(&musb->lock, flags);
 	musb_platform_disable(musb);
 	musb_generic_disable(musb);
@@ -1040,6 +1041,7 @@ static void musb_shutdown(struct platform_device *pdev)
 	musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
 	musb_platform_exit(musb);
 
+	pm_runtime_put(musb->controller);
 	/* FIXME power down */
 }
 

also attached for convenience.

-- 
balbi

[-- Attachment #2: 0001-usb-musb-Fix-for-merge-issue.diff --]
[-- Type: text/x-diff, Size: 1294 bytes --]

>From 84cebd52a4b5d590af476869dc5b786fe567c095 Mon Sep 17 00:00:00 2001
From: Hema HK <hemahk@ti.com>
Date: Thu, 17 Mar 2011 16:11:58 +0530
Subject: [PATCH] usb: musb: Fix for merge issue
Organization: Texas Instruments\n

There was conflict while merging 2 patches. Enabling vbus code
is wrongly moved to error check if loop.

This is a fix to resolve the merge issue.

Signed-off-by: Hema HK <hemahk@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 drivers/usb/musb/musb_gadget.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 419ca3e..9ecb057 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1880,12 +1880,12 @@ int usb_gadget_probe_driver(struct usb_gadget_driver *driver,
 		if (retval < 0) {
 			DBG(1, "add_hcd failed, %d\n", retval);
 			goto err2;
-
-			if ((musb->xceiv->last_event == USB_EVENT_ID)
-						&& musb->xceiv->set_vbus)
-				otg_set_vbus(musb->xceiv, 1);
 		}
 
+		if ((musb->xceiv->last_event == USB_EVENT_ID)
+					&& musb->xceiv->set_vbus)
+			otg_set_vbus(musb->xceiv, 1);
+
 		hcd->self.uses_pio_for_control = 1;
 
 		if (musb->xceiv->last_event == USB_EVENT_NONE)
-- 
1.7.4.1.343.ga91df


[-- Attachment #3: 0001-usb-musb-Fix-the-crash-issue-during-reboot.diff --]
[-- Type: text/x-diff, Size: 4814 bytes --]

>From ee262c660a855864efa78181cf7b7095b6416098 Mon Sep 17 00:00:00 2001
From: Hema HK <hemahk@ti.com>
Date: Tue, 22 Mar 2011 16:02:12 +0530
Subject: [PATCH] usb: musb: Fix the crash issue during reboot
Organization: Texas Instruments\n

Below crash observed with commit 7acc6197b76edd0b932a7cbcc6cfad0a8a87f026
(usb: musb: Idle path retention and offmode support for OMAP3)
during board reboot.

The musb clock was disabled when musb_shutdown() was called by
platform_drv_shutdown in which there are register accesses.
call pm_runtime_get_sync() and pm_runtime_put_sync() in the
musb_shutdown function.

/ # [  172.368774] Unhandled fault: imprecise external abort (0x1406) at 0x400f0000
[  172.376190] Internal error: : 1406 [#1] SMP
[  172.380554] last sysfs file: /sys/devices/platform/omap/omap_i2c.4/i2c-4/i2c-dev/i2c-4/dev
[  172.389221] Modules linked in:
[  172.392456] CPU: 0    Tainted: G        W    (2.6.38-06671-geddecbb #33)
[  172.399475] PC is at do_raw_spin_unlock+0x50/0xc0
[  172.404418] LR is at _raw_spin_unlock_irqrestore+0x24/0x44
[  172.410186] pc : [<c069bfdc>]    lr : [<c085a7f8>]    psr: 60000093
[  172.410186] sp : ee993e40  ip : c0d00240  fp : bea9cf14
[  172.422241] r10: 00000000  r9 : ee992000  r8 : c04b2fa8
[  172.427703] r7 : 00000000  r6 : c0fa46c0  r5 : ef966124  r4 : ef966124
[  172.434539] r3 : ef92cbc0  r2 : ef92cbc0  r1 : 00000000  r0 : ef966124
[  172.441406] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
[  172.448974] Control: 10c5387d  Table: ae8d804a  DAC: 00000015
[  172.454986] Process init (pid: 1094, stack limit = 0xee9922f8)
[  172.461120] Stack: (0xee993e40 to 0xee994000)
[  172.465667] 3e40: a0000013 c085a7f8 ef966124 a0000013 c0fa46c0 c0761ab4 c0761a70 ef95c008
[  172.474273] 3e60: ef95c014 c06e2fd0 c06e2fbc c06dea90 00000000 01234567 28121969 c04fccb4
[  172.482849] 3e80: 00000000 c04fcd04 c0a302bc c04fce44 c0a02600 00000001 00000000 c085cd04
[  172.491424] 3ea0: 00000000 00000002 c09ea000 c085afc0 ee993f24 00000000 00040001 00000445
[  172.499999] 3ec0: a8eb9d34 00000027 00000000 00000000 00000000 c0a56a4c 00000000 00000000
[  172.508575] 3ee0: 00000002 60000093 00000000 c0519aac 00000002 00000080 00000000 c0550420
[  172.517150] 3f00: 00000000 00000002 ee970000 c0a56a3c c0a56a20 00000002 c0a56a3c 00000000
[  172.525726] 3f20: c0a56a3c 0000000a c1580e00 c0a56a20 00000002 c0a56a3c c1580e00 c0a56a20
[  172.534301] 3f40: ef92cbc0 c05173a0 00000001 ef92cbc0 c0576190 c04e3174 20000013 c0517324
[  172.542877] 3f60: ef815c00 ee90b720 c04e3174 c0576190 00000001 ef92cbc0 c04b2f00 ffffffff
[  172.551483] 3f80: 00000058 c0517324 00000000 00000000 ffffffff 00000000 00000000 ffffffff
[  172.560058] 3fa0: 00000058 c04b2de0 00000000 00000000 fee1dead 28121969 01234567 00000000
[  172.568634] 3fc0: 00000000 00000000 ffffffff 00000058 00000000 00000001 400aa000 bea9cf14
[  172.577209] 3fe0: 000ea148 bea9c958 000aa750 40225728 60000010 fee1dead 00000000 00000000
[  172.585784] [<c069bfdc>] (do_raw_spin_unlock+0x50/0xc0) from [<c085a7f8>] (_raw_spin_unlock_irqrestore+0x24/0x44)
[  172.596588] [<c085a7f8>] (_raw_spin_unlock_irqrestore+0x24/0x44) from [<c0761ab4>] (musb_shutdown+0x44/0x88)
[  172.606933] [<c0761ab4>] (musb_shutdown+0x44/0x88) from [<c06e2fd0>] (platform_drv_shutdown+0x14/0x18)
[  172.616699] [<c06e2fd0>] (platform_drv_shutdown+0x14/0x18) from [<c06dea90>] (device_shutdown+0x74/0xb4)
[  172.626647] [<c06dea90>] (device_shutdown+0x74/0xb4) from [<c04fccb4>] (kernel_restart_prepare+0x24/0x38)
[  172.636688] [<c04fccb4>] (kernel_restart_prepare+0x24/0x38) from [<c04fcd04>] (kernel_restart+0xc/0x48)
[  172.646545] [<c04fcd04>] (kernel_restart+0xc/0x48) from [<c04fce44>] (sys_reboot+0xfc/0x1d8)
[  172.655426] [<c04fce44>] (sys_reboot+0xfc/0x1d8) from [<c04b2de0>] (ret_fast_syscall+0x0/0x3c)
[  172.664459] Code: e3c3303f e594200c e593300c e1520003 (0a000002)
[  172.670867] ------------[ cut here ]------------

Signed-off-by: Hema HK <hemahk@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 drivers/usb/musb/musb_core.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 630ae7f..f10ff00 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1030,6 +1030,7 @@ static void musb_shutdown(struct platform_device *pdev)
 	struct musb	*musb = dev_to_musb(&pdev->dev);
 	unsigned long	flags;
 
+	pm_runtime_get_sync(musb->controller);
 	spin_lock_irqsave(&musb->lock, flags);
 	musb_platform_disable(musb);
 	musb_generic_disable(musb);
@@ -1040,6 +1041,7 @@ static void musb_shutdown(struct platform_device *pdev)
 	musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
 	musb_platform_exit(musb);
 
+	pm_runtime_put(musb->controller);
 	/* FIXME power down */
 }
 
-- 
1.7.4.1.343.ga91df

Re: What is missing from musb - linux-omap merge?

[Jarkko Nikula]

On Wed, 6 Apr 2011 16:34:40 +0300
Felipe Balbi <balbi@ti.com> wrote:

> Hi,
> 
> On Wed, Apr 06, 2011 at 04:23:34PM +0300, Jarkko Nikula wrote:
> > Hi
> > 
> > I've been trying to hunt why the OMAP3 retention on Nokia N900 went
> > broken in 2.6.39-rc and reason is somewhere around musb code merge with
> > linux-omap code or vise versa.
> > 
> > I bisected this into:
> 
> I guess it's the missing Hema's patch which should be queued already.
> Here it is:
> 
> commit 84cebd52a4b5d590af476869dc5b786fe567c095
> Author: Hema HK <hemahk@ti.com>
> Date:   Thu Mar 17 16:11:58 2011 +0530
> 
>     usb: musb: Fix for merge issue
>     
Yeah, that was missing from the commits I was testing but it was in
where I started bisecting and where I noticed the retention issue so
this don't fix it.

> you might also need the one below:
> 
> commit ee262c660a855864efa78181cf7b7095b6416098
> Author: Hema HK <hemahk@ti.com>
> Date:   Tue Mar 22 16:02:12 2011 +0530
> 
>     usb: musb: Fix the crash issue during reboot
>     
Applies fine to 2.6.39-rc2 but still doesn't fix the retention issue.

-- 
Jarkko

Re: What is missing from musb - linux-omap merge?

[Kevin Hilman]

Jarkko Nikula <jhnikula@gmail.com> writes:

> On Wed, 6 Apr 2011 16:34:40 +0300
> Felipe Balbi <balbi@ti.com> wrote:
>
>> Hi,
>> 
>> On Wed, Apr 06, 2011 at 04:23:34PM +0300, Jarkko Nikula wrote:
>> > Hi
>> > 
>> > I've been trying to hunt why the OMAP3 retention on Nokia N900 went
>> > broken in 2.6.39-rc and reason is somewhere around musb code merge with
>> > linux-omap code or vise versa.
>> > 
>> > I bisected this into:
>> 
>> I guess it's the missing Hema's patch which should be queued already.
>> Here it is:
>> 
>> commit 84cebd52a4b5d590af476869dc5b786fe567c095
>> Author: Hema HK <hemahk@ti.com>
>> Date:   Thu Mar 17 16:11:58 2011 +0530
>> 
>>     usb: musb: Fix for merge issue
>>     
> Yeah, that was missing from the commits I was testing but it was in
> where I started bisecting and where I noticed the retention issue so
> this don't fix it.
>
>> you might also need the one below:
>> 
>> commit ee262c660a855864efa78181cf7b7095b6416098
>> Author: Hema HK <hemahk@ti.com>
>> Date:   Tue Mar 22 16:02:12 2011 +0530
>> 
>>     usb: musb: Fix the crash issue during reboot
>>     
> Applies fine to 2.6.39-rc2 but still doesn't fix the retention issue.

Without actually trying this myself, what is likely affecting retention
is probably a missing (or failed) reset of the MUSB module.

Retention was also broken on several platforms before the MUSB cleanup &
hwmod conversion because the reset happens during hwmod init.  Because
most bootloaders are using MUSB, they often leave it in a state that
prevents idle (and thus retention), so a hwmod reset is the most
reliable way go get the IP into a known state.

Kevin

RE: What is missing from musb - linux-omap merge?

[Hema Kalliguddi]

[-- Attachment #1: Type: text/plain, Size: 5757 bytes --]

Hi,

>-----Original Message-----
>From: Jarkko Nikula [mailto:jhnikula@gmail.com]
>Sent: Wednesday, April 06, 2011 6:54 PM
>To: OMAP Linux discussion
>Cc: Felipe Balbi; Hema HK
>Subject: What is missing from musb - linux-omap merge?
>
>Hi
>
>I've been trying to hunt why the OMAP3 retention on Nokia N900 went
>broken in 2.6.39-rc and reason is somewhere around musb code merge with
>linux-omap code or vise versa.
>
I tried the core retention with v2.6.39-rc1 with OMAP3630Zoom3 board
and don't observe any issues. Core is transitioning to retention without
any issue,
with or without musb driver loaded.

But on OMAP3430SDP I am observing the crash when try to do
echo mem > /sys/power/state.

Attached is the fix for this issue and core transitions to retention.

When you say retention is not working can you please carify what is
happening?
are you trying in idle path retention or suspend/resume?

Regards,
Hema

>I bisected this into:
>
>commit 0df0914d414a504b975f3cc66ace0c16ef55b7f3
>Merge: 6899608 05f6894
>Author: Linus Torvalds <torvalds@linux-foundation.org>
>Date:   Thu Mar 17 19:28:15 2011 -0700
>
>    Merge branch 'omap-for-linus' of
>git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6
>
>Yep, there were conflicts resolved by Linus but those didn't look that
>they explain the problem.
>
>So then I went to check the linux-omap branch omap-for-linus that got
>pulled to vanilla. Top commit was:
>
>commit 05f689400ea5fa3d71af82f910c8b140f87ad1f3
>Merge: 17fe12c 02b7b94
>Author: Tony Lindgren <tony@atomide.com>
>Date:   Mon Mar 14 11:22:22 2011 -0700
>
>    Merge branches 'devel-mux' and 'devel-misc' into omap-for-linus
>
>Here retention and usb networking are working so all were fine in
>linux-omap in 2.6.38-rc7.
>
>Then back to vanilla and checking the usb pull.
>
>commit 971f115a50afbe409825c9f3399d5a3b9aca4381
>Merge: 2e270d8 500132a
>Author: Linus Torvalds <torvalds@linux-foundation.org>
>Date:   Wed Mar 16 15:04:26 2011 -0700
>
>    Merge branch 'usb-next' of
>git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6
>
>Yes, musb doesn't compile here... trivial build fix attached as it's
>not our interest now (but will bother all bisecters). Here retention
>works but usb networking doesn't.
>
>Then I went testing patches from linux-omap/omap-for-linus on top of
>vanilla commit that precedes the omap-for-linus pull:
>
>commit 6899608533410557e6698cb9d4ff6df553916e98
>Merge: 411f5c7 92c260f
>Author: Linus Torvalds <torvalds@linux-foundation.org>
>Date:   Thu Mar 17 19:13:18 2011 -0700
>
>    Merge branch 'for-linus' of
>git://codeaurora.org/quic/kernel/davidb/linux-ms
>
>Some amount of conflict resolving, mostly trivial, some testing and
>came around these commits (note local commit ids):
>
>commit 5cd15f0ba7594e4cd1dd01a100dc94013930a6a9
>Author: Hema HK <hemahk@ti.com>
>Date:   Thu Feb 17 12:07:17 2011 +0530
>
>    OMAP2430: hwmod data: Add USBOTG
>
>-> Retention ok
>
>commit 2d982bb2593ab64151c4a01758735e67d7db5d36
>Author: Hema HK <hemahk@ti.com>
>Date:   Thu Feb 17 12:07:18 2011 +0530
>
>    OMAP3xxx: hwmod data: Add USBOTG
>
>commit 6dc0c8ee8bdaac3ad11c4313431d8d7b3c886ede
>Author: Hema HK <hemahk@ti.com>
>Date:   Thu Feb 17 12:07:19 2011 +0530
>
>    AM35xx: hwmod data: Add USBOTG
>
>-> These don't boot
>
>commit 4bd3924ed10bef872e1fbfbb590fb7132df7dd4c
>Author: Hema HK <hemahk@ti.com>
>Date:   Thu Feb 17 12:07:21 2011 +0530
>
>    OMAP2+: musb: hwmod adaptation for musb registration
>
>-> Boots, usb networking works and but no retention
>
>
>Then arch/arm/mach-omap2 diff between
>
>vanilla 0df0914d414a504b975f3cc66ace0c16ef55b7f3 (l-o pull)
>and
>l-o 05f689400ea5fa3d71af82f910c8b140f87ad1f3 (for linus)
>
>doesn't show any suspicious to me. E.g. no differences in
>omap_hwmod_3xxx_data.c and clock3xxx_data.c changes are just those
>clock name changes that Linus complained. Rest seems to be unrelated.
>
> Kconfig                        |    1
> Makefile                       |    2
> board-3430sdp.c                |   10
> board-3630sdp.c                |   10
> board-4430sdp.c                |    1
> board-am3517crane.c            |   10
> board-am3517evm.c              |   12
> board-cm-t35.c                 |   10
> board-cm-t3517.c               |   10
> board-devkit8000.c             |   10
> board-igep0020.c               |   10
> board-igep0030.c               |   10
> board-omap3beagle.c            |   10
> board-omap3evm.c               |   14 -
> board-omap3pandora.c           |   10
> board-omap3stalker.c           |   10
> board-omap3touchbook.c         |   10
> board-omap4panda.c             |   11
> board-overo.c                  |   10
> board-zoom.c                   |   10
> clock3xxx_data.c               |   19 +
> clock44xx_data.c               |   10
> include/mach/board-zoom.h.orig |   11
> include/mach/debug-macro.S     |   13
> omap4-common.c                 |    7
> omap_phy_internal.c            |   29 +-
> pm.h                           |    2
> sleep24xx.S                    |    2
> sleep34xx.S                    |    2
> sram242x.S                     |    3
> sram243x.S                     |    3
> sram34xx.S                     |    1
> usb-ehci.c                     |  522
>-------------------------------------
> usb-host.c                     |  574
>+++++++++++++++++++++++++++++++++++++++++
> usb-musb.c                     |    3
> 35 files changed, 737 insertions(+), 645 deletions(-)
>
>These findings made me thinking are there some patch or patchset
>missing for musb as there are these musb build breakages and usb
>networking not working in mainline issues, retention breaks only when
>applying patches from linux-omap/omap-for-linus but what are ok in
>linux-omap 2.6.38-rc7?
>
>--
>Jarkko
>

[-- Attachment #2: suspend-3430.patch --]
[-- Type: application/octet-stream, Size: 808 bytes --]

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 630ae7f..2af45f0 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2367,7 +2367,8 @@ static int musb_suspend(struct device *dev)
 		 */
 	}
 
-	musb_save_context(musb);
+	if (!pm_runtime_suspended(dev))
+		musb_save_context(musb);
 
 	spin_unlock_irqrestore(&musb->lock, flags);
 	return 0;
@@ -2378,7 +2379,8 @@ static int musb_resume_noirq(struct device *dev)
 	struct platform_device *pdev = to_platform_device(dev);
 	struct musb	*musb = dev_to_musb(&pdev->dev);
 
-	musb_restore_context(musb);
+	if (!pm_runtime_suspended(dev))
+		musb_restore_context(musb);
 
 	/* for static cmos like DaVinci, register values were preserved
 	 * unless for some reason the whole soc powered down or the USB

Re: What is missing from musb - linux-omap merge?

[Jarkko Nikula]

Hi

On Thu, 7 Apr 2011 14:38:06 +0530
Hema Kalliguddi <hemahk@ti.com> wrote:

> I tried the core retention with v2.6.39-rc1 with OMAP3630Zoom3 board
> and don't observe any issues. Core is transitioning to retention without
> any issue,
> with or without musb driver loaded.
> 
> But on OMAP3430SDP I am observing the crash when try to do
> echo mem > /sys/power/state.
> 
> Attached is the fix for this issue and core transitions to retention.
> 
Hmm.. suspend/resume are fine on Nokia N900 with and without the patch.
Patch also didn't fix the idle retention.

> When you say retention is not working can you please carify what is
> happening?
> are you trying in idle path retention or suspend/resume?
> 
Sorry not being verbose enough, I was testing the idle retention.

For me it looks these differencies are explained by different
bootloaders. As Kevin told they may leave MUSB in a wrong state. Was it
so that before hwmod conversion the musb did IP reset etc and now this
feature is missing? So I'm thinking is this problem a regression or
missing feature after hwmod conversion?

-- 
Jarkko

Re: What is missing from musb - linux-omap merge?

[Felipe Balbi]

On Thu, Apr 07, 2011 at 01:34:52PM +0300, Jarkko Nikula wrote:
> Hi
> 
> On Thu, 7 Apr 2011 14:38:06 +0530
> Hema Kalliguddi <hemahk@ti.com> wrote:
> 
> > I tried the core retention with v2.6.39-rc1 with OMAP3630Zoom3 board
> > and don't observe any issues. Core is transitioning to retention without
> > any issue,
> > with or without musb driver loaded.
> > 
> > But on OMAP3430SDP I am observing the crash when try to do
> > echo mem > /sys/power/state.
> > 
> > Attached is the fix for this issue and core transitions to retention.
> > 
> Hmm.. suspend/resume are fine on Nokia N900 with and without the patch.
> Patch also didn't fix the idle retention.
> 
> > When you say retention is not working can you please carify what is
> > happening?
> > are you trying in idle path retention or suspend/resume?
> > 
> Sorry not being verbose enough, I was testing the idle retention.
> 
> For me it looks these differencies are explained by different
> bootloaders. As Kevin told they may leave MUSB in a wrong state. Was it
> so that before hwmod conversion the musb did IP reset etc and now this
> feature is missing? So I'm thinking is this problem a regression or
> missing feature after hwmod conversion?

it's possibly a regression. I remember we had softreset before. Should
be fixed.

-- 
balbi

RE: What is missing from musb - linux-omap merge?

[Hema Kalliguddi]

>-----Original Message-----
>From: Felipe Balbi [mailto:balbi@ti.com]
>Sent: Thursday, April 07, 2011 5:08 PM
>To: Jarkko Nikula
>Cc: Hema Kalliguddi; OMAP Linux discussion; Felipe Balbi
>Subject: Re: What is missing from musb - linux-omap merge?
>
>On Thu, Apr 07, 2011 at 01:34:52PM +0300, Jarkko Nikula wrote:
>> Hi
>>
>> On Thu, 7 Apr 2011 14:38:06 +0530
>> Hema Kalliguddi <hemahk@ti.com> wrote:
>>
>> > I tried the core retention with v2.6.39-rc1 with
>OMAP3630Zoom3 board
>> > and don't observe any issues. Core is transitioning to
>retention without
>> > any issue,
>> > with or without musb driver loaded.
>> >
>> > But on OMAP3430SDP I am observing the crash when try to do
>> > echo mem > /sys/power/state.
>> >
>> > Attached is the fix for this issue and core transitions to
>retention.
>> >
>> Hmm.. suspend/resume are fine on Nokia N900 with and without
>the patch.
>> Patch also didn't fix the idle retention.
>>
>> > When you say retention is not working can you please carify what is
>> > happening?
>> > are you trying in idle path retention or suspend/resume?
>> >
>> Sorry not being verbose enough, I was testing the idle retention.
>>
>> For me it looks these differencies are explained by different
>> bootloaders. As Kevin told they may leave MUSB in a wrong
>state. Was it
>> so that before hwmod conversion the musb did IP reset etc
>and now this
>> feature is missing? So I'm thinking is this problem a regression or
>> missing feature after hwmod conversion?
>
Hwmod will take care of restting the ip if the SYSC_HAS_SOFTRESET
sysc_flag
is set. And it is being set in the hwmod structure of OMAP3.

I tested both idle path and suspend/resume retention and works fine
on OMAP3430SDP.
I am wondering what might be the problem with N900. Is it works if you do
the
ip reset in the musb driver?

Regards,
Hema

>it's possibly a regression. I remember we had softreset before. Should
>be fixed.
>
>--
>balbi
>

RE: What is missing from musb - linux-omap merge?

[Hema Kalliguddi]

Hi,

>-----Original Message-----
>From: Hema Kalliguddi [mailto:hemahk@ti.com]
>Sent: Thursday, April 07, 2011 6:29 PM
>To: balbi@ti.com; Jarkko Nikula
>Cc: OMAP Linux discussion
>Subject: RE: What is missing from musb - linux-omap merge?
>
>>-----Original Message-----
>>From: Felipe Balbi [mailto:balbi@ti.com]
>>Sent: Thursday, April 07, 2011 5:08 PM
>>To: Jarkko Nikula
>>Cc: Hema Kalliguddi; OMAP Linux discussion; Felipe Balbi
>>Subject: Re: What is missing from musb - linux-omap merge?
>>
>>On Thu, Apr 07, 2011 at 01:34:52PM +0300, Jarkko Nikula wrote:
>>> Hi
>>>
>>> On Thu, 7 Apr 2011 14:38:06 +0530
>>> Hema Kalliguddi <hemahk@ti.com> wrote:
>>>
>>> > I tried the core retention with v2.6.39-rc1 with
>>OMAP3630Zoom3 board
>>> > and don't observe any issues. Core is transitioning to
>>retention without
>>> > any issue,
>>> > with or without musb driver loaded.
>>> >
>>> > But on OMAP3430SDP I am observing the crash when try to do
>>> > echo mem > /sys/power/state.
>>> >
>>> > Attached is the fix for this issue and core transitions to
>>retention.
>>> >
>>> Hmm.. suspend/resume are fine on Nokia N900 with and without
>>the patch.
>>> Patch also didn't fix the idle retention.
>>>
>>> > When you say retention is not working can you please
>carify what is
>>> > happening?
>>> > are you trying in idle path retention or suspend/resume?
>>> >
>>> Sorry not being verbose enough, I was testing the idle retention.
>>>
>>> For me it looks these differencies are explained by different
>>> bootloaders. As Kevin told they may leave MUSB in a wrong
>>state. Was it
>>> so that before hwmod conversion the musb did IP reset etc
>>and now this
>>> feature is missing? So I'm thinking is this problem a regression or
>>> missing feature after hwmod conversion?
>>
>Hwmod will take care of restting the ip if the SYSC_HAS_SOFTRESET
>sysc_flag
>is set. And it is being set in the hwmod structure of OMAP3.
>
>I tested both idle path and suspend/resume retention and works fine
>on OMAP3430SDP.

Tested with OMAP3630Zoom3 board not with 3430SDP.

>I am wondering what might be the problem with N900. Is it
>works if you do
>the
>ip reset in the musb driver?
>
>Regards,
>Hema
>
>>it's possibly a regression. I remember we had softreset before. Should
>>be fixed.
>>
>>--
>>balbi
>>
>