Re: Enabling HSUSB1 port on OMAP3430 labrador

[Kovacs Peter Tamas <p.kovacs@holografika.com>]

Dear Anand, All,

>>> We are trying to make the HSUSB1 port on the OMAP3430 work as an USB 
>>> host.
>>> To do that, an ISP1507A ULPI HighSpeed USB transceiver is connected 
>>> to the HSUSB1pins (HSUSB1_STP, CLK, D-0..D7, DIR, NXT).
>>>
>>> I have all these USB related kernel config options enabled:
>>> USB_EHCI_HCD
>>> USB_OHCI_HCD
>>> USB_MUSB_HDRC
>>> TWL4030_USB
>>>
>>> My guess was that either EHCI or the Inventra should be the one 
>>> enabling that USB port on the OMAP, but no luck.
>>> The external USB port on the MDK works fine with this configuration.
>>>
>>> The pin multiplexing configuration in the board file 
>>> omap3430-labrador.c in u-boot also seems to be correct (although the 
>>> config of USB1_STP seems to be strange, but changing that didn't 
>>> work either).  
>> Not sure why the pad conf is done in u-boot for this board, but maybe
>> it was a copy-paste thing. That being said, if you've got the part
>> installed correctly, it ought to work.
>>   
> Yes, I can also see these pin multiplexing configs in 
> arch/arm/mach-omap2/usb-ehci.c.
> I have defined CONFIG_OMAP_EHCI_PHY_MODE there to make sure they are 
> PHY (couldn't find it in menuconfig, but this macro seems to be used 
> in this single file).
> Still, the clock goes high when powering the board on, and it remains 
> there forever.
>
> I recall seeing a TI-specific kernel source in another git repository, 
> which had menuconfig options for setting PHY/TLL, maybe the USB code 
> is different too?
After having no clock signal on the HSUSB1_CLK with the kernel pulled 
from from git.kernel.org/linux/kernel/linux-omap-2.6.git, I've tried 
some older ti-2.6.xx kernel branches from 
git.omapzoom.org/repo/omapkernel.git

branch ti-2.6.27-omap3 didn't compile.
branch ti-2.6.26-omap3 kind of works, but the HSUSB1_CLK is still dead.
branch ti-2.6.24-omap3 works, and during booting I can see a clock 
signal on HSUSB1_CLK, and also the STP signal seems to go high and back 
low as expected!

Is it possible that this feature is broken some months ago? I'll go and 
compare the relevant files, but your suggestions on how to make this 
work again in newer kernels are welcome.

Thanks,
Peter