Hi Michael,
On 10/06/13 12:55, Michael Trimarchi wrote:
Hi
On Mon, Jun 10, 2013 at 11:54:31AM +0300, Lubomir Popov wrote:
Hi Michael,
On 10/06/13 00:37, Michael Trimarchi wrote:
Hi
On 06/08/2013 10:43 PM, Lubomir Popov wrote:
Hi Tom, Michael,
Hello,
The following changes since commit 3da0e5750b24a9491058df6126c7be577a276c09:
arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
for you to fetch changes up to 80dd596d1b442ff53dbeb33eccdb8efd2283be79:
[snip]
Michael Trimarchi (1): usb: omap: ulpi: fix ulpi transceiver access
[snip]
drivers/usb/ulpi/omap-ulpi-viewport.c | 40 +-
[snip]
I just made a clean clone of u-boot-ti/master, manually applied the changes to the ehci files, added my board files and made a build. Everything seems to work fine, but I see an error message regarding ULPI reset that was not present before, and obviously it is due to Michael's changes:
SOM5_EVB # usb start (Re)start USB... USB0: ULPI: ulpi_reset: failed writing reset bit
Let me understand. The patch is wrong because you have a problem now. The old code was not sending any write command so any ulpi_reset and the test condition was wrong.
Right.
USB EHCI 1.00 scanning bus 0 for devices... 6 USB Device(s) found scanning usb for storage devices... 3 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found SOM5_EVB # usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Mass Storage (480 Mb/s, 200mA) | FSC MEMORYBIRD USB2 C157040817120315AA | +-3 Hub (480 Mb/s, 2mA) | | | +-4 Mass Storage (480 Mb/s, 96mA) | | Generic Ultra Fast Media Reader 000000264001 | | | +-5 Mass Storage (480 Mb/s, 100mA) | USB Flash Drive 531C43B21928F11F | +-6 Vendor specific (480 Mb/s, 500mA)
SOM5_EVB #
Otherwise everything is OK, the device on the ULPI port is working (it is #2 above). It is now late and I shall investigate in detail tomorrow, this is just an early warning ;)
Can you test the attach patch? Yes I know it is not inline but I will send inline tomorrow and I have done changing the old one. I was thinking port number was starting from 1 but I have done a quick check on soft_reset of omap and it is starting from 0
Just tested on a OMAP5430 custom board. Everything is OK, PHY soft reset passes. My ULPI PHY is on port 0, and with the previous version the insreg05 bit 31 remained stuck at 1, producing this error. Now when we write 1 to the port field instead of 0, everything is fine. So
Tested-by: Lubomir Popov lpopov@mm-sol.com
While testing, I however encountered another issue (not related to this patch, take it easy ;-) ): one particular USB flash stick, connected to the ULPI port, does systematically (100%) not get detected upon the first 'usb start' command after power-on; subsequent usb start/reset commands detect it alright. I have experimented a bit with some delays (assuming that it is some sort of timing problem), but without success. Other sticks are OK. Removing the call to omap_ehci_soft_phy_reset() (which calls ulpi_reset() and the viewport stuff) does not change anything.
I'm currently at work, where I have other obligations and cannot spend much time for U-Boot. Therefore, if somebody could share any experience on this subject, please let me know.
One thing that perhaps I should clarify: my ULPI PHY is the TI part TUSB1210; on the other hand, TI themselves recommend PHYs by SMSC, at least for the OMAP4. This was not the case for OMAP5, but who knows...
Thanks, Lubo
Michael
Best regards, Lubo
This patch fix the omap access to the transceiver configuration registers using the ulpi bus. As reported by the documentation the bit31 is used only to check if the transaction is done or still running and the reading and writing operation have different offset and have different values. What we need to do at the end of a transaction is leave the bus in done state. Anyway an error using the ulpi omap register is not recoverable so any error give out the usage of this interface.
Signed-off-by: Michael Trimarchi michael@amarulasolutions.com
- changes for V4
we use the omap access function.
- port_num start from 0 so we need to take in account when
- Fix the read function
- changes for V3 Fix patch subject
- changes for V2 Fix commit message
drivers/usb/ulpi/omap-ulpi-viewport.c | 42 +++++++-------------------------- 1 file changed, 9 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/ulpi/omap-ulpi-viewport.c b/drivers/usb/ulpi/omap-ulpi-viewport.c index 3c1ea1a..4db7fa4 100644 --- a/drivers/usb/ulpi/omap-ulpi-viewport.c +++ b/drivers/usb/ulpi/omap-ulpi-viewport.c @@ -22,18 +22,19 @@ #include <asm/io.h> #include <usb/ulpi.h>
-#define OMAP_ULPI_WR_OPSEL (3 << 21) -#define OMAP_ULPI_ACCESS (1 << 31) +#define OMAP_ULPI_WR_OPSEL (2 << 22) +#define OMAP_ULPI_RD_OPSEL (3 << 22) +#define OMAP_ULPI_START (1 << 31)
/*
- Wait for the ULPI Access to complete
*/
- Wait for having ulpi in done state
static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32 mask) { int timeout = CONFIG_USB_ULPI_TIMEOUT;
while (--timeout) {
if ((readl(ulpi_vp->viewport_addr) & mask))
if (!(readl(ulpi_vp->viewport_addr) & mask)) return 0;udelay(1);
@@ -43,40 +44,15 @@ static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32 mask) }
/*
- Wake the ULPI PHY up for communication
- returns 0 on success.
- */
-static int ulpi_wakeup(struct ulpi_viewport *ulpi_vp) -{
- int err;
- if (readl(ulpi_vp->viewport_addr) & OMAP_ULPI_ACCESS)
return 0; /* already awake */- writel(OMAP_ULPI_ACCESS, ulpi_vp->viewport_addr);
- err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS);
- if (err)
debug("ULPI wakeup timed out\n");- return err;
-}
-/*
- Issue a ULPI read/write request
*/ static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32 value) { int err;
err = ulpi_wakeup(ulpi_vp);
if (err)
return err;writel(value, ulpi_vp->viewport_addr);
err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS);
- err = ulpi_wait(ulpi_vp, OMAP_ULPI_START); if (err) debug("ULPI request timed out\n");
@@ -85,7 +61,7 @@ static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32 value)
int ulpi_write(struct ulpi_viewport *ulpi_vp, u8 *reg, u32 value) {
- u32 val = ((ulpi_vp->port_num & 0xf) << 24) |
u32 val = OMAP_ULPI_START | (((ulpi_vp->port_num + 1) & 0xf) << 24) | OMAP_ULPI_WR_OPSEL | ((u32)reg << 16) | (value & 0xff);
return ulpi_request(ulpi_vp, val);
@@ -94,8 +70,8 @@ int ulpi_write(struct ulpi_viewport *ulpi_vp, u8 *reg, u32 value) u32 ulpi_read(struct ulpi_viewport *ulpi_vp, u8 *reg) { int err;
- u32 val = ((ulpi_vp->port_num & 0xf) << 24) |
OMAP_ULPI_WR_OPSEL | ((u32)reg << 16);
- u32 val = OMAP_ULPI_START | (((ulpi_vp->port_num + 1) & 0xf) << 24) |
OMAP_ULPI_RD_OPSEL | ((u32)reg << 16);
This fix (OMAP_ULPI_START | ...) to ulpi_read() is correct. It does not however solve my issue :( . As I noted, with or without calling the soft reset, behavior with this particular USB stick is the same.
err = ulpi_request(ulpi_vp, val); if (err)
BR, Lubo