* Tero Kristo <t-kristo@xxxxxx> [140111 01:56]: > On 01/10/2014 08:53 PM, Tony Lindgren wrote: > >* Mike Turquette <mturquette@xxxxxxxxxx> [140109 14:25]: > >>Quoting Tero Kristo (2014-01-09 06:00:11) > >>>Hi, > >>> > >>>So, bad luck number release for this, as v12 wasn't sufficient still. > >>> > >>>Changes compared to previous version: > >>>- Dropped any changes to generic clock drivers, as it seems impossible > >>> to agree anything in short term, this means the patch set shrank in > >>> size from 49 patches to 40 (first 9 patches were dropped). > >>>- Copy pasted implementation for clk-divider and clk-mux from drivers/clk > >>> to drivers/clk/ti, and made the modifications needed to the TI version > >>> of the clock drivers only (based on discussions with Mike, this is fine) > >>>- Changed name of clk_ll_ops to ti_clk_ll_ops so that this doesn't conflict > >>> with any generic implementation we might have at some point, migrating > >>> this to the generic version should be easy enough also. > >>>- Fixed trace_clk_div_div_ck for omap4, this node was broken in previous > >>> versions and resulted into an orphan clock node > >>>- Fixed compile problem for omap5 only build reported by Felipe > >>>- Fixed a couple of sparse warnings > >>>- changed the mach-omap2/clock.c to use readl_relaxed / writel_relaxed > >>> instead of __raw_readl / __raw_writel > >> > >>Hi Tero, > >> > >>This approach takes care of all of my concerns with this series. Thanks > >>for your long suffering patience on it. > >> > >>It seems some build errors are cropping up, so once those are fixed then > >>I'll be happy to merge clk-next-dt-clks-v13 into clk-next for 3.14. > > > >I'm fine with Mike merging these all via the clock tree assuming no more > >pending comments. For the patches changed from the last time around, > >please feel free to add: > > > >Acked-by: Tony Lindgren <tony@xxxxxxxxxxx> > > How about the dts data patches? Should these also go via Mike's > tree? Otherwise we will have boot failures until the dts patches are > merged. Yes I think that's the way to go, they mostly add new files so there should not be major conflicts. Regards, Tony -- 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
