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