lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 12 Apr 2019 15:49:57 +0200
From:   Boris Brezillon <boris.brezillon@...labora.com>
To:     Helen Koike <helen.koike@...labora.com>
Cc:     dri-devel@...ts.freedesktop.org, David Airlie <airlied@...ux.ie>,
        dnicoara@...omium.org, daniels@...labora.com,
        alexandros.frantzis@...labora.com, daniel.vetter@...ll.ch,
        linux-kernel@...r.kernel.org, tomasz Figa <tfiga@...omium.org>,
        tina.zhang@...el.com, Sean Paul <seanpaul@...gle.com>,
        kernel@...labora.com, nicholas.kazlauskas@....com,
        Stéphane Marchesin <marcheu@...gle.com>,
        Gustavo Padovan <gustavo.padovan@...labora.com>,
        Sean Paul <sean@...rly.run>, Sandy Huang <hjc@...k-chips.com>,
        linux-doc@...r.kernel.org, Thomas Zimmermann <tzimmermann@...e.de>,
        Jonathan Corbet <corbet@....net>,
        Harry Wentland <harry.wentland@....com>,
        Alex Deucher <alexander.deucher@....com>,
        Bhawanpreet Lakha <Bhawanpreet.Lakha@....com>,
        "David (ChunMing) Zhou" <David1.Zhou@....com>,
        Anthony Koo <Anthony.Koo@....com>,
        Russell King <rmk+kernel@...linux.org.uk>,
        linux-rockchip@...ts.infradead.org,
        Ville Syrjälä <ville.syrjala@...ux.intel.com>,
        Rob Clark <robdclark@...il.com>,
        Heiko Stübner <heiko@...ech.de>,
        Eric Anholt <eric@...olt.net>, Leo Li <sunpeng.li@....com>,
        linux-arm-msm@...r.kernel.org,
        Christian König <christian.koenig@....com>,
        linux-arm-kernel@...ts.infradead.org,
        David Francis <David.Francis@....com>,
        Mikita Lipski <mikita.lipski@....com>,
        amd-gfx@...ts.freedesktop.org,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <maxime.ripard@...tlin.com>,
        freedreno@...ts.freedesktop.org,
        Mamta Shukla <mamtashukla555@...il.com>,
        Daniel Vetter <daniel@...ll.ch>
Subject: Re: [PATCH v3 2/4] drm/atomic: rename async_{update,check} to
 amend_{update,check}

Hi Helen,

On Fri, 12 Apr 2019 09:58:25 -0300
Helen Koike <helen.koike@...labora.com> wrote:

> Asynchronous update is the ability change the hw state at any time, not
> only during vblank.
> 
> Amend mode is the ability to perform 1000 commits to be applied as soon
> as possible without waiting for 1000 vblanks.
> 
> async updates can be seen as amend, but the opposite is not true.
> 
> &drm_plane_helper_funcs.atomic_async_{update,check}() was being used by
> drivers to implement amend and not async. So rename them to amend.
> 
> Also improve docs explaining the difference.
> 
> If asynchronous is required, normal page flip can be performed using
> DRM_MODE_PAGE_FLIP_ASYNC flag.
> 
> Signed-off-by: Helen Koike <helen.koike@...labora.com>
> 
> ---
> Hello,
> 
> I would like to officially clarify what async update means by adding it
> in the docs.
> Please correct me if I am wrong, but the current async_{update,check}
> callbacks are being used to do amend (the legacy cursor behavior), i.e.
> to allow 1000 updates without waiting for 1000 vblanks.

Right now, the semantic of async update is driver dependent. Some
drivers will amend the last commit touching that plane (amend semantic),
others will update the plane buffer immediately which might cause
tearing (async semantic).

> 
> So I would like to clarify this in the docs and rename the current
> callbacks to reflect this behaviour.

I'm all for this clarification, but I don't think renaming the async
hooks is a good idea, since some drivers will not do real 'amend'. So,
you're changing the name, but it's still confusing :-).

How about adding new hooks (and/or flags) for the AMEND case, and
keeping the async path untouched. We can then let drivers that
currently implement async as amend implement the amend hooks instead.
Once you've done that, you can hook that up to the legacy cursor update
path so that it first tries one then the other and finally falls back
to a sync update if none of ASYNC/AMEND is possible.

> 
> I also see that for real async updates, the flag
> DRM_MODE_PAGE_FLIP_ASYNC can be used in a normal sync update (it is
> already being used by some drivers actually, in the atomic path, not only
> in the legacy page flip, at least is what I understood from
> amdgpu_dm_atomic_commit_tail() implementation).

Yes, right now, async does not necessarily imply non-block, but
Daniel seemed to think that most users want non-block when they do an
async page flip, so maybe it should be clarified too.

Regards,

Boris

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