[PATCH 0/3] omap: musb: Add device tree support

[PATCH 0/3] omap: musb: Add device tree support

[Kishon Vijay Abraham I]

This patch series adds device tree support for MUSB.

The glue layer is now made to write to mailbox register (present in
control module) instead of calling phy layer to write to mailbox
register. Writing to mailbox register notifies the core of events like
device connect/disconnect.

Previously these patches were part of
[PATCH v7 0/7] omap: musb: Add device tree support

This patch series was created to contain only the *musb* part and it
also has one hwmod patch.

This patch series was created on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git musb

Kishon Vijay Abraham I (3):
  arm: omap: hwmod: add a new addr space in otg for writing to control
    module
  usb: musb: omap: write directly to mailbox instead of using phy
  usb: musb: omap: Add device tree support for omap musb glue

 Documentation/devicetree/bindings/usb/omap-usb.txt |   33 ++++++
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    5 +
 drivers/usb/musb/omap2430.c                        |  106 ++++++++++++++++++--
 drivers/usb/musb/omap2430.h                        |    9 ++
 4 files changed, 146 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt

-- 
1.7.9.5

[PATCH 0/3] omap: musb: Add device tree support

[Kishon Vijay Abraham I]

This patch series adds device tree support for MUSB.

The glue layer is now made to write to mailbox register (present in
control module) instead of calling phy layer to write to mailbox
register. Writing to mailbox register notifies the core of events like
device connect/disconnect.

Previously these patches were part of
[PATCH v7 0/7] omap: musb: Add device tree support

This patch series was created to contain only the *musb* part and it
also has one hwmod patch.

This patch series was created on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git musb

Kishon Vijay Abraham I (3):
  arm: omap: hwmod: add a new addr space in otg for writing to control
    module
  usb: musb: omap: write directly to mailbox instead of using phy
  usb: musb: omap: Add device tree support for omap musb glue

 Documentation/devicetree/bindings/usb/omap-usb.txt |   33 ++++++
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    5 +
 drivers/usb/musb/omap2430.c                        |  106 ++++++++++++++++++--
 drivers/usb/musb/omap2430.h                        |    9 ++
 4 files changed, 146 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt

-- 
1.7.9.5

[PATCH 0/3] omap: musb: Add device tree support

[Kishon Vijay Abraham I]

This patch series adds device tree support for MUSB.

The glue layer is now made to write to mailbox register (present in
control module) instead of calling phy layer to write to mailbox
register. Writing to mailbox register notifies the core of events like
device connect/disconnect.

Previously these patches were part of
[PATCH v7 0/7] omap: musb: Add device tree support

This patch series was created to contain only the *musb* part and it
also has one hwmod patch.

This patch series was created on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git musb

Kishon Vijay Abraham I (3):
  arm: omap: hwmod: add a new addr space in otg for writing to control
    module
  usb: musb: omap: write directly to mailbox instead of using phy
  usb: musb: omap: Add device tree support for omap musb glue

 Documentation/devicetree/bindings/usb/omap-usb.txt |   33 ++++++
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    5 +
 drivers/usb/musb/omap2430.c                        |  106 ++++++++++++++++++--
 drivers/usb/musb/omap2430.h                        |    9 ++
 4 files changed, 146 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt

-- 
1.7.9.5

[PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Kishon Vijay Abraham I]

The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.

Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.

Cc: Benoit Cousson <b-cousson-l0cyMroinI0@public.gmane.org>
Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..02341bc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
 		.pa_end		= 0x4a0ab003,
 		.flags		= ADDR_TYPE_RT
 	},
+	{
+		.pa_start	= 0x4a00233c,
+		.pa_end		= 0x4a00233f,
+		.flags		= ADDR_TYPE_RT
+	},
 	{ }
 };
 
-- 
1.7.9.5

[PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Kishon Vijay Abraham I]

The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.

Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.

Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..02341bc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
 		.pa_end		= 0x4a0ab003,
 		.flags		= ADDR_TYPE_RT
 	},
+	{
+		.pa_start	= 0x4a00233c,
+		.pa_end		= 0x4a00233f,
+		.flags		= ADDR_TYPE_RT
+	},
 	{ }
 };
 
-- 
1.7.9.5

[PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Kishon Vijay Abraham I]

The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.

Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.

Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..02341bc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
 		.pa_end		= 0x4a0ab003,
 		.flags		= ADDR_TYPE_RT
 	},
+	{
+		.pa_start	= 0x4a00233c,
+		.pa_end		= 0x4a00233f,
+		.flags		= ADDR_TYPE_RT
+	},
 	{ }
 };
 
-- 
1.7.9.5

Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Vaibhav Hiremath]

On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> The mailbox register for usb otg in omap is present in control module.
> On detection of any events VBUS or ID, this register should be written
> to send the notification to musb core.
> 
> Till we have a separate control module driver to write to control module,
> omap2430 will handle the register writes to control module by itself. So
> a new address space to represent this control module register is added
> to usb_otg_hs.
> 
> Cc: Benoit Cousson <b-cousson@ti.com>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 242aee4..02341bc 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
>  		.pa_end		= 0x4a0ab003,
>  		.flags		= ADDR_TYPE_RT
>  	},
> +	{
> +		.pa_start	= 0x4a00233c,
> +		.pa_end		= 0x4a00233f,
> +		.flags		= ADDR_TYPE_RT
> +	},

I do not have any objection/comment here, but I believe this is control
module address space required for USB module, right?
I am not sure this is right way of accessing control module space.
Actually Control Module Access required for drivers is one of the
blocking issue we have currently.

Also there was some effort put up by 'Konstantine' to convert Control
module to MFD driver, I haven't seen any further update on it. But it
would be good to check with him.

Thanks,
Vaibhav
>  	{ }
>  };
>  
> 

Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Vaibhav Hiremath]

On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> The mailbox register for usb otg in omap is present in control module.
> On detection of any events VBUS or ID, this register should be written
> to send the notification to musb core.
> 
> Till we have a separate control module driver to write to control module,
> omap2430 will handle the register writes to control module by itself. So
> a new address space to represent this control module register is added
> to usb_otg_hs.
> 
> Cc: Benoit Cousson <b-cousson@ti.com>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 242aee4..02341bc 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
>  		.pa_end		= 0x4a0ab003,
>  		.flags		= ADDR_TYPE_RT
>  	},
> +	{
> +		.pa_start	= 0x4a00233c,
> +		.pa_end		= 0x4a00233f,
> +		.flags		= ADDR_TYPE_RT
> +	},

I do not have any objection/comment here, but I believe this is control
module address space required for USB module, right?
I am not sure this is right way of accessing control module space.
Actually Control Module Access required for drivers is one of the
blocking issue we have currently.

Also there was some effort put up by 'Konstantine' to convert Control
module to MFD driver, I haven't seen any further update on it. But it
would be good to check with him.

Thanks,
Vaibhav
>  	{ }
>  };
>  
> 

[PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Vaibhav Hiremath]

On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> The mailbox register for usb otg in omap is present in control module.
> On detection of any events VBUS or ID, this register should be written
> to send the notification to musb core.
> 
> Till we have a separate control module driver to write to control module,
> omap2430 will handle the register writes to control module by itself. So
> a new address space to represent this control module register is added
> to usb_otg_hs.
> 
> Cc: Benoit Cousson <b-cousson@ti.com>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 242aee4..02341bc 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
>  		.pa_end		= 0x4a0ab003,
>  		.flags		= ADDR_TYPE_RT
>  	},
> +	{
> +		.pa_start	= 0x4a00233c,
> +		.pa_end		= 0x4a00233f,
> +		.flags		= ADDR_TYPE_RT
> +	},

I do not have any objection/comment here, but I believe this is control
module address space required for USB module, right?
I am not sure this is right way of accessing control module space.
Actually Control Module Access required for drivers is one of the
blocking issue we have currently.

Also there was some effort put up by 'Konstantine' to convert Control
module to MFD driver, I haven't seen any further update on it. But it
would be good to check with him.

Thanks,
Vaibhav
>  	{ }
>  };
>  
> 

Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Felipe Balbi]

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

Hi,

On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> > The mailbox register for usb otg in omap is present in control module.
> > On detection of any events VBUS or ID, this register should be written
> > to send the notification to musb core.
> > 
> > Till we have a separate control module driver to write to control module,
> > omap2430 will handle the register writes to control module by itself. So
> > a new address space to represent this control module register is added
> > to usb_otg_hs.
> > 
> > Cc: Benoit Cousson <b-cousson@ti.com>
> > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > ---
> >  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > index 242aee4..02341bc 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
> >  		.pa_end		= 0x4a0ab003,
> >  		.flags		= ADDR_TYPE_RT
> >  	},
> > +	{
> > +		.pa_start	= 0x4a00233c,
> > +		.pa_end		= 0x4a00233f,
> > +		.flags		= ADDR_TYPE_RT
> > +	},
> 
> I do not have any objection/comment here, but I believe this is control
> module address space required for USB module, right?
> I am not sure this is right way of accessing control module space.
> Actually Control Module Access required for drivers is one of the
> blocking issue we have currently.
> 
> Also there was some effort put up by 'Konstantine' to convert Control
> module to MFD driver, I haven't seen any further update on it. But it
> would be good to check with him.

this was an agreement with Benoit since we already lost a couple merge
windows for this patchset. We agreed to wait until -rc4 for SCM driver
and if it wasn't ready, we'd go ahead with this and SCM author would fix
it up on a patch converting users to new SCM driver.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Felipe Balbi]

Hi,

On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> > The mailbox register for usb otg in omap is present in control module.
> > On detection of any events VBUS or ID, this register should be written
> > to send the notification to musb core.
> > 
> > Till we have a separate control module driver to write to control module,
> > omap2430 will handle the register writes to control module by itself. So
> > a new address space to represent this control module register is added
> > to usb_otg_hs.
> > 
> > Cc: Benoit Cousson <b-cousson@ti.com>
> > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > ---
> >  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > index 242aee4..02341bc 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
> >  		.pa_end		= 0x4a0ab003,
> >  		.flags		= ADDR_TYPE_RT
> >  	},
> > +	{
> > +		.pa_start	= 0x4a00233c,
> > +		.pa_end		= 0x4a00233f,
> > +		.flags		= ADDR_TYPE_RT
> > +	},
> 
> I do not have any objection/comment here, but I believe this is control
> module address space required for USB module, right?
> I am not sure this is right way of accessing control module space.
> Actually Control Module Access required for drivers is one of the
> blocking issue we have currently.
> 
> Also there was some effort put up by 'Konstantine' to convert Control
> module to MFD driver, I haven't seen any further update on it. But it
> would be good to check with him.

this was an agreement with Benoit since we already lost a couple merge
windows for this patchset. We agreed to wait until -rc4 for SCM driver
and if it wasn't ready, we'd go ahead with this and SCM author would fix
it up on a patch converting users to new SCM driver.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120906/65c44fa3/attachment.sig>

Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Felipe Balbi]

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

Hi,

