On Mon, Dec 12, 2011 at 12:19:42PM +0200, Heikki Krogerus wrote:
> On Mon, Dec 12, 2011 at 11:47:30AM +0200, Felipe Balbi wrote:
> > Yeah, but what I meant by that is that struct usb_phy would have a
> > struct usb_otg field, not just a pointer to struct usb_otg. Something
> > like:
> >
> > struct usb_otg {
> > unsigned a,b,c;
> > };
> >
> > struct usb_phy {
> > struct usb_otg otg;
> > };
>
> Uh.. We should have talked about this earlier. My fault. You want
> the phy to be always available. I would prefer to have the chance to be
> able to use otg even if there is no phy driver at all. When we have
> USB2 with UTMI+ controller, there is no need to have phy driver. This
I could say the same about a ULPI compliant driver. The catch isn't if
the PHY is ULPI or UTMI+ compliant, the catch is if we need to tweak
anything on the controller for whatever reason (PM, comparator levels,
timer expiration, etc).
Every single USB2 PHY on the market will be either ULPI or UTMI+
compliant, otherwise we can't make an SoC unless we also design the PHYs
and don't allow customer to use another PHY, right ? If there's no
standard to follow, we could not use an off-the-shelf PHY. This means
that just because your PHY is UTMI+ compliant, it doesn't mean it's
Plug-N-Play. That's why we generally have an I2C control interface. Just
to make things easier should we need to e.g. turn off a regulator to
save few extra mA.
> configuration is however completely OTG capable. The "otg driver" will
> only deal with the controller.
>
> This would mean that the events would again be part of OTG, not PHY.
I didn't get this final part ;-) sorry.
--
balbi
Attachment:
signature.asc
Description: Digital signature
