> >
> > - How to support OTG, you will give up struct usb_otg or not?
>
> I'm not sure what you mean by giving up usb_otg. What we were discussing
> with Heikki and Felipe is reworking the otg framework so that, for
> example, we have a common otg state machine instead of reimplementing it
> in every otg driver. We planned for this work to be based upon this
> chipidea driver. Maybe this topic should be brought up again.
>
As I haven't seen otg_set_host at your host driver, and no otg_set_vbus
when device <--> host switch.
> In any case, my plan is that the otg part of ci_hdrc should be based on
> those otg framework changes, which should come first. Heikki, do you
> have anything to add?
>
OK, understand. Currently, I just want to know that ID switch can work
or not at your board?
By the way, why not return directly when it sees a id change interrupt
at ci_irq?
> > - When ID switch occurs, do udc_start/udc_stop is enough, seems no
> registers
> > operation?
>
> The ID switch will cause the stop() for current role and the start() for
> the new role, which at the very least resets the device and sets
> USBMODE_CM_{D,H}C. Also, when the gadget is stopped, UDC is
> deinitialized and queue heads are flushed. Does this answer your
> question?
>
I don't know if you have used any otg drivers at your board when using your patchset.
When host switches device, the host->stop will not call controller reset,
and udc_start only calls otg_set_peripheral, I don't know where you set device
mode at udc_start.
> > - I have not found vbus interrupt code which is used to stand for
> > connect and disconnect at device mode.
>
> It's not there yet. I think it should be in the otg part of the
> driver. What do you think?
Yes, again, no vbus on/off, does your id switch is ok? Your vbus is always
on?
> > - Current, there is no PHY Layer code (I will begin to do it soon),
> > so your PHY operation is at udc code, once the PHY Layer code is ready,
> > do you will move it to core.c?
>
> I think of phy code as platform code, it doesn't directly concern the
> chipidea driver, except for the bits where chipidea might need explicit
> configuration of the phy type. But I think that is still separate from
> the actual phy code. My understanding is, usb controllers should be
> really decoupled from phy code and shoud only talk to one another
> through certain api. Again, Heikki might have more to say on this.
Yes, it should talk with PHY's API, when init, wakeup, suspend are needed.
>
> > Seems you have moved msm udc to chipidea folder, but have not changed
> > host and otg part, how msm user goes on using usb driver?
>
> Well, both ehci-msm.c and msm-otg.c are separate drivers, and nothing
> has changed from their prospective. With my patchset, they should still
> work as they did before it.
>
Oh, I did not mention CONFIG_USB_CHIPIDEA_HOST can be not defined.
Have you tried to not define CONFIG_USB_CHIPIDEA_HOST at your board?
>
> Regards,
> --
> Alex
--
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
