Subject: [PATCHv13 00/40] ARM: TI SoC clock DT conversion

From: [email-masked] (Tony Lindgren)
Date: Sat, 11 Jan 2014 16:36:06 -0800

* Tero Kristo <[email-masked]> [140111 01:56]:
> On 01/10/2014 08:53 PM, Tony Lindgren wrote:
> >* Mike Turquette <[email-masked]> [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 <[email-masked]>
> 
> 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