[U-Boot] Marvell Armada-38x DDR training code

[U-Boot] Marvell Armada-38x DDR training code

[Chris Packham]

Hi,

I've posted a couple of improvements to the in-tree ddr training code
but we've known for a while that u-boot proper is a bit behind
Marvell's code for ddr training. And now I really do have a problem on
my board that is fixed by using Marvell's code.

Yesterday I got hold of patches from Marvell for their "standalone"
mv_ddr code. It's under a tri-license Proprietary/GPL/BSD-3c so I've
exercised my rights under the GPL and made it available on github
https://github.com/cpackham/mv_ddr.git

This standalone code looks the most u-boot-ish of any code I've gotten
out of Marvell. In fact I suspect it was based on the work that Stefan
did initially.

The question how do I get this upstream I could submit 475 odd patches
preserving the authorship, I could submit one big roll-up of changes.
Neither option is particularly appealing. It would be hard to narrow
down the subset of changes that fixes my particular problem.

Any suggestions on how to proceed?

[U-Boot] Marvell Armada-38x DDR training code

[Chris Packham]

On Thu, Mar 29, 2018 at 4:01 PM, Chris Packham <judge.packham@gmail.com> wrote:
> Hi,
>
> I've posted a couple of improvements to the in-tree ddr training code
> but we've known for a while that u-boot proper is a bit behind
> Marvell's code for ddr training. And now I really do have a problem on
> my board that is fixed by using Marvell's code.
>
> Yesterday I got hold of patches from Marvell for their "standalone"
> mv_ddr code. It's under a tri-license Proprietary/GPL/BSD-3c so I've
> exercised my rights under the GPL and made it available on github
> https://github.com/cpackham/mv_ddr.git

Actually looks like Marvell have their own official one
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git so
there's no need for mine. I'll take it down to avoid confusion.

> This standalone code looks the most u-boot-ish of any code I've gotten
> out of Marvell. In fact I suspect it was based on the work that Stefan
> did initially.
>
> The question how do I get this upstream I could submit 475 odd patches
> preserving the authorship, I could submit one big roll-up of changes.
> Neither option is particularly appealing. It would be hard to narrow
> down the subset of changes that fixes my particular problem.
>
> Any suggestions on how to proceed?

[U-Boot] Marvell Armada-38x DDR training code

[Stefan Roese]

Hi Chris,

sorry for the late reply - I just returned from vacation.

On 04.04.2018 03:31, Chris Packham wrote:
> On Thu, Mar 29, 2018 at 4:01 PM, Chris Packham <judge.packham@gmail.com> wrote:
>> Hi,
>>
>> I've posted a couple of improvements to the in-tree ddr training code
>> but we've known for a while that u-boot proper is a bit behind
>> Marvell's code for ddr training. And now I really do have a problem on
>> my board that is fixed by using Marvell's code.
>>
>> Yesterday I got hold of patches from Marvell for their "standalone"
>> mv_ddr code. It's under a tri-license Proprietary/GPL/BSD-3c so I've
>> exercised my rights under the GPL and made it available on github
>> https://github.com/cpackham/mv_ddr.git
> 
> Actually looks like Marvell have their own official one
> https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git so
> there's no need for mine. I'll take it down to avoid confusion.

Understood.

>> This standalone code looks the most u-boot-ish of any code I've gotten
>> out of Marvell. In fact I suspect it was based on the work that Stefan
>> did initially.
>>
>> The question how do I get this upstream I could submit 475 odd patches
>> preserving the authorship, I could submit one big roll-up of changes.
>> Neither option is particularly appealing. It would be hard to narrow
>> down the subset of changes that fixes my particular problem.
>>
>> Any suggestions on how to proceed?

Are you still interested in porting / pushing those patches into
mainline? I would very much welcome this. And yes, its not easy to
decide, how this should be done. Both options have some drawbacks.
Do you have a preference?

Thanks,
Stefan

[U-Boot] Marvell Armada-38x DDR training code

[Chris Packham]

On Sun, Apr 8, 2018 at 10:24 PM, Stefan Roese <sr@denx.de> wrote:
> Hi Chris,
>
> sorry for the late reply - I just returned from vacation.

No problem. I'm about to head off on vacation next week myself.

> On 04.04.2018 03:31, Chris Packham wrote:
>>
>> On Thu, Mar 29, 2018 at 4:01 PM, Chris Packham <judge.packham@gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I've posted a couple of improvements to the in-tree ddr training code
>>> but we've known for a while that u-boot proper is a bit behind
>>> Marvell's code for ddr training. And now I really do have a problem on
>>> my board that is fixed by using Marvell's code.
>>>
>>> Yesterday I got hold of patches from Marvell for their "standalone"
>>> mv_ddr code. It's under a tri-license Proprietary/GPL/BSD-3c so I've
>>> exercised my rights under the GPL and made it available on github
>>> https://github.com/cpackham/mv_ddr.git
>>
>>
>> Actually looks like Marvell have their own official one
>> https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git so
>> there's no need for mine. I'll take it down to avoid confusion.
>
>
> Understood.
>
>>> This standalone code looks the most u-boot-ish of any code I've gotten
>>> out of Marvell. In fact I suspect it was based on the work that Stefan
>>> did initially.
>>>
>>> The question how do I get this upstream I could submit 475 odd patches
>>> preserving the authorship, I could submit one big roll-up of changes.
>>> Neither option is particularly appealing. It would be hard to narrow
>>> down the subset of changes that fixes my particular problem.
>>>
>>> Any suggestions on how to proceed?
>
>
> Are you still interested in porting / pushing those patches into
> mainline? I would very much welcome this. And yes, its not easy to
> decide, how this should be done. Both options have some drawbacks.
> Do you have a preference?

Yes I'm still keen for them to go in, I should have something ready
either today or tomorrow. I'm not sure if it's something that can go
in 2018.05 or if we should leave it for .07 to give the other board
maintainers a chance to test.

I've settled on treating it as a "sync with upstream" since many of
the commits just fix something done earlier. I'll do what I can to
reduce the delta (e.g. remove unused code that gets deleted in the
next step) but there will be at least one big-ish patch which may trip
over the mailing lists size limit. Also because there are changes to
the topology_map structure that large patch will need touch files
outside of drivers/ddr/marvell to preserve bisect-ability.

I'll also have to look into re-doing Marek B's 2T timing changes. I
can probably do that on-top of the new code since the new code
defaults to 2T for a38x.