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