Anyone using an ISP1505?

GoogleGroups
1

Guys:

I'm working on an OMAP3530CUS board that uses an ISP1505 USB PHY, and I
haven't gotten much luck getting the kernel to recognize any USB
devices. No luck, actually. :slight_smile: My oscilloscope and the schematic say
that the hardware is wired up properly, I'm just wondering if anyone has
a similar configuration that's working for them--- and which kernel they
are using?

The only thing I'm a little concerned about is the possibility that the
"nop" transceiver isn't the right one for the ISP1505. I have seen
patches floating around that claim to support the ISP1504, which should
be compatible with the 1505 if the datasheet is to be believed; but
those patches were in the context of i.MX3x machines, and they also
depended on a "slim framework for external transceivers" patch that
AFAICT hasn't been merged anywhere despite having been posted back in June.

Said patches can be found here:

http://kerneltrap.org/mailarchive/linux-usb/2009/6/10/5909543

Anyone have any ideas on how to pursue this, before I start chasing a
solution down myself?

Thanks!!

b.g.

2

Hi,

3

I'm working on an OMAP3530CUS board that uses an ISP1505 USB PHY, and I
haven't gotten much luck getting the kernel to recognize any USB
devices. No luck, actually. :slight_smile: My oscilloscope and the schematic say
that the hardware is wired up properly, I'm just wondering if anyone has
a similar configuration that's working for them--- and which kernel they
are using?

Is it with the OTG controller or with the EHCI controller?

The NXP ISP1505 is supposed to be transparent - no programming usually
required.

If it's with the EHCI controller, you need to take care of a couple of
issues on the board (due to the input clocking mode used in the OMAP3).

- Anand

4

Gadiyar, Anand wrote:

I'm working on an OMAP3530CUS board that uses an ISP1505 USB PHY, and I
haven't gotten much luck getting the kernel to recognize any USB
devices. No luck, actually. :slight_smile: My oscilloscope and the schematic say
that the hardware is wired up properly, I'm just wondering if anyone has
a similar configuration that's working for them--- and which kernel they
are using?
    
Is it with the OTG controller or with the EHCI controller?
  
The pins of the ISP1505 are tied to pins T24, T23, and so on of the
OMAP3530CUS, which on my schematic are labeled UH0_D0, UH0_D1, etc.
That's EHCI, right? But I have both the EHCI and MUSB drivers enabled,
and both appear to initialize properly according to the kernel logs.

The NXP ISP1505 is supposed to be transparent - no programming usually
required.
  
That's what I thought. I have the "nop" transceiver driver installed.

If it's with the EHCI controller, you need to take care of a couple of
issues on the board (due to the input clocking mode used in the OMAP3).
  
Can you elaborate? Thanks!

b.g.

5

Felipe Balbi wrote:

is this with musb ? if it's musb, you need the nop transceiver. Do you
have any boot logs which you could share ? Without information on the
board, is a bit difficult :frowning:

Of course. Here is an excerpt from my dmesg output:

Linux version 2.6.33-rc1-06888-g7fa9fb6-dirty (bgat@mercury) (gcc
version 4.3.2 (Debian 4.3.2-1.1) ) #22 Fri Dec 18 18:58:00 UTC
2009
CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7),
cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction
cache
Machine: TBD
Memory policy: ECC disabled, Data cache
writeback
On node 0 totalpages:
32768

free_area_init_node: node 0, pgdat c0467a3c, node_mem_map
c0485000
  Normal zone: 256 pages used for
memmap
  Normal zone: 0 pages
reserved

  Normal zone: 32512 pages, LIFO
batch:7
OMAP3430/3530 ES3.0 (l2cache iva sgx neon isp
)
SRAM: Mapped pa 0x40200000 to va 0xfe400000 size:
0x100000
Built 1 zonelists in Zone order, mobility grouping on. Total pages:
32512
Kernel command line: root=nfs nfsroot=192.168.2.10:/exports/tbd rw
ip=192.168.2.168:192.168.2.10:192.168.2.1:255.255.255.0:tbd:eth0:off
console=ttyS1,115200n8
PID hash table entries: 512 (order: -1, 2048
bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536
bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768
bytes)
Memory: 128MB = 128MB
total

