On Mon, Apr 30, 2012 at 03:46:49PM -0700, Saravana Kannan wrote:
> I'm still hoping a Ack/Nack for the general idea from the others.
>
I believe that I have Acked the idea when you proposed it at the first
time. What I really hoped is you can post the patch at least 1 week
earlier. Basically I share the same frustration that Sascha has, the
platform porting have been delayed by flowing changes on the core code.
It's been -rc5, but we have not got a stable core base to have platform
porting expose on linux-next.
Anyway, since I agree this is the right direction for the long run, I
will revisit my platform porting one more time once Mike applies the
patch.
--
Regards,
Shawn
On Tue, May 01, 2012 at 04:11:05PM +0800, Shawn Guo wrote:
> On Mon, Apr 30, 2012 at 03:46:49PM -0700, Saravana Kannan wrote:
> > I'm still hoping a Ack/Nack for the general idea from the others.
> >
> I believe that I have Acked the idea when you proposed it at the first
> time. What I really hoped is you can post the patch at least 1 week
> earlier. Basically I share the same frustration that Sascha has, the
> platform porting have been delayed by flowing changes on the core code.
> It's been -rc5, but we have not got a stable core base to have platform
> porting expose on linux-next.
Hi folks
I agree with you as well, it is frustrating. Could we agree, that once
this patch is in, we freeze the core until the start of the next
cycle. We use the remainder of this cycle for porting platforms to the
generic clock framework.
Andrew
On Tue, May 01, 2012 at 11:13:34AM +0200, Andrew Lunn wrote:
> I agree with you as well, it is frustrating. Could we agree, that once
> this patch is in, we freeze the core until the start of the next
> cycle. We use the remainder of this cycle for porting platforms to the
> generic clock framework.
Or merge the platforms then do framework changes incrementally, updating
the platforms as we go (which is the normal pattern for maintaining a
framework...). I see we've already got SPEAr merged.
> Or merge the platforms then do framework changes incrementally, updating
> the platforms as we go (which is the normal pattern for maintaining a
> framework...). I see we've already got SPEAr merged.
I'm not too sure SPEAr has been really merged. As far as i understand,
its dependencies have not been fulfilled, so it does not compile. This
to me is another indication of the problems we have at the moment...
Andrew
On 05/01/2012 10:00 AM, Mark Brown wrote:
> On Tue, May 01, 2012 at 11:13:34AM +0200, Andrew Lunn wrote:
>
>> I agree with you as well, it is frustrating. Could we agree, that once
>> this patch is in, we freeze the core until the start of the next
>> cycle. We use the remainder of this cycle for porting platforms to the
>> generic clock framework.
>
> Or merge the platforms then do framework changes incrementally, updating
> the platforms as we go (which is the normal pattern for maintaining a
> framework...). I see we've already got SPEAr merged.
Sorry for the annoyance I seem to have caused. I too have been trying to
get this in for a while before the other platforms started using the new
framework. Not everyone was free at the same time and it's taken longer
that I would have wished for.
I did my best to limit the changes that would be needed without making
my patch useless. Appreciate your understanding.
Regards,
Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On Tue, May 01, 2012 at 11:03:57AM -0700, Saravana Kannan wrote:
> Sorry for the annoyance I seem to have caused. I too have been
> trying to get this in for a while before the other platforms started
> using the new framework. Not everyone was free at the same time and
> it's taken longer that I would have wished for.
> I did my best to limit the changes that would be needed without
> making my patch useless. Appreciate your understanding.
To be honest it doesn't look like your patch is a particular issue here
- there's wider process problems, for example we've managed to go
through most of the release cycle and so far the only changes showing up
in -next are:
Viresh Kumar (6):
SPEAr: clk: Add VCO-PLL Synthesizer clock
SPEAr: clk: Add Auxiliary Synthesizer clock
SPEAr: clk: Add Fractional Synthesizer clock
SPEAr: clk: Add General Purpose Timer Synthesizer clock
SPEAr: Switch to common clock framework
SPEAr13xx: Add common clock framework support
Mark Brown (1):
ARM: 7376/1: clkdev: Implement managed clk_get()
Sascha Hauer (1):
clk: add a fixed factor clock
viresh kumar (1):
ARM: 7392/1: CLKDEV: Optimize clk_find()
and obviously there's quite a bit more work which has been going on.
On 20120501-19:19, Mark Brown wrote:
> On Tue, May 01, 2012 at 11:03:57AM -0700, Saravana Kannan wrote:
>
> > Sorry for the annoyance I seem to have caused. I too have been
> > trying to get this in for a while before the other platforms started
> > using the new framework. Not everyone was free at the same time and
> > it's taken longer that I would have wished for.
>
> > I did my best to limit the changes that would be needed without
> > making my patch useless. Appreciate your understanding.
>
> To be honest it doesn't look like your patch is a particular issue here
> - there's wider process problems, for example we've managed to go
> through most of the release cycle and so far the only changes showing up
> in -next are:
I think that "wider process problems" is probably a euphemism, and I'll
take responsibility for that. This has been a learning process for me
and I underestimated the percentage of my time that would be consumed by
common clk maintenance. I'm trying to rectify that problem now.
>
> Viresh Kumar (6):
> SPEAr: clk: Add VCO-PLL Synthesizer clock
> SPEAr: clk: Add Auxiliary Synthesizer clock
> SPEAr: clk: Add Fractional Synthesizer clock
> SPEAr: clk: Add General Purpose Timer Synthesizer clock
> SPEAr: Switch to common clock framework
> SPEAr13xx: Add common clock framework support
>
> Mark Brown (1):
> ARM: 7376/1: clkdev: Implement managed clk_get()
>
> Sascha Hauer (1):
> clk: add a fixed factor clock
>
> viresh kumar (1):
> ARM: 7392/1: CLKDEV: Optimize clk_find()
>
> and obviously there's quite a bit more work which has been going on.
I could use some suggestions on the best way to resolve the merge issues
we have currently. It appears that we have three bases that platforms
need to port over the common clk framework:
Russell's clkdev
Arnd's arm-soc
My clk-next branch
I was happy to push my changes to Linus directly (as discussed in
previous mails) but I'm starting to think that maybe having Arnd absorb
the clk-next branch as part of arm-soc would be the fastest way to
assist platforms that are porting over.
Do the platform folks agree? Is this suggestion sane?
Thanks,
Mike
On Tue, May 01, 2012 at 06:56:50PM -0700, Mike Turquette wrote:
> I could use some suggestions on the best way to resolve the merge issues
> we have currently. It appears that we have three bases that platforms
> need to port over the common clk framework:
>
> Russell's clkdev
> Arnd's arm-soc
> My clk-next branch
>
> I was happy to push my changes to Linus directly (as discussed in
> previous mails) but I'm starting to think that maybe having Arnd absorb
> the clk-next branch as part of arm-soc would be the fastest way to
> assist platforms that are porting over.
>
> Do the platform folks agree? Is this suggestion sane?
>
As one of the people who are working on platform porting, I'm not
concerned about the path that clk core goes to Linus, but the time
when we have a stable clk core branch appears on arm-soc either as
a dependency or a downstream tree. Once we have stable branches for
both rmk's clkdev and clk core appear on arm-soc, we can start asking
Arnd to pull platform porting.
--
Regards,
Shawn
> I could use some suggestions on the best way to resolve the merge issues
> we have currently. It appears that we have three bases that platforms
> need to port over the common clk framework:
>
> Russell's clkdev
> Arnd's arm-soc
> My clk-next branch
Hi Mike
The Orion code only depends on clk-next. I've been more conservative
with the changes, knowing that once they are merged i can add more
patches to make use of devm_get_clk() etc.
So for my, as well as going in via arm-soc, i could also imaging
giving you a pull request and becoming part of clk-next. However, i
don't care what route they take.
Andrew
On Wednesday 02 May 2012, Mike Turquette wrote:
> I was happy to push my changes to Linus directly (as discussed in
> previous mails) but I'm starting to think that maybe having Arnd absorb
> the clk-next branch as part of arm-soc would be the fastest way to
> assist platforms that are porting over.
>
> Do the platform folks agree? Is this suggestion sane?
I guess that makes sense while there are still nontrivial
interdependencies between work going the clk-next branch and into
arm-soc.
Arnd
On Tue, May 01, 2012 at 06:56:50PM -0700, Mike Turquette wrote:
> On 20120501-19:19, Mark Brown wrote:
> > To be honest it doesn't look like your patch is a particular issue here
> > - there's wider process problems, for example we've managed to go
> > through most of the release cycle and so far the only changes showing up
> > in -next are:
> I think that "wider process problems" is probably a euphemism, and I'll
> take responsibility for that. This has been a learning process for me
> and I underestimated the percentage of my time that would be consumed by
> common clk maintenance. I'm trying to rectify that problem now.
It's not really a euphamism - it really does seem like we've got all the
technical stuff proceeding reasonably well but we're just struggling
with the mechanics of actually getting the code into -next and on its
way to mainline.
> I was happy to push my changes to Linus directly (as discussed in
> previous mails) but I'm starting to think that maybe having Arnd absorb
> the clk-next branch as part of arm-soc would be the fastest way to
> assist platforms that are porting over.
> Do the platform folks agree? Is this suggestion sane?
Seems to make sense to me; if there's some bits that are less clear you
could always keep them on a branch separate to the one that the
platforms use. It's probably also worth getting things into -next
directly, that way integration testing of bleeding edge stuff can happen
before it's been merged into other trees and it's hard to change.
What I've tried do with regmap when it's been possible (it's not this
time around because the stride changes touch everything) is to have
topic branches so that people can pull in only the specific bits they
need. I still end upn sending a pull request to Linus even if chunks of
it have also gone via other trees.
On 20120502-07:16, Andrew Lunn wrote:
> > I could use some suggestions on the best way to resolve the merge issues
> > we have currently. It appears that we have three bases that platforms
> > need to port over the common clk framework:
> >
> > Russell's clkdev
> > Arnd's arm-soc
> > My clk-next branch
>
> Hi Mike
>
> The Orion code only depends on clk-next. I've been more conservative
> with the changes, knowing that once they are merged i can add more
> patches to make use of devm_get_clk() etc.
>
> So for my, as well as going in via arm-soc, i could also imaging
> giving you a pull request and becoming part of clk-next. However, i
> don't care what route they take.
>
Hi Andrew,
The choice is yours.
Regards,
Mike
> Andrew