diff mbox

OMAP3530 USB host problems

Message ID 20090220192330.GN32564@gandalf (mailing list archive)
State Not Applicable, archived
Delegated to: Felipe Balbi
Headers show

Commit Message

Felipe Balbi Feb. 20, 2009, 7:23 p.m. UTC 
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:


and tell us if it worked

Comments

Gary Thomas Feb. 20, 2009, 7:35 p.m. UTC | #1 
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...
Felipe Balbi Feb. 20, 2009, 7:41 p.m. UTC | #2 
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.
Felipe Balbi Feb. 23, 2009, 10:21 a.m. UTC | #3 
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 ??
Gary Thomas Feb. 23, 2009, 1:08 p.m. UTC | #4 
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...
Felipe Balbi Feb. 23, 2009, 1:27 p.m. UTC | #5 
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.
Gary Thomas Feb. 23, 2009, 5:21 p.m. UTC | #6 
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
Felipe Balbi Feb. 23, 2009, 6 p.m. UTC | #7 
On Mon, Feb 23, 2009 at 10:21:25AM -0700, Gary Thomas wrote:
> 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).

Yeah, as I suspected. Even in current linux-omap, I got report that vbus
goes on, but enumeration doesn't happen, so you're at the same stage.

> Thanks for the pointers

no problems
diff mbox

Patch

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