Hi,
> > 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.
My comment was w.r.t current musb driver which needs gadget module to be
Inserted and why we can't have gadget as modules (as suggested by Felipe
above) for host only ports in such use case.
If we have modified musb driver where host only port can be initialized
then there is no discussion needed for gadget module or builtin
for such ports.
>
> >
> >>
[...]
> >>
> >>> 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,
Again misread by you.
I am raising the concern of menuconfig option which would still appear to
select gadget driver for host only port if we go with pdata->board_mode option.
We need to additionally fix this issue as well.
Please note that, I am "NOT" proposing a solution with menuconfig option.
> 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.
I am not proposing to have gadget driver requirement as-is in current musb
Driver but explaining to Felipe the need to host only port in the use case.
>
> >
> >>
> >>> 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.
Please read carefully. I am "NOT" proposing any menuconfig based solution
But brining out the issue of ugly gadget driver option still available
With proposed solution of using pdata->board_mode.
Ajay
>
> >
> > 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
