On Thu, Dec 02, 2010 at 04:13:50PM +0530, Gupta, Ajay Kumar wrote:
>> why don't you add a proper otg_transceiver driver for am35x ? >> Is it like omap4's internal phy ? A separate block ? > >AM35x PHY is built inside the ip and we need to configure it through >PHY control register. > >Additionally we also need to access IPSS reset and Intr clear register >as well which would not fit inside otg_transceiver. how about passing an extra struct resource if am35x ? Then you could ioremap that base on am35x.c and use normal musb_read/write functions.We already have generic APIs so I think we can pass function pointers to musb driver via "struct omap_musb_board_data", struct omap_musb_board_data { + void (*phy_on) (void) + void (*phy_off) (void) + void (*intr_clr) (void) } Reset part can be done in board file itself same as Ethernet driver is doing. Does this look fine?
so those would be "turn phy on", "turn phy off" and "clear interrupt" apis ? How about: int (*set_phy_power)(unsigned on); void (*clear_phy_irq)(void); You'd need one less API for that. BTW, could you do it on top of my musb-hw branch ? Then I can push together with those for merge window. -- balbi -- 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
