RE: OMAP3430: MUSB host and hot-plugging

RE: OMAP3430: MUSB host and hot-plugging

[Felipe Balbi]

> Using the default config omap_3430sdp_defconig, I'm doing some basic
> hot-plug tests of MUSB in host mode.
> 
> I noticed that after booting, the first time I connect my USB key, it
> is detected just fine, the usb/scsi storage modulesare loaded by
> hotplug and I can access the device just fine.
> 
> I then remove the key, and the kernel seems to detect the removal just
> fine, and does what seems to be a clean shutdown.
> 
> However, if I then plug the key back in, nothing happens.  
> 
> Forcing a session start via "echo 'F' > /proc/driver/musb_hdrc" causes
> the device to be (re)detected and things look good again.  It is not
> until I force the session start that I see the interrupt and the
> CONNECT event.
> 
> Any ideas why this isn't detected on insertion?

You're better than me then, I can't get even the first insertion
right.

What I'm suspecting is that we do get the insertion but twl4030
do not notify musb about id pin status through ULPI.

You can check that cuz you still in b_idle state even though
you have a mini-A connector attached to it. Also, if you put a
printk in the irq handler (on twl4030-usb.c) you can see it
gets called after attaching the cable.

And there's one other trick, after switching to host role,
you see that you're in a_host from /sys/devices/platform/musb_hdrc.0/mode,
if you remove the cable (mini-A) and attach it again right
after that, before musb_do_idle put musb in b_idle again,
you get the usb stick recognized and musb_core goes back
to a_host from a_wait_bcon state.

I'm suspecting that twl4030_phy_suspend is somehow
messing it up. I'm now digging on it and still
I can't say for sure what's happening.

Maybe somebody else has other comments on that.

-- 
Best Regards,

Felipe Balbi
http://felipebalbi.com
me@felipebalbi.com

RE: OMAP3430: MUSB host and hot-plugging

[Pandita, Vikram]

Hi Felipe/Kevin

>To: Kevin Hilman; Linux omap
>Subject: RE: OMAP3430: MUSB host and hot-plugging
>
>> Forcing a session start via "echo 'F' > /proc/driver/musb_hdrc" causes
>> the device to be (re)detected and things look good again.  It is not
>> until I force the session start that I see the interrupt and the
>> CONNECT event.
>>
>> Any ideas why this isn't detected on insertion?
>
>You're better than me then, I can't get even the first insertion
>I'm suspecting that twl4030_phy_suspend is somehow
>messing it up. I'm now digging on it and still
>I can't say for sure what's happening.
>
>Maybe somebody else has other comments on that.

If you can provide us the procedure to enable hot-plugging for MUSB on OMAP3430, we will look into this issue.


>
>--
>Best Regards,
>
>Felipe Balbi
>http://felipebalbi.com
>me@felipebalbi.com
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: OMAP3430: MUSB host and hot-plugging

[Felipe Balbi]

On Thu, 20 Mar 2008 18:04:01 +0530, "Pandita, Vikram"
<vikram.pandita@ti.com> wrote:
> Hi Felipe/Kevin
> 
>>To: Kevin Hilman; Linux omap
>>Subject: RE: OMAP3430: MUSB host and hot-plugging
>>
>>> Forcing a session start via "echo 'F' > /proc/driver/musb_hdrc" causes
>>> the device to be (re)detected and things look good again.  It is not
>>> until I force the session start that I see the interrupt and the
>>> CONNECT event.
>>>
>>> Any ideas why this isn't detected on insertion?
>>
>>You're better than me then, I can't get even the first insertion
>>I'm suspecting that twl4030_phy_suspend is somehow
>>messing it up. I'm now digging on it and still
>>I can't say for sure what's happening.
>>
>>Maybe somebody else has other comments on that.
> 
> If you can provide us the procedure to enable hot-plugging for MUSB on
> OMAP3430, we will look into this issue.

As far as musb driver is concerned it should be just a mater of
building it with otg support. But as of now, I cannot get id
pin status to musb using twl4030.

Maybe we still have some missing pieces on linux-omap, which I'm
researching on that.

-- 
Best Regards,

Felipe Balbi
http://felipebalbi.com
me@felipebalbi.com

RE: OMAP3430: MUSB host and hot-plugging

[Pandita, Vikram]

Felipe

>Sent: Thursday, March 20, 2008 6:09 PM
>To: Pandita, Vikram
>Cc: Kevin Hilman; Linux omap
>Subject: RE: OMAP3430: MUSB host and hot-plugging
>
>
>> If you can provide us the procedure to enable hot-plugging for MUSB on
>> OMAP3430, we will look into this issue.
>
>As far as musb driver is concerned it should be just a mater of
>building it with otg support. But as of now, I cannot get id
>pin status to musb using twl4030.
>
>Maybe we still have some missing pieces on linux-omap, which I'm
>researching on that.

 I meant if you could pass on how you have written the hot plugging function/agent for MUSB.
I have not tried hot-plugging on omap. 

>
>--
>Best Regards,
>
>Felipe Balbi
>http://felipebalbi.com
>me@felipebalbi.com
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: OMAP3430: MUSB host and hot-plugging

[Felipe Balbi]

On Thu, 20 Mar 2008 18:17:55 +0530, "Pandita, Vikram"
<vikram.pandita@ti.com> wrote:
> Felipe
> 
>>Sent: Thursday, March 20, 2008 6:09 PM
>>To: Pandita, Vikram
>>Cc: Kevin Hilman; Linux omap
>>Subject: RE: OMAP3430: MUSB host and hot-plugging
>>
>>
>>> If you can provide us the procedure to enable hot-plugging for MUSB on
>>> OMAP3430, we will look into this issue.
>>
>>As far as musb driver is concerned it should be just a mater of
>>building it with otg support. But as of now, I cannot get id
>>pin status to musb using twl4030.
>>
>>Maybe we still have some missing pieces on linux-omap, which I'm
>>researching on that.
> 
>  I meant if you could pass on how you have written the hot plugging
> function/agent for MUSB.
> I have not tried hot-plugging on omap. 

There should be no need for that.
twl4030-usb is using ulpi interface on 3430sdp, which means all interrupts
are
directed to musb using that interface, also musb switches between
host/peripheral
roles automatically as long as we get an id pin change interrupt.

Somehow this interrupt is not going to musb's driver when we're using ulpi
on 3430.

I have some other questions for you but it'll be privatly.

> 
>>
>>--
>>Best Regards,
>>
>>Felipe Balbi
>>http://felipebalbi.com
>>me@felipebalbi.com
>>
>>--
>>To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
-- 
Best Regards,

Felipe Balbi
http://felipebalbi.com
me@felipebalbi.com

Re: OMAP3430: MUSB host and hot-plugging

[Kevin Hilman]

"Pandita, Vikram" <vikram.pandita@ti.com> writes:

> Felipe
>
>>Sent: Thursday, March 20, 2008 6:09 PM
>>To: Pandita, Vikram
>>Cc: Kevin Hilman; Linux omap
>>Subject: RE: OMAP3430: MUSB host and hot-plugging
>>
>>
>>> If you can provide us the procedure to enable hot-plugging for MUSB on
>>> OMAP3430, we will look into this issue.
>>
>>As far as musb driver is concerned it should be just a mater of
>>building it with otg support. But as of now, I cannot get id
>>pin status to musb using twl4030.
>>
>>Maybe we still have some missing pieces on linux-omap, which I'm
>>researching on that.
>
>
>  I meant if you could pass on how you have written the hot plugging
> function/agent for MUSB.  I have not tried hot-plugging on omap.

There's no additional code.  You can reproduce this with current OMAP
git, and default omap_3430sdp_defconfig, which enables MUSB in OTG
mode.

Here's what I do:

- plug in cable (mini-A to A-female)
- boot
- after booting, plug in USB storage device.
  on my userland, hotplug does its thing, and the usb/scsi storage modules
  are loaded, and I can then access /dev/sda* 
- unplug USB key.
  kernel msgs show the disconnect happens etc.

- replug USB key --- nothing happens

- echo 'F' > /proc/driver/musb_hdrc

  USB key is detected and 'CONNECT' event happens, and I can then
  access /dev/sda* again.


Kevin

Re: OMAP3430: MUSB host and hot-plugging

[Felipe Balbi]

