On Oct 19, 2011, at 5:06 AM, "Gupta, Ajay Kumar" <ajay.gupta@xxxxxx> wrote:
> Hi,
>> On Thu, Oct 13, 2011 at 12:50:55PM +0530, Gupta, Ajay Kumar wrote:
>>> We are facing an issue in AM335x based custom board which has two musb
>>> port.
>>>
>>> a) musb0 ID pin is floating and have micro-B plug receptacle
>>> connector. [DEVICE ONLY]
>>> b) musb1 ID pin is grounded and have standard-A plug receptacle
>>> connector. [HOST ONLY]
>>>
>>> We are using udc-core in linux v3.1-rc8 kernel. This kernel only
>>> provides option for selecting gadget driver for first instance only as
>>> builtin.
>>
>> why don't you mark all gadget drivers as modules ? I do that all the
>> time:
>
> This wouldn't help if we want to use musb1 (host only) port during bootup
> so that root file system on a pen drive connected to it can be mounted.
I don't think it hurts that use case as the host driver is enabled by the platform data without other sections of the kernel having it hard-coded to a port.
>
>>
>> CONFIG_USB_GADGET=m
>> CONFIG_USB_GADGET_DEBUG=y
>> CONFIG_USB_GADGET_DEBUG_FILES=y
>> CONFIG_USB_GADGET_DEBUG_FS=y
>> CONFIG_USB_GADGET_VBUS_DRAW=2
>> CONFIG_USB_R8A66597=m
>> CONFIG_USB_M66592=m
>> CONFIG_USB_AMD5536UDC=m
>> CONFIG_USB_CI13XXX_PCI=m
>> CONFIG_USB_NET2272=m
>> CONFIG_USB_NET2272_DMA=y
>> CONFIG_USB_NET2280=m
>> CONFIG_USB_GOKU=m
>> CONFIG_USB_EG20T=m
>> CONFIG_USB_DUMMY_HCD=m
>> CONFIG_USB_GADGET_DUALSPEED=y
>> CONFIG_USB_GADGET_SUPERSPEED=y
>> CONFIG_USB_ZERO=m
>> CONFIG_USB_ZERO_HNPTEST=y
>> CONFIG_USB_AUDIO=m
>> CONFIG_USB_ETH=m
>> CONFIG_USB_ETH_RNDIS=y
>> CONFIG_USB_ETH_EEM=y
>> CONFIG_USB_G_NCM=m
>> CONFIG_USB_GADGETFS=m
>> CONFIG_USB_FUNCTIONFS=m
>> CONFIG_USB_FUNCTIONFS_ETH=y
>> CONFIG_USB_FUNCTIONFS_RNDIS=y
>> CONFIG_USB_FUNCTIONFS_GENERIC=y
>> CONFIG_USB_FILE_STORAGE=m
>> CONFIG_USB_FILE_STORAGE_TEST=y
>> CONFIG_USB_MASS_STORAGE=m
>> CONFIG_USB_G_SERIAL=m
>> CONFIG_USB_MIDI_GADGET=m
>> CONFIG_USB_G_PRINTER=m
>> CONFIG_USB_CDC_COMPOSITE=m
>> CONFIG_USB_G_NOKIA=m
>> CONFIG_USB_G_MULTI=m
>> CONFIG_USB_G_MULTI_RNDIS=y
>> CONFIG_USB_G_MULTI_CDC=y
>> CONFIG_USB_G_HID=m
>> CONFIG_USB_G_DBGP=m
>> # CONFIG_USB_G_DBGP_PRINTK is not set
>> CONFIG_USB_G_DBGP_SERIAL=y
>> CONFIG_USB_G_WEBCAM=m
>>
>>> Current musb driver requires a gadget module to be inserted for a musb
>>> port to be usable in OTG mode which is the only mode available in
>>> v3.1-rc8 due to recent changes removing all HOST and GADGET only
>>> ifdeffery.
>>
>> You can add runtime checks based on platform_data. Something like:
>>
>> switch (pdata->mode) {
>> case MUSB_HOST:
>> start_host();
>> break;
>> case MUSB_PERIPHERAL:
>> start_gadget();
>> break;
>> case MUSB_OTG:
>> start_gadget()
>> start_host();
>> break;
>> default:
>> error();
>> }
>>
>> which means that for a port which is host-only, it won't require a
>> gadget driver and for a port which is gadget-only, it won't start host
>> stack.
>
> If so then how about the menuconfig option for gadget driver for such host
> only port? Shouldn't the gadget driver option be unavailable for such ports?
A menuconfig option would be taking things in the wrong direction as it would apply across platforms, which breaks the valid use-case of using the same kernel across multiple target systems. It seems to me what would block the loading of a gadget driver would be the fact that a valid host driver has been initialized for this port already.
Felipe, can you give a bit of clarity where this platform code would go and if these are existing functions or pseudo-functions we would need to create? How do we get the required code for start_host() to be there at boot time and how do we skip the initialization calls on ports that use gadget drivers?
>
>
>>
>>> Now for the custom board's musb1 port to be usable we have two option:
>>> 1) After bootup insert a gadget module and then use host
>> functionality.
>>> 2) Change the menuconfig logic and possibly udc-core layer so that it
>> provides option
>>> to select second gadget module as builtin.
>>
>> why built-in ?
>
> Already explained above.
It doesn't seem to be a good conclusion that it is a gadget driver that must be loaded and built-in for the host port.
>
>>
>>> 3) Change musb driver so that there is no need for gadget driver for
>>> host only ports. (may be based on musb->board_mode ?)
>>
>> yes.
>
> Doesn't seem to be a cleaner way as explained above the issue of gadget
> Driver coming in menuconfig for such ports.
Menuconfig is not a cleaner way relative to platform data. When FDT comes, this would be something expressed by platform data as well.
>
> Ajay
>>
>>> In there any plan to support option 2) or 3) above?
>>>
>>> Now the issue on our custom board is that we want root filesystem on
>>> MSC pen drive connected to musb1 port and this gadget limitation is
>>> stopping us to support this.
>>
>> well, patches are welcome ;-)
>>
>> --
>> balbi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
