Skip to contentSkip to conversation

resend of pending TWL patches

PATCH In review David Brownell 7 participants 11 messages Oct 3, 2008 – Oct 12, 2008 1 message not in the archive

lore
Share & tools
lore

David Brownell

author
#0 lore raw

cover resend of pending TWL patches

This flushes my queue of TWL (and related) patches that seem ready to merge:

- remove extra headers from RTC driver
- remove RTC header
- remove pwrirq header
- core cleanups
- gpiolib to_irq() feature
- implement to_irq() for OMAP gpios
- ... and for TWL gpios

At that point the twl4030-core code will be ready to enter the MFD queue IMO ... there've not been many review comments other than mine (which were mostly addressed in the "core cleanups" patch above).

The main open issues with respect to the TWL core seem to relate to IRQ handling. I've had a bright idea that I think will solve a bunch of issues at once, but that can/should go separately. And then there will still be the issue of genirq support for threaded IRQs -- which isn't quite available yet.

(One observation is that we should prefer to get drivers in mainline even if they're not yet fully cooked ... and mainline is happy with that model. In this case we'll have cleaned up lots of ragged edges, but not yet many of the IRQ bits.)

- Dave

author
#1 lore raw
Quoted 2 lines · David Brownell

This flushes my queue of TWL (and related) patches that seem ready to merge:

Sanity tested on Beagle, FYI.

Where I observed a new oddity: the boot hung right after listing the MTD partitions. Which is where the EHCI code would come up ... took that driver out of the build, and the hang went away. Clue, oh clue; where art thou?

- Dave

A message that is not in the archive (sent off-list or not yet received): [email protected]

#3 lore raw

(Hit reply instead of reply-all... Reminder to self. Never send emails when you're sleepy)

Quoted 42 lines · Anand Gadiyar
Quoted 11 lines · David Brownell
Quoted 2 lines · David Brownell

This flushes my queue of TWL (and related) patches that seem ready to merge:

Sanity tested on Beagle, FYI.

Where I observed a new oddity: the boot hung right after listing the MTD partitions. Which is where the EHCI code would come up ... took that driver out of the build, and the hang went away. Clue, oh clue; where art thou?

Well... Any chance this bit of code here helps? This infinite loop shouldn't even have been here. Oh well.

====CUT_HERE=====
Remove infinite loop in DPLL 5 programming. Ideally, DPLL5 should be taken care of by the clock framework.

---
 drivers/usb/host/ehci-omap.c |    2 ++
 1 files changed, 2 insertions(+)

Index: linux-omap-2.6/drivers/usb/host/ehci-omap.c
===================================================================
--- linux-omap-2.6.orig/drivers/usb/host/ehci-omap.c 2008-09-18
14:59:34.000000000 +0530
+++ linux-omap-2.6/drivers/usb/host/ehci-omap.c 2008-09-18 15:00:09.737475758 +0530

(quoted diff) +2 -0
@@ -170,10 +170,12 @@ static int omap_start_ehc(struct platfor
                       (7 << OMAP3430ES2_EN_PERIPH2_DPLL_SHIFT),
                       PLL_MOD, OMAP3430ES2_CM_CLKEN2);
 
+#if 0
       while (!(cm_read_mod_reg(PLL_MOD, CM_IDLEST2) &
                               OMAP3430ES2_ST_PERIPH2_CLK_MASK))
               dev_dbg(hcd->self.controller, "idlest2 = 0x%x\n",
                       cm_read_mod_reg(PLL_MOD, CM_IDLEST2));
+#endif
       /* End DPLL5 programming */
#4 lore raw

On Friday 03 of October 2008 19:38:51 Anand Gadiyar wrote:
That's nothing new in David's case ;-) (dont consider this an insult)

Quoted 5 lines

