All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel@daenzer.net>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
	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: Fri, 4 Aug 2017 13:12:36 +0900	[thread overview]
Message-ID: <da6d83e5-4e3e-0d54-37e5-4f3cacb652f2@daenzer.net> (raw)
In-Reply-To: <CAKMK7uG2XNYk-7uc0Rf27SseKcknCXeqL-RRdajCDeX5ceQ4+Q@mail.gmail.com>

On 03/08/17 10:54 PM, Daniel Vetter wrote:
> 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.

Are you sure that this is working as intended?
https://bugs.freedesktop.org/show_bug.cgi?id=100399 sounds like
unbinding works even while Xorg is using the DRM device.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2017-08-04  4:12 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
2017-08-03 17:52         ` Alex Deucher
2017-08-11  8:49           ` Daniel Vetter
2017-08-04  4:12         ` Michel Dänzer [this message]
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=da6d83e5-4e3e-0d54-37e5-4f3cacb652f2@daenzer.net \
    --to=michel@daenzer.net \
    --cc=alexdeucher@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --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.