From: "Ville Syrjälä" <ville.syrjala@linux.intel.com> To: Fernando Ramos <greenfoo@u92.eu> 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: [Intel-gfx] [PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible Date: Mon, 4 Oct 2021 11:19:01 +0300 [thread overview] Message-ID: <YVq49SWuC3T7i1a6@intel.com> (raw) In-Reply-To: <YVjd7hLKtYG2bkY7@zacax395.localdomain> On Sun, Oct 03, 2021 at 12:32:14AM +0200, Fernando Ramos wrote: > On 21/10/02 09:13AM, Fernando Ramos wrote: > > > > Sean, could you revert the whole patch series? I'll have a deeper look into the > > patch set and come up with a v3 where all these issues will be addressed. > > > > Hi Sean, > > I now understand the nature of the issue that caused the problem with i915 and > have proceed to remove the global context structure (which revealed a similar > issue in the amdgpu driver). > > I have prepared a V3 version of the patch set where these issues should > hopefully be fixed for both the i915 and amdgpu drivers. > > In order to prevent causing more disruption, could you tell me what the proper > way to proceed would be? In particular: > > 1. Is there any place where I can push my changes so that they are tested > on a i915 machine? (Some type of automated pool) cc:intel-gfx, which it looks like you did, _but_ your patches did did not even apply against drm-tip so our CI rejected it. There was a reply to the patches from CI indicating that. And that is one reason I probably just ignored the whole thing. If it doesn't even apply/build it's not worth my time to read. > > 2. I can test the amdgpu driver on my machine but, what about all the other > architectures? What is the standard procedure? Should I simply publish V3 > and wait for feedback from the different vendors? (I would hate to cause a > simular situation again) > > 3. Should I post V3 on top of drm-next or drm-misc-next? The normal rule is: always work on drm-tip. That is what gets tested by our CI as well. Yes, it does mean a bit of extra hurdles during development since drm-tip is a rebasing tree, but there are tools like dim retip to help out here. As for where to merge them. I would generally recommed against merging i915 patches through drm-misc unless there is a very compelling reason to do so. i915 is a fast moving target and if there are significant changes coming in via drm-misc they usually will cause conflicts for people during drm-tip rebuild. Also I would expect to see an ack requested from i915 maintainers for merging anything significant via drm-misc, which I don't think happened in this case. -- Ville Syrjälä Intel
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com> To: Fernando Ramos <greenfoo@u92.eu> 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: Mon, 4 Oct 2021 11:19:01 +0300 [thread overview] Message-ID: <YVq49SWuC3T7i1a6@intel.com> (raw) In-Reply-To: <YVjd7hLKtYG2bkY7@zacax395.localdomain> On Sun, Oct 03, 2021 at 12:32:14AM +0200, Fernando Ramos wrote: > On 21/10/02 09:13AM, Fernando Ramos wrote: > > > > Sean, could you revert the whole patch series? I'll have a deeper look into the > > patch set and come up with a v3 where all these issues will be addressed. > > > > Hi Sean, > > I now understand the nature of the issue that caused the problem with i915 and > have proceed to remove the global context structure (which revealed a similar > issue in the amdgpu driver). > > I have prepared a V3 version of the patch set where these issues should > hopefully be fixed for both the i915 and amdgpu drivers. > > In order to prevent causing more disruption, could you tell me what the proper > way to proceed would be? In particular: > > 1. Is there any place where I can push my changes so that they are tested > on a i915 machine? (Some type of automated pool) cc:intel-gfx, which it looks like you did, _but_ your patches did did not even apply against drm-tip so our CI rejected it. There was a reply to the patches from CI indicating that. And that is one reason I probably just ignored the whole thing. If it doesn't even apply/build it's not worth my time to read. > > 2. I can test the amdgpu driver on my machine but, what about all the other > architectures? What is the standard procedure? Should I simply publish V3 > and wait for feedback from the different vendors? (I would hate to cause a > simular situation again) > > 3. Should I post V3 on top of drm-next or drm-misc-next? The normal rule is: always work on drm-tip. That is what gets tested by our CI as well. Yes, it does mean a bit of extra hurdles during development since drm-tip is a rebasing tree, but there are tools like dim retip to help out here. As for where to merge them. I would generally recommed against merging i915 patches through drm-misc unless there is a very compelling reason to do so. i915 is a fast moving target and if there are significant changes coming in via drm-misc they usually will cause conflicts for people during drm-tip rebuild. Also I would expect to see an ack requested from i915 maintainers for merging anything significant via drm-misc, which I don't think happened in this case. -- Ville Syrjälä Intel
next prev parent reply other threads:[~2021-10-04 8:19 UTC|newest] Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-24 6:43 [PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible Fernando Ramos 2021-09-24 6:43 ` [Nouveau] " Fernando Ramos 2021-09-24 6:43 ` [Intel-gfx] " Fernando Ramos 2021-09-24 6:43 ` [PATCH v2 01/17] drm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN() Fernando Ramos 2021-09-24 6:43 ` [Nouveau] " Fernando Ramos 2021-09-24 6:43 ` [Intel-gfx] " Fernando Ramos 2021-09-24 6:43 ` [PATCH v2 02/17] drm/i915: " Fernando Ramos 2021-09-24 6:43 ` [Nouveau] " Fernando Ramos 2021-09-24 6:43 ` [Intel-gfx] " Fernando Ramos 2021-09-24 6:43 ` [PATCH v2 03/17] drm/msm: " Fernando Ramos 2021-09-24 6:43 ` [Nouveau] " Fernando Ramos 2021-09-24 6:43 ` [Intel-gfx] " Fernando Ramos 2021-09-24 6:43 ` [PATCH v2 04/17] drm: cleanup: drm_modeset_lock_all() " Fernando Ramos 2021-09-24 6:43 ` [Nouveau] " Fernando Ramos 2021-09-24 6:43 ` [Intel-gfx] " Fernando Ramos 2021-09-24 6:43 ` [PATCH v2 05/17] drm/vmwgfx: " Fernando Ramos 2021-09-24 6:43 ` [Nouveau] " Fernando Ramos 2021-09-24 6:43 ` [Intel-gfx] " Fernando Ramos 2021-09-24 6:43 ` [PATCH v2 06/17] drm/tegra: " Fernando Ramos 2021-09-24 6:43 ` [Nouveau] " Fernando Ramos 2021-09-24 6:43 ` [Intel-gfx] " Fernando Ramos 2021-09-24 6:43 ` [PATCH v2 07/17] drm/shmobile: " Fernando Ramos 2021-09-24 6:43 ` [Nouveau] " Fernando Ramos 2021-09-24 6:43 ` [Intel-gfx] " Fernando Ramos 2021-09-24 6:43 ` [PATCH v2 08/17] drm/radeon: " Fernando Ramos 2021-09-24 6:43 ` [Nouveau] " Fernando Ramos 2021-09-24 6:43 ` [Intel-gfx] " Fernando Ramos 2021-09-24 6:43 ` [PATCH v2 09/17] drm/omapdrm: " Fernando Ramos 2021-09-24 6:43 ` [Nouveau] " Fernando Ramos 2021-09-24 6:43 ` [Intel-gfx] " Fernando Ramos 2021-09-24 6:43 ` [PATCH v2 10/17] drm/nouveau: " Fernando Ramos 2021-09-24 6:43 ` [Nouveau] " Fernando Ramos 2021-09-24 6:43 ` [Intel-gfx] " Fernando Ramos 2021-09-24 6:43 ` [PATCH v2 11/17] drm/msm: " Fernando Ramos 2021-09-24 6:43 ` [Nouveau] " Fernando Ramos 2021-09-24 6:43 ` [Intel-gfx] " Fernando Ramos 2021-09-24 6:43 ` [PATCH v2 12/17] drm/i915: " Fernando Ramos 2021-09-24 6:43 ` [Nouveau] " Fernando Ramos 2021-09-24 6:43 ` [Intel-gfx] " Fernando Ramos 2021-09-24 6:43 ` [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] " Fernando Ramos 2021-09-24 6:43 ` [Intel-gfx] " Fernando Ramos 2021-09-24 6:43 ` [PATCH v2 14/17] drm/gma500: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() Fernando Ramos 2021-09-24 6:43 ` [Nouveau] " Fernando Ramos 2021-09-24 6:43 ` [Intel-gfx] " Fernando Ramos 2021-09-24 6:43 ` [PATCH v2 15/17] drm/amd: " Fernando Ramos 2021-09-24 6:43 ` [Nouveau] " Fernando Ramos 2021-09-24 6:43 ` [Intel-gfx] " Fernando Ramos 2021-09-24 6:43 ` [PATCH v2 16/17] drm: cleanup: remove drm_modeset_(un)lock_all() Fernando Ramos 2021-09-24 6:43 ` [Nouveau] " Fernando Ramos 2021-09-24 6:43 ` [Intel-gfx] " Fernando Ramos 2021-09-24 6:43 ` [PATCH v2 17/17] doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup Fernando Ramos 2021-09-24 6:43 ` [Nouveau] " Fernando Ramos 2021-09-24 6:43 ` [Intel-gfx] " Fernando Ramos 2021-09-24 7:04 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible (rev2) Patchwork 2021-10-01 18:36 ` [PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible Sean Paul 2021-10-01 18:36 ` [Intel-gfx] " Sean Paul 2021-10-01 18:36 ` [Nouveau] " Sean Paul 2021-10-01 19:00 ` Ville Syrjälä 2021-10-01 19:00 ` [Intel-gfx] " Ville Syrjälä 2021-10-01 19:00 ` [Nouveau] " Ville Syrjälä 2021-10-01 20:48 ` Sean Paul 2021-10-01 20:48 ` [Intel-gfx] " Sean Paul 2021-10-01 20:48 ` [Nouveau] " Sean Paul 2021-10-01 22:05 ` Ville Syrjälä 2021-10-01 22:05 ` [Intel-gfx] " Ville Syrjälä 2021-10-01 22:05 ` Ville Syrjälä 2021-10-02 2:30 ` [Intel-gfx] " Ville Syrjälä 2021-10-02 2:30 ` [Nouveau] " Ville Syrjälä 2021-10-02 7:13 ` Fernando Ramos 2021-10-02 7:13 ` [Nouveau] " Fernando Ramos 2021-10-02 17:28 ` Fernando Ramos 2021-10-02 17:28 ` [Nouveau] " Fernando Ramos 2021-10-04 8:01 ` Ville Syrjälä 2021-10-04 8:01 ` Ville Syrjälä 2021-10-02 22:32 ` Fernando Ramos 2021-10-02 22:32 ` [Nouveau] " Fernando Ramos 2021-10-04 8:19 ` Ville Syrjälä [this message] 2021-10-04 8:19 ` Ville Syrjälä 2021-10-04 8:39 ` Jani Nikula 2021-10-04 8:39 ` [Nouveau] " 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=YVq49SWuC3T7i1a6@intel.com \ --to=ville.syrjala@linux.intel.com \ --cc=amd-gfx@lists.freedesktop.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=freedreno@lists.freedesktop.org \ --cc=greenfoo@u92.eu \ --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: linkBe 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.