All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Felipe Balbi <balbi@ti.com>
Cc: linux-usb@vger.kernel.org, linux-omap@vger.kernel.org,
	Grazvydas Ignotas <notasas@gmail.com>,
	Kishon Vijay Abraham I <kishon@ti.com>
Subject: Re: usb: musb: Fix LapDock enumeration on omap for boot and slow cable insertion
Date: Thu, 16 May 2013 10:15:20 -0700	[thread overview]
Message-ID: <20130516171520.GZ5600@atomide.com> (raw)
In-Reply-To: <20130515140537.GC26183@arwen.pp.htv.fi>

* Felipe Balbi <balbi@ti.com> [130515 07:11]:
> On Fri, May 03, 2013 at 11:01:33AM -0700, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [130503 10:55]:
> > > Looks like we can get VBUS interrupt before the ID interrupt
> 
> how can this happen ? VBUS interrupt happens when you connect to a port
> which is sourcing VBUS to you, while ID interrupt happens when ID is
> grounded, meaning that you should be sourcing VBUS.

Yes, in this case we get both interrupts and the order depends
on how fast/slow the cable is inserted.
 
> Have you hacked a Hub to backfeed 5V to OMAP by any chance ?

..as that's how the LapDock seems to behave backfeeding 5V.

It would be interesting to take a look at the signaling on it,
but I think my old beagle sniffer is fried.

Looking at the "Figure 6-1: Common State Diagram" on page 32 in
"USB_OTG_and_EH_3-0_release_1_1_10May2012.pdf" the logic is the
following depending on the order of interrupt:

start -> id ground -> a_idle -> a_wait_vrise -> a_wait_bcon...

or

start -> vbus -> b_idle -> id ground -> a_idle -> a_wait_vrise ->
a_wait_bcon...

I don't think having the VBUS there actually violates that if
we just should follow the ID state and accept that a_wait_vrise
is already satisfied and not even try to turn the VBUS at MUSB
end in that case.

Regards,

Tony

      reply	other threads:[~2013-05-16 17:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-03 17:50 usb: musb: Fix LapDock enumeration on omap for boot and slow cable insertion Tony Lindgren
2013-05-03 18:01 ` Tony Lindgren
     [not found]   ` <20130503180132.GW28721-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2013-05-15 14:05     ` Felipe Balbi
2013-05-16 17:15       ` Tony Lindgren [this message]

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=20130516171520.GZ5600@atomide.com \
    --to=tony@atomide.com \
    --cc=balbi@ti.com \
    --cc=kishon@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=notasas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.