[PATCH v2] musb: am35x: fix compile error due to control apis

[PATCH v2] musb: am35x: fix compile error due to control apis

[Ajay Kumar Gupta]

As the control.h have been moved to new location and it's
uses are not allowed to drivers directly so moving the phy
control, interrupt clear and reset functionality to board
files.

Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org>
---
Patch created against recent Linus's tree.
Changes from v1:
        - Moved musb reset part also to usb-musb.c so that all the
          boards can use it.
        - Corrected return value of set_mode() in case of null function
	- Used pr_info/err instead of printk.

 arch/arm/mach-omap2/usb-musb.c        |   97 ++++++++++++++++++++++++
 arch/arm/plat-omap/include/plat/usb.h |    4 +
 drivers/usb/musb/am35x.c              |  134 +++++++++++---------------------
 3 files changed, 147 insertions(+), 88 deletions(-)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 7260558..8c1d121 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -30,9 +30,102 @@
 #include <mach/irqs.h>
 #include <mach/am35xx.h>
 #include <plat/usb.h>
+#include "control.h"
 
 #ifdef CONFIG_USB_MUSB_SOC
 
+static void am35x_musb_reset(void)
+{
+	u32	regval;
+
+	/* Reset the musb interface */
+	regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+
+	regval |= AM35XX_USBOTGSS_SW_RST;
+	omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+	regval &= ~AM35XX_USBOTGSS_SW_RST;
+	omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+	regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+}
+
+static void am35x_musb_phy_power(u8 on)
+{
+	unsigned long timeout = jiffies + msecs_to_jiffies(100);
+	u32 devconf2;
+
+	if (on) {
+		/*
+		 * Start the on-chip PHY and its PLL.
+		 */
+		devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+		devconf2 &= ~(CONF2_RESET | CONF2_PHYPWRDN | CONF2_OTGPWRDN);
+		devconf2 |= CONF2_PHY_PLLON;
+
+		omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+
+		pr_info(KERN_INFO "Waiting for PHY clock good...\n");
+		while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
+				& CONF2_PHYCLKGD)) {
+			cpu_relax();
+
+			if (time_after(jiffies, timeout)) {
+				pr_err(KERN_ERR "musb PHY clock good timed out\n");
+				break;
+			}
+		}
+	} else {
+		/*
+		 * Power down the on-chip PHY.
+		 */
+		devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+		devconf2 &= ~CONF2_PHY_PLLON;
+		devconf2 |=  CONF2_PHYPWRDN | CONF2_OTGPWRDN;
+		omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+	}
+}
+
+static void am35x_musb_clear_irq(void)
+{
+	u32 regval;
+
+	regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+	regval |= AM35XX_USBOTGSS_INT_CLR;
+	omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+	regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static void am35x_musb_set_mode(u8 musb_mode)
+{
+	u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+	devconf2 &= ~CONF2_OTGMODE;
+	switch (musb_mode) {
+#ifdef	CONFIG_USB_MUSB_HDRC_HCD
+	case MUSB_HOST:		/* Force VBUS valid, ID = 0 */
+		devconf2 |= CONF2_FORCE_HOST;
+		break;
+#endif
+#ifdef	CONFIG_USB_GADGET_MUSB_HDRC
+	case MUSB_PERIPHERAL:	/* Force VBUS valid, ID = 1 */
+		devconf2 |= CONF2_FORCE_DEVICE;
+		break;
+#endif
+#ifdef	CONFIG_USB_MUSB_OTG
+	case MUSB_OTG:		/* Don't override the VBUS/ID comparators */
+		devconf2 |= CONF2_NO_OVERRIDE;
+		break;
+#endif
+	default:
+		pr_info(KERN_INFO "Unsupported mode %u\n", musb_mode);
+	}
+
+	omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+}
+
 static struct resource musb_resources[] = {
 	[0] = { /* start and end set dynamically */
 		.flags	= IORESOURCE_MEM,
@@ -93,6 +186,10 @@ void __init usb_musb_init(struct omap_musb_board_data *board_data)
 	} else if (cpu_is_omap3517() || cpu_is_omap3505()) {
 		musb_resources[0].start = AM35XX_IPSS_USBOTGSS_BASE;
 		musb_resources[1].start = INT_35XX_USBOTG_IRQ;
+		board_data->set_phy_power = am35x_musb_phy_power;
+		board_data->clear_irq = am35x_musb_clear_irq;
+		board_data->set_mode = am35x_musb_set_mode;
+		board_data->reset = am35x_musb_reset;
 	} else if (cpu_is_omap34xx()) {
 		musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
 	} else if (cpu_is_omap44xx()) {
diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h
index 59c7fe7..7c0be5a 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -69,6 +69,10 @@ struct omap_musb_board_data {
 	u8	mode;
 	u16	power;
 	unsigned extvbus:1;
+	void	(*set_phy_power)(u8 on);
+	void	(*clear_irq)(void);
+	void	(*set_mode)(u8 mode);
+	void	(*reset)(void);
 };
 
 enum musb_interface    {MUSB_INTERFACE_ULPI, MUSB_INTERFACE_UTMI};
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index b0aabf3..5ac1c51 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -30,7 +30,6 @@
 #include <linux/clk.h>
 #include <linux/io.h>
 
-#include <plat/control.h>
 #include <plat/usb.h>
 
 #include "musb_core.h"
@@ -80,47 +79,6 @@
 
 #define USB_MENTOR_CORE_OFFSET	0x400
 
-static inline void phy_on(void)
-{
-	unsigned long timeout = jiffies + msecs_to_jiffies(100);
-	u32 devconf2;
-
-	/*
-	 * Start the on-chip PHY and its PLL.
-	 */
-	devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
-
-	devconf2 &= ~(CONF2_RESET | CONF2_PHYPWRDN | CONF2_OTGPWRDN);
-	devconf2 |= CONF2_PHY_PLLON;
-
-	omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
-
-	DBG(1, "Waiting for PHY clock good...\n");
-	while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
-			& CONF2_PHYCLKGD)) {
-		cpu_relax();
-
-		if (time_after(jiffies, timeout)) {
-			DBG(1, "musb PHY clock good timed out\n");
-			break;
-		}
-	}
-}
-
-static inline void phy_off(void)
-{
-	u32 devconf2;
-
-	/*
-	 * Power down the on-chip PHY.
-	 */
-	devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
-
-	devconf2 &= ~CONF2_PHY_PLLON;
-	devconf2 |=  CONF2_PHYPWRDN | CONF2_OTGPWRDN;
-	omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
-}
-
 /*
  * musb_platform_enable - enable interrupts
  */
@@ -255,9 +213,12 @@ static irqreturn_t am35x_interrupt(int irq, void *hci)
 {
 	struct musb  *musb = hci;
 	void __iomem *reg_base = musb->ctrl_base;
+	struct device *dev = musb->controller;
+	struct musb_hdrc_platform_data *plat = dev->platform_data;
+	struct omap_musb_board_data *data = plat->board_data;
 	unsigned long flags;
 	irqreturn_t ret = IRQ_NONE;
-	u32 epintr, usbintr, lvl_intr;
+	u32 epintr, usbintr;
 
 	spin_lock_irqsave(&musb->lock, flags);
 
@@ -346,9 +307,8 @@ eoi:
 	/* EOI needs to be written for the IRQ to be re-asserted. */
 	if (ret == IRQ_HANDLED || epintr || usbintr) {
 		/* clear level interrupt */
-		lvl_intr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
-		lvl_intr |= AM35XX_USBOTGSS_INT_CLR;
-		omap_ctrl_writel(lvl_intr, AM35XX_CONTROL_LVL_INTR_CLEAR);
+		if (data->clear_irq)
+			data->clear_irq();
 		/* write EOI */
 		musb_writel(reg_base, USB_END_OF_INTR_REG, 0);
 	}
@@ -364,37 +324,24 @@ eoi:
 
 int musb_platform_set_mode(struct musb *musb, u8 musb_mode)
 {
-	u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+	struct device *dev = musb->controller;
+	struct musb_hdrc_platform_data *plat = dev->platform_data;
+	struct omap_musb_board_data *data = plat->board_data;
+	int	retval = 0;
 
-	devconf2 &= ~CONF2_OTGMODE;
-	switch (musb_mode) {
-#ifdef	CONFIG_USB_MUSB_HDRC_HCD
-	case MUSB_HOST:		/* Force VBUS valid, ID = 0 */
-		devconf2 |= CONF2_FORCE_HOST;
-		break;
-#endif
-#ifdef	CONFIG_USB_GADGET_MUSB_HDRC
-	case MUSB_PERIPHERAL:	/* Force VBUS valid, ID = 1 */
-		devconf2 |= CONF2_FORCE_DEVICE;
-		break;
-#endif
-#ifdef	CONFIG_USB_MUSB_OTG
-	case MUSB_OTG:		/* Don't override the VBUS/ID comparators */
-		devconf2 |= CONF2_NO_OVERRIDE;
-		break;
-#endif
-	default:
-		DBG(2, "Trying to set unsupported mode %u\n", musb_mode);
-	}
+	if (data->set_mode)
+		data->set_mode(musb_mode);
+	else
+		retval = -EIO;
 
-	omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
-	return 0;
+	return retval;
 }
 
 int __init musb_platform_init(struct musb *musb, void *board_data)
 {
+	struct omap_musb_board_data *data = board_data;
 	void __iomem *reg_base = musb->ctrl_base;
-	u32 rev, lvl_intr, sw_reset;
+	u32 rev;
 	int status;
 
 	musb->mregs += USB_MENTOR_CORE_OFFSET;
@@ -429,29 +376,22 @@ int __init musb_platform_init(struct musb *musb, void *board_data)
 
 	musb->board_set_vbus = am35x_set_vbus;
 
-	/* Global reset */
-	sw_reset = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
-
-	sw_reset |= AM35XX_USBOTGSS_SW_RST;
-	omap_ctrl_writel(sw_reset, AM35XX_CONTROL_IP_SW_RESET);
-
-	sw_reset &= ~AM35XX_USBOTGSS_SW_RST;
-	omap_ctrl_writel(sw_reset, AM35XX_CONTROL_IP_SW_RESET);
-
-	/* Reset the controller */
-	musb_writel(reg_base, USB_CTRL_REG, AM35X_SOFT_RESET_MASK);
+	/* Start the on-chip PHY and its PLL. */
+	if (data->reset)
+		data->reset();
 
 	/* Start the on-chip PHY and its PLL. */
-	phy_on();
+	if (data->set_phy_power)
+		data->set_phy_power(1);
 
 	msleep(5);
 
 	musb->isr = am35x_interrupt;
 
 	/* clear level interrupt */
-	lvl_intr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
-	lvl_intr |= AM35XX_USBOTGSS_INT_CLR;
-	omap_ctrl_writel(lvl_intr, AM35XX_CONTROL_LVL_INTR_CLEAR);
+	if (data->clear_irq)
+		data->clear_irq();
+
 	return 0;
 exit1:
 	clk_disable(musb->phy_clock);
@@ -463,10 +403,16 @@ exit0:
 
 int musb_platform_exit(struct musb *musb)
 {
+	struct device *dev = musb->controller;
+	struct musb_hdrc_platform_data *plat = dev->platform_data;
+	struct omap_musb_board_data *data = plat->board_data;
+
 	if (is_host_enabled(musb))
 		del_timer_sync(&otg_workaround);
 
-	phy_off();
+	/* Shutdown the on-chip PHY and its PLL. */
+	if (data->set_phy_power)
+		data->set_phy_power(0);
 
 	otg_put_transceiver(musb->xceiv);
 	usb_nop_xceiv_unregister();
@@ -483,13 +429,25 @@ int musb_platform_exit(struct musb *musb)
 void musb_platform_save_context(struct musb *musb,
 	struct musb_context_registers *musb_context)
 {
-	phy_off();
+	struct device *dev = musb->controller;
+	struct musb_hdrc_platform_data *plat = dev->platform_data;
+	struct omap_musb_board_data *data = plat->board_data;
+
+	/* Shutdown the on-chip PHY and its PLL. */
+	if (data->set_phy_power)
+		data->set_phy_power(0);
 }
 
 void musb_platform_restore_context(struct musb *musb,
 	struct musb_context_registers *musb_context)
 {
-	phy_on();
+	struct device *dev = musb->controller;
+	struct musb_hdrc_platform_data *plat = dev->platform_data;
+	struct omap_musb_board_data *data = plat->board_data;
+
+	/* Start the on-chip PHY and its PLL. */
+	if (data->set_phy_power)
+		data->set_phy_power(1);
 }
 #endif
 
-- 
1.6.2.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] musb: am35x: fix compile error due to control apis

[Sergei Shtylyov]

Hello.

On 06-12-2010 11:13, Ajay Kumar Gupta wrote:

> As the control.h have been moved to new location and it's
> uses are not allowed to drivers directly so moving the phy
> control, interrupt clear and reset functionality to board
> files.

    I'm not fond of the whole approach. I'm not sure why accesses to the 
control registers are such a no-no, taking into account that one needs to 
access such regisyter to clear the interrupt...

> Signed-off-by: Ajay Kumar Gupta<ajay.gupta-l0cyMroinI0@public.gmane.org>
[...]

> diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
> index 7260558..8c1d121 100644
> --- a/arch/arm/mach-omap2/usb-musb.c
> +++ b/arch/arm/mach-omap2/usb-musb.c
> @@ -30,9 +30,102 @@
>   #include<mach/irqs.h>
>   #include<mach/am35xx.h>
>   #include<plat/usb.h>
> +#include "control.h"
>
>   #ifdef CONFIG_USB_MUSB_SOC
>
> +static void am35x_musb_reset(void)
> +{
> +	u32	regval;
> +
> +	/* Reset the musb interface */
> +	regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
> +
> +	regval |= AM35XX_USBOTGSS_SW_RST;
> +	omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
> +
> +	regval&= ~AM35XX_USBOTGSS_SW_RST;
> +	omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
> +
> +	regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);

    Why read it and ignore the result?

WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2] musb: am35x: fix compile error due to control apis

[Gupta, Ajay Kumar]

Hi,
> > As the control.h have been moved to new location and it's
> > uses are not allowed to drivers directly so moving the phy
> > control, interrupt clear and reset functionality to board
> > files.
> 
>     I'm not fond of the whole approach. I'm not sure why accesses to the
> control registers are such a no-no, taking into account that one needs to
> access such regisyter to clear the interrupt...

I think Tony is the right person to answer this :)

> 
> > Signed-off-by: Ajay Kumar Gupta<ajay.gupta-l0cyMroinI0@public.gmane.org>
> [...]
> 
> > diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-
> musb.c

[...]

> > +	regval&= ~AM35XX_USBOTGSS_SW_RST;
> > +	omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
> > +
> > +	regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
> 
>     Why read it and ignore the result?

This is due to recommendation for OMAPs as discussed at below
Link,
http://markmail.org/message/s3lp7xlyq7zxnjtc#query:+page:1+mid:kfia4ld4xgzek6kq+state:results

Thanks,
Ajay
> 
> WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] musb: am35x: fix compile error due to control apis

