Re: [PATCH v2 3/4] ddr: imx: Allow to call ddr init without logging failure

On 20.08.26 17:25, Marek Vasut wrote:
> On 8/20/26 4:25 PM, Frieder Schrempf wrote:
>> On 20.08.26 10:05, Marek Vasut wrote:
>>> On 8/20/26 8:34 AM, Frieder Schrempf wrote:
>>>> On 19.08.26 14:47, Marek Vasut wrote:
>>>>> On 8/19/26 12:10 PM, Frieder Schrempf wrote:
>>>>>> On 19.08.26 12:04, Marek Vasut wrote:
>>>>>>> On 8/19/26 9:07 AM, Frieder Schrempf wrote:
>>>>>>>> From: Frieder Schrempf <[email protected]>
>>>>>>>>
>>>>>>>> In some cases we need to call ddr_init() multiple times to try
>>>>>>>> different configurations.
>>>>>>>
>>>>>>> What different configurations ? Details please ?
>>>>>>
>>>>>> The detection of different DDR types/sizes on our SoMs has always
>>>>>> been
>>>>>> based on trying the init and seeing if it succeeds, falling back
>>>>>> to the
>>>>>> smaller sizes on failure. See here [1].
>>>>> Could you maybe bring the interface up in some minimal 400 MTps or 100
>>>>> MTps configuration and then read out the MR ID registers from the DRAM
>>>>> to discern which DRAM configuration is present on your SoM? This would
>>>>> be the ideal generic way of doing this, and it would be reliable since
>>>>> the IDs are stable and surely indicate which DRAM chip and how big it
>>>>> is.
>>>>
>>>> No, unfortunately this doesn't work. We already tried. The MR ID can't
>>>> be used as we have single and dual rank setups that report the same ID.
>>>> We have no way of knowing how many dies are connected unless we try it.
>>>
>>> Is the controller unable to interact with each rank separately ? I would
>>> expect in single rank setup, that read of MR ID from one rank would pass
>>> and from the other rank it would fail ?
>>
>> I'm not sure, but even if it would work, it would require several
>> separate init attempts only to read the IDs
> 
> Why ? Init the bus in slowest mode with widest bus settings, then try
> MRRD on all available DRAM chips, then figure out which ones report
> valid IDs and which ones fail the MRd .

As far as I can see this doesn't work. If we use the widest bus setting
(CsPresent=0x3) on a single rank module, the training fails and the DDR
remains in a state where the MR read doesn't work yet.

So, actually the training failure is what already tells us that there is
a single rank DDR and that's exactly what our current code does: first
init with the dual rank config and if that fails, fall back to single rank.

> 
>> , so I'm not sure if there is
>> any benefit.
> 
> Generic solution that surely works and does not guess the DRAM size.
> 
>> Also I'm not seeing anyone doing this kind of thing. It
>> might be worth looking at, but my primary goal now is to land patch 1 of
>> this series in order to fix the regression.
> 
> What regression ? (I was not CCed on that)
> 
> You can (=should) send bugfixes separately.

Right, I dropped everything but the bugfix in v3 and will continue this
separately.