Nouveau - Oct 2021 - [Intel-gfx] [PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible

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)

  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?

Thanks for your patience :)

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