Hi, On Wed, Oct 19, 2011 at 05:41:06AM -0400, Jason Kridner wrote: > >> 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 tks :-) > 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? It should just be about phasing that usb_create_hcd() part to a separate function, place that on musb_host.c and if MUSB_HOST or MUSB_OTG, call that function ;-) > >>> 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. tks :-) -- balbi
Attachment:
signature.asc
Description: Digital signature