(Hit reply instead of reply-all... Reminder to self. Never send emails when you're sleepy)

Quoted 1 line · Anand Gadiyar

On Fri, Oct 3, 2008 at 10:12 PM, David Brownell <[email protected]>

Quoted 44 lines · wrote:
Quoted 29 lines
Quoted 10 lines · David Brownell
Quoted 2 lines

This flushes my queue of TWL (and related) patches that seem ready to merge:

Sanity tested on Beagle, FYI.

Where I observed a new oddity: the boot hung right after listing the MTD partitions. Which is where the EHCI code would come up ... took that driver out of the build, and the hang went away. Clue, oh clue; where art thou?

Well... Any chance this bit of code here helps? This infinite loop shouldn't even have been here. Oh well.

====CUT_HERE=====
Remove infinite loop in DPLL 5 programming. Ideally, DPLL5 should be taken care of by the clock framework.

---
 drivers/usb/host/ehci-omap.c |    2 ++
 1 files changed, 2 insertions(+)

Index: linux-omap-2.6/drivers/usb/host/ehci-omap.c
===================================================================
--- linux-omap-2.6.orig/drivers/usb/host/ehci-omap.c 2008-09-18
14:59:34.000000000 +0530
+++ linux-omap-2.6/drivers/usb/host/ehci-omap.c 2008-09-18 15:00:09.737475758 +0530

Review static int omap_start_ehc(struct platfor · line 179

Quoted 10 lines
(quoted diff) +2 -0
@@ -170,10 +170,12 @@ static int omap_start_ehc(struct platfor
                       (7 << OMAP3430ES2_EN_PERIPH2_DPLL_SHIFT),
                       PLL_MOD, OMAP3430ES2_CM_CLKEN2);
 
+#if 0
       while (!(cm_read_mod_reg(PLL_MOD, CM_IDLEST2) &
                               OMAP3430ES2_ST_PERIPH2_CLK_MASK))
               dev_dbg(hcd->self.controller, "idlest2 = 0x%x\n",
                       cm_read_mod_reg(PLL_MOD, CM_IDLEST2));
+#endif
       /* End DPLL5 programming */

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#5 lore raw
Quoted 14 lines · Marek Vasut

On Friday 03 of October 2008 19:38:51 Anand Gadiyar wrote:
That's nothing new in David's case ;-) (dont consider this an insult)

Quoted 5 lines

(Hit reply instead of reply-all... Reminder to self. Never send emails when you're sleepy)

Quoted 1 line · Anand Gadiyar

On Fri, Oct 3, 2008 at 10:12 PM, David Brownell <[email protected]>

Quoted 5 lines · wrote:
Quoted 5 lines
Quoted 5 lines · David Brownell
Quoted 2 lines

This flushes my queue of TWL (and related) patches that seem ready to merge:

Sanity tested on Beagle, FYI.

Pushed all seven patches to l-o.

Tony

Quoted 45 lines
Quoted 27 lines
Quoted 27 lines
Quoted 5 lines

Where I observed a new oddity: the boot hung right after listing the MTD partitions. Which is where the EHCI code would come up ... took that driver out of the build, and the hang went away. Clue, oh clue; where art thou?

Well... Any chance this bit of code here helps? This infinite loop shouldn't even have been here. Oh well.

====CUT_HERE=====
Remove infinite loop in DPLL 5 programming. Ideally, DPLL5 should be taken care of by the clock framework.

---
 drivers/usb/host/ehci-omap.c |    2 ++
 1 files changed, 2 insertions(+)

Index: linux-omap-2.6/drivers/usb/host/ehci-omap.c
===================================================================
--- linux-omap-2.6.orig/drivers/usb/host/ehci-omap.c 2008-09-18
14:59:34.000000000 +0530
+++ linux-omap-2.6/drivers/usb/host/ehci-omap.c 2008-09-18 15:00:09.737475758 +0530

(quoted diff) +0 -0
@@ -170,10 +170,12 @@ static int omap_start_ehc(struct platfor
                       (7 << OMAP3430ES2_EN_PERIPH2_DPLL_SHIFT),
                       PLL_MOD, OMAP3430ES2_CM_CLKEN2);
Quoted 12 lines

Review static int omap_start_ehc(struct platfor · line 179

Quoted 7 lines
(quoted diff) +2 -0
+#if 0
       while (!(cm_read_mod_reg(PLL_MOD, CM_IDLEST2) &
                               OMAP3430ES2_ST_PERIPH2_CLK_MASK))
               dev_dbg(hcd->self.controller, "idlest2 = 0x%x\n",
                       cm_read_mod_reg(PLL_MOD, CM_IDLEST2));
+#endif
       /* End DPLL5 programming */

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#6 lore raw
In reply to Anand Gadiyar
Quoted 8 lines
Quoted 8 lines
Quoted 5 lines

Where I observed a new oddity: the boot hung right after listing the MTD partitions. Which is where the EHCI code would come up ... took that driver out of the build, and the hang went away. Clue, oh clue; where art thou?

Well... Any chance this bit of code here helps? This infinite loop shouldn't even have been here. Oh well.

Didn't help. :(

This code has so many infinite loops for hardware handshaking (none with timeouts!) that it's hard to say which one might be causing this ... if indeed one of them is indeed the cause.

Quoted 27 lines
Quoted 25 lines

====CUT_HERE=====
Remove infinite loop in DPLL 5 programming. Ideally, DPLL5 should be taken care of by the clock framework.

---
 drivers/usb/host/ehci-omap.c |    2 ++
 1 files changed, 2 insertions(+)

Index: linux-omap-2.6/drivers/usb/host/ehci-omap.c
===================================================================
--- linux-omap-2.6.orig/drivers/usb/host/ehci-omap.c 2008-09-18
14:59:34.000000000 +0530
+++ linux-omap-2.6/drivers/usb/host/ehci-omap.c 2008-09-18 15:00:09.737475758 +0530

(quoted diff) +2 -0
@@ -170,10 +170,12 @@ static int omap_start_ehc(struct platfor
                       (7 << OMAP3430ES2_EN_PERIPH2_DPLL_SHIFT),
                       PLL_MOD, OMAP3430ES2_CM_CLKEN2);
 
+#if 0
       while (!(cm_read_mod_reg(PLL_MOD, CM_IDLEST2) &
                               OMAP3430ES2_ST_PERIPH2_CLK_MASK))
               dev_dbg(hcd->self.controller, "idlest2 = 0x%x\n",
                       cm_read_mod_reg(PLL_MOD, CM_IDLEST2));
+#endif
       /* End DPLL5 programming */
#7 lore raw
Quoted 6 lines · David Brownell
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines

Where I observed a new oddity: the boot hung right after listing the MTD partitions. Which is where the EHCI code would come up ... took that driver out of the build, and the hang went away. Clue, oh clue; where art thou?

Quoted 8 lines
Quoted 2 lines
Quoted 2 lines

Well... Any chance this bit of code here helps? This infinite loop shouldn't even have been here. Oh well.

Didn't help. :(

This code has so many infinite loops for hardware handshaking (none with timeouts!) that it's hard to say which one might be causing this ... if indeed one of them is indeed the cause.

I put timeouts in all of the infinite loops to see which one was the culprit.

Turns out it is this one in omap_start_ehc:

	/* Wait for TLL to be Active */
	while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3) &
		(1 << OMAP3430ES2_ST_USBTLL_SHIFT)));

