Hi, David,
So you suggest we didnot use this function -- usb_bus_start_enum, right?
As I remember, if I didnot use this function, our OTG device cannot
pass the OTG Protocol Test. I will check the real reason and try to
use the other solution to replace this function such as resuming the
port.
yep. I am working on HNP on PXA3xx. :)
Regards
Yong
2009/4/28 David Brownell <david-b@xxxxxxxxxxx>:
> 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