On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
> > 
> > 
> > On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> > > The mailbox register for usb otg in omap is present in control module.
> > > On detection of any events VBUS or ID, this register should be written
> > > to send the notification to musb core.
> > > 
> > > Till we have a separate control module driver to write to control module,
> > > omap2430 will handle the register writes to control module by itself. So
> > > a new address space to represent this control module register is added
> > > to usb_otg_hs.
> > > 
> > > Cc: Benoit Cousson <b-cousson@ti.com>
> > > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > > ---
> > >  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
> > >  1 file changed, 5 insertions(+)
> > > 
> > > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > index 242aee4..02341bc 100644
> > > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
> > >  		.pa_end		= 0x4a0ab003,
> > >  		.flags		= ADDR_TYPE_RT
> > >  	},
> > > +	{
> > > +		.pa_start	= 0x4a00233c,
> > > +		.pa_end		= 0x4a00233f,
> > > +		.flags		= ADDR_TYPE_RT
> > > +	},
> > 
> > I do not have any objection/comment here, but I believe this is control
> > module address space required for USB module, right?
> > I am not sure this is right way of accessing control module space.
> > Actually Control Module Access required for drivers is one of the
> > blocking issue we have currently.
> > 
> > Also there was some effort put up by 'Konstantine' to convert Control
> > module to MFD driver, I haven't seen any further update on it. But it
> > would be good to check with him.
> 
> this was an agreement with Benoit since we already lost a couple merge
> windows for this patchset. We agreed to wait until -rc4 for SCM driver
> and if it wasn't ready, we'd go ahead with this and SCM author would fix
> it up on a patch converting users to new SCM driver.

Tony, can I get your Acked-by to this patch so I can take it together
with the rest of the series ? Thanks

ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
to merge it into your tree once I apply.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Felipe Balbi]

Hi,

On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
> > 
> > 
> > On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> > > The mailbox register for usb otg in omap is present in control module.
> > > On detection of any events VBUS or ID, this register should be written
> > > to send the notification to musb core.
> > > 
> > > Till we have a separate control module driver to write to control module,
> > > omap2430 will handle the register writes to control module by itself. So
> > > a new address space to represent this control module register is added
> > > to usb_otg_hs.
> > > 
> > > Cc: Benoit Cousson <b-cousson@ti.com>
> > > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > > ---
> > >  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
> > >  1 file changed, 5 insertions(+)
> > > 
> > > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > index 242aee4..02341bc 100644
> > > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
> > >  		.pa_end		= 0x4a0ab003,
> > >  		.flags		= ADDR_TYPE_RT
> > >  	},
> > > +	{
> > > +		.pa_start	= 0x4a00233c,
> > > +		.pa_end		= 0x4a00233f,
> > > +		.flags		= ADDR_TYPE_RT
> > > +	},
> > 
> > I do not have any objection/comment here, but I believe this is control
> > module address space required for USB module, right?
> > I am not sure this is right way of accessing control module space.
> > Actually Control Module Access required for drivers is one of the
> > blocking issue we have currently.
> > 
> > Also there was some effort put up by 'Konstantine' to convert Control
> > module to MFD driver, I haven't seen any further update on it. But it
> > would be good to check with him.
> 
> this was an agreement with Benoit since we already lost a couple merge
> windows for this patchset. We agreed to wait until -rc4 for SCM driver
> and if it wasn't ready, we'd go ahead with this and SCM author would fix
> it up on a patch converting users to new SCM driver.

Tony, can I get your Acked-by to this patch so I can take it together
with the rest of the series ? Thanks

ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
to merge it into your tree once I apply.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120906/2db3b3d5/attachment.sig>

Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [120906 10:23]:
> Hi,
> 
> On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
> > Hi,
> > 
> > On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
> > > 
> > > 
> > > On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> > > > The mailbox register for usb otg in omap is present in control module.
> > > > On detection of any events VBUS or ID, this register should be written
> > > > to send the notification to musb core.
> > > > 
> > > > Till we have a separate control module driver to write to control module,
> > > > omap2430 will handle the register writes to control module by itself. So
> > > > a new address space to represent this control module register is added
> > > > to usb_otg_hs.
> > > > 
> > > > Cc: Benoit Cousson <b-cousson@ti.com>
> > > > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > > > ---
> > > >  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
> > > >  1 file changed, 5 insertions(+)
> > > > 
> > > > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > index 242aee4..02341bc 100644
> > > > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
> > > >  		.pa_end		= 0x4a0ab003,
> > > >  		.flags		= ADDR_TYPE_RT
> > > >  	},
> > > > +	{
> > > > +		.pa_start	= 0x4a00233c,
> > > > +		.pa_end		= 0x4a00233f,
> > > > +		.flags		= ADDR_TYPE_RT
> > > > +	},
> > > 
> > > I do not have any objection/comment here, but I believe this is control
> > > module address space required for USB module, right?
> > > I am not sure this is right way of accessing control module space.
> > > Actually Control Module Access required for drivers is one of the
> > > blocking issue we have currently.
> > > 
> > > Also there was some effort put up by 'Konstantine' to convert Control
> > > module to MFD driver, I haven't seen any further update on it. But it
> > > would be good to check with him.
> > 
> > this was an agreement with Benoit since we already lost a couple merge
> > windows for this patchset. We agreed to wait until -rc4 for SCM driver
> > and if it wasn't ready, we'd go ahead with this and SCM author would fix
> > it up on a patch converting users to new SCM driver.
> 
> Tony, can I get your Acked-by to this patch so I can take it together
> with the rest of the series ? Thanks
> 
> ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
> to merge it into your tree once I apply.

It would be best if this got acked by Benoit and Paul as they may
have some other patches queued up. I'll ack if they ack ;)

Tony

[PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [120906 10:23]:
> Hi,
> 
> On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
> > Hi,
> > 
> > On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
> > > 
> > > 
> > > On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> > > > The mailbox register for usb otg in omap is present in control module.
> > > > On detection of any events VBUS or ID, this register should be written
> > > > to send the notification to musb core.
> > > > 
> > > > Till we have a separate control module driver to write to control module,
> > > > omap2430 will handle the register writes to control module by itself. So
> > > > a new address space to represent this control module register is added
> > > > to usb_otg_hs.
> > > > 
> > > > Cc: Benoit Cousson <b-cousson@ti.com>
> > > > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > > > ---
> > > >  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
> > > >  1 file changed, 5 insertions(+)
> > > > 
> > > > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > index 242aee4..02341bc 100644
> > > > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
> > > >  		.pa_end		= 0x4a0ab003,
> > > >  		.flags		= ADDR_TYPE_RT
> > > >  	},
> > > > +	{
> > > > +		.pa_start	= 0x4a00233c,
> > > > +		.pa_end		= 0x4a00233f,
> > > > +		.flags		= ADDR_TYPE_RT
> > > > +	},
> > > 
> > > I do not have any objection/comment here, but I believe this is control
> > > module address space required for USB module, right?
> > > I am not sure this is right way of accessing control module space.
> > > Actually Control Module Access required for drivers is one of the
> > > blocking issue we have currently.
> > > 
> > > Also there was some effort put up by 'Konstantine' to convert Control
> > > module to MFD driver, I haven't seen any further update on it. But it
> > > would be good to check with him.
> > 
> > this was an agreement with Benoit since we already lost a couple merge
> > windows for this patchset. We agreed to wait until -rc4 for SCM driver
> > and if it wasn't ready, we'd go ahead with this and SCM author would fix
> > it up on a patch converting users to new SCM driver.
> 
> Tony, can I get your Acked-by to this patch so I can take it together
> with the rest of the series ? Thanks
> 
> ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
> to merge it into your tree once I apply.

It would be best if this got acked by Benoit and Paul as they may
have some other patches queued up. I'll ack if they ack ;)

Tony

Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Felipe Balbi]

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

Hi,

On Thu, Sep 06, 2012 at 12:56:07PM -0700, Tony Lindgren wrote:
> * Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> [120906 10:23]:
> > Hi,
> > 
> > On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
> > > > 
> > > > 
> > > > On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> > > > > The mailbox register for usb otg in omap is present in control module.
> > > > > On detection of any events VBUS or ID, this register should be written
> > > > > to send the notification to musb core.
> > > > > 
> > > > > Till we have a separate control module driver to write to control module,
> > > > > omap2430 will handle the register writes to control module by itself. So
> > > > > a new address space to represent this control module register is added
> > > > > to usb_otg_hs.
> > > > > 
> > > > > Cc: Benoit Cousson <b-cousson-l0cyMroinI0@public.gmane.org>
> > > > > Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
> > > > > ---
> > > > >  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
> > > > >  1 file changed, 5 insertions(+)
> > > > > 
> > > > > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > > index 242aee4..02341bc 100644
> > > > > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > > @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
> > > > >  		.pa_end		= 0x4a0ab003,
> > > > >  		.flags		= ADDR_TYPE_RT
> > > > >  	},
> > > > > +	{
> > > > > +		.pa_start	= 0x4a00233c,
> > > > > +		.pa_end		= 0x4a00233f,
> > > > > +		.flags		= ADDR_TYPE_RT
> > > > > +	},
> > > > 
> > > > I do not have any objection/comment here, but I believe this is control
> > > > module address space required for USB module, right?
> > > > I am not sure this is right way of accessing control module space.
> > > > Actually Control Module Access required for drivers is one of the
> > > > blocking issue we have currently.
> > > > 
> > > > Also there was some effort put up by 'Konstantine' to convert Control
> > > > module to MFD driver, I haven't seen any further update on it. But it
> > > > would be good to check with him.
> > > 
> > > this was an agreement with Benoit since we already lost a couple merge
> > > windows for this patchset. We agreed to wait until -rc4 for SCM driver
> > > and if it wasn't ready, we'd go ahead with this and SCM author would fix
> > > it up on a patch converting users to new SCM driver.
> > 
> > Tony, can I get your Acked-by to this patch so I can take it together
> > with the rest of the series ? Thanks
> > 
> > ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
> > to merge it into your tree once I apply.
> 
> It would be best if this got acked by Benoit and Paul as they may
> have some other patches queued up. I'll ack if they ack ;)

Benoit, care to ack this patch ???

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Felipe Balbi]

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

Hi,

On Thu, Sep 06, 2012 at 12:56:07PM -0700, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [120906 10:23]:
> > Hi,
> > 
> > On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
> > > > 
> > > > 
> > > > On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> > > > > The mailbox register for usb otg in omap is present in control module.
> > > > > On detection of any events VBUS or ID, this register should be written
> > > > > to send the notification to musb core.
> > > > > 
> > > > > Till we have a separate control module driver to write to control module,
> > > > > omap2430 will handle the register writes to control module by itself. So
> > > > > a new address space to represent this control module register is added
> > > > > to usb_otg_hs.
> > > > > 
> > > > > Cc: Benoit Cousson <b-cousson@ti.com>
> > > > > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > > > > ---
> > > > >  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
> > > > >  1 file changed, 5 insertions(+)
> > > > > 
> > > > > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > > index 242aee4..02341bc 100644
> > > > > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > > @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
> > > > >  		.pa_end		= 0x4a0ab003,
> > > > >  		.flags		= ADDR_TYPE_RT
> > > > >  	},
> > > > > +	{
> > > > > +		.pa_start	= 0x4a00233c,
> > > > > +		.pa_end		= 0x4a00233f,
> > > > > +		.flags		= ADDR_TYPE_RT
> > > > > +	},
> > > > 
> > > > I do not have any objection/comment here, but I believe this is control
> > > > module address space required for USB module, right?
> > > > I am not sure this is right way of accessing control module space.
> > > > Actually Control Module Access required for drivers is one of the
> > > > blocking issue we have currently.
> > > > 
> > > > Also there was some effort put up by 'Konstantine' to convert Control
> > > > module to MFD driver, I haven't seen any further update on it. But it
> > > > would be good to check with him.
> > > 
> > > this was an agreement with Benoit since we already lost a couple merge
> > > windows for this patchset. We agreed to wait until -rc4 for SCM driver
> > > and if it wasn't ready, we'd go ahead with this and SCM author would fix
> > > it up on a patch converting users to new SCM driver.
> > 
> > Tony, can I get your Acked-by to this patch so I can take it together
> > with the rest of the series ? Thanks
> > 
> > ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
> > to merge it into your tree once I apply.
> 
> It would be best if this got acked by Benoit and Paul as they may
> have some other patches queued up. I'll ack if they ack ;)

