[U-Boot] Marvell Armada-38x DDR training code
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?
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?
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
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.
participants (2)
-
Chris Packham -
Stefan Roese