[PATCH 3/4] [RFC] ARM: dts: stm32: Rework DDR DT inclusion

[Marek Vasut]

On 4/7/20 3:00 PM, Patrick DELAUNAY wrote:
> Dear Marek,

Hi,

>> diff --git a/arch/arm/dts/stm32mp15-ddr.dtsi b/arch/arm/dts/stm32mp15-ddr.dtsi
>> index 38f29bb789..50ca7092c4 100644
>> --- a/arch/arm/dts/stm32mp15-ddr.dtsi
>> +++ b/arch/arm/dts/stm32mp15-ddr.dtsi
>> @@ -3,152 +3,233 @@
>>   * Copyright : STMicroelectronics 2018
>>   */
>>
>> -/ {
>> -	soc {
>> -		ddr: ddr at 5a003000 {
>> -			u-boot,dm-pre-reloc;
> 
> For information, binding file must be updated also
> ./doc/device-tree-bindings/memory-controllers/st,stm32mp1-ddr.txt
> 
> This binding and the helper file " stm32mp15-ddr.dtsi" is common with TF-A.
> 
>> +&ddr {
>> +	config at DDR_MEM_LABEL {
> 
> I think that  "config at text"
> don't respect the latest device tree rule and a warning is raised with latest dtc version
> 
> it is now mandatory to value after align @ with reg value
> 
> config@<reg> {
> 	reg = <reg>
> }
> 
> It is why I prefer a name without meaning here (as config-1 / config-2), 
> And selection is done on st,mem-name
> 
> config-1 {
> ....
> }
> config-2 {
> ....
> }
> 
> 
> And I want to propose, for DH board with several configuration
> 
> &ddr  {
> 	config-1 {
> #include "stm32mp15-ddr3-1x4Gb-1066-binG.dtsi"
> 	}
> 	config-2 {
> #include "stm32mp15-ddr3-2x4Gb-1066-binG.dtsi"
> 	}
> }
> 
> 
> For ST board with only one configuration (don't change the device tree, config at the same level)
> &ddr  {
> #include "stm32mp15-ddr3-1x4Gb-1066-binG.dtsi"
> }
> 
> 
> NB: I have a other idea, it is to use the "reg" as config identifier to select configuration, as it is done with OTP with "opp-supported-hw"
> in linux/Documentation/devicetree/bindings/opp/opp.txt
> 
> And reg can be the identified with your GPIO setting
> 
> &ddr  {
> 	config at 2 {
> 		reg = 2;
> #include "stm32mp15-ddr3-1x4Gb-1066-binG.dtsi"
> 	}
> 	config at 3 {
> 		reg = 3;
> #include "stm32mp15-ddr3-2x4Gb-1066-binG.dtsi"
> 	}
> }
> 
> This proposal avoids to compare a hardcoded string in SPL...

I would much rather prefer to avoid manually writing the config@<foo>
parts, that should be handled by some macro magic instead. With my
proposal, it is not necessary at all either.