From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marek.vasut@gmail.com>
Date: Sun, 6 Nov 2011 00:35:18 +0100
Subject: [U-Boot] [PATCH] ulpi: add generic ULPI functionality
In-Reply-To: <CAB+7RbF6ArQRPey3iVaUHg3hyTFG_O+WE78Vbxq2kkZS-Wy_uA@mail.gmail.com>
References: <1320526223-30474-1-git-send-email-fermata7@gmail.com>
	<201111060013.52683.marek.vasut@gmail.com>
	<CAB+7RbF6ArQRPey3iVaUHg3hyTFG_O+WE78Vbxq2kkZS-Wy_uA@mail.gmail.com>
Message-ID: <201111060035.19007.marek.vasut@gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

> 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?