We've been doing some finer grained testing on our Armada-385 based
platforms and found that on a read the ODT was kicking in 3 clock cycles
too early.
It is likely this has gone unnoticed because prior to commit 247c80d6b8ad
("mv_ddr: ddr3: only use active chip-selects when tuning ODT") most
systems would have ended up maxing out the read ODT values.
Marvell have been directing us to add 3 to the min/max read calculation
and that seems to do the trick. Rather than just adding +3 I've adjusted
the existing manipulations.
I've only got access to our x530 platform at the moment so it would be
good if anyone with access to other Armada-385 could take this for a
spin.
Chris Packham (2):
mv_ddr: ddr3: Use correct bitmask for read sample delay
mv_ddr: ddr3: Update {min,max}_read_sample calculation
drivers/ddr/marvell/a38x/ddr3_training_hw_algo.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
We've been doing some finer grained testing on our Armada-385 based platforms and found that on a read the ODT was kicking in 3 clock cycles too early. It is likely this has gone unnoticed because prior to commit 247c80d6b8ad ("mv_ddr: ddr3: only use active chip-selects when tuning ODT") most systems would have ended up maxing out the read ODT values. Marvell have been directing us to add 3 to the min/max read calculation and that seems to do the trick. Rather than just adding +3 I've adjusted the existing manipulations. I've only got access to our x530 platform at the moment so it would be good if anyone with access to other Armada-385 could take this for a spin. Chris Packham (2): mv_ddr: ddr3: Use correct bitmask for read sample delay mv_ddr: ddr3: Update {min,max}_read_sample calculation drivers/ddr/marvell/a38x/ddr3_training_hw_algo.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)