>-----Original Message----- >From: Bill Gatliff [mailto:bgat@xxxxxxxxxxxxxxx] >Sent: Monday, December 21, 2009 11:07 AM >To: Pandita, Vikram >Cc: Gadiyar, Anand; linux-omap@xxxxxxxxxxxxxxx; beagleboard@xxxxxxxxxxxxxxxx >Subject: Re: Anyone using an ISP1505? > >Pandita, Vikram wrote: >>> -----Original Message----- >>> From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Bill >>> Gatliff >>> Sent: Friday, December 18, 2009 1:11 PM >>> To: Gadiyar, Anand >>> Cc: linux-omap@xxxxxxxxxxxxxxx; beagleboard@xxxxxxxxxxxxxxxx >>> 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@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
