Hi,
On Thu, Mar 14, 2013 at 05:38:03PM +0800, Peter Chen wrote:
> > > > @@ -160,6 +163,24 @@ usb_phy_shutdown(struct usb_phy *x)
> > > > x->shutdown(x);
> > > > }
> > > >
> > > > +static inline int
> > > > +usb_phy_vbus_on(struct usb_phy *x)
> > > > +{
> > > > + if (!x->set_vbus)
> > > > + return 0;
> > > > +
> > > > + return x->set_vbus(x, true);
> > > > +}
> > > > +
> > > > +static inline int
> > > > +usb_phy_vbus_off(struct usb_phy *x)
> > > > +{
> > > > + if (!x->set_vbus)
> > > > + return 0;
> > > > +
> > > > + return x->set_vbus(x, false);
> > > > +}
> > > > +
> > >
> > > What's plan for otg's set_vbus? I suggest using phy's to instead of
> > > otg's.
> >
>
> When I think it more, does it work like below:
>
> - If PHY supplies vbus_setting function (like ulpi.c), the callback
> is assigned at PHY driver.
> - If board supplies vbus on/off function (through gpio), the callback
> is assigned at controller driver.
> Here vbus setting is USB staff, no limited to PHY.
I wonder if the whole vbus toggling logic shouldn't, eventually, become
a regulator. That would clean up a bunch of these details. I mean, we
can still provide usb_phy_vbus_on()/off() but that would just call into
the proper regulator.
Also, I think we should have a single location where VBUS is controlled,
since the VBUS line is directly routed to a pin in the PHY, the PHY
driver seems like the most logical entity to handle that.
--
balbi
Attachment:
signature.asc
Description: Digital signature
