Re: OMAP3530 USB host problems

[Gary Thomas <gary@mlbassoc.com>]

Felipe Balbi wrote:
> On Mon, Feb 23, 2009 at 02:08:12PM +0100, ext Gary Thomas wrote:
>> Felipe Balbi wrote:
>>> On Fri, Feb 20, 2009 at 08:41:58PM +0100, ext Felipe Balbi wrote:
>>>> On Fri, Feb 20, 2009 at 12:35:29PM -0700, Gary Thomas wrote:
>>>>> Felipe Balbi wrote:
>>>>>> On Fri, Feb 20, 2009 at 12:05:49PM -0700, Gary Thomas wrote:
>>>>>>> Felipe Balbi wrote:
>>>>>>>> On Fri, Feb 20, 2009 at 11:50:44AM -0700, Gary Thomas wrote:
>>>>>>>>> Felipe Balbi wrote:
>>>>>>>>>> On Fri, Feb 20, 2009 at 11:15:36AM -0700, Gary Thomas wrote:
>>>>>>>>>>> I have a 3530 board (similar to the OMAP3EVM) and I'm trying
>>>>>>>>>>> to get the USB host working.  Sadly, this is failing, but I
>>>>>>>>>>> don't quite see why.  From drivers/usb/host/echi-omap.c:
>>>>>>>>>>>        /* Wait for TLL to be Active */
>>>>>>>>>>>         timeout = 1000;
>>>>>>>>>>>        while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
>>>>>>>>>>>                        & (1 << OMAP3430ES2_ST_USBTLL_SHIFT)))
>>>>>>>>>>>         {
>>>>>>>>>>>             if (--timeout <= 0) {
>>>>>>>>>>>                 printk(KERN_ERR "USB TLL is unavailable\n");
>>>>>>>>>>>                 return -ENODEV;
>>>>>>>>>>>             }
>>>>>>>>>>>                cpu_relax();
>>>>>>>>>>>         }
>>>>>>>>>>>
>>>>>>>>>>> Any clues on why this might be?  How do I solve it?
>>>>>>>>>> could you enable CONFIG_DEBUG_LL and post the seria console output ?
>>>>>>>>>>
>>>>>>>>>> do you really use TLL ?? I don't really know omap3evm, but I guess it
>>>>>>>>>> uses PHY mode (correct me if I'm wrong).
>>>>>>>>>>
>>>>>>>>> It's not that I _need_ TLL, the driver function omap_start_ehci()
>>>>>>>>> tries to reset the part of the USB controller and fails.  I'm just
>>>>>>>>> trying to understand why this part of the code falls over.
>>>>>>>> you have OMAP_EHCI_TLL_MODE set, you should probably use
>>>>>>>> OMAP_EHCI_PHY_MODE instead.
>>>>>>>>
>>>>>>>> You can fix it via "make menuconfig"
>>>>>>>>
>>>>>>> I already have that; this code is still being used.
>>>>>>>   # CONFIG_OMAP_EHCI_TLL_MODE is not set
>>>>>>>   CONFIG_OMAP_EHCI_PHY_MODE=y
>>>>>>>
>>>>>>> This is not used in the function above at all.
>>>>>> hmm.. true, just checked the function.
>>>>>>
>>>>>> Weird, TRM says when that bit is 1, we cannot access ST_USBTLL, we
>>>>>> should access it when it's 0, try the following:
>>>>>>
>>>>>> diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
>>>>>> index 1b3266c..122e95b 100644
>>>>>> --- a/drivers/usb/host/ehci-omap.c
>>>>>> +++ b/drivers/usb/host/ehci-omap.c
>>>>>> @@ -250,7 +250,7 @@ static int omap_start_ehc(struct platform_device *dev, struct usb_hcd *hcd)
>>>>>>
>>>>>>         /* Wait for TLL to be Active */
>>>>>>         while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
>>>>>> -                       & (1 << OMAP3430ES2_ST_USBTLL_SHIFT)))
>>>>>> +                       & (0 << OMAP3430ES2_ST_USBTLL_SHIFT)))
>>>>>>                 cpu_relax();
>>>>>>
>>>>>>         /* perform TLL soft reset, and wait until reset is complete */
>>>>>>
>>>>>> and tell us if it worked
>>>>>>
>>>>> Sadly, I've already tried this and things just continue to fall apart.
>>>>>
>>>>>   Unhandled fault: external abort on non-linefetch (0x1008) at 0xd8062010
>>>>>   Internal error: : 1008 [#1]
>>>>>   Modules linked in:
>>>>>   CPU: 0    Not tainted  (2.6.27-omap1-svn4799-dirty14 #60)
>>>>>   PC is at ehci_hcd_omap_drv_probe+0x370/0x5e4
>>>>>   LR is at release_console_sem+0x1a8/0x1d8
>>>>>
>>>>> Hence, my desired to figure out the TLL timeout...
>>>> keep TLL as is, the problem now seems to be a clock that should be on
>>>> and is off. Try to figure (with printk() for example) at which line the
>>>> code stops, put printk() before and after register read/write operations
>>>> during probe and omap_start_ehc(), let's see where does it dies.
>>> any news ??
>>>
>> Not really;  I'd like to figure out *why* this part of the USB
>> device isn't working, not just find a way around it...
> 
> It's not a way around it. That bit is wrong, one problem is fixed now
> but we came to another issue which is a non-linefetch, which makes me
> wonder that's a clock issue.
> 
> You should just try to fetch me for information and I might be able to
> help you more.
> 

It turns out that the various USB clocks were not enabled (this is prototype
hardware, only roughly equivalent to the OMAP3EVM and I started with a
kernel snapshot more than a month ago, so much may have changed in the
meantime).  I can now get through this part of the USB host initialization
code (still doesn't work, but I think I can figure it out).

Thanks for the pointers


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------