AM3517 usb host issue

AM3517 usb host issue

[Ben Dooks]

I am trying to get the full-speed USB host working on an custom AM3517
device with the 3.18.12 kernel. The hardware works (a 2.6.37 kernel has
been used for testing).

Does anyone have any experience of 3.18 (or similarly recent kernel on
an AM3517 system) or have any pointers as where to start debugging? The
ti-linux-3.14.y does not have any patches that aren't applied to the
usb on 3.18.13.

The cpu port 1 is connected by a TI TUSB1106 usb transceiver that is
directly connected to a full-speed hub (TI USB2046) hub so the OHCI
driver is the only one in use.

Note, the ohci-omap3 is loaded as a module as this is how their user
application expects to be able to shut down usb when it does not need
it.

The device tree configuration for the usb host:

> &usbhshost {
> 	status = "okay";	/* just in case it is started disabled */
> 
> 	port1-mode = "ohci-phy-6pin-dpdm";
> };
> 
> &usbhsohci {
> 	status = "okay";
> };
> 
> &usbhsehci {
> 	status = "disabled";	/* no ehci on board */
> };


The usb from the logs is as follows. Some extra debugging has been
added to verify the device-tree settings:

> [    0.000000] AM3517 ES1.1 (l2cache sgx neon)                                 
> 
> [    0.869706] usbcore: registered new interface driver usbfs                   
> [    0.874270] usbcore: registered new interface driver hub                     
> [    0.878592] usbcore: registered new device driver usb                        
> [    1.223199] usbhs_tll 48062000.usbhstll: starting TI HSUSB TLL Controller    
> [    1.273000] usbhs_omap 48064000.usbhshost: ports 0                           
> [    1.278291] usbhs_omap 48064000.usbhshost: port 0: ohci-phy-6pin-dpdm        
> [    1.284476] usbhs_omap 48064000.usbhshost: port0-mode: ohci-phy-6pin-dpdm ->5
> [    1.288689] usbhs_tll 48062000.usbhstll: omap_tll_init()                     
> [    1.293628] usbhs_omap 48064000.usbhshost: usbhs_runtime_resume              
> [    1.298434] usbhs_omap 48064000.usbhshost: sysconfig 0x00001009              
> [    1.302730] usbhs_tll 48062000.usbhstll: omap_tll_enable()                   
> [    1.307668] usbhs_omap 48064000.usbhshost: usbhs_runtime_suspend             
> [    1.310142] stopping usb controller                                          
> [    1.419910] usbhs_tll 48062000.usbhstll: omap_tll_disable()                  
> [    1.423547] usbhs_omap 48064000.usbhshost: 3 ports                           
> [    1.429065] usbhs_omap 48064000.usbhshost: starting TI HSUSB Controller      
> [    1.433831] usbhs_omap 48064000.usbhshost: usbhs_runtime_resume              
> [    1.438625] usbhs_omap 48064000.usbhshost: sysconfig 0x00001009              
> [    1.442921] usbhs_tll 48062000.usbhstll: omap_tll_enable()                   
> [    1.448548] usbhs_omap 48064000.usbhshost: omap_usbhs_rev1_hostconfig =>     
> [    1.455034] usbhs_omap 48064000.usbhshost: UHH setup done, uhh_hostconfig=80d
> [    1.459918] usbhs_omap 48064000.usbhshost: usbhs_runtime_suspend             
> [    1.462337] stopping usb controller                                          
> [    1.569905] usbhs_tll 48062000.usbhstll: omap_tll_disable()                  
> [    1.575408] usbhs_omap 48064000.usbhshost: populating usb sub nodes....      
> 
> [   77.609168] usbhs_omap 48064000.usbhshost: usbhs_runtime_resume              
> [   77.613927] usbhs_omap 48064000.usbhshost: sysconfig 0x00001009              
> [   77.618374] usbhs_tll 48062000.usbhstll: omap_tll_enable()                   
> [   77.802694] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001    
> [   77.816003] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber1
> [   77.827391] usb usb1: Product: OHCI Host Controller                          
> [   77.838674] usb usb1: Manufacturer: Linux 3.18.13-00203-ga3c52be-dirty ohci_d
> [   77.849913] usb usb1: SerialNumber: 48064400.ohci                            

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AM3517 usb host issue

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 4845 bytes --]