Benoit, care to ack this patch ???

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Felipe Balbi]

Hi,

On Thu, Sep 06, 2012 at 12:56:07PM -0700, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [120906 10:23]:
> > Hi,
> > 
> > On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
> > > > 
> > > > 
> > > > On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> > > > > The mailbox register for usb otg in omap is present in control module.
> > > > > On detection of any events VBUS or ID, this register should be written
> > > > > to send the notification to musb core.
> > > > > 
> > > > > Till we have a separate control module driver to write to control module,
> > > > > omap2430 will handle the register writes to control module by itself. So
> > > > > a new address space to represent this control module register is added
> > > > > to usb_otg_hs.
> > > > > 
> > > > > Cc: Benoit Cousson <b-cousson@ti.com>
> > > > > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > > > > ---
> > > > >  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
> > > > >  1 file changed, 5 insertions(+)
> > > > > 
> > > > > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > > index 242aee4..02341bc 100644
> > > > > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > > > @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
> > > > >  		.pa_end		= 0x4a0ab003,
> > > > >  		.flags		= ADDR_TYPE_RT
> > > > >  	},
> > > > > +	{
> > > > > +		.pa_start	= 0x4a00233c,
> > > > > +		.pa_end		= 0x4a00233f,
> > > > > +		.flags		= ADDR_TYPE_RT
> > > > > +	},
> > > > 
> > > > I do not have any objection/comment here, but I believe this is control
> > > > module address space required for USB module, right?
> > > > I am not sure this is right way of accessing control module space.
> > > > Actually Control Module Access required for drivers is one of the
> > > > blocking issue we have currently.
> > > > 
> > > > Also there was some effort put up by 'Konstantine' to convert Control
> > > > module to MFD driver, I haven't seen any further update on it. But it
> > > > would be good to check with him.
> > > 
> > > this was an agreement with Benoit since we already lost a couple merge
> > > windows for this patchset. We agreed to wait until -rc4 for SCM driver
> > > and if it wasn't ready, we'd go ahead with this and SCM author would fix
> > > it up on a patch converting users to new SCM driver.
> > 
> > Tony, can I get your Acked-by to this patch so I can take it together
> > with the rest of the series ? Thanks
> > 
> > ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
> > to merge it into your tree once I apply.
> 
> It would be best if this got acked by Benoit and Paul as they may
> have some other patches queued up. I'll ack if they ack ;)

Benoit, care to ack this patch ???

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120910/f04477e0/attachment.sig>

Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Benoit Cousson]

Hi Felipe,

On 09/10/2012 05:58 PM, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Sep 06, 2012 at 12:56:07PM -0700, Tony Lindgren wrote:
>> * Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> [120906 10:23]:
>>> Hi,
>>>
>>> On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
>>>> Hi,
>>>>
>>>> On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
>>>>>
>>>>>
>>>>> On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
>>>>>> The mailbox register for usb otg in omap is present in control module.
>>>>>> On detection of any events VBUS or ID, this register should be written
>>>>>> to send the notification to musb core.
>>>>>>
>>>>>> Till we have a separate control module driver to write to control module,
>>>>>> omap2430 will handle the register writes to control module by itself. So
>>>>>> a new address space to represent this control module register is added
>>>>>> to usb_otg_hs.
>>>>>>
>>>>>> Cc: Benoit Cousson <b-cousson-l0cyMroinI0@public.gmane.org>
>>>>>> Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
>>>>>> ---
>>>>>>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
>>>>>>  1 file changed, 5 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>>>>> index 242aee4..02341bc 100644
>>>>>> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>>>>> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>>>>> @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
>>>>>>  		.pa_end		= 0x4a0ab003,
>>>>>>  		.flags		= ADDR_TYPE_RT
>>>>>>  	},
>>>>>> +	{
>>>>>> +		.pa_start	= 0x4a00233c,
>>>>>> +		.pa_end		= 0x4a00233f,
>>>>>> +		.flags		= ADDR_TYPE_RT
>>>>>> +	},
>>>>>
>>>>> I do not have any objection/comment here, but I believe this is control
>>>>> module address space required for USB module, right?
>>>>> I am not sure this is right way of accessing control module space.
>>>>> Actually Control Module Access required for drivers is one of the
>>>>> blocking issue we have currently.
>>>>>
>>>>> Also there was some effort put up by 'Konstantine' to convert Control
>>>>> module to MFD driver, I haven't seen any further update on it. But it
>>>>> would be good to check with him.
>>>>
>>>> this was an agreement with Benoit since we already lost a couple merge
>>>> windows for this patchset. We agreed to wait until -rc4 for SCM driver
>>>> and if it wasn't ready, we'd go ahead with this and SCM author would fix
>>>> it up on a patch converting users to new SCM driver.
>>>
>>> Tony, can I get your Acked-by to this patch so I can take it together
>>> with the rest of the series ? Thanks
>>>
>>> ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
>>> to merge it into your tree once I apply.
>>
>> It would be best if this got acked by Benoit and Paul as they may
>> have some other patches queued up. I'll ack if they ack ;)
> 
> Benoit, care to ack this patch ???

Gosh, that's hard to ack something like that :-)

But considering that the control module driver is not there yet, I have
no choice but accepting that one if we want to have the functionality
we've been waiting for years.

Could you just update the patch with a big disclaimer on top of the
address range to explain that this should not belong here and will be
removed ASAP, when the proper driver will be done.

Then you sign the patch with your blood and that should be fine for me :-).

Thanks,
Benoit

Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Benoit Cousson]

Hi Felipe,

On 09/10/2012 05:58 PM, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Sep 06, 2012 at 12:56:07PM -0700, Tony Lindgren wrote:
>> * Felipe Balbi <balbi@ti.com> [120906 10:23]:
>>> Hi,
>>>
>>> On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
>>>> Hi,
>>>>
>>>> On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
>>>>>
>>>>>
>>>>> On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
>>>>>> The mailbox register for usb otg in omap is present in control module.
>>>>>> On detection of any events VBUS or ID, this register should be written
>>>>>> to send the notification to musb core.
>>>>>>
>>>>>> Till we have a separate control module driver to write to control module,
>>>>>> omap2430 will handle the register writes to control module by itself. So
>>>>>> a new address space to represent this control module register is added
>>>>>> to usb_otg_hs.
>>>>>>
>>>>>> Cc: Benoit Cousson <b-cousson@ti.com>
>>>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>>>>> ---
>>>>>>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
>>>>>>  1 file changed, 5 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>>>>> index 242aee4..02341bc 100644
>>>>>> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>>>>> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>>>>> @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
>>>>>>  		.pa_end		= 0x4a0ab003,
>>>>>>  		.flags		= ADDR_TYPE_RT
>>>>>>  	},
>>>>>> +	{
>>>>>> +		.pa_start	= 0x4a00233c,
>>>>>> +		.pa_end		= 0x4a00233f,
>>>>>> +		.flags		= ADDR_TYPE_RT
>>>>>> +	},
>>>>>
>>>>> I do not have any objection/comment here, but I believe this is control
>>>>> module address space required for USB module, right?
>>>>> I am not sure this is right way of accessing control module space.
>>>>> Actually Control Module Access required for drivers is one of the
>>>>> blocking issue we have currently.
>>>>>
>>>>> Also there was some effort put up by 'Konstantine' to convert Control
>>>>> module to MFD driver, I haven't seen any further update on it. But it
>>>>> would be good to check with him.
>>>>
>>>> this was an agreement with Benoit since we already lost a couple merge
>>>> windows for this patchset. We agreed to wait until -rc4 for SCM driver
>>>> and if it wasn't ready, we'd go ahead with this and SCM author would fix
>>>> it up on a patch converting users to new SCM driver.
>>>
>>> Tony, can I get your Acked-by to this patch so I can take it together
>>> with the rest of the series ? Thanks
>>>
>>> ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
>>> to merge it into your tree once I apply.
>>
>> It would be best if this got acked by Benoit and Paul as they may
>> have some other patches queued up. I'll ack if they ack ;)
> 
> Benoit, care to ack this patch ???

Gosh, that's hard to ack something like that :-)

But considering that the control module driver is not there yet, I have
no choice but accepting that one if we want to have the functionality
we've been waiting for years.

Could you just update the patch with a big disclaimer on top of the
address range to explain that this should not belong here and will be
removed ASAP, when the proper driver will be done.

Then you sign the patch with your blood and that should be fine for me :-).

Thanks,
Benoit

[PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Benoit Cousson]

Hi Felipe,

On 09/10/2012 05:58 PM, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Sep 06, 2012 at 12:56:07PM -0700, Tony Lindgren wrote:
>> * Felipe Balbi <balbi@ti.com> [120906 10:23]:
>>> Hi,
>>>
>>> On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
>>>> Hi,
>>>>
>>>> On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
>>>>>
>>>>>
>>>>> On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
>>>>>> The mailbox register for usb otg in omap is present in control module.
>>>>>> On detection of any events VBUS or ID, this register should be written
>>>>>> to send the notification to musb core.
>>>>>>
>>>>>> Till we have a separate control module driver to write to control module,
>>>>>> omap2430 will handle the register writes to control module by itself. So
>>>>>> a new address space to represent this control module register is added
>>>>>> to usb_otg_hs.
>>>>>>
>>>>>> Cc: Benoit Cousson <b-cousson@ti.com>
>>>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>>>>> ---
>>>>>>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
>>>>>>  1 file changed, 5 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>>>>> index 242aee4..02341bc 100644
>>>>>> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>>>>> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>>>>> @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
>>>>>>  		.pa_end		= 0x4a0ab003,
>>>>>>  		.flags		= ADDR_TYPE_RT
>>>>>>  	},
>>>>>> +	{
>>>>>> +		.pa_start	= 0x4a00233c,
>>>>>> +		.pa_end		= 0x4a00233f,
>>>>>> +		.flags		= ADDR_TYPE_RT
>>>>>> +	},
>>>>>
>>>>> I do not have any objection/comment here, but I believe this is control
>>>>> module address space required for USB module, right?
>>>>> I am not sure this is right way of accessing control module space.
>>>>> Actually Control Module Access required for drivers is one of the
>>>>> blocking issue we have currently.
>>>>>
>>>>> Also there was some effort put up by 'Konstantine' to convert Control
>>>>> module to MFD driver, I haven't seen any further update on it. But it
>>>>> would be good to check with him.
>>>>
>>>> this was an agreement with Benoit since we already lost a couple merge
>>>> windows for this patchset. We agreed to wait until -rc4 for SCM driver
>>>> and if it wasn't ready, we'd go ahead with this and SCM author would fix
>>>> it up on a patch converting users to new SCM driver.
>>>
>>> Tony, can I get your Acked-by to this patch so I can take it together
>>> with the rest of the series ? Thanks
>>>
>>> ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
>>> to merge it into your tree once I apply.
>>
>> It would be best if this got acked by Benoit and Paul as they may
>> have some other patches queued up. I'll ack if they ack ;)
> 
> Benoit, care to ack this patch ???

