Re: [PATCH 3/4] dt-bindings: mmc: cdns,sdhci: add SD6HC DDR50 read-path tuning

["NG, TZE YEE" <tze.yee.ng@altera.com>]

On 28/9/2026 4:05 pm, Krzysztof Kozlowski wrote:
> On Tue, Sep 22, 2026 at 07:12:37PM +0800, tze.yee.ng@altera.com wrote:
>> From: Tze Yee Ng <tze.yee.ng@altera.com>
>>
>> DDR50 has no CMD19 tuning, so the SD6HC read path must be centred by
>> static, board/SoC-characterised PHY settings. Add three optional SD6HC
>> properties:
>>
>>    - cdns,ddr50-read-dqs-delay:   DLL_SLAVE[7:0] read-DQS delay that centres
>>      the read eye (0-255).
>>    - cdns,ddr50-use-lpbk-dqs:     DQS_TIMING[21] read-DQS source
>>      (0 = phony, 1 = loopback).
>>    - cdns,ddr50-phony-dqs-timing: PHY_CTRL[9:4] phony DQS assertion timing
>>      (0-63) that positions the fabricated strobe relative to the returning
>>      DDR data; not produced by the Cadence timing calculation.
>>
>> All three are disallowed for the SD4HC variant.
>>
>> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
>> ---
>>   .../devicetree/bindings/mmc/cdns,sd6hc.yaml   | 27 +++++++++++++++++++
>>   1 file changed, 27 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/cdns,sd6hc.yaml b/Documentation/devicetree/bindings/mmc/cdns,sd6hc.yaml
>> index d5ea2717904b..df86872603d0 100644
>> --- a/Documentation/devicetree/bindings/mmc/cdns,sd6hc.yaml
>> +++ b/Documentation/devicetree/bindings/mmc/cdns,sd6hc.yaml
>> @@ -74,6 +74,33 @@ properties:
>>       maximum: 1000
>>       default: 24
>>   
>> +  cdns,ddr50-read-dqs-delay:
>> +    description: |
>> +      SD6HC DDR50 read-DQS delay (DLL_SLAVE[7:0]) used to centre the read
>> +      eye. DDR50 has no CMD19 tuning, so this is a board/SoC-characterised
>> +      value. If absent, the driver default is used.
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    minimum: 0
>> +    maximum: 0xff
> 
> default: ...
> 

Hi Krysztof,

Thanks for your review.

No fixed constant. When the property is absent, the driver keeps the
value it computes for the mode. I'll reword the descriptions to say that.

> Also, look at the existing bindings. How are the delays represented? ps.
> Why is this different?
> 
> 

In the modes this targets (DDR50/DDR52) the PHY runs the DLL
bypassed, where this field is a count of delay elements - so it maps to 
time via cdns,delay-element-ps just like the existing delay. I'll 
express it in ps:

cdns,ddr-read-dqs-delay-ps, convert in the driver (count = ps / 
delay-element-ps), default 0.

>> +
>> +  cdns,ddr50-use-lpbk-dqs:
>> +    description: |
>> +      SD6HC DDR50 read-DQS source (DQS_TIMING[21]): 0 = phony DQS,
>> +      1 = loopback DQS. If absent, the driver default is used.
> 
> Then this is just type: boolean
> 

Agreed. I'll make it a boolean.

Note: v2 also renames these cdns,ddr50-* -> cdns,ddr-* and applies them 
in both SD DDR50 and eMMC DDR52 (per Tanmay's review).

>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    enum: [0, 1]
>> +
>> +  cdns,ddr50-phony-dqs-timing:
>> +    description: |
>> +      SD6HC DDR50 phony DQS assertion timing (PHY_CTRL[9:4]). Positions the
>> +      fabricated read strobe relative to the returning DDR data; the correct
>> +      value depends on the board's SD flight time and is not produced by the
>> +      Cadence timing calculation. If absent, the driver default
>> +      (REBAR_PULSE_CYCLES-1) is used.
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    minimum: 0
>> +    maximum: 0x3f
> 
> Best regards,
> Krzysztof