Hello!
On Apr 29, 2011, at 5:21 AM, Felipe Balbi wrote:
>> On Apr 28, 2011, at 2:14 AM, Mike Rapoport wrote:
>>>>>> +static struct omap_musb_board_data musb_board_data = {
>>>>>> + .interface_type = MUSB_INTERFACE_ULPI,
>>>>>> +#ifdef CONFIG_USB_MUSB_OTG
>>>>>> + .mode = MUSB_OTG,
>>>>>> +#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
>>>>>> + .mode = MUSB_HOST,
>>>>>> +#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
>>>>>> + .mode = MUSB_PERIPHERAL,
>>>>>> +#endif
>>>>> This kind of ifdefery is handled inside the musb driver. I'd set the mode to
>>>>> MUSB_OTG unless you want to explicitly limit it to HOST or PERIPHERAL
>>>> Actually it's not.
>>>> If I set MUSB_OTG here and then I choose PERIPHERAL mode in the kernel config,
>>>> the musb transceiver code will complain about board file and kernel config mismatch.
>>>> The Nook Color is advertised as peripheral device, but OTG must be working too
>>>> (not totally working at this point) I think there is value to be able to configure it
>>>> in two different modes.
>>> Frankly, I haven't tried choosing different modes in the kernel config and in
>>> the board data. Still, I believe that board data should define desired operation
>>> mode and the driver should do the best effort to enable the controller in the
>>> desired mode.
>> The desired operation mode is dependent on musb configuration.
>> E.g. see n8x0 board file for the example of the same thing.
> Only development platforms should have that ifdef trickery. The idea of
> that field is to tell the driver how the board is wired.
> Host/Peripheral/OTG support is hardwired by the circuitry around the
> USB receptacle you have on your board.
I am raising this again, I guess.
So what is the plan with boards that are not advertised as having USB host support,
but it's still possible to enable it with some trickery?
Say on the Nook Color it's possible and I recently managed to do it, but it seems current
drivers/usb/otg/twl4030-usb.c does not have any code to enable vbus (well, easy to overcome
with a patch, I guess). Additional hacks are likely needed since ID pin is not
connected in the usb receptacle, so no way to have real OTG, manual switch via sysfs is needed.
Additionally a particularly popular request from user community seems to be to allow external
source to drive vbus (and perhaps allow battery charging at the same time), I am not exactly sure
how that would fit into the current driver picture.
Any ideas on how it would be best to start tackling this for eventual inclusion into mainline?
Thanks.
Bye,
Oleg--
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