[Sergei Shtylyov]

Hello.

Gupta, Ajay Kumar wrote:

>>> As the control.h have been moved to new location and it's
>>> uses are not allowed to drivers directly so moving the phy
>>> control, interrupt clear and reset functionality to board
>>> files.

>>     I'm not fond of the whole approach. I'm not sure why accesses to the
>> control registers are such a no-no, taking into account that one needs to
>> access such regisyter to clear the interrupt...

> I think Tony is the right person to answer this :)

    Yeah, I thought he must be reading linux-omap...

>>> Signed-off-by: Ajay Kumar Gupta<ajay.gupta@ti.com>
>> [...]

>>> diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c

> [...]

>>> +	regval&= ~AM35XX_USBOTGSS_SW_RST;
>>> +	omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
>>> +
>>> +	regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
>>     Why read it and ignore the result?

> This is due to recommendation for OMAPs as discussed at below
> Link,
> http://markmail.org/message/s3lp7xlyq7zxnjtc#query:+page:1+mid:kfia4ld4xgzek6kq+state:results

    There is recommendation to read back the interrupt status register, which 
this register isn't. Anyway, a comment wouldn't hurt...

> Thanks,
> Ajay

WBR, Sergei

Re: [PATCH v2] musb: am35x: fix compile error due to control apis