If I allow it fall out of the loop after 100000 tries, I get:

Unhandled fault: external abort on non-linefetch (0x1028) at 0xd8062014

Internal error: : 1028 [#1]
Modules linked in:
CPU: 0    Not tainted  (2.6.27-omap1 #1)
PC is at ehci_hcd_omap_drv_probe+0x2c4/0x538
LR is at release_console_sem+0x188/0x19c
pc : [<c02dae78>]    lr : [<c010f060>]    psr: 80000013

sp : c781fe20 ip : c781fd50 fp : c781fe44
r10: c04f8c90 r9 : 00000000 r8 : c797ae20
r7 : 00000011 r6 : c797ac00 r5 : c04f8d24 r4 : 000186a1 r3 : d8062000 r2 : 00000002 r1 : 00000001 r0 : 0000000f
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 00c5387f Table: 80004018 DAC: 00000017 Process swapper (pid: 1, stack limit = 0xc781e2e8)

Stack: (0xc781fe20 to 0xc7820000)

fe20: c04f8c98 c04f8d44 c050e710 c050e710 c050af80 c001e534 c781fe54 c781fe48
fe40: c0277298 c02dabc0 c781fe74 c781fe58 c0276530 c0277284 c04f8c98 c04f8d44
fe60: c050e710 c050e710 c781fe94 c781fe78 c0276628 c027646c 00000000 c781fe9c
fe80: c02765dc c050e710 c781fec4 c781fe98 c0275ba8 c02765e8 c051baa0 c7803c58
fea0: c7803c58 c04f8ce0 00000000 c050e710 c051baa0 c7b88a20 c781fed4 c781fec8
fec0: c0276378 c0275b68 c781ff04 c781fed8 c0276034 c0276364 c048fbbd c050e710
fee0: c051baa0 c05419c4 c050e710 c051baa0 00000000 00000000 c781ff2c c781ff08
ff00: c027681c c0275f98 c05419c4 c0026cf8 c051baa0 00000000 00000000 c001e534
ff20: c781ff3c c781ff30 c0277630 c0276790 c781ff5c c781ff40 c001e590 c02775c4
ff40: 000000a0 00000060 c0026fcc c0026cf8 c781ffdc c781ff60 c00ee298 c001e540
ff60: 0000015f c0533398 c781ff94 c781ff78 c0195800 c0195670 c781ff94 c7840260
ff80: c01959f8 c781ff9e c781ffc4 c781ff98 c0136844 c0195888 c781ffb4 35332618
ffa0: 00000031 00000000 00000192 c0026cf8 00000000 c0026fcc c0026cf8 00000000
ffc0: 00000000 00000000 00000000 00000000 c781fff4 c781ffe0 c0008734 c00ee254
ffe0: 00000000 00000000 00000000 c781fff8 c0111220 c00086d0 0084f950 492af4c0

Backtrace:
[<c02dabb4>] (ehci_hcd_omap_drv_probe+0x0/0x538) from [<c0277298>]
(platform_drv_probe+0x20/0x24)
[<c0277278>] (platform_drv_probe+0x0/0x24) from [<c0276530>]
(driver_probe_device+0xd0/0x17c)
[<c0276460>] (driver_probe_device+0x0/0x17c) from [<c0276628>]
(__driver_attach+0x4c/0x70)
 r7:c050e710 r6:c050e710 r5:c04f8d44 r4:c04f8c98
[<c02765dc>] (__driver_attach+0x0/0x70) from [<c0275ba8>]
(bus_for_each_dev+0x4c/0x84)
 r7:c050e710 r6:c02765dc r5:c781fe9c r4:00000000
[<c0275b5c>] (bus_for_each_dev+0x0/0x84) from [<c0276378>]
(driver_attach+0x20/0x28)
 r7:c7b88a20 r6:c051baa0 r5:c050e710 r4:00000000
[<c0276358>] (driver_attach+0x0/0x28) from [<c0276034>]
(bus_add_driver+0xa8/0x214)
[<c0275f8c>] (bus_add_driver+0x0/0x214) from [<c027681c>]
(driver_register+0x98/0x120)
 r8:00000000 r7:00000000 r6:c051baa0 r5:c050e710 r4:c05419c4
[<c0276784>] (driver_register+0x0/0x120) from [<c0277630>]
(platform_driver_register+0x78/0x94)
[<c02775b8>] (platform_driver_register+0x0/0x94) from [<c001e590>]
(ehci_hcd_init+0x5c/0x94)
[<c001e534>] (ehci_hcd_init+0x0/0x94) from [<c00ee298>]
(__exception_text_end+0x50/0x168)
 r5:c0026cf8 r4:c0026fcc
[<c00ee248>] (__exception_text_end+0x0/0x168) from [<c0008734>]
(kernel_init+0x70/0xdc)
[<c00086c4>] (kernel_init+0x0/0xdc) from [<c0111220>] (do_exit+0x0/0x6c0)
 r5:00000000 r4:00000000
Code: e30033e9 e1510003 0a000005 e59f3248 (e5933014)
---[ end trace 596e1d827138a4cc ]---
Kernel panic - not syncing: Attempted to kill init!

I'll keep digging, but I know next to nothing about the USB stack. Perhaps this info will trigger an "ah ha" for someone with more knowledge.

Steve

author
#8 lore raw
Quoted 7 lines · Steve Sakoman

I put timeouts in all of the infinite loops to see which one was the culprit.

Turns out it is this one in omap_start_ehc:

        /* Wait for TLL to be Active */
        while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3) & (1 << OMAP3430ES2_ST_USBTLL_SHIFT)));