Memory: 125168KB available (3992K code, 310K data, 164K init, 0K
highmem)
Hierarchical RCU
implementation.

RCU-based detection of stalled CPUs is
enabled.
NR_IRQS:388

Clocking rate (Crystal/Core/MPU): 19.2/332/545
MHz
Reprogramming SDRC clock to 332000000
Hz
GPMC revision
5.0

IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96
interrupts
Total of 96 interrupts on 1 active
controller
OMAP GPIO hardware version
2.5
OMAP clockevent source: GPTIMER12 at 32768
Hz
Console: colour dummy device
80x30
Calibrating delay loop... 524.12 BogoMIPS
(lpj=2048000)
Mount-cache hash table entries:
512
CPU: Testing write buffer coherency:
ok
NET: Registered protocol family
16
mux: Setting signal mcbsp_clks.mcbsp_clks 0x0100 ->
0x0100
mux: Setting signal mcbsp2_fsx.mcbsp2_fsx 0x0018 ->
0x0100
mux: Setting signal mcbsp2_clkx.mcbsp2_clkx 0x0018 ->
0x0100
mux: Setting signal mcbsp2_dx.mcbsp2_dx 0x0018 ->
0x0000
mux: Setting signal mcbsp2_dr.mcbsp2_dr 0x0100 ->
0x0100
mux: Setting signal i2c1_scl.i2c1_scl 0x0118 ->
0x0118
mux: Setting signal i2c1_sda.i2c1_sda 0x0118 ->
0x0118
mux: Setting signal sys_clkout1.sys_clkout1 0x0100 ->
0x0000
mux: Setting signal hsusb0_clk.hsusb0_clk 0x0100 ->
0x0000
mux: Setting signal hsusb0_stp.hsusb0_stp 0x0018 ->
0x0000
mux: Setting signal hsusb0_dir.hsusb0_dir 0x0100 ->
0x0100
mux: Setting signal hsusb0_nxt.hsusb0_nxt 0x0100 ->
0x0100
mux: Setting signal hsusb0_data0.hsusb0_data0 0x0100 ->
0x0100
mux: Setting signal hsusb0_data1.hsusb0_data1 0x0100 ->
0x0100
mux: Setting signal hsusb0_data2.hsusb0_data2 0x0100 ->
0x0100
mux: Setting signal hsusb0_data3.hsusb0_data3 0x0100 ->
0x0100
mux: Setting signal hsusb0_data4.hsusb0_data4 0x0100 ->
0x0100
mux: Setting signal hsusb0_data5.hsusb0_data5 0x0100 ->
0x0100
mux: Setting signal hsusb0_data6.hsusb0_data6 0x0100 ->
0x0100
mux: Setting signal hsusb0_data7.hsusb0_data7 0x0100 ->
0x0100
mux: Setting signal mcbsp3_dx.gpio140 0x0004 ->
0x0004
mux: Setting signal etk_clk.hsusb1_stp 0x0018 ->
0x0003
mux: Setting signal etk_ctl.hsusb1_clk 0x0000 ->
0x0003
mux: Setting signal etk_d8.hsusb1_dir 0x0100 ->
0x010b
mux: Setting signal etk_d9.hsusb1_nxt 0x0100 ->
0x010b
mux: Setting signal etk_d0.hsusb1_data0 0x0100 ->
0x010b
mux: Setting signal etk_d1.hsusb1_data1 0x0100 ->
0x010b
mux: Setting signal etk_d2.hsusb1_data2 0x0108 ->
0x010b
mux: Setting signal etk_d7.hsusb1_data3 0x0100 ->
0x010b
mux: Setting signal etk_d4.hsusb1_data4 0x0100 ->
0x010b
mux: Setting signal etk_d5.hsusb1_data5 0x0100 ->
0x010b
mux: Setting signal etk_d6.hsusb1_data6 0x0100 ->
0x010b
mux: Setting signal etk_d3.hsusb1_data7 0x0100 ->
0x010b
mux: Setting signal etk_d11.hsusb2_stp 0x0100 ->
0x0003
mux: Setting signal etk_d10.hsusb2_clk 0x0100 ->
0x0003
mux: Setting signal etk_d12.hsusb2_dir 0x0100 ->
0x010b
mux: Setting signal etk_d13.hsusb2_nxt 0x0100 ->
0x010b
mux: Setting signal etk_d14.hsusb2_data0 0x0100 ->
0x010b
mux: Setting signal etk_d15.hsusb2_data1 0x0100 ->
0x010b
mux: Setting signal mcspi1_cs3.hsusb2_data2 0x011f ->
0x010b
mux: Setting signal mcspi2_cs1.hsusb2_data3 0x011c ->
0x010b
mux: Setting signal mcspi2_simo.hsusb2_data4 0x010f ->
0x010b
mux: Setting signal mcspi2_somi.hsusb2_data5 0x010f ->
0x010b
mux: Setting signal mcspi2_cs0.hsusb2_data6 0x011f ->
0x010b
mux: Setting signal mcspi2_clk.hsusb2_data7 0x010f ->
0x010b
OMAP DMA hardware revision
4.0
bio: create slab <bio-0> at
0
SCSI subsystem
initialized

