[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120910164323.GK7464@arwen.pp.htv.fi>
Date: Mon, 10 Sep 2012 19:43:28 +0300
From: Felipe Balbi <balbi@...com>
To: Benoit Cousson <b-cousson@...com>
Cc: balbi@...com, Tony Lindgren <tony@...mide.com>,
Vaibhav Hiremath <hvaibhav@...com>,
Kishon Vijay Abraham I <kishon@...com>,
grant.likely@...retlab.ca, rob.herring@...xeda.com,
rob@...dley.net, linux@....linux.org.uk,
gregkh@...uxfoundation.org, devicetree-discuss@...ts.ozlabs.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-usb@...r.kernel.org, Paul Walmsley <paul@...an.com>
Subject: Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for
writing to control module
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@...com>
> >>>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@...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
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists