Re: Git tree updated to v2.6.27, some issues remain
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 -- 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
Re: Git tree updated to v2.6.27, some issues remain
* David Brownell <[EMAIL PROTECTED]> [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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git tree updated to v2.6.27, some issues remain
On Thursday 16 October 2008, Nathan Monson wrote: > On Thu, Oct 16, 2008 at 12:43 PM, David Brownell <[EMAIL PROTECTED]> 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 -- 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
Re: Git tree updated to v2.6.27, some issues remain
On Thu, Oct 16, 2008 at 12:43 PM, David Brownell <[EMAIL PROTECTED]> 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 -- 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
Re: Git tree updated to v2.6.27, some issues remain
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 -- 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
Re: Git tree updated to v2.6.27, some issues remain
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 PGP.sig Description: This is a digitally signed message part
Re: Git tree updated to v2.6.27, some issues remain
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git tree updated to v2.6.27, some issues remain
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 -- 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
RE: Git tree updated to v2.6.27, some issues remain
>From: David Brownell [mailto:[EMAIL PROTECTED] >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.0 -0500 +++ l-o/drivers/i2c/chips/twl4030-pwrirq.c 2008-10-10 18:14:42.0 -0500 @@ -128,14 +128,24 @@ static int twl4030_pwrirq_thread(void *d return 0; } +#include + 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
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... -- 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
RE: Git tree updated to v2.6.27, some issues remain
>From: David Brownell [mailto:[EMAIL PROTECTED] >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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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. 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
RE: Git tree updated to v2.6.27, some issues remain
>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 <[EMAIL PROTECTED]> 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 -- 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
Re: Git tree updated to v2.6.27, some issues remain
On Fri, Oct 10, 2008 at 3:15 PM, Pandita, Vikram <[EMAIL PROTECTED]> 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 -- 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
RE: Git tree updated to v2.6.27, some issues remain
>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); -- 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
RE: Git tree updated to v2.6.27, some issues remain
>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 <[EMAIL PROTECTED]> 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 [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 -- 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
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 <[EMAIL PROTECTED]> 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 [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
Re: Git tree updated to v2.6.27, some issues remain
On Fri, Oct 10, 2008 at 8:43 AM, David Brownell <[EMAIL PROTECTED]> 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 -- 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
Re: Git tree updated to v2.6.27, some issues remain
On Friday 10 October 2008, Tony Lindgren wrote: > Anything else not working right now? MUSB on Overo... -- 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