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

[Tom Rini]

On Mon, Jun 10, 2013 at 11:55:31AM +0200, 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 at 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 at amarulasolutions.com>

Thanks for sorting this all out.  Please post as a separate thread the
new patch, and I'm going to drop the ULPI patch from my pull request for
now (we'll pick it up before release).  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130610/447972cb/attachment.pgp>