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

Message ID 1346943331-18120-2-git-send-email-kishon@ti.com
State New, archived
Headers show

Commit Message

Kishon Vijay Abraham I Sept. 6, 2012, 2:55 p.m. UTC
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(+)

Comments

Vaibhav Hiremath Sept. 6, 2012, 3:34 p.m. UTC | #1
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
>  	{ }
>  };
>  
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Felipe Balbi Sept. 6, 2012, 5:13 p.m. UTC | #2
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.
Felipe Balbi Sept. 6, 2012, 5:18 p.m. UTC | #3
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.
Tony Lindgren Sept. 6, 2012, 7:56 p.m. UTC | #4
* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Vaibhav Hiremath Sept. 7, 2012, 4:57 a.m. UTC | #5
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
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Felipe Balbi Sept. 10, 2012, 3:58 p.m. UTC | #6
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 ???
Benoit Cousson Sept. 10, 2012, 4:17 p.m. UTC | #7
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

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Felipe Balbi Sept. 10, 2012, 4:43 p.m. UTC | #8
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-#
Kishon Vijay Abraham I Sept. 11, 2012, 8:52 a.m. UTC | #9
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

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
+	},
 	{ }
 };