Gosh, that's hard to ack something like that :-)

But considering that the control module driver is not there yet, I have
no choice but accepting that one if we want to have the functionality
we've been waiting for years.

Could you just update the patch with a big disclaimer on top of the
address range to explain that this should not belong here and will be
removed ASAP, when the proper driver will be done.

Then you sign the patch with your blood and that should be fine for me :-).

Thanks,
Benoit

Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Felipe Balbi]

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

Hi,

On Mon, Sep 10, 2012 at 06:17:03PM +0200, Benoit Cousson wrote:
> >>>>> On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> >>>>>> The mailbox register for usb otg in omap is present in control module.
> >>>>>> On detection of any events VBUS or ID, this register should be written
> >>>>>> to send the notification to musb core.
> >>>>>>
> >>>>>> Till we have a separate control module driver to write to control module,
> >>>>>> omap2430 will handle the register writes to control module by itself. So
> >>>>>> a new address space to represent this control module register is added
> >>>>>> to usb_otg_hs.
> >>>>>>
> >>>>>> Cc: Benoit Cousson <b-cousson@ti.com>
> >>>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> >>>>>> ---
> >>>>>>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
> >>>>>>  1 file changed, 5 insertions(+)
> >>>>>>
> >>>>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> >>>>>> index 242aee4..02341bc 100644
> >>>>>> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> >>>>>> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> >>>>>> @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
> >>>>>>  		.pa_end		= 0x4a0ab003,
> >>>>>>  		.flags		= ADDR_TYPE_RT
> >>>>>>  	},
> >>>>>> +	{
> >>>>>> +		.pa_start	= 0x4a00233c,
> >>>>>> +		.pa_end		= 0x4a00233f,
> >>>>>> +		.flags		= ADDR_TYPE_RT
> >>>>>> +	},
> >>>>>
> >>>>> I do not have any objection/comment here, but I believe this is control
> >>>>> module address space required for USB module, right?
> >>>>> I am not sure this is right way of accessing control module space.
> >>>>> Actually Control Module Access required for drivers is one of the
> >>>>> blocking issue we have currently.
> >>>>>
> >>>>> Also there was some effort put up by 'Konstantine' to convert Control
> >>>>> module to MFD driver, I haven't seen any further update on it. But it
> >>>>> would be good to check with him.
> >>>>
> >>>> this was an agreement with Benoit since we already lost a couple merge
> >>>> windows for this patchset. We agreed to wait until -rc4 for SCM driver
> >>>> and if it wasn't ready, we'd go ahead with this and SCM author would fix
> >>>> it up on a patch converting users to new SCM driver.
> >>>
> >>> Tony, can I get your Acked-by to this patch so I can take it together
> >>> with the rest of the series ? Thanks
> >>>
> >>> ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
> >>> to merge it into your tree once I apply.
> >>
> >> It would be best if this got acked by Benoit and Paul as they may
> >> have some other patches queued up. I'll ack if they ack ;)
> > 
> > Benoit, care to ack this patch ???
> 
> Gosh, that's hard to ack something like that :-)

btw, that's not different than what's already in tree, the only
difference is that now hwmod knows about it...

> But considering that the control module driver is not there yet, I have
> no choice but accepting that one if we want to have the functionality
> we've been waiting for years.
> 
> Could you just update the patch with a big disclaimer on top of the
> address range to explain that this should not belong here and will be
> removed ASAP, when the proper driver will be done.

sure, that's doable... Kishon, can you do this ASAP ? I want to send my
pull requests tomorrow at the latest.

> Then you sign the patch with your blood and that should be fine for me
> :-).

I'm running out of blood already, but maybe there's enough for this last
one... 8-#

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Felipe Balbi]

Hi,

On Mon, Sep 10, 2012 at 06:17:03PM +0200, Benoit Cousson wrote:
> >>>>> On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> >>>>>> The mailbox register for usb otg in omap is present in control module.
> >>>>>> On detection of any events VBUS or ID, this register should be written
> >>>>>> to send the notification to musb core.
> >>>>>>
> >>>>>> Till we have a separate control module driver to write to control module,
> >>>>>> omap2430 will handle the register writes to control module by itself. So
> >>>>>> a new address space to represent this control module register is added
> >>>>>> to usb_otg_hs.
> >>>>>>
> >>>>>> Cc: Benoit Cousson <b-cousson@ti.com>
> >>>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> >>>>>> ---
> >>>>>>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
> >>>>>>  1 file changed, 5 insertions(+)
> >>>>>>
> >>>>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> >>>>>> index 242aee4..02341bc 100644
> >>>>>> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> >>>>>> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> >>>>>> @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
> >>>>>>  		.pa_end		= 0x4a0ab003,
> >>>>>>  		.flags		= ADDR_TYPE_RT
> >>>>>>  	},
> >>>>>> +	{
> >>>>>> +		.pa_start	= 0x4a00233c,
> >>>>>> +		.pa_end		= 0x4a00233f,
> >>>>>> +		.flags		= ADDR_TYPE_RT
> >>>>>> +	},
> >>>>>
> >>>>> I do not have any objection/comment here, but I believe this is control
> >>>>> module address space required for USB module, right?
> >>>>> I am not sure this is right way of accessing control module space.
> >>>>> Actually Control Module Access required for drivers is one of the
> >>>>> blocking issue we have currently.
> >>>>>
> >>>>> Also there was some effort put up by 'Konstantine' to convert Control
> >>>>> module to MFD driver, I haven't seen any further update on it. But it
> >>>>> would be good to check with him.
> >>>>
> >>>> this was an agreement with Benoit since we already lost a couple merge
> >>>> windows for this patchset. We agreed to wait until -rc4 for SCM driver
> >>>> and if it wasn't ready, we'd go ahead with this and SCM author would fix
> >>>> it up on a patch converting users to new SCM driver.
> >>>
> >>> Tony, can I get your Acked-by to this patch so I can take it together
> >>> with the rest of the series ? Thanks
> >>>
> >>> ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
> >>> to merge it into your tree once I apply.
> >>
> >> It would be best if this got acked by Benoit and Paul as they may
> >> have some other patches queued up. I'll ack if they ack ;)
> > 
> > Benoit, care to ack this patch ???
> 
> Gosh, that's hard to ack something like that :-)

btw, that's not different than what's already in tree, the only
difference is that now hwmod knows about it...

> But considering that the control module driver is not there yet, I have
> no choice but accepting that one if we want to have the functionality
> we've been waiting for years.
> 
> Could you just update the patch with a big disclaimer on top of the
> address range to explain that this should not belong here and will be
> removed ASAP, when the proper driver will be done.

sure, that's doable... Kishon, can you do this ASAP ? I want to send my
pull requests tomorrow at the latest.

> Then you sign the patch with your blood and that should be fine for me
> :-).

I'm running out of blood already, but maybe there's enough for this last
one... 8-#

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120910/18b7f9cf/attachment.sig>

Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[ABRAHAM, KISHON VIJAY]

Hi,

On Mon, Sep 10, 2012 at 10:13 PM, Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> wrote:
> Hi,
>
> On Mon, Sep 10, 2012 at 06:17:03PM +0200, Benoit Cousson wrote:
>> >>>>> On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
>> >>>>>> The mailbox register for usb otg in omap is present in control module.
>> >>>>>> On detection of any events VBUS or ID, this register should be written
>> >>>>>> to send the notification to musb core.
>> >>>>>>
>> >>>>>> Till we have a separate control module driver to write to control module,
>> >>>>>> omap2430 will handle the register writes to control module by itself. So
>> >>>>>> a new address space to represent this control module register is added
>> >>>>>> to usb_otg_hs.
>> >>>>>>
>> >>>>>> Cc: Benoit Cousson <b-cousson-l0cyMroinI0@public.gmane.org>
>> >>>>>> Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
>> >>>>>> ---
>> >>>>>>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
>> >>>>>>  1 file changed, 5 insertions(+)
>> >>>>>>
>> >>>>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> >>>>>> index 242aee4..02341bc 100644
>> >>>>>> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> >>>>>> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> >>>>>> @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
>> >>>>>>                .pa_end         = 0x4a0ab003,
>> >>>>>>                .flags          = ADDR_TYPE_RT
>> >>>>>>        },
>> >>>>>> +      {
>> >>>>>> +              .pa_start       = 0x4a00233c,
>> >>>>>> +              .pa_end         = 0x4a00233f,
>> >>>>>> +              .flags          = ADDR_TYPE_RT
>> >>>>>> +      },
>> >>>>>
>> >>>>> I do not have any objection/comment here, but I believe this is control
>> >>>>> module address space required for USB module, right?
>> >>>>> I am not sure this is right way of accessing control module space.
>> >>>>> Actually Control Module Access required for drivers is one of the
>> >>>>> blocking issue we have currently.
>> >>>>>
>> >>>>> Also there was some effort put up by 'Konstantine' to convert Control
>> >>>>> module to MFD driver, I haven't seen any further update on it. But it
>> >>>>> would be good to check with him.
>> >>>>
>> >>>> this was an agreement with Benoit since we already lost a couple merge
>> >>>> windows for this patchset. We agreed to wait until -rc4 for SCM driver
>> >>>> and if it wasn't ready, we'd go ahead with this and SCM author would fix
>> >>>> it up on a patch converting users to new SCM driver.
>> >>>
>> >>> Tony, can I get your Acked-by to this patch so I can take it together
>> >>> with the rest of the series ? Thanks
>> >>>
>> >>> ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
>> >>> to merge it into your tree once I apply.
>> >>
>> >> It would be best if this got acked by Benoit and Paul as they may
>> >> have some other patches queued up. I'll ack if they ack ;)
>> >
>> > Benoit, care to ack this patch ???
>>
>> Gosh, that's hard to ack something like that :-)
>
> btw, that's not different than what's already in tree, the only
> difference is that now hwmod knows about it...
>
>> But considering that the control module driver is not there yet, I have
>> no choice but accepting that one if we want to have the functionality
>> we've been waiting for years.
>>
>> Could you just update the patch with a big disclaimer on top of the
>> address range to explain that this should not belong here and will be
>> removed ASAP, when the proper driver will be done.
>
> sure, that's doable... Kishon, can you do this ASAP ? I want to send my
> pull requests tomorrow at the latest.

Sure. Will send now.

Thanks
Kishon

Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[ABRAHAM, KISHON VIJAY]

Hi,

