[U-Boot] [PATCH] driver/ddr: Fix DDR4 driver for ARM

York Sun
2014-06-18T15:46:25Z

On 06/18/2014 07:57 AM, Jon Loeliger wrote:
> On Tue, Jun 17, 2014 at 5:07 PM, York Sun <yorksun@freescale.com> wrote:
>> Previously the driver was only tested on Power SoCs. Minor fix is needed
>> for ARM SoCs.
>>
>> Signed-off-by: York Sun <yorksun@freescale.com>
>
>
> Hi York!
>
>
>> --- a/drivers/ddr/fsl/fsl_ddr_gen4.c
>> +++ b/drivers/ddr/fsl/fsl_ddr_gen4.c
>
>> @@ -183,12 +184,20 @@ step2:
>> * we choose the max, that is 500 us for all of case.
>> */
>> udelay(500);
>> +#ifdef CONFIG_PPC
>> asm volatile("sync;isync");
>> +#else
>> + asm volatile("dsb sy;isb");
>> +#endif
>>
>> /* Let the controller go */
>> temp_sdram_cfg = ddr_in32(&ddr->sdram_cfg) & ~SDRAM_CFG_BI;
>> ddr_out32(&ddr->sdram_cfg, temp_sdram_cfg | SDRAM_CFG_MEM_EN);
>> +#ifdef CONFIG_PPC
>> asm volatile("sync;isync");
>> +#else
>> + asm volatile("dsb sy;isb");
>> +#endif
>>
>> total_gb_size_per_controller = 0;
>> for (i = 0; i < CONFIG_CHIP_SELECTS_PER_CTRL; i++) {
>
> This is a great example where we should try to introduce better abstractions
> in much the same way that Linux has. Specifically, we (U-Boot) collective
> might work toward some common lower-level abstractions such as a
> memory_barrier() (and variants), and let those generic names get mapped
> into architecture-specific implementations via a linked binding. Then this
> code would not need to change, nor would #ifdefs be needed.
>

Agreed. I will work on that.

York