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

[Kevin Hilman <khilman@deeprootsystems.com>]

"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.

Kevin