omap2_mcspi omap2_mcspi.1: registered master
spi1
omap2_mcspi omap2_mcspi.2: registered master
spi2
omap2_mcspi omap2_mcspi.3: registered master
spi3
omap2_mcspi omap2_mcspi.4: registered master
spi4
usbcore: registered new interface driver
usbfs
usbcore: registered new interface driver
hub
usbcore: registered new device driver
usb
i2c_omap i2c_omap.1: bus 1 rev3.12 at 100
kHz
Switching to clocksource
32k_counter
musb_hdrc: version 6.0, musb-dma, host,
debug=0
musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine (X), bulk
split (X), HB-ISO Rx, HB-ISO Tx,
SoftConn)

musb_hdrc: MHDRC RTL version
1.400
musb_hdrc: setup fifo_mode
4
musb_hdrc: 28/31 max ep, 16384/16384
memory
musb_hdrc: USB Host mode controller at fa0ab000 using DMA, IRQ
92
musb_hdrc musb_hdrc: MUSB HDRC host
driver
musb_hdrc musb_hdrc: new USB bus registered, assigned bus number
1
usb usb1: default language
0x0409
usb usb1: udev 1, busnum 1, minor =
0
usb usb1: New USB device found, idVendor=1d6b,
idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
usb usb1: Product: MUSB HDRC host
driver
usb usb1: Manufacturer: Linux 2.6.33-rc1-06888-g7fa9fb6-dirty
musb-hcd
usb usb1: SerialNumber:
musb_hdrc
usb usb1:
uevent

usb usb1:
usb_probe_device

usb usb1: configuration #1 chosen from 1
choice
usb usb1: adding 1-0:1.0 (config #1, interface
0)
usb 1-0:1.0:
uevent

hub 1-0:1.0:
usb_probe_interface

hub 1-0:1.0: usb_probe_interface - got
id
hub 1-0:1.0: USB hub
found

hub 1-0:1.0: 1 port
detected

hub 1-0:1.0: standalone
hub
hub 1-0:1.0: individual port power
switching
hub 1-0:1.0: no over-current
protection
hub 1-0:1.0: power on to power good time:
10ms
hub 1-0:1.0: 100mA bus power budget for each
child
hub 1-0:1.0: local power source is
good
hub 1-0:1.0: enabling power on all
ports
NET: Registered protocol family
2
IP route cache hash table entries: 1024 (order: 0, 4096
bytes)
TCP established hash table entries: 4096 (order: 3, 32768
bytes)
TCP bind hash table entries: 4096 (order: 2, 16384
bytes)
TCP: Hash tables configured (established 4096 bind
4096)
TCP reno
registered

UDP hash table entries: 256 (order: 0, 4096
bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096
bytes)
NET: Registered protocol family
1
RPC: Registered udp transport
module.
RPC: Registered tcp transport
module.
RPC: Registered tcp NFSv4.1 backchannel transport
module.
NetWinder Floating Point Emulator V0.97 (double
precision)
VFS: Disk quotas
dquot_6.5.2

