[PATCH 1/2] AM35x: musb: fix compilation error

[PATCH 1/2] AM35x: musb: fix compilation error

[Ajay Kumar Gupta]

Fixes compilation error as control.h APIs are not available to
drivers/usb/musb/am35x.c file. Earlier it was getting included
from <plat/control.h> but now moved to new location by another
pacth.

Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org>
---
Patch created against latest Linus's tree (v2.6.37-rc3)

 arch/arm/plat-omap/include/plat/usb.h |    2 ++
 drivers/usb/musb/am35x.c              |    1 -
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h
index 59c7fe7..f1b8b40 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -6,6 +6,8 @@
 #include <linux/usb/musb.h>
 #include <plat/board.h>
 
+#include "../../../mach-omap2/control.h"
+
 #define OMAP3_HS_USB_PORTS	3
 enum ehci_hcd_omap_mode {
 	EHCI_HCD_OMAP_MODE_UNKNOWN,
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index b0aabf3..30f524a 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"
-- 
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

[PATCH 2/2] musb_gadget: fix compilation warning

[Ajay Kumar Gupta]

Fixes below compilation warning when musb driver is compiled for
PIO mode.
drivers/usb/musb/musb_gadget.c: In function 'musb_g_rx':
drivers/usb/musb/musb_gadget.c:840:
		warning: label 'exit' defined but not used

Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
---
Patch created against latest Linus's tree (v2.6.37-rc3)

 drivers/usb/musb/musb_gadget.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 36cfd06..bb9f05e 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -837,7 +837,9 @@ void musb_g_rx(struct musb *musb, u8 epnum)
 		if (!request)
 			return;
 	}
+#if defined(CONFIG_USB_INVENTRA_DMA) || defined(CONFIG_USB_TUSB_OMAP_DMA)
 exit:
+#endif
 	/* Analyze request */
 	rxstate(musb, to_musb_request(request));
 }
-- 
1.6.2.4

Re: [PATCH 1/2] AM35x: musb: fix compilation error

[Felipe Balbi]

Hi,

On Mon, Nov 22, 2010 at 02:22:40PM +0530, Ajay Kumar Gupta wrote:
>Fixes compilation error as control.h APIs are not available to
>drivers/usb/musb/am35x.c file. Earlier it was getting included
>from <plat/control.h> but now moved to new location by another
>pacth.
>
>Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org>

Tony ? Do you ack the usage of that header ?

>---
>Patch created against latest Linus's tree (v2.6.37-rc3)
>
> arch/arm/plat-omap/include/plat/usb.h |    2 ++
> drivers/usb/musb/am35x.c              |    1 -
> 2 files changed, 2 insertions(+), 1 deletions(-)
>
>diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h
>index 59c7fe7..f1b8b40 100644
>--- a/arch/arm/plat-omap/include/plat/usb.h
>+++ b/arch/arm/plat-omap/include/plat/usb.h
>@@ -6,6 +6,8 @@
> #include <linux/usb/musb.h>
> #include <plat/board.h>
>
>+#include "../../../mach-omap2/control.h"
>+
> #define OMAP3_HS_USB_PORTS	3
> enum ehci_hcd_omap_mode {
> 	EHCI_HCD_OMAP_MODE_UNKNOWN,
>diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
>index b0aabf3..30f524a 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"
>-- 
>1.6.2.4

-- 
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 2/2] musb_gadget: fix compilation warning

[Felipe Balbi]

On Mon, Nov 22, 2010 at 02:22:41PM +0530, Ajay Kumar Gupta wrote:
>Fixes below compilation warning when musb driver is compiled for
>PIO mode.
>drivers/usb/musb/musb_gadget.c: In function 'musb_g_rx':
>drivers/usb/musb/musb_gadget.c:840:
>		warning: label 'exit' defined but not used
>
>Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org>

Applied, thanks

-- 
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 1/2] AM35x: musb: fix compilation error

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [101122 02:12]:
> Hi,
> 
> On Mon, Nov 22, 2010 at 02:22:40PM +0530, Ajay Kumar Gupta wrote:
> >Fixes compilation error as control.h APIs are not available to
> >drivers/usb/musb/am35x.c file. Earlier it was getting included
> >from <plat/control.h> but now moved to new location by another
> >pacth.
> >
> >Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
> 
> 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.

Regards,

Tony

Re: [PATCH 1/2] AM35x: musb: fix compilation error

[Felipe Balbi]

On Tue, Nov 30, 2010 at 10:30:10AM -0800, Tony Lindgren wrote:
>* Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> [101122 02:12]:
>> Hi,
>>
>> On Mon, Nov 22, 2010 at 02:22:40PM +0530, Ajay Kumar Gupta wrote:
>> >Fixes compilation error as control.h APIs are not available to
>> >drivers/usb/musb/am35x.c file. Earlier it was getting included
>> >from <plat/control.h> but now moved to new location by another
>> >pacth.
>> >
>> >Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org>
>>
>> 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.

