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
next prev parent reply other threads:[~2021-10-04 8:19 UTC|newest]
Thread overview: 29+ 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 ` [PATCH v2 01/17] drm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN() Fernando Ramos
2021-09-24 6:43 ` [PATCH v2 02/17] drm/i915: " Fernando Ramos
2021-09-24 6:43 ` [PATCH v2 03/17] drm/msm: " Fernando Ramos
2021-09-24 6:43 ` [PATCH v2 04/17] drm: cleanup: drm_modeset_lock_all() " Fernando Ramos
2021-09-24 6:43 ` [PATCH v2 05/17] drm/vmwgfx: " Fernando Ramos
2021-09-24 6:43 ` [PATCH v2 06/17] drm/tegra: " Fernando Ramos
2021-09-24 6:43 ` [PATCH v2 07/17] drm/shmobile: " Fernando Ramos
2021-09-24 6:43 ` [PATCH v2 08/17] drm/radeon: " Fernando Ramos
2021-09-24 6:43 ` [PATCH v2 09/17] drm/omapdrm: " Fernando Ramos
2021-09-24 6:43 ` [PATCH v2 10/17] drm/nouveau: " Fernando Ramos
2021-09-24 6:43 ` [PATCH v2 11/17] drm/msm: " Fernando Ramos
2021-09-24 6:43 ` [PATCH v2 12/17] drm/i915: " 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 ` [PATCH v2 14/17] drm/gma500: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() Fernando Ramos
2021-09-24 6:43 ` [PATCH v2 15/17] drm/amd: " 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 ` [PATCH v2 17/17] doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup Fernando Ramos
2021-10-01 18:36 ` [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 ` [Intel-gfx] " Ville Syrjälä
2021-10-02 7:13 ` Fernando Ramos
2021-10-02 17:28 ` Fernando Ramos
2021-10-04 8:01 ` Ville Syrjälä
2021-10-02 22:32 ` Fernando Ramos
2021-10-04 8:19 ` Ville Syrjälä [this message]
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=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: 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).