[Tony Lindgren]

* Sergei Shtylyov <sshtylyov@mvista.com> [101206 09:04]:
> Hello.
> 
> Gupta, Ajay Kumar wrote:
> 
> >>>As the control.h have been moved to new location and it's
> >>>uses are not allowed to drivers directly so moving the phy
> >>>control, interrupt clear and reset functionality to board
> >>>files.
> 
> >>    I'm not fond of the whole approach. I'm not sure why accesses to the
> >>control registers are such a no-no, taking into account that one needs to
> >>access such regisyter to clear the interrupt...

Because drivers should arch independent and any tinkering of the
platform level registers will lead into pains later on that
I end up having to deal with.

To me it seem you just init to separate out the transceiver,
right?
 
> >I think Tony is the right person to answer this :)
> 
>    Yeah, I thought he must be reading linux-omap...

I do yeah.. Might take a while to respond sometimes though :)

Tony
 

Re: [PATCH v2] musb: am35x: fix compile error due to control apis

[Sergei Shtylyov]

Hello.

On 06-12-2010 20:54, Tony Lindgren wrote:

>>>>> As the control.h have been moved to new location and it's
>>>>> uses are not allowed to drivers directly so moving the phy
>>>>> control, interrupt clear and reset functionality to board
>>>>> files.

