- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page
Zynq Linux USB Driver Customizat ion
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
06-05-2012 01:00 PM
My custom board needs to reset the USB PHY via GPIO and set the DRVVBUS_EXT bit in the USB PHY. I have done that by hacking in GPIO and ULPI code into ehci-xilinx-usbps.c. Not very elegant nor modular.
Is there a better way that would the design intent and structure of the driver?
I noticed that xusbps_usb2_platform_data has init and exit vectors. I haven't found any way to pass values for those vectors down to the driver. Those vectors do not appear to be used anywhere. How should they be used? Can I use them to handle the USB PHY reset GPIO?
Re: Zynq Linux USB Driver Customizat ion
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
06-06-2012 04:25 PM
Hi Norman,
I'm not a USB expert for sure and it's a bit complicated, but here's some thoughts.
Ideally we need that to be specified in the device tree, which GPIO to be used for resetting the USB phy as that's a problem for every unique board design.
I see what you mean about the init and exit vectors. I'll do some more digging on that.
You may need your own board specific file in arch/arm/mach-zynq to handle board unique stuff and for now you do hack in the reset of the USB phy there probably. I was going to do that for ours and have not got around to it as we're using u-boot to reset the phy, but need to do this also.
Thanks.
Re: Zynq Linux USB Driver Customizat ion
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
06-06-2012 10:00 PM
Thanks for the reply. No expert on USB either. I am not sure if reseting the USB PHY once in the board file on boot is ideal. I am guessing that the USB PHY reset should be under control of the driver and reset appropriately anytime after boot.
Putting all USB initializaiton in the board.c file would not quite work for me. I need to set the DRVVBUS_EXT bit for VBUS to be turned on in host mode. For that I need the access to the controllers ULPI viewport. And it must be done after the USB controller is brought up but before it is enabled. And only in HOST only mode. Note the USB PHYs from Texas Instruments seem to require both DRVVBUS and DRVVBUS_EXT set for VBUS to be turned on. Ideally, the Zynq USB controller should have a "TI" mode that would handle both bits.
I tried registering platform data with init and exit vectors initialized to my functions. I did this from the board.c file. The result is that I get two instances of the USB driver. My instance that fails to boot because it does not have all the device tree parameters. The second instance is from the device tree definition. It fails because the first instance has taken some resources it needs. I don't think it is possible to use device trees to initialize function pointers. Scalar values only?











