Hi,
On Sun, Jun 05, 2011 at 04:05:55PM -0400, Oleg Drokin wrote:
> 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?
Before we can add this trickery, we need to fix what's already in
mainline. To be fair and straight, although it's kinda fun to allow any
board to become USB Host by modifying cables and the like, we shouldn't
be focusing on that.
Before even thinking about such things, we need to see the problems we
have today and one of them is that we don't have a real PHY layer,
another is that MUSB driver is still quite buggy in several situations,
specially for host mode. There's still some coupling between the glue
layer and the core IP driver, which shouldn't exist.
In short, no I will not take patches adding hacker-only features until
the whole thing is in good shape and passes USB Certification without
add on hacks done by product manufacturers. Let's first have a
Certifiable USB Stack with a certifiable MUSB driver, then we play with
hacker-only features.
--
balbi
Attachment:
signature.asc
Description: Digital signature
