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

[Igor Grinberg <grinberg@compulab.co.il>]

On 11/06/11 01:32, Jana Rapava wrote:
> 
> 
> 2011/11/6 Marek Vasut <marek.vasut at gmail.com <mailto:marek.vasut@gmail.com>>
> 
>     > 2011/11/5 Marek Vasut <marek.vasut at gmail.com <mailto: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.

User should neither care about the register, nor the access mode.
User should ask the driver to do "something useful"
(e.g. put the phy to some mode, enable vbus, etc.),
and that can be done with flags and functional API.


-- 
Regards,
Igor.