[PATCHv9 5/9] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
jason at lakedaemon.net
Fri May 17 08:55:13 EDT 2013
On Fri, May 17, 2013 at 12:08:26AM -0700, Mike Turquette wrote:
> Quoting Jason Cooper (2013-05-16 08:06:16)
> > Mike, Sebastian,
> > On Thu, May 16, 2013 at 10:26:24AM +0200, Sebastian Hesselbarth wrote:
> > > On 05/16/2013 09:44 AM, Thomas Petazzoni wrote:
> > > >Dear Mike Turquette,
> > > >
> > > >On Wed, 15 May 2013 14:41:54 -0700, Mike Turquette wrote:
> > > >>Quoting Thomas Petazzoni (2013-05-15 06:25:19)
> > > >>>The Armada 370 has two gatable clocks for each PCIe interface, and we
> > > >>>want both of them to be enabled. We therefore make one of the two
> > > >>>clocks a child of the other, as we did for the sataX and sataXlnk
> > > >>>clocks on Armada XP.
> > > >>
> > > >>Ack for patches #5 and #6. Do you want me to take them?
> > Thanks for the Ack!
> > > >I don't know, I guess with your Ack, it would be easier to carry them
> > > >through the Marvell maintainers and then the arm-soc tree, so that we
> > > >can test arm-soc and have all the pieces needed in here.
> > > >
> > > >That said, Sebastian Hesselbarth has submitted a big rework of the
> > > >mvebu clock drivers, which would conflict with this patch, and
> > > >Sebastian's rework would most likely go through your tree. If that's
> > > >the case, I guess it would be better to let you take #5 and #6 in this
> > > >patch series.
> > >
> > > I also requested to take the restructure patches through ARM tree. They
> > > are only touching files in drivers/clk/mvebu and by taking them through
> > > ARM, we can update PCIe clock patches easily. The dependency between
> > > Thomas' and my patches basically is that I renamed files that Thomas
> > > now commits to. (I switched clk/mvebu from per-function files to per-soc
> > > files).
> > I agree. My heart jumped into my throat a little there :) Mike, if
> > it's ok with you, I'd prefer to take these through arm-soc. Any merge
> > conflicts should be minimal. And at any rate, resolving the conflicts
> > are *much* easier to handle than having arm-soc depend on an outside
> > tree (then Linus has to take care in the order he merges them, no
> > rebasing for clk tree, dogs and cats living together, etc ;-) )
> Yeah that all sounds good to me. I'll review the restructure patches
More information about the linux-arm-kernel