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
?

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

Reply via email to