Re: MUSB dual-role on AM335x behaving weirdly
On 20/08/2015 18:46, Felipe Balbi wrote: > On Thu, Aug 20, 2015 at 06:35:17PM +0200, Gregory CLEMENT wrote: >> Hi Felipe, >> >> On 18/08/2015 16:13, Felipe Balbi wrote: >>> Hi, >>> >>> On Tue, Aug 18, 2015 at 02:36:13PM +0200, Gregory CLEMENT wrote: Hi again Felipe, I sent this email again without the capture because it prevented to be delivered to the mailing lists. On 04/08/2015 21:32, Felipe Balbi wrote: > On Tue, Aug 04, 2015 at 04:23:02PM +0200, Gregory CLEMENT wrote: >> Hi again, >> On 04/08/2015 15:08, Gregory CLEMENT wrote: >>> Hi Bin, >>> >>> On 02/07/2015 19:05, Bin Liu wrote: Hi, On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT wrote: > Hi Felipe, > > On 27/05/2015 11:42, Alexandre Belloni wrote: >> Hi, >> >> On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote : >>> On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote: Alexandre, On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni wrote: > On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote : >> I think I found the root cause of the problem: board design >> issue - I >> bet the custom board has too much cap on VBUS line. It should be >> < >> 10uF. >> > > We have a custom board that exhibits the issue but it only has a > 100nF > cap on VBUS. Have you measured the VBUS discharging? Is there any way to share your schematics? >>> >>> Alexandre, any further comments ? >>> >> >> Yeah, I have just got more info. >> >> This is the relevant part of the schematic: >> http://free-electrons.com/~alexandre/usb.png >> >> The total VBUS capacitance is 200nF and the USB0 pins are connected >> directly to the AM3358 pins. U1 is actually not fitted. >> >> We didn't measure VBUS discharging but we observe the OTG pin sensing >> stops when plugging an OTG cable without any device. > > Do you have any news about this topic? > > > Is there something else that we can do to help solving this issue? In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the gadget driver configured? It has to be a module not built-in. >>> >>> Indeed when I configured CONFIG_USB_MUSB_HDRC=m and >>> CONFIG_USB_MUSB_DSPS=m >>> it worked seamless. >>> >> >> Actually it didn't worked. And now sometimes I even received continuously >> the following message: >> >> musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active > > this is likely because your VBUS hasn't dropped below 0.8V fast enough. > > I could only trigger this message in that situation. Use a scope to poke > at VBUS and see how long is takes to reach 0.8V, this could all be cause > by too much capacitance on VBUS line. We got some news: "The capacitance on VBUS due to components is 200nF and the additional parasitic capacitance will be much smaller than this" The rail discharge time is ~36ms when an USB drive is removed from the OTG adapter. I attached a capture of this. What do you think about these values? However, "there appears to be a considerable delay between the removal of a usb drive and the initiation of the VBUS discharge (maybe ~1 second, I wasn't able to measure this time)." >>> >>> yeah, this is really weird. I can't think of anything that would make >>> VBUS discharge slower from a SW point of view. Once you remove the >>> cable, VBUS is physically removed and there's nothing else charging it. >> >> I have more feedback about it: "When I look at it on the oscilloscope >> this isn't a 'slow discharge' like a slowly draining capacitor, it is >> a delay between the removal of a device and the initiation of the >> discharge. The discharge itself is quite fast once it begins, it just >> seems as if the SOC/driver is taking a long time to notice the cable >> is disconnected. At this stage, this isn't actually a problem, just >> odd." >> >> While working on this issue we found that the >> tg_state_a_wait_vrise_timeout case seemed not managed by musb_dsps >> driver. I've just submitted a patch for it: >> https://lkml.org/lkml/2015/8/20/507 > > cool, I'll test it next week. Good finding btw. Thanks, however it seemed already needs to be amended. > >> I made most of my test on a 3.17 kernel and today by using a 4.1 >> kernel with the patch I have submitted I didn't manage to reproduce >> the issue. I saw that since 3.17, there were some patches related to >> the babble interrupts;
Re: MUSB dual-role on AM335x behaving weirdly
On Thu, Aug 20, 2015 at 06:35:17PM +0200, Gregory CLEMENT wrote: > Hi Felipe, > > On 18/08/2015 16:13, Felipe Balbi wrote: > > Hi, > > > > On Tue, Aug 18, 2015 at 02:36:13PM +0200, Gregory CLEMENT wrote: > >> Hi again Felipe, > >> > >> I sent this email again without the capture because it prevented to be > >> delivered > >> to the mailing lists. > >> > >> On 04/08/2015 21:32, Felipe Balbi wrote: > >>> On Tue, Aug 04, 2015 at 04:23:02PM +0200, Gregory CLEMENT wrote: > Hi again, > On 04/08/2015 15:08, Gregory CLEMENT wrote: > > Hi Bin, > > > > On 02/07/2015 19:05, Bin Liu wrote: > >> Hi, > >> > >> On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT > >> wrote: > >>> Hi Felipe, > >>> > >>> On 27/05/2015 11:42, Alexandre Belloni wrote: > Hi, > > On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote : > > On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote: > >> Alexandre, > >> > >> On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni > >> wrote: > >>> On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote : > I think I found the root cause of the problem: board design > issue - I > bet the custom board has too much cap on VBUS line. It should be > < > 10uF. > > >>> > >>> We have a custom board that exhibits the issue but it only has a > >>> 100nF > >>> cap on VBUS. > >> > >> Have you measured the VBUS discharging? Is there any way to share > >> your > >> schematics? > > > > Alexandre, any further comments ? > > > > Yeah, I have just got more info. > > This is the relevant part of the schematic: > http://free-electrons.com/~alexandre/usb.png > > The total VBUS capacitance is 200nF and the USB0 pins are connected > directly to the AM3358 pins. U1 is actually not fitted. > > We didn't measure VBUS discharging but we observe the OTG pin sensing > stops when plugging an OTG cable without any device. > >>> > >>> Do you have any news about this topic? > >>> > >>> > >>> Is there something else that we can do to help solving this issue? > >> > >> In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the > >> gadget driver configured? It has to be a module not built-in. > > > > Indeed when I configured CONFIG_USB_MUSB_HDRC=m and > > CONFIG_USB_MUSB_DSPS=m > > it worked seamless. > > > > Actually it didn't worked. And now sometimes I even received continuously > the following message: > > musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active > >>> > >>> this is likely because your VBUS hasn't dropped below 0.8V fast enough. > >>> > >>> I could only trigger this message in that situation. Use a scope to poke > >>> at VBUS and see how long is takes to reach 0.8V, this could all be cause > >>> by too much capacitance on VBUS line. > >> > >> We got some news: > >> "The capacitance on VBUS due to components is 200nF and the additional > >> parasitic > >> capacitance will be much smaller than this" > >> > >> The rail discharge time is ~36ms when an USB drive is removed from the OTG > >> adapter. > >> I attached a capture of this. > >> > >> What do you think about these values? > >> > >> > >> However, "there appears to be a considerable delay between the removal of > >> a usb > >> drive and the initiation of the VBUS discharge (maybe ~1 second, I wasn't > >> able > >> to measure this time)." > > > > yeah, this is really weird. I can't think of anything that would make > > VBUS discharge slower from a SW point of view. Once you remove the > > cable, VBUS is physically removed and there's nothing else charging it. > > I have more feedback about it: "When I look at it on the oscilloscope > this isn't a 'slow discharge' like a slowly draining capacitor, it is > a delay between the removal of a device and the initiation of the > discharge. The discharge itself is quite fast once it begins, it just > seems as if the SOC/driver is taking a long time to notice the cable > is disconnected. At this stage, this isn't actually a problem, just > odd." > > While working on this issue we found that the > tg_state_a_wait_vrise_timeout case seemed not managed by musb_dsps > driver. I've just submitted a patch for it: > https://lkml.org/lkml/2015/8/20/507 cool, I'll test it next week. Good finding btw. > I made most of my test on a 3.17 kernel and today by using a 4.1 > kernel with the patch I have submitted I didn't manage to reproduce > the issue. I saw that since 3.17, there were some patches related to > the babble interrupts; so maybe it was enough to fix the issue we saw. > It is still weird because one month ago I also tested with a 4.1 > ker
Re: MUSB dual-role on AM335x behaving weirdly
Hi Felipe, On 18/08/2015 16:13, Felipe Balbi wrote: > Hi, > > On Tue, Aug 18, 2015 at 02:36:13PM +0200, Gregory CLEMENT wrote: >> Hi again Felipe, >> >> I sent this email again without the capture because it prevented to be >> delivered >> to the mailing lists. >> >> On 04/08/2015 21:32, Felipe Balbi wrote: >>> On Tue, Aug 04, 2015 at 04:23:02PM +0200, Gregory CLEMENT wrote: Hi again, On 04/08/2015 15:08, Gregory CLEMENT wrote: > Hi Bin, > > On 02/07/2015 19:05, Bin Liu wrote: >> Hi, >> >> On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT >> wrote: >>> Hi Felipe, >>> >>> On 27/05/2015 11:42, Alexandre Belloni wrote: Hi, On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote : > On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote: >> Alexandre, >> >> On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni >> wrote: >>> On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote : I think I found the root cause of the problem: board design issue - I bet the custom board has too much cap on VBUS line. It should be < 10uF. >>> >>> We have a custom board that exhibits the issue but it only has a >>> 100nF >>> cap on VBUS. >> >> Have you measured the VBUS discharging? Is there any way to share >> your >> schematics? > > Alexandre, any further comments ? > Yeah, I have just got more info. This is the relevant part of the schematic: http://free-electrons.com/~alexandre/usb.png The total VBUS capacitance is 200nF and the USB0 pins are connected directly to the AM3358 pins. U1 is actually not fitted. We didn't measure VBUS discharging but we observe the OTG pin sensing stops when plugging an OTG cable without any device. >>> >>> Do you have any news about this topic? >>> >>> >>> Is there something else that we can do to help solving this issue? >> >> In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the >> gadget driver configured? It has to be a module not built-in. > > Indeed when I configured CONFIG_USB_MUSB_HDRC=m and CONFIG_USB_MUSB_DSPS=m > it worked seamless. > Actually it didn't worked. And now sometimes I even received continuously the following message: musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active >>> >>> this is likely because your VBUS hasn't dropped below 0.8V fast enough. >>> >>> I could only trigger this message in that situation. Use a scope to poke >>> at VBUS and see how long is takes to reach 0.8V, this could all be cause >>> by too much capacitance on VBUS line. >> >> We got some news: >> "The capacitance on VBUS due to components is 200nF and the additional >> parasitic >> capacitance will be much smaller than this" >> >> The rail discharge time is ~36ms when an USB drive is removed from the OTG >> adapter. >> I attached a capture of this. >> >> What do you think about these values? >> >> >> However, "there appears to be a considerable delay between the removal of a >> usb >> drive and the initiation of the VBUS discharge (maybe ~1 second, I wasn't >> able >> to measure this time)." > > yeah, this is really weird. I can't think of anything that would make > VBUS discharge slower from a SW point of view. Once you remove the > cable, VBUS is physically removed and there's nothing else charging it. I have more feedback about it: "When I look at it on the oscilloscope this isn't a 'slow discharge' like a slowly draining capacitor, it is a delay between the removal of a device and the initiation of the discharge. The discharge itself is quite fast once it begins, it just seems as if the SOC/driver is taking a long time to notice the cable is disconnected. At this stage, this isn't actually a problem, just odd." While working on this issue we found that the tg_state_a_wait_vrise_timeout case seemed not managed by musb_dsps driver. I've just submitted a patch for it: https://lkml.org/lkml/2015/8/20/507 I made most of my test on a 3.17 kernel and today by using a 4.1 kernel with the patch I have submitted I didn't manage to reproduce the issue. I saw that since 3.17, there were some patches related to the babble interrupts; so maybe it was enough to fix the issue we saw. It is still weird because one month ago I also tested with a 4.1 kernel and I had issues... It needs more testing to see if it is really fixed because the issue comes only time to time. I will keep you inform about our last tests. Thanks, Gregory -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "un
Re: MUSB dual-role on AM335x behaving weirdly
Hi, On Tue, Aug 18, 2015 at 02:36:13PM +0200, Gregory CLEMENT wrote: > Hi again Felipe, > > I sent this email again without the capture because it prevented to be > delivered > to the mailing lists. > > On 04/08/2015 21:32, Felipe Balbi wrote: > > On Tue, Aug 04, 2015 at 04:23:02PM +0200, Gregory CLEMENT wrote: > >> Hi again, > >> On 04/08/2015 15:08, Gregory CLEMENT wrote: > >>> Hi Bin, > >>> > >>> On 02/07/2015 19:05, Bin Liu wrote: > Hi, > > On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT > wrote: > > Hi Felipe, > > > > On 27/05/2015 11:42, Alexandre Belloni wrote: > >> Hi, > >> > >> On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote : > >>> On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote: > Alexandre, > > On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni > wrote: > > On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote : > >> I think I found the root cause of the problem: board design issue > >> - I > >> bet the custom board has too much cap on VBUS line. It should be < > >> 10uF. > >> > > > > We have a custom board that exhibits the issue but it only has a > > 100nF > > cap on VBUS. > > Have you measured the VBUS discharging? Is there any way to share > your > schematics? > >>> > >>> Alexandre, any further comments ? > >>> > >> > >> Yeah, I have just got more info. > >> > >> This is the relevant part of the schematic: > >> http://free-electrons.com/~alexandre/usb.png > >> > >> The total VBUS capacitance is 200nF and the USB0 pins are connected > >> directly to the AM3358 pins. U1 is actually not fitted. > >> > >> We didn't measure VBUS discharging but we observe the OTG pin sensing > >> stops when plugging an OTG cable without any device. > > > > Do you have any news about this topic? > > > > > > Is there something else that we can do to help solving this issue? > > In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the > gadget driver configured? It has to be a module not built-in. > >>> > >>> Indeed when I configured CONFIG_USB_MUSB_HDRC=m and CONFIG_USB_MUSB_DSPS=m > >>> it worked seamless. > >>> > >> > >> Actually it didn't worked. And now sometimes I even received continuously > >> the following message: > >> > >> musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active > > > > this is likely because your VBUS hasn't dropped below 0.8V fast enough. > > > > I could only trigger this message in that situation. Use a scope to poke > > at VBUS and see how long is takes to reach 0.8V, this could all be cause > > by too much capacitance on VBUS line. > > We got some news: > "The capacitance on VBUS due to components is 200nF and the additional > parasitic > capacitance will be much smaller than this" > > The rail discharge time is ~36ms when an USB drive is removed from the OTG > adapter. > I attached a capture of this. > > What do you think about these values? > > > However, "there appears to be a considerable delay between the removal of a > usb > drive and the initiation of the VBUS discharge (maybe ~1 second, I wasn't able > to measure this time)." yeah, this is really weird. I can't think of anything that would make VBUS discharge slower from a SW point of view. Once you remove the cable, VBUS is physically removed and there's nothing else charging it. -- balbi signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
Hi again Felipe, I sent this email again without the capture because it prevented to be delivered to the mailing lists. On 04/08/2015 21:32, Felipe Balbi wrote: > On Tue, Aug 04, 2015 at 04:23:02PM +0200, Gregory CLEMENT wrote: >> Hi again, >> On 04/08/2015 15:08, Gregory CLEMENT wrote: >>> Hi Bin, >>> >>> On 02/07/2015 19:05, Bin Liu wrote: Hi, On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT wrote: > Hi Felipe, > > On 27/05/2015 11:42, Alexandre Belloni wrote: >> Hi, >> >> On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote : >>> On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote: Alexandre, On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni wrote: > On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote : >> I think I found the root cause of the problem: board design issue - I >> bet the custom board has too much cap on VBUS line. It should be < >> 10uF. >> > > We have a custom board that exhibits the issue but it only has a 100nF > cap on VBUS. Have you measured the VBUS discharging? Is there any way to share your schematics? >>> >>> Alexandre, any further comments ? >>> >> >> Yeah, I have just got more info. >> >> This is the relevant part of the schematic: >> http://free-electrons.com/~alexandre/usb.png >> >> The total VBUS capacitance is 200nF and the USB0 pins are connected >> directly to the AM3358 pins. U1 is actually not fitted. >> >> We didn't measure VBUS discharging but we observe the OTG pin sensing >> stops when plugging an OTG cable without any device. > > Do you have any news about this topic? > > > Is there something else that we can do to help solving this issue? In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the gadget driver configured? It has to be a module not built-in. >>> >>> Indeed when I configured CONFIG_USB_MUSB_HDRC=m and CONFIG_USB_MUSB_DSPS=m >>> it worked seamless. >>> >> >> Actually it didn't worked. And now sometimes I even received continuously >> the following message: >> >> musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active > > this is likely because your VBUS hasn't dropped below 0.8V fast enough. > > I could only trigger this message in that situation. Use a scope to poke > at VBUS and see how long is takes to reach 0.8V, this could all be cause > by too much capacitance on VBUS line. We got some news: "The capacitance on VBUS due to components is 200nF and the additional parasitic capacitance will be much smaller than this" The rail discharge time is ~36ms when an USB drive is removed from the OTG adapter. I attached a capture of this. What do you think about these values? However, "there appears to be a considerable delay between the removal of a usb drive and the initiation of the VBUS discharge (maybe ~1 second, I wasn't able to measure this time)." Thanks, Gregory -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MUSB dual-role on AM335x behaving weirdly
On Tue, Aug 04, 2015 at 04:23:02PM +0200, Gregory CLEMENT wrote: > Hi again, > On 04/08/2015 15:08, Gregory CLEMENT wrote: > > Hi Bin, > > > > On 02/07/2015 19:05, Bin Liu wrote: > >> Hi, > >> > >> On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT > >> wrote: > >>> Hi Felipe, > >>> > >>> On 27/05/2015 11:42, Alexandre Belloni wrote: > Hi, > > On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote : > > On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote: > >> Alexandre, > >> > >> On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni > >> wrote: > >>> On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote : > I think I found the root cause of the problem: board design issue - I > bet the custom board has too much cap on VBUS line. It should be < > 10uF. > > >>> > >>> We have a custom board that exhibits the issue but it only has a 100nF > >>> cap on VBUS. > >> > >> Have you measured the VBUS discharging? Is there any way to share your > >> schematics? > > > > Alexandre, any further comments ? > > > > Yeah, I have just got more info. > > This is the relevant part of the schematic: > http://free-electrons.com/~alexandre/usb.png > > The total VBUS capacitance is 200nF and the USB0 pins are connected > directly to the AM3358 pins. U1 is actually not fitted. > > We didn't measure VBUS discharging but we observe the OTG pin sensing > stops when plugging an OTG cable without any device. > >>> > >>> Do you have any news about this topic? > >>> > >>> > >>> Is there something else that we can do to help solving this issue? > >> > >> In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the > >> gadget driver configured? It has to be a module not built-in. > > > > Indeed when I configured CONFIG_USB_MUSB_HDRC=m and CONFIG_USB_MUSB_DSPS=m > > it worked seamless. > > > > Actually it didn't worked. And now sometimes I even received continuously > the following message: > > musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active this is likely because your VBUS hasn't dropped below 0.8V fast enough. I could only trigger this message in that situation. Use a scope to poke at VBUS and see how long is takes to reach 0.8V, this could all be cause by too much capacitance on VBUS line. cheers -- balbi signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
Hi again, On 04/08/2015 15:08, Gregory CLEMENT wrote: > Hi Bin, > > On 02/07/2015 19:05, Bin Liu wrote: >> Hi, >> >> On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT >> wrote: >>> Hi Felipe, >>> >>> On 27/05/2015 11:42, Alexandre Belloni wrote: Hi, On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote : > On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote: >> Alexandre, >> >> On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni >> wrote: >>> On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote : I think I found the root cause of the problem: board design issue - I bet the custom board has too much cap on VBUS line. It should be < 10uF. >>> >>> We have a custom board that exhibits the issue but it only has a 100nF >>> cap on VBUS. >> >> Have you measured the VBUS discharging? Is there any way to share your >> schematics? > > Alexandre, any further comments ? > Yeah, I have just got more info. This is the relevant part of the schematic: http://free-electrons.com/~alexandre/usb.png The total VBUS capacitance is 200nF and the USB0 pins are connected directly to the AM3358 pins. U1 is actually not fitted. We didn't measure VBUS discharging but we observe the OTG pin sensing stops when plugging an OTG cable without any device. >>> >>> Do you have any news about this topic? >>> >>> >>> Is there something else that we can do to help solving this issue? >> >> In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the >> gadget driver configured? It has to be a module not built-in. > > Indeed when I configured CONFIG_USB_MUSB_HDRC=m and CONFIG_USB_MUSB_DSPS=m > it worked seamless. > Actually it didn't worked. And now sometimes I even received continuously the following message: musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active Gregory -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MUSB dual-role on AM335x behaving weirdly
Hi Bin, On 02/07/2015 19:05, Bin Liu wrote: > Hi, > > On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT > wrote: >> Hi Felipe, >> >> On 27/05/2015 11:42, Alexandre Belloni wrote: >>> Hi, >>> >>> On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote : On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote: > Alexandre, > > On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni > wrote: >> On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote : >>> I think I found the root cause of the problem: board design issue - I >>> bet the custom board has too much cap on VBUS line. It should be < >>> 10uF. >>> >> >> We have a custom board that exhibits the issue but it only has a 100nF >> cap on VBUS. > > Have you measured the VBUS discharging? Is there any way to share your > schematics? Alexandre, any further comments ? >>> >>> Yeah, I have just got more info. >>> >>> This is the relevant part of the schematic: >>> http://free-electrons.com/~alexandre/usb.png >>> >>> The total VBUS capacitance is 200nF and the USB0 pins are connected >>> directly to the AM3358 pins. U1 is actually not fitted. >>> >>> We didn't measure VBUS discharging but we observe the OTG pin sensing >>> stops when plugging an OTG cable without any device. >> >> Do you have any news about this topic? >> >> >> Is there something else that we can do to help solving this issue? > > In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the > gadget driver configured? It has to be a module not built-in. Indeed when I configured CONFIG_USB_MUSB_HDRC=m and CONFIG_USB_MUSB_DSPS=m it worked seamless. Thanks, Gregory > > Regards, > -Bin. > >> >> >> Thanks, >> >> Gregory >> >> >> -- >> Gregory Clement, Free Electrons >> Kernel, drivers, real-time and embedded Linux >> development, consulting, training and support. >> http://free-electrons.com -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MUSB dual-role on AM335x behaving weirdly
Hi, On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT wrote: > Hi Felipe, > > On 27/05/2015 11:42, Alexandre Belloni wrote: >> Hi, >> >> On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote : >>> On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote: Alexandre, On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni wrote: > On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote : >> I think I found the root cause of the problem: board design issue - I >> bet the custom board has too much cap on VBUS line. It should be < >> 10uF. >> > > We have a custom board that exhibits the issue but it only has a 100nF > cap on VBUS. Have you measured the VBUS discharging? Is there any way to share your schematics? >>> >>> Alexandre, any further comments ? >>> >> >> Yeah, I have just got more info. >> >> This is the relevant part of the schematic: >> http://free-electrons.com/~alexandre/usb.png >> >> The total VBUS capacitance is 200nF and the USB0 pins are connected >> directly to the AM3358 pins. U1 is actually not fitted. >> >> We didn't measure VBUS discharging but we observe the OTG pin sensing >> stops when plugging an OTG cable without any device. > > Do you have any news about this topic? > > > Is there something else that we can do to help solving this issue? In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the gadget driver configured? It has to be a module not built-in. Regards, -Bin. > > > Thanks, > > Gregory > > > -- > Gregory Clement, Free Electrons > Kernel, drivers, real-time and embedded Linux > development, consulting, training and support. > http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MUSB dual-role on AM335x behaving weirdly
Hi Felipe, On 27/05/2015 11:42, Alexandre Belloni wrote: > Hi, > > On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote : >> On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote: >>> Alexandre, >>> >>> On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni >>> wrote: On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote : > I think I found the root cause of the problem: board design issue - I > bet the custom board has too much cap on VBUS line. It should be < > 10uF. > We have a custom board that exhibits the issue but it only has a 100nF cap on VBUS. >>> >>> Have you measured the VBUS discharging? Is there any way to share your >>> schematics? >> >> Alexandre, any further comments ? >> > > Yeah, I have just got more info. > > This is the relevant part of the schematic: > http://free-electrons.com/~alexandre/usb.png > > The total VBUS capacitance is 200nF and the USB0 pins are connected > directly to the AM3358 pins. U1 is actually not fitted. > > We didn't measure VBUS discharging but we observe the OTG pin sensing > stops when plugging an OTG cable without any device. Do you have any news about this topic? Is there something else that we can do to help solving this issue? Thanks, Gregory -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MUSB dual-role on AM335x behaving weirdly
Hi, On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote : > On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote: > > Alexandre, > > > > On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni > > wrote: > > > On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote : > > >> I think I found the root cause of the problem: board design issue - I > > >> bet the custom board has too much cap on VBUS line. It should be < > > >> 10uF. > > >> > > > > > > We have a custom board that exhibits the issue but it only has a 100nF > > > cap on VBUS. > > > > Have you measured the VBUS discharging? Is there any way to share your > > schematics? > > Alexandre, any further comments ? > Yeah, I have just got more info. This is the relevant part of the schematic: http://free-electrons.com/~alexandre/usb.png The total VBUS capacitance is 200nF and the USB0 pins are connected directly to the AM3358 pins. U1 is actually not fitted. We didn't measure VBUS discharging but we observe the OTG pin sensing stops when plugging an OTG cable without any device. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MUSB dual-role on AM335x behaving weirdly
On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote: > Alexandre, > > On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni > wrote: > > On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote : > >> I think I found the root cause of the problem: board design issue - I > >> bet the custom board has too much cap on VBUS line. It should be < > >> 10uF. > >> > > > > We have a custom board that exhibits the issue but it only has a 100nF > > cap on VBUS. > > Have you measured the VBUS discharging? Is there any way to share your > schematics? Alexandre, any further comments ? -- balbi signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
On Thu, May 14, 2015 at 02:19:28PM -0500, Bin Liu wrote: > Felipe, > > On Thu, May 14, 2015 at 2:04 PM, Felipe Balbi wrote: > > On Thu, May 14, 2015 at 12:49:07PM -0500, Felipe Balbi wrote: > >> On Thu, May 14, 2015 at 12:40:31PM -0500, Felipe Balbi wrote: > >> > On Thu, May 14, 2015 at 12:07:00PM -0500, Felipe Balbi wrote: > >> > > Hi, > >> > > > >> > > On Wed, Feb 25, 2015 at 01:11:22PM +0100, Yegor Yefremov wrote: > >> > > > On 25.02.2015 12:11, Maxime Ripard wrote: > >> > > > > On Tue, Feb 24, 2015 at 11:33:57AM -0600, Felipe Balbi wrote: > >> > > > >> Hi, > >> > > > >> > >> > > > >> On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote: > >> > > > >>> Hi Felipe, > >> > > > >>> > >> > > > >>> On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote: > >> > > > Hi, > >> > > > > >> > > > On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote: > >> > > > > On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote: > >> > > > >> Hi, > >> > > > >> > >> > > > >> On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov > >> > > > >> wrote: > >> > > > >>> I have the same experience with 3.15. The switching is > >> > > > >>> working when > >> > > > >>> CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But > >> > > > >>> since 3.16 > >> > > > >> > >> > > > >> since 3.16 ? > >> > > > > > >> > > > > That's what Yegor said. I never saw it working with 3.15 either. > >> > > > > >> > > > I've used 3.15.1 and 3.15.2 with this set of patches: > >> > > > https://github.com/visionsystemsgmbh/onrisc_br_bsp/tree/master/board/vscom/kernel-patches/linux-3.15 > >> > > > > >> > > > And it worked so far. The system: > >> > > > http://www.visionsystems.de/produkte/baltos-ir-5221.html > >> > > > >> > > I've had more time to look into this (thanks Yegor for sponsoring a > >> > > test/dev platform) what I noticed is that Connect IRQ takes seconds to > >> > > fire up. Below a tiny log snippet after pluging USB OTG adapter cable > >> > > that came with IR5521: > >> > > > >> > > | [ 1227.200514] musb-hdrc musb-hdrc.1.auto: usbintr (100) epintr(0) > >> > > > >> > > Cable connected. ID is grounded. 0x100 == DRVVBUS IRQ > >> > > > >> > > | [ 1227.206788] musb-hdrc musb-hdrc.1.auto: VBUS on (a_wait_vrise), > >> > > devctl 19 > >> > > > >> > > MUSB starts to wait for VBUS to reach Session valid threshold > >> > > > >> > > | [ 1230.281159] musb-hdrc musb-hdrc.1.auto: usbintr (10) epintr(0) > >> > > > >> > > 3 seconds later connect interrupt happens. Looking at VBUS charge time > >> > > with a scope, it's quite ok. VBUS charges in about 1.77ms. I'll dig > >> > > further into this. > >> > > >> > even more weird. If I disconnect device from OTG adapter, rather than > >> > OTG adapter from IR5521, this leave ID pin grounded, which means DRVVBUS > >> > is still asserted and VBUS remains above session valid threshold. > >> > > >> > Even in this case, when I connect the device on the other end of the > >> > cable, I still see some 3 seconds delay from the time device is > >> > connected, to the time connect IRQ fires up. > >> > >> seems to be a problem with the USB stick I'm using. Tested two other > >> devices and they connect right away. > > > > ok, fixing DRD on AM335x will take longer than I originally expected, > > probably won't be ready for v4.2 :-( > > Are you able replicate the issue with TI AM335x GP EVM? I am wondering > if the is custom board design problem? have you checked the custom > board schematics? don't have either AM335x GP EVM nor schematics for this board. But it's certainly not a problem with the board. It's very easy to replicate the problem: Set dr-mode to otg, load g_zero, connect to PC and as quickly as you can, remove cable and attach otg cable with a mouse or whatever on the other end. First time, mouse won't enumerate (no IRQs fire) remove and connect again. You should see a Babble IRQ. -- balbi signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
Hi, On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote: > Hi, > > On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: > > I have the same experience with 3.15. The switching is working when > > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16 > > it seems to be broken. Still had no time to bisect this. > > I've been giving a few versions (from v3.15 to Tuesday's linux-next) a > try, and I always see the same behaviour now: > > - Booting as a gadget (ie, with a USB cable plugged in), and > swapping the cable for a (real, this time) USB OTG cable with a > USB key never works. When the device is plugged, all I get is > > [ 262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc > [ 278.064748] usb 1-1: device descriptor read/64, error -110 > > Putting in back in gadget results with a load of continuous: > [ 315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall while > active > > - Booting as a host, or with nothing connected to it actually work, > up to a few plug-a-device-then-plug-a-host cycles, where you end > up with the following logs when disconnecting the device (somehow, > it always happens when it is set in host mode). > > [ 12.969075] CAUTION: musb: Babble Interrupt Occurred > [ 12.974445] CAUTION: musb: Babble Interrupt Occurred > [ 12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition > (a_wait_bcon) > [ 12.988498] usb 1-1: USB disconnect, device number 2 > [ 13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from > Babble > > Plugging back our USB cable, with the AM335x acting as a device > work once. Then, when it switches to the host mode, we end up with > the same scenario than in the coldplug as gadget case: USB read > error, before then having all the a_wait_vfall messages. I gave it some more testing these two days, with next-20150410, with pretty much the same results. Dumping the DSPS glue registers doesn't get anywhere, in both cases (booting as peripheral and then switching to host, or booting as host) they are identical. However, the musb registers vary greatly. In the first case, we boot as host, switch to peripheral, and then switch back to host, repeatedly until it fails: http://code.bulix.org/p0d964-88211?raw We can see that while it still works, value comes back to their original state when switching back to host, which makes sense. However, when it fails, some registers are not set back to their initial values, including TxMaxPp, TxCSRp, RxMaxPp, ConfigData, DevCtl, TxFIFOadd and RxFIFOadd. Some registers that were not changing while it was working also now have a different value: TxMaxPp, RxMaxPp, MISC, TxFIFOsz and RxFIFOsz. Starting with the device as peripheral, and then switching to host fails instantly, once again with exotic values for the registers compared to the configuration set whenever the host mode is working: http://code.bulix.org/uo8fmu-88210?raw However, the registers values are quite similar to the one we got previously when the host mode was failing after a while, which might indicate that we end up in the same case somehow. Since I've not been able to find the musb datasheet, I'm unfortunately unable to make any deduction from these besides that something looks fishy. I've also did some runs with the musb glue and core compiled with debug options: Booted as host: http://code.bulix.org/97jz3i-88207?raw Booted as peripheral: http://code.bulix.org/vqdqt6-88208?raw I hope it helps... Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
On 25.02.2015 12:11, Maxime Ripard wrote: > On Tue, Feb 24, 2015 at 11:33:57AM -0600, Felipe Balbi wrote: >> Hi, >> >> On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote: >>> Hi Felipe, >>> >>> On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote: Hi, On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote: > On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote: >> Hi, >> >> On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: >>> I have the same experience with 3.15. The switching is working when >>> CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16 >> >> since 3.16 ? > > That's what Yegor said. I never saw it working with 3.15 either. I've used 3.15.1 and 3.15.2 with this set of patches: https://github.com/visionsystemsgmbh/onrisc_br_bsp/tree/master/board/vscom/kernel-patches/linux-3.15 And it worked so far. The system: http://www.visionsystems.de/produkte/baltos-ir-5221.html >>> it seems to be broken. Still had no time to bisect this. >> >> I've been giving a few versions (from v3.15 to Tuesday's linux-next) a >> try, and I always see the same behaviour now: >> >> - Booting as a gadget (ie, with a USB cable plugged in), and >> swapping the cable for a (real, this time) USB OTG cable with a >> USB key never works. When the device is plugged, all I get is >> >> [ 262.944846] usb 1-1: new high-speed USB device number 2 using >> musb-hdrc >> [ 278.064748] usb 1-1: device descriptor read/64, error -110 >> >> Putting in back in gadget results with a load of continuous: >> [ 315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall >> while active >> >> - Booting as a host, or with nothing connected to it actually work, >> up to a few plug-a-device-then-plug-a-host cycles, where you end >> up with the following logs when disconnecting the device (somehow, >> it always happens when it is set in host mode). >> >> [ 12.969075] CAUTION: musb: Babble Interrupt Occurred >> [ 12.974445] CAUTION: musb: Babble Interrupt Occurred >> [ 12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition >> (a_wait_bcon) >> [ 12.988498] usb 1-1: USB disconnect, device number 2 >> [ 13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover >> from Babble >> >> Plugging back our USB cable, with the AM335x acting as a device >> work once. Then, when it switches to the host mode, we end up with >> the same scenario than in the coldplug as gadget case: USB read >> error, before then having all the a_wait_vfall messages. > > Guys, any ideas/hints? which platform are you using ? I guess the only way to move here would be to bisect between 3.15 and 3.16 to find the offending commit. >>> >>> 3.15 didn't work either unfortunately. I had the behaviour described >>> above on all kernel between 3.15 and a 4.0-rc1-ish. >>> >>> This is on an custom design based on the am335x. >> >> has it ever worked ? I don't have a board here which can do dual role. >> BBB has a mini-B only on the peripheral port. > > I don't know if it ever worked. > > Maxime > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MUSB dual-role on AM335x behaving weirdly
On Tue, Feb 24, 2015 at 11:33:57AM -0600, Felipe Balbi wrote: > Hi, > > On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote: > > Hi Felipe, > > > > On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote: > > > Hi, > > > > > > On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote: > > > > On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote: > > > > > Hi, > > > > > > > > > > On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: > > > > > > I have the same experience with 3.15. The switching is working when > > > > > > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16 > > since 3.16 ? That's what Yegor said. I never saw it working with 3.15 either. > > > > > > it seems to be broken. Still had no time to bisect this. > > > > > > > > > > I've been giving a few versions (from v3.15 to Tuesday's linux-next) a > > > > > try, and I always see the same behaviour now: > > > > > > > > > > - Booting as a gadget (ie, with a USB cable plugged in), and > > > > > swapping the cable for a (real, this time) USB OTG cable with a > > > > > USB key never works. When the device is plugged, all I get is > > > > > > > > > > [ 262.944846] usb 1-1: new high-speed USB device number 2 using > > > > > musb-hdrc > > > > > [ 278.064748] usb 1-1: device descriptor read/64, error -110 > > > > > > > > > > Putting in back in gadget results with a load of continuous: > > > > > [ 315.258839] musb_bus_suspend 2484: trying to suspend as > > > > > a_wait_vfall while active > > > > > > > > > > - Booting as a host, or with nothing connected to it actually work, > > > > > up to a few plug-a-device-then-plug-a-host cycles, where you end > > > > > up with the following logs when disconnecting the device (somehow, > > > > > it always happens when it is set in host mode). > > > > > > > > > > [ 12.969075] CAUTION: musb: Babble Interrupt Occurred > > > > > [ 12.974445] CAUTION: musb: Babble Interrupt Occurred > > > > > [ 12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition > > > > > (a_wait_bcon) > > > > > [ 12.988498] usb 1-1: USB disconnect, device number 2 > > > > > [ 13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover > > > > > from Babble > > > > > > > > > > Plugging back our USB cable, with the AM335x acting as a device > > > > > work once. Then, when it switches to the host mode, we end up with > > > > > the same scenario than in the coldplug as gadget case: USB read > > > > > error, before then having all the a_wait_vfall messages. > > > > > > > > Guys, any ideas/hints? > > > > > > which platform are you using ? I guess the only way to move here would > > > be to bisect between 3.15 and 3.16 to find the offending commit. > > > > 3.15 didn't work either unfortunately. I had the behaviour described > > above on all kernel between 3.15 and a 4.0-rc1-ish. > > > > This is on an custom design based on the am335x. > > has it ever worked ? I don't have a board here which can do dual role. > BBB has a mini-B only on the peripheral port. I don't know if it ever worked. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
Hi, On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote: > Hi Felipe, > > On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote: > > Hi, > > > > On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote: > > > On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote: > > > > Hi, > > > > > > > > On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: > > > > > I have the same experience with 3.15. The switching is working when > > > > > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16 since 3.16 ? > > > > > it seems to be broken. Still had no time to bisect this. > > > > > > > > I've been giving a few versions (from v3.15 to Tuesday's linux-next) a > > > > try, and I always see the same behaviour now: > > > > > > > > - Booting as a gadget (ie, with a USB cable plugged in), and > > > > swapping the cable for a (real, this time) USB OTG cable with a > > > > USB key never works. When the device is plugged, all I get is > > > > > > > > [ 262.944846] usb 1-1: new high-speed USB device number 2 using > > > > musb-hdrc > > > > [ 278.064748] usb 1-1: device descriptor read/64, error -110 > > > > > > > > Putting in back in gadget results with a load of continuous: > > > > [ 315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall > > > > while active > > > > > > > > - Booting as a host, or with nothing connected to it actually work, > > > > up to a few plug-a-device-then-plug-a-host cycles, where you end > > > > up with the following logs when disconnecting the device (somehow, > > > > it always happens when it is set in host mode). > > > > > > > > [ 12.969075] CAUTION: musb: Babble Interrupt Occurred > > > > [ 12.974445] CAUTION: musb: Babble Interrupt Occurred > > > > [ 12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition > > > > (a_wait_bcon) > > > > [ 12.988498] usb 1-1: USB disconnect, device number 2 > > > > [ 13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover > > > > from Babble > > > > > > > > Plugging back our USB cable, with the AM335x acting as a device > > > > work once. Then, when it switches to the host mode, we end up with > > > > the same scenario than in the coldplug as gadget case: USB read > > > > error, before then having all the a_wait_vfall messages. > > > > > > Guys, any ideas/hints? > > > > which platform are you using ? I guess the only way to move here would > > be to bisect between 3.15 and 3.16 to find the offending commit. > > 3.15 didn't work either unfortunately. I had the behaviour described > above on all kernel between 3.15 and a 4.0-rc1-ish. > > This is on an custom design based on the am335x. has it ever worked ? I don't have a board here which can do dual role. BBB has a mini-B only on the peripheral port. -- balbi signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
Hi Felipe, On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote: > Hi, > > On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote: > > On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote: > > > Hi, > > > > > > On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: > > > > I have the same experience with 3.15. The switching is working when > > > > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16 > > > > it seems to be broken. Still had no time to bisect this. > > > > > > I've been giving a few versions (from v3.15 to Tuesday's linux-next) a > > > try, and I always see the same behaviour now: > > > > > > - Booting as a gadget (ie, with a USB cable plugged in), and > > > swapping the cable for a (real, this time) USB OTG cable with a > > > USB key never works. When the device is plugged, all I get is > > > > > > [ 262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc > > > [ 278.064748] usb 1-1: device descriptor read/64, error -110 > > > > > > Putting in back in gadget results with a load of continuous: > > > [ 315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall > > > while active > > > > > > - Booting as a host, or with nothing connected to it actually work, > > > up to a few plug-a-device-then-plug-a-host cycles, where you end > > > up with the following logs when disconnecting the device (somehow, > > > it always happens when it is set in host mode). > > > > > > [ 12.969075] CAUTION: musb: Babble Interrupt Occurred > > > [ 12.974445] CAUTION: musb: Babble Interrupt Occurred > > > [ 12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition > > > (a_wait_bcon) > > > [ 12.988498] usb 1-1: USB disconnect, device number 2 > > > [ 13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover > > > from Babble > > > > > > Plugging back our USB cable, with the AM335x acting as a device > > > work once. Then, when it switches to the host mode, we end up with > > > the same scenario than in the coldplug as gadget case: USB read > > > error, before then having all the a_wait_vfall messages. > > > > Guys, any ideas/hints? > > which platform are you using ? I guess the only way to move here would > be to bisect between 3.15 and 3.16 to find the offending commit. 3.15 didn't work either unfortunately. I had the behaviour described above on all kernel between 3.15 and a 4.0-rc1-ish. This is on an custom design based on the am335x. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
Hi, On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote: > On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote: > > Hi, > > > > On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: > > > I have the same experience with 3.15. The switching is working when > > > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16 > > > it seems to be broken. Still had no time to bisect this. > > > > I've been giving a few versions (from v3.15 to Tuesday's linux-next) a > > try, and I always see the same behaviour now: > > > > - Booting as a gadget (ie, with a USB cable plugged in), and > > swapping the cable for a (real, this time) USB OTG cable with a > > USB key never works. When the device is plugged, all I get is > > > > [ 262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc > > [ 278.064748] usb 1-1: device descriptor read/64, error -110 > > > > Putting in back in gadget results with a load of continuous: > > [ 315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall > > while active > > > > - Booting as a host, or with nothing connected to it actually work, > > up to a few plug-a-device-then-plug-a-host cycles, where you end > > up with the following logs when disconnecting the device (somehow, > > it always happens when it is set in host mode). > > > > [ 12.969075] CAUTION: musb: Babble Interrupt Occurred > > [ 12.974445] CAUTION: musb: Babble Interrupt Occurred > > [ 12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition > > (a_wait_bcon) > > [ 12.988498] usb 1-1: USB disconnect, device number 2 > > [ 13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from > > Babble > > > > Plugging back our USB cable, with the AM335x acting as a device > > work once. Then, when it switches to the host mode, we end up with > > the same scenario than in the coldplug as gadget case: USB read > > error, before then having all the a_wait_vfall messages. > > Guys, any ideas/hints? which platform are you using ? I guess the only way to move here would be to bisect between 3.15 and 3.16 to find the offending commit. cheers -- balbi signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote: > Hi, > > On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: > > I have the same experience with 3.15. The switching is working when > > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16 > > it seems to be broken. Still had no time to bisect this. > > I've been giving a few versions (from v3.15 to Tuesday's linux-next) a > try, and I always see the same behaviour now: > > - Booting as a gadget (ie, with a USB cable plugged in), and > swapping the cable for a (real, this time) USB OTG cable with a > USB key never works. When the device is plugged, all I get is > > [ 262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc > [ 278.064748] usb 1-1: device descriptor read/64, error -110 > > Putting in back in gadget results with a load of continuous: > [ 315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall while > active > > - Booting as a host, or with nothing connected to it actually work, > up to a few plug-a-device-then-plug-a-host cycles, where you end > up with the following logs when disconnecting the device (somehow, > it always happens when it is set in host mode). > > [ 12.969075] CAUTION: musb: Babble Interrupt Occurred > [ 12.974445] CAUTION: musb: Babble Interrupt Occurred > [ 12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition > (a_wait_bcon) > [ 12.988498] usb 1-1: USB disconnect, device number 2 > [ 13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from > Babble > > Plugging back our USB cable, with the AM335x acting as a device > work once. Then, when it switches to the host mode, we end up with > the same scenario than in the coldplug as gadget case: USB read > error, before then having all the a_wait_vfall messages. Guys, any ideas/hints? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
Hi, On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: > I have the same experience with 3.15. The switching is working when > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16 > it seems to be broken. Still had no time to bisect this. I've been giving a few versions (from v3.15 to Tuesday's linux-next) a try, and I always see the same behaviour now: - Booting as a gadget (ie, with a USB cable plugged in), and swapping the cable for a (real, this time) USB OTG cable with a USB key never works. When the device is plugged, all I get is [ 262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc [ 278.064748] usb 1-1: device descriptor read/64, error -110 Putting in back in gadget results with a load of continuous: [ 315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active - Booting as a host, or with nothing connected to it actually work, up to a few plug-a-device-then-plug-a-host cycles, where you end up with the following logs when disconnecting the device (somehow, it always happens when it is set in host mode). [ 12.969075] CAUTION: musb: Babble Interrupt Occurred [ 12.974445] CAUTION: musb: Babble Interrupt Occurred [ 12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition (a_wait_bcon) [ 12.988498] usb 1-1: USB disconnect, device number 2 [ 13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from Babble Plugging back our USB cable, with the AM335x acting as a device work once. Then, when it switches to the host mode, we end up with the same scenario than in the coldplug as gadget case: USB read error, before then having all the a_wait_vfall messages. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
Hi, On Thu, Jan 22, 2015 at 8:00 AM, Maxime Ripard wrote: > Hi Markus, > > On Thu, Jan 22, 2015 at 12:01:13PM +0100, Markus Pargmann wrote: >> Hi, >> >> On Thu, Jan 22, 2015 at 11:43:30AM +0100, Maxime Ripard wrote: >> > Hi Yegor, >> > >> > On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: >> > > On 21.01.2015 19:53, Bin Liu wrote: >> > > > Hi, >> > > > >> > > > On Wed, Jan 21, 2015 at 10:06 AM, Maxime Ripard >> > > > wrote: >> > > >> Hi Felipe, >> > > >> >> > > >> I'm currently working on a custom AM335x-based board, that has a OTG >> > > >> connector wired to one of the musb controlers, and Linux 3.17 >> > > >> >> > > >> This OTG connector seems to behave in a weird way when it comes to >> > > >> switching from one role to another: >> > > >> >> > > >> - The host mode works with CONFIG_USB_MUSB_DUAL_ROLE set, only if >> > > >> the dr_mode is set to host in the DT, and only if we plug the USB >> > > >> device after the kernel has booted. Otherwise, even though the >> > > >> controller seems to be set up as host in the kernel logs, it >> > > >> doesn't work. When DR-mode is set to otg, DRVVBUS is not high >> > > >> which surely doesn't help, but there might be some other issues. >> > > >> >> > > >> - The gadget mode works with CONFIG_USB_MUSB_DUAL_ROLE, if dr_mode >> > > >> is set to otg and not host (obviously), and only if we plug the >> > > >> USB cable after the kernel has booted. >> > > >> >> > > >> - The gadget mode works with CONFIG_USB_MUSB_GADGET, and with >> > > >> dr_mode set to otg, even if we cold plug the device. >> > > >> >> > > >> - As you might expect from the two first items, the runtime >> > > >> switching from gadget to host when CONFIG_USB_MUSB_DUAL_ROLE is >> > > >> set and dr_mode is set in otg doesn't work either. >> > > >> >> > > >> It looks like it's only waiting for an interrupt to occur to read the >> > > >> ID pin state, without reading its initial value, which would explain >> > > >> why both the host and gadget enumerate only when a device/cable is >> > > >> hotplugged, and that there's some configuration bits that differ >> > > >> whenever dr_mode changes, but I couldn't really see anything standing >> > > >> out in the driver nor the datasheet. >> > > >> >> > > >> Have you already experienced something alike with that driver? >> > > > >> > > > I don't use vanilla mainline kernel very often, but I don't have such >> > > > hotplug issues with TI 3.12/14 kernels [1]. I only use >> > > > CONFIG_USB_MUSB_DUAL_ROLE though. >> > > > >> > > > [1] git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git, branch >> > > > remote/origin/linux-3.14.y >> > > >> > > I have the same experience with 3.15. The switching is working when >> > > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16 >> > > it seems to be broken. Still had no time to bisect this. >> > >> > I just gave 3.15 a quick try, and it looks like it can now detect when >> > the device is acting as a gadget, but the host mode is not working at >> > all. >> > >> > That's a good lead though, I'll dig more into the older versions and >> > see if some are working better than others. >> >> This issue may be related to the fact that the musb controller does not >> have an ID pin interrupt. Last year I sent a RFC for a soft detection in >> OTG mode. It has a poll loop which toggles the SESSION bit of the >> controller to detect devices as host and drops back to device otherwise. >> This is far away from a good solution. >> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/204519.html > > I guess it was a combination of two issues: after giving your patch a > try, I found out that (even without your patch), in OTG mode, the > gadget device is properly attached even if plugged before the kernel > boots. I don't really know how I missed that, but anyway... > > I also tested to force the ID pin to the ground when a USB device was > plugged in, and it then enumerates properly, both when cold and hot > plugging. It's a bit weird because the adapter I'm using is working > fine on other boards, but maybe the AM335x controller is a bit more > picky with the ID pin, or that the other SoC I was testing it on On the hw side, for AM335x MUSB controller to work in host mode, the ID pin has to be grounded directly or via a resister which is less than 10 Ohms. So, for dr_mode = host, the ID pin is normally grounded directly on the board; for dr_mode = org, a micro-A cable should be used to ensure the ID pin is properly grounded. Regards, -Bin. > (Atmel's sama5d4) is quite relaxed about it. > > I'm guessing that when forced in the host mode, the driver ignores > completely the ID pin, hence why it was working properly with that > setup. > > Thanks a lot, > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in
Re: MUSB dual-role on AM335x behaving weirdly
Hi Markus, On Thu, Jan 22, 2015 at 12:01:13PM +0100, Markus Pargmann wrote: > Hi, > > On Thu, Jan 22, 2015 at 11:43:30AM +0100, Maxime Ripard wrote: > > Hi Yegor, > > > > On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: > > > On 21.01.2015 19:53, Bin Liu wrote: > > > > Hi, > > > > > > > > On Wed, Jan 21, 2015 at 10:06 AM, Maxime Ripard > > > > wrote: > > > >> Hi Felipe, > > > >> > > > >> I'm currently working on a custom AM335x-based board, that has a OTG > > > >> connector wired to one of the musb controlers, and Linux 3.17 > > > >> > > > >> This OTG connector seems to behave in a weird way when it comes to > > > >> switching from one role to another: > > > >> > > > >> - The host mode works with CONFIG_USB_MUSB_DUAL_ROLE set, only if > > > >> the dr_mode is set to host in the DT, and only if we plug the USB > > > >> device after the kernel has booted. Otherwise, even though the > > > >> controller seems to be set up as host in the kernel logs, it > > > >> doesn't work. When DR-mode is set to otg, DRVVBUS is not high > > > >> which surely doesn't help, but there might be some other issues. > > > >> > > > >> - The gadget mode works with CONFIG_USB_MUSB_DUAL_ROLE, if dr_mode > > > >> is set to otg and not host (obviously), and only if we plug the > > > >> USB cable after the kernel has booted. > > > >> > > > >> - The gadget mode works with CONFIG_USB_MUSB_GADGET, and with > > > >> dr_mode set to otg, even if we cold plug the device. > > > >> > > > >> - As you might expect from the two first items, the runtime > > > >> switching from gadget to host when CONFIG_USB_MUSB_DUAL_ROLE is > > > >> set and dr_mode is set in otg doesn't work either. > > > >> > > > >> It looks like it's only waiting for an interrupt to occur to read the > > > >> ID pin state, without reading its initial value, which would explain > > > >> why both the host and gadget enumerate only when a device/cable is > > > >> hotplugged, and that there's some configuration bits that differ > > > >> whenever dr_mode changes, but I couldn't really see anything standing > > > >> out in the driver nor the datasheet. > > > >> > > > >> Have you already experienced something alike with that driver? > > > > > > > > I don't use vanilla mainline kernel very often, but I don't have such > > > > hotplug issues with TI 3.12/14 kernels [1]. I only use > > > > CONFIG_USB_MUSB_DUAL_ROLE though. > > > > > > > > [1] git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git, branch > > > > remote/origin/linux-3.14.y > > > > > > I have the same experience with 3.15. The switching is working when > > > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16 > > > it seems to be broken. Still had no time to bisect this. > > > > I just gave 3.15 a quick try, and it looks like it can now detect when > > the device is acting as a gadget, but the host mode is not working at > > all. > > > > That's a good lead though, I'll dig more into the older versions and > > see if some are working better than others. > > This issue may be related to the fact that the musb controller does not > have an ID pin interrupt. Last year I sent a RFC for a soft detection in > OTG mode. It has a poll loop which toggles the SESSION bit of the > controller to detect devices as host and drops back to device otherwise. > This is far away from a good solution. > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/204519.html I guess it was a combination of two issues: after giving your patch a try, I found out that (even without your patch), in OTG mode, the gadget device is properly attached even if plugged before the kernel boots. I don't really know how I missed that, but anyway... I also tested to force the ID pin to the ground when a USB device was plugged in, and it then enumerates properly, both when cold and hot plugging. It's a bit weird because the adapter I'm using is working fine on other boards, but maybe the AM335x controller is a bit more picky with the ID pin, or that the other SoC I was testing it on (Atmel's sama5d4) is quite relaxed about it. I'm guessing that when forced in the host mode, the driver ignores completely the ID pin, hence why it was working properly with that setup. Thanks a lot, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
Hi, On Thu, Jan 22, 2015 at 11:43:30AM +0100, Maxime Ripard wrote: > Hi Yegor, > > On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: > > On 21.01.2015 19:53, Bin Liu wrote: > > > Hi, > > > > > > On Wed, Jan 21, 2015 at 10:06 AM, Maxime Ripard > > > wrote: > > >> Hi Felipe, > > >> > > >> I'm currently working on a custom AM335x-based board, that has a OTG > > >> connector wired to one of the musb controlers, and Linux 3.17 > > >> > > >> This OTG connector seems to behave in a weird way when it comes to > > >> switching from one role to another: > > >> > > >> - The host mode works with CONFIG_USB_MUSB_DUAL_ROLE set, only if > > >> the dr_mode is set to host in the DT, and only if we plug the USB > > >> device after the kernel has booted. Otherwise, even though the > > >> controller seems to be set up as host in the kernel logs, it > > >> doesn't work. When DR-mode is set to otg, DRVVBUS is not high > > >> which surely doesn't help, but there might be some other issues. > > >> > > >> - The gadget mode works with CONFIG_USB_MUSB_DUAL_ROLE, if dr_mode > > >> is set to otg and not host (obviously), and only if we plug the > > >> USB cable after the kernel has booted. > > >> > > >> - The gadget mode works with CONFIG_USB_MUSB_GADGET, and with > > >> dr_mode set to otg, even if we cold plug the device. > > >> > > >> - As you might expect from the two first items, the runtime > > >> switching from gadget to host when CONFIG_USB_MUSB_DUAL_ROLE is > > >> set and dr_mode is set in otg doesn't work either. > > >> > > >> It looks like it's only waiting for an interrupt to occur to read the > > >> ID pin state, without reading its initial value, which would explain > > >> why both the host and gadget enumerate only when a device/cable is > > >> hotplugged, and that there's some configuration bits that differ > > >> whenever dr_mode changes, but I couldn't really see anything standing > > >> out in the driver nor the datasheet. > > >> > > >> Have you already experienced something alike with that driver? > > > > > > I don't use vanilla mainline kernel very often, but I don't have such > > > hotplug issues with TI 3.12/14 kernels [1]. I only use > > > CONFIG_USB_MUSB_DUAL_ROLE though. > > > > > > [1] git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git, branch > > > remote/origin/linux-3.14.y > > > > I have the same experience with 3.15. The switching is working when > > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16 > > it seems to be broken. Still had no time to bisect this. > > I just gave 3.15 a quick try, and it looks like it can now detect when > the device is acting as a gadget, but the host mode is not working at > all. > > That's a good lead though, I'll dig more into the older versions and > see if some are working better than others. This issue may be related to the fact that the musb controller does not have an ID pin interrupt. Last year I sent a RFC for a soft detection in OTG mode. It has a poll loop which toggles the SESSION bit of the controller to detect devices as host and drops back to device otherwise. This is far away from a good solution. http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/204519.html Best Regards, Markus -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
Hi Yegor, On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: > On 21.01.2015 19:53, Bin Liu wrote: > > Hi, > > > > On Wed, Jan 21, 2015 at 10:06 AM, Maxime Ripard > > wrote: > >> Hi Felipe, > >> > >> I'm currently working on a custom AM335x-based board, that has a OTG > >> connector wired to one of the musb controlers, and Linux 3.17 > >> > >> This OTG connector seems to behave in a weird way when it comes to > >> switching from one role to another: > >> > >> - The host mode works with CONFIG_USB_MUSB_DUAL_ROLE set, only if > >> the dr_mode is set to host in the DT, and only if we plug the USB > >> device after the kernel has booted. Otherwise, even though the > >> controller seems to be set up as host in the kernel logs, it > >> doesn't work. When DR-mode is set to otg, DRVVBUS is not high > >> which surely doesn't help, but there might be some other issues. > >> > >> - The gadget mode works with CONFIG_USB_MUSB_DUAL_ROLE, if dr_mode > >> is set to otg and not host (obviously), and only if we plug the > >> USB cable after the kernel has booted. > >> > >> - The gadget mode works with CONFIG_USB_MUSB_GADGET, and with > >> dr_mode set to otg, even if we cold plug the device. > >> > >> - As you might expect from the two first items, the runtime > >> switching from gadget to host when CONFIG_USB_MUSB_DUAL_ROLE is > >> set and dr_mode is set in otg doesn't work either. > >> > >> It looks like it's only waiting for an interrupt to occur to read the > >> ID pin state, without reading its initial value, which would explain > >> why both the host and gadget enumerate only when a device/cable is > >> hotplugged, and that there's some configuration bits that differ > >> whenever dr_mode changes, but I couldn't really see anything standing > >> out in the driver nor the datasheet. > >> > >> Have you already experienced something alike with that driver? > > > > I don't use vanilla mainline kernel very often, but I don't have such > > hotplug issues with TI 3.12/14 kernels [1]. I only use > > CONFIG_USB_MUSB_DUAL_ROLE though. > > > > [1] git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git, branch > > remote/origin/linux-3.14.y > > I have the same experience with 3.15. The switching is working when > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16 > it seems to be broken. Still had no time to bisect this. I just gave 3.15 a quick try, and it looks like it can now detect when the device is acting as a gadget, but the host mode is not working at all. That's a good lead though, I'll dig more into the older versions and see if some are working better than others. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
On 21.01.2015 19:53, Bin Liu wrote: > Hi, > > On Wed, Jan 21, 2015 at 10:06 AM, Maxime Ripard > wrote: >> Hi Felipe, >> >> I'm currently working on a custom AM335x-based board, that has a OTG >> connector wired to one of the musb controlers, and Linux 3.17 >> >> This OTG connector seems to behave in a weird way when it comes to >> switching from one role to another: >> >> - The host mode works with CONFIG_USB_MUSB_DUAL_ROLE set, only if >> the dr_mode is set to host in the DT, and only if we plug the USB >> device after the kernel has booted. Otherwise, even though the >> controller seems to be set up as host in the kernel logs, it >> doesn't work. When DR-mode is set to otg, DRVVBUS is not high >> which surely doesn't help, but there might be some other issues. >> >> - The gadget mode works with CONFIG_USB_MUSB_DUAL_ROLE, if dr_mode >> is set to otg and not host (obviously), and only if we plug the >> USB cable after the kernel has booted. >> >> - The gadget mode works with CONFIG_USB_MUSB_GADGET, and with >> dr_mode set to otg, even if we cold plug the device. >> >> - As you might expect from the two first items, the runtime >> switching from gadget to host when CONFIG_USB_MUSB_DUAL_ROLE is >> set and dr_mode is set in otg doesn't work either. >> >> It looks like it's only waiting for an interrupt to occur to read the >> ID pin state, without reading its initial value, which would explain >> why both the host and gadget enumerate only when a device/cable is >> hotplugged, and that there's some configuration bits that differ >> whenever dr_mode changes, but I couldn't really see anything standing >> out in the driver nor the datasheet. >> >> Have you already experienced something alike with that driver? > > I don't use vanilla mainline kernel very often, but I don't have such > hotplug issues with TI 3.12/14 kernels [1]. I only use > CONFIG_USB_MUSB_DUAL_ROLE though. > > [1] git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git, branch > remote/origin/linux-3.14.y I have the same experience with 3.15. The switching is working when CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16 it seems to be broken. Still had no time to bisect this. Yegor -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MUSB dual-role on AM335x behaving weirdly
Hi, On Wed, Jan 21, 2015 at 10:06 AM, Maxime Ripard wrote: > Hi Felipe, > > I'm currently working on a custom AM335x-based board, that has a OTG > connector wired to one of the musb controlers, and Linux 3.17 > > This OTG connector seems to behave in a weird way when it comes to > switching from one role to another: > > - The host mode works with CONFIG_USB_MUSB_DUAL_ROLE set, only if > the dr_mode is set to host in the DT, and only if we plug the USB > device after the kernel has booted. Otherwise, even though the > controller seems to be set up as host in the kernel logs, it > doesn't work. When DR-mode is set to otg, DRVVBUS is not high > which surely doesn't help, but there might be some other issues. > > - The gadget mode works with CONFIG_USB_MUSB_DUAL_ROLE, if dr_mode > is set to otg and not host (obviously), and only if we plug the > USB cable after the kernel has booted. > > - The gadget mode works with CONFIG_USB_MUSB_GADGET, and with > dr_mode set to otg, even if we cold plug the device. > > - As you might expect from the two first items, the runtime > switching from gadget to host when CONFIG_USB_MUSB_DUAL_ROLE is > set and dr_mode is set in otg doesn't work either. > > It looks like it's only waiting for an interrupt to occur to read the > ID pin state, without reading its initial value, which would explain > why both the host and gadget enumerate only when a device/cable is > hotplugged, and that there's some configuration bits that differ > whenever dr_mode changes, but I couldn't really see anything standing > out in the driver nor the datasheet. > > Have you already experienced something alike with that driver? I don't use vanilla mainline kernel very often, but I don't have such hotplug issues with TI 3.12/14 kernels [1]. I only use CONFIG_USB_MUSB_DUAL_ROLE though. [1] git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git, branch remote/origin/linux-3.14.y Regards, -Bin. > > Thanks, > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
MUSB dual-role on AM335x behaving weirdly
Hi Felipe, I'm currently working on a custom AM335x-based board, that has a OTG connector wired to one of the musb controlers, and Linux 3.17 This OTG connector seems to behave in a weird way when it comes to switching from one role to another: - The host mode works with CONFIG_USB_MUSB_DUAL_ROLE set, only if the dr_mode is set to host in the DT, and only if we plug the USB device after the kernel has booted. Otherwise, even though the controller seems to be set up as host in the kernel logs, it doesn't work. When DR-mode is set to otg, DRVVBUS is not high which surely doesn't help, but there might be some other issues. - The gadget mode works with CONFIG_USB_MUSB_DUAL_ROLE, if dr_mode is set to otg and not host (obviously), and only if we plug the USB cable after the kernel has booted. - The gadget mode works with CONFIG_USB_MUSB_GADGET, and with dr_mode set to otg, even if we cold plug the device. - As you might expect from the two first items, the runtime switching from gadget to host when CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode is set in otg doesn't work either. It looks like it's only waiting for an interrupt to occur to read the ID pin state, without reading its initial value, which would explain why both the host and gadget enumerate only when a device/cable is hotplugged, and that there's some configuration bits that differ whenever dr_mode changes, but I couldn't really see anything standing out in the driver nor the datasheet. Have you already experienced something alike with that driver? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
