Re: [PATCH v3 01/14] phy: hdmi: Add HDMI 2.1 FRL configuration options

[Cristian Ciocaltea <cristian.ciocaltea@collabora.com>]

On 8/19/25 3:42 AM, Dmitry Baryshkov wrote:
> 
> 
> On 18/08/2025 21:59, Cristian Ciocaltea wrote:
>> The HDMI 2.1 specification introduced the Fixed Rate Link (FRL) mode,
>> aiming to replace the older Transition-Minimized Differential Signaling
>> (TMDS) mode used in previous HDMI versions to support much higher
>> bandwidths (up to 48 Gbps) for modern video and audio formats.
>>
>> FRL has been designed to support ultra high resolution formats at high
>> refresh rates like 8K@60Hz or 4K@120Hz, and eliminates the need for
>> dynamic bandwidth adjustments, which reduces latency.  It operates with
>> 3 or 4 lanes at different link rates: 3Gbps, 6Gbps, 8Gbps, 10Gbps or
>> 12Gbps.
>>
>> Add support for configuring the FRL mode for HDMI PHYs.
> 
> Could you please point out corresponding DRM patches? 
> They might be WIP or incomplete. I'd like to see how this works on the consumer side.

Sure, please check the top-most commits prefixed with [WIP-FRL] in [1].  In
particular, phy_set_mode_ext() is being called in [2].

>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>>   include/linux/phy/phy-hdmi.h | 19 +++++++++++++++++--
>>   1 file changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/phy/phy-hdmi.h b/include/linux/phy/phy-hdmi.h
>> index f0ec963c6e84f1b7728acafc824dff191c6b873d..83330d359e3ae345554f20429519da14506b8ab5 100644
>> --- a/include/linux/phy/phy-hdmi.h
>> +++ b/include/linux/phy/phy-hdmi.h
>> @@ -6,16 +6,31 @@
>>   #ifndef __PHY_HDMI_H_
>>   #define __PHY_HDMI_H_
>>   +#include <linux/types.h>
>> +
>> +enum phy_mode_hdmi {
>> +    PHY_MODE_HDMI_TMDS,
>> +    PHY_MODE_HDMI_FRL,
> 
> There is no unified approach for PHY submode names. Nevertheless I'd suggest something like PHY_HDMI_MODE_TMDS / _FRL. 
> It follows more closely the networking / USB submodes. An alternative might be to use PHY_SUBMODE_HDMI_TMDS / _FRL.

I'd go for PHY_HDMI_MODE_{TMDS|FRL} and I should probably also rename the
enum to phy_hdmi_mode.

> But it's really a nit and/or bikeschedding.

No worries, let's handle this.

>> +};
>> +
>>   /**
>>    * struct phy_configure_opts_hdmi - HDMI configuration set
>> - * @tmds_char_rate: HDMI TMDS Character Rate in Hertz.
>>    * @bpc: Bits per color channel.
>> + * @tmds_char_rate: HDMI TMDS Character Rate in Hertz.
>> + * @frl.rate_per_lane: HDMI FRL Rate per Lane in Gbps.
> 
> This works nicely until HDMI Forum adds an rate not being even Gbps. 
> Is there a reason for not using ULL and bps following the tmds_char_rate design?

This is for consistency with the related members of struct drm_hdmi_info:

    /** @max_frl_rate_per_lane: support fixed rate link */
    u8 max_frl_rate_per_lane;

    /** @max_lanes: supported by sink */
    u8 max_lanes;

>> + * @frl.lanes: HDMI FRL lanes count.
>>    *
>>    * This structure is used to represent the configuration state of a HDMI phy.
>>    */
>>   struct phy_configure_opts_hdmi {
>> -    unsigned long long tmds_char_rate;
>>       unsigned int bpc;
>> +    union {
>> +        unsigned long long tmds_char_rate;
>> +        struct {
>> +            u8 rate_per_lane;
>> +            u8 lanes;
>> +        } frl;
>> +    };
>>   };
>>     #endif /* __PHY_HDMI_H_ */
>>
> 

[1] https://gitlab.collabora.com/cristicc/linux-next/-/commits/rk3588-hdmi-frl
[2] https://gitlab.collabora.com/cristicc/linux-next/-/commit/86dd2cbbccdc71a3b5db87fdf876370dc3b6f2df#90498bf5e199fded685141134e7c623ef4f4411c_132_215