On Mon, Sep 10, 2012 at 10:13 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Mon, Sep 10, 2012 at 06:17:03PM +0200, Benoit Cousson wrote:
>> >>>>> On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
>> >>>>>> The mailbox register for usb otg in omap is present in control module.
>> >>>>>> On detection of any events VBUS or ID, this register should be written
>> >>>>>> to send the notification to musb core.
>> >>>>>>
>> >>>>>> Till we have a separate control module driver to write to control module,
>> >>>>>> omap2430 will handle the register writes to control module by itself. So
>> >>>>>> a new address space to represent this control module register is added
>> >>>>>> to usb_otg_hs.
>> >>>>>>
>> >>>>>> Cc: Benoit Cousson <b-cousson@ti.com>
>> >>>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> >>>>>> ---
>> >>>>>>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
>> >>>>>>  1 file changed, 5 insertions(+)
>> >>>>>>
>> >>>>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> >>>>>> index 242aee4..02341bc 100644
>> >>>>>> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> >>>>>> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> >>>>>> @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
>> >>>>>>                .pa_end         = 0x4a0ab003,
>> >>>>>>                .flags          = ADDR_TYPE_RT
>> >>>>>>        },
>> >>>>>> +      {
>> >>>>>> +              .pa_start       = 0x4a00233c,
>> >>>>>> +              .pa_end         = 0x4a00233f,
>> >>>>>> +              .flags          = ADDR_TYPE_RT
>> >>>>>> +      },
>> >>>>>
>> >>>>> I do not have any objection/comment here, but I believe this is control
>> >>>>> module address space required for USB module, right?
>> >>>>> I am not sure this is right way of accessing control module space.
>> >>>>> Actually Control Module Access required for drivers is one of the
>> >>>>> blocking issue we have currently.
>> >>>>>
>> >>>>> Also there was some effort put up by 'Konstantine' to convert Control
>> >>>>> module to MFD driver, I haven't seen any further update on it. But it
>> >>>>> would be good to check with him.
>> >>>>
>> >>>> this was an agreement with Benoit since we already lost a couple merge
>> >>>> windows for this patchset. We agreed to wait until -rc4 for SCM driver
>> >>>> and if it wasn't ready, we'd go ahead with this and SCM author would fix
>> >>>> it up on a patch converting users to new SCM driver.
>> >>>
>> >>> Tony, can I get your Acked-by to this patch so I can take it together
>> >>> with the rest of the series ? Thanks
>> >>>
>> >>> ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
>> >>> to merge it into your tree once I apply.
>> >>
>> >> It would be best if this got acked by Benoit and Paul as they may
>> >> have some other patches queued up. I'll ack if they ack ;)
>> >
>> > Benoit, care to ack this patch ???
>>
>> Gosh, that's hard to ack something like that :-)
>
> btw, that's not different than what's already in tree, the only
> difference is that now hwmod knows about it...
>
>> But considering that the control module driver is not there yet, I have
>> no choice but accepting that one if we want to have the functionality
>> we've been waiting for years.
>>
>> Could you just update the patch with a big disclaimer on top of the
>> address range to explain that this should not belong here and will be
>> removed ASAP, when the proper driver will be done.
>
> sure, that's doable... Kishon, can you do this ASAP ? I want to send my
> pull requests tomorrow at the latest.

Sure. Will send now.

Thanks
Kishon

[PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[ABRAHAM, KISHON VIJAY]

Hi,

On Mon, Sep 10, 2012 at 10:13 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Mon, Sep 10, 2012 at 06:17:03PM +0200, Benoit Cousson wrote:
>> >>>>> On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
>> >>>>>> The mailbox register for usb otg in omap is present in control module.
>> >>>>>> On detection of any events VBUS or ID, this register should be written
>> >>>>>> to send the notification to musb core.
>> >>>>>>
>> >>>>>> Till we have a separate control module driver to write to control module,
>> >>>>>> omap2430 will handle the register writes to control module by itself. So
>> >>>>>> a new address space to represent this control module register is added
>> >>>>>> to usb_otg_hs.
>> >>>>>>
>> >>>>>> Cc: Benoit Cousson <b-cousson@ti.com>
>> >>>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> >>>>>> ---
>> >>>>>>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
>> >>>>>>  1 file changed, 5 insertions(+)
>> >>>>>>
>> >>>>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> >>>>>> index 242aee4..02341bc 100644
>> >>>>>> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> >>>>>> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> >>>>>> @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
>> >>>>>>                .pa_end         = 0x4a0ab003,
>> >>>>>>                .flags          = ADDR_TYPE_RT
>> >>>>>>        },
>> >>>>>> +      {
>> >>>>>> +              .pa_start       = 0x4a00233c,
>> >>>>>> +              .pa_end         = 0x4a00233f,
>> >>>>>> +              .flags          = ADDR_TYPE_RT
>> >>>>>> +      },
>> >>>>>
>> >>>>> I do not have any objection/comment here, but I believe this is control
>> >>>>> module address space required for USB module, right?
>> >>>>> I am not sure this is right way of accessing control module space.
>> >>>>> Actually Control Module Access required for drivers is one of the
>> >>>>> blocking issue we have currently.
>> >>>>>
>> >>>>> Also there was some effort put up by 'Konstantine' to convert Control
>> >>>>> module to MFD driver, I haven't seen any further update on it. But it
>> >>>>> would be good to check with him.
>> >>>>
>> >>>> this was an agreement with Benoit since we already lost a couple merge
>> >>>> windows for this patchset. We agreed to wait until -rc4 for SCM driver
>> >>>> and if it wasn't ready, we'd go ahead with this and SCM author would fix
>> >>>> it up on a patch converting users to new SCM driver.
>> >>>
>> >>> Tony, can I get your Acked-by to this patch so I can take it together
>> >>> with the rest of the series ? Thanks
>> >>>
>> >>> ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
>> >>> to merge it into your tree once I apply.
>> >>
>> >> It would be best if this got acked by Benoit and Paul as they may
>> >> have some other patches queued up. I'll ack if they ack ;)
>> >
>> > Benoit, care to ack this patch ???
>>
>> Gosh, that's hard to ack something like that :-)
>
> btw, that's not different than what's already in tree, the only
> difference is that now hwmod knows about it...
>
>> But considering that the control module driver is not there yet, I have
>> no choice but accepting that one if we want to have the functionality
>> we've been waiting for years.
>>
>> Could you just update the patch with a big disclaimer on top of the
>> address range to explain that this should not belong here and will be
>> removed ASAP, when the proper driver will be done.
>
> sure, that's doable... Kishon, can you do this ASAP ? I want to send my
> pull requests tomorrow at the latest.

Sure. Will send now.

Thanks
Kishon

RE: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Hiremath, Vaibhav]

On Thu, Sep 06, 2012 at 22:43:03, Balbi, Felipe wrote:
> Hi,
> 
> On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
> > 
> > 
> > On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> > > The mailbox register for usb otg in omap is present in control module.
> > > On detection of any events VBUS or ID, this register should be written
> > > to send the notification to musb core.
> > > 
> > > Till we have a separate control module driver to write to control module,
> > > omap2430 will handle the register writes to control module by itself. So
> > > a new address space to represent this control module register is added
> > > to usb_otg_hs.
> > > 
> > > Cc: Benoit Cousson <b-cousson-l0cyMroinI0@public.gmane.org>
> > > Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
> > > ---
> > >  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
> > >  1 file changed, 5 insertions(+)
> > > 
> > > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > index 242aee4..02341bc 100644
> > > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
> > >  		.pa_end		= 0x4a0ab003,
> > >  		.flags		= ADDR_TYPE_RT
> > >  	},
> > > +	{
> > > +		.pa_start	= 0x4a00233c,
> > > +		.pa_end		= 0x4a00233f,
> > > +		.flags		= ADDR_TYPE_RT
> > > +	},
> > 
> > I do not have any objection/comment here, but I believe this is control
> > module address space required for USB module, right?
> > I am not sure this is right way of accessing control module space.
> > Actually Control Module Access required for drivers is one of the
> > blocking issue we have currently.
> > 
> > Also there was some effort put up by 'Konstantine' to convert Control
> > module to MFD driver, I haven't seen any further update on it. But it
> > would be good to check with him.
> 
> this was an agreement with Benoit since we already lost a couple merge
> windows for this patchset. We agreed to wait until -rc4 for SCM driver
> and if it wasn't ready, we'd go ahead with this and SCM author would fix
> it up on a patch converting users to new SCM driver.
> 

Understood and thanks for confirming.

Thanks,
Vaibhav

> -- 
> balbi
> 

RE: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Hiremath, Vaibhav]

On Thu, Sep 06, 2012 at 22:43:03, Balbi, Felipe wrote:
> Hi,
> 
> On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
> > 
> > 
> > On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> > > The mailbox register for usb otg in omap is present in control module.
> > > On detection of any events VBUS or ID, this register should be written
> > > to send the notification to musb core.
> > > 
> > > Till we have a separate control module driver to write to control module,
> > > omap2430 will handle the register writes to control module by itself. So
> > > a new address space to represent this control module register is added
> > > to usb_otg_hs.
> > > 
> > > Cc: Benoit Cousson <b-cousson@ti.com>
> > > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > > ---
> > >  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
> > >  1 file changed, 5 insertions(+)
> > > 
> > > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > index 242aee4..02341bc 100644
> > > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
> > >  		.pa_end		= 0x4a0ab003,
> > >  		.flags		= ADDR_TYPE_RT
> > >  	},
> > > +	{
> > > +		.pa_start	= 0x4a00233c,
> > > +		.pa_end		= 0x4a00233f,
> > > +		.flags		= ADDR_TYPE_RT
> > > +	},
> > 
> > I do not have any objection/comment here, but I believe this is control
> > module address space required for USB module, right?
> > I am not sure this is right way of accessing control module space.
> > Actually Control Module Access required for drivers is one of the
> > blocking issue we have currently.
> > 
> > Also there was some effort put up by 'Konstantine' to convert Control
> > module to MFD driver, I haven't seen any further update on it. But it
> > would be good to check with him.
> 
> this was an agreement with Benoit since we already lost a couple merge
> windows for this patchset. We agreed to wait until -rc4 for SCM driver
> and if it wasn't ready, we'd go ahead with this and SCM author would fix
> it up on a patch converting users to new SCM driver.
> 

Understood and thanks for confirming.

Thanks,
Vaibhav

> -- 
> balbi
> 

[PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Hiremath, Vaibhav]

On Thu, Sep 06, 2012 at 22:43:03, Balbi, Felipe wrote:
> Hi,
> 
> On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
> > 
> > 
> > On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
> > > The mailbox register for usb otg in omap is present in control module.
> > > On detection of any events VBUS or ID, this register should be written
> > > to send the notification to musb core.
> > > 
> > > Till we have a separate control module driver to write to control module,
> > > omap2430 will handle the register writes to control module by itself. So
> > > a new address space to represent this control module register is added
> > > to usb_otg_hs.
> > > 
> > > Cc: Benoit Cousson <b-cousson@ti.com>
> > > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > > ---
> > >  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    5 +++++
> > >  1 file changed, 5 insertions(+)
> > > 
> > > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > index 242aee4..02341bc 100644
> > > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > > @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
> > >  		.pa_end		= 0x4a0ab003,
> > >  		.flags		= ADDR_TYPE_RT
> > >  	},
> > > +	{
> > > +		.pa_start	= 0x4a00233c,
> > > +		.pa_end		= 0x4a00233f,
> > > +		.flags		= ADDR_TYPE_RT
> > > +	},
> > 
> > I do not have any objection/comment here, but I believe this is control
> > module address space required for USB module, right?
> > I am not sure this is right way of accessing control module space.
> > Actually Control Module Access required for drivers is one of the
> > blocking issue we have currently.
> > 
> > Also there was some effort put up by 'Konstantine' to convert Control
> > module to MFD driver, I haven't seen any further update on it. But it
> > would be good to check with him.
> 
> this was an agreement with Benoit since we already lost a couple merge
> windows for this patchset. We agreed to wait until -rc4 for SCM driver
> and if it wasn't ready, we'd go ahead with this and SCM author would fix
> it up on a patch converting users to new SCM driver.
> 

