[U-Boot] Please pull u-boot-ti/master

[Lubomir Popov <lpopov@mm-sol.com>]

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
>   * port_num start from 0 so we need to take in account when
>   we use the omap access function.
>   * 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