nouveau.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Fernando Ramos <greenfoo@u92.eu>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Sean Paul <sean@poorly.run>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, amd-gfx@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	freedreno@lists.freedesktop.org, nouveau@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org, linux-tegra@vger.kernel.org
Subject: Re: [Nouveau] [Intel-gfx] [PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible
Date: Sat, 2 Oct 2021 19:28:02 +0200	[thread overview]
Message-ID: <YViWomXZWdy/81uT@zacax395.localdomain> (raw)
In-Reply-To: <YVgGklsHT5fkavDL@zacax395.localdomain>

On 21/10/02 09:13AM, Fernando Ramos wrote:
> On 21/10/02 05:30AM, Ville Syrjälä wrote:
> > On Sat, Oct 02, 2021 at 01:05:47AM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 01, 2021 at 04:48:15PM -0400, Sean Paul wrote:
> > > > On Fri, Oct 01, 2021 at 10:00:50PM +0300, Ville Syrjälä wrote:
> > > > > On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> > > > > > 
> > > > > > Thank you for revising, Fernando! I've pushed the set to drm-misc-next (along
> > > > > > with the necessary drm-tip conflict resolutions).
> > > > > 
> > > > > Ugh. Did anyone actually review the locking changes this does?
> > > > > I shot the previous i915 stuff down because the commit messages
> > > > > did not address any of it.
> > > > 
> > > > I reviewed the set on 9/17, I didn't see your feedback on that thread.
> > > 
> > > It was much earlir than that.
> > > https://lists.freedesktop.org/archives/dri-devel/2021-June/313193.html

Sorry, I'm new to this and it did not occur to me to search for similar patches
in the mailing list archives in case there were additional comments that applied
to my change set.

In case I had done that I would have found that, as you mentioned, you had
already raised two issues back in June:

    On Tue, Jun 29, 2021, Ville Syrjälä wrote:
    >
    > That looks wrong. You're using a private ctx here, but still
    > passing dev->mode_config.acquire_ctx to the lower level stuff.
    > 
    > Also DRM_MODESET_LOCK_ALL_{BEGIN,END}() do not seem to be
    > equivalent to drm_modeset_{lock,unlock}_all() when it comes to 
    > mode_config.mutex. So would need a proper review whether we
    > actually need that lock or not.

The first one was pointing out the same error I would later repeat in my patch
series (ups).

After further inspection of the code it looks to me that changing this:

    intel_modeset_setup_hw_state(dev, dev->mode_config.acquire_ctx);

...into this:

    intel_modeset_setup_hw_state(dev, &ctx);

...would be enough.

Why? The only difference between the old drm_modeset_{lock,unlock}_all()
functions and the new DRM_MODESET_LOCK_ALL_{BEGIN,END}() macros is that the
former use a global context stored in dev->mode_config.acquire_ctx while the
latter depend on a user provided one (typically in the stack).

In the old (working) code the global context structure is freed in
drm_modeset_unlock_all() thus we are sure no one is holding a reference to it at
that point. This means that as long as no one accesses the global
dev->mode_config.acquire_ctx context in the block that runs between lock/BEGIN
and unlock/END, the code should be equivalent before and after my changes.

In fact, now that my patch series removes the drm_modeset_{lock,unlock}_all()
functions, the acquire_ctx field of the drm_mode_config structure should be
deleted:

    /**
     * @acquire_ctx:
     *
     * Global implicit acquire context used by atomic drivers for legacy
     * IOCTLs. Deprecated, since implicit locking contexts make it
     * impossible to use driver-private &struct drm_modeset_lock. Users of
     * this must hold @mutex.
     */
    struct drm_modeset_acquire_ctx *acquire_ctx;

If I had done that (ie. removing this field) I would have detected the problem
when compiling.

There is another place (in the amdgpu driver) where this field is still being
referenced, but before I investigate that I would like to know if you agree that
this is a good path to follow.

Regarding the second issue you raised...

    > Also DRM_MODESET_LOCK_ALL_{BEGIN,END}() do not seem to be
    > equivalent to drm_modeset_{lock,unlock}_all() when it comes to 
    > mode_config.mutex. So would need a proper review whether we
    > actually need that lock or not.

...the only difference regarding mode_config.mutex I see is that in the new
macros the mutex is locked only under this condition:

    if (!drm_drv_uses_atomic_modeset(dev))

...which seems reasonable, right? Is this what you were referring to or is it
something else?

Please let me know what you think.

Thanks!




  reply	other threads:[~2021-10-03 19:51 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-24  6:43 [Nouveau] [PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible Fernando Ramos
2021-09-24  6:43 ` [Nouveau] [PATCH v2 01/17] drm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN() Fernando Ramos
2021-09-24  6:43 ` [Nouveau] [PATCH v2 02/17] drm/i915: " Fernando Ramos
2021-09-24  6:43 ` [Nouveau] [PATCH v2 03/17] drm/msm: " Fernando Ramos
2021-09-24  6:43 ` [Nouveau] [PATCH v2 04/17] drm: cleanup: drm_modeset_lock_all() " Fernando Ramos
2021-09-24  6:43 ` [Nouveau] [PATCH v2 05/17] drm/vmwgfx: " Fernando Ramos
2021-09-24  6:43 ` [Nouveau] [PATCH v2 06/17] drm/tegra: " Fernando Ramos
2021-09-24  6:43 ` [Nouveau] [PATCH v2 07/17] drm/shmobile: " Fernando Ramos
2021-09-24  6:43 ` [Nouveau] [PATCH v2 08/17] drm/radeon: " Fernando Ramos
2021-09-24  6:43 ` [Nouveau] [PATCH v2 09/17] drm/omapdrm: " Fernando Ramos
2021-09-24  6:43 ` [Nouveau] [PATCH v2 10/17] drm/nouveau: " Fernando Ramos
2021-09-24  6:43 ` [Nouveau] [PATCH v2 11/17] drm/msm: " Fernando Ramos
2021-09-24  6:43 ` [Nouveau] [PATCH v2 12/17] drm/i915: " Fernando Ramos
2021-09-24  6:43 ` [Nouveau] [PATCH v2 13/17] drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() part 2 Fernando Ramos
2021-09-24  6:43 ` [Nouveau] [PATCH v2 14/17] drm/gma500: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() Fernando Ramos
2021-09-24  6:43 ` [Nouveau] [PATCH v2 15/17] drm/amd: " Fernando Ramos
2021-09-24  6:43 ` [Nouveau] [PATCH v2 16/17] drm: cleanup: remove drm_modeset_(un)lock_all() Fernando Ramos
2021-09-24  6:43 ` [Nouveau] [PATCH v2 17/17] doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup Fernando Ramos
2021-10-01 18:36 ` [Nouveau] [PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible Sean Paul
2021-10-01 19:00   ` Ville Syrjälä
2021-10-01 20:48     ` Sean Paul
2021-10-01 22:05       ` Ville Syrjälä
2021-10-02  2:30         ` [Nouveau] [Intel-gfx] " Ville Syrjälä
2021-10-02  7:13           ` Fernando Ramos
2021-10-02 17:28             ` Fernando Ramos [this message]
2021-10-04  8:01               ` Ville Syrjälä
2021-10-02 22:32             ` Fernando Ramos
2021-10-04  8:19               ` Ville Syrjälä
2021-10-04  8:39                 ` Jani Nikula

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YViWomXZWdy/81uT@zacax395.localdomain \
    --to=greenfoo@u92.eu \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=sean@poorly.run \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).