On Wednesday 22 April 2009, yao yong wrote:
> Hi, David,
>
> When you start the HNP, did you call the function -- usb_bus_start_enum?
Grepping the latest iteration of the code reports "no".
The B_HOST calls usb_hcd_resume_root_hub() ... there's
another option (polling root hub status) but a quick
scan of debug traces suggests not. I think that'd be
just from the A_HOST state.
I seem to recall code avoiding a needless *initial* reset
of that port, perhaps in usbcore, but my mind hasn't gotten
twisted around those code sequences for a few weeks now.
> As you know, usb_bus_start_enum will reset the port. and according to
> OHCI port,
Yes, and that function was added for an OTG stack which
used OHCI. Without thinking a *bunch* more about it, I
can't quite say whether this is only a case of the MUSB
code not needing that ... or whether it's part of the
fact that its HNP code hasn't passed all the tests yet.
Or whether this is an area where the USB stack has
changed enough since 2.6.10 that it no longer needs
that function.
The only *sure* answer is for me to unbox a specific
old dev board and see how that's behaving lately. If
I do that, I'm pretty sure to lose a bunch of days
fixing other issues first, before I could test it; sigh.
> if reset the port, USB_PORT_STAT_ENABLE will be set.
I'm fairly sure I didn't have to reset to achieve that.
You might not need to either ... remember there are some
timing constraints, which might not jive with a reset.
> so when we go into the following code,
>
> if ((portstatus & USB_PORT_STAT_ENABLE) && (
> type != HUB_RESUME ||
> !(portstatus & USB_PORT_STAT_CONNECTION) ||
> !udev ||
> udev->state == USB_STATE_NOTATTACHED)) {
> clear_port_feature(hdev, port1, USB_PORT_FEAT_ENABLE)
> portstatus &= ~USB_PORT_STAT_ENABLE;
> }
That's in hub_activate(). I notice that the comment above
says the disable shouldn't happen on a resume ... which
suggests that maybe usbcore changes here have affected these
code paths.
> the condition will be satisified, so we will call the
> clear_port_feature(hdev, port1, USB_PORT_FEAT_ENABLE). Then it will
> cause the port disconnected. Then OTG statemachine will be changed
> from B_HOST to B_PERIPHERAL.
Which is clearly the wrong thing. Does it work better if
you resume the root hub when
- Dave
p.s. Are you working on HNP for PXA-270 or PXA-3XX? I'm
just guessing; and would be shoked cif Marvell doesn't
have other Linux-capable OTG platforms by now!
> Regards
> Yong
>
> 2009/4/17 David Brownell <david-b@xxxxxxxxxxx>:
> > On Thursday 16 April 2009, Eric Miao wrote:
> >> > But I'm not entirely sure this patch is correct. Does this affect
> >> > some of the OTG conformance tests? I've certainly observed HNP
> >> > to proceed through b_host enumerating an a_peripheral (after the
> >> > role switch) with the current code.
> >> >
> >> > Of course, the fact that I've seen it work *could* be caused by
> >> > bugs in the drivers I was working with.
> >> >
> >>
> >> David,
> >>
> >> Could you let me know which exact platform and OTG driver you've
> >> used when you observed it was working?
> >
> > The musb_hdrc driver, in OTG mode. Working on two different
> > flavors of TI silicon (OMAP3, DaVinci) talking to each other
> > with Gadget Zero set up as the HNP test device ... so that as
> > soon as the a_host sees that b_device, it initiates HNP.
> >
> > (That's *with* the benefit of the HNP fixes now in Greg's
> > 2.6.31 merge queue.)
> >
> > One test I want to get back to is having *both* nodes be that
> > HNP test device. One wants to be sure it doesn't keep looping
> > in HNP, switching roles forever. ;)
> >
> >
> > And also, back in the 2.6.10 days ... OMAP 1611 H2 platforms,
> > talking both to each other and to the full speed OTG test
> > harness. I don't think that's been tested at all recently,
> > and so I expect some level of bitrot has set in. That was
> > the original test platform for all this OTG code, of course.
> >
> > - Dave
> >
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
