Git tree updated to v2.6.27, some issues remain

Git tree updated to v2.6.27, some issues remain

[Tony Lindgren]

Hi all,

I've just updated our git tree to v2.6.27 and pushed some recent fixes.

Let's try to get the pending issues sorted out and then tag -omap1
at the end of next week. So far it looks like we still have the following
issues remaining:

- i2c transfers not working because of i2c-omap.c PM (These also make
  musb init fail at least on 3430sdp)

- 24xx/34xx write posting issue

- 34xx spurious interrupts about 1/20 reboots

Anything else not working right now?

BTW, I'll out of town for the weekend, then flying back to home on
Monday, so I'll be offline for most part until Tuesday.

Tony

Re: Git tree updated to v2.6.27, some issues remain

[David Brownell]

On Friday 10 October 2008, Tony Lindgren wrote:
> Anything else not working right now?

MUSB on Overo...

Re: Git tree updated to v2.6.27, some issues remain

[Steve Sakoman]

On Fri, Oct 10, 2008 at 8:43 AM, David Brownell <david-b@pacbell.net> wrote:
> On Friday 10 October 2008, Tony Lindgren wrote:
>> Anything else not working right now?
>
> MUSB on Overo...

Indeed.  Any theories?

I am trying a second build with EHCI enabled to see if it still dies on boot.

Steve

RE: Git tree updated to v2.6.27, some issues remain

[Pandita, Vikram]

>Sent: Friday, October 10, 2008 10:58 AM
>To: David Brownell; linux-omap@vger.kernel.org List
>Subject: Re: Git tree updated to v2.6.27, some issues remain
>
>On Fri, Oct 10, 2008 at 8:43 AM, David Brownell <david-b@pacbell.net> wrote:
>> On Friday 10 October 2008, Tony Lindgren wrote:
>>> Anything else not working right now?
>>
>> MUSB on Overo...
>
>Indeed.  Any theories?

My theory - 

In: drivers/mfd/twl4030-core.c
	struct resource r = {
      	  .start = TWL4030_PWRIRQ_USB_PRES,
	        .flags = IORESOURCE_IRQ,
	};
	status = platform_device_add_resources(pdev, &r, 1);

where value of TWL4030_PWRIRQ_USB_PRES = 378


In: drivers/i2c/chips/twl4030-usb.c
       status = request_irq(twl->irq ^(378)^ , twl4030_usb_irq, 0, "twl4030_usb", twl);
fails because 378 > NR_IRQS



>
>I am trying a second build with EHCI enabled to see if it still dies on boot.
>
>Steve
>--
>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: Git tree updated to v2.6.27, some issues remain

[Pandita, Vikram]

>Sent: Friday, October 10, 2008 3:50 PM
>To: Steve Sakoman; David Brownell; linux-omap@vger.kernel.org List
>Subject: RE: Git tree updated to v2.6.27, some issues remain
>
>>Sent: Friday, October 10, 2008 10:58 AM
>>To: David Brownell; linux-omap@vger.kernel.org List
>>Subject: Re: Git tree updated to v2.6.27, some issues remain
>>
>>On Fri, Oct 10, 2008 at 8:43 AM, David Brownell <david-b@pacbell.net> wrote:
>>> On Friday 10 October 2008, Tony Lindgren wrote:
>>>> Anything else not working right now?
>>>
>>> MUSB on Overo...
>>
>>Indeed.  Any theories?
>
>My theory -
>
>In: drivers/mfd/twl4030-core.c
>	struct resource r = {
>      	  .start = TWL4030_PWRIRQ_USB_PRES,
>	        .flags = IORESOURCE_IRQ,
>	};
>	status = platform_device_add_resources(pdev, &r, 1);
>
>where value of TWL4030_PWRIRQ_USB_PRES = 378
>
>
>In: drivers/i2c/chips/twl4030-usb.c
>       status = request_irq(twl->irq ^(378)^ , twl4030_usb_irq, 0, "twl4030_usb", twl);
>fails because 378 > NR_IRQS


Theory changed. NR_IRQS is 402. so above is not the issue.

