Hi,
On Mon, Nov 19, 2012 at 08:17:34PM +0100, Sascha Hauer wrote:
> Hi Peter,
>
> > @@ -139,6 +139,7 @@ struct ci13xxx {
> > enum ci_role role;
> > bool is_otg;
> > struct work_struct work;
> > + struct delayed_work dwork;
> > struct workqueue_struct *wq;
> >
> > struct dma_pool *qh_pool;
> > @@ -164,6 +165,11 @@ struct ci13xxx {
> > bool global_phy;
> > struct usb_phy *transceiver;
> > struct usb_hcd *hcd;
> > + /* events handled at ci_role_work */
> > +#define ID 0
> > +#define B_SESS_VALID 1
> > + unsigned long events;
> > + struct usb_otg otg;
>
> I looked into implementing ULPI support for the chipidea driver. This
> does not integrate very well with having a struct usb_otg here. Instead
> it should be a pointer. Look into drivers/usb/otg/ulpi.c. This
> allocates the struct usb_otg itself and we have to feed the pointer into
> struct ci13xxx.
>
> Also I think that using a regulator as a vbus provider is not i.MX
> specific, it's not even chipidea specific. I think this should be a
> driver of its own under drivers/usb/otg/, or maybe part of
> drivers/usb/otg/gpio_vbus.c.if it's really a normal regulator, it should be a regulator driver which the PHY uses. That's what we do on OMAP and has worked quite well. One thing to note however, if your regulator can sink and source VBUS, then regulator framework has a limitation. You can sent the regulator to "boost" mode (or whatever they call it on your device, that's the mode which starts sourcing 500mA or 900mA on VBUS). I have tried persuading regulator folks to add another API call for that, but so far nothing has happened :-( Maybe more users will help :-) -- balbi
signature.asc
Description: Digital signature
