> On Behalf Of Felipe Balbi [me@xxxxxxxxxxxxxxx] > On Fri, Sep 12, 2008 at 12:21:59PM -0700, Tony Lindgren wrote: > > * David Brownell <david-b@xxxxxxxxxxx> [080912 12:18]: > > > On Friday 12 September 2008, Felipe Balbi wrote: > > > > /* Enusre bit is set */ > > > > > > My Cortex Mark-I (cerebral, humanoid) treats that as a compile error ... :) > > > > Have you tried preprocessing with squint? :) > > ehehe, it's not in my diff, so it wasn't me. :-p > I'll fix it in the final clean up Was planning on cleaning up this driver and sending to linux-omap as Tony suggested, but I'm afraid I won't be able to look at it for a while. So if you're going to be doing this anyway, then could you please meld in Vikram's other patch from [1] as well? By the way, how do you propose to test this driver? Do you have the expansion board for the SDP, or some other hardware that can be used? Also, while we're discussing this driver, a few points to be resolved: 1. TLL vs PHY mode needs to be set somewhere. Me thinks this information ought to come from board-specific data and the driver would need to set things up accordingly. What would be a good way to do this? 2. The OHCI driver (not yet in linux-omap and not in a shape to go ought at the moment either) would need to touch a lot of common registers during init/exit/re-init. Any ideas where to put this code such that we can have the EHCI driver, or the OHCI driver, or both loaded and unloaded at will and still working without interfering with each other. 3. For OHCI, the transceiver used on the expansion board happens to be an ISP1301 for which there currently exists a driver (drivers/i2c/chips/isp1301_omap.c). Since this is meant to be an OTG transceiver, the driver does otg_set_transceiver. But MUSB is the OTG controller and has it's own transceiver... and we can't have two of those, right? :) Ideas welcome. Regards, Anand [1] http://marc.info/?l=linux-omap&m=121483462926647&w=2-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
