[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPj87rNDsyBfy=P=0SzTm7u6Na6BpeZSpEt1mRPhLCd6rHXzTA@mail.gmail.com>
Date: Fri, 18 Apr 2025 10:43:19 +0100
From: Daniel Stone <daniel@...ishbar.org>
To: Andy Yan <andyshrk@....com>
Cc: Konstantin Shabanov <mail@...htsea.me>, Sandy Huang <hjc@...k-chips.com>,
Heiko Stübner <heiko@...ech.de>,
Andy Yan <andy.yan@...k-chips.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Dan Callaghan <djc@....id.au>, dri-devel@...ts.freedesktop.org,
linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] drm/rockchip: Disable AFBC for res >2560 on rk3399
Hi Andy,
On Fri, 18 Apr 2025 at 01:16, Andy Yan <andyshrk@....com> wrote:
> I prefer the V1 version PATCH[0]. This is because we do not deal with hardware-related
> differences at this level. It involves a VOP-related restriction and we always handle
> limitiation like this within the VOP driver .
As said in the review for v1, this is not enough for generic userspace.
If drmModeAddFB2WithModifiers() fails, userspace knows that the buffer
can never work in that configuration, and it should fall back. If
drmModeAtomicCommit(DRM_MODE_ATOMIC_TEST_ONLY) fails, userspace does
not know that the buffer can _never_ work, because the failure may be
transient or due to a combination of things.
Returning the more localised error saves userspace a lot of work and
enables a more optimal system.
Cheers,
Daniel
Powered by blists - more mailing lists