Dquot-cache hash table entries: 1024 (order 0, 4096
bytes)
JFFS2 version 2.2. (NAND) � 2001-2006 Red Hat,
Inc.
msgmni has been set to
244

alg: No test for stdrng
(krng)
io scheduler noop
registered

io scheduler deadline
registered

io scheduler cfq registered
(default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing
enabled
serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a
ST16654
serial8250.1: ttyS1 at MMIO 0x4806c000 (irq = 73) is a
ST16654
console [ttyS1]
enabled

hub 1-0:1.0: state 7 ports 1 chg 0000 evt
0000
serial8250.2: ttyS2 at MMIO 0x49020000 (irq = 74) is a
ST16654
brd: module
loaded

loop: module
loaded

PPP generic driver version
2.4.2
PPP Deflate Compression module
registered
PPP BSD Compression module
registered
NET: Registered protocol family
24
smsc911x: Driver version
2008-10-21.
smsc911x-mdio:
probed

eth0: attached PHY driver [SMSC LAN8700] (mii_bus:phy_addr=ffffffff:01,
irq=-1)
net eth0: MAC Address:
46:66:17:ff:76:af

console [netcon0]
enabled

netconsole: network logging
started
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI)
Driver
ehci_hcd: block sizes: qh 60 qtd 96 itd 160 sitd
96
ehci-omap ehci-omap.0: starting TI EHCI USB
Controller
ehci-omap ehci-omap.0: TLL RESET
DONE
ehci-omap ehci-omap.0: OMAP3 ES version >
ES2.1
ehci-omap ehci-omap.0: UHH setup done,
uhh_hostconfig=31c
ehci-omap ehci-omap.0: OMAP-EHCI Host
Controller
ehci-omap ehci-omap.0: new USB bus registered, assigned bus number
2
ehci-omap ehci-omap.0: park
0
ehci-omap ehci-omap.0: irq 77, io mem
0x48064800
ehci-omap ehci-omap.0: reset command 090b02 park=3 ithresh=9 period=1024
Reset HALT
ehci-omap ehci-omap.0: init command 010009 (park)=0 ithresh=1 period=256
RUN
ehci-omap ehci-omap.0: USB 2.0 started, EHCI
1.00
usb usb2: default language
0x0409
usb usb2: udev 1, busnum 2, minor =
128
usb usb2: New USB device found, idVendor=1d6b,
idProduct=0002
usb usb2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
usb usb2: Product: OMAP-EHCI Host
Controller
usb usb2: Manufacturer: Linux 2.6.33-rc1-06888-g7fa9fb6-dirty
ehci_hcd
usb usb2: SerialNumber:
ehci-omap.0
usb usb2:
uevent

usb usb2:
usb_probe_device

usb usb2: configuration #1 chosen from 1
choice
usb usb2: adding 2-0:1.0 (config #1, interface
0)
usb 2-0:1.0:
uevent

hub 2-0:1.0:
usb_probe_interface

hub 2-0:1.0: usb_probe_interface - got
id
hub 2-0:1.0: USB hub
found

hub 2-0:1.0: 3 ports
detected

hub 2-0:1.0: standalone
hub
hub 2-0:1.0: individual port power
switching
hub 2-0:1.0: individual port over-current
protection
hub 2-0:1.0: power on to power good time:
20ms
hub 2-0:1.0: local power source is
good
hub 2-0:1.0: enabling power on all ports
i2c /dev entries driver
OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
Advanced Linux Sound Architecture Driver Version 1.0.21.
No device for DAI omap-mcbsp-dai-0
No device for DAI omap-mcbsp-dai-1
No device for DAI omap-mcbsp-dai-2
No device for DAI omap-mcbsp-dai-3
No device for DAI omap-mcbsp-dai-4
asoc: WM8731 <-> omap-mcbsp-dai-0 mapping ok
ALSA device list:
  #0: tbd (WM8731)
