On 3/25/2011 1:02 AM, Hilman, Kevin wrote:
Kevin Hilman<khilman@xxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
