[PATCH v9 01/13] usb: musb: dsps: add phy control logic to glue
From: Santhapuri, Damodar AM335x uses NOP transceiver driver and need to enable builtin PHY by writing into usb_ctrl register available in system control module register space. This is being added at musb glue driver layer untill a separate system control module driver is available. Signed-off-by: Ajay Kumar Gupta Signed-off-by: Santhapuri, Damodar Signed-off-by: Ravi Babu --- arch/arm/mach-omap2/board-ti8168evm.c |1 - arch/arm/mach-omap2/omap_phy_internal.c | 35 arch/arm/plat-omap/include/plat/usb.h |5 +- drivers/usb/musb/musb_dsps.c| 87 +-- 4 files changed, 73 insertions(+), 55 deletions(-) diff --git a/arch/arm/mach-omap2/board-ti8168evm.c b/arch/arm/mach-omap2/board-ti8168evm.c index d4c8392..0c7c098 100644 --- a/arch/arm/mach-omap2/board-ti8168evm.c +++ b/arch/arm/mach-omap2/board-ti8168evm.c @@ -26,7 +26,6 @@ #include static struct omap_musb_board_data musb_board_data = { - .set_phy_power = ti81xx_musb_phy_power, .interface_type = MUSB_INTERFACE_ULPI, .mode = MUSB_OTG, .power = 500, diff --git a/arch/arm/mach-omap2/omap_phy_internal.c b/arch/arm/mach-omap2/omap_phy_internal.c index d52651a..d80bb16 100644 --- a/arch/arm/mach-omap2/omap_phy_internal.c +++ b/arch/arm/mach-omap2/omap_phy_internal.c @@ -254,38 +254,3 @@ void am35x_set_mode(u8 musb_mode) omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2); } - -void ti81xx_musb_phy_power(u8 on) -{ - void __iomem *scm_base = NULL; - u32 usbphycfg; - - scm_base = ioremap(TI81XX_SCM_BASE, SZ_2K); - if (!scm_base) { - pr_err("system control module ioremap failed\n"); - return; - } - - usbphycfg = __raw_readl(scm_base + USBCTRL0); - - if (on) { - if (cpu_is_ti816x()) { - usbphycfg |= TI816X_USBPHY0_NORMAL_MODE; - usbphycfg &= ~TI816X_USBPHY_REFCLK_OSC; - } else if (cpu_is_ti814x()) { - usbphycfg &= ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN - | USBPHY_DPINPUT | USBPHY_DMINPUT); - usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN - | USBPHY_DPOPBUFCTL | USBPHY_DMOPBUFCTL); - } - } else { - if (cpu_is_ti816x()) - usbphycfg &= ~TI816X_USBPHY0_NORMAL_MODE; - else if (cpu_is_ti814x()) - usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN; - - } - __raw_writel(usbphycfg, scm_base + USBCTRL0); - - iounmap(scm_base); -} diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h index 548a4c8..c2aa4ae 100644 --- a/arch/arm/plat-omap/include/plat/usb.h +++ b/arch/arm/plat-omap/include/plat/usb.h @@ -95,7 +95,6 @@ extern void am35x_musb_reset(void); extern void am35x_musb_phy_power(u8 on); extern void am35x_musb_clear_irq(void); extern void am35x_set_mode(u8 musb_mode); -extern void ti81xx_musb_phy_power(u8 on); /* AM35x */ /* USB 2.0 PHY Control */ @@ -120,8 +119,8 @@ extern void ti81xx_musb_phy_power(u8 on); #define CONF2_DATPOL (1 << 1) /* TI81XX specific definitions */ -#define USBCTRL0 0x620 -#define USBSTAT0 0x624 +#define MUSB_USBSS_REV_816X0x9 +#define MUSB_USBSS_REV_814X0xb /* TI816X PHY controls bits */ #define TI816X_USBPHY0_NORMAL_MODE (1 << 0) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 84d8181..960258d 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -116,9 +116,46 @@ struct dsps_glue { struct platform_device *musb; /* child musb pdev */ const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */ struct timer_list timer;/* otg_workaround timer */ + u32 __iomem *usb_ctrl; + u8 usbss_rev; }; /** + * musb_dsps_phy_control - phy on/off + * @glue: struct dsps_glue * + * @on: flag for phy to be switched on or off + * + * This is to enable the PHY using usb_ctrl register in system control + * module space. + * + * XXX: This function will be removed once we have a seperate driver for + * control module + */ +static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on) +{ + u32 usbphycfg; + + usbphycfg = __raw_readl(glue->usb_ctrl); + + if (on) { + if (glue->usbss_rev == MUSB_USBSS_REV_816X) { + usbphycfg |= TI816X_USBPHY0_NORMAL_MODE; + usbphycfg &= ~TI816X_USBPHY_REFCLK_OSC; + } else if (glue->usbss_rev == MUSB_USBSS_REV_814X) { + usbphycfg &= ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN + | USBPHY_DPINPUT | USBPHY_DMINPUT); + usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN +
Re: [PATCH v9 01/13] usb: musb: dsps: add phy control logic to glue
Hi, On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote: > From: Santhapuri, Damodar > > AM335x uses NOP transceiver driver and need to enable builtin PHY > by writing into usb_ctrl register available in system control > module register space. This is being added at musb glue driver > layer untill a separate system control module driver is available. > > Signed-off-by: Ajay Kumar Gupta > Signed-off-by: Santhapuri, Damodar > Signed-off-by: Ravi Babu Kishon, you were adding a real phy driver for OMAP's internal phy logic on one of your patches and I believe this will conflict with your changes, right ? How does this look to you ? Is this at least correct ? I suppose the correct way would be to actually have the system control module driver which we have been waiting, right ? > --- > arch/arm/mach-omap2/board-ti8168evm.c |1 - > arch/arm/mach-omap2/omap_phy_internal.c | 35 > arch/arm/plat-omap/include/plat/usb.h |5 +- > drivers/usb/musb/musb_dsps.c| 87 > +-- > 4 files changed, 73 insertions(+), 55 deletions(-) > > diff --git a/arch/arm/mach-omap2/board-ti8168evm.c > b/arch/arm/mach-omap2/board-ti8168evm.c > index d4c8392..0c7c098 100644 > --- a/arch/arm/mach-omap2/board-ti8168evm.c > +++ b/arch/arm/mach-omap2/board-ti8168evm.c > @@ -26,7 +26,6 @@ > #include > > static struct omap_musb_board_data musb_board_data = { > - .set_phy_power = ti81xx_musb_phy_power, > .interface_type = MUSB_INTERFACE_ULPI, > .mode = MUSB_OTG, > .power = 500, > diff --git a/arch/arm/mach-omap2/omap_phy_internal.c > b/arch/arm/mach-omap2/omap_phy_internal.c > index d52651a..d80bb16 100644 > --- a/arch/arm/mach-omap2/omap_phy_internal.c > +++ b/arch/arm/mach-omap2/omap_phy_internal.c > @@ -254,38 +254,3 @@ void am35x_set_mode(u8 musb_mode) > > omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2); > } > - > -void ti81xx_musb_phy_power(u8 on) > -{ > - void __iomem *scm_base = NULL; > - u32 usbphycfg; > - > - scm_base = ioremap(TI81XX_SCM_BASE, SZ_2K); > - if (!scm_base) { > - pr_err("system control module ioremap failed\n"); > - return; > - } > - > - usbphycfg = __raw_readl(scm_base + USBCTRL0); > - > - if (on) { > - if (cpu_is_ti816x()) { > - usbphycfg |= TI816X_USBPHY0_NORMAL_MODE; > - usbphycfg &= ~TI816X_USBPHY_REFCLK_OSC; > - } else if (cpu_is_ti814x()) { > - usbphycfg &= ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN > - | USBPHY_DPINPUT | USBPHY_DMINPUT); > - usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN > - | USBPHY_DPOPBUFCTL | USBPHY_DMOPBUFCTL); > - } > - } else { > - if (cpu_is_ti816x()) > - usbphycfg &= ~TI816X_USBPHY0_NORMAL_MODE; > - else if (cpu_is_ti814x()) > - usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN; > - > - } > - __raw_writel(usbphycfg, scm_base + USBCTRL0); > - > - iounmap(scm_base); > -} > diff --git a/arch/arm/plat-omap/include/plat/usb.h > b/arch/arm/plat-omap/include/plat/usb.h > index 548a4c8..c2aa4ae 100644 > --- a/arch/arm/plat-omap/include/plat/usb.h > +++ b/arch/arm/plat-omap/include/plat/usb.h > @@ -95,7 +95,6 @@ extern void am35x_musb_reset(void); > extern void am35x_musb_phy_power(u8 on); > extern void am35x_musb_clear_irq(void); > extern void am35x_set_mode(u8 musb_mode); > -extern void ti81xx_musb_phy_power(u8 on); > > /* AM35x */ > /* USB 2.0 PHY Control */ > @@ -120,8 +119,8 @@ extern void ti81xx_musb_phy_power(u8 on); > #define CONF2_DATPOL (1 << 1) > > /* TI81XX specific definitions */ > -#define USBCTRL0 0x620 > -#define USBSTAT0 0x624 > +#define MUSB_USBSS_REV_816X 0x9 > +#define MUSB_USBSS_REV_814X 0xb > > /* TI816X PHY controls bits */ > #define TI816X_USBPHY0_NORMAL_MODE (1 << 0) > diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c > index 84d8181..960258d 100644 > --- a/drivers/usb/musb/musb_dsps.c > +++ b/drivers/usb/musb/musb_dsps.c > @@ -116,9 +116,46 @@ struct dsps_glue { > struct platform_device *musb; /* child musb pdev */ > const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */ > struct timer_list timer;/* otg_workaround timer */ > + u32 __iomem *usb_ctrl; > + u8 usbss_rev; > }; > > /** > + * musb_dsps_phy_control - phy on/off > + * @glue: struct dsps_glue * > + * @on: flag for phy to be switched on or off > + * > + * This is to enable the PHY using usb_ctrl register in system control > + * module space. > + * > + * XXX: This function will be removed once we have a seperate driver for > + * control module > + */ > +static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on) > +{ > + u32 usbphycfg; > + > + usbphy
Re: [PATCH v9 01/13] usb: musb: dsps: add phy control logic to glue
Hi, On Fri, Aug 31, 2012 at 5:53 PM, Felipe Balbi wrote: > Hi, > > On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote: >> From: Santhapuri, Damodar >> >> AM335x uses NOP transceiver driver and need to enable builtin PHY >> by writing into usb_ctrl register available in system control >> module register space. This is being added at musb glue driver >> layer untill a separate system control module driver is available. >> >> Signed-off-by: Ajay Kumar Gupta >> Signed-off-by: Santhapuri, Damodar >> Signed-off-by: Ravi Babu > > Kishon, you were adding a real phy driver for OMAP's internal phy logic > on one of your patches and I believe this will conflict with your > changes, right ? Indeed. My final patch of that series removes some of the functions from omap_phy_internal.c (which was taken care in the phy driver). > > How does this look to you ? Is this at least correct ? I suppose the > correct way would be to actually have the system control module driver > which we have been waiting, right ? Correct. I think once we have the system control module driver in place, we'll have everything wrt control module register writes implemented in correct way. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 01/13] usb: musb: dsps: add phy control logic to glue
On Fri, Aug 31, 2012 at 06:51:04PM +0530, ABRAHAM, KISHON VIJAY wrote: > Hi, > > On Fri, Aug 31, 2012 at 5:53 PM, Felipe Balbi wrote: > > Hi, > > > > On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote: > >> From: Santhapuri, Damodar > >> > >> AM335x uses NOP transceiver driver and need to enable builtin PHY > >> by writing into usb_ctrl register available in system control > >> module register space. This is being added at musb glue driver > >> layer untill a separate system control module driver is available. > >> > >> Signed-off-by: Ajay Kumar Gupta > >> Signed-off-by: Santhapuri, Damodar > >> Signed-off-by: Ravi Babu > > > > Kishon, you were adding a real phy driver for OMAP's internal phy logic > > on one of your patches and I believe this will conflict with your > > changes, right ? > > Indeed. My final patch of that series removes some of the functions > from omap_phy_internal.c (which was taken care in the phy driver). > > > > How does this look to you ? Is this at least correct ? I suppose the > > correct way would be to actually have the system control module driver > > which we have been waiting, right ? > > Correct. I think once we have the system control module driver in > place, we'll have everything wrt control module register writes > implemented in correct way. So $SUBJECT will pretty much be thrown away once we have SCM driver, in that case it's best to wait a bit longer and apply this series once SCM driver is available and after your series too... you agree ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v9 01/13] usb: musb: dsps: add phy control logic to glue
On Fri, Aug 31, 2012 at 6:49 PM, Felipe Balbi wrote: > On Fri, Aug 31, 2012 at 06:51:04PM +0530, ABRAHAM, KISHON VIJAY wrote: >> Hi, >> >> On Fri, Aug 31, 2012 at 5:53 PM, Felipe Balbi wrote: >> > Hi, >> > >> > On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote: >> >> From: Santhapuri, Damodar >> >> >> >> AM335x uses NOP transceiver driver and need to enable builtin PHY >> >> by writing into usb_ctrl register available in system control >> >> module register space. This is being added at musb glue driver >> >> layer untill a separate system control module driver is available. >> >> >> >> Signed-off-by: Ajay Kumar Gupta >> >> Signed-off-by: Santhapuri, Damodar >> >> Signed-off-by: Ravi Babu >> > >> > Kishon, you were adding a real phy driver for OMAP's internal phy logic >> > on one of your patches and I believe this will conflict with your >> > changes, right ? >> >> Indeed. My final patch of that series removes some of the functions >> from omap_phy_internal.c (which was taken care in the phy driver). >> > >> > How does this look to you ? Is this at least correct ? I suppose the >> > correct way would be to actually have the system control module driver >> > which we have been waiting, right ? >> >> Correct. I think once we have the system control module driver in >> place, we'll have everything wrt control module register writes >> implemented in correct way. > > So $SUBJECT will pretty much be thrown away once we have SCM driver, in > that case it's best to wait a bit longer and apply this series once SCM > driver is available and after your series too... you agree ? Yes. That would be better. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 01/13] usb: musb: dsps: add phy control logic to glue
* Ravi Babu [120831 04:10]: > --- a/arch/arm/plat-omap/include/plat/usb.h > +++ b/arch/arm/plat-omap/include/plat/usb.h > @@ -95,7 +95,6 @@ extern void am35x_musb_reset(void); > extern void am35x_musb_phy_power(u8 on); > extern void am35x_musb_clear_irq(void); > extern void am35x_set_mode(u8 musb_mode); > -extern void ti81xx_musb_phy_power(u8 on); > > /* AM35x */ > /* USB 2.0 PHY Control */ > @@ -120,8 +119,8 @@ extern void ti81xx_musb_phy_power(u8 on); > #define CONF2_DATPOL (1 << 1) > > /* TI81XX specific definitions */ > -#define USBCTRL0 0x620 > -#define USBSTAT0 0x624 > +#define MUSB_USBSS_REV_816X 0x9 > +#define MUSB_USBSS_REV_814X 0xb > > /* TI816X PHY controls bits */ > #define TI816X_USBPHY0_NORMAL_MODE (1 << 0) This file needs to move to include/linux/platform_data/usb-omap.h as it's blocking the ARM single zImage changes so some coordination is required here. Felipe, can you do a minimal immutable branch with just one patch against v3.6-rc3 that move the header so I can pull in too? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v9 01/13] usb: musb: dsps: add phy control logic to glue
> On Fri, Aug 31, 2012 at 06:51:04PM +0530, ABRAHAM, KISHON VIJAY wrote: > > Hi, > > > > On Fri, Aug 31, 2012 at 5:53 PM, Felipe Balbi wrote: > > > Hi, > > > > > > On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote: > > >> From: Santhapuri, Damodar > > >> > > >> AM335x uses NOP transceiver driver and need to enable > builtin PHY > > >> by writing into usb_ctrl register available in system control > > >> module register space. This is being added at musb glue driver > > >> layer untill a separate system control module driver is > available. > > >> > > >> Signed-off-by: Ajay Kumar Gupta > > >> Signed-off-by: Santhapuri, Damodar > > >> Signed-off-by: Ravi Babu > > > > > > Kishon, you were adding a real phy driver for OMAP's internal phy > > > logic on one of your patches and I believe this will > conflict with > > > your changes, right ? > > > > Indeed. My final patch of that series removes some of the functions > > from omap_phy_internal.c (which was taken care in the phy driver). > > > > > > How does this look to you ? Is this at least correct ? I > suppose the > > > correct way would be to actually have the system control module > > > driver which we have been waiting, right ? > > > > Correct. I think once we have the system control module driver in > > place, we'll have everything wrt control module register writes > > implemented in correct way. > > So $SUBJECT will pretty much be thrown away once we have SCM > driver, in that case it's best to wait a bit longer and apply > this series once SCM driver is available and after your > series too... you agree ? > Felipe, I am sure there are patches in this series[0/13], which are not dependent on this patch or control module, Can we pull in those patches (all dual instances support patches)? So that I can re-work and submit again? > -- > balbi > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 01/13] usb: musb: dsps: add phy control logic to glue
Hi, On Tue, Sep 04, 2012 at 02:04:15PM +, B, Ravi wrote: > > On Fri, Aug 31, 2012 at 06:51:04PM +0530, ABRAHAM, KISHON VIJAY wrote: > > > Hi, > > > > > > On Fri, Aug 31, 2012 at 5:53 PM, Felipe Balbi wrote: > > > > Hi, > > > > > > > > On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote: > > > >> From: Santhapuri, Damodar > > > >> > > > >> AM335x uses NOP transceiver driver and need to enable > > builtin PHY > > > >> by writing into usb_ctrl register available in system control > > > >> module register space. This is being added at musb glue driver > > > >> layer untill a separate system control module driver is > > available. > > > >> > > > >> Signed-off-by: Ajay Kumar Gupta > > > >> Signed-off-by: Santhapuri, Damodar > > > >> Signed-off-by: Ravi Babu > > > > > > > > Kishon, you were adding a real phy driver for OMAP's internal phy > > > > logic on one of your patches and I believe this will > > conflict with > > > > your changes, right ? > > > > > > Indeed. My final patch of that series removes some of the functions > > > from omap_phy_internal.c (which was taken care in the phy driver). > > > > > > > > How does this look to you ? Is this at least correct ? I > > suppose the > > > > correct way would be to actually have the system control module > > > > driver which we have been waiting, right ? > > > > > > Correct. I think once we have the system control module driver in > > > place, we'll have everything wrt control module register writes > > > implemented in correct way. > > > > So $SUBJECT will pretty much be thrown away once we have SCM > > driver, in that case it's best to wait a bit longer and apply > > this series once SCM driver is available and after your > > series too... you agree ? > > > > Felipe, I am sure there are patches in this series[0/13], which are > not dependent on this patch or control module, Can we pull in those > patches (all dual instances support patches)? So that I can re-work > and submit again? sure, will do, don't worry :-) -- balbi signature.asc Description: Digital signature
RE: [PATCH v9 01/13] usb: musb: dsps: add phy control logic to glue
Hi > > > > >> AM335x uses NOP transceiver driver and need to enable > > > builtin PHY > > > > >> by writing into usb_ctrl register available in > system control > > > > >> module register space. This is being added at musb > glue driver > > > > >> layer untill a separate system control module driver is > > > available. > > > > >> > > > > >> Signed-off-by: Ajay Kumar Gupta > > > > >> Signed-off-by: Santhapuri, Damodar > > > > > >> Signed-off-by: Ravi Babu > > > > > > > > > > Kishon, you were adding a real phy driver for OMAP's internal > > > > > phy logic on one of your patches and I believe this will > > > conflict with > > > > > your changes, right ? > > > > > > > > Indeed. My final patch of that series removes some of the > > > > functions from omap_phy_internal.c (which was taken > care in the phy driver). > > > > > > > > > > How does this look to you ? Is this at least correct ? I > > > suppose the > > > > > correct way would be to actually have the system > control module > > > > > driver which we have been waiting, right ? > > > > > > > > Correct. I think once we have the system control module > driver in > > > > place, we'll have everything wrt control module register writes > > > > implemented in correct way. > > > > > > So $SUBJECT will pretty much be thrown away once we have > SCM driver, > > > in that case it's best to wait a bit longer and apply this series > > > once SCM driver is available and after your series too... > you agree > > > ? > > > > > > > Felipe, I am sure there are patches in this series[0/13], which are > > not dependent on this patch or control module, Can we pull in those > > patches (all dual instances support patches)? So that I can re-work > > and submit again? > > sure, will do, don't worry :-) Thanks. Then shall I rework patches [3/13 to 13/13] and re-submit only musb dual instances patches which are independent of control module. > > -- > balbi > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html