[PATCH 1/5] arm: mmp: make private clock definition exclude from common clock

Mike Turquette mturquette at linaro.org
Tue Aug 28 16:52:42 EDT 2012


Quoting Chao Xie (2012-08-27 18:40:07)
> On Tue, Aug 28, 2012 at 6:42 AM, Haojian Zhuang
> <haojian.zhuang at gmail.com> wrote:
> > On Mon, Aug 27, 2012 at 10:53 AM, Chao Xie <xiechao.mail at gmail.com> wrote:
> >> From: Chao Xie <chao.xie at marvell.com>
> >>
> >> the clock.c is mmp private implementation, make it excluded
> >> from common clock framework
> >>
> >> Signed-off-by: Chao Xie <xiechao.mail at gmail.com>
> >> ---
> >>  arch/arm/mach-mmp/Makefile |    5 ++++-
> >>  1 files changed, 4 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile
> >> index b786f7e..815c3e7 100644
> >> --- a/arch/arm/mach-mmp/Makefile
> >> +++ b/arch/arm/mach-mmp/Makefile
> >> @@ -2,13 +2,16 @@
> >>  # Makefile for Marvell's PXA168 processors line
> >>  #
> >>
> >> -obj-y                          += common.o clock.o devices.o time.o irq.o
> >> +obj-y                          += common.o devices.o time.o irq.o
> >>
> >>  # SoC support
> >>  obj-$(CONFIG_CPU_PXA168)       += pxa168.o
> >>  obj-$(CONFIG_CPU_PXA910)       += pxa910.o
> >>  obj-$(CONFIG_CPU_MMP2)         += mmp2.o sram.o
> >>
> >> +ifeq ($(CONFIG_COMMON_CLK), )
> >> +obj-y                          += clock.o
> >> +endif
> >
> > Why not to discard all private clock code? Maybe you can use common
> > clk in arch-mmp directly.
> Our dvfs and devfreq are set up based on private clock code. The
> migration of dvfs and devfreq is on going. Checking in common clock
> framework code will help us mirgarate the dvfs and devfreq, but i do
> not want to block the our product development, so I would like to keep
> the private clock code untile we have settle down all the problems.

I am OK with the general approach.  It would be nice to remove all of
the old stuff at the same time to have a better diffstat, but I also
understand needing to balance out the needs of product teams.

Since DVFS is a concern for you I would ask you look in on my
dvfs/reentrancy rfc [1] and provide feedback on whether you think it
will work well for your platform.

Regards,
Mike

[1] http://marc.info/?l=linux-arm-kernel&m=134507427602446&w=2



More information about the linux-arm-kernel mailing list