On Wed, 2010-12-01 at 17:38 +0530, Gupta, Ajay Kumar wrote: > > >> Tony ? Do you ack the usage of that header ? > > > > > >NAK. Drivers should not mess with the control registers directly. > > > > > >Instead, the following should be done in the platform init code: > > > > > >$ grep -r omap_ctrl_read drivers/usb > > >drivers/usb/musb/am35x.c: devconf2 = > > omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2); > > >drivers/usb/musb/am35x.c: while > > (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2) > > >drivers/usb/musb/am35x.c: devconf2 = > > omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2); > > >drivers/usb/musb/am35x.c: lvl_intr = > > omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR); > > >drivers/usb/musb/am35x.c: u32 devconf2 = > > omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2); > > >drivers/usb/musb/am35x.c: sw_reset = > > omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET); > > >drivers/usb/musb/am35x.c: lvl_intr = > > omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR); > > > > > >You can pass a function pointer like board_set_power or simila in > > >platform_data. > > We would need control register apis for accessing USB PHY control > , IPSS reset and interrupt clear register. This would require to > add three different function pointer and that would mostly be > custom to AM35x. Will that be acceptable from musb perspective ? why don't you add a proper otg_transceiver driver for am35x ? Is it like omap4's internal phy ? A separate block ? -- balbi -- 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
