From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 269F1C98321 for ; Fri, 25 Sep 2026 11:11:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Fam6qKD0Z5s9rmJFVf/14AFEXaxDXKCdUqboCF/j9T4=; b=E1fKo228MTk1na zk63x5j7apwK2HZbXtUP15TNZzzTGbPEA+R2Kn63fLOmNKNXCqekqWQvpPSwbxhFMPKkr3pBcAkmI Q4gt2Ae7QDwswcif9uuK/hhxlKeOomu2xonkfxe4cCJLs5nIzy59Z+C8yYveZSBGjCiTgS9QsW2wG zJLQlTPFJD2bbf5dKPEpmM9vt7C/LOUzw4ulVSP1Km4Bl6DYO9BdIeOejLP670DxjIkeSqCVkQ68z Cm1CF+7DykrNI366mx6XRYRGzYCq9TtFDDrJ/MPf4Pax/Y23cR0deU2xhEMP2NldD3tYT+C7jeHaU sUaewKdIL6eSBr39fAVw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xA3pw-0000000DANX-0m1H; Fri, 25 Sep 2026 11:11:28 +0000 Received: from mgamail.intel.com ([192.198.163.9]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1xA3pt-0000000DAMg-2eId; Fri, 25 Sep 2026 11:11:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1790334685; x=1821870685; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=pKJG4NNixG1bTghsu6d6b7QSc5YQncCMfKdLtiQwQAA=; b=n8Cr6KedIOaRj44vEtEv4kL8b6m1CFmrTQ3nyGOLbYp3BTOVcm1TBOJt YqP8z1W3PwLO5JP4bco72F9UCRjm66KNEE+iTCLafX77NO2O+F0SbWcaA OtcCNgS8SHuzgB8Jf7qBfOJW+0cqVOT7TwRc2sQjmbz1wX6Amc6GRF6WP NZpM5vf7QQzi4UjGGcMoIeREWKK8ZxyVhlkRPsHvyVXvaYP9SOwcKGZAj wijsNqisII1iD26Q8hQov63Q1gTJqXrcqRcTqLPvRhoxFMfTHLDNnUsDa FJrTdeSU6KJeryCZEF4M8mu06Zj6Id+yMYyZcE2wQlS1NICX4VHqTkRqB g==; X-CSE-ConnectionGUID: gRVEfVxzRe610PxA6JP/uA== X-CSE-MsgGUID: n7QUw4UfSa6WsmDUpPqHAA== X-IronPort-AV: E=McAfee;i="6800,10657,11915"; a="101778962" X-IronPort-AV: E=Sophos;i="6.27,122,1787036400"; d="scan'208";a="101778962" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Sep 2026 04:11:24 -0700 X-CSE-ConnectionGUID: cAeg1zLZQKKVg0SQhiZSeg== X-CSE-MsgGUID: gN2VeGlYSaS63jTDQxoBpQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,122,1787036400"; d="scan'208";a="270788768" Received: from smoticic-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.245.90]) by fmviesa009-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Sep 2026 04:11:18 -0700 From: Jani Nikula To: Daniel Stone , Vidith Madhu Cc: Nicolas Frattaroli , "Borah, Chaitanya Kumar" , Leo Li , Daniel Stone , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Helge Deller , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Luca Ceresoli , Sandy Huang , Heiko =?utf-8?Q?St=C3=BCbner?= , Andy Yan , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, kernel@collabora.com, Derek Foreman , wayland-devel@lists.freedesktop.org Subject: Re: [PATCH RFC 06/25] drm/connector: hdmi: Add VTEM EMP generation In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs Bertel Jungin Aukio 5, 02600 Espoo, Finland References: <20260921-vrr-limiter-uapi-v1-0-2fcd7d011646@collabora.com> <20260921-vrr-limiter-uapi-v1-6-2fcd7d011646@collabora.com> Date: Fri, 25 Sep 2026 14:11:15 +0300 Message-ID: <80ac0fee0d67a9e44a4858be904bdbb2265e50b5@intel.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260925_041125_691636_355C050A X-CRM114-Status: GOOD ( 21.97 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org On Fri, 25 Sep 2026, Daniel Stone wrote: > Hi Vidith, > > On Fri, 25 Sept 2026 at 04:49, Vidith Madhu 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 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip