Re: [PATCH v3 0/7] OMAP: hwmod: Full data set for OMAP4430 ES1 & ES2

["Cousson, Benoit" <b-cousson@ti.com>]

On 8/12/2010 2:34 AM, Kevin Hilman wrote:
> "Cousson, Benoit"<b-cousson@ti.com>  writes:
>
>> Hi Kevin,
>>
>> On 8/9/2010 9:11 PM, Kevin Hilman wrote:
>>> Benoit Cousson<b-cousson@ti.com>   writes:
>>>
>>>> Hi Kevin&   Paul,
>>>>
>>>> Here is the OMAP4430 ES1&   ES2 hwmod data v3 series.
>>>>
>>>> Please note that there is no difference between the ES1&   ES2 wrt hwmod.
>>>>
>>>> This series is re-organised in order to allow initial submission for upstream
>>>> with minimal interconnect data set + mpu.
>>>>
>>>> Further data will be sent along with the driver once adapted to hwmod.
>>>> A first patch is done for the TIMER IP as an example.
>>>>
>>>> Patches are based on lo/for-next + for-next-fixes + pm-wip/hwmods-reset
>>>> + pm-wip/hwmods-debugfs and are available here:
>>>> git://dev.omapzoom.org/pub/scm/swarch/linux-omap-adv.git pm-wip/hwmods-omap4
>>>>
>>>> Tested on OMAP4430 ES1.0 GP device using PAB board.
>>>
>>> This is looking good to me.  Of course, as you noted we need to
>>> understand the root cause of need for those temporary patches before
>>> merging.
>>>
>>> To facilitate broader testing with the other hwmod conversions in
>>> progress, and to test with runtime PM, I've updated my
>>> pm-wip/hwmods-omap4 branch now includes your series (and its
>>> dependencies.)
>>
>> Cool, thanks.
>>
>> Maybe we should reshuffle the branch in order to allow people to start
>> stacking the OMAP4 hwmod data in small pieces on top of the initial
>> data.
>
> Yes, it is time for that.
>
>> What about these branches:
>>
>> ->  pm-wip/hwmods-omap4-full that contains the original full data that
>> people will split but that nobody should use as a base.
>>
>> bbd5866 OMAP: hwmod: Temporary prevent reset during _setup for I2Cs
>> c47ddf5 OMAP: hwmod: Temporary prevent reset during _setup for GPIOs
>> 4d2fbb8 OMAP4: hwmod: Add remaining hwmods data for OMAP4430 ES1&  ES2
>> a9a8f22 OMAP4: hwmod: Add TIMER data for OMAP4430 ES1&  ES2
>
> OK, done.
>
>> ->  pm-wip/hwmods-omap4-base to base all driver hwmod migration
>> including the OMAP4 data part
>
> OK, done, but I kept the name pm-wip/hwmods-omap4 since that's what
> people are already using for a base.
>
>> b8eccd4 OMAP: omap_hwmod: remove locking from hwmod_for_each iterators
>
> fyi... there's an updated version of this locking patch in my pm-wip/hwmods
> branch, based on top of your for-next-fixes branch, and included as part
> of pm-wip/hwmods-omap4.
>
>> fedcdf6 PM: allow runtime PM get/put from interrupts-disabled context
>> a55908c OMAP1: PM: add simple runtime PM layer to manage clocks
>> be46d49 OMAP: bus-level PM: enable use of runtime PM API for...
>> 1ebda92 OMAP: PM: initial runtime PM core support
>
> This is still pm-wip/runtime (but included in pm-wip/hwmods-omap4)
>
>> 2cb85f7 USB: Remove omap_cfg_reg for 2430
>
> This s still pm-backports (but included in pm-wip/hwmods-omap4)
>
>> ->  pm-wip/hwmods-omap4
>>
>> 71a4efa OMAP4: pm: Change l3_main to l3_main_1 during bus device init
>> 1cf660c OMAP4: clock: Fix clock names and align with hwmod names
>> 517cead OMAP4: hwmod: Add initial data for OMAP4430 ES1&  ES2
>
> I just left this as your for-next-fixes branch and merged it into
> my pm-wip/hwmods-omap4.

Great, thanks.

I'll start notifying people to rebase and re-submit the OMAP4 hwmod part.

Thanks,
Benoit