Re: [PATCH 3/4] drm: Only lastclose on unload for legacy drivers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux