"Nayak, Rajendra" <rnayak@xxxxxx> writes: >> -----Original Message----- >> From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] >> Sent: Wednesday, August 25, 2010 3:10 AM >> To: Nayak, Rajendra >> Cc: linux-omap@xxxxxxxxxxxxxxx; paul@xxxxxxxxx; Cousson, Benoit >> Subject: Re: [RFC][PATCH 2/2] OMAP4: PRCM: Fix usage of prm/cm accessor api's for >> OMAP4 >> >> Rajendra Nayak <rnayak@xxxxxx> 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@xxxxxx> >> > Cc: Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> >> > Cc: Paul Walmsley <paul@xxxxxxxxx> >> > Cc: Benoit Cousson <b-cousson@xxxxxx> >> >> 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 -- 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
