[PULL] topic/mst-suspend-resume-reprobe-2019-10-29-2
Daniel Vetter
daniel.vetter at ffwll.ch
Wed Oct 30 18:49:50 UTC 2019
On Wed, Oct 30, 2019 at 7:23 PM Lyude Paul <lyude at redhat.com> wrote:
>
> On Wed, 2019-10-30 at 10:21 +0100, Daniel Vetter wrote:
> > On Tue, Oct 29, 2019 at 11:06 PM Lyude Paul <lyude at redhat.com> wrote:
> > > topic/mst-suspend-resume-reprobe-2019-10-29-2:
> > > UAPI Changes:
> > >
> > > Cross-subsystem Changes:
> > >
> > > Core Changes:
> > > * Handle UP requests asynchronously in the DP MST helpers, fixing
> > > hotplug notifications and allowing us to implement suspend/resume
> > > reprobing
> > > * Add basic suspend/resume reprobing to the DP MST helpers
> > > * Improve locking for link address reprobing and connection status
> > > request handling in the DP MST helpers
> > > * Miscellaneous refactoring in the DP MST helpers
> > > * Add a Kconfig option to the DP MST helpers to enable tracking of
> > > gets/puts for topology references for debugging purposes
> > >
> > > Driver Changes:
> > > * nouveau: Resume hotplug interrupts earlier, so that sideband
> > > messages may be transmitted during resume and thus allow
> > > suspend/resume reprobing for DP MST to work
> > > * nouveau: Avoid grabbing runtime PM references when handling short DP
> > > pulses, so that handling sideband messages in resume codepaths with the
> > > DP MST helpers doesn't deadlock us
> > > * i915, nouveau, amdgpu, radeon: Use detect_ctx for probing MST
> > > connectors, so that we can grab the topology manager's atomic lock
> > >
> > > Note: there's some amdgpu patches that I didn't realize were pushed
> > > upstream already when creating this topic branch. When they fail to
> > > apply, you can just ignore and skip them.
> > > The following changes since commit
> > > 2e79e22e092acd55da0b2db066e4826d7d152c41:
> >
> > Out of curiosity, why did you go with a topic branch here? Usually we
> > only do those if there's a serious cross-tree coordination problem,
> > that can't be solved with some acks for merging the patches through
> > the unusual tree. Plus then some notes in the pull requests why and
> > who should pull this in. These one here doesn't seem like this is
> > necessary, and the standard approach of stuffing it all into
> > drm-misc-next should be good enough. Also rule of thumb maintainers do
> > the topic branch stuff with merges and prep and everything.
> >
> > I'm also confused with your "when they fail to apply", topic branches
> > are only ever merged, not applied individually.
> Ah sorry, I'm still a bit new to this. The reason I didn't want to just push
> this into drm-misc is because without some of the nouveau and amdgpu patches
> coming before the suspend/resume stuff there would have been regressions, and
> I didn't want to push a bunch of unrelated patches into drm-misc and cause
> issues like what happened the last time I merged a large MST series like this.
Hm, what kind of mess happened?
In general, all the tricks just move around where/who resolves the
conflicts, if there's conflicts between trees and ongoing work you
can't really avoid that. Approaches, sorted from most preferred to
least:
- Just smash it all into one tree, with maintainer acks for all the
patches that go through the "wrong" tree. Committers get to sort out
conflicts as they push new patches, maintainers get to bake them with
a backmerge. Might not be the best around merge window where there's 4
weeks of no backmerging. But even then generally not a big deal.
- 1) merge core patches 2) wait&backmerge 3) merge driver patches 4)
more waiting and backmerge 5) merge cleanups. Here author resolves
conflicts when resubmitting.
- do a topic branch if the above isn't fast enough (mostly that's for
when the conflict is with a non-drm tree, where the waiting would be a
full merge window). Here maintainers resolve conflicts when applying
the topic pull request to each of their tree.
More dance than the first option is imo only warranted if there's a
known conflict looming, not "just in case".
-Daniel
> > -Daniel
> >
> > > Merge v5.4-rc4 into drm-next (2019-10-23 12:10:05 +0200)
> > >
> > > are available in the Git repository at:
> > >
> > > git://anongit.freedesktop.org/drm/drm-misc tags/topic/mst-suspend-
> > > resume-reprobe-2019-10-29-2
> > >
> > > for you to fetch changes up to 12a280c7286857119cf0d88c487f695e3a1c0912:
> > >
> > > drm/dp_mst: Add topology ref history tracking for debugging (2019-10-24
> > > 14:36:13 -0400)
> > >
> > > ----------------------------------------------------------------
> > > UAPI Changes:
> > >
> > > Cross-subsystem Changes:
> > >
> > > Core Changes:
> > > * Handle UP requests asynchronously in the DP MST helpers, fixing
> > > hotplug notifications and allowing us to implement suspend/resume
> > > reprobing
> > > * Add basic suspend/resume reprobing to the DP MST helpers
> > > * Improve locking for link address reprobing and connection status
> > > request handling in the DP MST helpers
> > > * Miscellaneous refactoring in the DP MST helpers
> > > * Add a Kconfig option to the DP MST helpers to enable tracking of
> > > gets/puts for topology references for debugging purposes
> > >
> > > Driver Changes:
> > > * nouveau: Resume hotplug interrupts earlier, so that sideband
> > > messages may be transmitted during resume and thus allow
> > > suspend/resume reprobing for DP MST to work
> > > * nouveau: Avoid grabbing runtime PM references when handling short DP
> > > pulses, so that handling sideband messages in resume codepaths with the
> > > DP MST helpers doesn't deadlock us
> > > * i915, nouveau, amdgpu, radeon: Use detect_ctx for probing MST
> > > connectors, so that we can grab the topology manager's atomic lock
> > >
> > > Note: there's some amdgpu patches that I didn't realize were pushed
> > > upstream already when creating this topic branch. When they fail to
> > > apply, you can just ignore and skip them.
> > >
> > > ----------------------------------------------------------------
> > > Lyude Paul (14):
> > > drm/dp_mst: Destroy MSTBs asynchronously
> > > drm/dp_mst: Remove PDT teardown in drm_dp_destroy_port() and
> > > refactor
> > > drm/dp_mst: Refactor pdt setup/teardown, add more locking
> > > drm/dp_mst: Handle UP requests asynchronously
> > > drm/dp_mst: Add probe_lock
> > > drm/dp_mst: Protect drm_dp_mst_port members with locking
> > > drm/dp_mst: Don't forget to update port->input in
> > > drm_dp_mst_handle_conn_stat()
> > > drm/dp_mst: Lessen indenting in drm_dp_mst_topology_mgr_resume()
> > > drm/nouveau: Don't grab runtime PM refs for HPD IRQs
> > > drm/nouveau: Resume hotplug interrupts earlier
> > > drm/amdgpu: Iterate through DRM connectors correctly
> > > drm/amdgpu/dm: Resume short HPD IRQs before resuming MST topology
> > > drm/dp_mst: Add basic topology reprobing when resuming
> > > drm/dp_mst: Add topology ref history tracking for debugging
> > >
> > > drivers/gpu/drm/Kconfig | 14 +
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 13 +-
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 20 +-
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 5 +-
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c | 40 +-
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 5 +-
> > > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 34 +-
> > > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 34 +-
> > > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 40 +-
> > > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 34 +-
> > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 41 +-
> > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 10 +-
> > > .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 28 +-
> > > drivers/gpu/drm/drm_dp_mst_topology.c | 1176
> > > +++++++++++++++-----
> > > drivers/gpu/drm/i915/display/intel_dp.c | 3 +-
> > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 28 +-
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c | 38 +-
> > > drivers/gpu/drm/nouveau/nouveau_connector.c | 33 +-
> > > drivers/gpu/drm/nouveau/nouveau_display.c | 19 +-
> > > drivers/gpu/drm/radeon/radeon_dp_mst.c | 24 +-
> > > include/drm/drm_dp_mst_helper.h | 160 ++-
> > > 21 files changed, 1322 insertions(+), 477 deletions(-)
> > >
> >
> >
> --
> Cheers,
> Lyude Paul
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the dri-devel
mailing list