TCP cubic registered
NET: Registered protocol family 17
NET: Registered protocol family 15
Power Management for TI OMAP3.
VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
hub 2-0:1.0: state 7 ports 3 chg 0000 evt 0000
net eth0: SMSC911x/921x identified at 0xc88ae000, IRQ: 222
IP-Config: Complete:
     device=eth0, addr=192.168.2.168, mask=255.255.255.0, gw=192.168.2.1,
     host=tbd, domain=, nis-domain=(none),
     bootserver=192.168.2.10, rootserver=192.168.2.10, rootpath=
Looking up port of RPC 100003/2 on 192.168.2.10
hub 1-0:1.0: hub_suspend
usb usb1: bus auto-suspend
hub 2-0:1.0: hub_suspend
usb usb2: bus auto-suspend
ehci-omap ehci-omap.0: suspend root hub
Looking up port of RPC 100005/1 on 192.168.2.10
VFS: Mounted root (nfs filesystem) on device 0:12.
Freeing init memory: 164K
usb usb2: uevent
usb 2-0:1.0: uevent
usb usb1: uevent
usb 1-0:1.0: uevent
usb usb1: uevent
usb usb2: uevent
usb usb2: uevent
usb 2-0:1.0: uevent
usb usb1: uevent
usb 1-0:1.0: uevent

6

From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Bill
Gatliff
Sent: Friday, December 18, 2009 1:11 PM
To: Gadiyar, Anand
Cc: linux-omap@vger.kernel.org; beagleboard@googlegroups.com
Subject: Re: Anyone using an ISP1505?

<snip>

If it's with the EHCI controller, you need to take care of a couple of
issues on the board (due to the input clocking mode used in the OMAP3).

Can you elaborate? Thanks!

For omap-ehci, the OMAP feeds in the 60Mhz clock to the PHY(1505 in your case).
This is the input clocking mode of phy.

It looks like the PHY state machine requires sometime to stabilize and lock into this 60Mhz clock input and this is done with a GPIO form omap.

In ehci_hcd_omap_platform_data, Typically boards have
. phy_reset = true
. reset_gpio_port[0] = GPIO going to phy reset pin

On your board you need to find, if there is a GPIO hooked from omap to PHY.
And the GPIO behavior is decided by the PHY pin property ( whether its active high/low and whether its chipselect or reset of phy).

By default the code assumes that the GPIO is connected to RESET pin: going 0 while the 60mhz clock input stabilizes and then once done, make it 1.

So find out what GPIO from omap is connected to phy to control the phy.

7

>
> Is it with the OTG controller or with the EHCI controller?
>

The pins of the ISP1505 are tied to pins T24, T23, and so on of the
OMAP3530CUS, which on my schematic are labeled UH0_D0, UH0_D1, etc.
That's EHCI, right? But I have both the EHCI and MUSB drivers enabled,
and both appear to initialize properly according to the kernel logs.

T23, T24, ... on the CUS package are for MUSB (the signals are hsusb0_*).

EHCI is hsusb[1-3]_*.

NOP XCEIV is what you should be using. I'm not sure why it is not working
for you. One of the OMAP3 EVM boards uses an NXP ISP1504 here, and it
should be very similar to what you're using.

Do you see a clock signal on R21 (UH0_CLK in your schematic I suppose)?

> If it's with the EHCI controller, you need to take care of a couple of
> issues on the board (due to the input clocking mode used in the OMAP3).
>

Can you elaborate? Thanks!

Forget this, since you're using MUSB.

- Anand

8

Pandita, Vikram wrote:

From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Bill
Gatliff
Sent: Friday, December 18, 2009 1:11 PM
To: Gadiyar, Anand
Cc: linux-omap@vger.kernel.org; beagleboard@googlegroups.com
Subject: Re: Anyone using an ISP1505?

<snip>
  

If it's with the EHCI controller, you need to take care of a couple of
issues on the board (due to the input clocking mode used in the OMAP3).

Can you elaborate? Thanks!

For omap-ehci, the OMAP feeds in the 60Mhz clock to the PHY(1505 in your case).
This is the input clocking mode of phy.

