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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




* 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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux