Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 2 Jul 2020 10:59:36 +0300
From:   Pekka Paalanen <ppaalanen@gmail.com>
To:     James Jones <jajones@nvidia.com>
Cc:     "Kirill A. Shutemov" <kirill@shutemov.name>,
        Daniel Vetter <daniel.vetter@ffwll.ch>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        LKML <linux-kernel@vger.kernel.org>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        Ben Skeggs <bskeggs@redhat.com>
Subject: Re: [git pull] drm for 5.8-rc1
Message-ID: <20200702105936.6ac90dd0@eldfell>
In-Reply-To: <77e744b9-b5e2-9e9b-44c1-98584d2ae2f3@nvidia.com>
References: <CAPM=9txGww+omvateOTizZRV9_wLdAbq6uAz3DRa_S6bn1jQuQ@mail.gmail.com>
        <20200630230808.wj2xlt44vrszqfzx@box>
        <ef7816b4-72ee-9e0e-8cac-4d80d8343f9f@nvidia.com>
        <20200701075719.p7h5zypdtlhqxtgv@box>
        <20200701075902.hhmaskxtjsm4bcx7@box>
        <77e744b9-b5e2-9e9b-44c1-98584d2ae2f3@nvidia.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 boundary="Sig_/1XKmWarqMAAGn2W3pJg=x0V"; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--Sig_/1XKmWarqMAAGn2W3pJg=x0V
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Wed, 1 Jul 2020 12:45:48 -0700
James Jones <jajones@nvidia.com> wrote:

> OK, I think I see what's going on.  In the Xorg modesetting driver, the=20
> logic is basically:
>=20
> if (gbm_has_modifiers && DRM_CAP_ADDFB2_MODIFIERS !=3D 0) {
>    drmModeAddFB2WithModifiers(..., gbm_bo_get_modifier(bo->gbm));
> } else {
>    drmModeAddFB(...);
> }
>=20
> There's no attempt to verify the DRM-KMS device supports the modifier,=20
> but then, why would there be?  GBM presumably chose a supported modifier=
=20
> at buffer creation time, and we don't know which plane the FB is going=20
> to be used with yet.  GBM doesn't actually ask the kernel which=20
> modifiers it supports here either though.  It just goes into Mesa via=20
> DRI and reports the modifier (unpatched) Mesa chose on its own.  Mesa=20
> just hard-codes the modifiers in its driver backends since its thinking=20
> in terms of a device's 3D engine, not display.  In theory, Mesa's DRI=20
> drivers could query KMS for supported modifiers if allocating from GBM=20
> using the non-modifiers path and the SCANOUT flag is set (perhaps some=20
> drivers do this or its equivalent?  Haven't checked.), but that seems=20
> pretty gnarly and doesn't fix the modifier-based GBM allocation path=20
> AFAIK.  Bit of a mess.

Hi,

the way I believe it is supposed to work is that modesetting DDX first
asks KMS what modifiers it supports, and then passes that list to GBM
when it is attempting to create a gbm_bo or a gbm_surface. If
modesetting does not do that and still uses modifiers API for creating
bos or surfaces, modesetting is broken I believe.

gbm_bo_create_with_modifiers()
gbm_surface_create_with_modifiers()

Of course, this doesn't affect the need of a kernel workaround.

How is modesetting creating the bo or surface currently?

Why would the KMS driver starting to support modifiers API suddenly
make the buffers fail, does it change how the buffers get allocated in
modesetting as well?

Or maybe you're talking about something else than what I assumed, I'm
not really up-to-date here.


Thanks,
pq

--Sig_/1XKmWarqMAAGn2W3pJg=x0V
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAl79k+gACgkQI1/ltBGq
qqeB0g//bCgxzhfwsFwQWNpJJROB8d0HJfL2wrFYHoCco5SaWO826/QQ6tVEy1D2
81ZvtCciJZnlnsYg+LvGrWh1rQt1K7HpacaKqL4e+86Puy1oQjesUEu6/z9ANl6q
mAipS5zVEmczSMb5437ZunBIIzHcv/TI1YxqdoGer24/hfPDhTLJzvZQri7f9KtV
e94492D9PuCkNqGYHrM/5K1kyXlqNpWPn5kVeD+5L8BWFEX/lW8XmbIKzjV1g5Vk
odknAPDl16fLEEGshDAhQ2t9T6RQJu5KH3FPQ6qMGzn8cBjwsIMa/EFUk5uHTM9I
HdG6wqm0dyTYHsCG2DOZ+ID0KlvFc/ZdLz7x7u+AfsZ4z9r/Mq3zePtxrQYSOzct
bg8VwLKjw+Q9jB02kIE1hF+gNBbS28RvTHhRIbiK1uOqVyVa9Wlfb4377rXwSCaE
8VSez9r98oNeTV5922WVEc9ocqTmT0y/jfy0gMLZnNex0vG29Oz1Fno4bMHOwLNE
VM3DOeHi4KhJkLQ3bjHf5Gbkzp6dyFmI0ncEntNPMMr2pmtOqTPzJ2xs7NPf1Hb6
4PI+jwnho2wB2oUyGGp6qMj9pluIWgLXV4iSJaY/Z6z0WvyGKqO9NHIILQwj/eU3
dCCIyb3Ws/ltJoxJIbGtMRtIzERiaxlhYZ6PHJAiUsB9mmmp1wA=
=xzji
-----END PGP SIGNATURE-----

--Sig_/1XKmWarqMAAGn2W3pJg=x0V--