It looks like the PHY state machine requires sometime to stabilize and lock into this 60Mhz clock input and this is done with a GPIO form omap.

In ehci_hcd_omap_platform_data, Typically boards have
. phy_reset = true
. reset_gpio_port[0] = GPIO going to phy reset pin

On your board you need to find, if there is a GPIO hooked from omap to PHY.
And the GPIO behavior is decided by the PHY pin property ( whether its active high/low and whether its chipselect or reset of phy).

By default the code assumes that the GPIO is connected to RESET pin: going 0 while the 60mhz clock input stabilizes and then once done, make it 1.

So find out what GPIO from omap is connected to phy to control the phy.
  
Ok, I'll look at that. I'm not sure if I have such a GPIO pin going to
the PHY.

I do have the XTAL input tied to SYS_CLK1/GPIO_10, and I've verified
that I'm sending out a 19.2MHz clock signal on that pin. That seems to
be what the ISP1505ABS chip needs. I start that clock in my board setup
code.

I just re-re-re-read the ISP1505 datasheet, and noticed this remark:

    "Remark: When CLOCK starts toggling after power-up, the USB link
    must issue a reset command over the ULPI bus to ensure correct
    operation of the ISP1505".

I see in drivers/usb/host/ehci-omap.c where the TLL is reset, but I
can't find any code that sends a ULPI reset command out over the link.
Or am I missing something?

I also see drivers/usb/otg/ulpi.c which claims to support the ISP1504,
which is a very similar chip to the ISP1505. But it also lacks any
mention of a ULPI reset-type command.

Any additional thoughts? I'm losing hair fast on this one.... :slight_smile:

b.g.

9

From: Bill Gatliff [mailto:bgat@billgatliff.com]
Sent: Monday, December 21, 2009 11:07 AM
To: Pandita, Vikram
Cc: Gadiyar, Anand; linux-omap@vger.kernel.org; beagleboard@googlegroups.com
Subject: Re: Anyone using an ISP1505?

Pandita, Vikram wrote:

From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Bill
Gatliff
Sent: Friday, December 18, 2009 1:11 PM
To: Gadiyar, Anand
Cc: linux-omap@vger.kernel.org; beagleboard@googlegroups.com
Subject: Re: Anyone using an ISP1505?

<snip>

If it's with the EHCI controller, you need to take care of a couple of
issues on the board (due to the input clocking mode used in the OMAP3).

Can you elaborate? Thanks!

For omap-ehci, the OMAP feeds in the 60Mhz clock to the PHY(1505 in your case).
This is the input clocking mode of phy.

It looks like the PHY state machine requires sometime to stabilize and lock into this 60Mhz clock

input and this is done with a GPIO form omap.

In ehci_hcd_omap_platform_data, Typically boards have
. phy_reset = true
. reset_gpio_port[0] = GPIO going to phy reset pin

On your board you need to find, if there is a GPIO hooked from omap to PHY.
And the GPIO behavior is decided by the PHY pin property ( whether its active high/low and whether

its chipselect or reset of phy).

By default the code assumes that the GPIO is connected to RESET pin: going 0 while the 60mhz clock

input stabilizes and then once done, make it 1.

So find out what GPIO from omap is connected to phy to control the phy.

Ok, I'll look at that. I'm not sure if I have such a GPIO pin going to
the PHY.

Bill
There is a basic confusion whether you are using MUSB OTG core of omap
Or are you using EHCI core of omap.

Both can be connected to a ULPI PHY and so you need to be very precise?

I do have the XTAL input tied to SYS_CLK1/GPIO_10, and I've verified
that I'm sending out a 19.2MHz clock signal on that pin. That seems to
be what the ISP1505ABS chip needs. I start that clock in my board setup
code.

I just re-re-re-read the ISP1505 datasheet, and noticed this remark:

   "Remark: When CLOCK starts toggling after power-up, the USB link
   must issue a reset command over the ULPI bus to ensure correct
   operation of the ISP1505".

I see in drivers/usb/host/ehci-omap.c where the TLL is reset, but I
can't find any code that sends a ULPI reset command out over the link.
Or am I missing something?

