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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 3FAD5EB2717 for ; Tue, 10 Feb 2026 20:54:54 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7E4C310E030; Tue, 10 Feb 2026 20:54:53 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="getsRlrh"; dkim-atps=neutral Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9A27710E030 for ; Tue, 10 Feb 2026 20:54:51 +0000 (UTC) Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-b8eb39e24ddso85147466b.3 for ; Tue, 10 Feb 2026 12:54:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770756890; x=1771361690; darn=lists.freedesktop.org; h=mime-version:user-agent:content-transfer-encoding :disposition-notification-to:references:in-reply-to:date:cc:to:from :subject:message-id:from:to:cc:subject:date:message-id:reply-to; bh=kfTsDpxF/1pt/GYWHrHA8HMvDdV44JWrQ/sRs5nS5WI=; b=getsRlrhs5aXI8H4t6kLLLmmI5oms0Fe/JO1IGf0xNA70h8ek4iHISNG0w4gX3F2v5 mO72ZvrqYj3gXu8EN0l8i0ZBk+yodgAUM9kBQ8ZcQ0RtXJMNtd1lYwP+poc3Jk9ZsmXJ zx3QJ+nm2ssGzYzElAmUX38+CvODJfbgvrDnoPkr2WH3YCGxHUACpkFIDj5lZZkFVz89 2HyqlmRURa2ktidFanp5wSUCHSvMbvPK2tJ3w+QF91hzlrzlsYRwMNaWx6yLReLipoWw BYWIp16HlWf4+LUgDRz4Zyzcr0+NTKAetZ4aECUxhvKcSr37DR9Fy6pCVpnpH2LqdWnC MNyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770756890; x=1771361690; h=mime-version:user-agent:content-transfer-encoding :disposition-notification-to:references:in-reply-to:date:cc:to:from :subject:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=kfTsDpxF/1pt/GYWHrHA8HMvDdV44JWrQ/sRs5nS5WI=; b=mW85uvWJLMdkK/43zG6jTwJlsCvQcFXfVV9BdiB/KcLOP0ruMIio+7Fc2UVIAcF+pH CqA04f91ZD12J/Srroa0F1Ean1mTDFXF5utGZzqD98dMQX695Uu8HHNc9u0WVgkwf720 Pq4WAfZw1pYP1mZ70QMQQ23AE0Zx6hxuk0M0rkJ8nQhfS2zoPKIcs9NR13U/DgL49zV1 5XhegNqiM0SBRjuRZ4oXtWgZauNzsrii5S/7HgkNIMG0UaHjJ1hO/DKaUVlWmq3lfQT8 ZvcutC0YWA4G/qVpm9U9ZdtmYxKUembN1acN1BNFPe4IHpSjhjz7PetXe8FmySG04g7K Jx4w== X-Forwarded-Encrypted: i=1; AJvYcCWdSaMCGDeQYqEjARwRsKsVWJekE74PFIcT5h0uR5sQfYImRT/ClARTS9C3n4qN/pCwnWEuI2i88ds=@lists.freedesktop.org X-Gm-Message-State: AOJu0YyTSiB0DmUXAyhbhlV9XMlTV5PJ33Iuo4VMfKKrb7iRRBSyXCy0 KK/1/zpHhbOq7UBEDnvo7likF2hcOeZ2EpibLjLU/a6u6K8gMBzYQh1s X-Gm-Gg: AZuq6aKkpaGvA9VOyZD760lY9WbOZ9BRkvBkHAD4xo+4hJ7zqpGno5r3+rIpCNkEmZF DkQERDI8h2QGhHMy+JZXb8OJbZ9WNLdWKk9BE1RSHZ5AR3WDol+rTvK0ay+5iJ/3SdXUpfyMwiO mS6f8YDiYqd1xDnyZbW/mhpGftKPpq6gyL6FBAVIQiRhOVUCBpOcTgFI7Gne2PmIOTgRmB2mHFr QLdoE6xwIKDPoJpgGvjDz2Y0tStO2kDHT9v5Sys2QGxz7EqhqlimGUEsX/GMFlpQqz0WYP0eho+ 3wEiViTLiEhCga42ywU8EL+J7WD3lC40EbxxKtYvRbdoaUlEFlDJr9Qmrt1bIsfchemxcka0tgO 1+ZXHSqr7mo0Ko/rvBa9CHzPnPl1kWdjp7td3UXh5kga5SqfZI8/O63xEdxfvSmClDSTuUH5auu kplTDyKNluHFkMgoqmBayc+TwQauESuJ3m0CfmMsBxdSHPCvQjngtOo8vGdMMVbB8tW6o7jWnuU vfMLn36pNfmCsjjMKwVIw== X-Received: by 2002:a17:907:1c03:b0:b87:6c5c:d3d4 with SMTP id a640c23a62f3a-b8f549a17cbmr130270466b.2.1770756889693; Tue, 10 Feb 2026 12:54:49 -0800 (PST) Received: from [192.168.1.239] (87-205-5-123.static.ip.netia.com.pl. [87.205.5.123]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8f6e71dce1sm93866b.0.2026.02.10.12.54.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Feb 2026 12:54:49 -0800 (PST) Message-ID: <0627d5bfb4b58e7c767097fd8bf58345eb7196bd.camel@gmail.com> Subject: Re: [PATCH v3 16/19] drm/amd/display: Add parameter to control ALLM behavior From: Tomasz =?UTF-8?Q?Paku=C5=82a?= To: Alex Deucher Cc: Harry Wentland , alexander.deucher@amd.com, sunpeng.li@amd.com, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch, siqueira@igalia.com, dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, bernhard.berger@gmail.com, michel.daenzer@mailbox.org, daniel@fooishbar.org, admin@ptr1337.dev Date: Tue, 10 Feb 2026 21:54:46 +0100 In-Reply-To: References: <20260203185626.55428-1-tomasz.pakula.oficjalny@gmail.com> <20260203185626.55428-17-tomasz.pakula.oficjalny@gmail.com> <79264ab170e48e1372b3b847d75f4635dcc57aa6.camel@gmail.com> <1002281ca27d58a47a47fb655a88637e49776706.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, 2026-02-10 at 14:17 -0500, Alex Deucher wrote: > On Tue, Feb 10, 2026 at 1:44=E2=80=AFPM Tomasz Paku=C5=82a > wrote: > >=20 > > On Fri, 2026-02-06 at 17:04 -0500, Alex Deucher wrote: > > >=20 > > > Also, maybe a per connector kms property would be preferable. Then > > > you could change it per display. > > >=20 > > > Alex > >=20 > > I've dealt with all Harry's comments but wanted to make sure I > > understand properly. Do you mean, that the two settings should be a > > connector property like VRR_ENABLED? I understand the intent and I thin= k > > in some time, it would be best to have these exposed in compositor > > settings but how would a user control this until then? > >=20 > > Would it suffice to fire IOCTLs from a third-party tool like LACT where > > support for this could be added in a short time? > >=20 > > I made it a module property in the first place, because I thought such > > settings are pretty set-and-forget and module properties are just easy > > to set :) > >=20 > > Still, I think the defaults are sane. If I have to spend some more time > > to get the connector properties working, I could send the patches with > > the module properties ripped out for now. >=20 > My understanding is that these are something the compositor would like > to manage. I'd like to avoid adding module parameters if we can help > it because they usually cause more trouble than they help due to > unforeseen interactions with other features or "conventional wisdom" > blindly followed which leads to a bad user experience. >=20 > Alex Sure! I'll remove the parameters for now and send v4 to get some feedback on the cleanups and then I'll figure out the KMS properties. You're right, leaving that in would surely lead to issues and then people lamenting their removals.. Thanks for all the comments and all your work! Tomasz