That was my feeling too. Anand, care to update ?!?

-- 
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 1/2] AM35x: musb: fix compilation error

[Gupta, Ajay Kumar]

> >> 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-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 1/2] AM35x: musb: fix compilation error

[Felipe Balbi]

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-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 1/2] AM35x: musb: fix compilation error

[Gupta, Ajay Kumar]

> > 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 ?

AM35x PHY is built inside the ip and we need to configure it through
PHY control register. 

Additionally we also need to access IPSS reset and Intr clear register
as well which would not fit inside otg_transceiver.

Ajay
> 
> --
> 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 1/2] AM35x: musb: fix compilation error

[Felipe Balbi]

On Thu, Dec 02, 2010 at 10:22:11AM +0530, Gupta, Ajay Kumar wrote:
>> > 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 ?
>
>AM35x PHY is built inside the ip and we need to configure it through
>PHY control register.
>
>Additionally we also need to access IPSS reset and Intr clear register
>as well which would not fit inside otg_transceiver.

how about passing an extra struct resource if am35x ? Then you could
ioremap that base on am35x.c and use normal musb_read/write functions.

-- 
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 1/2] AM35x: musb: fix compilation error

[Gupta, Ajay Kumar]

> >> why don't you add a proper otg_transceiver driver for am35x ?
> >> Is it like omap4's internal phy ? A separate block ?
> >
> >AM35x PHY is built inside the ip and we need to configure it through
> >PHY control register.
> >
> >Additionally we also need to access IPSS reset and Intr clear register
> >as well which would not fit inside otg_transceiver.
> 
> how about passing an extra struct resource if am35x ? Then you could
> ioremap that base on am35x.c and use normal musb_read/write functions.

We already have generic APIs so I think we can pass function pointers to
musb driver via "struct omap_musb_board_data",

 struct omap_musb_board_data {
+	void	(*phy_on) (void)
+	void 	(*phy_off) (void)
+	void  (*intr_clr) (void)
 }

Reset part can be done in board file itself same as Ethernet driver is doing.

Does this look fine?

-Ajay
> 
> --
> 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 1/2] AM35x: musb: fix compilation error

[Felipe Balbi]

On Thu, Dec 02, 2010 at 04:13:50PM +0530, Gupta, Ajay Kumar wrote:
>> >> why don't you add a proper otg_transceiver driver for am35x ?
>> >> Is it like omap4's internal phy ? A separate block ?
>> >
>> >AM35x PHY is built inside the ip and we need to configure it through
>> >PHY control register.
>> >
>> >Additionally we also need to access IPSS reset and Intr clear register
>> >as well which would not fit inside otg_transceiver.
>>
>> how about passing an extra struct resource if am35x ? Then you could
>> ioremap that base on am35x.c and use normal musb_read/write functions.
>
>We already have generic APIs so I think we can pass function pointers to
>musb driver via "struct omap_musb_board_data",
>
> struct omap_musb_board_data {
>+	void	(*phy_on) (void)
>+	void 	(*phy_off) (void)
>+	void  (*intr_clr) (void)
> }
>
>Reset part can be done in board file itself same as Ethernet driver is doing.
>
>Does this look fine?

so those would be "turn phy on", "turn phy off" and "clear interrupt"
apis ?

How about:

int (*set_phy_power)(unsigned on);
void (*clear_phy_irq)(void);

You'd need one less API for that. BTW, could you do it on top of my
musb-hw branch ? Then I can push together with those for merge window.

-- 
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 1/2] AM35x: musb: fix compilation error

[Gupta, Ajay Kumar]

> >We already have generic APIs so I think we can pass function pointers to
> >musb driver via "struct omap_musb_board_data",
> >
> > struct omap_musb_board_data {
> >+	void	(*phy_on) (void)
> >+	void 	(*phy_off) (void)
> >+	void  (*intr_clr) (void)
> > }
> >
> >Reset part can be done in board file itself same as Ethernet driver is
> doing.
> >
> >Does this look fine?
> 
> so those would be "turn phy on", "turn phy off" and "clear interrupt"
> apis ?
> 
> How about:
> int (*set_phy_power)(unsigned on);
Looks good.

> void (*clear_phy_irq)(void);
This is actually musb ip interrupt clear so I will make it like,

void (*clear_irq) (void);

> 
> You'd need one less API for that. BTW, could you do it on top of my
> musb-hw branch ? Then I can push together with those for merge window.
Not yet, I will send once completed.

