On 1/9/07, David Brownell <[EMAIL PROTECTED]> wrote: > On Tuesday 09 January 2007 2:41 pm, Meher wrote: > > Hi, > > I started going through the ohci-omap.c file and trying to make > > sense of the interfaces. I am stuck at the point where the interrupt > > handler is hooked with request_irq in the function, > > usb_hcd_omap_probe. Interrupt handler that is hooked is "usb_hcd_irq" > > which in turn calls driver->irq which turns out to be ohci_irq. > > Yes ... > > > > What is confusing to me is that OMAP USB is based on MUSB HDRC > > OTG core and its registers are not OHCI compatible (am I correct??). > > There are multiple OMAP chips. The ones that integrate the MUSB OTG > core (2430 and ISTR 3430) *also* have the same full speed USB support > that OMAP1 included ... > > But you can also use the musb_hdrc with a discrete "tusb6010" chip. > Or for that matter, with a DaVinci chip. (DaVinci combines a high > end video quality DSP with an ARM; it's not a mobile phone chip.) > Eventually I expect other (non-TI) chips to work with that driver. > (Presumably you've seen the nasty code from Mentor; IMO it's not even > worth considering use in any product, without first doing the cleanup > found in the musb_hdrc driver...) >
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? > > > So I expected a OMAP MUSB specific interrupt handler and low level > > functions to handle the MUSB registers for interrupts/FIFO handling > > etc., Can some one point me to where this stuff happens? > > I already did that when I said to look at drivers/usb/musb ... > > > > Also in a board view, when system is getting initialized, first > > usb_init function in drivers/core/usb.c is called and then respective > > HCD driver init methods are called?? > > 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 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 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? > > - Dave > -- Regards, Meher ------------------------------------------------------------------------- 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
