Re: AM3517 usb host issue
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-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517 usb host issue
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.00] 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 0x1009 [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 0x1009 [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 0x1009 [ 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
AM3517 usb host issue
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.00] 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 0x1009
[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 0x1009
[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 0x1009
[ 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-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517 usb host issue
-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.00] 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 0x1009 [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 0x1009 [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 0x1009 [ 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
Re: AM3517 usb host issue
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.00] 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 0x1009 [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 0x1009 [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 0x1009 [ 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
Re: AM3517 usb host issue
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.00] 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 0x1009
[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 0x1009
[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 0x1009
[ 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
signature.asc
Description: Digital signature
