On 05/04/12 12:06, Russ Dill wrote: > On Thu, May 3, 2012 at 11:03 PM, Igor Grinberg <grinb...@compulab.co.il> > wrote: >> Hi Russ, >> >> On 05/03/12 22:08, Russ Dill wrote: >>> On Wed, May 2, 2012 at 3:38 AM, Raja, Govindraj <govindraj.r...@ti.com> >>> wrote: >>>> On Wed, May 2, 2012 at 2:17 PM, Russ Dill <russ.d...@ti.com> wrote: >>>>> On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj <govindraj.r...@ti.com> >>>>> wrote: >>>>>> On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda >>>>>> <keshava_mgo...@ti.com> wrote: >>>>>>> From: Keshava Munegowda <keshava_mgo...@ti.com> >>>>>>> >>>>>>> It is observed that the echi ports of 3430 sdp board >>>>>>> are not working due to the random timing of programming >>>>>>> the associated GPIOs of the ULPI PHYs of the EHCI for reset. >>>>>>> If the PHYs are reset at during usbhs core driver, host ports will >>>>>>> not work because EHCI driver is loaded after the resetting PHYs. >>>>>>> The PHYs should be in reset state while initializing the EHCI >>>>>>> controller. >>>>>>> The code which does the GPIO pins associated with the PHYs >>>>>>> are programmed to reset is moved from the USB host core driver >>>>>>> to EHCI driver. >>>>>> >>>>>> I tested on beagle xm where gpio nreset is requested from >>>>>> board file. >>>>>> (Basic enumertaion after gpio nreset seems to work fine, >>>>>> Hub and smsc lan chip get detected afetr boot up) >>>>>> >>>>> >>>>> What base did you test this on top of? my xM is failing USB-wise when >>>>> I apply this on v3.3.3 (with the UART mux fix patch) and where it is >>>>> applied within master (3.4-rc4, again, with the UART mux fix patch). >>>>> Additionally, reverting this patch from 3.4-rc5 causes rc5 to work >>>>> properly. >>>>> >>>> >>>> Works for me be on 3.4-rc5 Beagle-XM even without reverting the patch >>>> >>>> Logs as in here [1]. >>>> >>>> -- >>>> Thanks, >>>> Govindraj.R >>>> >>>> [1]: >>>> http://pastebin.pandaboard.org/index.php/view/20343533 >>> >>> I've tracked down the difference. I'm loading my uEnv.txt and uImage >>> in u-boot from the network which means initializing USB. You are >>> loading straight from MMC. If I switch to loading straight from MMC >>> everything works. >>> >>> Can everyone do a 'usb start' in u-boot before booting and re-test? >>> I'm pretty sure this is a regression, but the bug could be a strange >>> u-boot/kernel interaction. >> >> Probably, kernel code does not reinitialize EHCI correctly if it was already >> enabled? >> Can you try the below sequence: >> usb start >> usb stop >> boot Linux > > That doesn't work. Rebooting does work though.
This means that U-Boot's usb stop command is also not clean enough... So we have two problems here, one is related to kernel USB initialization and the second to U-Boot usb stop command... -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
