[U-Boot] [PATCH] ulpi: add generic ULPI functionality

[Marek Vasut <marek.vasut@gmail.com>]

> 2011/11/6 Marek Vasut <marek.vasut@gmail.com>
> 
> > > 2011/11/5 Marek Vasut <marek.vasut@gmail.com>
> > > 
> > > > > +int ulpi_wait(struct usb_ehci *ehci, u32 ulpi_value, u32
> > > > > ulpi_mask)
> > > > 
> > > > So this works only with EHCI? How generic is it then ?
> > > 
> > > I thought until now that ULPI is EHCI-dependent, but isn't... Ok, what
> > 
> > else
> > 
> > > should be supported? OHCI? I haven't any hardware to test it, but I
> > > could give it a try.
> > 
> > What about xHCI? I have no idea about OHCI, but why won't you be able to
> > have
> > OHCI and ULPI PHY?
> 
> I'll look at it.
> 
> > > > > +void ulpi_iface_ctrl_flags
> > > > > +     (struct usb_ehci *ehci, struct ulpi_regs *ulpi, int
> > 
> > access_mode,
> > 
> > > > u32
> > > > 
> > > > > flags) +{
> > > > > +     switch (access_mode) {
> > > > > +     case WRITE:
> > > > > +             ulpi_write(ehci, (u32)&ulpi->iface_ctrl_write,
> > > > > flags); +             break;
> > > > > +     case SET:
> > > > > +             ulpi_write(ehci, (u32)&ulpi->iface_ctrl_set, flags);
> > > > > +             break;
> > > > > +     case CLEAR:
> > > > > +             ulpi_write(ehci, (u32)&ulpi->iface_ctrl_clear,
> > > > > flags); +             break;
> > > > > +     }
> > > > > +
> > > > > +}
> > > > 
> > > > Is this crap from linux or something?
> > > 
> > > No, Linux has offset-based access to ULPI registers, some structure
> > > otg_transceiver, where the driver sets the bits which it wants to be
> > > set
> > 
> > in
> > 
> > > ULPI registers (if I understand it well) and family of functions, which
> > 
> > set
> > 
> > > bits according to informations in otg_transceiver.
> > 
> > Ok, you have writel() functions, why do you need this switch stuff ?
> 
> I tried to design some interface, which would allow its user care only
> about register, access mode and flags and not about the exact way this huge
> bunch od u8 fields called "ulpi_regs" is implemented.

I'd assume the interface will expose something like:

* ULPI power up port
* ULPI power down power

maybe something else, no?