[U-Boot] [PATCH 3/6] sunxi: add Cubieboard2 support

[Siarhei Siamashka]

On Fri, 25 Jul 2014 07:52:28 +0100
Ian Campbell <ijc at hellion.org.uk> wrote:

> On Fri, 2014-07-25 at 00:12 +0300, Siarhei Siamashka wrote:
> > The multi-soc support (within the Allwinner A10/A13/A20 family) is the
> > feature, which is scheduled for this merge window. It is a present
> > piece of work.
> 
> I have never seen any such code, nor am I aware of any such thing being
> "scheduled" for this merge window (who by?).

Sorry for not stating this clear enough. I'm am taking care of this
particular part of work. And this has been the plan since the start.

> As far as I'm concerned this is not a goal for this merge window,

You have not seen all the sunxi patches yet. And the merge window is
still open.

> if it lands then that would be nice but I think you are either underestimating
> the work involved or over estimating the size of the merge window.

We'll see.

> > Your patch is related in the sense that it is detrimental to this goal.
> 
> No it is not. Whoever eventually wants to work on multi SoC support can
> trivially build on this series.

Right. Anyway, I have both Cubieboard1 and Cubieboard2 hardware. So the
code in u-boot is still fully testable by me, and I'm not dependent on
the cooperation from the nominal maintainers of these boards.

> > > > The newly added Cubieboard2 from your patch appears to be missing the
> > > > important AXP209_POWER option. So the patch is not good enough to be
> > > > pushed anywhere in its current form.
> > > 
> > > It works for me regardless and always has.
> > 
> > This simply means that your board is not very sensitive to the use of
> > wrong voltages and may tolerate some abuse. You are just betting on
> > luck.
> 
> The sunxi github tree had exactly the same lack of power controller
> config issue and it appears to be fine for plenty of people.

Okay, that's totally convincing. Not.

> Note that we have not yet merged FAST_MBUS into mainline.

FAST_MBUS was just the use of 400MHz MBUS clock frequency instead
of 300MHz. It required the dcdc3 voltage increase from 1.25V to 1.3V.
Not doing so caused troubles for a *small* fraction of users. The
odds of *you* being in this group are indeed rather small.

Now we are talking about the 300MHz MBUS clock frequency in the
mainline u-boot, which is normally used with the dcdc3 voltage 1.25V.
But the default AXP209 dcdc3 voltage after reset appears to be only
1.2V (measured on the Cubietruck, where the tests pads are easily
accessible).

> > If you have been tracking the linux-sunxi mailing list, wrong voltages
> > (dcdc3 in particular) have caused some very real reliability problems
> > for some fraction of users. "Works for me" is not the right answer.
> > 
> > > The AXP209 config is trivial to add now that Hans has added the relevant code. 
> 
> And I have already sent a patch to do so.

Thanks for addressing the problem. That was the exactly the action I
expected from you. You don't need to go full length explaining how
minor or insignificant it was. Really.

> > Yes. You can fix the problem after the fact, or you can avoid pushing
> > the problematic commit in the first place and do something better.
> 
> We are not going to redo all of these patches from scratch as you seem
> to be asking repeatedly for every trivial issue you have found in your
> review of this series which I'm afraid is several weeks to late to be
> useful.

I am reviewing your patches because it is a good development practice,
and actually a part of the u-boot development process. I'm not doing
this personally for you. This is just needed to ensure code quality.

As for redoing the patches from scratch, you totally got the wrong
idea. I'm not the one to tell you what to do. I can only share my
opinion and you don't have any obligations to pay attention. It is
your responsibility as a custodian to make decisions in the best
interests of the sunxi project and do a proper job.

> Please base your work on what is currently in u-boot-sunxi#master, that
> is now the baseline.

OK. Let's go this route.

> Even if we *were* to redo the current stuff as you
> are asking your work will still have to be based on that.

I just want to mitigate risks and ensure that you don't screw up
something as an inexperienced custodian.

And was just waiting for the upstream custodians to confirm that
they are really going to accept your strange early pull request.
Now the comments from Tom seem to be reassuring.

-- 
Best regards,
Siarhei Siamashka