From: balbi@ti•com (Felipe Balbi)
To: linux-arm-kernel@lists•infradead.org
Subject: MUSB dual-role on AM335x behaving weirdly
Date: Thu, 20 Aug 2015 11:46:56 -0500 [thread overview]
Message-ID: <20150820164656.GA4938@saruman.tx.rr.com> (raw)
In-Reply-To: <55D601C5.40608@free-electrons.com>
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
> >>>>>> <gregory.clement@free-electrons•com> 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
> >>>>>>>>>> <alexandre.belloni@free-electrons•com> 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
> 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.
all right. Seems like we really need to turn some of those states
handling into a reusable (musb-specific) library.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150820/dcebba1f/attachment.sig>
next prev parent reply other threads:[~2015-08-20 16:46 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-21 16:06 MUSB dual-role on AM335x behaving weirdly Maxime Ripard
2015-01-21 18:53 ` Bin Liu
2015-01-22 7:37 ` Yegor Yefremov
2015-01-22 10:43 ` Maxime Ripard
2015-01-22 11:01 ` Markus Pargmann
2015-01-22 14:00 ` Maxime Ripard
2015-01-22 14:52 ` Bin Liu
2015-02-05 13:21 ` Maxime Ripard
2015-02-24 10:39 ` Maxime Ripard
2015-02-24 14:54 ` Felipe Balbi
2015-02-24 16:50 ` Maxime Ripard
2015-02-24 17:33 ` Felipe Balbi
2015-02-25 11:11 ` Maxime Ripard
2015-02-25 12:11 ` Yegor Yefremov
2015-05-14 17:07 ` Felipe Balbi
2015-05-14 17:40 ` Felipe Balbi
2015-05-14 17:49 ` Felipe Balbi
2015-05-14 19:04 ` Felipe Balbi
2015-05-14 19:19 ` Bin Liu
2015-05-14 19:21 ` Felipe Balbi
2015-05-14 19:29 ` Bin Liu
2015-05-14 19:29 ` Felipe Balbi
2015-05-14 19:49 ` Felipe Balbi
2015-05-14 20:03 ` Bin Liu
2015-05-14 20:10 ` Felipe Balbi
2015-05-14 21:04 ` Bin Liu
2015-05-14 21:16 ` Bin Liu
2015-05-14 21:26 ` Alexandre Belloni
2015-05-14 21:36 ` Bin Liu
2015-05-26 14:51 ` Felipe Balbi
2015-05-27 9:42 ` Alexandre Belloni
2015-07-02 7:16 ` Gregory CLEMENT
2015-07-02 17:05 ` Bin Liu
2015-08-04 13:08 ` Gregory CLEMENT
2015-08-04 14:23 ` Gregory CLEMENT
2015-08-04 19:32 ` Felipe Balbi
2015-08-18 12:36 ` Gregory CLEMENT
2015-08-18 14:13 ` Felipe Balbi
2015-08-20 16:35 ` Gregory CLEMENT
2015-08-20 16:46 ` Felipe Balbi [this message]
2015-08-21 12:19 ` Gregory CLEMENT
2015-04-14 15:46 ` Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150820164656.GA4938@saruman.tx.rr.com \
--to=balbi@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox