[patch 2.6.27-rc8-omap 0/7] resend of pending TWL patches

[patch 2.6.27-rc8-omap 0/7] resend of pending TWL patches

[David Brownell]

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

Re: [patch 2.6.27-rc8-omap 0/7] resend of pending TWL patches

[David Brownell]

On Friday 03 October 2008, David Brownell wrote:
> 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

Re: [patch 2.6.27-rc8-omap 0/7] resend of pending TWL patches

[Anand Gadiyar]

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

On Fri, Oct 3, 2008 at 11:06 PM, Anand Gadiyar <gadiyar@gmail.com> wrote:
> On Fri, Oct 3, 2008 at 10:12 PM, David Brownell <david-b@pacbell.net> wrote:
>> On Friday 03 October 2008, David Brownell wrote:
>>> 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
> @@ -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 */
>

Re: [patch 2.6.27-rc8-omap 0/7] resend of pending TWL patches

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

> (Hit reply instead of reply-all... Reminder to self. Never send emails
> when you're sleepy)
>
> On Fri, Oct 3, 2008 at 11:06 PM, Anand Gadiyar <gadiyar@gmail.com> wrote:
> > On Fri, Oct 3, 2008 at 10:12 PM, David Brownell <david-b@pacbell.net> 
wrote:
> >> On Friday 03 October 2008, David Brownell wrote:
> >>> 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
> > @@ -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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 2.6.27-rc8-omap 0/7] resend of pending TWL patches

[Tony Lindgren]

* Marek Vasut <marek.vasut@gmail.com> [081003 20:54]:
> 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)
> 
> > (Hit reply instead of reply-all... Reminder to self. Never send emails
> > when you're sleepy)
> >
> > On Fri, Oct 3, 2008 at 11:06 PM, Anand Gadiyar <gadiyar@gmail.com> wrote:
> > > On Fri, Oct 3, 2008 at 10:12 PM, David Brownell <david-b@pacbell.net> 
> wrote:
> > >> On Friday 03 October 2008, David Brownell wrote:
> > >>> 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


> > >>
> > >> 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
> > > @@ -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 majordomo@vger.kernel.org
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 2.6.27-rc8-omap 0/7] resend of pending TWL patches

[David Brownell]

> >> 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.


> > ====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
> > @@ -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 */
> >
> 
> 

Re: [patch 2.6.27-rc8-omap 0/7] resend of pending TWL patches

[Steve Sakoman]

On Mon, Oct 6, 2008 at 4:26 PM, David Brownell <david-b@pacbell.net> wrote:
>> >> 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.

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

Re: [patch 2.6.27-rc8-omap 0/7] resend of pending TWL patches

[David Brownell]

On Saturday 11 October 2008, Steve Sakoman wrote:
> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [patch 2.6.27-rc8-omap 0/7] resend of pending TWL patches

[Woodruff, Richard]

> owner@vger.kernel.org] On Behalf Of David Brownell
 
> > 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.

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [patch 2.6.27-rc8-omap 0/7] resend of pending TWL patches

[Pandita, Vikram]

>From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of
>Woodruff, Richard
>Sent: Sunday, October 12, 2008 8:22 AM
>To: David Brownell; Steve Sakoman
>Cc: Anand Gadiyar; linux-omap@vger.kernel.org
>Subject: RE: [patch 2.6.27-rc8-omap 0/7] resend of pending TWL patches
>
>
>> owner@vger.kernel.org] On Behalf Of David Brownell
>
>> > 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.
>
>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.




> 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.
>
>Regards,
>Richard W.
>
>--
>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

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

Re: [patch 2.6.27-rc8-omap 0/7] resend of pending TWL patches

[David Brownell]

On Sunday 12 October 2008, Pandita, Vikram wrote:
> >> >         /* 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.  
> 
> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html