All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Herrmann <dh.herrmann@gmail.com>
To: "Stéphane Marchesin" <stephane.marchesin@gmail.com>
Cc: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>, Haixia Shi <hshi@chromium.org>
Subject: Re: [PATCH 2/2] drm: make unplugged flag specific to udl driver
Date: Wed, 10 Feb 2016 23:09:34 +0100	[thread overview]
Message-ID: <CANq1E4SQuJ5dR-9WBenm4VkifsmYLc2TH7drV_MVEZEv_bo8gg@mail.gmail.com> (raw)
In-Reply-To: <CACP_E++Xaave8b6ZyJ6YCaRnPqYM7RCHgKoHa18uSYzR2JUVkw@mail.gmail.com>

Hi

On Wed, Feb 10, 2016 at 11:02 PM, Stéphane Marchesin
<stephane.marchesin@gmail.com> wrote:
> On Wed, Feb 10, 2016 at 1:54 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>>> If a device is unplugged, you should consider all your resources to be
>>>> destroyed. There is no reason to release them manually. User-space
>>>> *must* be able to deal with asynchronous unplugs.
>>>
>>> So the problem if you do that is that things like a buffer's memory
>>> pages can disappear from under you. How would you deal with that case?
>>> User space certainly can't have a segfault handler catch that just in
>>> case :)
>>
>> If you rip out hardware resources, then you better be able to deal
>> with it. Sure, UDL is an exception as it doesn't have memory resources
>> on the chip. But it sounds fishy to me, if you base your API on it. On
>> a lot of other devices, the memory will simply not be there. So you
>> cannot keep it around.
>
> The thing is, you are not unplugging a device here; you are unplugging
> a USB monitor. As a proof that this is just a monitor, I can plug
> another USB monitor with the same driver and pick up where I left off.
> I guess I am saying that the concept of unplugging a device is not
> applicable here (or to any driver that I know, for that matter).
>
> Other drivers already handle all this by, for example, failing page
> flips if the monitor is gone. We basically want to do the same for
> UDL; I don't think we need to invent a new level of unplug here.

No, you rip out a display controller. You don't just unplug a monitor,
you remove the whole hardware. If UDL were treated on the same level
as connector-hotplugging, then you should implement it that way. But
currently it is not.

Btw., even if you do this, you still have to deal with devices going
away, and new devices being plugged. DRM does not support
CRTC/connector hotplugging, yet. Hence, making UDL a singleton driver
will not work either.

>>
>> There are many ways to invalidate memory mappings. You either unmap
>> the entire range (and user-space must deal with SIGBUS, which is
>> completely feasible and a lot of code already does it), or you replace
>> all with a zero page, or you duplicate all pages, ... IMO, user-space
>> has to start dealing with hardware unplug properly and stop pretending
>> it cannot happen.
>
> What you are suggesting is much more complicated than you claim, for
> example if you destroy the dmabuf which is shared with another driver,
> what happens? User space definitely can't deal with that.
>
> I think we should wait until we have unpluggable display hardware
> before inventing really complex support for it.

PCI Hotplugging. Has been around since a decade. Intel just got lucky
that they cannot be ripped out. The other drivers don't care (and
break horribly if you do).

Feel free to come up with a better way to deal with UDL hotplugging.
However, I for myself recommend doing it properly, on the bus level.
Like all other subsystems do.

Thanks
David
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2016-02-10 22:09 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-05 21:57 [PATCH 1/2] drm/msm: remove the drm_device_is_unplugged check Haixia Shi
2016-02-05 21:57 ` [PATCH 2/2] drm: make unplugged flag specific to udl driver Haixia Shi
2016-02-09 12:44   ` David Herrmann
2016-02-09 20:45     ` Haixia Shi
2016-02-09 20:52       ` David Herrmann
2016-02-10 23:16   ` [PATCH v2 2/2] drm: remove drm_device_is_unplugged checks in common drm code Haixia Shi
2016-02-09 10:25 ` [PATCH 1/2] drm/msm: remove the drm_device_is_unplugged check David Herrmann
2016-02-09 13:03   ` Daniel Vetter
2016-02-09 21:05 ` [PATCH 2/2] drm: make unplugged flag specific to udl driver Haixia Shi
2016-02-10  6:27   ` Daniel Vetter
2016-02-10 12:24   ` David Herrmann
2016-02-10 20:39     ` Haixia Shi
2016-02-10 21:38       ` David Herrmann
2016-02-10 21:46         ` Stéphane Marchesin
2016-02-10 21:54           ` David Herrmann
2016-02-10 22:02             ` Stéphane Marchesin
2016-02-10 22:09               ` David Herrmann [this message]
2016-02-11  8:17               ` Daniel Vetter
2016-02-10 20:51     ` Haixia Shi
2016-02-10 21:00       ` Haixia Shi
2016-02-10 21:33         ` David Herrmann
2016-02-10 21:35       ` David Herrmann
2016-02-10 21:38         ` Haixia Shi
2016-02-10 21:40           ` David Herrmann
2016-02-10 23:18 ` [PATCH v2 2/2] drm: remove drm_device_is_unplugged checks in common drm code Haixia Shi
2016-02-11  8:19   ` Daniel Vetter
2016-02-11 10:30   ` David Herrmann
2016-02-11 19:19     ` Haixia Shi
2016-02-11 21:57     ` [PATCH v3 2/2] drm: remove drm_device_is_unplugged and related code Haixia Shi
2016-02-12  6:22       ` Daniel Vetter
2016-02-12 19:50       ` Haixia Shi
2016-02-17  0:27         ` Haixia Shi
2016-02-26 14:29         ` David Herrmann

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=CANq1E4SQuJ5dR-9WBenm4VkifsmYLc2TH7drV_MVEZEv_bo8gg@mail.gmail.com \
    --to=dh.herrmann@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hshi@chromium.org \
    --cc=stephane.marchesin@gmail.com \
    /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.