> >> 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 ? -Ajay > > That was my feeling too. Anand, care to update ?!? > > -- > 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