>>>>     I'm not fond of the whole approach. I'm not sure why accesses to the
>>>> control registers are such a no-no, taking into account that one needs to
>>>> access such regisyter to clear the interrupt...

> Because drivers should arch independent and any tinkering of the
> platform level registers will lead into pains later on that
> I end up having to deal with.

> To me it seem you just init to separate out the transceiver,
> right?

    We also have to install a hook to clear the MUSB level interrupt via the 
control register -- that's a thing that makes me dubious about not allowing 
drivers to access the control registers.

> Tony

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] musb: am35x: fix compile error due to control apis

[Paul Walmsley]

Hello Sergei

On Tue, 7 Dec 2010, Sergei Shtylyov wrote:

> On 06-12-2010 20:54, Tony Lindgren wrote:
> > > > > > As the control.h have been moved to new location and it's
> > > > > > uses are not allowed to drivers directly so moving the phy
> > > > > > control, interrupt clear and reset functionality to board
> > > > > > files.
> 
> > > > >     I'm not fond of the whole approach. I'm not sure why accesses to
> > > > > the
> > > > > control registers are such a no-no, taking into account that one needs
> > > > > to
> > > > > access such regisyter to clear the interrupt...
> 
> > Because drivers should arch independent and any tinkering of the
> > platform level registers will lead into pains later on that
> > I end up having to deal with.
> 
> > To me it seem you just init to separate out the transceiver,
> > right?
> 
>    We also have to install a hook to clear the MUSB level interrupt via the
> control register -- that's a thing that makes me dubious about not allowing
> drivers to access the control registers.

