Sekhar Nori wrote: > On 5/23/2012 8:24 AM, Jon Povey wrote: >> I've just been trying to build musb driver modules for DM365 on >> kernel 3.4. I am getting errors which I think are due to the >> rearrangement of the mach-davinci/davinci.h and associated headers: >> >> CC [M] drivers/usb/musb/davinci.o >> drivers/usb/musb/davinci.c: In function 'phy_on': >> drivers/usb/musb/davinci.c:67: error: implicit declaration of >> function 'IO_ADDRESS' drivers/usb/musb/davinci.c:67: error: > 'DAVINCI_SYSTEM_MODULE_BASE' undeclared (first use in this function) >> >> Not sure the right way to fix, I am just bodging for now. > > I see this too. Looks like this was missed all along because the > davinci_all_defconfig does not enable the MUSB davinci glue > layer. This > needs to be corrected too. > > There is a lot of machine specific code in the davinci glue > layer which > needs to be cleaned up for a correct solution to this issue. > > For now, to fix this regression, we can directly define > USB_PHY_CTRL and > DM355_DEEPSLEEP to the correct register addresses. Then include > <mach/hardware.h> to get definition of IO_ADDRESS(). I guess this > what you did too. Pretty much, I just copied the define of DAVINCI_SYSTEM_MODULE_BASE > Do you mind sending this to Felipe and checking if he is OK > with taking it? Sent. Note that USB doesn't work on DM365 at the moment, the phy_ctrl is not set up right and the evm board file doesn't call the arch USB init. I started with this patch: http://linux.omap.com/pipermail/davinci-linux-open-source/2011-July/023212.html Maybe there is some reason why DM365 USB support has not made it to mainline? By the way: I am trying to get this working at the moment for dual role USB mass storage as host, and CDC serial as gadget. Based on kernel 3.0-rc7 seems more or less OK, just that it doesn't switch back to peripheral mode once host mode has been used. But I tried rebasing my board to 3.2 and 3.4 and things seem a lot more broken, no reaction to USB sticks being plugged in, and plugging into a PC gives an immediate OOPS in gadget ep0 interrupt handler. I haven't bisected any further than that as it's quite time-consuming rebasing the board support each time. Let me know if you want any more info about the above. This is on our own board and cables which control the ID pin appropriately, I don't have access to a DM365 EVM again until July. But if someone wants me to test some DM365 USB patches, let me know. -- Jon Povey jon.povey@xxxxxxxxxxxxxxx Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network -- 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