Theory 2: 
When I debug on LDP board, I can see the failure happening in request_irq()

In T2-probe: 
	request_irq( ... )
		... 
		if (irq_desc[irq].status & IRQ_NOREQUEST)  
			return -EINVAL;	>>>> code returns from here !!! 
		...

>
>
>
>>
>>I am trying a second build with EHCI enabled to see if it still dies on boot.
>>
>>Steve
>>--
>>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: Git tree updated to v2.6.27, some issues remain

[Pandita, Vikram]

>Sent: Friday, October 10, 2008 5:15 PM
>To: Steve Sakoman; David Brownell; linux-omap@vger.kernel.org List
>Subject: RE: Git tree updated to v2.6.27, some issues remain
>
>>>>> Anything else not working right now?
>>>>
>>>> MUSB on Overo...
>>>
>
>Theory 2:
>When I debug on LDP board, I can see the failure happening in request_irq()
>
>In T2-probe:
>	request_irq( ... )
>		...
>		if (irq_desc[irq].status & IRQ_NOREQUEST)
>			return -EINVAL;	>>>> code returns from here !!!
>		...

This patch fixes the T2-probe request_irq() issue:

diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 5983926..57cad7e 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -159,7 +159,7 @@ void __init omap_init_irq(void)
 	printk(KERN_INFO "Total of %ld interrupts on %d active controller%s\n",
 	       nr_irqs, nr_banks, nr_banks > 1 ? "s" : "");
 
-	for (i = 0; i < nr_irqs; i++) {
+	for (i = 0; i < NR_IRQS; /*nr_irqs;*/ i++) {
 		set_irq_chip(i, &omap_irq_chip);
 		set_irq_handler(i, handle_level_irq);
 		set_irq_flags(i, IRQF_VALID);

Re: Git tree updated to v2.6.27, some issues remain

[David Brownell]

On Friday 10 October 2008, Pandita, Vikram wrote:
> --- a/arch/arm/mach-omap2/irq.c
> +++ b/arch/arm/mach-omap2/irq.c
> @@ -159,7 +159,7 @@ void __init omap_init_irq(void)
>         printk(KERN_INFO "Total of %ld interrupts on %d active controller%s\n",
>                nr_irqs, nr_banks, nr_banks > 1 ? "s" : "");
>  
> -       for (i = 0; i < nr_irqs; i++) {
> +       for (i = 0; i < NR_IRQS; /*nr_irqs;*/ i++) {
>                 set_irq_chip(i, &omap_irq_chip);
>                 set_irq_handler(i, handle_level_irq);
>                 set_irq_flags(i, IRQF_VALID);
> 

This could explain a problem appearing on every OMAP3 board.
But not one appearing only on Overo ... especially when the
same binary works on Beagle.

However, that's also very incorrect.  Most of those NR_IRQS
interrupts are managed by some chip other than the toplevel
OMAP IRQ controller(s)...

- 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: Git tree updated to v2.6.27, some issues remain

[Pandita, Vikram]

>From: David Brownell [mailto:david-b@pacbell.net]
>Sent: Friday, October 10, 2008 5:55 PM
>To: Pandita, Vikram
>Cc: Steve Sakoman; linux-omap@vger.kernel.org List
>Subject: Re: Git tree updated to v2.6.27, some issues remain
>
>On Friday 10 October 2008, Pandita, Vikram wrote:
>> --- a/arch/arm/mach-omap2/irq.c
>> +++ b/arch/arm/mach-omap2/irq.c
>> @@ -159,7 +159,7 @@ void __init omap_init_irq(void)
>>         printk(KERN_INFO "Total of %ld interrupts on %d active controller%s\n",
>>                nr_irqs, nr_banks, nr_banks > 1 ? "s" : "");
>>
>> -       for (i = 0; i < nr_irqs; i++) {
>> +       for (i = 0; i < NR_IRQS; /*nr_irqs;*/ i++) {
>>                 set_irq_chip(i, &omap_irq_chip);
>>                 set_irq_handler(i, handle_level_irq);
>>                 set_irq_flags(i, IRQF_VALID);
>>
>
>This could explain a problem appearing on every OMAP3 board.
>But not one appearing only on Overo ... especially when the
>same binary works on Beagle.

I saw this problem on LDP. 

>
>However, that's also very incorrect.  Most of those NR_IRQS
>interrupts are managed by some chip other than the toplevel
>OMAP IRQ controller(s)...

Somewhere for the T2 interrupts following function has to be run: 
	set_irq_flags(i, IRQF_VALID);

>
>- 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: Git tree updated to v2.6.27, some issues remain

[David Brownell]

On Friday 10 October 2008, Pandita, Vikram wrote:
> Somewhere for the T2 interrupts following function has to be run: 
>         set_irq_flags(i, IRQF_VALID);

Why do you think that's not being done?

On Beagle, it's clearly done.  And the init sequence is
the same on Overo.  So I see no reason to think it's not
being done there too...

--
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: Git tree updated to v2.6.27, some issues remain

[Pandita, Vikram]

>From: David Brownell [mailto:david-b@pacbell.net]
>Sent: Friday, October 10, 2008 7:33 PM
>To: Pandita, Vikram
>Cc: Steve Sakoman; linux-omap@vger.kernel.org List
>Subject: Re: Git tree updated to v2.6.27, some issues remain
>
>On Friday 10 October 2008, Pandita, Vikram wrote:
>> Somewhere for the T2 interrupts following function has to be run:
>>         set_irq_flags(i, IRQF_VALID);
>
>Why do you think that's not being done?
>
>On Beagle, it's clearly done.  And the init sequence is
>the same on Overo.  So I see no reason to think it's not
>being done there too...
>


I did not have your following patch.
Without this patch, the pwrirq does not initialize TWL-USB flag: set_irq_flags(i, IRQF_VALID); 
And hence the failure. 

With your patch, you delay the i2c writing and then the set_irq_flags() gets called.


Index: l-o/drivers/i2c/chips/twl4030-pwrirq.c
===================================================================
--- l-o.orig/drivers/i2c/chips/twl4030-pwrirq.c 2008-10-10 13:45:21.000000000 -0500
+++ l-o/drivers/i2c/chips/twl4030-pwrirq.c      2008-10-10 18:14:42.000000000 -0500
@@ -128,14 +128,24 @@ static int twl4030_pwrirq_thread(void *d
        return 0;
 }

+#include <linux/delay.h>
+
 static int __init twl4030_pwrirq_init(void)
 {
        int i, err;

        twl4030_pwrirq_mask = 0xff;

+/* HEY:  core already did this.
+ * But that's surely not why we
+ * sometimes see timeouts here ...
+ */
+for (i = 0; i < 5; i++) {
        err = twl4030_i2c_write_u8(TWL4030_MODULE_INT, twl4030_pwrirq_mask,
                                        TWL4030_INT_PWR_IMR1);
+if (!err) break;
+msleep(10);
+}
        if (err)
                return err;

--
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: Git tree updated to v2.6.27, some issues remain

[David Brownell]

On Friday 10 October 2008, Pandita, Vikram wrote:
> I did not have your following patch.
> Without this patch, the pwrirq does not initialize TWL-USB flag: set_irq_flags(i, IRQF_VALID); 
> And hence the failure. 
> 
> With your patch, you delay the i2c writing and then the set_irq_flags() gets called.

A better fix for this one would be either of the recent i2c-omap patches:
mine disabling the low-power idle mechanism, or Paul's making it actually
work like it was supposed to.  Paul's fix should IMO be merged.

The "MUSB doesn't work on Overo" problem kicks in even with the I2C idle
problem fixed, or that workaround patch.

- Dave

Re: Git tree updated to v2.6.27, some issues remain

[Nathan Monson]

On Fri, Oct 10, 2008 at 3:15 PM, Pandita, Vikram <vikram.pandita@ti.com> wrote:
> Theory changed. NR_IRQS is 402. so above is not the issue.
>
> Theory 2:
> When I debug on LDP board, I can see the failure happening in request_irq()
>
> In T2-probe:
>        request_irq( ... )
>                ...
>                if (irq_desc[irq].status & IRQ_NOREQUEST)
>                        return -EINVAL; >>>> code returns from here !!!
>                ...

This is exactly what I saw when testing bare linux-omap git without
Dave's i2c retry patch.  Maybe the patch is not working for you?

- Nathan

RE: Git tree updated to v2.6.27, some issues remain

[Pandita, Vikram]

>Sent: Friday, October 10, 2008 5:29 PM
>To: Pandita, Vikram
>Cc: linux-omap@vger.kernel.org List
>Subject: Re: Git tree updated to v2.6.27, some issues remain
>
>On Fri, Oct 10, 2008 at 3:15 PM, Pandita, Vikram <vikram.pandita@ti.com> wrote:
>> Theory changed. NR_IRQS is 402. so above is not the issue.
>>
>> Theory 2:
>> When I debug on LDP board, I can see the failure happening in request_irq()
>>
>> In T2-probe:
>>        request_irq( ... )
>>                ...
>>                if (irq_desc[irq].status & IRQ_NOREQUEST)
>>                        return -EINVAL; >>>> code returns from here !!!
>>                ...
>
>This is exactly what I saw when testing bare linux-omap git without
>Dave's i2c retry patch.  Maybe the patch is not working for you?

Check the fix I just sent. 

>
>- Nathan

Re: Git tree updated to v2.6.27, some issues remain

[David Brownell]

On Friday 10 October 2008, Tony Lindgren wrote:
> Let's try to get the pending issues sorted out and then tag -omap1
> at the end of next week. So far it looks like we still have the following
> issues remaining:
> 
> - i2c transfers not working because of i2c-omap.c PM (These also make
>   musb init fail at least on 3430sdp)

Resolved ...


> - 24xx/34xx write posting issue
> 
> - 34xx spurious interrupts about 1/20 reboots

... I think I saw patches for at least the posting issue
get sent ...

 
> Anything else not working right now?

The MUSB transceiver-level issues I was aware of (mostly
on Overo, but minor glitches on Beagle) now seem to be
fixed by the combination of the IRQ patches I sent last
week, plus the twl4030-usb patch I just sent.

- 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: Git tree updated to v2.6.27, some issues remain

[Koen Kooi]

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


Op 16 okt 2008, om 21:43 heeft David Brownell het volgende geschreven:

> The MUSB transceiver-level issues I was aware of (mostly
> on Overo, but minor glitches on Beagle) now seem to be
> fixed by the combination of the IRQ patches I sent last
> week, plus the twl4030-usb patch I just sent.

Does your patch also make OTG cable detect work?

regards,

Koen

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: Git tree updated to v2.6.27, some issues remain

[David Brownell]

On Thursday 16 October 2008, Koen Kooi wrote:
> > The MUSB transceiver-level issues I was aware of (mostly
> > on Overo, but minor glitches on Beagle) now seem to be
> > fixed by the combination of the IRQ patches I sent last
> > week, plus the twl4030-usb patch I just sent.
> 
> Does your patch also make OTG cable detect work?

I'm not entirely sure what you mean by that ...

For an OTG connector there are four states of note:

 (1) Nothing connected
 (2) There's a B-connector
	(2a) with nothing on the other end, same as (1)
	(2b) with a host on the other end, suppling VBUS
 (3) There's an A-connector, grounding the ID pin
	(3a) with nothing on the other end,
	(3b) with a periphereral pulling up D+ or D-

That patch uses the STS_HW_CONDITIONS register to detect
those three basic states ...

Now, whether the musb_hdrc code handles both (3a) and (3b)
correctly is another issue.  Recently it only handled the
(3b) case, which is what I tend to use.

On this go-around I didn't test the (3a) case.  If that
starts to work, great; but I was focussing on fixing the
regresssions.  Does it work for you?  (So you can plug
in a B-device to the other end, "later"?)

- Dave

Re: Git tree updated to v2.6.27, some issues remain

[Felipe Balbi]

On Thu, Oct 16, 2008 at 01:46:08PM -0700, David Brownell wrote:
> On Thursday 16 October 2008, Koen Kooi wrote:
> > > The MUSB transceiver-level issues I was aware of (mostly
> > > on Overo, but minor glitches on Beagle) now seem to be
> > > fixed by the combination of the IRQ patches I sent last
> > > week, plus the twl4030-usb patch I just sent.
> > 
> > Does your patch also make OTG cable detect work?
> 
> I'm not entirely sure what you mean by that ...
> 
> For an OTG connector there are four states of note:
> 
>  (1) Nothing connected
>  (2) There's a B-connector
> 	(2a) with nothing on the other end, same as (1)
> 	(2b) with a host on the other end, suppling VBUS
>  (3) There's an A-connector, grounding the ID pin
> 	(3a) with nothing on the other end,
> 	(3b) with a periphereral pulling up D+ or D-
> 
> That patch uses the STS_HW_CONDITIONS register to detect
> those three basic states ...
> 
> Now, whether the musb_hdrc code handles both (3a) and (3b)
> correctly is another issue.  Recently it only handled the
> (3b) case, which is what I tend to use.
> 
> On this go-around I didn't test the (3a) case.  If that
> starts to work, great; but I was focussing on fixing the
> regresssions.  Does it work for you?  (So you can plug
> in a B-device to the other end, "later"?)

In that case, if we have nothing connected on the other end, there's not
much to do besides xceiv.state = OTG_STATE_A_IDLE; It won't be useful to
start sourcing vbus since there's nothing to use it and we'd just spend
battery for nothing.

-- 
balbi

Re: Git tree updated to v2.6.27, some issues remain

[Nathan Monson]

On Thu, Oct 16, 2008 at 12:43 PM, David Brownell <david-b@pacbell.net> wrote:
> The MUSB transceiver-level issues I was aware of (mostly
> on Overo, but minor glitches on Beagle) now seem to be
> fixed by the combination of the IRQ patches I sent last
> week, plus the twl4030-usb patch I just sent.

This is working great for me now.  Whether I boot plugged in, or later
plug in the A side or B side, USB host mode is working again.  Thank
you!

Of course, I still apply a stack of Ajay's patches to get MUSB host
mode stable, but there's a different issue.

- Nathan

Re: Git tree updated to v2.6.27, some issues remain

[David Brownell]

On Thursday 16 October 2008, Nathan Monson wrote:
> On Thu, Oct 16, 2008 at 12:43 PM, David Brownell <david-b@pacbell.net> wrote:
> > The MUSB transceiver-level issues I was aware of (mostly
> > on Overo, but minor glitches on Beagle) now seem to be
> > fixed by the combination of the IRQ patches I sent last
> > week, plus the twl4030-usb patch I just sent.
> 
> This is working great for me now.  Whether I boot plugged in, or later
> plug in the A side or B side, USB host mode is working again.  Thank
> you!

:)


> Of course, I still apply a stack of Ajay's patches to get MUSB host
> mode stable, but there's a different issue.

I hope Felipe is on top of all those, and has them queued
for the upcoming 2.6.28 mainline USB merge ...

- dave

Re: Git tree updated to v2.6.27, some issues remain

[Tony Lindgren]

* David Brownell <david-b@pacbell.net> [081016 12:43]:
> On Friday 10 October 2008, Tony Lindgren wrote:
> > Let's try to get the pending issues sorted out and then tag -omap1
> > at the end of next week. So far it looks like we still have the following
> > issues remaining:
> > 
> > - i2c transfers not working because of i2c-omap.c PM (These also make
> >   musb init fail at least on 3430sdp)
> 
> Resolved ...
> 
> 
> > - 24xx/34xx write posting issue
> > 
> > - 34xx spurious interrupts about 1/20 reboots
> 
> ... I think I saw patches for at least the posting issue
> get sent ...

I pushed the strongly ordered patch for that.

> 
>  
> > Anything else not working right now?
> 
> The MUSB transceiver-level issues I was aware of (mostly
> on Overo, but minor glitches on Beagle) now seem to be
> fixed by the combination of the IRQ patches I sent last
> week, plus the twl4030-usb patch I just sent.

So I guess we have a go for tagging v2.6.27-omap1 on Friday!
Also, looks like the minimal omap3 patches just hit mainline
few hours ago :)

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