Hello. Yusuf Caglar AKYUZ wrote:
i'm trying to get an USB-stick running on a DVEVM-alike hardware on a recent kernel, but the USB host appears to be plain dead.
I've digged a little into the kernel and my result is, that 'platform_driver_probe' in the end of 'musb_init' never ends calling 'musb_probe', thus resulting in the musb_driver being deregistered and ignored by the kernel.
Digging deeper, the 'platform_driver_probe' enumerates the 'platform' bus but fails to find any suiting device. Thus, from the sources, it appears as if the construction misses a 'platform_device' representing the USB host controller.
Because only the kernel and no hardware appears to be involved, it looks like a silly kernel configuration problem to me. I write to ask if someone knows the solution or could otherwise help.
I can produce the result with 'davinci_evm_dm644x_defconfig'.
You said DVEVM-alike, does it have i2c port expander as well for VBUS control?
There's much more wisdom in controlling DRVVBUS via plain GPIO than this horrible GPIO expander thing.
Absolutely.
In fact we're using GPIO in our own boards and:
1) DRVVBUS control must be board specific. 2) Simply passing GPIO with platform data is not enough because polarity may even change. 3) I guess we don't need a workqueue for direct GPIO control.
What is the best way to achieve these goals? Passing a function pointer via platform data to handle pin control at board* files, or passing GPIO number and polarity via platform data while using workqueue for all the cases?
I definitely think the first one is better.
Regards, Caglar
WBR, Sergei _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