Thanks,
Ajay
> 
> --
> 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 1/2] AM35x: musb: fix compilation error

[Felipe Balbi]

On Fri, Dec 03, 2010 at 07:08:53PM +0530, Gupta, Ajay Kumar wrote:
>> >We already have generic APIs so I think we can pass function pointers to
>> >musb driver via "struct omap_musb_board_data",
>> >
>> > struct omap_musb_board_data {
>> >+	void	(*phy_on) (void)
>> >+	void 	(*phy_off) (void)
>> >+	void  (*intr_clr) (void)
>> > }
>> >
>> >Reset part can be done in board file itself same as Ethernet driver is
>> doing.
>> >
>> >Does this look fine?
>>
>> so those would be "turn phy on", "turn phy off" and "clear interrupt"
>> apis ?
>>
>> How about:
>> int (*set_phy_power)(unsigned on);
>Looks good.
>
>> void (*clear_phy_irq)(void);
>This is actually musb ip interrupt clear so I will make it like,
>
>void (*clear_irq) (void);

Is AM35x that different ? Can't you just write to MUSB_INTRRX
MUSB_INTRTX and MUSB_INTRUSB ??

-- 
balbi

RE: [PATCH 1/2] AM35x: musb: fix compilation error

[Gupta, Ajay Kumar]

> On Fri, Dec 03, 2010 at 07:08:53PM +0530, Gupta, Ajay Kumar wrote:
> >> >We already have generic APIs so I think we can pass function pointers
> to
> >> >musb driver via "struct omap_musb_board_data",
> >> >
> >> > struct omap_musb_board_data {
> >> >+	void	(*phy_on) (void)
> >> >+	void 	(*phy_off) (void)
> >> >+	void  (*intr_clr) (void)
> >> > }
> >> >
> >> >Reset part can be done in board file itself same as Ethernet driver is
> >> doing.
> >> >
> >> >Does this look fine?
> >>
> >> so those would be "turn phy on", "turn phy off" and "clear interrupt"
> >> apis ?
> >>
> >> How about:
> >> int (*set_phy_power)(unsigned on);
> >Looks good.
> >
> >> void (*clear_phy_irq)(void);
> >This is actually musb ip interrupt clear so I will make it like,
> >
> >void (*clear_irq) (void);
> 
> Is AM35x that different ? Can't you just write to MUSB_INTRRX
> MUSB_INTRTX and MUSB_INTRUSB ??
Writing to MUSB_INTRRX/TX/USB wouldn't help. We have to clear interrupt
Bit in control register INTR_LVL_CLR.

-Ajay
> 
> --
> balbi

Re: [PATCH 1/2] AM35x: musb: fix compilation error

[Felipe Balbi]

On Mon, Dec 06, 2010 at 05:24:53PM +0530, Gupta, Ajay Kumar wrote:
>> On Fri, Dec 03, 2010 at 07:08:53PM +0530, Gupta, Ajay Kumar wrote:
>> >> >We already have generic APIs so I think we can pass function pointers
>> to
>> >> >musb driver via "struct omap_musb_board_data",
>> >> >
>> >> > struct omap_musb_board_data {
>> >> >+	void	(*phy_on) (void)
>> >> >+	void 	(*phy_off) (void)
>> >> >+	void  (*intr_clr) (void)
>> >> > }
>> >> >
>> >> >Reset part can be done in board file itself same as Ethernet driver is
>> >> doing.
>> >> >
>> >> >Does this look fine?
>> >>
>> >> so those would be "turn phy on", "turn phy off" and "clear interrupt"
>> >> apis ?
>> >>
>> >> How about:
>> >> int (*set_phy_power)(unsigned on);
>> >Looks good.
>> >
>> >> void (*clear_phy_irq)(void);
>> >This is actually musb ip interrupt clear so I will make it like,
>> >
>> >void (*clear_irq) (void);
>>
>> Is AM35x that different ? Can't you just write to MUSB_INTRRX
>> MUSB_INTRTX and MUSB_INTRUSB ??
>Writing to MUSB_INTRRX/TX/USB wouldn't help. We have to clear interrupt
>Bit in control register INTR_LVL_CLR.

I see, thanks for the info :-)

-- 
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 1/2] AM35x: musb: fix compilation error

[Gupta, Ajay Kumar]

[-- Attachment #1: Type: text/plain, Size: 404 bytes --]

Hi,
> >> Is AM35x that different ? Can't you just write to MUSB_INTRRX
> >> MUSB_INTRTX and MUSB_INTRUSB ??
> >Writing to MUSB_INTRRX/TX/USB wouldn't help. We have to clear interrupt
> >Bit in control register INTR_LVL_CLR.
> 
> I see, thanks for the info :-)

