public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Lukas Wunner <lukas@wunner.de>
Cc: Archit Taneja <architt@codeaurora.org>,
	Ismo Toijala <ismo.toijala@gmail.com>,
	Hans de Goede <hdegoede@redhat.com>,
	nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Alex Deucher <alexander.deucher@amd.com>,
	Ben Skeggs <bskeggs@redhat.com>, Tejun Heo <tj@kernel.org>,
	Dave Airlie <airlied@redhat.com>
Subject: Re: [Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers
Date: Mon, 19 Feb 2018 15:54:33 +0100	[thread overview]
Message-ID: <20180219145433.GG22199@phenom.ffwll.local> (raw)
In-Reply-To: <20180219144742.yffm3ptzyrslccjj@wunner.de>

On Mon, Feb 19, 2018 at 03:47:42PM +0100, Lukas Wunner wrote:
> On Mon, Feb 19, 2018 at 03:05:53PM +0100, Daniel Vetter wrote:
> > On Mon, Feb 19, 2018 at 12:58:17PM +0100, Lukas Wunner wrote:
> > > On Mon, Feb 19, 2018 at 12:34:43PM +0100, Daniel Vetter wrote:
> > > > Well, userspace expects hotplug events, even when we runtime suspend
> > > > stuff. Hence waking shit up with polling. Imo ignoring hotplug events is a
> > > > pretty serious policy decision which is ok in the context of
> > > > vga_switcheroo, but not really as an automatic thing. E.g. usb also wakes
> > > > up if you plug something in, even with all the runtime pm stuff enabled.
> > > > Same for sata and everything else.
> > > 
> > > On the MacBook Pro, the HPD pin of external DP and HDMI ports goes into
> > > the gmux controller, which sends an interrupt on hotplug even if the GPU
> > > is powered down.
> > > 
> > > Apparently Optimus has a similar functionality, cf. 3a6536c51d5d.
> > 
> > Yeah, for vga_switcheroo and gmux setups shutting down polling explicitly
> > makes sense. I think ideally we'd stop polling in the gmux handler somehow
> > (maybe by dropping the relevant DRM_CONNECTOR_POLL flags, or outright
> > stopping it all). But not when runtime suspending the entire gpu (e.g.
> > idle system that shuts down the screen and everything, before it decides
> > a few minutes later to do a full system suspend).
> 
> nouveau, radeon and amdgpu currently use runtime PM *only* on hybrid
> graphics laptops.
> 
> Should the drivers later be extended to also use runtime PM in other
> scenarios (desktop machines, eGPUs), they can easily detect whether
> to disable polling on runtime suspend by calling apple_gmux_present()
> on Macs or the equivalent for Optimus/ATPX.

Ah, then I think the current solution is ok (if not entirely clean imo,
but that can be fixed up whenever it hurts). Implementing runtime pm for
other cases is up to the driver authors really (probably more pressing
when the gpu is on the same SoC).
-Daniel

> 
> Thanks,
> 
> Lukas
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-02-19 14:54 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-11  9:38 [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers Lukas Wunner
2018-02-11  9:38 ` [PATCH 5/5] drm/amdgpu: Fix deadlock on runtime suspend Lukas Wunner
2018-02-11  9:38 ` [PATCH 1/5] workqueue: Allow retrieval of current task's work struct Lukas Wunner
2018-02-12 17:07   ` Tejun Heo
2018-02-11  9:38 ` [PATCH 4/5] drm/radeon: Fix deadlock on runtime suspend Lukas Wunner
2018-02-11  9:38 ` [PATCH 2/5] drm: Allow determining if current task is output poll worker Lukas Wunner
2018-02-12 17:46   ` Lyude Paul
2018-02-12 17:50     ` [Intel-gfx] " Chris Wilson
2018-02-12 18:40       ` Lukas Wunner
2018-02-14  8:19     ` Lukas Wunner
2018-02-14  7:41   ` [PATCH v2] " Lukas Wunner
2018-02-14 19:07     ` Lyude Paul
2018-02-11  9:38 ` [PATCH 3/5] drm/nouveau: Fix deadlock on runtime suspend Lukas Wunner
2018-02-11 18:58 ` [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers Mike Lothian
2018-02-11 19:23   ` Lukas Wunner
2018-02-11 19:41     ` Lukas Wunner
2018-02-12  0:35       ` Mike Lothian
2018-02-12  3:39         ` Lukas Wunner
2018-02-12  9:03           ` Mike Lothian
2018-02-12  9:45             ` Lukas Wunner
2018-02-12 18:58               ` Alex Deucher
2018-02-13  8:17                 ` Lukas Wunner
2018-02-13 15:19                   ` Alex Deucher
2018-02-12 13:04 ` Imre Deak
2018-02-16  8:49   ` i915 runtime PM (was: Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers) Lukas Wunner
2018-02-16 12:33     ` Imre Deak
2018-02-12 17:43 ` [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers Lyude Paul
     [not found] ` <cover.1518338788.git.lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
2018-02-13 10:55   ` Liviu Dudau
2018-02-13 11:52     ` Lukas Wunner
2018-02-13 15:46       ` Liviu Dudau
     [not found]         ` <20180213154608.GI9111-A/Nd4k6kWRHZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2018-02-14 13:57           ` Lukas Wunner
2018-02-14  8:46 ` Lukas Wunner
2018-02-14  9:26   ` Maarten Lankhorst
     [not found]     ` <1ab1ea48-125c-a104-c11d-16d1e9d94b98-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-02-14 14:08       ` Sean Paul
2018-02-14 14:43         ` Michel Dänzer
2018-02-14 14:58           ` Sean Paul
2018-02-15  5:38             ` Lukas Wunner
2018-02-19 11:48               ` [Intel-gfx] " Daniel Vetter
2018-02-19 12:22                 ` Lukas Wunner
2018-02-17 10:38 ` Lukas Wunner
2018-02-19 11:34 ` [Nouveau] " Daniel Vetter
2018-02-19 11:58   ` Lukas Wunner
2018-02-19 14:05     ` [Intel-gfx] " Daniel Vetter
2018-02-19 14:47       ` Lukas Wunner
2018-02-19 14:54         ` Daniel Vetter [this message]
2018-02-19 15:50           ` Alex Deucher

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=20180219145433.GG22199@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=airlied@redhat.com \
    --cc=alexander.deucher@amd.com \
    --cc=architt@codeaurora.org \
    --cc=bskeggs@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hdegoede@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ismo.toijala@gmail.com \
    --cc=jiangshanlai@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=nouveau@lists.freedesktop.org \
    --cc=tj@kernel.org \
    /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