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

[Tim Harvey]

On Sun, Jan 31, 2016 at 9:25 AM, Marek Vasut <marex at denx.de> wrote:
> On Monday, January 25, 2016 at 12:30:00 AM, Tom Rini wrote:
>> On Mon, Jan 25, 2016 at 12:00:05AM +0100, Marek Vasut wrote:
>> > 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?
>>
>> If I tell you I'm probably going to have the wait_for_bit stuff applied
>> before the next imx PR is ready... ?
>
> So, why is this patchset not applied yet ... ?
>

Stefano,

I would also like to see this applied. I have some time in the coming
weeks to do some extensive testing of it over a variety of memory
chips and configurations.

Regards,

Tim