* Anyone using an ISP1505? @ 2009-12-17 19:01 Bill Gatliff 2009-12-17 19:10 ` Felipe Balbi 2009-12-17 19:20 ` Gadiyar, Anand 0 siblings, 2 replies; 13+ messages in thread From: Bill Gatliff @ 2009-12-17 19:01 UTC (permalink / raw) To: linux-omap@vger.kernel.org, beagleboard 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. :) 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. -- Bill Gatliff bgat@billgatliff.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Anyone using an ISP1505? 2009-12-17 19:01 Anyone using an ISP1505? Bill Gatliff @ 2009-12-17 19:10 ` Felipe Balbi 2009-12-18 19:13 ` Bill Gatliff 2009-12-17 19:20 ` Gadiyar, Anand 1 sibling, 1 reply; 13+ messages in thread From: Felipe Balbi @ 2009-12-17 19:10 UTC (permalink / raw) To: ext Bill Gatliff; +Cc: linux-omap@vger.kernel.org, beagleboard@googlegroups.com Hi, On Thu, Dec 17, 2009 at 08:01:15PM +0100, ext Bill Gatliff 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. :) 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? 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 :-( -- balbi ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Anyone using an ISP1505? 2009-12-17 19:10 ` Felipe Balbi @ 2009-12-18 19:13 ` Bill Gatliff 0 siblings, 0 replies; 13+ messages in thread From: Bill Gatliff @ 2009-12-18 19:13 UTC (permalink / raw) To: felipe.balbi; +Cc: linux-omap@vger.kernel.org, beagleboard@googlegroups.com 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 :-( 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 -- Bill Gatliff bgat@billgatliff.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Anyone using an ISP1505? 2009-12-17 19:01 Anyone using an ISP1505? Bill Gatliff 2009-12-17 19:10 ` Felipe Balbi @ 2009-12-17 19:20 ` Gadiyar, Anand 2009-12-18 19:10 ` Bill Gatliff 1 sibling, 1 reply; 13+ messages in thread From: Gadiyar, Anand @ 2009-12-17 19:20 UTC (permalink / raw) To: Bill Gatliff, linux-omap@vger.kernel.org, beagleboard@googlegroups.com > 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. :) 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Anyone using an ISP1505? 2009-12-17 19:20 ` Gadiyar, Anand @ 2009-12-18 19:10 ` Bill Gatliff 2009-12-18 19:20 ` Pandita, Vikram 2009-12-19 10:05 ` Gadiyar, Anand 0 siblings, 2 replies; 13+ messages in thread From: Bill Gatliff @ 2009-12-18 19:10 UTC (permalink / raw) To: Gadiyar, Anand; +Cc: linux-omap@vger.kernel.org, beagleboard@googlegroups.com 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. :) 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. -- Bill Gatliff bgat@billgatliff.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Anyone using an ISP1505? 2009-12-18 19:10 ` Bill Gatliff @ 2009-12-18 19:20 ` Pandita, Vikram 2009-12-21 17:06 ` Bill Gatliff 2009-12-19 10:05 ` Gadiyar, Anand 1 sibling, 1 reply; 13+ messages in thread From: Pandita, Vikram @ 2009-12-18 19:20 UTC (permalink / raw) To: Bill Gatliff, Gadiyar, Anand Cc: linux-omap@vger.kernel.org, beagleboard@googlegroups.com >-----Original Message----- >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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Anyone using an ISP1505? 2009-12-18 19:20 ` Pandita, Vikram @ 2009-12-21 17:06 ` Bill Gatliff 2009-12-21 19:43 ` Pandita, Vikram 0 siblings, 1 reply; 13+ messages in thread From: Bill Gatliff @ 2009-12-21 17:06 UTC (permalink / raw) To: Pandita, Vikram Cc: Gadiyar, Anand, linux-omap@vger.kernel.org, beagleboard@googlegroups.com Pandita, Vikram wrote: >> -----Original Message----- >> 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.... :) b.g. -- Bill Gatliff bgat@billgatliff.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Anyone using an ISP1505? 2009-12-21 17:06 ` Bill Gatliff @ 2009-12-21 19:43 ` Pandita, Vikram 2009-12-21 19:47 ` Bill Gatliff 0 siblings, 1 reply; 13+ messages in thread From: Pandita, Vikram @ 2009-12-21 19:43 UTC (permalink / raw) To: Bill Gatliff Cc: Gadiyar, Anand, linux-omap@vger.kernel.org, beagleboard@googlegroups.com >-----Original Message----- >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: >>> -----Original Message----- >>> 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. > > >Any additional thoughts? I'm losing hair fast on this one.... :) > > >b.g. > >-- >Bill Gatliff >bgat@billgatliff.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Anyone using an ISP1505? 2009-12-21 19:43 ` Pandita, Vikram @ 2009-12-21 19:47 ` Bill Gatliff 2009-12-21 20:12 ` Gadiyar, Anand 0 siblings, 1 reply; 13+ messages in thread From: Bill Gatliff @ 2009-12-21 19:47 UTC (permalink / raw) To: Pandita, Vikram Cc: Gadiyar, Anand, linux-omap@vger.kernel.org, beagleboard@googlegroups.com 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. -- Bill Gatliff bgat@billgatliff.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Anyone using an ISP1505? 2009-12-21 19:47 ` Bill Gatliff @ 2009-12-21 20:12 ` Gadiyar, Anand 2009-12-21 20:42 ` Felipe Balbi 0 siblings, 1 reply; 13+ messages in thread From: Gadiyar, Anand @ 2009-12-21 20:12 UTC (permalink / raw) To: Bill Gatliff, Pandita, Vikram Cc: linux-omap@vger.kernel.org, beagleboard@googlegroups.com 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Anyone using an ISP1505? 2009-12-21 20:12 ` Gadiyar, Anand @ 2009-12-21 20:42 ` Felipe Balbi 2009-12-21 20:57 ` Gadiyar, Anand 0 siblings, 1 reply; 13+ messages in thread From: Felipe Balbi @ 2009-12-21 20:42 UTC (permalink / raw) To: ext Gadiyar, Anand Cc: Bill Gatliff, Pandita, Vikram, linux-omap@vger.kernel.org, beagleboard@googlegroups.com Hi, On Mon, Dec 21, 2009 at 09:12:15PM +0100, ext Gadiyar, Anand wrote: >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 ?? -- balbi ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Anyone using an ISP1505? 2009-12-21 20:42 ` Felipe Balbi @ 2009-12-21 20:57 ` Gadiyar, Anand 0 siblings, 0 replies; 13+ messages in thread From: Gadiyar, Anand @ 2009-12-21 20:57 UTC (permalink / raw) To: felipe.balbi@nokia.com Cc: Bill Gatliff, Pandita, Vikram, linux-omap@vger.kernel.org, beagleboard@googlegroups.com Felipe Balbi wrote: > Hi, > > On Mon, Dec 21, 2009 at 09:12:15PM +0100, ext Gadiyar, Anand wrote: > >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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Anyone using an ISP1505? 2009-12-18 19:10 ` Bill Gatliff 2009-12-18 19:20 ` Pandita, Vikram @ 2009-12-19 10:05 ` Gadiyar, Anand 1 sibling, 0 replies; 13+ messages in thread From: Gadiyar, Anand @ 2009-12-19 10:05 UTC (permalink / raw) To: Bill Gatliff; +Cc: linux-omap@vger.kernel.org, beagleboard@googlegroups.com > > > > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2009-12-21 20:59 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-12-17 19:01 Anyone using an ISP1505? Bill Gatliff 2009-12-17 19:10 ` Felipe Balbi 2009-12-18 19:13 ` Bill Gatliff 2009-12-17 19:20 ` Gadiyar, Anand 2009-12-18 19:10 ` Bill Gatliff 2009-12-18 19:20 ` Pandita, Vikram 2009-12-21 17:06 ` Bill Gatliff 2009-12-21 19:43 ` Pandita, Vikram 2009-12-21 19:47 ` Bill Gatliff 2009-12-21 20:12 ` Gadiyar, Anand 2009-12-21 20:42 ` Felipe Balbi 2009-12-21 20:57 ` Gadiyar, Anand 2009-12-19 10:05 ` Gadiyar, Anand
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.