From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Sun, 24 Jan 2016 14:33:57 -0500 Subject: [U-Boot] [PATCH 1/2] arm: imx6: Add DDR3 calibration code for MX6 Q/D/DL In-Reply-To: <201601241822.10241.marex@denx.de> References: <1450276807-8960-1-git-send-email-marex@denx.de> <201601241811.19732.marex@denx.de> <56A5075F.6040908@denx.de> <201601241822.10241.marex@denx.de> Message-ID: <20160124193357.GU3359@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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? -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: