Re: [RFC][PATCH 2/2] OMAP4: PRCM: Fix usage of prm/cm accessor api's for OMAP4

[Kevin Hilman <khilman@deeprootsystems.com>]

"Nayak, Rajendra" <rnayak@ti.com> writes:

>> -----Original Message-----
>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>> Sent: Wednesday, August 25, 2010 3:10 AM
>> To: Nayak, Rajendra
>> Cc: linux-omap@vger.kernel.org; paul@pwsan.com; Cousson, Benoit
>> Subject: Re: [RFC][PATCH 2/2] OMAP4: PRCM: Fix usage of prm/cm accessor api's for
>> OMAP4
>> 
>> Rajendra Nayak <rnayak@ti.com> writes:
>> 
>> > OMAP's have always had PRCM split into PRM for power and reset
>> > management and CM for clock management.
>> > In OMAP4 the split (physically) is not very straight forward and
>> > there are instances of clock management control registers in PRM
>> > and vice versa.
>> > However it still makes sense, even on OMAP4 to logically split
>> > PRCM into PRM and CM for better understanding and to avoid adding
>> > additonal complexity in higher level frameworks which rely on the
>> > accessor api;s to do the low level register accesses.
>> >
>> > Hence this patch makes sure that any clock management code can
>> > use the cm_read/write* accessor apis (without knowing the physical split)
>> > and power and reset management code can use prm_read/write*
>> > accessor api;s.
>> >
>> > To do this the submodule offsets within PRM/CM1 and CM2 have additonal
>> > info embedded in them specifying what base address to use while
>> > trying to access registers in the given submodule.
>> >
>> > The 16 bit signed submodule offset is defined for OMAP4 as
>> > <Bit 15>	| <Bit 14:13> 		| <Bit 12:0>
>> > <Sign bit>	| <base identifier>	| <submodule offset from base>
>> >
>> > For older OMAP's the base identifier is always set to 0.
>> >
>> > Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>> > Cc: Kevin Hilman <khilman@deeprootsystems.com>
>> > Cc: Paul Walmsley <paul@pwsan.com>
>> > Cc: Benoit Cousson <b-cousson@ti.com>
>> 
>> I'm OK with this approach, but I don't like the extra overhead added for
>> every PRCM access on OMAP2/3.
>> 
>> What if you keep the original functions and add new functions for OMAP4,
>> and use function pointers init'd at runtime (based on the existence of
>> prcm_mpu_base)

> I actually have a series to split the powerdomain f/w into platform
> specific and platform independent functions. With that I should be
> able to get rid of this single function (for prm) for omap2/3 and
> omap4 and have separate functions. I can do a similar split for
> clockdomain framework and do the same for the cm functions.  I will
> post the powerdomain split patches soon for review.

OK.

> Do you think it still makes sense to have this function pointer approach in the interim?

No, it sounds like your split-up approach is better all around.

Kevin