Re: [PATCH RFC 06/25] drm/connector: hdmi: Add VTEM EMP generation

[Jani Nikula <jani.nikula@linux.intel.com>]

On Fri, 25 Sep 2026, Daniel Stone <daniel@fooishbar.org> wrote:
> Hi Vidith,
>
> On Fri, 25 Sept 2026 at 04:49, Vidith Madhu <vmadhu@nvidia.com> wrote:
>> On Mon, 21 Sep 2026, Nicolas Frattaroli wrote:
>> > +     if (!crtc_state->vrr_enabled) {
>> I don't think we should use the vrr_enabled CRTC property to determine
>> VRR_EN in the VTEM EMP. Transitioning the VRR mode sink-side typically causes
>> blanking, and it was discussed in patch [03/25] that drivers should be
>> free to handle vrr_enabled changes as a seamless switch since it only
>> concerns source-side VRR state (this is how the NVIDIA driver handles it).
>> Maybe it would make sense to extend the qms_enabled connector property
>> introduced in this patchset to an enum of {Off, Gaming, QMS}? This would allow
>> a standard path to control the VRR state on the sink, separately from
>> vrr_enabled.
>
> I remain cautious of putting this amount of policy inside the kernel
> and/or left to individual IHV choices. It's relatively obvious for
> NVIDIA and AMD to say 'we'll always enable FRL/VRR to smash the
> maximum rate (unless it's contraindicated by USB-C bandwidth somehow)
> because the power burn is inconsequential', but if you were MediaTek
> or Rockchip you'd probably make a different decision. Then again, if
> you were an MTK device living on AC power, maybe you'd make the same
> decision. Or maybe AMD would want to make a different decision on
> laptop parts because the bandwidth is noticeable then.
>
> The point is that I don't think we should bury this down in implicit
> kernel state. I'm with you on surfacing this as an explicit connector
> property. Possibly a bitmask of modes the user will use? e.g. {
> frr_only = 0, maybe_gaming_vrr = (1 << 0),  maybe_qms = (1 << 1), ...
> }? Or perhaps just a flag for whether the link should be negotiated as
> wide as possible or tight to the existing mode params?

On a tangent, Ville and I have been tossing around an idea to introduce
a drm device level property to control device "power mode" policy,
mapping to the kind of setting userspace already provides. Could start
of with the typical "performance", "balanced/default", and "power
saver".

It could be a single high-level knob to choose policy in the drm core
and drivers, instead of exposing a plethora of fine grained policy that
don't necessarily map well between drivers and may have conflicts
between them. And end up with a lot of ABI to maintain.

Policy decisions like this crop up all the time, even on things like how
to choose Display Port link config and DSC and color depth, and my gut
feeling is that just having e.g. those three options would help with
design decisions massively.

The user and userspace could use AC power or battery level or whatever
to decide which power mode to choose at the high level, and you wouldn't
have to have every desktop environment tweak every little thing at the
detailed level.


BR,
Jani.


-- 
Jani Nikula, Intel