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

[Tom Rini <trini@konsulko.com>]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160124/54df2c0a/attachment.sig>