[PATCH u-boot-marvell] ddr: marvell: a38x: Fix Synchronous vs Asynchronous mode determination

[Stefan Roese]

On 1/4/22 15:57, Marek Behún wrote:
> From: Marek Behún <marek.behun at nic.cz>
> 
> Before commit 4c289425752f ("mv_ddr: a38x: add support for ddr async
> mode"), Asynchornous Mode was only used when the CPU Subsystem Clock
> Options[4:0] field in the SAR1 register was set to value 0x13: CPU at
> 2 GHz and DDR at 933 MHz.
> 
> Then commit 4c289425752f ("mv_ddr: a38x: add support for ddr async
> mode") added support for Asynchornous Modes with frequencies other than
> 933 MHz (but at least 467 MHz), but the code it added to check for
> whether Asynchornous Mode should be used is wrong: it checks whether the
> frequency setting in board DDR topology map is set to value other than
> MV_DDR_FREQ_SAR.
> 
> Thus boards which define a specific value, greater than 400 MHz, for DDR
> frequency in their board topology (e.g. Turris Omnia defines
> MV_DDR_FREQ_800), are incorrectly put into Asynchornous Mode after that
> commit.
> 
> The A38x Functional Specification, section 10.12 DRAM Clocking, says:
>    In Synchornous mode, the DRAM and CPU clocks are edge aligned and run
>    in 1:2 or 1:3 CPU to DRAM frequency ratios.
> 
> Change the check for whether Asynchornous Mode should be used according
> to this explanation in Functional Specification.
> 
> Signed-off-by: Marek Behún <marek.behun at nic.cz>

Reviewed-by: Stefan Roese <sr at denx.de>

Thanks,
Stefan

> ---
> A PR was also created for mv-ddr-marvell:
>    https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/35
> 
> Please test this. It is possible this commit will fix DDR training
> issues, since commit 4c289425752f in mv-ddr-marvell started using
> Asynchronous Mode where Synchronous Mode was used previously.
> ---
>   drivers/ddr/marvell/a38x/mv_ddr_plat.c | 19 ++++++++-----------
>   1 file changed, 8 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/ddr/marvell/a38x/mv_ddr_plat.c b/drivers/ddr/marvell/a38x/mv_ddr_plat.c
> index faafc86ea2..7c7bce73a3 100644
> --- a/drivers/ddr/marvell/a38x/mv_ddr_plat.c
> +++ b/drivers/ddr/marvell/a38x/mv_ddr_plat.c
> @@ -167,8 +167,6 @@ static u16 a38x_vco_freq_per_sar_ref_clk_40_mhz[] = {
>   };
>   
>   
> -static u32 async_mode_at_tf;
> -
>   static u32 dq_bit_map_2_phy_pin[] = {
>   	1, 0, 2, 6, 9, 8, 3, 7,	/* 0 */
>   	8, 9, 1, 7, 2, 6, 3, 0,	/* 1 */
> @@ -734,7 +732,8 @@ static int ddr3_tip_a38x_set_divider(u8 dev_num, u32 if_id,
>   	u32 divider = 0;
>   	u32 sar_val, ref_clk_satr;
>   	u32 async_val;
> -	u32 freq = mv_ddr_freq_get(frequency);
> +	u32 cpu_freq;
> +	u32 ddr_freq = mv_ddr_freq_get(frequency);
>   
>   	if (if_id != 0) {
>   		DEBUG_TRAINING_ACCESS(DEBUG_LEVEL_ERROR,
> @@ -751,11 +750,14 @@ static int ddr3_tip_a38x_set_divider(u8 dev_num, u32 if_id,
>   	ref_clk_satr = reg_read(DEVICE_SAMPLE_AT_RESET2_REG);
>   	if (((ref_clk_satr >> DEVICE_SAMPLE_AT_RESET2_REG_REFCLK_OFFSET) & 0x1) ==
>   	    DEVICE_SAMPLE_AT_RESET2_REG_REFCLK_25MHZ)
> -		divider = a38x_vco_freq_per_sar_ref_clk_25_mhz[sar_val] / freq;
> +		cpu_freq = a38x_vco_freq_per_sar_ref_clk_25_mhz[sar_val];
>   	else
> -		divider = a38x_vco_freq_per_sar_ref_clk_40_mhz[sar_val] / freq;
> +		cpu_freq = a38x_vco_freq_per_sar_ref_clk_40_mhz[sar_val];
> +
> +	divider = cpu_freq / ddr_freq;
>   
> -	if ((async_mode_at_tf == 1) && (freq > 400)) {
> +	if (((cpu_freq % ddr_freq != 0) || (divider != 2 && divider != 3)) &&
> +	    (ddr_freq > 400)) {
>   		/* Set async mode */
>   		dunit_write(0x20220, 0x1000, 0x1000);
>   		dunit_write(0xe42f4, 0x200, 0x200);
> @@ -869,8 +871,6 @@ int ddr3_tip_ext_write(u32 dev_num, u32 if_id, u32 reg_addr,
>   
>   int mv_ddr_early_init(void)
>   {
> -	struct mv_ddr_topology_map *tm = mv_ddr_topology_map_get();
> -
>   	/* FIXME: change this configuration per ddr type
>   	 * configure a380 and a390 to work with receiver odt timing
>   	 * the odt_config is defined:
> @@ -882,9 +882,6 @@ int mv_ddr_early_init(void)
>   
>   	mv_ddr_sw_db_init(0, 0);
>   
> -	if (tm->interface_params[0].memory_freq != MV_DDR_FREQ_SAR)
> -		async_mode_at_tf = 1;
> -
>   	return MV_OK;
>   }
>   
> 

Viele Grüße,
Stefan Roese

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de