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

[ABRAHAM, KISHON VIJAY]

Hi,

On Mon, Sep 10, 2012 at 10:13 PM, Felipe Balbi <balbi@xxxxxx> 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@xxxxxx>
>> >>>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@xxxxxx>
>> >>>>>> ---
>> >>>>>>  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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/