On Thu, Mar 20, 2008 at 10:11:03AM -0700, Kevin Hilman wrote:
> "Pandita, Vikram" <vikram.pandita@ti.com> writes:
> 
> > Felipe
> >
> >>Sent: Thursday, March 20, 2008 6:09 PM
> >>To: Pandita, Vikram
> >>Cc: Kevin Hilman; Linux omap
> >>Subject: RE: OMAP3430: MUSB host and hot-plugging
> >>
> >>
> >>> If you can provide us the procedure to enable hot-plugging for MUSB on
> >>> OMAP3430, we will look into this issue.
> >>
> >>As far as musb driver is concerned it should be just a mater of
> >>building it with otg support. But as of now, I cannot get id
> >>pin status to musb using twl4030.
> >>
> >>Maybe we still have some missing pieces on linux-omap, which I'm
> >>researching on that.
> >
> >
> >  I meant if you could pass on how you have written the hot plugging
> > function/agent for MUSB.  I have not tried hot-plugging on omap.
> 
> There's no additional code.  You can reproduce this with current OMAP
> git, and default omap_3430sdp_defconfig, which enables MUSB in OTG
> mode.
> 
> Here's what I do:
> 
> - plug in cable (mini-A to A-female)
> - boot
> - after booting, plug in USB storage device.
>   on my userland, hotplug does its thing, and the usb/scsi storage modules
>   are loaded, and I can then access /dev/sda* 
> - unplug USB key.
>   kernel msgs show the disconnect happens etc.
> 
> - replug USB key --- nothing happens

Same here. Although if you unplug and replug right away, it'll work.
That's because musb was still waiting in a_wait_bcon state and I didn't
let it fall into b_idle.

That's why I'm suspecting on twl4030_phy_{suspend,resume}() routines.
After reading twl4030's docs I couldn't find anything suspicious on the
code but I'll dig more tomorrow and after the holidays.

-- 
Best Regards,

Felipe Balbi
me@felipebalbi.com
http://blog.felipebalbi.com

OMAP3430: MUSB host and hot-plugging

[Kevin Hilman]

Using the default config omap_3430sdp_defconig, I'm doing some basic
hot-plug tests of MUSB in host mode.

I noticed that after booting, the first time I connect my USB key, it
is detected just fine, the usb/scsi storage modulesare loaded by
hotplug and I can access the device just fine.

I then remove the key, and the kernel seems to detect the removal just
fine, and does what seems to be a clean shutdown.

However, if I then plug the key back in, nothing happens.  

Forcing a session start via "echo 'F' > /proc/driver/musb_hdrc" causes
the device to be (re)detected and things look good again.  It is not
until I force the session start that I see the interrupt and the
CONNECT event.

Any ideas why this isn't detected on insertion?

Thanks,

Kevin

Re: OMAP3430: MUSB host and hot-plugging

[David Brownell]

On Wednesday 19 March 2008, Kevin Hilman wrote:

> However, if I then plug the key back in, nothing happens.  
> 
> Forcing a session start via "echo 'F' > /proc/driver/musb_hdrc" causes
> the device to be (re)detected and things look good again.  It is not
> until I force the session start that I see the interrupt and the
> CONNECT event.
> 
> Any ideas why this isn't detected on insertion?

Just for the record ... that's always been a problem.  There's
some strange side-effect driven magic in the Mentor IP, right
in that area, which has always been fragile.

For example, it seems to think something other than the state
of the ID pin should control whether it's in the A-side state
machine (default host) or the B-side one (default peripheral),
and it gets fairly twitchey about VBUS levels too ... as in,
it doesn't allow the specified 100 msec for it to stabilize,
and enters a fault/shutdown mode if voltage drops because of,
say, contact bounce or inrush current, while it stabilizes.

Needing that "force session start" is a warning flag.  The
very notion of that kind of "session" is something introduced
by Mentor, which is not part of the OTG spec (at least, not in
anything like that form).  Multiple weeks have been wasted
trying to sort out misbehavior in that area, and there seem
to be revision-specific issues too.

- Dave

Re: OMAP3430: MUSB host and hot-plugging

[Felipe Balbi]

On Thu, Mar 20, 2008 at 12:30:03PM -0700, David Brownell wrote:
> On Wednesday 19 March 2008, Kevin Hilman wrote:
> 
> > However, if I then plug the key back in, nothing happens.  
> > 
> > Forcing a session start via "echo 'F' > /proc/driver/musb_hdrc" causes
> > the device to be (re)detected and things look good again.  It is not
> > until I force the session start that I see the interrupt and the
> > CONNECT event.
> > 
> > Any ideas why this isn't detected on insertion?
> 
> Just for the record ... that's always been a problem.  There's
> some strange side-effect driven magic in the Mentor IP, right
> in that area, which has always been fragile.
> 
> For example, it seems to think something other than the state
> of the ID pin should control whether it's in the A-side state
> machine (default host) or the B-side one (default peripheral),
> and it gets fairly twitchey about VBUS levels too ... as in,
> it doesn't allow the specified 100 msec for it to stabilize,
> and enters a fault/shutdown mode if voltage drops because of,
> say, contact bounce or inrush current, while it stabilizes.
> 
> Needing that "force session start" is a warning flag.  The
> very notion of that kind of "session" is something introduced
> by Mentor, which is not part of the OTG spec (at least, not in
> anything like that form).  Multiple weeks have been wasted
> trying to sort out misbehavior in that area, and there seem
> to be revision-specific issues too.

Looks like code is flakey again after merging usb stuff with mainline
then?

But I tried with n800/n810 and it's working fine, this surely means the
problem resides either in drivers/usb/musb/omap2430.c or
driver/i2c/chips/twl4030-usb.c

I'm more into some flakeyness in omap2430.c as it looks like
twl4030-usb.c generates the cable insertion interrupt. Could it be some
problem in the ULPI support for omap3 that's preventing musb to wake up
and switch to host role ? Maybe we're not getting wakeup events e.g.
cable insertion interrupt is not waking up Mentor IP Core ?

Well, these still some thoughts I still need to debug more in order to
really understand the problem there.

-- 
Best Regards,

Felipe Balbi
me@felipebalbi.com
http://blog.felipebalbi.com

Re: OMAP3430: MUSB host and hot-plugging

[David Brownell]

On Thursday 20 March 2008, Felipe Balbi wrote:
> Could it be some
> problem in the ULPI support for omap3 that's preventing musb to wake up
> and switch to host role ?

Your theory is as good as mine; I don't have that hardware.

I was just pointing out that this specific area has always
been a significant PITA for the MUSB silicon ... I'm not the
only developer who's ended up losing weeks of time chasing
(undocumented) bogosity in the area of host-side startup.

The thing is that making it "switch to host role" is the
very black magic that regularly misbehaved.  ISTR there was
a chicken/egg thing going on:  it couldn't know it needed to
switch to "host role" unless the oddball Mentor "session"
was already active, but it couldn't be activated unless you
somehow knew it should be in host role...

Re: OMAP3430: MUSB host and hot-plugging

[Felipe Balbi]

On Thu, Mar 20, 2008 at 01:25:28PM -0700, David Brownell wrote:
> On Thursday 20 March 2008, Felipe Balbi wrote:
> > Could it be some
> > problem in the ULPI support for omap3 that's preventing musb to wake up
> > and switch to host role ?
> 
> Your theory is as good as mine; I don't have that hardware.
> 
> I was just pointing out that this specific area has always
> been a significant PITA for the MUSB silicon ... I'm not the
> only developer who's ended up losing weeks of time chasing
> (undocumented) bogosity in the area of host-side startup.
> 
> The thing is that making it "switch to host role" is the
> very black magic that regularly misbehaved.  ISTR there was
> a chicken/egg thing going on:  it couldn't know it needed to
> switch to "host role" unless the oddball Mentor "session"
> was already active, but it couldn't be activated unless you
> somehow knew it should be in host role...

Hmm... thanks for the tips Dave, I'll re-check that programmers guide
again tomorrow and try to debug a bit more.

-- 
Best Regards,

Felipe Balbi
me@felipebalbi.com
http://blog.felipebalbi.com

RE: OMAP3430: MUSB host and hot-plugging

[Pandita, Vikram]

>Sent: Friday, March 21, 2008 1:55 AM
>On Thursday 20 March 2008, Felipe Balbi wrote:
>> Could it be some
>> problem in the ULPI support for omap3 that's preventing musb to wake up
>> and switch to host role ?
>
>Your theory is as good as mine; I don't have that hardware.
>
>I was just pointing out that this specific area has always
>been a significant PITA for the MUSB silicon ... I'm not the
>only developer who's ended up losing weeks of time chasing
>(undocumented) bogosity in the area of host-side startup.
>
>The thing is that making it "switch to host role" is the
>very black magic that regularly misbehaved.  ISTR there was
>a chicken/egg thing going on:  it couldn't know it needed to
>switch to "host role" unless the oddball Mentor "session"
>was already active, but it couldn't be activated unless you
>somehow knew it should be in host role...

The right way then to debug would be to do an LA probe of ULPI signals on re-attach.
To get around this problem, I have heard of implementations having a separate GPIO implemented to wakeup the system on cable attaches. Don't remember which implementation though.
I will see if I get time to work on this and will keep posted.

>
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html