[U-Boot] [PATCH 1/2] arm: imx6: Add DDR3 calibration code for MX6 Q/D/DL

[Marek Vasut]

On Sunday, January 24, 2016 at 11:21:51 PM, Tom Rini wrote:
> On Sun, Jan 24, 2016 at 11:07:30PM +0100, Marek Vasut wrote:
> > On Sunday, January 24, 2016 at 08:33:57 PM, Tom Rini wrote:
> > > On Sun, Jan 24, 2016 at 06:22:10PM +0100, Marek Vasut wrote:
> > > > On Sunday, January 24, 2016 at 06:18:23 PM, Stefano Babic wrote:
> > > > > On 24/01/2016 18:11, Marek Vasut wrote:
> > > > > > It is not clear when the wait_for_bit() will be applied, I am
> > > > > > certain there will be another round for so. I do not want to
> > > > > > wait for it and I don't see a reason why those patches should
> > > > > > block this if the conversion can be done afterward.
> > > > > 
> > > > > Just wait for a while - if it takes too much, I reconsider to apply
> > > > > this first and factorize wait_for_bit() in a follow-up patch.
> > > > 
> > > > I have waited for over a month and I fail to see a reason why patches
> > > > which will be applied at uncertain point in the future shall block
> > > > this patchset. The wait_for_bit() can be removed by a subsequent
> > > > patch, it is already pulled out explicitly in the code, so I don't
> > > > see a problem with applying this.
> > > 
> > > Did I miss something or isn't v4 of wait_for_bit good to go?
> > 
> > I don't really know if it's good to go, but this patch does not depend on
> > it in any way. A subsequent patch can drop the wait_for_bit() from here,
> > it's the same as the wait_for_bit() in dwc2 and other wait_for_bit()
> > anywhere else, but I don't see a reason why this patch should not be
> > applied now.
> > 
> > If I follow the logic in this thread, it would also be possible to say
> > that this patch should wait until Eric submits the MX6S DDR support for
> > example. We could indefinitelly wait for new and new stuff which might
> > possibly block this.
> 
> Why don't you ack/test/review the wait_for_bit series and post a
> follow-up to this one that uses the common function, which can be
> squashed into the original and then this gets picked up?

Why ? I can send subsequent patch which removes the duplicate wait_for_bit()
from this code once the wait_for_bit series is applied. I don't see a problem
with that and the wait_for_bit() being so explicitly pulled out from the code
is done with that in mind. But that does not block this patch from being applied 
now. Does it?

Best regards,
Marek Vasut