Felipe,

I have recreated this patch (attached) on top of your patch
set and AM35x is working.

Thanks,
Ajay
> 
> --
> balbi

[-- Attachment #2: 0001-musb-am35x-fix-compile-error-due-to-control-apis.patch --]
[-- Type: application/octet-stream, Size: 10742 bytes --]

From 92072384e25522986464608cbd80c4bc6d5fb7d6 Mon Sep 17 00:00:00 2001
From: Ajay Kumar Gupta <ajay.gupta@ti.com>
Date: Tue, 7 Dec 2010 18:57:45 +0530
Subject: [PATCH] musb: am35x: fix compile error due to control apis

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@ti.com>
---
 arch/arm/mach-omap2/usb-musb.c        |   97 ++++++++++++++++++++++++
 arch/arm/plat-omap/include/plat/usb.h |    4 +
 drivers/usb/musb/am35x.c              |  130 +++++++++++---------------------
 3 files changed, 146 insertions(+), 85 deletions(-)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 9107883..5298949 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"
 
 #if defined(CONFIG_USB_MUSB_OMAP2PLUS) || defined (CONFIG_USB_MUSB_AM35X)
 
+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,
@@ -96,6 +189,10 @@ void __init usb_musb_init(struct omap_musb_board_data *board_data)
 		musb_device.name = "musb-am35x";
 		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 9b1893f..5c02416 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -70,6 +70,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 3f56e7e..76c8d48 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -32,7 +32,6 @@
 #include <linux/platform_device.h>
 #include <linux/dma-mapping.h>
 
-#include <plat/control.h>
 #include <plat/usb.h>
 
 #include "musb_core.h"
@@ -90,47 +89,6 @@ struct am35x_glue {
 };
 #define glue_to_musb(g)		platform_get_drvdata(g->musb)
 
-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);
-}
-
 /*
  * am35x_musb_enable - enable interrupts
  */
@@ -265,9 +223,12 @@ static irqreturn_t am35x_musb_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);
 
@@ -356,9 +317,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);
 	}
@@ -374,37 +334,26 @@ eoi:
 
 static int am35x_musb_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;
 }
 
 static int am35x_musb_init(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;
 	void __iomem *reg_base = musb->ctrl_base;
-	u32 rev, lvl_intr, sw_reset;
+	u32 rev;
 
 	musb->mregs += USB_MENTOR_CORE_OFFSET;
 
@@ -421,39 +370,40 @@ static int am35x_musb_init(struct musb *musb)
 	if (is_host_enabled(musb))
 		setup_timer(&otg_workaround, otg_timer, (unsigned long) musb);
 
-	/* 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 musb */
+	if (data->reset)
+		data->reset();
 
 	/* Reset the controller */
 	musb_writel(reg_base, USB_CTRL_REG, AM35X_SOFT_RESET_MASK);
 
 	/* 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_musb_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;
 }
 
 static int am35x_musb_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();
@@ -630,8 +580,13 @@ static int __exit am35x_remove(struct platform_device *pdev)
 static int am35x_suspend(struct device *dev)
 {
 	struct am35x_glue	*glue = dev_get_drvdata(dev);
+	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);
 
-	phy_off();
 	clk_disable(glue->phy_clk);
 	clk_disable(glue->clk);
 
@@ -641,9 +596,14 @@ static int am35x_suspend(struct device *dev)
 static int am35x_resume(struct device *dev)
 {
 	struct am35x_glue	*glue = dev_get_drvdata(dev);
+	struct musb_hdrc_platform_data *plat = dev->platform_data;
+	struct omap_musb_board_data *data = plat->board_data;
 	int			ret;
 
-	phy_on();
+	/* Start the on-chip PHY and its PLL. */
+	if (data->set_phy_power)
+		data->set_phy_power(1);
+
 	ret = clk_enable(glue->phy_clk);
 	if (ret) {
 		dev_err(dev, "failed to enable PHY clock\n");
-- 
1.6.2.4

Re: [PATCH 1/2] AM35x: musb: fix compilation error

[Felipe Balbi]

On Tue, Dec 07, 2010 at 07:25:12PM +0530, Gupta, Ajay Kumar wrote:
>Hi,
>> >> Is AM35x that different ? Can't you just write to MUSB_INTRRX
>> >> MUSB_INTRTX and MUSB_INTRUSB ??
>> >Writing to MUSB_INTRRX/TX/USB wouldn't help. We have to clear interrupt
>> >Bit in control register INTR_LVL_CLR.
>>
>> I see, thanks for the info :-)
>
>Felipe,
>
>I have recreated this patch (attached) on top of your patch
>set and AM35x is working.

applied it. Thanks

-- 
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