linux-kernel - Re: [PATCH v3 3/8] drm/fb_helper: Introduce hotplug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 6 Aug 2018 21:43:03 +0200
From:   Daniel Vetter <daniel@...ll.ch>
To:     Lukas Wunner <lukas@...ner.de>
Cc:     Lyude Paul <lyude@...hat.com>, Daniel Vetter <daniel@...ll.ch>,
        David Airlie <airlied@...ux.ie>, nouveau@...ts.freedesktop.org,
        Karol Herbst <karolherbst@...il.com>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org
Subject: Re: [PATCH v3 3/8] drm/fb_helper: Introduce hotplug_suspend/resume()

On Mon, Aug 06, 2018 at 09:34:57PM +0200, Lukas Wunner wrote:
> On Mon, Aug 06, 2018 at 03:15:31PM -0400, Lyude Paul wrote:
> > You did mention in the review of one of my other patches that we should avoid
> > disabling polling during runtime suspend, and you're definitely right. I feel
> > a bit silly for not remembering that since I was the one who made it so that
> > i915 does polling in runtime suspend for chips without RPM HPD detection in
> > the first place because it was causing people's displays not to come up on
> > vlv...
> > Anyway: I think if we just leave output polling enabled during runtime suspend
> > that might actually fix all of the fb_helper locking issues since we won't
> > need to wait on any of the output poll workers to finish, at least I think it
> > should: I'll confirm this when I get into the office
> 
> Quoth Imre Deak:
> 
>    "In i915 polling is on during runtime suspend only if there are outputs
>     without hotplug interrupt support. A special case is when an output has
>     working HPD interrupts when in D0, but no interrupts when runtime
>     suspended. For these we start polling (from a scheduled work) in the
>     runtime suspend hook and stop it in the runtime resume hook (again from
>     a scheduled work)."
>     https://lkml.org/lkml/2018/2/12/330
> 
> nouveau only uses runtime PM on discrete GPUs in dual GPU laptops.
> Resuming the GPU from D3cold to D0 every few seconds to poll the
> outputs would waste too much power on such machines.
> 
> The question is, why is polling running at all, since all modern
> laptops have HPD-capable ports such as DP?

Note we don't fully sync with the poll worker here, we just update the
polling flags and let the poll worker lazily notice the change (and stop
itsefl). That avoids the deadlock. It also means that the poll worker must
call pm_runtime_get() in all the right places though.

On resume we need to kick it again, but that doesn't have a deadlock
potential.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch