[U-Boot] [PATCH RFC] OMAP5: uEVM: Enable USB EHCI functionality (preliminary, not tested)

Lubomir Popov
2013-05-16T08:23:00Z

Hi Tom,

Thanks for testing. One more thing needs fixing, my fault.
I forgot that the mux_data.h file comes from the sEVM w/o
any modification. Not only USB shall not work...

Fix is in http://patchwork.ozlabs.org/patch/244233/

Please see comments inline below.

On 16/05/13 01:06, Tom Rini wrote:
> On Wed, May 15, 2013 at 06:55:24PM +0300, Lubomir Popov wrote:
>
>> Prerequisites: appropriate patches to the USB EHCI and Eth
>> drivers, and to the OMAP5 clock register definitions.
>>
>> Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>
>> ---
>> Assumption is that this code shall run on TI 750-2628-21X
>> hardware (also known as OMAP5432 ES2.0 PandaBoard5) - the
>> GPIOs that I used used for HSIC reset correspond to that
>> board. Looking at mux_data.h however, I'm somewhat concerned.
>> All the uevm board files are inherited from the sEVM, which
>> is a very different hardware platform, and I'm afraid that
>> only changing the file names might not be sufficient.
>>
>> The patch is not tested yet due to lack of hardware. Tom,
>> I'm hoping for your assistance.
>
> OK, I applied:
> $ git log --oneline master..
> 93460ef OMAP4/5: Add USB EHCI support
> d18c49c OMAP5: Enable USB Ethernet support with LAN9730
> 15a4481 OMAP5: Enable access to auxclk registers
> f307fc2 OMAP5: Power: Add more functionality to Palmas driver
> efdf00c OMAP5: uEVM: Enable USB EHCI functionality (preliminary, not tested)
> And added:
> +#define CONFIG_USB_ULPI
> +#define CONFIG_USB_ULPI_VIEWPORT_OMAP
> to include/configs/omap5_uevm.h
Actually not needed at all for this board - it does not have any
ULPI PHYs. We shall just get dead code.
>
> And usb start/usb rescan don't see any devices.
> OMAP5432 uEVM # usb start
> (Re)start USB...
> USB0: USB EHCI 1.00
> scanning bus 0 for devices... 1 USB Device(s) found
> scanning usb for storage devices... 0 Storage Device(s) found
> scanning usb for ethernet devices... 0 Ethernet Device(s) found
>
> Cable was plugged into the eth and a storage device was also plugged in.
> I suspect that we need to set CONFIG_OMAP_EHCI_PHY1_RESET_GPIO /
> CONFIG_OMAP_EHCI_PHY2_RESET_GPIO. I'm looking around for the schematic
> so I can try and find that out.
No. This is for ULPI PHY reset only, we are using CONFIG_OMAP_HSIC_PORT2_RESET_GPIO
and CONFIG_OMAP_HSIC_PORT3_RESET_GPIO for the HSIC devices. The problem is that
these pads were not configured to GPIO mode. Above patch fixes this.
>
Best regards,
Lubo