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

Tom Rini
2013-06-10T15:37:57Z

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

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>