All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fernando Ramos <greenfoo@u92.eu>
To: Sean Paul <sean@poorly.run>
Cc: 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: [PATCH 14/15] drm/amd: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
Date: Sat, 18 Sep 2021 11:42:40 +0200	[thread overview]
Message-ID: <YUW0kJr1XoqCENhl@zacax395.localdomain> (raw)
In-Reply-To: <YUUh7X+Ft7vKHlcT@zacax395.localdomain>

On 21/09/18 01:17AM, Fernando Ramos wrote:

> > > +#include <drm/drm_drv.h>
> > 
> > Top-level headers generally come above the driver headers. Also, now that I think
> > about this a bit more, all of the new includes in this set should probably be
> > for 'drm_modeset_lock.h' instead of 'drm_drv.h'.
> 
> Ok. Let me try that.

Turns out that the DRM_MODESET_LOCK_ALL_*() macros expansion includes a call
to drm_drv_uses_atomic_modeset() which is defined in "drm_drv.h".

Thus, #include'ing <drm/drm_drv.h> cannot be avoided.

This makes me wonder...

  1. "drm_drv.h" includes "drm_device.h", which includes "drm_mode_config.h",
     which includes "drm_modeset_lock.h"

  2. "drm_modeset_lock.h" defines DRM_MODESET_LOCK_ALL_*() which expands into
     drm_drv_uses_atomic_modeset()

  3. drm_drv_uses_atomic_modeset() is declared in "drm_drv.h"

There seems to be a circular dependency here.

We can try to fix this, but I suggest to do it in a different patch series.


WARNING: multiple messages have this Message-ID (diff)
From: Fernando Ramos <greenfoo@u92.eu>
To: Sean Paul <sean@poorly.run>
Cc: 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: [Intel-gfx] [PATCH 14/15] drm/amd: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
Date: Sat, 18 Sep 2021 11:42:40 +0200	[thread overview]
Message-ID: <YUW0kJr1XoqCENhl@zacax395.localdomain> (raw)
In-Reply-To: <YUUh7X+Ft7vKHlcT@zacax395.localdomain>

On 21/09/18 01:17AM, Fernando Ramos wrote:

> > > +#include <drm/drm_drv.h>
> > 
> > Top-level headers generally come above the driver headers. Also, now that I think
> > about this a bit more, all of the new includes in this set should probably be
> > for 'drm_modeset_lock.h' instead of 'drm_drv.h'.
> 
> Ok. Let me try that.

Turns out that the DRM_MODESET_LOCK_ALL_*() macros expansion includes a call
to drm_drv_uses_atomic_modeset() which is defined in "drm_drv.h".

Thus, #include'ing <drm/drm_drv.h> cannot be avoided.

This makes me wonder...

  1. "drm_drv.h" includes "drm_device.h", which includes "drm_mode_config.h",
     which includes "drm_modeset_lock.h"

  2. "drm_modeset_lock.h" defines DRM_MODESET_LOCK_ALL_*() which expands into
     drm_drv_uses_atomic_modeset()

  3. drm_drv_uses_atomic_modeset() is declared in "drm_drv.h"

There seems to be a circular dependency here.

We can try to fix this, but I suggest to do it in a different patch series.


WARNING: multiple messages have this Message-ID (diff)
From: Fernando Ramos <greenfoo@u92.eu>
To: Sean Paul <sean@poorly.run>
Cc: 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] [PATCH 14/15] drm/amd: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
Date: Sat, 18 Sep 2021 11:42:40 +0200	[thread overview]
Message-ID: <YUW0kJr1XoqCENhl@zacax395.localdomain> (raw)
In-Reply-To: <YUUh7X+Ft7vKHlcT@zacax395.localdomain>

On 21/09/18 01:17AM, Fernando Ramos wrote:

> > > +#include <drm/drm_drv.h>
> > 
> > Top-level headers generally come above the driver headers. Also, now that I think
> > about this a bit more, all of the new includes in this set should probably be
> > for 'drm_modeset_lock.h' instead of 'drm_drv.h'.
> 
> Ok. Let me try that.

Turns out that the DRM_MODESET_LOCK_ALL_*() macros expansion includes a call
to drm_drv_uses_atomic_modeset() which is defined in "drm_drv.h".

Thus, #include'ing <drm/drm_drv.h> cannot be avoided.

This makes me wonder...

  1. "drm_drv.h" includes "drm_device.h", which includes "drm_mode_config.h",
     which includes "drm_modeset_lock.h"

  2. "drm_modeset_lock.h" defines DRM_MODESET_LOCK_ALL_*() which expands into
     drm_drv_uses_atomic_modeset()

  3. drm_drv_uses_atomic_modeset() is declared in "drm_drv.h"

There seems to be a circular dependency here.

We can try to fix this, but I suggest to do it in a different patch series.


  reply	other threads:[~2021-09-18  9:42 UTC|newest]