I also see drivers/usb/otg/ulpi.c which claims to support the ISP1504,
which is a very similar chip to the ISP1505. But it also lacks any
mention of a ULPI reset-type command.

ULPI reset is implemented in hardware. No s/w intervention is required for this feature.
As soon as 60Mhz clock starts, and iclocks are enabled to the USB core of omap, the ULPI reset goes on the ULPI bus.

No surprise you are not finding this code, as there is none.

10

Pandita, Vikram wrote:

Bill
There is a basic confusion whether you are using MUSB OTG core of omap
Or are you using EHCI core of omap.

Both can be connected to a ULPI PHY and so you need to be very precise?
  
I'm on the CUS package, and the D0 pin of the PHY is tied to pad T24 of
the OMAP3530. That's the ULPI D0 for EHCI, right?

If the pad can be multiplexed between both MUSB and EHCI, how can I tell
which one is connected there now? For that matter, where in the
mountains of OMAP3xxx documentation does it say which controller the UH0
pins are tied to? I haven't found it yet...

Thanks!

b.g.

11

Bill Gatliff wrote:

Pandita, Vikram wrote:
> Bill
> There is a basic confusion whether you are using MUSB OTG core of omap
> Or are you using EHCI core of omap.
>
> Both can be connected to a ULPI PHY and so you need to be very precise?
>

I'm on the CUS package, and the D0 pin of the PHY is tied to pad T24 of
the OMAP3530. That's the ULPI D0 for EHCI, right?

No confusion for me. I took the liberty of looking this up, and for
this package, T24 is D0 for MUSB, not EHCI.

If the pad can be multiplexed between both MUSB and EHCI, how can I tell
which one is connected there now?

No pad in the OMAP3 is multiplexed between both MUSB and EHCI; HSUSB0
is MUSB (this makes sense, since most users of the OMAP3 would like
to use the OMAP3 as a USB peripheral, and there is only one peripheral
controller, so the MUSB lines are usually not switches to other roles.

EHCI on the other hand is on HSUSB1 to HSUSB3 (there are 3 ports).

For that matter, where in the mountains of OMAP3xxx documentation
does it say which controller the UH0 pins are tied to? I haven't
found it yet...

Well, in the USB chapter of the OMAP3 TRM, the very first figure
(24.1 - USB modules overview) shows this clearly. Port0 is MUSB,
and Ports 1-3 are HSUSB Host.

Hope this helps,
Anand

12

Hi,

13

Felipe Balbi wrote:

Hi,

>Bill Gatliff wrote:
>>
>> Pandita, Vikram wrote:
>> > Bill
>> > There is a basic confusion whether you are using MUSB OTG core of omap
>> > Or are you using EHCI core of omap.
>> >
>> > Both can be connected to a ULPI PHY and so you need to be very precise?
>> >
>>
>> I'm on the CUS package, and the D0 pin of the PHY is tied to pad T24 of
>> the OMAP3530. That's the ULPI D0 for EHCI, right?
>>
>
>No confusion for me. I took the liberty of looking this up, and for
>this package, T24 is D0 for MUSB, not EHCI.
>
>
>> If the pad can be multiplexed between both MUSB and EHCI, how can I tell
>> which one is connected there now?
>
>
>No pad in the OMAP3 is multiplexed between both MUSB and EHCI; HSUSB0
>is MUSB (this makes sense, since most users of the OMAP3 would like
>to use the OMAP3 as a USB peripheral, and there is only one peripheral
>controller, so the MUSB lines are usually not switches to other roles.
>
>
>EHCI on the other hand is on HSUSB1 to HSUSB3 (there are 3 ports).
>
>
>> For that matter, where in the mountains of OMAP3xxx documentation
>> does it say which controller the UH0 pins are tied to? I haven't
>> found it yet...
>
>Well, in the USB chapter of the OMAP3 TRM, the very first figure
>(24.1 - USB modules overview) shows this clearly. Port0 is MUSB,
>and Ports 1-3 are HSUSB Host.

Are you just missing to call usb_nop_xceiv_register() ??

can you attach your .config file to the mail ??

And maybe a boot log also?

-Anand