[Intel-gfx] [PATCH 3/4] drm: Only lastclose on unload for legacy drivers
Daniel Vetter
daniel.vetter at ffwll.ch
Thu Aug 3 13:54:34 UTC 2017
On Thu, Aug 3, 2017 at 1:17 AM, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> On Wed, Aug 2, 2017 at 10:50 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
>> On Wed, Aug 2, 2017 at 7:56 AM, Daniel Vetter <daniel.vetter at 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
More information about the Intel-gfx
mailing list