[PATCH v5 05/10] phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes

Cristian Ciocaltea cristian.ciocaltea at collabora.com
Fri Aug 7 07:22:27 PDT 2026


On 8/7/26 4:04 PM, Manivannan Sadhasivam wrote:
> On Thu, Jul 23, 2026 at 10:41:48PM +0300, Cristian Ciocaltea wrote:
>> Any changes to the PHY link rate and/or color depth done via the HDMI
>> PHY configuration API are not immediately programmed into the hardware,
>> but are delayed until the PHY usage count gets incremented from 0 to 1,
>> that is when it is powered on or when the PLL clock exposed through
>> the CCF API is prepared, whichever comes first.
>>
>> Since the clock might remain in prepared state after subsequent PHY
>> config changes, the programming can also be triggered via
>> clk_ops.set_rate().  However, from the clock consumer perspective (i.e.
>> VOP2 display controller), the (pixel) clock rate doesn't vary with bpc,
>> as that is handled internally by the PHY and reflected in the TDMS
>> character rate only.
>>
>> As a consequence, changing the bpc while preserving the modeline may
>> lead to out-of-sync issues between CCF and HDMI PHY config state,
>> because the .set_rate() callback is not invoked when clock rate remains
>> constant.  This may also happen when the PHY PLL has been pre-programmed
>> by an external entity, e.g. the bootloader, which is actually a
>> regression introduced by the recent FRL patches.
> 
> Don't mention 'patches' in description. Once the patch gets merged, it becomes a
> commit. If needed, reference the offending commit(s) directly.

Ack.  I will reword if there is a need for v6.

>>
>> Introduce a pll_config_dirty flag to keep track of uncommitted PHY
>> config changes and use it in clk_ops.determine_rate() to invalidate the
>> current clock rate (as known by CCF) and, consequently, ensure those
>> changes are programmed into hardware via clk_ops.set_rate().
>>
>> Moreover, proceed with a similar fix in phy_ops.power_on() callback, to
>> handle the scenario where the CCF API is not used due to operating in
>> FRL mode, while the clock is still in a prepared state and thus
>> preventing rk_hdptx_phy_consumer_get() to apply the updated PHY
>> configuration.
>>
>> Fixes: de5dba833118 ("phy: rockchip: samsung-hdptx: Add HDMI 2.1 FRL support")
>> Fixes: 9d0ec51d7c22 ("phy: rockchip: samsung-hdptx: Add high color depth management")
>> Tested-by: Thomas Niederprüm <dubito at online.de>
>> Tested-by: Simon Wright <simon at symple.nz>
>> Tested-by: Diederik de Haas <diederik at cknow-tech.com>  # NanoPC-T6 LTS
>> Reviewed-by: Andy Yan <andy.yan at rock-chips.com>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
> 
> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam at oss.qualcomm.com>

Thanks,
Cristian



More information about the linux-arm-kernel mailing list