Hi,

On Fri, May 22, 2015 at 11:04:33AM +0300, Ben Dooks wrote:
> I am trying to get the full-speed USB host working on an custom AM3517
> device with the 3.18.12 kernel. The hardware works (a 2.6.37 kernel has
> been used for testing).
> 
> Does anyone have any experience of 3.18 (or similarly recent kernel on
> an AM3517 system) or have any pointers as where to start debugging? The
> ti-linux-3.14.y does not have any patches that aren't applied to the
> usb on 3.18.13.
> 
> The cpu port 1 is connected by a TI TUSB1106 usb transceiver that is
> directly connected to a full-speed hub (TI USB2046) hub so the OHCI
> driver is the only one in use.
> 
> Note, the ohci-omap3 is loaded as a module as this is how their user
> application expects to be able to shut down usb when it does not need
> it.
> 
> The device tree configuration for the usb host:

and what exactly doesn't work ? That old OHCI driver hasn't been touched
in years, it's no surprise that it stopped working :-(

Anyway, what exactly doesn't work ? No device enumerates ? Do you get
any IRQs by plugging a new device in ?

> > &usbhshost {
> > 	status = "okay";	/* just in case it is started disabled */
> > 
> > 	port1-mode = "ohci-phy-6pin-dpdm";
> > };
> > 
> > &usbhsohci {
> > 	status = "okay";
> > };
> > 
> > &usbhsehci {
> > 	status = "disabled";	/* no ehci on board */
> > };
> 
> 
> The usb from the logs is as follows. Some extra debugging has been
> added to verify the device-tree settings:
> 
> > [    0.000000] AM3517 ES1.1 (l2cache sgx neon)                                 
> > 
> > [    0.869706] usbcore: registered new interface driver usbfs                   
> > [    0.874270] usbcore: registered new interface driver hub                     
> > [    0.878592] usbcore: registered new device driver usb                        
> > [    1.223199] usbhs_tll 48062000.usbhstll: starting TI HSUSB TLL Controller    
> > [    1.273000] usbhs_omap 48064000.usbhshost: ports 0                           
> > [    1.278291] usbhs_omap 48064000.usbhshost: port 0: ohci-phy-6pin-dpdm        
> > [    1.284476] usbhs_omap 48064000.usbhshost: port0-mode: ohci-phy-6pin-dpdm ->5
> > [    1.288689] usbhs_tll 48062000.usbhstll: omap_tll_init()                     
> > [    1.293628] usbhs_omap 48064000.usbhshost: usbhs_runtime_resume              
> > [    1.298434] usbhs_omap 48064000.usbhshost: sysconfig 0x00001009              
> > [    1.302730] usbhs_tll 48062000.usbhstll: omap_tll_enable()                   
> > [    1.307668] usbhs_omap 48064000.usbhshost: usbhs_runtime_suspend             
> > [    1.310142] stopping usb controller                                          
> > [    1.419910] usbhs_tll 48062000.usbhstll: omap_tll_disable()                  
> > [    1.423547] usbhs_omap 48064000.usbhshost: 3 ports                           
> > [    1.429065] usbhs_omap 48064000.usbhshost: starting TI HSUSB Controller      
> > [    1.433831] usbhs_omap 48064000.usbhshost: usbhs_runtime_resume              
> > [    1.438625] usbhs_omap 48064000.usbhshost: sysconfig 0x00001009              
> > [    1.442921] usbhs_tll 48062000.usbhstll: omap_tll_enable()                   
> > [    1.448548] usbhs_omap 48064000.usbhshost: omap_usbhs_rev1_hostconfig =>     
> > [    1.455034] usbhs_omap 48064000.usbhshost: UHH setup done, uhh_hostconfig=80d
> > [    1.459918] usbhs_omap 48064000.usbhshost: usbhs_runtime_suspend             
> > [    1.462337] stopping usb controller                                          
> > [    1.569905] usbhs_tll 48062000.usbhstll: omap_tll_disable()                  
> > [    1.575408] usbhs_omap 48064000.usbhshost: populating usb sub nodes....      
> > 
> > [   77.609168] usbhs_omap 48064000.usbhshost: usbhs_runtime_resume              
> > [   77.613927] usbhs_omap 48064000.usbhshost: sysconfig 0x00001009              
> > [   77.618374] usbhs_tll 48062000.usbhstll: omap_tll_enable()                   
> > [   77.802694] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001    
> > [   77.816003] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber1
> > [   77.827391] usb usb1: Product: OHCI Host Controller                          
> > [   77.838674] usb usb1: Manufacturer: Linux 3.18.13-00203-ga3c52be-dirty ohci_d
> > [   77.849913] usb usb1: SerialNumber: 48064400.ohci                            

