Re: OMAP3530 USB host problems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux