On 10/20/2010 12:23 PM, ext Felipe Contreras wrote:
On Wed, Oct 20, 2010 at 12:14 PM, Roger Quadros<roger.quadros@xxxxxxxxx> wrote:
On 10/20/2010 11:53 AM, ext felipe.contreras@xxxxxxxxx wrote:
On Wed, Oct 20, 2010 at 10:46 AM, Roger Quadros<roger.quadros@xxxxxxxxx>
wrote:
On 10/19/2010 05:33 PM, ext Felipe Contreras wrote:
On Tue, Oct 19, 2010 at 4:40 PM, Roger Quadros<roger.quadros@xxxxxxxxx>
wrote:
@@ -843,6 +841,7 @@ config USB_CDC_COMPOSITE
config USB_G_NOKIA
tristate "Nokia composite gadget"
depends on PHONET
+ depends on USB_GADGET_MUSB_HDRC
This is wrong. Is there a build problem or run-time problem without
this?
Try:
CONFIG_USB_G_NOKIA=y
CONFIG_USB_GADGET_MUSB_HDRC=n
At least g_nokia doesn't seem to work correctly on my N900.
It won't work on N900 because N900 has MUSB USB gadget controller and it
needs to be selected somehow while building for N900.
You should set CONFIG_USB_GADGET_MUSB_HDRC to y somewhere else while
building for N900 and not here because g_nokia is not MUSB specific.
How do you expect people to know that? The Kconfig should define what
USB_G_NOKIA needs to work, so that people can enable those things
without go Googling hunting for a workable defconfig. Right now people
can build g_nokia modules that don't work, and that shouldn't be
allowed by the Kconfig.
USB_G_NOKIA just needs a USB gadget controller to work. The gadget
controller used for the board should come from the board's Kconfig which
will ideally be supplied by the board's vendor.
Ok, but USB_OMAP is not supposed to work on the N900? (I tried and it didn't)
No it won't work. USB_OMAP was for older OMAP's. MUSB is on OMAP3 and later. But
MUSB is not limited to OMAP SoC.
For example, can't USB_GADGET_MUSB_HDRC be selected in MACH_NOKIA_RX51 in
arch/arm/mach-omap2/Kconfig? or is there a better place to put it?
I don't think so, because people might not want USB at all. The ideal
case would be for USB_GADGET_MUSB_HDRC to be selected automatically
when the user selects USB and USB_GADGET, but that's not happening
because USB_GADGET_OMAP is selected first (all the dependencies are
met).
Yes you are right. In think with the current setup (i.e. controller selection at
kconfig and limitation to one controller per config) we will never be able to
satisfy all users.
We might need to move to some kind of gadget controller framework and runtime
controller selection to solve this problem.
--
regards,
-roger
--
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
