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@xxxxxxxxxxxx> wrote: > > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y@xxxxxxxxxxxxx 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@xxxxxxxxxxxxx> > > > > 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. > 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. But I'm happy to just queue-up patches 2 and 3 of this series now if you prefer. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