Fishy ... TLL == TransceiverLess Link, which is used with on-board links that don't need to be morphed to use signals that go over cables as defined in the USB spec. I would think you'd want ULPI.

- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#9 lore raw
Quoted 5 lines

[email protected]] On Behalf Of David Brownell

Quoted 2 lines

Turns out it is this one in omap_start_ehc:

Quoted 8 lines
Quoted 3 lines

        /* Wait for TLL to be Active */
        while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3) & (1 << OMAP3430ES2_ST_USBTLL_SHIFT)));

Fishy ... TLL == TransceiverLess Link, which is used with on-board links that don't need to be morphed to use signals that go over cables as defined in the USB spec. I would think you'd want ULPI.

TLL block does get used for some cases for non-tll (phy) mode use. Recently there was some low power fixes for non-tll mode in which tll block handling was important. This was specifically in ohci configuration.

Anand (in copy) did make some fix which changed ordering of clock enables which were necessary to get usb bus suspend/resume working. With the other ordering you would get an abort when accessing that blocks registers.

Regards,
Richard W.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#10 lore raw
Quoted 17 lines

From: [email protected] [mailto:[email protected]] On Behalf Of Woodruff, Richard
Sent: Sunday, October 12, 2008 8:22 AM
To: David Brownell; Steve Sakoman
Cc: Anand Gadiyar; [email protected]
Subject: RE: [patch 2.6.27-rc8-omap 0/7] resend of pending TWL patches

