On Wed, Jun 17, 2026 at 06:20:19PM +0200, Gerald Loacker wrote: > Hi Conor, > > Am 17.06.2026 um 17:51 schrieb Conor Dooley: > > On Wed, Jun 17, 2026 at 02:23:14PM +0200, Gerald Loacker wrote: > >> Add support for the optional rockchip,clk-lane-phase device tree property > >> to allow board-specific tuning of the clock lane sampling phase for > >> improved signal integrity across supported data rates. > >> > >> Signed-off-by: Gerald Loacker > >> --- > >> Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml | 7 +++++++ > >> 1 file changed, 7 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml > >> index 03950b3cad08c..0d824d1511bc0 100644 > >> --- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml > >> +++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml > >> @@ -56,6 +56,13 @@ properties: > >> description: > >> Some additional phy settings are access through GRF regs. > >> > >> + rockchip,clk-lane-phase: > >> + $ref: /schemas/types.yaml#/definitions/uint32 > >> + minimum: 0 > >> + maximum: 7 > >> + description: > >> + Clock lane sampling phase in 40 ps steps. The hardware default is 3. > > > > Can this instead become rockchip,clk-lane-phase-ps and be listed in the > > actual unit? > > With the -ps suffix, you can then drop the $ref. > > The default should be listed as "default: 3" (or default: 120) > > > > pw-bot: changes-requested > > > > Thanks for the suggestion. > > The phase setting is a hardware tap index (0–7) selecting a delay line > position. The datasheet mentions “about 40 ps” per step, but this is not > a calibrated or guaranteed value and may vary with PVT. > > Because of that, I’d prefer to keep the property as an index and > document the approximate delay in the description: > > Clock lane sampling phase selection (hardware tap index 0–7). Each step > corresponds to an approximately 40 ps delay as described in the hardware > specification. > > This matches the hardware model more closely. Happy to adjust if needed. > Sure, I think that's fair. > >> + > >> required: > >> - compatible > >> - reg > >> > >> -- > >> 2.34.1 > >> >