On Tue, Apr 28, 2009 at 3:50 PM, David Brownell <david-b@xxxxxxxxxxx> wrote:
> 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!
>
We have a lot of other SoCs and platforms, Linux-based, supporting
full OTG compliance, with another framework. The reason of Yong's
work, however, is to contribute back with the existing OTG support
in the kernel. Now you don't have to be shocked ;-)
--
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
