Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 2 Feb 2022 17:04:55 +0200
From:   Pekka Paalanen <ppaalanen@gmail.com>
To:     Noralf =?UTF-8?B?VHLDuG5uZXM=?= <noralf@tronnes.org>
Cc:     Thomas Zimmermann <tzimmermann@suse.de>,
        Sam Ravnborg <sam@ravnborg.org>,
        Javier Martinez Canillas <javierm@redhat.com>,
        linux-fbdev@vger.kernel.org, David Airlie <airlied@linux.ie>,
        Daniel Vetter <daniel.vetter@ffwll.ch>,
        Emil Velikov <emil.l.velikov@gmail.com>,
        linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        Maxime Ripard <maxime@cerno.tech>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH 1/4] drm: Add I2C connector type
Message-ID: <20220202170455.3eece5a3@eldfell>
In-Reply-To: <c6100ec3-b511-17cf-c542-e124c14fb334@tronnes.org>
References: <20220131201225.2324984-1-javierm@redhat.com>
        <20220131201225.2324984-2-javierm@redhat.com>
        <YfhMESTylI1NTKDg@ravnborg.org>
        <4d9a56a7-da25-b411-61cc-372c6fa9011d@tronnes.org>
        <4966d03e-ee0c-5130-3819-05a90a8f6d06@suse.de>
        <c6100ec3-b511-17cf-c542-e124c14fb334@tronnes.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/WjkHlZCIIXSuY/pBxDvwVSo";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Precedence: bulk

--Sig_/WjkHlZCIIXSuY/pBxDvwVSo
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, 2 Feb 2022 10:45:42 +0100
Noralf Tr=C3=B8nnes <noralf@tronnes.org> wrote:

> Den 02.02.2022 10.14, skrev Thomas Zimmermann:
> > Hi Noralf,
> >=20
> > since you're here, I'll just hijack the discussion to ask something only
> > semi-related.
> >=20
> > IIRC the gud driver doesn't update the display immediately during atomic
> > commits. Instead, it instructs a helper thread to do the update. What's
> > the rational behind this design? Is that something we should adopt for
> > other drivers that operate over slow buses (USB, I2C, etc)? Would this
> > be relevant for the ssd1307 driver?
> >  =20
>=20
> Async flushing is only necessary on multi display setups where there's
> only one rendering loop for all the displays. I saw what tiny/gm12u320.c
> did and Hans gave me the rationale. The SPI drivers run flushing inline.
> Info on the gud wiki:
> https://github.com/notro/gud/wiki/Linux-Host-Driver#asynchronous-flushing

Hi,

please also consider that userspace may throttle to the KMS pageflip
events. If the pageflip event is immediate from submitting a flip, that
could mean userspace will be repainting in a busy-loop, like 1 kHz.
However, I remember something about virtual KMS drivers doing exactly
this, and there being something that tells userspace to throttle itself
instead of depending on pageflip completions. I just forget how that is
supposed to work, and I'm fairly sure that e.g. Weston does not behave
well there.

Unfortunately, the pageflip event is also what synchronises FB usage.
Once flipping in a new FB completed, the old FB is free for re-use.
But, if the kernel is still copying out from the old FB, userspace may
partially overwrite the contents, temporarily leading to an incomplete
or too new image on screen. Do you have anything to prevent that?


Thanks,
pq

--Sig_/WjkHlZCIIXSuY/pBxDvwVSo
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

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

iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAmH6nZcACgkQI1/ltBGq
qqf/fA/9GWEbIffTcEQ1bgTLS1bvxOSJHl23hNSsG+SZKOAWl4xRyKbPxAxUlXST
dHeg56RX0psfejXIy0/u8b1+kFtoW2fGgrDSpVyHWVJS0CThcjLvjA7/VU5JaYBm
6TQNDvHe1sT8d00XsNaTOXJ4MQm1EhC1YOguoqr74a84ixVrvEbYxmfF58wX6uVi
4Kq2As+831fH1iGlTPULBLpjK0pJdlVM+LfCZjCR8IjznaPIvH8qle9QJDjriRE2
IBqc0zw0HwSCUTs5k68oltjvFVNfEiVLWQISK8CK1Mnw29CKWkeowbx76RzsTx2U
qSIxwkS3JnpzBVOQIw83i74GzMcJK78a4PGWQc2BP1Zdr5XXx1CjDG4V5i/oj7LS
V4sfIIi29esJ6wb1C0wAoxNHKA1FxI9QFqhiIXaD5R7pTeM+ysnh0Iqh/42KMOSA
CfSMbTBIs2oP0YzoUh+tLU1FEwfpW7LQBci32EujuUsQggcGWRvtI6Y2b8+L+a4F
Nnojdf5BrB0Ggq22LvfctgUze+DY6OdDQz0Y12e7QPAHlrErLLAeqp560Z8SwNYP
86sq8TOgfN094rp4jwdmuYr1Kn73Lxe6kuHgwwwaF/xDfTM+0gjnYqfogzCVDC4W
Uj2Ry8T8pGajGwsMSiWOM9hutqO4UXuaJ04+T6qY3otLIXhxuDo=
=V1N6
-----END PGP SIGNATURE-----

--Sig_/WjkHlZCIIXSuY/pBxDvwVSo--