Re: [PATCH 1/8] dt-bindings: memory: tegra: Add Tegra210 EMC bindings

[Dmitry Osipenko <digetx@gmail.com>]

02.04.2019 5:26, Joseph Lo пишет:
> On 4/1/19 8:12 PM, Dmitry Osipenko wrote:
>> 25.03.2019 10:45, Joseph Lo пишет:
>>> Add the binding document for the external memory controller (EMC) which
>>> communicates with external LPDDR4 devices. It includes the bindings of
>>> the EMC node and the EMC table of different rates.
>>>
>>> To support high rates for LPDDR4, the EMC table must be trained before
>>> it can be used for runtime clock switching. It has been done by firmware
>>> and merged to the table that Linux kernel uses. For backward
>>> compatibility with the devices that had been launched on the market, like
>>> Shield and Jetson platforms, the bindings in the EMC table should remain
>>> the same. So the firmware can recognize them and merge the trained EMC
>>> table for the kernel.
>>>
>>> Based on the work of Peter De Schrijver <pdeschrijver@nvidia.com>.
>>>
>>> Signed-off-by: Joseph Lo <josephl@nvidia.com>
>>> ---
>>>   .../nvidia,tegra210-emc.txt                   | 605 ++++++++++++++++++
>>>   1 file changed, 605 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.txt b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.txt
>>> new file mode 100644
>>> index 000000000000..1f6b6df6d37b
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.txt
>>> @@ -0,0 +1,605 @@
>>> +NVIDIA Tegra210 SoC EMC (external memory controller)
>>> +====================================================
> snip
>>> +- nvidia,emc-training-mod-regs :
>>> +- nvidia,emc-save-restore-mod-regs :
>>> +    deprecated, keep for for backward compatibility
>>
>> This is a new binding, so.. backward compatibility with what? Some old version of downstream bootloader? Do you really need it?
>>
> Yes, backward compatibility for the firmware that helps to do the initial DDR4 training before we can use that. Although the kernel doesn't use that for EMC scaling, the firmware still uses these bindings and updates them.
> 
>>> +- nvidia,emc-burst-mc-regs : values for the following registers
>>> +                 (See TRM 18.10.1 for register descriptions)
>>> +    MC_EMEM_ARB_CFG
>>> +    MC_EMEM_ARB_OUTSTANDING_REQ
>>> +    MC_EMEM_ARB_REFPB_HP_CTRL
>>> +    MC_EMEM_ARB_REFPB_BANK_CTRL
>>> +    MC_EMEM_ARB_TIMING_RCD
>>> +    MC_EMEM_ARB_TIMING_RP
>>> +    MC_EMEM_ARB_TIMING_RC
>>> +    MC_EMEM_ARB_TIMING_RAS
>>> +    MC_EMEM_ARB_TIMING_FAW
>>> +    MC_EMEM_ARB_TIMING_RRD
>>> +    MC_EMEM_ARB_TIMING_RAP2PRE
>>> +    MC_EMEM_ARB_TIMING_WAP2PRE
>>> +    MC_EMEM_ARB_TIMING_R2R
>>> +    MC_EMEM_ARB_TIMING_W2W
>>> +    MC_EMEM_ARB_TIMING_R2W
>>> +    MC_EMEM_ARB_TIMING_CCDMW
>>> +    MC_EMEM_ARB_TIMING_W2R
>>> +    MC_EMEM_ARB_TIMING_RFCPB
>>> +    MC_EMEM_ARB_DA_TURNS
>>> +    MC_EMEM_ARB_DA_COVERS
>>> +    MC_EMEM_ARB_MISC0
>>> +    MC_EMEM_ARB_MISC1
>>> +    MC_EMEM_ARB_MISC2
>>> +    MC_EMEM_ARB_RING1_THROTTLE
>>> +    MC_EMEM_ARB_DHYST_CTRL
>>> +    MC_EMEM_ARB_DHYST_TIMEOUT_UTIL_0
>>> +    MC_EMEM_ARB_DHYST_TIMEOUT_UTIL_1
>>> +    MC_EMEM_ARB_DHYST_TIMEOUT_UTIL_2
>>> +    MC_EMEM_ARB_DHYST_TIMEOUT_UTIL_3
>>> +    MC_EMEM_ARB_DHYST_TIMEOUT_UTIL_4
>>> +    MC_EMEM_ARB_DHYST_TIMEOUT_UTIL_5
>>> +    MC_EMEM_ARB_DHYST_TIMEOUT_UTIL_6
>>> +    MC_EMEM_ARB_DHYST_TIMEOUT_UTIL_7
>>> +- nvidia,emc-la-scale-regs : values for the following registers
>>> +                 (See TRM 18.10.1 for register descriptions)
>>> +    MC_MLL_MPCORER_PTSA_RATE
>>> +    MC_FTOP_PTSA_RATE
>>> +    MC_PTSA_GRANT_DECREMENT
>>> +    MC_LATENCY_ALLOWANCE_XUSB_0
>>> +    MC_LATENCY_ALLOWANCE_XUSB_1
>>> +    MC_LATENCY_ALLOWANCE_TSEC_0
>>> +    MC_LATENCY_ALLOWANCE_SDMMCA_0
>>> +    MC_LATENCY_ALLOWANCE_SDMMCAA_0
>>> +    MC_LATENCY_ALLOWANCE_SDMMC_0
>>> +    MC_LATENCY_ALLOWANCE_SDMMCAB_0
>>> +    MC_LATENCY_ALLOWANCE_PPCS_0
>>> +    MC_LATENCY_ALLOWANCE_PPCS_1
>>> +    MC_LATENCY_ALLOWANCE_MPCORE_0
>>> +    MC_LATENCY_ALLOWANCE_HC_0
>>> +    MC_LATENCY_ALLOWANCE_HC_1
>>> +    MC_LATENCY_ALLOWANCE_AVPC_0
>>> +    MC_LATENCY_ALLOWANCE_GPU_0
>>> +    MC_LATENCY_ALLOWANCE_GPU2_0
>>> +    MC_LATENCY_ALLOWANCE_NVENC_0
>>> +    MC_LATENCY_ALLOWANCE_NVDEC_0
>>> +    MC_LATENCY_ALLOWANCE_VIC_0
>>> +    MC_LATENCY_ALLOWANCE_VI2_0
>>> +    MC_LATENCY_ALLOWANCE_ISP2_0
>>> +    MC_LATENCY_ALLOWANCE_ISP2_1
>>
>> Shouldn't this be a part of a "Memory Controller" binding like it is done for T124?
>>
> 
> The Tegra SoCs before Tegra132 only supports DDR3 or DDR2. The EMC table doesn't include the settings of latency allowance registers. For the DDR4 support on Tegra210, we will dynamically scale these latency allowance registers as well to support faster clock rate. So the arbitration can be adapted according to the rate switching.
> 
> And the EMC scaling sequence for DDR3 and DDR4 is quite different. So the EMC scaling sequence for Tegra124 cannot be used for Tegra210. Same as the EMC table bindings.

This is not true, the MC configuration part is exactly the same for all of the Tegra's, see T124 driver and the tegra_mc_write_emem_configuration() which writes MC registers defined per-SoC and T210 could easily include the LA registers. But I now see that you mentioned in the cover letter that you're not going to change the binding and want upstream to accept the downstream binding as-is, in this case it's fine to mix EMC with MC. Ultimately it will be nicer if the bootloader firmware could be updated to conform with upstream to have all of the bindings consistent across all of SoC generations, AFAIK that's what other vendors are doing.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel