Re: [PATCH/RFC 00/19] OMAP: voltage layer cleanup and restructure

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

On 3/25/2011 1:02 AM, Hilman, Kevin wrote:
> Kevin Hilman<khilman@ti.com>  writes:
>
>> This series is the begining of a voltage layer cleanup and restruture
>> with the primary goal of splitting up voltage domain, voltage
>> processor (VP) and voltage controller (VC) code.
>>
>> The RFC part is for the last 3 patches in the series, and for
>> discussion of how/if to split out the SoC specifics.  As an example, I
>> started on the VC and split out some functionality (setting slave i2c
>> addr, setting PMIC register addresses) into hooks that can be
>> implemented in SoC specific code.  I'd appreciate any input on this
>> approach as well as the types of functions/APIs that should exist at
>> this level.
>
> Based on some more discussions with Paul, I decided on a slightly
> different approach based on a suggestion from Paul.
>
> Rather than create the vc3xxx.c/vc4xxx.c files, instead I create the SoC
> specific functions for the VC in the existing SoC specific PRM code
> (prm2xxx_3xxx.c and prm4xxx.c.)

FWIW, I prefer your original approach :-)

I really think we'd better split the PRCM code by functions instead or 
trying to map the HW partitioning which is purely arbitrary most of the 
time.

This is for that reason that I didn't wanted to split CM to CM1 & CM2. 
These 2 partitions are doing exactly the same stuff than what CM used to do.

In this case, the PRM just contain a bunch a various stuff that are not
necessarily related. VP and VC are both standalone IPs, that are just 
located in the PRM because if was convenient for the HW folks.

So having dedicated file for each functions inside the PRCM is for my 
point of view a much better approach for the long term.

Otherwise, we might end up with one big file that will just mimic the 
mess we have inside the HW.


That being said, as soon as we have defined the functions, moving them 
here and there should not be a big deal.

Benoit