Skip to contentSkip to conversation

Git tree updated to v2.6.27, some issues remain

DISCUSSION Tony Lindgren 7 participants 20 messages Oct 10, 2008 – Oct 17, 2008

Subsystems (3)
Arm (32-bit) Arm sub-architectures OMAP2+ support
lore
Share & tools
lore

Tony Lindgren

author maintainer
#0 lore raw

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

#1 lore raw
Quoted 1 line · Tony Lindgren

Anything else not working right now?

MUSB on Overo...

#2 lore raw
Quoted 4 lines · David Brownell
Quoted 1 line · Tony Lindgren

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

#3 lore raw
Quoted 11 lines

Sent: Friday, October 10, 2008 10:58 AM
To: David Brownell; [email protected] List
Subject: Re: Git tree updated to v2.6.27, some issues remain

Quoted 4 lines · David Brownell
Quoted 1 line · Tony Lindgren

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

Quoted 8 lines

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

#4 lore raw
Quoted 25 lines

Sent: Friday, October 10, 2008 3:50 PM
To: Steve Sakoman; David Brownell; [email protected] List
Subject: RE: Git tree updated to v2.6.27, some issues remain

Quoted 11 lines

Sent: Friday, October 10, 2008 10:58 AM
To: David Brownell; [email protected] List
Subject: Re: Git tree updated to v2.6.27, some issues remain

Quoted 4 lines · David Brownell
Quoted 1 line · Tony Lindgren

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);
Quoted 6 lines

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 !!! 
		...
Quoted 16 lines
Quoted 11 lines

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

#5 lore raw
Quoted 13 lines

Sent: Friday, October 10, 2008 5:15 PM
To: Steve Sakoman; David Brownell; [email protected] List
Subject: RE: Git tree updated to v2.6.27, some issues remain

Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
Quoted 1 line

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

Quoted 6 lines

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:

arch/arm/mach-omap2/irq.c +1 -1
index 5983926..57cad7e 100644
@@ -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);
#6 lore raw
Quoted 5 lines · Vikram
arch/arm/mach-omap2/irq.c +0 -0
@@ -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" : "");
Quoted 7 lines


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

#7 lore raw
Quoted 13 lines

From: David Brownell [mailto:[email protected]]
Sent: Friday, October 10, 2008 5:55 PM
To: Pandita, Vikram
Cc: Steve Sakoman; [email protected] List
Subject: Re: Git tree updated to v2.6.27, some issues remain

Quoted 6 lines · Vikram
arch/arm/mach-omap2/irq.c +0 -0
@@ -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" : "");
Quoted 10 lines

arch/arm/mach-omap2/irq.c void __init omap_init_irq(void) · line 165

Quoted 6 lines
arch/arm/mach-omap2/irq.c +1 -1
-       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.

Quoted 4 lines

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);
Quoted 3 lines

- 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

#8 lore raw
Quoted 2 lines · Vikram

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

#9 lore raw
Quoted 8 lines

From: David Brownell [mailto:[email protected]]
Sent: Friday, October 10, 2008 7:33 PM
To: Pandita, Vikram
Cc: Steve Sakoman; [email protected] List
Subject: Re: Git tree updated to v2.6.27, some issues remain

On Friday 10 October 2008, Pandita, Vikram wrote:

Quoted 9 lines
Quoted 2 lines

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.

drivers/i2c/chips/twl4030-pwrirq.c 2008-10-10 18:14:42.000000000 -0500 renamed from drivers/i2c/chips/twl4030-pwrirq.c 2008-10-10 13:45:21.000000000 -0500 +10 -0
Index: l-o/drivers/i2c/chips/twl4030-pwrirq.c
===================================================================
@@ -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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#10 lore raw
Quoted 5 lines · Vikram

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

#11 lore raw
In reply to Pandita, Vikram
Quoted 11 lines · Vikram

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

#12 lore raw
Quoted 18 lines

Sent: Friday, October 10, 2008 5:29 PM
To: Pandita, Vikram
Cc: [email protected] List
Subject: Re: Git tree updated to v2.6.27, some issues remain

Quoted 11 lines · Vikram

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 !!!
               ...
Quoted 2 lines

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.

Quoted 2 lines

- Nathan

#13 lore raw
In reply to Tony Lindgren
Quoted 6 lines · Tony Lindgren

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

Quoted 3 lines

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

Quoted 1 line

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

#14 lore raw

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

Quoted 4 lines

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

#15 lore raw
Quoted 6 lines · Koen Kooi
Quoted 4 lines

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

#16 lore raw
Quoted 23 lines · David Brownell
Quoted 6 lines · Koen Kooi
Quoted 4 lines

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

Quoted 8 lines

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.

Signature · 1 line
balbi
#17 lore raw
In reply to David Brownell
Quoted 4 lines · David Brownell

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

#18 lore raw
Quoted 9 lines · Nathan Monson
Quoted 4 lines · David Brownell

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!

:)

Quoted 2 lines

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

author maintainer
#19 lore raw
In reply to David Brownell
Quoted 11 lines · David Brownell
Quoted 6 lines · Tony Lindgren

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

Quoted 6 lines
Quoted 3 lines

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

Quoted 8 lines
Quoted 3 lines

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