[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
