From mboxrd@z Thu Jan  1 00:00:00 1970
From: mturquette@linaro.org (Mike Turquette)
Date: Tue, 28 Aug 2012 13:52:42 -0700
Subject: [PATCH 1/5] arm: mmp: make private clock definition exclude from
 common clock
In-Reply-To: <CADApbegJwd3jQr+rKd-54AxhZG=On0LSEG5ioX-jnq9S0xY=ug@mail.gmail.com>
References: <1346036043-20115-1-git-send-email-xiechao.mail@gmail.com>
 <CAN1soZy54UcoQ_qrN2Wh4ZWVMCXj3gpHZas57GqQeT988dnkQQ@mail.gmail.com>
 <CADApbegJwd3jQr+rKd-54AxhZG=On0LSEG5ioX-jnq9S0xY=ug@mail.gmail.com>
Message-ID: <20120828205242.30660.26162@nucleus>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

Quoting Chao Xie (2012-08-27 18:40:07)
> On Tue, Aug 28, 2012 at 6:42 AM, Haojian Zhuang
> <haojian.zhuang@gmail.com> wrote:
> > On Mon, Aug 27, 2012 at 10:53 AM, Chao Xie <xiechao.mail@gmail.com> wrote:
> >> From: Chao Xie <chao.xie@marvell.com>
> >>
> >> the clock.c is mmp private implementation, make it excluded
> >> from common clock framework
> >>
> >> Signed-off-by: Chao Xie <xiechao.mail@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