Understood and thanks for confirming.

Thanks,
Vaibhav

> -- 
> balbi
> 

[PATCH 2/3] usb: musb: omap: write directly to mailbox instead of using phy

[Kishon Vijay Abraham I]

The glue layer should directly write to mailbox register (present in
control module) instead of calling phy layer to write to mailbox
register. Writing to mailbox register notifies the core of events like
device connect/disconnect.

Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.

Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
---
 drivers/usb/musb/omap2430.c |   52 +++++++++++++++++++++++++++++++++++++------
 drivers/usb/musb/omap2430.h |    9 ++++++++
 2 files changed, 54 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 02c39a7..f4d9503 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -45,6 +45,7 @@ struct omap2430_glue {
 	struct platform_device	*musb;
 	enum omap_musb_vbus_id_status status;
 	struct work_struct	omap_musb_mailbox_work;
+	u32 __iomem		*control_otghs;
 };
 #define glue_to_musb(g)		platform_get_drvdata(g->musb)
 
@@ -52,6 +53,26 @@ struct omap2430_glue		*_glue;
 
 static struct timer_list musb_idle_timer;
 
+/**
+ * omap4_usb_phy_mailbox - write to usb otg mailbox
+ * @glue: struct omap2430_glue *
+ * @val: the value to be written to the mailbox
+ *
+ * On detection of a device (ID pin is grounded), this API should be called
+ * to set AVALID, VBUSVALID and ID pin is grounded.
+ *
+ * When OMAP is connected to a host (OMAP in device mode), this API
+ * is called to set AVALID, VBUSVALID and ID pin in high impedance.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
+ * control module
+ */
+static void omap4_usb_phy_mailbox(struct omap2430_glue *glue, u32 val)
+{
+	if (glue->control_otghs)
+		writel(val, glue->control_otghs);
+}
+
 static void musb_do_idle(unsigned long _musb)
 {
 	struct musb	*musb = (void *)_musb;
@@ -247,6 +268,7 @@ EXPORT_SYMBOL_GPL(omap_musb_mailbox);
 
 static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 {
+	u32 val;
 	struct musb *musb = glue_to_musb(glue);
 	struct device *dev = musb->controller;
 	struct musb_hdrc_platform_data *pdata = dev->platform_data;
@@ -262,7 +284,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 		musb->xceiv->last_event = USB_EVENT_ID;
 		if (musb->gadget_driver) {
 			pm_runtime_get_sync(dev);
-			usb_phy_init(musb->xceiv);
+			val = AVALID | VBUSVALID;
+			omap4_usb_phy_mailbox(glue, val);
 			omap2430_musb_set_vbus(musb, 1);
 		}
 		break;
@@ -275,7 +298,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 		musb->xceiv->last_event = USB_EVENT_VBUS;
 		if (musb->gadget_driver)
 			pm_runtime_get_sync(dev);
-		usb_phy_init(musb->xceiv);
+		val = IDDIG | AVALID | VBUSVALID;
+		omap4_usb_phy_mailbox(glue, val);
 		break;
 
 	case OMAP_MUSB_ID_FLOAT:
@@ -292,7 +316,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 			if (musb->xceiv->otg->set_vbus)
 				otg_set_vbus(musb->xceiv->otg, 0);
 		}
-		usb_phy_shutdown(musb->xceiv);
+		val = SESSEND | IDDIG;
+		omap4_usb_phy_mailbox(glue, val);
 		break;
 	default:
 		dev_dbg(dev, "ID float\n");
@@ -367,6 +392,7 @@ err1:
 static void omap2430_musb_enable(struct musb *musb)
 {
 	u8		devctl;
+	u32		val;
 	unsigned long timeout = jiffies + msecs_to_jiffies(1000);
 	struct device *dev = musb->controller;
 	struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
@@ -376,7 +402,8 @@ static void omap2430_musb_enable(struct musb *musb)
 	switch (glue->status) {
 
 	case OMAP_MUSB_ID_GROUND:
-		usb_phy_init(musb->xceiv);
+		val = AVALID | VBUSVALID;
+		omap4_usb_phy_mailbox(glue, val);
 		if (data->interface_type != MUSB_INTERFACE_UTMI)
 			break;
 		devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
@@ -395,7 +422,8 @@ static void omap2430_musb_enable(struct musb *musb)
 		break;
 
 	case OMAP_MUSB_VBUS_VALID:
-		usb_phy_init(musb->xceiv);
+		val = IDDIG | AVALID | VBUSVALID;
+		omap4_usb_phy_mailbox(glue, val);
 		break;
 
 	default:
@@ -405,11 +433,14 @@ static void omap2430_musb_enable(struct musb *musb)
 
 static void omap2430_musb_disable(struct musb *musb)
 {
+	u32 val;
 	struct device *dev = musb->controller;
 	struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
 
-	if (glue->status != OMAP_MUSB_UNKNOWN)
-		usb_phy_shutdown(musb->xceiv);
+	if (glue->status != OMAP_MUSB_UNKNOWN) {
+		val = SESSEND | IDDIG;
+		omap4_usb_phy_mailbox(glue, val);
+	}
 }
 
 static int omap2430_musb_exit(struct musb *musb)
@@ -441,6 +472,7 @@ static int __devinit omap2430_probe(struct platform_device *pdev)
 	struct musb_hdrc_platform_data	*pdata = pdev->dev.platform_data;
 	struct platform_device		*musb;
 	struct omap2430_glue		*glue;
+	struct resource			*res;
 	int				ret = -ENOMEM;
 
 	glue = devm_kzalloc(&pdev->dev, sizeof(*glue), GFP_KERNEL);
@@ -463,6 +495,12 @@ static int __devinit omap2430_probe(struct platform_device *pdev)
 	glue->musb			= musb;
 	glue->status			= OMAP_MUSB_UNKNOWN;
 
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+
+	glue->control_otghs = devm_request_and_ioremap(&pdev->dev, res);
+	if (glue->control_otghs == NULL)
+		dev_dbg(&pdev->dev, "Failed to obtain control memory\n");
+
 	pdata->platform_ops		= &omap2430_ops;
 
 	platform_set_drvdata(pdev, glue);
diff --git a/drivers/usb/musb/omap2430.h b/drivers/usb/musb/omap2430.h
index 40b3c02..b85f397 100644
--- a/drivers/usb/musb/omap2430.h
+++ b/drivers/usb/musb/omap2430.h
@@ -49,4 +49,13 @@
 #define OTG_FORCESTDBY		0x414
 #	define	ENABLEFORCE		(1 << 0)
 
+/*
+ * Control Module bit definitions
+ * XXX: Will be removed once we have a driver for control module.
+ */
+#define	AVALID				BIT(0)
+#define	BVALID				BIT(1)
+#define	VBUSVALID			BIT(2)
+#define	SESSEND				BIT(3)
+#define	IDDIG				BIT(4)
 #endif	/* __MUSB_OMAP243X_H__ */
-- 
1.7.9.5

[PATCH 2/3] usb: musb: omap: write directly to mailbox instead of using phy

[Kishon Vijay Abraham I]

The glue layer should directly write to mailbox register (present in
control module) instead of calling phy layer to write to mailbox
register. Writing to mailbox register notifies the core of events like
device connect/disconnect.

Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
 drivers/usb/musb/omap2430.c |   52 +++++++++++++++++++++++++++++++++++++------
 drivers/usb/musb/omap2430.h |    9 ++++++++
 2 files changed, 54 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 02c39a7..f4d9503 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -45,6 +45,7 @@ struct omap2430_glue {
 	struct platform_device	*musb;
 	enum omap_musb_vbus_id_status status;
 	struct work_struct	omap_musb_mailbox_work;
+	u32 __iomem		*control_otghs;
 };
 #define glue_to_musb(g)		platform_get_drvdata(g->musb)
 
@@ -52,6 +53,26 @@ struct omap2430_glue		*_glue;
 
 static struct timer_list musb_idle_timer;
 
+/**
+ * omap4_usb_phy_mailbox - write to usb otg mailbox
+ * @glue: struct omap2430_glue *
+ * @val: the value to be written to the mailbox
+ *
+ * On detection of a device (ID pin is grounded), this API should be called
+ * to set AVALID, VBUSVALID and ID pin is grounded.
+ *
+ * When OMAP is connected to a host (OMAP in device mode), this API
+ * is called to set AVALID, VBUSVALID and ID pin in high impedance.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
+ * control module
+ */
+static void omap4_usb_phy_mailbox(struct omap2430_glue *glue, u32 val)
+{
+	if (glue->control_otghs)
+		writel(val, glue->control_otghs);
+}
+
 static void musb_do_idle(unsigned long _musb)
 {
 	struct musb	*musb = (void *)_musb;
@@ -247,6 +268,7 @@ EXPORT_SYMBOL_GPL(omap_musb_mailbox);
 
 static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 {
+	u32 val;
 	struct musb *musb = glue_to_musb(glue);
 	struct device *dev = musb->controller;
 	struct musb_hdrc_platform_data *pdata = dev->platform_data;
@@ -262,7 +284,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 		musb->xceiv->last_event = USB_EVENT_ID;
 		if (musb->gadget_driver) {
 			pm_runtime_get_sync(dev);
-			usb_phy_init(musb->xceiv);
+			val = AVALID | VBUSVALID;
+			omap4_usb_phy_mailbox(glue, val);
 			omap2430_musb_set_vbus(musb, 1);
 		}
 		break;
@@ -275,7 +298,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 		musb->xceiv->last_event = USB_EVENT_VBUS;
 		if (musb->gadget_driver)
 			pm_runtime_get_sync(dev);
-		usb_phy_init(musb->xceiv);
+		val = IDDIG | AVALID | VBUSVALID;
+		omap4_usb_phy_mailbox(glue, val);
 		break;
 
 	case OMAP_MUSB_ID_FLOAT:
@@ -292,7 +316,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 			if (musb->xceiv->otg->set_vbus)
 				otg_set_vbus(musb->xceiv->otg, 0);
 		}
-		usb_phy_shutdown(musb->xceiv);
+		val = SESSEND | IDDIG;
+		omap4_usb_phy_mailbox(glue, val);
 		break;
 	default:
 		dev_dbg(dev, "ID float\n");
@@ -367,6 +392,7 @@ err1:
 static void omap2430_musb_enable(struct musb *musb)
 {
 	u8		devctl;
+	u32		val;
 	unsigned long timeout = jiffies + msecs_to_jiffies(1000);
 	struct device *dev = musb->controller;
 	struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
@@ -376,7 +402,8 @@ static void omap2430_musb_enable(struct musb *musb)
 	switch (glue->status) {
 
 	case OMAP_MUSB_ID_GROUND:
-		usb_phy_init(musb->xceiv);
+		val = AVALID | VBUSVALID;
+		omap4_usb_phy_mailbox(glue, val);
 		if (data->interface_type != MUSB_INTERFACE_UTMI)
 			break;
 		devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
@@ -395,7 +422,8 @@ static void omap2430_musb_enable(struct musb *musb)
 		break;
 
 	case OMAP_MUSB_VBUS_VALID:
-		usb_phy_init(musb->xceiv);
+		val = IDDIG | AVALID | VBUSVALID;
+		omap4_usb_phy_mailbox(glue, val);
 		break;
 
 	default:
@@ -405,11 +433,14 @@ static void omap2430_musb_enable(struct musb *musb)
 
 static void omap2430_musb_disable(struct musb *musb)
 {
+	u32 val;
 	struct device *dev = musb->controller;
 	struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
 
-	if (glue->status != OMAP_MUSB_UNKNOWN)
-		usb_phy_shutdown(musb->xceiv);
+	if (glue->status != OMAP_MUSB_UNKNOWN) {
+		val = SESSEND | IDDIG;
+		omap4_usb_phy_mailbox(glue, val);
+	}
 }
 
 static int omap2430_musb_exit(struct musb *musb)
@@ -441,6 +472,7 @@ static int __devinit omap2430_probe(struct platform_device *pdev)
 	struct musb_hdrc_platform_data	*pdata = pdev->dev.platform_data;
 	struct platform_device		*musb;
 	struct omap2430_glue		*glue;
+	struct resource			*res;
 	int				ret = -ENOMEM;
 
 	glue = devm_kzalloc(&pdev->dev, sizeof(*glue), GFP_KERNEL);
@@ -463,6 +495,12 @@ static int __devinit omap2430_probe(struct platform_device *pdev)
 	glue->musb			= musb;
 	glue->status			= OMAP_MUSB_UNKNOWN;
 
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+
+	glue->control_otghs = devm_request_and_ioremap(&pdev->dev, res);
+	if (glue->control_otghs == NULL)
+		dev_dbg(&pdev->dev, "Failed to obtain control memory\n");
+
 	pdata->platform_ops		= &omap2430_ops;
 
 	platform_set_drvdata(pdev, glue);
diff --git a/drivers/usb/musb/omap2430.h b/drivers/usb/musb/omap2430.h
index 40b3c02..b85f397 100644
--- a/drivers/usb/musb/omap2430.h
+++ b/drivers/usb/musb/omap2430.h
@@ -49,4 +49,13 @@
 #define OTG_FORCESTDBY		0x414
 #	define	ENABLEFORCE		(1 << 0)
 
+/*
+ * Control Module bit definitions
+ * XXX: Will be removed once we have a driver for control module.
+ */
+#define	AVALID				BIT(0)
+#define	BVALID				BIT(1)
+#define	VBUSVALID			BIT(2)
+#define	SESSEND				BIT(3)
+#define	IDDIG				BIT(4)
 #endif	/* __MUSB_OMAP243X_H__ */
-- 
1.7.9.5

[PATCH 2/3] usb: musb: omap: write directly to mailbox instead of using phy

[Kishon Vijay Abraham I]

The glue layer should directly write to mailbox register (present in
control module) instead of calling phy layer to write to mailbox
register. Writing to mailbox register notifies the core of events like
device connect/disconnect.

Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
 drivers/usb/musb/omap2430.c |   52 +++++++++++++++++++++++++++++++++++++------
 drivers/usb/musb/omap2430.h |    9 ++++++++
 2 files changed, 54 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 02c39a7..f4d9503 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -45,6 +45,7 @@ struct omap2430_glue {
 	struct platform_device	*musb;
 	enum omap_musb_vbus_id_status status;
 	struct work_struct	omap_musb_mailbox_work;
+	u32 __iomem		*control_otghs;
 };
 #define glue_to_musb(g)		platform_get_drvdata(g->musb)
 
@@ -52,6 +53,26 @@ struct omap2430_glue		*_glue;
 
 static struct timer_list musb_idle_timer;
 
+/**
+ * omap4_usb_phy_mailbox - write to usb otg mailbox
+ * @glue: struct omap2430_glue *
+ * @val: the value to be written to the mailbox
+ *
+ * On detection of a device (ID pin is grounded), this API should be called
+ * to set AVALID, VBUSVALID and ID pin is grounded.
+ *
+ * When OMAP is connected to a host (OMAP in device mode), this API
+ * is called to set AVALID, VBUSVALID and ID pin in high impedance.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
+ * control module
+ */
+static void omap4_usb_phy_mailbox(struct omap2430_glue *glue, u32 val)
+{
+	if (glue->control_otghs)
+		writel(val, glue->control_otghs);
+}
+
 static void musb_do_idle(unsigned long _musb)
 {
 	struct musb	*musb = (void *)_musb;
@@ -247,6 +268,7 @@ EXPORT_SYMBOL_GPL(omap_musb_mailbox);
 
 static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 {
+	u32 val;
 	struct musb *musb = glue_to_musb(glue);
 	struct device *dev = musb->controller;
 	struct musb_hdrc_platform_data *pdata = dev->platform_data;
@@ -262,7 +284,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 		musb->xceiv->last_event = USB_EVENT_ID;
 		if (musb->gadget_driver) {
 			pm_runtime_get_sync(dev);
-			usb_phy_init(musb->xceiv);
+			val = AVALID | VBUSVALID;
+			omap4_usb_phy_mailbox(glue, val);
 			omap2430_musb_set_vbus(musb, 1);
 		}
 		break;
@@ -275,7 +298,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 		musb->xceiv->last_event = USB_EVENT_VBUS;
 		if (musb->gadget_driver)
 			pm_runtime_get_sync(dev);
-		usb_phy_init(musb->xceiv);
+		val = IDDIG | AVALID | VBUSVALID;
+		omap4_usb_phy_mailbox(glue, val);
 		break;
 
 	case OMAP_MUSB_ID_FLOAT:
@@ -292,7 +316,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 			if (musb->xceiv->otg->set_vbus)
 				otg_set_vbus(musb->xceiv->otg, 0);
 		}
-		usb_phy_shutdown(musb->xceiv);
+		val = SESSEND | IDDIG;
+		omap4_usb_phy_mailbox(glue, val);
 		break;
 	default:
 		dev_dbg(dev, "ID float\n");
@@ -367,6 +392,7 @@ err1:
 static void omap2430_musb_enable(struct musb *musb)
 {
 	u8		devctl;
+	u32		val;
 	unsigned long timeout = jiffies + msecs_to_jiffies(1000);
 	struct device *dev = musb->controller;
 	struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
@@ -376,7 +402,8 @@ static void omap2430_musb_enable(struct musb *musb)
 	switch (glue->status) {
 
 	case OMAP_MUSB_ID_GROUND:
-		usb_phy_init(musb->xceiv);
+		val = AVALID | VBUSVALID;
+		omap4_usb_phy_mailbox(glue, val);
 		if (data->interface_type != MUSB_INTERFACE_UTMI)
 			break;
 		devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
@@ -395,7 +422,8 @@ static void omap2430_musb_enable(struct musb *musb)
 		break;
 
 	case OMAP_MUSB_VBUS_VALID:
-		usb_phy_init(musb->xceiv);
+		val = IDDIG | AVALID | VBUSVALID;
+		omap4_usb_phy_mailbox(glue, val);
 		break;
 
 	default:
@@ -405,11 +433,14 @@ static void omap2430_musb_enable(struct musb *musb)
 
 static void omap2430_musb_disable(struct musb *musb)
 {
+	u32 val;
 	struct device *dev = musb->controller;
 	struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
 
-	if (glue->status != OMAP_MUSB_UNKNOWN)
-		usb_phy_shutdown(musb->xceiv);
+	if (glue->status != OMAP_MUSB_UNKNOWN) {
+		val = SESSEND | IDDIG;
+		omap4_usb_phy_mailbox(glue, val);
+	}
 }
 
 static int omap2430_musb_exit(struct musb *musb)
@@ -441,6 +472,7 @@ static int __devinit omap2430_probe(struct platform_device *pdev)
 	struct musb_hdrc_platform_data	*pdata = pdev->dev.platform_data;
 	struct platform_device		*musb;
 	struct omap2430_glue		*glue;
+	struct resource			*res;
 	int				ret = -ENOMEM;
 
 	glue = devm_kzalloc(&pdev->dev, sizeof(*glue), GFP_KERNEL);
@@ -463,6 +495,12 @@ static int __devinit omap2430_probe(struct platform_device *pdev)
 	glue->musb			= musb;
 	glue->status			= OMAP_MUSB_UNKNOWN;
 
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+
+	glue->control_otghs = devm_request_and_ioremap(&pdev->dev, res);
+	if (glue->control_otghs == NULL)
+		dev_dbg(&pdev->dev, "Failed to obtain control memory\n");
+
 	pdata->platform_ops		= &omap2430_ops;
 
 	platform_set_drvdata(pdev, glue);
diff --git a/drivers/usb/musb/omap2430.h b/drivers/usb/musb/omap2430.h
index 40b3c02..b85f397 100644
--- a/drivers/usb/musb/omap2430.h
+++ b/drivers/usb/musb/omap2430.h
@@ -49,4 +49,13 @@
 #define OTG_FORCESTDBY		0x414
 #	define	ENABLEFORCE		(1 << 0)
 
+/*
+ * Control Module bit definitions
+ * XXX: Will be removed once we have a driver for control module.
+ */
+#define	AVALID				BIT(0)
+#define	BVALID				BIT(1)
+#define	VBUSVALID			BIT(2)
+#define	SESSEND				BIT(3)
+#define	IDDIG				BIT(4)
 #endif	/* __MUSB_OMAP243X_H__ */
-- 
1.7.9.5

[PATCH 3/3] usb: musb: omap: Add device tree support for omap musb glue

[Kishon Vijay Abraham I]

Added device tree support for omap musb driver and updated the
Documentation with device tree binding information.

Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |   33 ++++++++++++
 drivers/usb/musb/omap2430.c                        |   54 ++++++++++++++++++++
 2 files changed, 87 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 0000000..544fa97
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,33 @@
+OMAP GLUE
+
+OMAP MUSB GLUE
+ - compatible : Should be "ti,musb-omap2430"
+ - ti,hwmods : must be "usb_otg_hs"
+ - multipoint : Should be "1" indicating the musb controller supports
+   multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+   MUSB configuration-specific setting. Should be set to "16"
+ - ram_bits : Specifies the ram address size. Should be set to "12"
+ - interface_type : This is a board specific setting to describe the type of
+   interface between the controller and the phy. It should be "0" or "1"
+   specifying ULPI and UTMI respectively.
+ - mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
+   represents PERIPHERAL.
+ - power : Should be "50". This signifies the controller can supply upto
+   100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+	compatible = "ti,musb-omap2430";
+	ti,hwmods = "usb_otg_hs";
+	multipoint = <1>;
+	num_eps = <16>;
+	ram_bits = <12>;
+};
+
+Board specific device node entry
+&usb_otg_hs {
+	interface_type = <1>;
+	mode = <3>;
+	power = <50>;
+};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f4d9503..d96873b 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -30,6 +30,7 @@
 #include <linux/init.h>
 #include <linux/list.h>
 #include <linux/io.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/dma-mapping.h>
 #include <linux/pm_runtime.h>
@@ -470,8 +471,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
 static int __devinit omap2430_probe(struct platform_device *pdev)
 {
 	struct musb_hdrc_platform_data	*pdata = pdev->dev.platform_data;
+	struct omap_musb_board_data	*data;
 	struct platform_device		*musb;
 	struct omap2430_glue		*glue;
+	struct device_node		*np = pdev->dev.of_node;
+	struct musb_hdrc_config		*config;
 	struct resource			*res;
 	int				ret = -ENOMEM;
 
@@ -501,6 +505,42 @@ static int __devinit omap2430_probe(struct platform_device *pdev)
 	if (glue->control_otghs == NULL)
 		dev_dbg(&pdev->dev, "Failed to obtain control memory\n");
 
+	if (np) {
+		pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+		if (!pdata) {
+			dev_err(&pdev->dev,
+				"failed to allocate musb platfrom data\n");
+			ret = -ENOMEM;
+			goto err1;
+		}
+
+		data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+		if (!data) {
+			dev_err(&pdev->dev,
+					"failed to allocate musb board data\n");
+			ret = -ENOMEM;
+			goto err1;
+		}
+
+		config = devm_kzalloc(&pdev->dev, sizeof(*config), GFP_KERNEL);
+		if (!data) {
+			dev_err(&pdev->dev,
+				"failed to allocate musb hdrc config\n");
+			goto err1;
+		}
+
+		of_property_read_u32(np, "mode", (u32 *)&pdata->mode);
+		of_property_read_u32(np, "interface_type",
+						(u32 *)&data->interface_type);
+		of_property_read_u32(np, "num_eps", (u32 *)&config->num_eps);
+		of_property_read_u32(np, "ram_bits", (u32 *)&config->ram_bits);
+		of_property_read_u32(np, "power", (u32 *)&pdata->power);
+		config->multipoint = of_property_read_bool(np, "multipoint");
+
+		pdata->board_data	= data;
+		pdata->config		= config;
+	}
+
 	pdata->platform_ops		= &omap2430_ops;
 
 	platform_set_drvdata(pdev, glue);
@@ -597,12 +637,26 @@ static struct dev_pm_ops omap2430_pm_ops = {
 #define DEV_PM_OPS	NULL
 #endif
 
+#ifdef CONFIG_OF
+static const struct of_device_id omap2430_id_table[] = {
+	{
+		.compatible = "ti,omap4-musb"
+	},
+	{
+		.compatible = "ti,omap3-musb"
+	},
+	{},
+};
+MODULE_DEVICE_TABLE(of, omap2430_id_table);
+#endif
+
 static struct platform_driver omap2430_driver = {
 	.probe		= omap2430_probe,
 	.remove		= __devexit_p(omap2430_remove),
 	.driver		= {
 		.name	= "musb-omap2430",
 		.pm	= DEV_PM_OPS,
+		.of_match_table = of_match_ptr(omap2430_id_table),
 	},
 };
 
-- 
1.7.9.5

[PATCH 3/3] usb: musb: omap: Add device tree support for omap musb glue

[Kishon Vijay Abraham I]

Added device tree support for omap musb driver and updated the
Documentation with device tree binding information.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |   33 ++++++++++++
 drivers/usb/musb/omap2430.c                        |   54 ++++++++++++++++++++
 2 files changed, 87 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 0000000..544fa97
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,33 @@
+OMAP GLUE
+
+OMAP MUSB GLUE
+ - compatible : Should be "ti,musb-omap2430"
+ - ti,hwmods : must be "usb_otg_hs"
+ - multipoint : Should be "1" indicating the musb controller supports
+   multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+   MUSB configuration-specific setting. Should be set to "16"
+ - ram_bits : Specifies the ram address size. Should be set to "12"
+ - interface_type : This is a board specific setting to describe the type of
+   interface between the controller and the phy. It should be "0" or "1"
+   specifying ULPI and UTMI respectively.
+ - mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
+   represents PERIPHERAL.
+ - power : Should be "50". This signifies the controller can supply upto
+   100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+	compatible = "ti,musb-omap2430";
+	ti,hwmods = "usb_otg_hs";
+	multipoint = <1>;
+	num_eps = <16>;
+	ram_bits = <12>;
+};
+
+Board specific device node entry
+&usb_otg_hs {
+	interface_type = <1>;
+	mode = <3>;
+	power = <50>;
+};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f4d9503..d96873b 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -30,6 +30,7 @@
 #include <linux/init.h>
 #include <linux/list.h>
 #include <linux/io.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/dma-mapping.h>
 #include <linux/pm_runtime.h>
@@ -470,8 +471,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
 static int __devinit omap2430_probe(struct platform_device *pdev)
 {
 	struct musb_hdrc_platform_data	*pdata = pdev->dev.platform_data;
+	struct omap_musb_board_data	*data;
 	struct platform_device		*musb;
 	struct omap2430_glue		*glue;
+	struct device_node		*np = pdev->dev.of_node;
+	struct musb_hdrc_config		*config;
 	struct resource			*res;
 	int				ret = -ENOMEM;
 
@@ -501,6 +505,42 @@ static int __devinit omap2430_probe(struct platform_device *pdev)
 	if (glue->control_otghs == NULL)
 		dev_dbg(&pdev->dev, "Failed to obtain control memory\n");
 
+	if (np) {
+		pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+		if (!pdata) {
+			dev_err(&pdev->dev,
+				"failed to allocate musb platfrom data\n");
+			ret = -ENOMEM;
+			goto err1;
+		}
+
+		data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+		if (!data) {
+			dev_err(&pdev->dev,
+					"failed to allocate musb board data\n");
+			ret = -ENOMEM;
+			goto err1;
+		}
+
+		config = devm_kzalloc(&pdev->dev, sizeof(*config), GFP_KERNEL);
+		if (!data) {
+			dev_err(&pdev->dev,
+				"failed to allocate musb hdrc config\n");
+			goto err1;
+		}
+
+		of_property_read_u32(np, "mode", (u32 *)&pdata->mode);
+		of_property_read_u32(np, "interface_type",
+						(u32 *)&data->interface_type);
+		of_property_read_u32(np, "num_eps", (u32 *)&config->num_eps);
+		of_property_read_u32(np, "ram_bits", (u32 *)&config->ram_bits);
+		of_property_read_u32(np, "power", (u32 *)&pdata->power);
+		config->multipoint = of_property_read_bool(np, "multipoint");
+
+		pdata->board_data	= data;
+		pdata->config		= config;
+	}
+
 	pdata->platform_ops		= &omap2430_ops;
 
 	platform_set_drvdata(pdev, glue);
@@ -597,12 +637,26 @@ static struct dev_pm_ops omap2430_pm_ops = {
 #define DEV_PM_OPS	NULL
 #endif
 
+#ifdef CONFIG_OF
+static const struct of_device_id omap2430_id_table[] = {
+	{
+		.compatible = "ti,omap4-musb"
+	},
+	{
+		.compatible = "ti,omap3-musb"
+	},
+	{},
+};
+MODULE_DEVICE_TABLE(of, omap2430_id_table);
+#endif
+
 static struct platform_driver omap2430_driver = {
 	.probe		= omap2430_probe,
 	.remove		= __devexit_p(omap2430_remove),
 	.driver		= {
 		.name	= "musb-omap2430",
 		.pm	= DEV_PM_OPS,
+		.of_match_table = of_match_ptr(omap2430_id_table),
 	},
 };
 
-- 
1.7.9.5

[PATCH 3/3] usb: musb: omap: Add device tree support for omap musb glue

[Kishon Vijay Abraham I]

Added device tree support for omap musb driver and updated the
Documentation with device tree binding information.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |   33 ++++++++++++
 drivers/usb/musb/omap2430.c                        |   54 ++++++++++++++++++++
 2 files changed, 87 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 0000000..544fa97
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,33 @@
+OMAP GLUE
+
+OMAP MUSB GLUE
+ - compatible : Should be "ti,musb-omap2430"
+ - ti,hwmods : must be "usb_otg_hs"
+ - multipoint : Should be "1" indicating the musb controller supports
+   multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+   MUSB configuration-specific setting. Should be set to "16"
+ - ram_bits : Specifies the ram address size. Should be set to "12"
+ - interface_type : This is a board specific setting to describe the type of
+   interface between the controller and the phy. It should be "0" or "1"
+   specifying ULPI and UTMI respectively.
+ - mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
+   represents PERIPHERAL.
+ - power : Should be "50". This signifies the controller can supply upto
+   100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs at 4a0ab000 {
+	compatible = "ti,musb-omap2430";
+	ti,hwmods = "usb_otg_hs";
+	multipoint = <1>;
+	num_eps = <16>;
+	ram_bits = <12>;
+};
+
+Board specific device node entry
+&usb_otg_hs {
+	interface_type = <1>;
+	mode = <3>;
+	power = <50>;
+};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f4d9503..d96873b 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -30,6 +30,7 @@
 #include <linux/init.h>
 #include <linux/list.h>
 #include <linux/io.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/dma-mapping.h>
 #include <linux/pm_runtime.h>
@@ -470,8 +471,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
 static int __devinit omap2430_probe(struct platform_device *pdev)
 {
 	struct musb_hdrc_platform_data	*pdata = pdev->dev.platform_data;
+	struct omap_musb_board_data	*data;
 	struct platform_device		*musb;
 	struct omap2430_glue		*glue;
+	struct device_node		*np = pdev->dev.of_node;
+	struct musb_hdrc_config		*config;
 	struct resource			*res;
 	int				ret = -ENOMEM;
 
@@ -501,6 +505,42 @@ static int __devinit omap2430_probe(struct platform_device *pdev)
 	if (glue->control_otghs == NULL)
 		dev_dbg(&pdev->dev, "Failed to obtain control memory\n");
 
+	if (np) {
+		pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+		if (!pdata) {
+			dev_err(&pdev->dev,
+				"failed to allocate musb platfrom data\n");
+			ret = -ENOMEM;
+			goto err1;
+		}
+
+		data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+		if (!data) {
+			dev_err(&pdev->dev,
+					"failed to allocate musb board data\n");
+			ret = -ENOMEM;
+			goto err1;
+		}
+
+		config = devm_kzalloc(&pdev->dev, sizeof(*config), GFP_KERNEL);
+		if (!data) {
+			dev_err(&pdev->dev,
+				"failed to allocate musb hdrc config\n");
+			goto err1;
+		}
+
+		of_property_read_u32(np, "mode", (u32 *)&pdata->mode);
+		of_property_read_u32(np, "interface_type",
+						(u32 *)&data->interface_type);
+		of_property_read_u32(np, "num_eps", (u32 *)&config->num_eps);
+		of_property_read_u32(np, "ram_bits", (u32 *)&config->ram_bits);
+		of_property_read_u32(np, "power", (u32 *)&pdata->power);
+		config->multipoint = of_property_read_bool(np, "multipoint");
+
+		pdata->board_data	= data;
+		pdata->config		= config;
+	}
+
 	pdata->platform_ops		= &omap2430_ops;
 
 	platform_set_drvdata(pdev, glue);
@@ -597,12 +637,26 @@ static struct dev_pm_ops omap2430_pm_ops = {
 #define DEV_PM_OPS	NULL
 #endif
 
+#ifdef CONFIG_OF
+static const struct of_device_id omap2430_id_table[] = {
+	{
+		.compatible = "ti,omap4-musb"
+	},
+	{
+		.compatible = "ti,omap3-musb"
+	},
+	{},
+};
+MODULE_DEVICE_TABLE(of, omap2430_id_table);
+#endif
+
 static struct platform_driver omap2430_driver = {
 	.probe		= omap2430_probe,
 	.remove		= __devexit_p(omap2430_remove),
 	.driver		= {
 		.name	= "musb-omap2430",
 		.pm	= DEV_PM_OPS,
+		.of_match_table = of_match_ptr(omap2430_id_table),
 	},
 };
 
-- 
1.7.9.5