Quoted 8 lines

[email protected]] On Behalf Of David Brownell

Quoted 5 lines

Turns out it is this one in omap_start_ehc:

        /* Wait for TLL to be Active */
        while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3) & (1 << OMAP3430ES2_ST_USBTLL_SHIFT)));

Quoted 6 lines
Quoted 4 lines

Fishy ... TLL == TransceiverLess Link, which is used with on-board links that don't need to be morphed to use signals that go over cables as defined in the USB spec. I would think you'd want ULPI.

TLL block does get used for some cases for non-tll (phy) mode use.

In particular, clocking mode used for EHCI on omap34xx is input clocking mode. This means OMAP feeds the 60Mhz clock and TLL module is used to generate the 60Mhz clock. So irrespective of TLL or ULPI-PHY mode, TLL block has to be kept up.

Quoted 8 lines

Recently there was some low
fixes for non-tll mode in which tll block handling was important. This was specifically in ohci configuration.

Anand (in copy) did make some fix which changed ordering of clock enables which were necessary to get usb bus suspend/resume working. With the other ordering you would get an abort when accessing that blocks registers.

Quoted 7 lines

Regards,
Richard W.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#11 lore raw
Quoted 9 lines · Vikram
Quoted 9 lines
Quoted 8 lines
Quoted 3 lines

        /* Wait for TLL to be Active */
        while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3) & (1 << OMAP3430ES2_ST_USBTLL_SHIFT)));

Fishy ... TLL == TransceiverLess Link, which is used with on-board links that don't need to be morphed to use signals that go over cables as defined in the USB spec.  I would think you'd want ULPI.

Quoted 5 lines
Quoted 1 line

TLL block does get used for some cases for non-tll (phy) mode use.

In particular, clocking mode used for EHCI on omap34xx is input clocking mode. This means OMAP feeds the 60Mhz clock and TLL module is used to generate the 60Mhz clock. So irrespective of TLL or ULPI-PHY mode, TLL block has to be kept up.

OK ... I suggest a comment in the code explaining that, so it's clear what's going on.

Along with whatever fix is needed to allow booting with EHCI enabled again. Something seems to be preventing TLL from coming up now...

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html