OK, so this is roothub, what happens when a device is plugged to the
other end ? Is VBUS charged ? We didn't even enumerate TUSB2046, did you
look at its datasheet (http://www.ti.com/lit/ds/symlink/tusb2046b.pdf) ?
What is the state of RESETn pin ? Perhaps that's tied to a GPIO and the
old TI kernel toggles that ? Anything interesting from usbmon ?

cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: AM3517 usb host issue

[Ben Dooks]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 22/05/15 16:50, Felipe Balbi wrote:
> Hi,
> 
> On Fri, May 22, 2015 at 11:04:33AM +0300, Ben Dooks wrote:
>> I am trying to get the full-speed USB host working on an custom
>> AM3517 device with the 3.18.12 kernel. The hardware works (a
>> 2.6.37 kernel has been used for testing).
>> 
>> Does anyone have any experience of 3.18 (or similarly recent
>> kernel on an AM3517 system) or have any pointers as where to
>> start debugging? The ti-linux-3.14.y does not have any patches
>> that aren't applied to the usb on 3.18.13.
>> 
>> The cpu port 1 is connected by a TI TUSB1106 usb transceiver that
>> is directly connected to a full-speed hub (TI USB2046) hub so the
>> OHCI driver is the only one in use.
>> 
>> Note, the ohci-omap3 is loaded as a module as this is how their
>> user application expects to be able to shut down usb when it does
>> not need it.
>> 
>> The device tree configuration for the usb host:
> 
> and what exactly doesn't work ? That old OHCI driver hasn't been
> touched in years, it's no surprise that it stopped working :-(
> 
> Anyway, what exactly doesn't work ? No device enumerates ? Do you
> get any IRQs by plugging a new device in ?

I will check the interrupts when I get back into the office.

There is only one device (the hub) which isn't enumerating and is
hard-wired on the board.

>>> &usbhshost { status = "okay";	/* just in case it is started
>>> disabled */
>>> 
>>> port1-mode = "ohci-phy-6pin-dpdm"; };
>>> 
>>> &usbhsohci { status = "okay"; };
>>> 
>>> &usbhsehci { status = "disabled";	/* no ehci on board */ };
>> 
>> 
>> The usb from the logs is as follows. Some extra debugging has
>> been added to verify the device-tree settings:
>> 
>>> [    0.000000] AM3517 ES1.1 (l2cache sgx neon)
>>> 
>>> 
>>> [    0.869706] usbcore: registered new interface driver usbfs
>>>  [    0.874270] usbcore: registered new interface driver hub
>>>  [    0.878592] usbcore: registered new device driver usb
>>>  [    1.223199] usbhs_tll 48062000.usbhstll: starting TI HSUSB
>>> TLL Controller [    1.273000] usbhs_omap 48064000.usbhshost:
>>> ports 0 [    1.278291] usbhs_omap 48064000.usbhshost: port 0:
>>> ohci-phy-6pin-dpdm [    1.284476] usbhs_omap
>>> 48064000.usbhshost: port0-mode: ohci-phy-6pin-dpdm ->5 [
>>> 1.288689] usbhs_tll 48062000.usbhstll: omap_tll_init()
>>>  [    1.293628] usbhs_omap 48064000.usbhshost:
>>> usbhs_runtime_resume [    1.298434] usbhs_omap
>>> 48064000.usbhshost: sysconfig 0x00001009 [    1.302730]
>>> usbhs_tll 48062000.usbhstll: omap_tll_enable()
>>>  [    1.307668] usbhs_omap 48064000.usbhshost:
>>> usbhs_runtime_suspend [    1.310142] stopping usb controller
>>>  [    1.419910] usbhs_tll 48062000.usbhstll: omap_tll_disable()
>>>  [    1.423547] usbhs_omap 48064000.usbhshost: 3 ports
>>>  [    1.429065] usbhs_omap 48064000.usbhshost: starting TI
>>> HSUSB Controller [    1.433831] usbhs_omap 48064000.usbhshost:
>>> usbhs_runtime_resume [    1.438625] usbhs_omap
>>> 48064000.usbhshost: sysconfig 0x00001009 [    1.442921]
>>> usbhs_tll 48062000.usbhstll: omap_tll_enable()
>>>  [    1.448548] usbhs_omap 48064000.usbhshost:
>>> omap_usbhs_rev1_hostconfig => [    1.455034] usbhs_omap
>>> 48064000.usbhshost: UHH setup done, uhh_hostconfig=80d [
>>> 1.459918] usbhs_omap 48064000.usbhshost: usbhs_runtime_suspend
>>>  [    1.462337] stopping usb controller
>>>  [    1.569905] usbhs_tll 48062000.usbhstll: omap_tll_disable()
>>>  [    1.575408] usbhs_omap 48064000.usbhshost: populating usb
>>> sub nodes....
>>> 
>>> [   77.609168] usbhs_omap 48064000.usbhshost:
>>> usbhs_runtime_resume [   77.613927] usbhs_omap
>>> 48064000.usbhshost: sysconfig 0x00001009 [   77.618374]
>>> usbhs_tll 48062000.usbhstll: omap_tll_enable()
>>>  [   77.802694] usb usb1: New USB device found, idVendor=1d6b,
>>> idProduct=0001 [   77.816003] usb usb1: New USB device strings:
>>> Mfr=3, Product=2, SerialNumber1 [   77.827391] usb usb1:
>>> Product: OHCI Host Controller [   77.838674] usb usb1:
>>> Manufacturer: Linux 3.18.13-00203-ga3c52be-dirty ohci_d [
>>> 77.849913] usb usb1: SerialNumber: 48064400.ohci
>>> 
> 
> OK, so this is roothub, what happens when a device is plugged to
> the other end ? Is VBUS charged ? We didn't even enumerate
> TUSB2046, did you look at its datasheet
> (http://www.ti.com/lit/ds/symlink/tusb2046b.pdf) ? What is the
> state of RESETn pin ? Perhaps that's tied to a GPIO and the old TI
> kernel toggles that ? Anything interesting from usbmon ?

I've gone through the schematics and verified the hub's reset line
is connected where we think it is (will try and check with a 'scope
on monday that it is being taken high, the boot-loader starts it low).

The root has just the one device connected, and unfortunately the
hw designer decided to hard-wire the D+ pull-up to 3.3V instead
of the transceiver's pull pin.

Not tried usbmon yet. However if the hub is not being detected then
probably won't show anything either.

I am going to install devmem2 into the root image and use it to poke
around and see the state of the system at run time.

Thanks for looking in to this.

- -- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVX43iAAoJEMuhVOkVU3uzaHUH/0rcRBoWJn07wuJZSDmX2cf7
pFV1jya+Qx1zJmVdwDfT1MLAW5XCdio5U+sZyWFe7mxbZd3IPXhMud4xAqjdEnvQ
amS3WcLVqbqLCbIq8KYKN6eSZqnf8gO2sPhSo3j86TpWyaQHstiS+FQu4Rv1v1XD
IUfXoQyp/taKihVcs7VvP6bT5lARr2lANGCJ6VAchHjLr04NM4VJUUXJ18m/Zxfm
A0Y6dJeLuT4MF9QpOd7KYVn2gYpdwtznF87J8gqJcYJHhggY1LWYBKiJSzBT6m/0
JYJldljoCEznro7G0ZaPMubWQO363SVEqDf3b7lmYuBKPo+7z/dr/KVmwiBf2a0=
=Hegi
-----END PGP SIGNATURE-----

Re: AM3517 usb host issue

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 5965 bytes --]

Hi,

On Fri, May 22, 2015 at 11:13:22PM +0300, Ben Dooks wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 22/05/15 16:50, Felipe Balbi wrote:
> > Hi,
> > 
> > On Fri, May 22, 2015 at 11:04:33AM +0300, Ben Dooks wrote:
> >> I am trying to get the full-speed USB host working on an custom
> >> AM3517 device with the 3.18.12 kernel. The hardware works (a
> >> 2.6.37 kernel has been used for testing).
> >> 
> >> Does anyone have any experience of 3.18 (or similarly recent
> >> kernel on an AM3517 system) or have any pointers as where to
> >> start debugging? The ti-linux-3.14.y does not have any patches
> >> that aren't applied to the usb on 3.18.13.
> >> 
> >> The cpu port 1 is connected by a TI TUSB1106 usb transceiver that
> >> is directly connected to a full-speed hub (TI USB2046) hub so the
> >> OHCI driver is the only one in use.
> >> 
> >> Note, the ohci-omap3 is loaded as a module as this is how their
> >> user application expects to be able to shut down usb when it does
> >> not need it.
> >> 
> >> The device tree configuration for the usb host:
> > 
> > and what exactly doesn't work ? That old OHCI driver hasn't been
> > touched in years, it's no surprise that it stopped working :-(
> > 
> > Anyway, what exactly doesn't work ? No device enumerates ? Do you
> > get any IRQs by plugging a new device in ?
> 
> I will check the interrupts when I get back into the office.
> 
> There is only one device (the hub) which isn't enumerating and is
> hard-wired on the board.

alright, that makes things a little more difficult :-)

