On Thu, Oct 29, 2009 at 11:29:39AM +0100, ext Gupta, Ajay Kumar wrote: > Hi, > > On Thu, Oct 29, 2009 at 08:03:21AM +0100, ext Gupta, Ajay Kumar wrote: > > > > I was thinking on adding a musb_hdrc_board_data which would group > > > > board-specific data such as this one. > > > > > > > > Musb's init phase is quite messy as of today so we would need to clean > > > > that up. Anyways, the main idea is: > > > > > > > > board will call usb_musb_init() with a musb_hdrc_board_data * as > > > > parameter. usb-musb would still hold a static struct > > > > musb_hdrc_platform_data for the (in our case) OMAP-specific init, > > those > > > > would be passed down to driver and init phase would be done as > > > > following: > > > > > > > > musb_init() > > > > -> musb_platform_init() > > > > -> musb_board_init() > > > > > > > > we could also have board_ops and platform_ops structures for the > > > > function pointers to be passed to musb_core.c Then all init could be > > > > done there. > > > > > > > > What do you say ??? > > > > > > This looks really good to isolate board specific settings. Do you have > > any > > > ready patch on this ? > > > > no, currently I'm working on refactoring the otg support. I could work > > on this after I finish otg refactoring unless you want to take this task > > :-) > > Sure, I will submit the first cut very soon.
We could discuss further off list about the design and implementation details. Just drop a mail :-) -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