That's only true for the AM35xx "IP subsystem" devices.  It's not true for 
any other device on that chip.  It is just due to the fact that the AM35xx 
hardware designers chose not to follow the standard OMAP3430 hardware 
design practice.  (Actually this standard practice goes back even further, 
at least to the OMAP2420 days.)  The OMAP2430/34xx/36xx adaptation layer 
for musb doesn't have to do these nasty SCM accesses.

As far as I know, every other device on the AM35xx outside the "IP 
subsystem" places its interrupt status registers in the same IP subsystem 
as the device that raises the interrupt.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] musb: am35x: fix compile error due to control apis

[Ben Gamari]

On Mon,  6 Dec 2010 13:43:31 +0530, Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org> wrote:
> As the control.h have been moved to new location and it's
> uses are not allowed to drivers directly so moving the phy
> control, interrupt clear and reset functionality to board
> files.
> 
What happened to the board changes for board-am3517evm? This patch
_really_ needs to include the necessary changes to a board. So far this
change has already been handled very sloppily (i.e. 2.6.37 was released
with am35x support that doesn't even build, much less function). If we
continue with this patch as proposed, not only will board maintainers
have absolutely no idea why USB isn't working in 2.6.38, but once they
are lucky enough to stumble upon the reason they will have no idea how
to fix the problem, having no template to work from.

As I understand it, this patch has already been merged into mmotm. Can
we please get a new version of this patch or even just a patch on top of
this modifying one of the boards to accomodate this change so that the
rest of us have some idea how to proceed?

Thanks,

- Ben
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] musb: am35x: fix compile error due to control apis

[Ben Gamari]

On Tue, 18 Jan 2011 14:15:13 -0500, Ben Gamari <bgamari.foss@gmail.com> wrote:
> On Mon,  6 Dec 2010 13:43:31 +0530, Ajay Kumar Gupta <ajay.gupta@ti.com> wrote:
> > As the control.h have been moved to new location and it's
> > uses are not allowed to drivers directly so moving the phy
> > control, interrupt clear and reset functionality to board
> > files.
> > 
> What happened to the board changes for board-am3517evm?

Ping. A response would be appreciated.

Cheers,

- Ben

Re: [PATCH v2] musb: am35x: fix compile error due to control apis

[Felipe Balbi]

Hi,

On Mon, Jan 24, 2011 at 10:45:22AM -0500, Ben Gamari wrote:
> On Tue, 18 Jan 2011 14:15:13 -0500, Ben Gamari <bgamari.foss-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Mon,  6 Dec 2010 13:43:31 +0530, Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org> wrote:
> > > As the control.h have been moved to new location and it's
> > > uses are not allowed to drivers directly so moving the phy
> > > control, interrupt clear and reset functionality to board
> > > files.
> > > 
> > What happened to the board changes for board-am3517evm?
> 
> Ping. A response would be appreciated.

sorry, quite busy at the moment, but here's one answer. Check this
commit:

commit a9c037832e9624e240c5019d0e01e9352e8f638d
Author: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org>
Date:   Tue Dec 7 18:57:45 2010 +0530

    musb: am35x: fix compile error due to control apis
    
    commit 4814ced5116e3b73dc4f63eec84999739fc8ed11 (OMAP:
    control: move plat-omap/control.h to mach-omap2/control.h)
    moved <plat/control.h> to another location, preventing
    drivers from accessing it, so we need to pass function
    pointers from arch code to be able to talk to internal
    PHY on AM35x.
    
    Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org>
    Signed-off-by: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>

$ git describe a9c037832e9624e240c5019d0e01e9352e8f638d
v2.6.37-rc1-95-ga9c0378

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] musb: am35x: fix compile error due to control apis

[Ben Gamari]

On Thu, 27 Jan 2011 06:48:10 +0200, Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> wrote:
> sorry, quite busy at the moment, but here's one answer. Check this
> commit:
> 
> commit a9c037832e9624e240c5019d0e01e9352e8f638d
> ...

Thanks for the reply! So I take it that omap's usb_musb_init takes care
of all of the new *_board_data fields now and therefore no board changes
are necessary?

Thanks,

- Ben
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] musb: am35x: fix compile error due to control apis

[Felipe Balbi]

On Thu, Jan 27, 2011 at 07:31:23AM -0500, Ben Gamari wrote:
> On Thu, 27 Jan 2011 06:48:10 +0200, Felipe Balbi <balbi@ti.com> wrote:
> > sorry, quite busy at the moment, but here's one answer. Check this
> > commit:
> > 
> > commit a9c037832e9624e240c5019d0e01e9352e8f638d
> > ...
> 
> Thanks for the reply! So I take it that omap's usb_musb_init takes care
> of all of the new *_board_data fields now and therefore no board changes
> are necessary?

correct.

-- 
balbi