> >>> &usbhshost { status = "okay";	/* just in case it is started
> >>> disabled */
> >>> 
> >>> port1-mode = "ohci-phy-6pin-dpdm"; };
> >>> 
> >>> &usbhsohci { status = "okay"; };
> >>> 
> >>> &usbhsehci { status = "disabled";	/* no ehci on board */ };
> >> 
> >> 
> >> The usb from the logs is as follows. Some extra debugging has
> >> been added to verify the device-tree settings:
> >> 
> >>> [    0.000000] AM3517 ES1.1 (l2cache sgx neon)
> >>> 
> >>> 
> >>> [    0.869706] usbcore: registered new interface driver usbfs
> >>>  [    0.874270] usbcore: registered new interface driver hub
> >>>  [    0.878592] usbcore: registered new device driver usb
> >>>  [    1.223199] usbhs_tll 48062000.usbhstll: starting TI HSUSB
> >>> TLL Controller [    1.273000] usbhs_omap 48064000.usbhshost:
> >>> ports 0 [    1.278291] usbhs_omap 48064000.usbhshost: port 0:
> >>> ohci-phy-6pin-dpdm [    1.284476] usbhs_omap
> >>> 48064000.usbhshost: port0-mode: ohci-phy-6pin-dpdm ->5 [
> >>> 1.288689] usbhs_tll 48062000.usbhstll: omap_tll_init()
> >>>  [    1.293628] usbhs_omap 48064000.usbhshost:
> >>> usbhs_runtime_resume [    1.298434] usbhs_omap
> >>> 48064000.usbhshost: sysconfig 0x00001009 [    1.302730]
> >>> usbhs_tll 48062000.usbhstll: omap_tll_enable()
> >>>  [    1.307668] usbhs_omap 48064000.usbhshost:
> >>> usbhs_runtime_suspend [    1.310142] stopping usb controller
> >>>  [    1.419910] usbhs_tll 48062000.usbhstll: omap_tll_disable()
> >>>  [    1.423547] usbhs_omap 48064000.usbhshost: 3 ports
> >>>  [    1.429065] usbhs_omap 48064000.usbhshost: starting TI
> >>> HSUSB Controller [    1.433831] usbhs_omap 48064000.usbhshost:
> >>> usbhs_runtime_resume [    1.438625] usbhs_omap
> >>> 48064000.usbhshost: sysconfig 0x00001009 [    1.442921]
> >>> usbhs_tll 48062000.usbhstll: omap_tll_enable()
> >>>  [    1.448548] usbhs_omap 48064000.usbhshost:
> >>> omap_usbhs_rev1_hostconfig => [    1.455034] usbhs_omap
> >>> 48064000.usbhshost: UHH setup done, uhh_hostconfig=80d [
> >>> 1.459918] usbhs_omap 48064000.usbhshost: usbhs_runtime_suspend
> >>>  [    1.462337] stopping usb controller
> >>>  [    1.569905] usbhs_tll 48062000.usbhstll: omap_tll_disable()
> >>>  [    1.575408] usbhs_omap 48064000.usbhshost: populating usb
> >>> sub nodes....
> >>> 
> >>> [   77.609168] usbhs_omap 48064000.usbhshost:
> >>> usbhs_runtime_resume [   77.613927] usbhs_omap
> >>> 48064000.usbhshost: sysconfig 0x00001009 [   77.618374]
> >>> usbhs_tll 48062000.usbhstll: omap_tll_enable()
> >>>  [   77.802694] usb usb1: New USB device found, idVendor=1d6b,
> >>> idProduct=0001 [   77.816003] usb usb1: New USB device strings:
> >>> Mfr=3, Product=2, SerialNumber1 [   77.827391] usb usb1:
> >>> Product: OHCI Host Controller [   77.838674] usb usb1:
> >>> Manufacturer: Linux 3.18.13-00203-ga3c52be-dirty ohci_d [
> >>> 77.849913] usb usb1: SerialNumber: 48064400.ohci
> >>> 
> > 
> > OK, so this is roothub, what happens when a device is plugged to
> > the other end ? Is VBUS charged ? We didn't even enumerate
> > TUSB2046, did you look at its datasheet
> > (http://www.ti.com/lit/ds/symlink/tusb2046b.pdf) ? What is the
> > state of RESETn pin ? Perhaps that's tied to a GPIO and the old TI
> > kernel toggles that ? Anything interesting from usbmon ?
> 
> I've gone through the schematics and verified the hub's reset line
> is connected where we think it is (will try and check with a 'scope
> on monday that it is being taken high, the boot-loader starts it low).
> 
> The root has just the one device connected, and unfortunately the
> hw designer decided to hard-wire the D+ pull-up to 3.3V instead
> of the transceiver's pull pin.
> 
> Not tried usbmon yet. However if the hub is not being detected then
> probably won't show anything either.
> 
> I am going to install devmem2 into the root image and use it to poke
> around and see the state of the system at run time.
> 
> Thanks for looking in to this.

yeah, no problem. You probably want to first make sure VBUS is alive
behind the HUB (iow, make sure the hub is powered up as you'd expect),
then make sure VBUS is coming out on the other end (the hub's ports).
The make sure RESETn is high as you'd want it to be. After that, then I
guess only register pick-and-poke is left.

cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: AM3517 usb host issue

[Ben Dooks]

On 22/05/15 23:13, Ben Dooks wrote:
> On 22/05/15 16:50, Felipe Balbi wrote:
>> Hi,
> 
>> On Fri, May 22, 2015 at 11:04:33AM +0300, Ben Dooks wrote:
>>> I am trying to get the full-speed USB host working on an custom
>>> AM3517 device with the 3.18.12 kernel. The hardware works (a
>>> 2.6.37 kernel has been used for testing).
>>>
>>> Does anyone have any experience of 3.18 (or similarly recent
>>> kernel on an AM3517 system) or have any pointers as where to
>>> start debugging? The ti-linux-3.14.y does not have any patches
>>> that aren't applied to the usb on 3.18.13.
>>>
>>> The cpu port 1 is connected by a TI TUSB1106 usb transceiver that
>>> is directly connected to a full-speed hub (TI USB2046) hub so the
>>> OHCI driver is the only one in use.
>>>
>>> Note, the ohci-omap3 is loaded as a module as this is how their
>>> user application expects to be able to shut down usb when it does
>>> not need it.
>>>
>>> The device tree configuration for the usb host:
> 
>> and what exactly doesn't work ? That old OHCI driver hasn't been
>> touched in years, it's no surprise that it stopped working :-(
> 
>> Anyway, what exactly doesn't work ? No device enumerates ? Do you
>> get any IRQs by plugging a new device in ?
> 
> I will check the interrupts when I get back into the office.
> 
> There is only one device (the hub) which isn't enumerating and is
> hard-wired on the board.
> 
>>>> &usbhshost { status = "okay";	/* just in case it is started
>>>> disabled */
>>>>
>>>> port1-mode = "ohci-phy-6pin-dpdm"; };
>>>>
>>>> &usbhsohci { status = "okay"; };
>>>>
>>>> &usbhsehci { status = "disabled";	/* no ehci on board */ };
>>>
>>>
>>> The usb from the logs is as follows. Some extra debugging has
>>> been added to verify the device-tree settings:
>>>
>>>> [    0.000000] AM3517 ES1.1 (l2cache sgx neon)
>>>>
>>>>
>>>> [    0.869706] usbcore: registered new interface driver usbfs
>>>>  [    0.874270] usbcore: registered new interface driver hub
>>>>  [    0.878592] usbcore: registered new device driver usb
>>>>  [    1.223199] usbhs_tll 48062000.usbhstll: starting TI HSUSB
>>>> TLL Controller [    1.273000] usbhs_omap 48064000.usbhshost:
>>>> ports 0 [    1.278291] usbhs_omap 48064000.usbhshost: port 0:
>>>> ohci-phy-6pin-dpdm [    1.284476] usbhs_omap
>>>> 48064000.usbhshost: port0-mode: ohci-phy-6pin-dpdm ->5 [
>>>> 1.288689] usbhs_tll 48062000.usbhstll: omap_tll_init()
>>>>  [    1.293628] usbhs_omap 48064000.usbhshost:
>>>> usbhs_runtime_resume [    1.298434] usbhs_omap
>>>> 48064000.usbhshost: sysconfig 0x00001009 [    1.302730]
>>>> usbhs_tll 48062000.usbhstll: omap_tll_enable()
>>>>  [    1.307668] usbhs_omap 48064000.usbhshost:
>>>> usbhs_runtime_suspend [    1.310142] stopping usb controller
>>>>  [    1.419910] usbhs_tll 48062000.usbhstll: omap_tll_disable()
>>>>  [    1.423547] usbhs_omap 48064000.usbhshost: 3 ports
>>>>  [    1.429065] usbhs_omap 48064000.usbhshost: starting TI
>>>> HSUSB Controller [    1.433831] usbhs_omap 48064000.usbhshost:
>>>> usbhs_runtime_resume [    1.438625] usbhs_omap
>>>> 48064000.usbhshost: sysconfig 0x00001009 [    1.442921]
>>>> usbhs_tll 48062000.usbhstll: omap_tll_enable()
>>>>  [    1.448548] usbhs_omap 48064000.usbhshost:
>>>> omap_usbhs_rev1_hostconfig => [    1.455034] usbhs_omap
>>>> 48064000.usbhshost: UHH setup done, uhh_hostconfig=80d [
>>>> 1.459918] usbhs_omap 48064000.usbhshost: usbhs_runtime_suspend
>>>>  [    1.462337] stopping usb controller
>>>>  [    1.569905] usbhs_tll 48062000.usbhstll: omap_tll_disable()
>>>>  [    1.575408] usbhs_omap 48064000.usbhshost: populating usb
>>>> sub nodes....
>>>>
>>>> [   77.609168] usbhs_omap 48064000.usbhshost:
>>>> usbhs_runtime_resume [   77.613927] usbhs_omap
>>>> 48064000.usbhshost: sysconfig 0x00001009 [   77.618374]
>>>> usbhs_tll 48062000.usbhstll: omap_tll_enable()
>>>>  [   77.802694] usb usb1: New USB device found, idVendor=1d6b,
>>>> idProduct=0001 [   77.816003] usb usb1: New USB device strings:
>>>> Mfr=3, Product=2, SerialNumber1 [   77.827391] usb usb1:
>>>> Product: OHCI Host Controller [   77.838674] usb usb1:
>>>> Manufacturer: Linux 3.18.13-00203-ga3c52be-dirty ohci_d [
>>>> 77.849913] usb usb1: SerialNumber: 48064400.ohci
>>>>
> 
>> OK, so this is roothub, what happens when a device is plugged to
>> the other end ? Is VBUS charged ? We didn't even enumerate
>> TUSB2046, did you look at its datasheet
>> (http://www.ti.com/lit/ds/symlink/tusb2046b.pdf) ? What is the
>> state of RESETn pin ? Perhaps that's tied to a GPIO and the old TI
>> kernel toggles that ? Anything interesting from usbmon ?
> 
> I've gone through the schematics and verified the hub's reset line
> is connected where we think it is (will try and check with a 'scope
> on monday that it is being taken high, the boot-loader starts it low).
> 
> The root has just the one device connected, and unfortunately the
> hw designer decided to hard-wire the D+ pull-up to 3.3V instead
> of the transceiver's pull pin.
> 
> Not tried usbmon yet. However if the hub is not being detected then
> probably won't show anything either.
> 
> I am going to install devmem2 into the root image and use it to poke
> around and see the state of the system at run time.
> 
> Thanks for looking in to this.

The hub is functioning, 3.3V is up, the ~RESET line is high and the
6MHz crystal is running at 6MHz.

I will get a register dump from both sets and compare.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

Re: AM3517 usb host issue

[Ben Dooks]

On 22/05/15 14:50, Felipe Balbi wrote:
> Hi,
> 
> On Fri, May 22, 2015 at 11:04:33AM +0300, Ben Dooks wrote:
>> I am trying to get the full-speed USB host working on an custom 
>> AM3517 device with the 3.18.12 kernel. The hardware works (a 
>> 2.6.37 kernel has been used for testing).
>> 
>> Does anyone have any experience of 3.18 (or similarly recent 
>> kernel on an AM3517 system) or have any pointers as where to 
>> start debugging? The ti-linux-3.14.y does not have any patches 
>> that aren't applied to the usb on 3.18.13.
>> 
>> The cpu port 1 is connected by a TI TUSB1106 usb transceiver
>> that is directly connected to a full-speed hub (TI USB2046) hub
>> so the OHCI driver is the only one in use.
>> 
>> Note, the ohci-omap3 is loaded as a module as this is how their 
>> user application expects to be able to shut down usb when it
>> does not need it.
>> 
>> The device tree configuration for the usb host:
> 
> and what exactly doesn't work ? That old OHCI driver hasn't been 
> touched in years, it's no surprise that it stopped working :-(
> 
> Anyway, what exactly doesn't work ? No device enumerates ? Do you 
> get any IRQs by plugging a new device in ?

I just found this in my backlog, and thought I should follow up with
the issue.

It turns out that even if we're not using the EHCI unit, the 120m
functional clock needs to be enabled. This may be down to an internal
routing of port signals, or the USB front-end needing it.

I've added a local boolean fix to enable the clock, and will post it
as soon as we've had a chance to review and document.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html