All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 3/4] drm: Only lastclose on unload for legacy drivers
Date: Thu, 3 Aug 2017 15:54:34 +0200	[thread overview]
Message-ID: <CAKMK7uG2XNYk-7uc0Rf27SseKcknCXeqL-RRdajCDeX5ceQ4+Q@mail.gmail.com> (raw)
In-Reply-To: <CAKMK7uH7sirxfNKV9FAOJS23QHMrniSQ-5yX72V_N9uCfH947w@mail.gmail.com>

On Thu, Aug 3, 2017 at 1:17 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Wed, Aug 2, 2017 at 10:50 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> On Wed, Aug 2, 2017 at 7:56 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>>> The only thing modern drivers are supposed to do in lastclose is
>>> restore the fb emulation state. Which is entirely optional, and
>>> there's really no reason to do that. So restrict it to legacy drivers
>>> (where the driver cleanup essentially happens in lastclose).
>>
>> vga_switcheroo_process_delayed_switch() gets called in lastclose.
>> Won't that need to get moved elsewhere for this to work?
>
> Hm right, I forgot the lazy way to do runtime pm by keeping the device
> alive as long as anyone has an open fd for it ... This shouldn't be a
> problem, since you need to unregister from vgaswitcheroo anyway on
> unload. Maybe that blows up, I'll check the code and augment the patch
> as needed.

So I think there's 3 cases:
- Trying to unload the module. You can't do that while anyone has the
fd still open, so lastclose is guaranteeed to run.
- Forcefully unbinding the driver through sysfs. Not any better, since
the can_switch stuff checks for the open count, and so will delay the
delayed switch no matter what.
- Actual hotremoval: a) not implemented since none of the drivers
taking part in vgaswitcheroo correctly unplug the drm device and b)
you can't hotremove a chip from a laptop.

So I think I'm not breaking this anymore than it probably already is :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2017-08-03 13:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-02 11:56 [PATCH 0/4] drm unplugging docs Daniel Vetter
2017-08-02 11:56 ` [PATCH 1/4] drm: Extract drm_device.h Daniel Vetter
2017-08-02 11:56 ` [PATCH 2/4] drm: Document device unplug infrastructure Daniel Vetter
2017-08-02 11:56 ` [PATCH 3/4] drm: Only lastclose on unload for legacy drivers Daniel Vetter
2017-08-02 20:50   ` Alex Deucher
2017-08-02 23:17     ` Daniel Vetter
2017-08-03 13:54       ` Daniel Vetter [this message]
2017-08-03 17:52         ` Alex Deucher
2017-08-11  8:49           ` Daniel Vetter
2017-08-04  4:12         ` Michel Dänzer
2017-08-04  9:15           ` Daniel Vetter
2017-08-02 11:56 ` [PATCH 4/4] drm: Clean up drm_dev_unplug Daniel Vetter
2017-08-02 12:26 ` ✓ Fi.CI.BAT: success for drm unplugging docs Patchwork

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=CAKMK7uG2XNYk-7uc0Rf27SseKcknCXeqL-RRdajCDeX5ceQ4+Q@mail.gmail.com \
    --to=daniel.vetter@ffwll.ch \
    --cc=alexdeucher@gmail.com \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.