Thread overview: 139+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-16 21:15 [PATCH 00/15] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible Fernando Ramos
2021-09-16 21:15 ` [Nouveau] " Fernando Ramos
2021-09-16 21:15 ` [Intel-gfx] " Fernando Ramos
2021-09-16 21:15 ` [PATCH 01/15] dmr: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN() Fernando Ramos
2021-09-16 21:15   ` [Nouveau] " Fernando Ramos
2021-09-16 21:15   ` [Intel-gfx] " Fernando Ramos
2021-09-17 15:28   ` Sean Paul
2021-09-17 15:28     ` [Intel-gfx] " Sean Paul
2021-09-17 15:28     ` [Nouveau] " Sean Paul
2021-09-17 22:07     ` Fernando Ramos
2021-09-17 22:07       ` [Nouveau] " Fernando Ramos
2021-09-17 22:07       ` [Intel-gfx] " Fernando Ramos
2021-09-16 21:15 ` [PATCH 02/15] dmr/i915: " Fernando Ramos
2021-09-16 21:15   ` [Nouveau] " Fernando Ramos
2021-09-16 21:15   ` [Intel-gfx] " Fernando Ramos
2021-09-17 15:31   ` Sean Paul
2021-09-17 15:31     ` [Intel-gfx] " Sean Paul
2021-09-17 15:31     ` [Nouveau] " Sean Paul
2021-09-16 21:15 ` [PATCH 03/15] dmr/msm: " Fernando Ramos
2021-09-16 21:15   ` [Nouveau] " Fernando Ramos
2021-09-16 21:15   ` [Intel-gfx] " Fernando Ramos
2021-09-17 15:29   ` Sean Paul
2021-09-17 15:29     ` [Intel-gfx] " Sean Paul
2021-09-17 15:29     ` [Nouveau] " Sean Paul
2021-09-20  1:54   ` kernel test robot
2021-09-20  1:54     ` kernel test robot
2021-09-20  1:54     ` [Intel-gfx] " kernel test robot
2021-09-20  1:54     ` [Nouveau] " kernel test robot
2021-09-20 21:25     ` Fernando Ramos
2021-09-20 21:25       ` Fernando Ramos
2021-09-20 21:25       ` [Nouveau] " Fernando Ramos
2021-09-20 21:25       ` [Intel-gfx] " Fernando Ramos
2021-09-16 21:15 ` [PATCH 04/15] drm: cleanup: drm_modeset_lock_all() " Fernando Ramos
2021-09-16 21:15   ` [Nouveau] " Fernando Ramos
2021-09-16 21:15   ` [Intel-gfx] " Fernando Ramos
2021-09-17 15:35   ` Sean Paul
2021-09-17 15:35     ` [Intel-gfx] " Sean Paul
2021-09-17 15:35     ` [Nouveau] " Sean Paul
2021-09-16 21:15 ` [PATCH 05/15] drm/vmwgfx: " Fernando Ramos
2021-09-16 21:15   ` [Nouveau] " Fernando Ramos
2021-09-16 21:15   ` [Intel-gfx] " Fernando Ramos
2021-09-17 15:37   ` Sean Paul
2021-09-17 15:37     ` [Intel-gfx] " Sean Paul
2021-09-17 15:37     ` [Nouveau] " Sean Paul
2021-09-16 21:15 ` [PATCH 06/15] drm/tegra: " Fernando Ramos
2021-09-16 21:15   ` [Nouveau] " Fernando Ramos
2021-09-16 21:15   ` [Intel-gfx] " Fernando Ramos
2021-09-17 15:38   ` Sean Paul
2021-09-17 15:38     ` [Intel-gfx] " Sean Paul
2021-09-17 15:38     ` [Nouveau] " Sean Paul
2021-09-17 22:34     ` Fernando Ramos
2021-09-17 22:34       ` [Nouveau] " Fernando Ramos
2021-09-17 22:34       ` [Intel-gfx] " Fernando Ramos
2021-09-16 21:15 ` [PATCH 07/15] drm/shmobile: " Fernando Ramos
2021-09-16 21:15   ` [Nouveau] " Fernando Ramos
2021-09-16 21:15   ` [Intel-gfx] " Fernando Ramos
2021-09-17 15:38   ` Sean Paul
2021-09-17 15:38     ` [Intel-gfx] " Sean Paul
2021-09-17 15:38     ` [Nouveau] " Sean Paul
2021-09-16 21:15 ` [PATCH 08/15] drm/radeon: " Fernando Ramos
2021-09-16 21:15   ` [Nouveau] " Fernando Ramos
2021-09-16 21:15   ` [Intel-gfx] " Fernando Ramos
2021-09-17 15:40   ` Sean Paul
2021-09-17 15:40     ` [Intel-gfx] " Sean Paul
2021-09-17 15:40     ` [Nouveau] " Sean Paul
2021-09-17 22:32     ` Fernando Ramos
2021-09-17 22:32       ` [Nouveau] " Fernando Ramos
2021-09-17 22:32       ` [Intel-gfx] " Fernando Ramos
2021-09-16 21:15 ` [PATCH 09/15] drm/omapdrm: " Fernando Ramos
2021-09-16 21:15   ` [Nouveau] " Fernando Ramos
2021-09-16 21:15   ` [Intel-gfx] " Fernando Ramos
2021-09-17 15:40   ` Sean Paul
2021-09-17 15:40     ` [Intel-gfx] " Sean Paul
2021-09-17 15:40     ` [Nouveau] " Sean Paul
2021-09-17 15:41   ` Sean Paul
2021-09-17 15:41     ` [Nouveau] " Sean Paul
2021-09-17 15:41     ` [Intel-gfx] " Sean Paul
2021-09-17 22:37     ` Fernando Ramos
2021-09-17 22:37       ` [Nouveau] " Fernando Ramos
2021-09-17 22:37       ` [Intel-gfx] " Fernando Ramos
2021-09-16 21:15 ` [PATCH 10/15] drm/nouveau: " Fernando Ramos
2021-09-16 21:15   ` [Nouveau] " Fernando Ramos
2021-09-16 21:15   ` [Intel-gfx] " Fernando Ramos
2021-09-17 15:42   ` Sean Paul
2021-09-17 15:42     ` [Intel-gfx] " Sean Paul
2021-09-17 15:42     ` [Nouveau] " Sean Paul
2021-09-16 21:15 ` [PATCH 11/15] drm/msm: " Fernando Ramos
2021-09-16 21:15   ` [Nouveau] " Fernando Ramos
2021-09-16 21:15   ` [Intel-gfx] " Fernando Ramos
2021-09-17 15:42   ` Sean Paul
2021-09-17 15:42     ` [Intel-gfx] " Sean Paul
2021-09-17 15:42     ` [Nouveau] " Sean Paul
2021-09-17 22:41     ` Fernando Ramos
2021-09-17 22:41       ` [Nouveau] " Fernando Ramos
2021-09-17 22:41       ` [Intel-gfx] " Fernando Ramos
2021-09-16 21:15 ` [PATCH 12/15] drm/i915: " Fernando Ramos
2021-09-16 21:15   ` [Nouveau] " Fernando Ramos
2021-09-16 21:15   ` [Intel-gfx] " Fernando Ramos
2021-09-17 15:48   ` Sean Paul
2021-09-17 15:48     ` [Intel-gfx] " Sean Paul
2021-09-17 15:48     ` [Nouveau] " Sean Paul
2021-09-17 22:57     ` Fernando Ramos
2021-09-17 22:57       ` [Nouveau] " Fernando Ramos
2021-09-17 22:57       ` [Intel-gfx] " Fernando Ramos
2021-09-16 21:15 ` [PATCH 13/15] drm/gma500: " Fernando Ramos
2021-09-16 21:15   ` [Nouveau] " Fernando Ramos
2021-09-16 21:15   ` [Intel-gfx] " Fernando Ramos
2021-09-17 15:49   ` Sean Paul
2021-09-17 15:49     ` [Intel-gfx] " Sean Paul
2021-09-17 15:49     ` [Nouveau] " Sean Paul
2021-09-16 21:15 ` [PATCH 14/15] drm/amd: " Fernando Ramos
2021-09-16 21:15   ` [Nouveau] " Fernando Ramos
2021-09-16 21:15   ` [Intel-gfx] " Fernando Ramos
2021-09-17 15:55   ` Sean Paul
2021-09-17 15:55     ` [Intel-gfx] " Sean Paul
2021-09-17 15:55     ` [Nouveau] " Sean Paul
2021-09-17 23:17     ` Fernando Ramos
2021-09-17 23:17       ` [Nouveau] " Fernando Ramos
2021-09-17 23:17       ` [Intel-gfx] " Fernando Ramos
2021-09-18  9:42       ` Fernando Ramos [this message]
2021-09-18  9:42         ` [Nouveau] " Fernando Ramos
2021-09-18  9:42         ` [Intel-gfx] " Fernando Ramos
2021-09-16 21:15 ` [PATCH 15/15] doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup Fernando Ramos
2021-09-16 21:15   ` [Nouveau] " Fernando Ramos
2021-09-16 21:15   ` [Intel-gfx] " Fernando Ramos
2021-09-17 15:56   ` Sean Paul
2021-09-17 15:56     ` [Intel-gfx] " Sean Paul
2021-09-17 15:56     ` [Nouveau] " Sean Paul
2021-09-17 23:21     ` Fernando Ramos
2021-09-17 23:21       ` [Nouveau] " Fernando Ramos
2021-09-17 23:21       ` [Intel-gfx] " Fernando Ramos
2021-09-16 23:53 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible Patchwork
2021-09-17  6:19   ` Fernando Ramos
2021-09-17 15:24 ` [PATCH 00/15] " Daniel Vetter
2021-09-17 15:24   ` [Intel-gfx] " Daniel Vetter
2021-09-17 15:24   ` [Nouveau] " Daniel Vetter
2021-09-17 21:41   ` Fernando Ramos
2021-09-17 21:41     ` [Nouveau] " Fernando Ramos
2021-09-17 21:41     ` [Intel-gfx] " Fernando Ramos

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=YUW0kJr1XoqCENhl@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 \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.