On Thu, Aug 03, 2017 at 01:52:55PM -0400, Alex Deucher wrote: > On Thu, Aug 3, 2017 at 9:54 AM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > > On Thu, Aug 3, 2017 at 1:17 AM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > >> On Wed, Aug 2, 2017 at 10:50 PM, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > >>> On Wed, Aug 2, 2017 at 7:56 AM, Daniel Vetter <daniel.vetter@xxxxxxxx> 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 :-) Added the above to the commit message ... > > Thanks. This series is: > Reviewed-by: Alex Deucher <alexander.deucher@xxxxxxx> ... and pulled the entire series in. Thanks for your review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
