On Wednesday 10 January 2007 7:33 am, Meher wrote: > I am actually interested in the Davinci USB core but when I look at > the drivers in drivers/usb/musb/ I have seen comments in the code like > it is not implemented in the kernel HCD framework and it has to change > some day. So I wanted to know the HCD framework and may be contribute > in moving the musb code towards the HDC framework.. Is there any musb > code that is HCD framework complaint?
The version I pointed you to, 2.6.19+ in the OMAP tree, has been updated to use the HCD framework. Which comments do you mean? If you're looking at the MontaVista 2.6.10 kernel, yes that version uses the old 2.2 based HCD interfaces. Not really fixable there, since those interfaces evolved substantially in more current code (starting ISTR in 2.6.11 kernels). > > From a board perspective the first thing that happens is that the > > code in arch/arm/mach-omapX/board-Y.c gets called, and that will do > > any pin configuration needed to cope with the USB in use on that > > specific board. It will also create the platform device. > > > > Then MUCH later some host side usbcore mechanisms will initialize > > their data structures. And after that, the driver probe() method > > gets called -- either for musb_hdrc, for ohci-hcd, or omap_udc. > > (The full speed OTG init is tricky though.) > > Yeah I have seen this from arch/arm/mach-davinci/board-davinci.c What kernel would that be? I see a "board-evm.c"; a "board-davinci.c" makes no sense, the chip can be used in many boards. For the EVM there's also an I2C boot interaction through one of three I2C gpio expanders ... one of them powers VBUS up/down. A better example is arch/arm/mach-omap2/usb-tusb6010.c which includes lots of lowlevel setup (clocking for two different I/O regions, plus DMAREQ lines) or, for full speed, arch/arm/plat-omap/usb.c which does more pin muxing. I think the 2430 support will resemble that a bit, in that it relies on an external transceiver. > initializing the platform_deviec and setting up the resources etc. I > beleve the platform devices should get initialized at startup without > waiting for any event to occur right? I mean linux assumes platform > devices exist at particular IO range Yes, that's what I said. > and will try to communicate with > them and initialize them at startup so as part of its __initcalls > linux calls the probe function for the respective HCD's? Normally, talking to those devices is part of probe(). That early stuff is just making sure the chip is set up so that probe() can just talk to that controller, and not worry about chip issues like pin multiplexing or how to turn VBUS power on/off ... so it wouldn't talk to the controller, or even turn its clocks on. - Dave ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
