[PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework

[Simon Horman]

On Wed, Oct 09, 2013 at 04:29:56PM +0900, Magnus Damm wrote:
> Hi Simon,
> 
> On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms at verge.net.au> wrote:
> > On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote:
> >> Hi Simon,
> >>
> >> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms at verge.net.au> wrote:
> >> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y at ops.dti.ne.jp wrote:
> >> >> Use common clock framework version of clock
> >> >>  drivers/clk/shmobile/clk-emev2.c
> >> >> instead of sh-clkfwk version
> >> >>  arch/arm/mach-shmobile/clock-emev2.c
> >> >> when it is configured as a part of multi-platform.
> >> >>
> >> >> Signed-off-by: Takashi Yoshii <takasi-y at ops.dti.ne.jp>
> >> >
> >> > Thanks.
> >> >
> >> > I plan to add this patch to a new topic branch,
> >> > topic/emev2-common-clock, in the renesas tree and
> >> > queue it up from there for inclusion in mainline
> >> > if/when the first patch of this series is accepted
> >> > by Mike Turquette.
> >>
> >> Thanks for picking up patches, Simon.
> >>
> >> I think you can simply merge this patch after the following series:
> >>
> >> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update
> >
> > This is already queued up.
> 
> Yes, I know, thanks for that. I tried to explain the dependency in the
> 00/00 cover letter but I will try to be more clear next time!
> 
> >> There are no build time dependencies on patch 1 and 2 so this patch
> >> can be merged independently. Regarding run-time operation, the
> >> multiplatform series above makes KZM9D DT reference only build for
> >> multiplatform, and in such case CCF is required.
> >>
> >> So if you want to keep KZM9D DT reference working until Mike Turquette
> >> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05]
> >> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits
> >> have been merged.
> >>
> >> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D
> >> Multiplatform update" before the EMEV2 CCF bits, but if so you may as
> >> well merge this patch as well IMO. This
> >> multiplatform-update-series-merge-before-CCF plan will result in
> >> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is
> >> fine with me.
> >
> > I am mainly concerned that the bindings may change before
> > they are finally merged. And I thought it would be nice to avoid
> > having to fix up the usage of the bindings if they change.
> 
> Sure, but the code in this patch looks like it simply starts DT CCF
> probing regardless of what the bindings look like. So I don't think
> you will have to worry about actual bindings detail.
> 
> > But I'm happy to just queue-up patches 2 and 3 of this series
> > now if you prefer.
> 
> Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =)

Thanks, I understand now.

I'll queue-up 3/3.